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:
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):
sudo dnf install epel-release -y
sudo dnf install fail2ban -y Verifica que la instalación fue exitosa:
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:
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:
sudo nano /etc/fail2ban/jail.local Y dentro de la sección [sshd], ajusta o agrega:
[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 como10m,1ho1d; con-1el 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:
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:
sudo apt install python3-systemd -y Y después, en la configuración del jail, sustituye el logpath por el backend correcto:
[sshd]
enabled = true
backend = systemd Reinicia y confirma que el servicio quedó activo:
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:
sudo fail2ban-client status Para ver el detalle de bloqueos específicos de la jail SSH (IPs baneadas, intentos totales, etc.):
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:
sudo nano /etc/fail2ban/jail.local [DEFAULT]
action = %(action_mwl)s
sender = [email protected]
destemail = [email protected]
mta = sendmail -
action: define qué tan detallada es la notificación (action_mwlincluye 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:
[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:
sudo nano /etc/fail2ban/filter.d/mi_servicio.conf Y define una expresión regular que identifique los intentos fallidos en el log correspondiente:
[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:
# 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:
| Perfil | maxretry | findtime | bantime | Cuándo usarlo |
|---|---|---|---|---|
| Permisivo | 6 | 10m | 10m | Servidor con varios usuarios humanos entrando por contraseña |
| Equilibrado | 5 | 10m | 1h | Configuración por defecto recomendada para un VPS de producción |
| Estricto | 3 | 1h | 1d o permanente | Servidor 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.
Hosting con LiteSpeed, NVMe y soporte 24/7 desde $3/mes.