instalar fail2ban en ubuntu 24.04

Qué hace realmente Fail2ban

Fail2ban es un demonio que lee logs. Monitorea los mensajes de autenticación de SSH y, tras varios fallos desde una misma dirección en un intervalo corto, ejecuta un comando de firewall para bloquear esa dirección temporalmente. Esa es su función principal. Consiste en unas treinta líneas de configuración en un solo archivo. En Ubuntu 24.04, la instalación es un único comando apt que proporciona protección antes de realizar cualquier edición.

Es importante entender qué es y qué no es. Fail2ban no autentica usuarios, no cifra datos y no detiene un único intento de inicio de sesión decidido; solo detiene los intentos repetidos desde la misma fuente. Es un filtro de ruido y un limitador de tasa, no una cerradura. Su función es evitar que el escaneo constante del puerto 22 consuma CPU, ancho de banda y espacio en logs, y ralentizar a cualquier atacante que deba operar desde una dirección a la vez.

Lo que Fail2ban no reemplaza

Fail2ban es la tercera capa, no la primera. Si su servidor aún acepta contraseñas por SSH, una botnet distribuida en miles de direcciones puede continuar los intentos de adivinación. Esto ocurre porque cada dirección se mantiene por debajo del umbral de baneo y nunca lo activa. La defensa real contra esto es la autenticación mediante llaves, la cual hace imposible el ataque de fuerza bruta sin importar el número de intentos. Fail2ban junto con la autenticación por llaves ofrece dos ventajas: elimina el ruido de fuerza bruta de sus logs y expulsa a los scanners rápidamente para que dejen de saturar el puerto. Utilícelo como defensa en profundidad. Fail2ban opera después de la autenticación por llaves y después de un firewall, nunca antes que ellos.

Requisitos previos y la realidad de Ubuntu 24.04

Necesitas un VPS con Ubuntu 24.04 con acceso root o sudo, y SSH funcionando — idealmente mediante autenticación por clave. Fail2ban consume pocos recursos: solo unos pocos megabytes de RAM y no requiere ajuste de límites.

A continuación, la parte que todas las guías antiguas interpretan mal. Durante años, el consejo estándar era "instala Fail2ban y luego añade backend = systemd, porque Ubuntu dejó de escribir /var/log/auth.log". Ese consejo describe un cambio real — las imágenes modernas de servidores y la nube se distribuyen sin rsyslog, por lo que SSH solo registra en el journal de systemd y ese archivo de texto ya no existe — pero en Ubuntu 24.04 el paquete Fail2ban ya contempla este cambio. El paquete incluye /etc/fail2ban/jail.d/defaults-debian.conf, y ese archivo, no los valores predeterminados originales, es lo que ejecuta tu servidor:

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

Lee esto con atención, ya que resuelve dos dudas antes de realizar cualquier acción. backend = systemd significa que el jail de SSH lee el journal, por lo que la ausencia de auth.log no importa. banaction = nftables significa que los bloqueos se aplican mediante nftables, que es el firewall que Ubuntu 24.04 utiliza realmente en lugar del legacy iptables. Y [sshd] enabled = true significa que el jail está activo desde el primer arranque. Conclusión: una instalación estándar de apt install fail2ban en Ubuntu 24.04 bloquea ataques de fuerza bruta en SSH de forma nativa. La mayor parte de tu trabajo consiste en confirmar esto, ajustar la política y asegurar que no perderás el acceso al servidor.

La antigua trampa de auth.log sigue afectando en tres situaciones, y es importante identificarlas: instalaste Fail2ban con pip en lugar de apt, por lo que no existe defaults-debian.conf; estás dentro de un contenedor sin privilegios que no tiene un journal de systemd para leer; o seguiste un tutorial antiguo y pegaste backend = auto en tu propio jail.local, sobrescribiendo el valor predeterminado que funciona. La sección de modos de fallo muestra exactamente cómo se presenta cada uno.

Paso 1: Instalar y confirmar que ya está bloqueando

sudo apt update
sudo apt install -y fail2ban

Ubuntu 24.04 incluye Fail2ban 1.0.2, y el paquete instala python3-systemd como una dependencia obligatoria, por lo que el backend del journal tiene todo lo necesario. El servicio se habilita y se inicia automáticamente:

sudo systemctl status fail2ban

Usted necesita active (running). Luego, revise la cárcel que ya está funcionando:

sudo fail2ban-client status sshd

En un VPS público con apenas unos minutos de actividad, es común ver ya fallos contabilizados y direcciones bloqueadas; internet escanea el puerto 22 continuamente. Eso demuestra que la configuración por defecto funciona. A partir de aquí, usted la perfeccionará en lugar de crearla desde cero.

Paso 2: Editar jail.local, nunca jail.conf

Fail2ban mantiene sus valores predeterminados en /etc/fail2ban/jail.conf. No edite ese archivo. Cualquier apt upgrade del paquete puede reemplazarlo y sus cambios se perderán sin previo aviso. Fail2ban lee los archivos en un orden fijo — jail.conf primero, luego todo lo contenido en jail.d/, y después jail.local — y el último valor es el que se aplica. El archivo .local es suyo y las actualizaciones del paquete nunca lo modifican. La misma regla se aplica a los filtros, donde un archivo *.local sobrescribe el filter.d/*.conf incluido.

Por lo tanto, escriba un jail.local pequeño que sobrescriba solo los ajustes específicos que necesite, y deje jail.conf y el jail.d/defaults-debian.conf del paquete intactos para usar como referencia.

Paso 3: Escribir /etc/fail2ban/jail.local

sudo nano /etc/fail2ban/jail.local

Pegue este contenido, cambiando la dirección en la línea ignoreip por su propia IP pública:

[DEFAULT]
# Ubuntu 24.04 already sets these two in jail.d/defaults-debian.conf.
# Pinning them here documents the dependency and survives if that
# file is ever removed or changed by an upgrade.
backend   = systemd
banaction = nftables

# Ban for one hour ...
bantime  = 1h
# ... if an address fails ...
maxretry = 5
# ... 5 times within 10 minutes.
findtime = 10m

# Never ban these. PUT YOUR OWN IP HERE.
ignoreip = 127.0.0.1/8 ::1 10.0.0.24

# Longer bans for repeat offenders: 1h, 2h, 4h ... up to a week.
bantime.increment = true
bantime.maxtime   = 1w

[sshd]
enabled = true

Cada línea tiene una función específica:

• bantime, findtime, maxretry definen la política. El valor predeterminado de bantime es de solo diez minutos; una hora es un límite más razonable. Cinco fallos desde una misma dirección en diez minutos activan el bloqueo. Los usuarios reales cometen errores de contraseña una o dos veces; cinco fallos en diez minutos indican un script.
• ignoreip es su medida de seguridad. Coloque aquí la dirección pública desde la que se conecta para evitar que Fail2ban le bloquee el acceso a su propio servidor. Si tiene una conexión doméstica con IP dinámica, prefiera el método VPN mencionado al final, pero no omita esta línea.
• bantime.increment = true aumenta la duración de cada bloqueo sucesivo —una hora, luego dos, luego cuatro— hasta bantime.maxtime. Las direcciones recurrentes reciben bloqueos progresivamente más largos.

Obtenga la dirección para la lista blanca desde la máquina desde la que realiza el SSH, no desde el servidor:

curl -s ifconfig.me

Puede generar un jail.local ajustado a sus puertos y política de bloqueo aquí, y luego pegarlo en el archivo:

Paso 4: Reiniciar y verificar la lectura del journal

sudo fail2ban-client -t
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

El -t realiza primero una prueba de configuración. Un error tipográfico en jail.local causará un error evidente aquí en lugar de dejar el servicio inoperativo. El estado saludable de la jail es el siguiente:

Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     14
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   10.0.0.66

El número que confirma que Fail2ban está leyendo los inicios de sesión es Total failed. Si es superior a cero, o aumenta al fallar deliberadamente un inicio de sesión desde otra máquina, el journal se está leyendo correctamente y el proceso ha terminado. Si permanece en 0 sin importar cuántas veces falle —y tiene la certeza de que no está realizando las pruebas desde la dirección en ignoreip— consulte los modos de error a continuación.

Observe que la línea Journal matches todavía menciona sshd.service. En Ubuntu, la unidad de SSH es en realidad ssh.service, pero el filtro incluido también coincide con _COMM=sshd, y OpenSSH en 24.04 registra sus fallos desde un proceso llamado sshd, por lo que la coincidencia funciona. Ese detalle solo es relevante si utiliza una versión reciente de OpenSSH (9.8 o posterior, donde el worker por conexión es sshd-session); los modos de error cubren ese caso.

Paso 5: Observar un baneo real o forzar uno para realizar pruebas

Los bloqueos reales ocurren de forma automática en pocos minutos en cualquier VPS público. Para observar uno, use tail en el log:

sudo tail -f /var/log/fail2ban.log

Un baneo tiene este aspecto:

2026-07-15 10:31:40,502 fail2ban.filter  [812]: INFO    [sshd] Found 10.0.0.66 - 2026-07-15 10:31:40
2026-07-15 10:31:44,118 fail2ban.actions [812]: NOTICE  [sshd] Ban 10.0.0.66

Para probar el funcionamiento completo sin esperar, banee manualmente una dirección de documentación; nunca use su propia dirección:

sudo fail2ban-client set sshd banip 10.0.0.66

El sistema imprimirá 1 y la dirección aparecerá bajo Banned IP list en fail2ban-client status sshd. Ahora confirme que el bloqueo existe realmente en el firewall. En Ubuntu 24.04 se utiliza nftables en lugar de iptables:

sudo nft list table inet f2b-table

Verá un set llamado addr-set-sshd que contiene 10.0.0.66, y una cadena f2b-chain que rechaza cualquier origen en dicho set. Si fail2ban-client indica que una dirección está baneada pero no aparece nada en nft list, la acción de baneo no coincide con su firewall; consulte la nota sobre nftables/iptables en los modos de error.

Paso 6: Desbloquearse a sí mismo y recuperar el acceso si queda bloqueado

Si ha bloqueado una dirección que no debía —su propia dirección—, elimínela:

sudo fail2ban-client set sshd unbanip 10.0.0.66

Devuelve 1 si la operación tiene éxito. Para limpiar todos los bloqueos de todas las jails:

sudo fail2ban-client unban --all

No confíe en una sesión de SSH ya abierta para evitar el bloqueo: el ban de nftables rechaza cada paquete de la dirección bloqueada hacia el puerto 22 —incluyendo las conexiones establecidas—, por lo que una sesión existente se congela en el momento en que se aplica el ban. Si se bloquea a sí mismo y no tiene una entrada ignoreip, perderá el acceso hasta que el bloqueo expire; recupere el acceso mediante la consola web de su proveedor (VNC o serial), que no utiliza SSH, y espere a que expire bantime o ejecute el comando de desbloqueo desde allí.

Paso 7: Hacer que los bloqueos sean persistentes y escalen

Fail2ban guarda los bloqueos activos en una base de datos SQLite pequeña en /var/lib/fail2ban/fail2ban.sqlite3 para que sobrevivan a un reinicio del servicio o del sistema; así no se pierden. Las líneas bantime.increment que ya añadió convierten cada infracción repetida en un problema creciente para el infractor, duplicando el tiempo aproximadamente desde una hora hasta una semana.

Para aplicar una política de "tres strikes" a nivel de sistema, Fail2ban incluye una jail recidive que supervisa su propio /var/log/fail2ban.log y aplica bloqueos largos a cualquier dirección bloqueada repetidamente en todas las jails. Debido a que su [DEFAULT] ahora utiliza el backend de systemd, asigne esta jail de nuevo al archivo de log que está diseñada para leer:

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

El uso de backend = auto con el parámetro logpath explícito mantiene a recidive leyendo el fail2ban.log plano, que es donde aparecen realmente las líneas Ban que contabiliza; la configuración predeterminada de systemd que estableció globalmente lo dirigiría al journal, donde estas no aparecen.

Paso 8: Combínelo con SSH basado solo en llaves, o mejor aún, con una VPN

Fail2ban es efectivo únicamente si se utiliza la autenticación por llaves. En un archivo de configuración en /etc/ssh/sshd_config.d/ —por ejemplo, /etc/ssh/sshd_config.d/00-hardening.conf— establezca:

PasswordAuthentication no
KbdInteractiveAuthentication no

Luego ejecute sudo systemctl restart ssh. Al desactivar las contraseñas, los ataques de fuerza bruta fallarán por completo; en este escenario, Fail2ban sirve para reducir el ruido en los logs y bloquear los escaneos rápidamente. Una opción aún más segura es mantener SSH fuera de la internet pública: coloque SSH detrás de una VPN WireGuard propia y cierre el puerto 22 en el firewall para que solo responda a través del túnel. Nadie puede realizar ataques de fuerza bruta en un puerto al que no tiene acceso, y Fail2ban actúa como una medida de respaldo en lugar de una primera línea de defensa.

Fail2ban no es solo para SSH. Cualquier servicio que registre intentos de inicio de sesión fallidos puede tener una cárcel (jail): un servidor de correo, un sitio nginx o un gestor de contraseñas Vaultwarden propio cuyo acceso web no se desee dejar expuesto a ataques de credential stuffing. Una vez que una aplicación web esté detrás de un sitio nginx con un certificado Let's Encrypt, apunte un filtro de Fail2ban a su log de acceso, de la misma forma que la cárcel de SSH apunta al journal.

Modos de fallo, con las cadenas exactas que verá

"Have not found any log file for sshd jail", y Fail2ban no inicia. Este es el antiguo problema auth.log, y en Ubuntu 24.04 solo ocurre si algo ha sobrescrito el valor predeterminado del paquete — una instalación pip sin defaults-debian.conf, un contenedor sin journal, o un backend = auto erróneo pegado en jail.local. En un backend de archivos sin /var/log/auth.log, el jail de sshd no puede encontrar su log y el daemon completo aborta. fail2ban.log muestra:

ERROR   Failed during configuration: Have not found any log file for sshd jail

Debido a que ese error es fatal, el servicio nunca se inicia, y fail2ban-client status reporta entonces el síntoma derivado:

ERROR  Failed to access socket path: /var/run/fail2ban/fail2ban.sock. Is fail2ban running?

Esa línea de "socket path" no significa que Fail2ban esté roto; significa que nunca se inició porque un jail no pudo encontrar su log. Configurar backend = systemd en [DEFAULT], algo que el paquete de Ubuntu ya hace por usted, corrige ambos mensajes a la vez.

El jail está activo pero Total failed nunca se mueve. El daemon se está ejecutando y el journal se está leyendo, pero los fallos reales se acumulan en journalctl -u ssh mientras el contador permanece en 0. Primero descarte lo obvio: está realizando pruebas desde una dirección listada en ignoreip, por lo que sus propios fallos están exentos por diseño. Si no es eso, está en una versión de OpenSSH donde el worker por conexión es sshd-session (9.8 y posteriores), cuyo journal _COMM es sshd-session, no sshd, por lo que la coincidencia incluida en el paquete no lo detecta. Amplíe la coincidencia en el bloque [sshd]:

[sshd]
enabled      = true
backend      = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd + _COMM=sshd-session

Reinicie, provoque un fallo de inicio de sesión a propósito desde una dirección que no esté en ignoreip, y confirme que Total failed finalmente aumenta.

Se ha bloqueado a sí mismo: Connection refused. Dejó su propia dirección fuera de ignoreip, realizó varios inicios de sesión fallidos y ahora:

ssh: connect to host 10.0.0.10 port 22: Connection refused

El rechazo, en lugar de un timeout silencioso, es el veredicto reject por defecto de la acción de nftables haciendo su trabajo — contra usted. Corríjalo como en el Paso 6: desbloquéese desde una sesión en una dirección diferente y no bloqueada, o desde la consola del proveedor — una sesión ya abierta desde la dirección bloqueada también se congela. Luego añada su dirección a ignoreip para que no vuelva a ocurrir.

Fail2ban dice que una dirección está bloqueada, pero aún puede conectarse. El contador en status sshd aumenta, pero la dirección sigue alcanzando el puerto 22. Esto es un desajuste entre la acción de bloqueo y el firewall; en Ubuntu 24.04 casi siempre significa que sobrescribió el banaction = nftables funcional con un banaction = iptables-multiport copiado de una guía antigua, en un sistema sin capa de iptables. fail2ban.log muestra:

fail2ban.actions [812]: ERROR  Failed to execute ban jail 'sshd' action 'iptables-multiport'

Elimine esa sobrescritura y deje la acción nftables del paquete, o, si gestiona el firewall totalmente mediante ufw y desea que los bloqueos aparezcan allí, configure banaction = ufw en [DEFAULT]. Reinicie y confirme que la regla aparece con sudo nft list ruleset | grep f2b.

Fail2ban no inicia tras editar jail.local. Un error tipográfico —un encabezado erróneo o un valor de tiempo incorrecto— hace que el servicio se niegue a iniciar. Pida a Fail2ban que verifique la configuración antes de ejecutarse:

sudo fail2ban-client -t

Indicará el archivo y el jail con el problema, por ejemplo Errors in jail 'sshd'. Skipping..., para que pueda corregir el origen en lugar de adivinar.

FAQ

¿La instalación estándar de Fail2ban en Ubuntu 24.04 realmente bloquea ataques SSH?

Sí. El paquete incluye /etc/fail2ban/jail.d/defaults-debian.conf, lo que habilita la cárcel sshd, establece backend = systemd para leer el journal de systemd en lugar del inexistente /var/log/auth.log, y configura banaction = nftables para que los bloqueos se apliquen mediante el firewall real de Ubuntu. Una configuración apt install fail2ban estándar protege SSH desde el primer arranque. Confírmelo con sudo fail2ban-client status sshd y busque un valor de Total failed distinto de cero.

¿Por qué Fail2ban no bloquea nada en mi servidor?

Descarte las tres causas comunes en orden. Puede estar realizando pruebas desde una dirección en ignoreip, la cual está exenta por diseño. Puede haber sobrescrito la configuración predeterminada al pegar backend = auto en jail.local desde una guía antigua, lo que impide la lectura del journal en imágenes sin auth.log. O puede estar dentro de un contenedor sin un journal de systemd para leer. Verifique Total failed en fail2ban-client status sshd: si el valor no aumenta mientras journalctl -u ssh muestra fallos reales, la cárcel está leyendo el archivo incorrecto.

¿Cómo desbloqueo mi propia dirección IP?

Ejecute sudo fail2ban-client set sshd unbanip YOUR.IP.HERE, que devuelve 1 si tiene éxito, o sudo fail2ban-client unban --all para eliminar todos los bloqueos. Si ha perdido el acceso por SSH, use la consola web o VNC de su proveedor para ejecutar el mismo comando; el bloqueo rechaza cada paquete de su dirección hacia el puerto 22, por lo que incluso una sesión ya abierta dejará de funcionar. Luego, añada su dirección a ignoreip para evitar que se repita.

¿Cuál es la diferencia entre jail.conf y jail.local?

jail.conf contiene los valores predeterminados originales de Fail2ban y se sobrescribe en cada actualización del paquete; cualquier edición allí se perderá eventualmente. El paquete de Debian/Ubuntu aplica sus propios ajustes mediante jail.d/defaults-debian.conf. Sus cambios deben ir en jail.local, que es el último archivo que se lee y tiene prioridad sobre ambos, y que las actualizaciones nunca modifican. Deje jail.conf solo como referencia de lectura.

¿Sustituye Fail2ban la autenticación SSH basada en llaves?

No. Fail2ban limita la frecuencia de intentos fallidos repetidos desde una misma dirección; no sirve contra ataques de fuerza bruta distribuidos y lentos donde cada dirección se mantiene bajo el umbral. La autenticación solo por llaves (PasswordAuthentication no) imposibilita el ataque de contraseñas por completo; en ese caso, Fail2ban solo sirve para reducir el ruido en los logs y expulsar escáneres rápidamente. Use ambos métodos y, de forma ideal, mantenga SSH fuera de la internet pública.