fail2ban: cómo bloquear fuerza bruta en Linux paso a paso

Abre el /var/log/auth.log de cualquier servidor SSH expuesto a internet y vas a ver cientos — a veces miles — de intentos de inicio de sesión por día. Los bots rastrean todo el IPv4 en horas, probando combinaciones de usuario y contraseña en cada puerto 22 que encuentran. fail2ban es la respuesta estándar para esto: monitorea los logs en tiempo real y banea automáticamente cualquier IP que supere el límite de intentos que definas. Simple, ligero y eficiente.

Qué hace fail2ban (y qué no hace)

fail2ban actúa en tres etapas: lee los logs de un servicio, aplica un filtro (expresión regular) para detectar intentos de autenticación fallidos y, cuando la IP supera el maxretry en el periodo findtime, activa una action — por defecto, una regla de bloqueo vía iptables o nftables con duración configurable.

Lo que no hace: no sustituye un hardening adecuado de SSH (deshabilitar el login de root, usar claves en vez de contraseña). Ambos trabajan en capas complementarias — fail2ban reduce el ruido de fuerza bruta, pero un servidor que todavía acepta contraseñas débiles sigue siendo vulnerable si el ataque viene de IPs distintas (distribuido, más difícil de banear).

Instalación en Ubuntu y Debian

sudo apt update && sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

En Ubuntu 22.04+ y Debian 12, el paquete ya viene con soporte para nftables/iptables y el servicio arranca automáticamente tras la instalación.

Creando el jail.local (nunca edites jail.conf)

El archivo /etc/fail2ban/jail.conf es el de referencia — se sobrescribe en cada actualización del paquete. Toda configuración personalizada va en jail.local, que tiene prioridad:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edita /etc/fail2ban/jail.local y ajusta la sección [DEFAULT]:

[DEFAULT]
bantime  = 1h
findtime  = 10m
maxretry = 5
backend = systemd

Significado de cada parámetro:

• bantime: cuánto tiempo queda baneada la IP. Acepta sufijos: 10m, 1h, 1d, 1w.
• findtime: ventana de observación. Si la IP falla maxretry veces dentro de ese periodo, recibe el baneo.
• maxretry: número de fallos tolerados antes del baneo.
• backend: cómo lee fail2ban los logs. systemd usa journald (por defecto en las distros modernas); usa auto si necesitas cubrir ambos.

Activando la jail de SSH

Todavía en jail.local, busca la sección [sshd] y configura:

[sshd]
enabled  = true
port     = ssh
maxretry = 3
bantime  = 2h
findtime = 5m

Con estos valores, tres intentos fallidos en cinco minutos resultan en dos horas de baneo. Para un servidor de producción, valores más agresivos tienen sentido: maxretry = 2 y bantime = 24h.

Después de editar, recarga:

sudo systemctl reload fail2ban

Comandos esenciales de gestión

¿Cómo verifico que fail2ban está funcionando?

Ejecuta sudo fail2ban-client status — lista las jails activas. Si aparece sshd, está monitoreando. Para ver el detalle de cuántas IPs fueron baneadas:

sudo fail2ban-client status sshd

Salida típica:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     317
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 4
   |- Total banned:     51
   `- Banned IP list:   203.0.113.42 198.51.100.7 ...

Para ver los logs en tiempo real:

sudo journalctl -u fail2ban -f

Para desbanear una IP manualmente (útil cuando tú mismo te equivocas con la contraseña y te bloqueas):

sudo fail2ban-client set sshd unbanip 203.0.113.42

Baneos crecientes para reincidentes

Por defecto, la IP queda baneada durante bantime y, cuando expira, vuelve a cero. Activar los baneos incrementales hace que el tiempo se duplique en cada reincidencia — las IPs persistentes terminan baneadas durante semanas:

[DEFAULT]
bantime.increment = true
bantime.multiplier = 2
bantime.maxtime = 1w

Con esto, el primer baneo dura el bantime configurado; el segundo, el doble; el tercero, cuatro veces más — hasta el tope de una semana. Este recurso está disponible desde fail2ban 0.11 en adelante, que es el predeterminado en Ubuntu 22.04+ y Debian 12.

Protegiendo otros servicios

fail2ban tiene jails listas para Nginx, Apache, Postfix, Dovecot y otros. Basta con habilitarlas en la sección correspondiente de jail.local. Ejemplo para Nginx (intentos de autenticación básica):

[nginx-http-auth]
enabled = true
port    = http,https
maxretry = 4
bantime  = 1h

La misma lógica de protección contra fuerza bruta que se aplica al RDP en Windows se aplica aquí: limitar intentos con bloqueo automático es la primera capa de defensa para cualquier servicio expuesto a la red.

Lista blanca — no se banea

Agrega tu IP (o rango) a la lista blanca para que fail2ban nunca la bloquee, aunque te equivoques con la contraseña varias veces:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 TU.IP.AQUI

Para varias IPs, sepáralas con espacio. Si accedes al servidor siempre desde la misma IP estática, esta línea te evita el dolor de cabeza de quedarte fuera.

Conclusión

Instalar fail2ban lleva menos de dos minutos y cubre automáticamente la capa más básica de fuerza bruta. Combinado con autenticación por clave SSH y deshabilitación del login de root, cierras la mayoría de los vectores de ataque que explotan los bots en servidores expuestos. Para quien administra VPS o servidores domésticos, este par de medidas equivale a trancar la puerta y cambiar la cerradura — no es invulnerabilidad, pero elimina el oportunismo. Si quieres ir más allá en el hardening de infraestructura, la guía sobre OPSEC y privacidad digital cubre la capa de comportamiento y exposición de información, que es donde empiezan muchos ataques reales.