Cuando analicé los logs de una organización sanitaria pública con 2.000 endpoints, conté más de 15.000 intentos de acceso SSH fallidos en una sola noche. Los bots escanean subredes IP enteras, prueban diccionarios de contraseñas y martillean el puerto 22 hasta encontrar una credencial débil. Si no tienes un sistema automatizado que bloquee estos ataques brute force, solo confías en que nadie adivine la contraseña correcta. Una confianza que nunca ha protegido ningún servidor. Fail2ban es la herramienta que transforma tus logs de autenticación en un firewall reactivo. Lee los intentos fallidos, identifica las IP maliciosas y actualiza las reglas de iptables o nftables para dropear el tráfico en tiempo real. En esta guía configuraremos Fail2ban en Linux para proteger SSH y los servicios web, desde los requisitos previos hasta las pruebas de funcionamiento, asegurando el cumplimiento de estándares como NIS2 art.21.
Requisitos Previos para Fail2ban en Linux
Asegúrate de tener acceso root o un usuario con privilegios sudo. Esta guía está probada en Ubuntu 22.04/24.04 y CentOS Stream 9, pero la lógica es idéntica en cualquier distribución Linux moderna. Necesitas un firewall activo, como UFW o firewalld, y un servidor SSH expuesto. No apliques configuraciones restrictivas en un servidor de producción sin probarlas antes en un entorno aislado. Un ban accidental de tu propia IP te dejaría fuera del sistema sin opciones.
Qué es Fail2ban y por qué todo servidor Linux debe tenerlo
Fail2ban es un daemon escrito en Python que monitoriza archivos de log buscando patrones específicos. Cuando detecta un número anómalo de errores de autenticación desde la misma IP, interviene modificando las reglas del firewall para bloquear ese nodo. No sustituye la autenticación por clave pública ni una VPN, pero constituye la primera capa de defensa contra el ruido de fondo de internet. Reduce la carga del servidor, disminuye el ruido en los logs y evita que los bots consuman recursos. Para cumplir con estándares como NIS2 art.21, ISO 27001:2022 y NIST CSF 2.0, proteger el acceso remoto es obligatorio. Fail2ban te permite configurar una respuesta automática y proporcional contra los ataques.
Instalación y Configuración de jail.local
Instalación en Ubuntu/Debian y CentOS/RHEL
La instalación requiere un solo comando. En Ubuntu y Debian, el paquete está en los repositorios oficiales.
sudo apt install fail2banEn CentOS Stream, RHEL y derivadas, se encuentra en EPEL.
sudo dnf install epel-release
sudo dnf install fail2banUna vez instalado, habilita el servicio en el arranque e inícialo.
sudo systemctl enable fail2ban
sudo systemctl start fail2banVerifica el estado. El daemon debe estar activo y sin errores.
sudo systemctl status fail2banConfiguración jail.local: los parámetros que importan
El paquete proporciona un archivo de configuración predeterminado, jail.conf. Nunca debes modificarlo. Las actualizaciones del sistema lo sobrescribirán. La práctica correcta consiste en copiarlo a jail.local. Fail2ban lee primero .local, y tus parámetros tendrán precedencia.
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localAbre jail.local con tu editor. Los parámetros globales que debes calibrar se encuentran en la sección [DEFAULT].
bantime: la duración del ban. El valor predeterminado es 10 minutos, demasiado bajo. Establece 3600 segundos (1 hora) o más para ataques sostenidos.findtime: la ventana temporal en la que Fail2ban cuenta los intentos. 600 segundos (10 minutos) es un buen compromiso.maxretry: el número de fallos antes del ban. Establece 3 para SSH, 5 para servicios web.
Estos valores definen la agresividad de tu defensa. Un bantime demasiado corto permite a los bots reintentar. Un maxretry demasiado alto les da demasiados intentos.
Protección de SSH y Servicios Web en Producción
Ajustes recomendados para SSH
Ahora activamos la jail específica para SSH. Busca la sección [sshd] en el archivo jail.local y configúrala así:
[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 3600
findtime = 600Con esta configuración, tras 3 intentos de login fallidos en 10 minutos, la IP de origen recibe un ban de una hora. Si tu puerto SSH no es el estándar 22, cambia el parámetro port con el número correcto. Tras guardar el archivo, reinicia el servicio para aplicar las reglas.
sudo systemctl restart fail2banLee también: SSH Hardening Linux: Complete Guide 2026 (10 Critical Settings)
Proteger Nginx y Apache
Fail2ban no protege solo el SSH. Los servidores web son objetivos constantes de ataques brute force en áreas de login o escaneos de vulnerabilidades. Debes crear jails personalizadas para los logs de Nginx o Apache. Para Nginx, habilita la jail [nginx-http-auth] para proteger la autenticación Basic Auth. Para Apache, usa [apache-auth]. Ambas leen los logs de errores de autenticación y aplican el mismo principio: demasiados errores idénticos provocan el ban de la IP. Añade los filtros en jail.local especificando la ruta correcta del log en el parámetro logpath. Por ejemplo, para Nginx en Ubuntu, la ruta suele ser /var/log/nginx/error.log.
Monitoreo y Pruebas de Funcionamiento
Monitorear los baneos en tiempo real
Para entender si Fail2ban está funcionando, comprueba el estado de las jails activas. El comando muestra las IP baneadas y el conteo de intentos.
sudo fail2ban-client status sshdLa salida devuelve el número de IP baneadas y la lista de direcciones. Si ves la lista llenarse, significa que el daemon está interceptando el tráfico malicioso. Revisa los logs del sistema para obtener detalles sobre cada acción emprendida.
sudo tail -f /var/log/fail2ban.logDesbloquear una IP baneada por error
Tarde o temprano banearás a un usuario legítimo. Un compañero que olvida su contraseña, una automatización corporativa con credenciales caducadas. No hace falta reiniciar el servicio. Usa el cliente para eliminar el ban en tiempo real.
sudo fail2ban-client set sshd unbanip 1.2.3.4Sustituye 1.2.3.4 por la dirección IP real. La acción es inmediata. Si no recuerdas la IP, usa sudo fail2ban-client status sshd para leer la lista de baneos activos.
Probar que Fail2ban está funcionando
No confíes en la suerte. Prueba la configuración. Desde una máquina externa, intenta un login SSH con contraseña errónea 3 veces seguidas. En el cuarto intento, la conexión debería rechazarse (Connection refused o Timeout). Compruébalo en el servidor.
sudo fail2ban-client status sshdLa IP de prueba debe aparecer en la lista de baneados. Si no aparece, verifica que el parámetro logpath en la jail apunte al archivo de log correcto de tu sistema (por ejemplo, /var/log/auth.log en Ubuntu, /var/log/secure en RHEL). Una ruta incorrecta es la causa más frecuente de mal funcionamiento.
Errores Comunes y Resolución de Problemas
El problema más recurrente es el archivo de log equivocado. Si Fail2ban no detecta los ataques, comprueba la ruta en logpath. Otro error frecuente es la ausencia del backend de firewall. Fail2ban se apoya en iptables, nftables o firewalld. Si usas UFW en Ubuntu, asegúrate de que la jail tenga banaction = ufw. Sin esta directiva, Fail2ban escribe reglas en iptables que UFW ignora, creando conflictos. Finalmente, las expresiones regulares en los filtros predeterminados podrían no alinearse con el formato de log de tu versión específica de un servicio. Revisa los filtros en /etc/fail2ban/filter.d/ y adapta el regex si es necesario. Puedes validar tus expresiones regulares con el comando fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf antes de recargar la configuración.
Conclusiones con Puntos Clave Operativos
Fail2ban transforma los logs pasivos en una defensa activa. Lo instalé como primer paso en una PA con 2.000 endpoints para detener el ruido de fondo de los bots, y el impacto en los logs fue inmediato. Recuerda tres reglas: copia siempre jail.conf a jail.local, reduce el maxretry y aumenta el bantime para SSH, y alinea siempre el banaction con tu firewall de sistema. Para profundizar en las directivas y filtros, consulta la documentación oficial en fail2ban.readthedocs.io. No dejes tus servidores expuestos a la fuerza bruta.
