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.
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
