# Fail2ban para proteger SSH de ataques de fuerza bruta

**Categoría:** Linux · **Nivel:** Intermedio · **Lectura:** 18 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/linux/fail2ban-para-proteger-ssh-de-ataques-de-fuerza-bruta/

## Respuesta rápida

**Fail2ban** es una herramienta de seguridad que protege un servidor de los **ataques de fuerza bruta** —sobre todo contra **SSH**, el acceso remoto—. El problema que resuelve es real y constante: en cuanto exponés SSH a internet, aparecen **bots automáticos** que prueban miles de combinaciones de usuario y contraseña por día, intentando adivinar las credenciales. Fail2ban corta eso de raíz con una idea simple: **vigila los registros** (los *logs*) del servidor, detecta cuándo una misma **IP** falla al iniciar sesión **demasiadas veces** en poco tiempo, y le **bloquea el acceso** temporalmente añadiendo una regla al cortafuegos. Es decir: al que insiste en adivinar, le cierra la puerta. Funciona con dos conceptos. Las **reglas de detección** (filtros): patrones que buscan en los logs las líneas de «intento fallido». Y las **jails** («cárceles»): la configuración que dice *qué* vigilar, *cuántos* fallos se toleran, en *cuánto* tiempo, y por *cuánto* se bloquea al infractor. La jail de SSH viene preparada y protegerla es tan simple como activarla y ajustar esos números. Un punto importante de encuadre: Fail2ban es una defensa **para tu propio servidor** —endurecerlo frente a ataques—, no una herramienta ofensiva. Y no es una bala de plata: **complementa**, no sustituye, a la medida de seguridad más importante de SSH, que es usar [claves en lugar de contraseñas](../conexion-remota-segura-con-ssh-y-claves/index.md) (con clave, la fuerza bruta de contraseñas simplemente no aplica). Lo ideal es la combinación: claves SSH como defensa principal, Fail2ban para frenar el ruido y el desgaste de los ataques, y otras medidas de endurecimiento. Sencillo de instalar, muy efectivo, y de lo primero que se pone en un servidor expuesto.

## La amenaza

Cualquiera que haya mirado los registros de un servidor con SSH expuesto a internet conoce el espectáculo: **cientos o miles de intentos de inicio de sesión fallidos al día**, desde IPs de todo el mundo, probando usuarios comunes (root, admin, user) y contraseñas típicas. No es que alguien te tenga entre ceja y ceja: son **bots automáticos** que escanean internet sin descanso buscando servidores SSH y lanzando **ataques de fuerza bruta** —probar combinaciones una tras otra hasta acertar—. Es ruido de fondo constante de internet. Y aunque la mayoría de esos intentos fracasan, representan un riesgo real (si tenés una contraseña débil, tarde o temprano la adivinan) y un desgaste (consumen recursos y ensucian los logs).

> **Atención**
>
> Conviene encuadrarlo bien: Fail2ban es una herramienta **defensiva**, para proteger **tu propio servidor** o uno que administrás. Su función es *frenar* ataques entrantes, no lanzarlos. Bloquea temporalmente a las IPs que se comportan como atacantes contra *tu* máquina, dentro de *tu* propio cortafuegos. Es exactamente el tipo de medida de endurecimiento que debe llevar todo servidor expuesto a internet, y encaja en el marco de la [administración segura de servidores](../administracion-de-servidores-linux-desde-cero/index.md). No hay nada de ofensivo en ello: es cerrar tu propia puerta a quien insiste en forzarla.

## Cómo funciona

El ciclo de Fail2ban es un bucle simple de vigilar, detectar y bloquear:

| Paso | Qué hace |
|---|---|
| 1. Vigila | Lee continuamente los registros del servicio (los intentos de login de SSH) |
| 2. Detecta | Con un filtro, reconoce las líneas de «intento fallido» y cuenta por IP |
| 3. Bloquea | Si una IP supera el umbral, le añade una regla de bloqueo en el cortafuegos |
| 4. Libera | Pasado el tiempo de bloqueo, retira la regla automáticamente |

> **Atención**
>
> Para configurar Fail2ban hay que entender dos piezas. Los **filtros** son las *reglas de detección*: patrones (expresiones regulares) que reconocen en los logs qué líneas significan «intento fallido» para cada servicio. Fail2ban trae filtros ya hechos para SSH y muchos otros servicios, así que rara vez hay que escribirlos. Las **jails** («cárceles») son la *configuración de la protección*: cada jail asocia un filtro a un servicio y define los cuatro números clave: qué log vigilar, cuántos fallos se toleran (*maxretry*), en qué ventana de tiempo (*findtime*), y cuánto dura el bloqueo (*bantime*). La jail de SSH viene preconfigurada; protegerlo se reduce a **activarla** y, si querés, ajustar esos valores —por ejemplo, 5 fallos en 10 minutos, bloqueo de 1 hora—. La configuración se hace en un archivo local para no perderla al actualizar. Para revisar qué está pasando —qué IPs se han bloqueado—, se consulta el estado de Fail2ban, y para investigar a fondo, los [logs con journalctl](../diagnostico-con-systemd-journalctl-y-strace/index.md).

## Parte de un conjunto

Fail2ban es efectivo, pero **no es la única ni la principal defensa** de SSH. Encaja en un conjunto de medidas que se refuerzan entre sí:

| Medida | Qué aporta |
|---|---|
| Claves SSH en vez de contraseñas | La defensa principal: la fuerza bruta de contraseñas deja de aplicar |
| Desactivar el login de root por SSH | Elimina el objetivo más buscado por los bots |
| Fail2ban | Frena el ruido y el desgaste de los intentos automáticos |
| Cambiar el puerto / cortafuegos | Reduce el escaneo automático (medida menor, complementaria) |

> **Atención**
>
> Es importante entender la jerarquía. La medida **más importante** para proteger SSH no es Fail2ban, sino usar [claves en lugar de contraseñas](../conexion-remota-segura-con-ssh-y-claves/index.md). Con autenticación por clave (y el login por contraseña desactivado), un ataque de fuerza bruta de *contraseñas* **simplemente no puede funcionar**: no hay contraseña que adivinar. En ese escenario, Fail2ban ya no te salva de un compromiso —las claves lo hacen—, pero **sigue aportando**: reduce el ruido en los logs, ahorra recursos que consumen los miles de intentos, y añade una capa contra otros abusos. Por eso la respuesta correcta no es «Fail2ban o claves», sino **ambos**: claves como cerradura de verdad, Fail2ban como portero que echa a los que insisten. Poner Fail2ban *y* mantener las contraseñas activas es un error común: es proteger el ruido sin cerrar la puerta real. Todo esto forma parte del endurecimiento que debería acompañar cualquier despliegue, y de un buen [plan de respuesta a incidentes](../../hacking/como-crear-un-plan-de-respuesta-ante-incidentes/index.md).

## Errores frecuentes

- **Usar Fail2ban y mantener las contraseñas.** La defensa principal son las claves; Fail2ban complementa, no sustituye.
- **Bloquearte a ti mismo.** Si fallás varias veces, tu propia IP puede caer; conviene añadir tu IP a la lista blanca.
- **Editar el archivo de configuración por defecto.** Se pierde al actualizar; la configuración va en un archivo local.
- **Poner un bantime demasiado corto.** Un bloqueo de segundos apenas frena al bot; ajustar a valores útiles.
- **No verificar que la jail de SSH está activa.** Instalar Fail2ban no basta; hay que activar la protección del servicio.
- **Confiar solo en cambiar el puerto.** Reduce el escaneo pero no protege; es una medida menor.
- **Olvidar revisar los bloqueos.** Conviene mirar el estado para detectar tanto ataques como falsos positivos.

## Preguntas frecuentes

**¿Qué es Fail2ban?**
Fail2ban es una herramienta de seguridad para servidores Linux cuya función es proteger los servicios expuestos, especialmente el acceso remoto por SSH, frente a los ataques de fuerza bruta, bloqueando de forma automática y temporal las direcciones de red que realizan demasiados intentos fallidos de inicio de sesión. El problema que resuelve es una realidad constante para cualquier servidor conectado a internet: en cuanto se expone un servicio como SSH, aparecen bots automáticos que recorren internet buscando servidores y lanzando ataques de fuerza bruta, que consisten en probar miles de combinaciones de usuario y contraseña una tras otra con la esperanza de adivinar unas credenciales válidas. Estos intentos, que pueden sumar cientos o miles al día, representan tanto un riesgo de seguridad, porque si existe una contraseña débil podría acabar siendo adivinada, como un desgaste del servidor, ya que consumen recursos y llenan los registros de ruido. Fail2ban aborda este problema con un mecanismo sencillo y eficaz: vigila continuamente los registros del servidor, donde queda constancia de cada intento de inicio de sesión; mediante unas reglas de detección identifica en esos registros las líneas correspondientes a los intentos fallidos y cuenta cuántos fallos comete cada dirección de red; y cuando una dirección supera un número de fallos permitido en un intervalo de tiempo, le bloquea el acceso durante un periodo determinado, añadiendo una regla al cortafuegos del sistema que le cierra la puerta. Transcurrido el tiempo de bloqueo, la regla se retira automáticamente. De este modo, Fail2ban frena en seco a los atacantes que insisten, ya que tras unos pocos intentos fallidos quedan bloqueados y no pueden seguir probando. Es una herramienta defensiva, destinada a proteger el propio servidor, sencilla de instalar y muy efectiva, que se considera una de las primeras medidas que conviene aplicar en cualquier servidor con servicios expuestos a internet. No obstante, no es una solución mágica ni la principal defensa de SSH, sino que complementa a medidas más fundamentales como el uso de claves en lugar de contraseñas, formando parte de un conjunto de medidas de endurecimiento del servidor.

**¿Qué es un ataque de fuerza bruta contra SSH?**
Un ataque de fuerza bruta contra SSH es un intento de conseguir acceso no autorizado a un servidor a través del servicio de acceso remoto SSH probando de forma sistemática y automatizada un gran número de combinaciones de usuario y contraseña, con la esperanza de acertar unas credenciales válidas que permitan entrar. El nombre de fuerza bruta alude precisamente a que no se emplea ninguna astucia técnica sofisticada, sino que simplemente se prueban muchísimas posibilidades una tras otra hasta dar con la correcta, confiando en la potencia de cálculo y en la persistencia. En el contexto de SSH, estos ataques son llevados a cabo casi siempre por bots automáticos, es decir, por programas que recorren internet de forma incesante buscando servidores que tengan el servicio SSH accesible y, cuando los encuentran, comienzan a lanzar intentos de inicio de sesión probando nombres de usuario comunes, como los de administración, y listas de contraseñas habituales o generadas. Cualquier servidor con SSH expuesto a internet empieza a recibir estos intentos a los pocos minutos de estar en línea, y es normal que acumule cientos o miles de intentos fallidos al día procedentes de direcciones de todo el mundo. Es importante entender que, en la inmensa mayoría de los casos, estos ataques no van dirigidos específicamente contra un servidor concreto por interés en él, sino que forman parte de un rastreo masivo e indiscriminado de internet en busca de objetivos fáciles, es decir, servidores con credenciales débiles o mal configurados. El peligro de estos ataques radica en que, si el servidor utiliza autenticación por contraseña y esa contraseña es débil o común, existe una probabilidad real de que, con suficientes intentos, el atacante acabe adivinándola y consiga acceso al servidor, con las graves consecuencias que ello conlleva. Además, aunque no lleguen a tener éxito, estos ataques suponen un desgaste continuo, ya que consumen recursos del servidor y llenan los registros de ruido que dificulta detectar otros problemas. Frente a esta amenaza, las defensas fundamentales son usar autenticación por claves en lugar de por contraseñas, con lo que el ataque de fuerza bruta de contraseñas deja de tener sentido, y desactivar el acceso directo del usuario administrador, mientras que Fail2ban aporta una capa adicional muy útil al bloquear a las direcciones que realizan demasiados intentos fallidos, frenando así el ataque y reduciendo su impacto.

**¿Cómo detecta y bloquea Fail2ban a los atacantes?**
Fail2ban detecta y bloquea a los atacantes mediante un ciclo de vigilancia de los registros, detección de intentos fallidos y bloqueo temporal en el cortafuegos, apoyándose en dos conceptos fundamentales que son los filtros y las jails. El proceso comienza con la vigilancia de los registros. Fail2ban monitoriza de forma continua los archivos de registro del servidor, en los que los servicios como SSH anotan cada intento de inicio de sesión, indicando si tuvo éxito o si falló y desde qué dirección de red se realizó. A continuación viene la detección, que se realiza mediante los filtros. Un filtro es una regla de detección, técnicamente un patrón, que Fail2ban utiliza para reconocer en los registros las líneas que corresponden a intentos fallidos de inicio de sesión para un servicio concreto. Fail2ban incluye filtros ya preparados para SSH y para muchos otros servicios, por lo que rara vez es necesario escribirlos manualmente. Usando el filtro, Fail2ban identifica los intentos fallidos y lleva la cuenta de cuántos comete cada dirección de red. El bloqueo se produce cuando una dirección supera el umbral configurado, es decir, cuando realiza más intentos fallidos de los permitidos dentro de una ventana de tiempo determinada. En ese momento, Fail2ban añade una regla al cortafuegos del sistema que bloquea el tráfico procedente de esa dirección, cerrándole efectivamente la puerta durante un periodo de tiempo definido, tras el cual la regla se retira automáticamente y la dirección vuelve a poder conectarse. Todo este comportamiento se configura mediante las jails, que son el segundo concepto clave. Una jail, cuyo nombre significa cárcel, es la configuración de la protección para un servicio, y asocia un filtro a un servicio definiendo los parámetros fundamentales del bloqueo: qué registro vigilar, cuántos intentos fallidos se toleran antes de bloquear, en qué ventana de tiempo se cuentan esos intentos, y durante cuánto tiempo dura el bloqueo. Para proteger SSH, Fail2ban trae una jail preconfigurada, de modo que activar la protección se reduce a habilitarla y, opcionalmente, ajustar esos parámetros a los valores deseados, por ejemplo tolerar un cierto número de fallos en unos minutos y bloquear durante una hora. La configuración se realiza en un archivo local para que no se pierda al actualizar la herramienta, y el estado de los bloqueos se puede consultar para ver qué direcciones han sido bloqueadas.

**¿Qué son las jails de Fail2ban?**
Las jails, cuyo nombre en inglés significa cárceles, son el concepto central de configuración de Fail2ban, y representan cada una la configuración de la protección para un servicio concreto, definiendo qué vigilar y bajo qué condiciones bloquear a las direcciones que se comportan como atacantes. Cada jail combina varios elementos que, en conjunto, determinan cómo Fail2ban protege un servicio determinado. El primer elemento es el filtro que la jail utiliza, es decir, la regla de detección que identifica en los registros las líneas correspondientes a los intentos fallidos para ese servicio. El segundo elemento es el registro o los registros que la jail debe vigilar, que son aquellos en los que el servicio anota sus intentos de inicio de sesión. El tercer elemento es el número máximo de intentos fallidos que se toleran antes de aplicar un bloqueo, un parámetro que determina cuán estricta es la protección. El cuarto elemento es la ventana de tiempo dentro de la cual se cuentan esos intentos fallidos, de modo que solo se bloquea a una dirección si acumula el número de fallos permitido dentro de ese intervalo. Y el quinto elemento es la duración del bloqueo, es decir, cuánto tiempo permanecerá bloqueada una dirección antes de que se le permita volver a conectarse. Ajustando estos parámetros se puede afinar el equilibrio entre seguridad y tolerancia, por ejemplo permitiendo algunos fallos para no penalizar los errores legítimos de tecleo, pero bloqueando con firmeza a quien insiste. Fail2ban incluye jails preconfiguradas para los servicios más habituales, y en particular una jail para SSH que ya viene lista, de manera que proteger el acceso remoto es tan sencillo como activar esa jail y, si se desea, ajustar sus parámetros. Un aspecto importante de la configuración de las jails es que las modificaciones deben realizarse en un archivo de configuración local y no en los archivos de configuración por defecto que trae la herramienta, ya que estos últimos pueden ser sobrescritos al actualizar Fail2ban, con lo que se perderían los cambios. Al usar un archivo local, la configuración personalizada se mantiene a salvo de las actualizaciones. Comprender el concepto de jail es esencial para configurar Fail2ban correctamente, ya que es a través de las jails como se define qué servicios se protegen y con qué criterios se bloquea a los atacantes.

**¿Fail2ban sustituye a las claves SSH?**
No, Fail2ban no sustituye a las claves SSH, sino que las complementa, ya que la autenticación por claves es la defensa fundamental y más importante para proteger el acceso remoto por SSH, mientras que Fail2ban aporta una capa adicional de protección que reduce el ruido y el desgaste de los ataques pero que no debe considerarse la principal barrera de seguridad. Para entender esta relación hay que comprender qué hace cada una. La autenticación por claves SSH consiste en usar un par de claves criptográficas en lugar de una contraseña para verificar la identidad de quien se conecta, de modo que solo puede acceder quien posee la clave privada correspondiente. Cuando se configura la autenticación por claves y se desactiva la autenticación por contraseña, un ataque de fuerza bruta de contraseñas simplemente deja de tener sentido, porque ya no hay ninguna contraseña que adivinar, y por muchos intentos que haga un atacante nunca podrá entrar probando contraseñas. Por eso las claves SSH son la defensa principal y más eficaz contra este tipo de ataques. Fail2ban, por su parte, actúa a un nivel distinto: no impide que existan intentos de acceso, sino que bloquea a las direcciones que realizan demasiados intentos fallidos. En un servidor que usa autenticación por contraseña, Fail2ban es muy valioso porque limita las posibilidades de que un ataque de fuerza bruta tenga éxito, al cortar a los atacantes tras unos pocos intentos. Pero en un servidor que ya usa autenticación por claves y ha desactivado las contraseñas, Fail2ban ya no es lo que impide un compromiso, puesto que las claves ya lo impiden, aunque sigue siendo útil por otros motivos: reduce el ruido en los registros, ahorra los recursos que consumen los miles de intentos automáticos, y añade una capa de protección frente a otros posibles abusos. Por ello, la forma correcta de plantearlo no es elegir entre Fail2ban o claves, sino usar ambos de forma combinada, empleando las claves como la cerradura de verdad que impide el acceso no autorizado y Fail2ban como un portero que echa a quienes insisten en intentarlo. Un error común es instalar Fail2ban pero seguir permitiendo el acceso por contraseña, lo que equivale a proteger el ruido sin cerrar la puerta principal. La configuración ideal de un servidor seguro combina la autenticación por claves como defensa principal, la desactivación del acceso directo del usuario administrador, Fail2ban para frenar el ruido de los ataques, y otras medidas de endurecimiento, formando así un conjunto de capas que se refuerzan mutuamente.

**¿Puedo bloquearme a mí mismo con Fail2ban?**
Sí, es perfectamente posible bloquearse a uno mismo con Fail2ban si se cometen demasiados intentos fallidos de inicio de sesión desde la propia dirección de red, ya que Fail2ban no distingue quién está detrás de una dirección, sino que aplica sus reglas por igual a todas las direcciones que superan el umbral de fallos configurado, por lo que conviene tomar precauciones para evitar quedarse fuera del propio servidor. Este autobloqueo puede ocurrir en varias situaciones habituales, como equivocarse repetidamente al escribir la contraseña, tener mal configurado el cliente SSH de modo que realice intentos fallidos, o estar probando la propia configuración de seguridad. Si se acumulan más intentos fallidos de los permitidos en la ventana de tiempo establecida, Fail2ban bloqueará la dirección desde la que se conecta el administrador, con el incómodo resultado de que este pierde el acceso a su propio servidor durante el tiempo de bloqueo configurado. Para evitar este problema, la medida más importante es añadir las direcciones de confianza, especialmente la propia, a una lista blanca o de direcciones ignoradas, que Fail2ban nunca bloquea con independencia de cuántos fallos cometan. Configurar esta lista blanca con la dirección o el rango de direcciones desde los que el administrador se conecta habitualmente garantiza que nunca se bloqueará a sí mismo, y es una de las primeras cosas que conviene hacer al configurar Fail2ban. No obstante, hay que tener cuidado con las direcciones dinámicas, ya que si la dirección desde la que se conecta el administrador cambia con el tiempo, la lista blanca podría quedar desactualizada. Como precaución adicional, es muy recomendable disponer de una vía de acceso alternativa al servidor que no dependa de SSH, como una consola de emergencia o un acceso a través del panel del proveedor de alojamiento, de modo que si por cualquier motivo se produce un autobloqueo se pueda entrar por otra vía para solucionarlo, por ejemplo eliminando el bloqueo de la propia dirección. También ayuda configurar tiempos de bloqueo razonables y no excesivamente largos durante la fase de pruebas, para que un autobloqueo accidental no deje sin acceso durante demasiado tiempo. En resumen, aunque el autobloqueo es un riesgo real al usar Fail2ban, se previene fácilmente añadiendo la propia dirección a la lista blanca y manteniendo una vía de acceso alternativa al servidor.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [GNU/Linux](https://underc0de.org/foro/gnu-linux/). Seguridad y administración de servidores.
2. **Underc0de, foro.** [Seguridad informática](https://underc0de.org/foro/seguridad-informatica/). Endurecimiento de sistemas.

### Documentación oficial

1. **Fail2ban.** [Fail2ban (GitHub)](https://github.com/fail2ban/fail2ban). Código y documentación oficial.
2. **OpenSSH.** [OpenSSH Manual](https://www.openssh.com/manual.html). El servidor SSH.
3. **NIST.** [SP 800-123](https://csrc.nist.gov/pubs/sp/800/123/final). Guía de seguridad de servidores.
4. **The Linux Documentation Project.** [TLDP](https://tldp.org/). Seguridad en Linux.

## Guías relacionadas

- [SSH con claves](../conexion-remota-segura-con-ssh-y-claves/index.md)
- [Administración de servidores](../administracion-de-servidores-linux-desde-cero/index.md)
- [Diagnóstico con journalctl](../diagnostico-con-systemd-journalctl-y-strace/index.md)
- [Respuesta a incidentes](../../hacking/como-crear-un-plan-de-respuesta-ante-incidentes/index.md)
- [Índice de Linux](../index.md)