Saltar al contenido
Security 2024-12-28 9 min de lectura

Fail2Ban: cómo bloquear ataques de fuerza bruta en SSH

Cualquier servidor conectado a internet recibe, tarde o temprano, intentos automatizados de acceso por fuerza bruta: bots que prueban miles de combinaciones de usuario y contraseña contra SSH, paneles web o servicios FTP. Fail2Ban es una herramienta de código abierto que monitorea los registros del sistema en tiempo real y bloquea automáticamente las IPs que muestran ese patrón de comportamiento, sin que tengas que revisar logs manualmente. En esta guía instalamos y configuramos Fail2Ban desde cero, incluyendo notificaciones por correo y filtros personalizados.

Fail2Ban: cómo bloquear ataques de fuerza bruta en SSH
#Security#Linux#Fail2Ban#SSH
J John Coveña
John Coveña
Fundador de Terranode · Infraestructura y redes

Qué necesitas antes de empezar

  • Un servidor Linux funcional (Ubuntu, Debian, CentOS u otra distribución compatible).
  • Acceso SSH con permisos de sudo.
  • Conocimientos básicos de edición de archivos por terminal.

Ventajas de usar Fail2Ban

  • Automatización de bloqueos: no necesitas revisar manualmente los logs en busca de comportamiento sospechoso.
  • Configuración flexible: puedes definir reglas distintas para cada servicio según su nivel de exposición.
  • Protección multiservicio: funciona con SSH, servidores web (Apache/Nginx), FTP y muchos otros de forma nativa.
  • Mejora del rendimiento: al bloquear IPs maliciosas rápidamente, reduces la carga que generan sus intentos repetidos sobre el servidor.

Paso 1: Instalar Fail2Ban

En distribuciones basadas en Debian/Ubuntu:

bash
sudo apt update
sudo apt install fail2ban python3-systemd -y

El paquete python3-systemd es necesario para leer los registros del journal de systemd, algo obligatorio en Debian 12 y posteriores, como se explica más abajo.

En distribuciones basadas en Red Hat (AlmaLinux, Rocky Linux):

bash
sudo dnf install epel-release -y
sudo dnf install fail2ban -y

Verifica que la instalación fue exitosa:

bash
fail2ban-client --version

Paso 2: Crear el archivo de configuración local

Fail2Ban recomienda nunca editar directamente jail.conf, ya que se sobrescribe con cada actualización del paquete. En su lugar, crea un archivo local que sí persiste:

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

Una alternativa más limpia, y la que usan la mayoría de los administradores hoy, es dejar jail.conf intacto y escribir solo lo que cambias en un archivo pequeño dentro de /etc/fail2ban/jail.d/. Así las actualizaciones nunca entran en conflicto con tu configuración.

Paso 3: Configurar protección básica para SSH

Edita el archivo local:

bash
sudo nano /etc/fail2ban/jail.local

Y dentro de la sección [sshd], ajusta o agrega:

ini
[sshd]
enabled  = true
port     = ssh
filter   = sshd
backend  = systemd
maxretry = 5
findtime = 10m
bantime  = 1h
ignoreip = 127.0.0.1/8 ::1 TU.IP.FIJA.AQUI

Cada parámetro cumple una función específica:

  • maxretry: número de intentos fallidos permitidos antes de bloquear la IP.
  • findtime: ventana de tiempo en la que se cuentan esos intentos fallidos.
  • bantime: cuánto permanece bloqueada la IP. Acepta valores como 10m, 1h o 1d; con -1 el bloqueo es permanente.
  • ignoreip: lista blanca de direcciones que Fail2Ban nunca bloqueará. Añade aquí tu IP fija si la tienes: es el seguro más barato contra quedarte fuera de tu propio servidor.

Reinicia el servicio para aplicar los cambios:

bash
sudo systemctl restart fail2ban

El error que impide arrancar Fail2Ban en Debian 12 y Ubuntu 24.04

Si Fail2Ban no arranca después de instalarlo y el mensaje del servicio menciona que no encuentra el archivo de log del jail sshd, el problema no es tuyo: desde Debian 12, el sistema ya no escribe /var/log/auth.log porque el registro se centralizó en el journal de systemd. Las guías escritas antes de ese cambio indican logpath = /var/log/auth.log, y ese archivo simplemente no existe, así que el servicio se niega a iniciar.

La solución son dos líneas. Primero, asegúrate de tener instalado el conector de Python con systemd:

bash
sudo apt install python3-systemd -y

Y después, en la configuración del jail, sustituye el logpath por el backend correcto:

ini
[sshd]
enabled = true
backend = systemd

Reinicia y confirma que el servicio quedó activo:

bash
sudo systemctl restart fail2ban
sudo systemctl status fail2ban

Si tu servidor todavía instala rsyslog y el archivo /var/log/auth.log sí existe —el caso de muchas imágenes de Ubuntu—, la configuración con logpath sigue funcionando. Comprobarlo es inmediato: ls -l /var/log/auth.log. Si el archivo no aparece, usa backend = systemd.

Verificar el estado y monitorear bloqueos

Para ver el estado general de Fail2Ban y qué jails están activas:

bash
sudo fail2ban-client status

Para ver el detalle de bloqueos específicos de la jail SSH (IPs baneadas, intentos totales, etc.):

bash
sudo fail2ban-client status sshd

Habilitar notificaciones por correo

Para recibir un aviso cada vez que Fail2Ban bloquee una IP, edita nuevamente el archivo local:

bash
sudo nano /etc/fail2ban/jail.local
ini
[DEFAULT]
action = %(action_mwl)s
sender = [email protected]
destemail = [email protected]
mta = sendmail
  • action: define qué tan detallada es la notificación (action_mwl incluye además un extracto del log relevante).
  • destemail: la dirección de correo donde quieres recibir las alertas.

Recuerda que necesitas un agente de correo (como sendmail o postfix) correctamente configurado en el servidor para que estas notificaciones lleguen.

Proteger otros servicios además de SSH

Fail2Ban incluye filtros predefinidos para muchos servicios comunes. Por ejemplo, para proteger la autenticación de Apache contra fuerza bruta:

ini
[apache-auth]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache2/error.log
maxretry = 3

El mismo patrón aplica para Nginx, vsftpd, Postfix y decenas de servicios más, cada uno con su propia sección en jail.local.

Crear filtros personalizados

Si necesitas proteger un servicio que no tiene un filtro predefinido, puedes crear el tuyo. Primero, crea el archivo de filtro:

bash
sudo nano /etc/fail2ban/filter.d/mi_servicio.conf

Y define una expresión regular que identifique los intentos fallidos en el log correspondiente:

ini
[Definition]
failregex = <HOST> - - .* 401

Finalmente, configura la jail correspondiente en jail.local apuntando a este nuevo filtro y al archivo de log de tu servicio.

Desbloquear una IP manualmente

Si una IP legítima queda bloqueada por error —lo más común: tu propia IP tras equivocarte varias veces con la contraseña— puedes desbloquearla al instante:

bash
# Desbloquear en todos los jails
sudo fail2ban-client unban 203.0.113.25

# O solo en un jail específico
sudo fail2ban-client set sshd unbanip 203.0.113.25

Para que no vuelva a ocurrir, añade esa dirección a ignoreip en jail.local. Y si administras desde una IP dinámica, considera dejar abierto un segundo camino de acceso —la consola web del proveedor de VPS— antes de endurecer nada: es la diferencia entre un susto de dos minutos y una tarde perdida.

Qué valores usar según el tipo de servidor

No existe una configuración correcta única: el equilibrio depende de cuántos usuarios legítimos se conectan y de cuánto te cuesta un bloqueo equivocado. Estas tres combinaciones cubren la mayoría de los casos:

PerfilmaxretryfindtimebantimeCuándo usarlo
Permisivo610m10mServidor con varios usuarios humanos entrando por contraseña
Equilibrado510m1hConfiguración por defecto recomendada para un VPS de producción
Estricto31h1d o permanenteServidor administrado solo por ti, con acceso por llave SSH

En el perfil estricto conviene además activar bantime.increment = true en la sección [DEFAULT]: con esa opción, cada reincidencia de la misma IP multiplica la duración del bloqueo, de forma que los atacantes persistentes acaban fuera durante días sin que tengas que intervenir.

Fail2Ban es una de esas herramientas que, una vez configuradas, siguen protegiendo tu servidor de forma silenciosa e ininterrumpida. Con una configuración básica para SSH ya reduces drásticamente el ruido de ataques automatizados; añadiendo protección para tus otros servicios expuestos y notificaciones por correo, tienes una defensa activa y con visibilidad real de lo que ocurre en tu infraestructura.

Un último recordatorio de prioridades: Fail2Ban es la segunda línea, no la primera. Antes que él van la autenticación por llave SSH con contraseñas deshabilitadas y un firewall que solo exponga los puertos necesarios, dos temas que cubrimos en la guía de seguridad para servidores Linux y en la de configuración de firewalls con UFW y Firewalld. Si administras un VPS expuesto a internet, esas tres capas juntas eliminan prácticamente todo el riesgo de acceso por fuerza bruta. Si tienes dudas durante la implementación, nuestro equipo de soporte técnico está disponible 24/7 para ayudarte.

¿Listo para llevar tu sitio al siguiente nivel?

Hosting con LiteSpeed, NVMe y soporte 24/7 desde $3/mes.

Ver planes de hosting

Preguntas frecuentes