Fail2ban en Linux: proteger SSH y verificar bloqueos

Fail2ban observa eventos de servicios y puede bloquear temporalmente direcciones que cumplen un patrón de intentos fallidos. Ayuda a reducir ciertos abusos repetidos, pero no sustituye actualizaciones, claves SSH, permisos ni controles de acceso.

Esta práctica utiliza Ubuntu o Debian con SSH registrado en el journal de systemd. Si tu instalación escribe únicamente en archivos, necesitas otro backend y un logpath real. No combines ambos modelos sin revisar qué está leyendo cada jail.

Conserva una salida antes de tocar bloqueos

Mantén abierta una sesión administrativa y comprueba el acceso a la consola del proveedor. Si agregas una IP de confianza a ignoreip, utiliza una dirección que controles y verifica si cambia; no excluyas redes grandes solo por comodidad.

Confirma el puerto real y que existen eventos SSH:

sudo /usr/sbin/sshd -T | grep '^port '
sudo journalctl -u ssh --since '30 minutes ago'

El servicio puede llamarse sshd en otra distribución. Una consulta vacía no prueba que no haya intentos: también puede indicar que estás revisando la unidad equivocada.

Instala y crea una configuración pequeña

sudo apt update
sudo apt install fail2ban python3-systemd
sudo nano /etc/fail2ban/jail.d/sshd.local

Guarda este ejemplo para SSH en 22:

[sshd]
enabled = true
backend = systemd
port = 22
findtime = 10m
maxretry = 5
bantime = 10m
ignoreip = 127.0.0.1/8 ::1

Cambia port si corresponde y añade una excepción administrativa solo cuando esté justificada. El backend systemd usa el journal; no añadas un logpath de auth.log a esta configuración.

No copies todo jail.conf a un archivo local. Un ajuste pequeño permite entender qué has cambiado y reduce la posibilidad de conservar valores antiguos durante una actualización.

La acción de firewall se hereda de los paquetes y ajustes del sistema. Identifica cuál se utilizará y si es compatible con tu entorno; forzar iptables en todas las máquinas no resuelve esa comprobación.

Valida y revisa el jail

sudo fail2ban-client -t

Si la prueba no presenta errores, aplica:

sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo journalctl -u fail2ban --since '10 minutes ago'

La lista debe incluir sshd. Revisa fallos al abrir el journal, errores del filtro y problemas al ejecutar las acciones. Un jail con cero eventos puede estar funcionando sin intentos recientes o puede estar leyendo el origen incorrecto.

Comprueba detección y acción por separado

Para evaluar coincidencias del filtro con los registros disponibles:

sudo fail2ban-regex systemd-journal sshd

Revisa qué líneas coinciden y cuáles no. No necesitas generar una tormenta de intentos para comprobarlo. En un laboratorio puedes producir unos pocos fallos controlados desde otro cliente, sin utilizar tu única vía administrativa.

Una segunda prueba verifica la acción de bloqueo. La dirección siguiente pertenece a un rango de documentación; no es tu IP ni demuestra una conexión real:

sudo fail2ban-client set sshd banip 203.0.113.77
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.77

Comprueba además las reglas del firewall que usa la acción. Después de retirar el ban, verifica que desapareció. Esto prueba el recorrido administrativo de la acción; la detección automática y el bloqueo de un cliente real requieren la prueba separada de laboratorio.

Ajusta después de observar

Un umbral bajo puede bloquear usuarios que escriben mal una contraseña, especialmente detrás de una salida compartida. Un periodo muy largo aumenta el costo de un falso positivo. Decide valores a partir del servicio y revisa los registros.

Para Nginx o Apache, habilita únicamente jails cuyos filtros y rutas correspondan a tu configuración. Varias peticiones a wp-login.php no demuestran por sí mismas una autenticación fallida; un filtro demasiado amplio puede bloquear tráfico legítimo.

Si existe un proxy, CDN o contenedor, identifica qué dirección aparece en el registro y qué tráfico alcanza la cadena de firewall. No confíes en cabeceras de IP enviadas por cualquier cliente.

En un bloqueo accidental, entra por la vía de recuperación, revisa el jail y retira el ban de la IP afectada. Corrige la causa en lugar de vaciar todas las reglas del firewall.

Preguntas frecuentes

¿Fail2ban impide todos los ataques por fuerza bruta?

No. Depende de eventos reconocibles y de acciones que alcancen el tráfico correspondiente. Los ataques distribuidos y otros métodos requieren controles adicionales.

¿Por qué no existe /var/log/auth.log en mi servidor?

Algunas instalaciones usan el journal u otra configuración de registros. Identifica el origen disponible y selecciona un backend compatible.

¿Puedo bloquear mi propia IP?

Sí. Una sesión abierta puede seguir funcionando o cortarse según la acción y las reglas. Conserva una consola de recuperación y prueba con otra dirección controlada.

En pocas palabras

Fail2ban conecta detección en registros con acciones de bloqueo. Debes comprobar ambas partes y conservar una vía de recuperación; activar el servicio no demuestra que un jail esté leyendo los eventos correctos.

Conclusión

Empieza con un solo jail, umbrales moderados y una prueba reversible. Añade servicios cuando puedas identificar sus registros, comprobar el filtro y validar el alcance de la acción de red.

Para continuar, revisa Cómo instalar Ubuntu desde una USB: paso a paso y Cómo instalar Docker en Ubuntu 24.04: guía práctica paso a paso.

Fuentes y documentación

Documentación de github.com.

Documentación de raw.githubusercontent.com.

Documentación de manpages.debian.org.