Guía de configuración de fail2ban para servidores Linux: jails, nftables y pruebas

Fail2ban vigila los registros (logs) de su servidor en busca de fallos repetidos (contraseñas SSH incorrectas, inicios de sesión de correo fallidos, intentos de adivinar accesos web) y bloquea temporalmente en el firewall la dirección IP responsable. En un servidor Linux sin panel de control, la configuración correcta es: poner todos los ajustes en jail.local (nunca editar jail.conf), leer los fallos de SSH desde el journal de systemd, usar acciones de nftables o firewalld, bloquear por más tiempo a los reincidentes, excluir sus propias direcciones y probar cada filtro con fail2ban-regex. Fail2ban reduce el ruido y frena los intentos de adivinar contraseñas, pero no reemplaza el inicio de sesión SSH solo con llaves.

Esta guía cubre servidores actuales con Debian 12/13, Ubuntu 24.04 y RHEL/AlmaLinux 9/10. (Los servidores cPanel tienen sus propias herramientas; las trataremos por separado.)

Lo que fail2ban hace y lo que no hace

Fail2ban funciona con "jails" (cárceles). Cada jail combina un filtro (expresiones regulares que reconocen un fallo en un log), una fuente de logs (un archivo o el journal de systemd) y una acción (normalmente un bloqueo en el firewall). Cuando una IP produce maxretry fallos dentro de findtime, queda bloqueada durante bantime.

Es útil contra:

• Intentos de adivinar contraseñas en SSH, correo (SMTP AUTH de Postfix, IMAP/POP3 de Dovecot) e inicios de sesión web.
• Escáneres ruidosos que llenan los logs y consumen recursos.

Es débil contra:

• Ataques distribuidos. Una botnet que prueba una contraseña desde cada una de miles de direcciones nunca alcanza un límite por IP.
• Ataques que no registran un fallo, como la explotación de una aplicación vulnerable.
• Atacantes con credenciales válidas. Una contraseña robada entra al primer intento.

Por eso fail2ban es una capa, no la cerradura. La cerradura es la autenticación SSH por llaves con las contraseñas desactivadas, tema de nuestra guía de fundamentos de endurecimiento de servidores Linux.

Paso 1: Instale fail2ban

## Debian / Ubuntu
sudo apt update
sudo apt install fail2ban python3-systemd

## RHEL / AlmaLinux / Rocky (fail2ban viene de EPEL)
sudo dnf install epel-release     # en RHEL, active EPEL según la documentación de Fedora EPEL
sudo dnf install fail2ban
sudo systemctl enable --now fail2ban

La versión upstream actual es fail2ban 1.1.1 (agosto de 2026); cada distribución publica su propia versión empaquetada. En Ubuntu 24.04, confirme que el servicio realmente arrancó con systemctl status fail2ban: el paquete original de 24.04 fallaba con Python 3.12 (bug 2055114 de Launchpad), así que asegúrese de tener las últimas actualizaciones instaladas.

Paso 2: Nunca edite jail.conf, cree jail.local

El encabezado de jail.conf lo dice claramente: no modifique este archivo, porque las actualizaciones del paquete pueden sobrescribirlo. Ponga sus cambios en /etc/fail2ban/jail.local o en archivos dentro de /etc/fail2ban/jail.d/ que terminen en .local. Los ajustes de los archivos .local reemplazan los valores predeterminados.

Muchos paquetes de distribución ya colocan un archivo en jail.d/ (por ejemplo, defaults-debian.conf de Debian activa la jail de sshd). Revise primero qué hay con ls /etc/fail2ban/jail.d/.

Un jail.local inicial razonable:

[DEFAULT]
## IP fija de su oficina, rango de la VPN y servidor de monitoreo. Nunca bloquearlos.
ignoreip = 127.0.0.1/8 ::1 203.0.113.10 10.8.0.0/24

bantime  = 1h
findtime = 10m
maxretry = 5

## Los reincidentes reciben bloqueos cada vez más largos
bantime.increment = true
bantime.factor    = 1
bantime.maxtime   = 1w

## Acciones de nftables (Debian 12/13, Ubuntu 24.04 con nftables)
banaction          = nftables-multiport
banaction_allports = nftables-allports

Reemplace las direcciones de ejemplo por las suyas. Olvidar ignoreip es la forma clásica de dejar a su propia oficina fuera después de que alguien escribe mal una contraseña varias veces.

Qué acción de bloqueo usar

• Debian/Ubuntu con nftables: nftables-multiport y nftables-allports vienen en /etc/fail2ban/action.d/. Los paquetes recientes de Debian ya usan nftables por defecto.
• RHEL/AlmaLinux con firewalld: use las acciones de firewalld (firewallcmd-rich-rules, firewallcmd-ipset o firewallcmd-multiport). El paquete fail2ban-firewalld de EPEL lo configura por usted, así que no cambie banaction a nftables en esos servidores.
• Ubuntu con ufw: existe una acción ufw, pero mezclar herramientas complica el diagnóstico; elija una sola interfaz de firewall por servidor.

Cómo funciona bantime.increment

Con bantime.increment = true, fail2ban recuerda los bloqueos anteriores en su base de datos y multiplica el tiempo de bloqueo cada vez que la misma dirección regresa, hasta bantime.maxtime. El primer bloqueo es corto, así que un empleado que se equivoca de contraseña no queda fuera por mucho tiempo, mientras que un escáner persistente termina bloqueado una semana. La jail [recidive] es una alternativa más antigua que bloquea las direcciones que siguen apareciendo en el propio log de fail2ban; no necesita ambas.

Paso 3: La jail de sshd con el backend de systemd

Los servidores modernos registran SSH en el journal de systemd. Debian 12 y versiones posteriores ya no instalan rsyslog por defecto, así que /var/log/auth.log puede no existir, y una jail basada en archivos no vigilaría nada sin avisarle. Use el journal:

[sshd]
enabled  = true
backend  = systemd
port     = ssh
maxretry = 4
## Opcional: detectar también sondeos previos a la autenticación y otro ruido
mode     = aggressive

El filtro upstream reconoce la unidad sshd.service y los procesos sshd y sshd-session (las versiones recientes de OpenSSH registran la autenticación desde sshd-session). En Debian y Ubuntu la unidad se llama ssh.service, así que agregue allí la línea correspondiente:

journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Si movió SSH a otro puerto, indique port = 2222 (o su puerto); de lo contrario el bloqueo se aplicará al puerto equivocado.

Paso 4: Jails para servicios web y de correo

Active solo las jails de los servicios que realmente funcionan en el servidor.

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

[apache-auth]
enabled = true

[postfix]
enabled = true
mode    = aggressive

[dovecot]
enabled = true

Notas:

• nginx-http-auth y apache-auth detectan fallos de autenticación HTTP básica. No entienden el formulario de inicio de sesión de su aplicación; protéjalo con límites de velocidad o un WAF.
• nginx-botsearch bloquea a los clientes que buscan rutas de administración comunes que no existen.
• postfix y dovecot cubren los intentos de adivinar contraseñas en SMTP AUTH e IMAP/POP3. En servidores donde los logs de correo solo van al journal (Debian 12 o posterior sin rsyslog), indique también backend = systemd en estas jails y confirme con fail2ban-regex que el filtro realmente coincide; si no, apunte logpath a su log de correo.

Paso 5: Pruebe antes de confiar

fail2ban-regex ejecuta un filtro contra logs reales e informa cuántas líneas coincidieron. Ejecútelo siempre después de activar una jail:

## Un log en archivo
sudo fail2ban-regex /var/log/nginx/error.log /etc/fail2ban/filter.d/nginx-http-auth.conf

## El journal de systemd (se muestra el nombre de unidad de Debian/Ubuntu)
sudo fail2ban-regex systemd-journal sshd \
  -m "_SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session"

Una jail con cero coincidencias en un servidor que claramente está siendo sondeado está mal configurada. Luego recargue y verifique que las jails estén funcionando:

sudo fail2ban-client -t            # probar la configuración
sudo systemctl reload fail2ban
sudo fail2ban-client status        # listar jails
sudo fail2ban-client status sshd   # fallos e IP bloqueadas de una jail

Paso 6: Revise y levante bloqueos

sudo fail2ban-client status sshd                 # bloqueos actuales
sudo fail2ban-client set sshd unbanip 198.51.100.7
sudo fail2ban-client unban 198.51.100.7          # quitar de todas las jails
sudo nft list ruleset | less                     # ver el lado del firewall

Si un empleado queda bloqueado una y otra vez, el problema suele ser una contraseña antigua guardada en un cliente de correo o en un script, no un ataque. Corrija el cliente y luego desbloquee.

Combínelo con SSH solo con llaves

Fail2ban solo reacciona después de los fallos. La configuración que hace inútil adivinar contraseñas SSH es:

• PasswordAuthentication no y KbdInteractiveAuthentication no en sshd_config (salvo que use keyboard-interactive para 2FA).
• PermitRootLogin no (o prohibit-password donde root deba entrar con una llave).
• SSH accesible solo desde su oficina o VPN cuando sea posible, mediante el firewall.
• Actualizaciones de seguridad automáticas, para que un servicio vulnerable no sea la puerta de entrada.

Con eso en su lugar, fail2ban sirve sobre todo para mantener los logs legibles y reducir la carga. Sigue siendo valioso para los inicios de sesión de correo y web, donde todavía se usan contraseñas.

Lista de verificación rápida

• Ajustes en jail.local o jail.d/*.local, nunca en jail.conf.
• ignoreip incluye las direcciones de su oficina, VPN y monitoreo.
• Jail de sshd con el backend de systemd y el nombre de unidad correcto.
• La acción de bloqueo coincide con su firewall (nftables o firewalld).
• bantime.increment activado con un bantime.maxtime razonable.
• Cada jail probada con fail2ban-regex.
• SSH solo con llaves y parches al día, porque fail2ban no los sustituye.

¿Necesita ayuda para proteger sus servidores Linux?

Core Florida IT configura y mantiene servidores Linux para empresas en Miami-Dade y todo el sur de Florida, con soporte remoto en todo el país, incluyendo instalación y reparación de servidores y revisiones de ciberseguridad. Si no está seguro de qué protege hoy sus servidores, solicite una evaluación de TI gratuita y lo revisaremos con usted.

Fuentes

• Proyecto Fail2ban: jail.conf (configuración predeterminada y comentarios)
• Proyecto Fail2ban: filtro sshd
• Versiones de Fail2ban
• Página de manual fail2ban-regex(1)
• Notas de la versión de Debian 12: cambios en el sistema de registro
• Bug 2055114 de Ubuntu Launchpad: fail2ban en 24.04