Yo siempre estoy dispuesto a estudiar día con día👨🏽🎓, por aquello que dicen de que «se es vieja o viejo cuando se deja de aprender«. Viendo (y disfrutando) la transmisión en vivo de los amigos de Tecnocrática una cosa (y es el comienzo apenas) que llamó mi atención fue lo de la mención de Fail2ban y su degradación al manejar un alto volumen de direcciones IP, ahora incluso los abusos que vienen por IPv6.
Y esto que para nada culpa nuestra, los administradores de red, sino que simplemente somos víctimas no más: Si atacan nuestros servidores de lo que sea (principalmente los servidores web con Nginx y Apache2) que pues Fail2ban hará el trabajo que le encomendamos y sumará a su lista una gran cantidad de direcciones IP que harán lento a nuestro servidor. Es por ello que me puse a investigar el tema y hoy, humildemente, retribuyo mis hallazgos.
Sobre estas líneas coloco el enlace el vídeo completo del endurecimiento de seguridad de nuestros servidores GNU/Linux®, clase magistral dictada por los amigos de Tecnocrática (Madrid, Reino de España🇪🇸); abajo está en la sección de fuentes consultadas va el resto de los enlaces.
Pues nada, comencemos y al grano.
Fail2ban e Iptables
- Algo que yo sabía era que Fail2ban funciona con lenguaje Python haciendo uso de Iptables.
- También conocía, o al menos lo escuché nombrar, que Nftables existe y no de ahora sino ya desde hace años (qué rápido pasa el tiempo ¿Cierto? 😯 ).
- Lo que yo desconocía, y aprendo hoy, es que Fail2ban soporta varias maneras de hacer valer los bloqueos.
- Y bueno, he de admitirlo, desde que lo conocí e instalé lo he utilizado superficialmente, justo para mis necesidades. Esto es así porque el tiempo es finito aunque los problemas son infinitos y sin embargo siempre hay que ser prácticos.
Causas por las que Fail2ban puede ir lento
Esta es mi situación, la vuestra ha de ser (y debe de ser) diferente, los numero en orden de importancia:
- Multitud de ataques de fuerza bruta: Esto último se ha incrementado hace cosa de un año con lo de las LucIA que pululan por allí, por estos lares estamos siendo explorados (y atacados) por un tal Jean-Claude Van Damme 😉. Esto por sí solo sobrecarga nuestros sistemas.
- Una gran cantidad de direcciones IP registradas y bloqueadas: (Ver punto 1) Vamos que una cosa es visitar tu sitio web en búsqueda de información, pongamos que una vez al día, y otra cosa muy distinta es tratar de ingresar explícitamente a vuestros sistemas. Es más (dentro de mi «ignorancia») si ninguna cuenta de usuario, señor(a) visitante, tenéis registrado en mi sitio web ¿Por qué demonios visitáis mi página de inicio de sesión? (Cuidado y si tengo razón, ahora con esto de las « LucIA » pues bien que saben lo que hacen; ya eso dejó de ser como hace décadas con los buscadores o «arañas web»).
- Tiempo de bloqueo largo: Mea culpa. «Por mi culpa, por mi culpa, por mi gran culpa».
- Base de datos sobrecargada: Esto yo lo había olvidado, Fail2ban utiliza SQLite como base de datos (BB.DD.) para almacenar los datos pertinente para su trabajo. El asunto es mantener dicha base de datos como tal, y es algo ajeno a Fail2ban. Al momento de escribir estas líneas, para 4121 direcciones IP bloqueadas tengo una base de datos de 281 megabytes, eso es más de 70 kilobytes de información por cada una de ellas. Esto es, sencillamente, inaceptable.
Mantenimiento de la base de datos en SQLite
Repito, esto va más allá de las capacidades de Fail2ban, en general cualquier software que utilice alguna base de datos (y la gran pregunta en este año 2026 es ¿Cuál software funciona sin una base de datos?🤔) corre y ejecuta sin inmiscuirse en los vericuetos del funcionamiento de su BB.DD. correspondiente.
Las siguientes instrucciones son para Ubuntu server 24.04 y sus correspondientes versiones de software instalado por los repositorios oficiales.
Por ello podemos primero realizarlo manualmente y luego pues agregarlo a un Cron mensual. Comencemos:
- Verificar si tenemos instalado SQLite versión 3:
sudo apt update && sudo apt install sqlite3
- Detener el servicio Fail2ban para evitar escrituras en la base de datos durante el proceso de compactación:
sudo systemctl stop fail2ban
- Compactar la base de datos SQLite:
sudo sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "VACUUM;"
- Reanudar el servicio Fail2ban con la base de datos ya compactada:
sudo systemctl start fail2ban
En mi caso particular de 281 megabytes la BB.DD. quedó en apenas 1,9 megabytes, eso es poco más de 426 bytes por cada dirección IP bloqueada.
- Una vez hayamos comprobado que funciona pues haremos un guion (
/etc/cron.monthly/fail2ban-vacuum) que ejecutaremos mensualmente sin nuestra intervención:
#!/bin/bash
systemctl stop fail2ban # Stop Fail2ban service.
sqlite3 /var/lib/fail2ban/fail2ban.sqlite3 "VACUUM;" # Execute vacuum SQLite db.
systemctl start fail2ban # Start Fail2ban service.
Dicho guion (o script, para que me entiendan) pues lo hacemos que sea ejecutable:
sudo chmod +x /etc/cron.monthly/fail2ban-vacuum
Lo comprobamos con:
sudo run-parts --verbose /etc/cron.monthly/
La respuesta debería ser cero (recomiendo usar Powerline por practicidad). Téngase en cuenta que este método de comprobación también ejecutara cualquier otro guion que ya hayamos planificado, revisar con:
sudo journalctl -u cron -n 100
De esta última ventana saldremos presionando la tecla Q.
Cambiando Iptables por Nftables
Pues a lo que vinimos: Cambiar la manera con la que Fail2ban hace valer sus bloqueos.
- Verificar que Nftables está instalado (sí, ya viene por defecto con Ubuntu server 24.04, «seguro mató confiado»):
sudo apt update && sudo apt install ipset nano -y
- Editar el fichero
sudo nano /etc/fail2ban/jail.local(fichero recomendado para mantener nuestra configuración cuando hagamos actualización mayor –upgrade– a la próxima versión LTS de Ubuntu server).
Recordemos la manera de leer las carpetas y ficheros de configuración de Fail2ban en su directorio /etc/fail2ban/:
…/jail.conf → …/jail.d/*.conf → …/jail.local → …/jail.d/*.local
De esta manera en …/jail.local solamente colocaremos nuestros parámetros preferidos, los cuales serán los últimos en ser leídos y utilizados (a menos que tengamos algo más en …/jail.d/*.local):
[DEFAULT]
# Actually by default for new Fail2ban installations:
banaction = nftables
# No inline argument, no parameters to "/etc/fail2ban/action.d/nftables-allports.conf":
banaction_allports = nftables-allports
# No read log files, use binary logs by Journal:
backend = systemd
[Definition]
allowipv6 = auto
[sshd]
enabled = true
He incluido en [Definition] de manera explícita el manejo de direcciones IPv6 para que sea automática la elección de este protocolo, de tenerlo en funcionamiento. La sección [sshd] es el primero y el que siempre agregamos a ser vigilado por Fail2ban, las sesiones SSH. A partir de allí agregaremos lo que tengamos, si es cada caso: Dovecot, WordPress, etcétera.
LuCIA
Fuentes consultadas
En idioma castellano
- «https://es.wikipedia.org/wiki/Fail2ban».
- «https://es.wikipedia.org/wiki/Iptables».
- «https://es.wikipedia.org/wiki/Nftables».
- «https://tecnocratica.net/wikicratica/books/linux/page/hardening-linux-a-mano-guia-paso-a-paso».
En idioma francés
- «».
- «».
- «».
En idioma inglés
