Fail2ban no asegura SSH, y su propio README lo dice
Instalas fail2ban, ves subir el contador de baneos, te sientes más seguro. Esa secuencia explica por qué la herramienta está en casi todos los servidores, y explica también por qué muchos de esos servidores están menos protegidos de lo que creen sus responsables.
La formulación más clara del problema no está en una crítica a fail2ban. Está en el propio README de fail2ban.
Qué hace realmente
El mecanismo es sencillo y funciona. Fail2ban analiza archivos de registro como /var/log/auth.log y banea las direcciones IP que realizan demasiados intentos de inicio de sesión fallidos. Lo hace actualizando las reglas del cortafuegos del sistema para rechazar nuevas conexiones desde esas direcciones IP durante un tiempo configurable.
Viene preparado para leer muchos archivos de registro estándar, incluidos los de sshd y Apache, y se le puede apuntar a cualquier archivo de registro que elijas, para cualquier error que quieras. Desde la versión 0.10 también reconoce direcciones IPv6.
Eso es una pieza de infraestructura genuinamente útil. Un servidor expuesto a internet acumula miles de intentos de inicio de sesión automatizados al día, y fail2ban convierte esa avalancha en un goteo.
La frase que el proyecto pone en su propio README
Aquí es donde la herramienta es más honesta que la mayoría de los consejos que se dan sobre ella:
Aunque Fail2Ban es capaz de reducir la tasa de intentos de autenticación incorrectos, no puede eliminar el riesgo que presenta una autenticación débil.
Fíjate en lo que ahí se admite. Fail2ban actúa sobre la tasa. No actúa sobre el riesgo. Son magnitudes distintas, y confundirlas es el error de fondo.
Si tu servidor SSH acepta una contraseña, un atacante tiene que adivinarla. Fail2ban ralentiza los intentos hasta hacerlos lentísimos y vuelve impracticable una fuerza bruta ingenua. Pero la puerta sigue abriéndose para cualquiera que tenga la contraseña, la haya adivinado, obtenido mediante phishing, comprado en un volcado de credenciales o sacado de un inicio de sesión reutilizado en un sitio ajeno que fue vulnerado. Ninguna de esas vías implica fallos repetidos, así que ninguna de ellas activa un baneo.
Qué te dice el proyecto que hagas en su lugar
El README no se queda en la advertencia. Nombra la alternativa:
Configura los servicios para que usen únicamente mecanismos de autenticación de dos factores o de clave pública/privada si de verdad quieres proteger servicios.
Ese es el arreglo real, y es un cambio de naturaleza más que un cambio de grado. Un servidor que acepta solo autenticación basada en claves no puede ser sometido a fuerza bruta en absoluto, porque no hay nada que adivinar. La superficie de ataque no se estrecha: desaparece.
Fíjate en la palabra solo. Añadir una clave dejando habilitada la autenticación por contraseña no cambia nada en cuanto al riesgo, porque el método más débil que se acepta es el que define tu exposición. El ajuste que importa es deshabilitar la autenticación por contraseña, no añadir una clave junto a ella.
Entonces, ¿deberías usarlo?
Sí, y por la razón correcta.
Consérvalo por el ruido. Unos registros que realmente puedas leer valen mucho. Cuando los intentos de autenticación fallidos bajan de miles al día a un puñado, una anomalía se vuelve visible en lugar de quedar sepultada. Ese es un beneficio operativo real y un buen argumento a favor de la herramienta.
No lo cuentes como tu seguridad de SSH. Si una revisión de seguridad de tu servidor termina en “fail2ban está instalado”, la revisión se detuvo un paso demasiado pronto. La pregunta que decide tu exposición es si se sigue aceptando la autenticación por contraseña.
Vigila lo que te cuesta. Los baneos se aplican a direcciones, y las direcciones se comparten. Una contraseña mal tecleada en una red corporativa o móvil puede dejar fuera a todos los que están detrás de esa dirección, tú incluido. Fail2ban es una de las formas más habituales en que los administradores se quedan fuera de sus propios servidores.
El resumen honesto
Fail2ban hace exactamente lo que dice: reduce la tasa de intentos de autenticación fallidos baneando en el cortafuegos las direcciones ruidosas, durante un tiempo configurable, a partir de tus registros.
Su propia documentación es explícita en que esto no puede eliminar el riesgo que presenta una autenticación débil, y en que los servicios que de verdad quieras proteger deberían usar mecanismos de dos factores o de clave pública y privada. Esas dos frases valen más que la mayoría de las listas de verificación de hardening.
Usa fail2ban para mantener tus registros legibles. Deshabilita la autenticación por contraseña para conservar tu servidor. No son sustitutos el uno del otro, y solo uno de los dos cambia lo que un atacante es capaz de hacer.
La descripción del comportamiento de fail2ban, la limitación citada sobre la autenticación débil, la recomendación de usar autenticación de dos factores o de clave pública y privada, y la compatibilidad con IPv6 desde la versión 0.10 están tomadas del propio README del proyecto fail2ban, consultado en el momento de escribir este artículo. Los detalles de configuración varían según la distribución; consulta la documentación de tu propio paquete antes de confiar en una ruta o un valor predeterminado concretos.