Fail2ban Apesta (2020)

Artículo original ↗ Discusión en Hacker News ↗

Fail2ban, una herramienta que analiza logs para bloquear temporalmente IPs tras repetidos fallos, divide a los administradores de sistemas sobre su verdadero valor de seguridad. Sus críticos argumentan que, con autenticación SSH basada en claves y un endurecimiento adecuado del servidor, aporta poco más que complejidad y riesgo de bloqueo, mientras que sus defensores dicen que reduce de forma significativa el ruido de fuerza bruta, el uso de recursos y el volumen de logs en servicios como SSH, correo y servidores web. El intercambio también aborda alternativas como bloqueadores integrados en aplicaciones, puertos no estándar, accesos mediante VPN/Zero Trust y los compromisos más amplios entre “defensa en profundidad” y “teatro de seguridad”.

Valor Percibido (Limitado) de Fail2ban

  • Muchos sostienen que, en gran medida, es innecesario para SSH una vez que se deshabilitan los inicios de sesión con contraseña y se aplica autenticación basada en claves.
  • Algunos lo ven principalmente como “teatro de seguridad” que hace que los administradores se sientan más seguros sin cambiar materialmente el riesgo frente a atacantes serios.
  • Otros responden que es una capa válida de “defensa en profundidad” que puede ralentizar o bloquear intentos de fuerza bruta y de password-spraying.

Casos de Uso en los que Fail2ban Ayuda

  • Ampliamente usado más allá de SSH: HTTP(S), IMAP/SMTP, SIP/VoIP, aplicaciones PHP heredadas, MQTT, NVRs, DNS, etc.
  • Beneficios reportados:
    • Reduce la carga de CPU/memoria derivada de intentos constantes de inicio de sesión/escaneo.
    • Disminuye el ruido en los logs, haciendo más fáciles de ver los problemas reales.
    • Útil para bloquear escáneres obvios (por ejemplo, rutas de phpMyAdmin, wp-login.php, honeypots de robots.txt).
  • Algunos administradores han usado con éxito scripts simples tipo fail2ban para mitigar reflexión DNS, abuso de SIP y fuerza bruta contra el correo.

Críticas, Riesgos y Dolor Operativo

  • Una mala configuración puede causar un bloqueo al propio administrador (por ejemplo, umbrales muy cortos o baneos permanentes), especialmente con clientes agresivos como Apple Mail.
  • En algunas distribuciones, la instalación por defecto hace poco hasta que se configuran explícitamente las jails; el registro estructurado y los contenedores pueden complicar la configuración.
  • Grandes conjuntos de reglas de iptables pueden perjudicar el rendimiento; se prefieren ipset o mecanismos residentes en el kernel.
  • El propio Fail2ban ha tenido CVEs (principalmente DoS, una RCE en una configuración no predeterminada), así que aumenta ligeramente la superficie de ataque.

Alternativas y Enfoques Arquitectónicos

  • Bloqueadores basados en kernel/API como blacklistd/blocklistd se consideran más limpios que raspar logs, pero requieren soporte de la aplicación.
  • Otras herramientas: CrowdSec, daemons mínimos personalizados, limitación de tasa con iptables/nftables, ipset, filtros específicos para DNS/SIP.
  • Algunos abogan por evitar por completo la exposición pública de servicios de administración: VPNs/Wireguard, jump hosts, redes Zero Trust/overlay, port knocking.

Cambiar los Puertos de SSH y Debates Relacionados

  • Pro: reduce drásticamente el tráfico SSH de paso y el ruido en los logs; es trivial de gestionar mediante ~/.ssh/config; a veces es necesario para sortear redes restrictivas.
  • Con: puede causar bloqueos si los puertos entran en conflicto, romper herramientas que asumen el puerto 22 y se considera una débil oscuridad. Hay preocupaciones sobre puertos no privilegiados que puedan volver a enlazarse, aunque existen mitigaciones (puertos reservados, DNAT).