Fail2ban Sucks (2020)

Artigo original ↗ Discussão no Hacker News ↗

Fail2ban, uma ferramenta que analisa logs para bloquear temporariamente IPs após falhas repetidas, divide administradores de sistemas quanto ao seu verdadeiro valor de segurança. Críticos argumentam que, com autenticação SSH por chave e o endurecimento adequado do servidor, ele acrescenta pouco além de complexidade e risco de lockout, enquanto defensores dizem que ele reduz de forma significativa o ruído de brute-force, o uso de recursos e o volume de logs em serviços como SSH, e-mail e servidores web. A discussão também aborda alternativas como bloqueadores integrados à aplicação, portas não padrão, acesso via VPN/Zero Trust e os trade-offs mais amplos entre “defesa em profundidade” e “teatro de segurança”.

Valor (Limitado) Percebido do Fail2ban

  • Muitos argumentam que ele é amplamente desnecessário para SSH, uma vez que os logins por senha são desativados e a autenticação por chave é imposta.
  • Alguns o veem principalmente como “teatro de segurança” que faz os administradores se sentirem mais seguros sem alterar materialmente o risco diante de atacantes sérios.
  • Outros contrapõem que ele é uma camada válida de “defesa em profundidade” que pode retardar ou bloquear tentativas de brute-force e password-spraying.

Casos de Uso em Que o Fail2ban Ajuda

  • Amplamente usado além de SSH: HTTP(S), IMAP/SMTP, SIP/VoIP, apps PHP legados, MQTT, NVRs, DNS, etc.
  • Benefícios relatados:
    • Reduz a carga de CPU/memória causada por tentativas constantes de login/scan.
    • Diminui o ruído nos logs, tornando mais fácil ver problemas reais.
    • Útil para banir scanners óbvios (por exemplo, paths do phpMyAdmin, wp-login.php, honeypots do robots.txt).
  • Alguns administradores usaram com sucesso scripts simples no estilo fail2ban para mitigar reflection de DNS, abuso de SIP e brute force em e-mail.

Críticas, Riscos e Dor Operacional

  • Configuração incorreta pode causar auto-lockout (por exemplo, limiares muito curtos ou bans permanentes), especialmente com clientes agressivos como o Apple Mail.
  • Em algumas distros, a instalação padrão faz pouco até que as jails sejam configuradas explicitamente; logging estruturado e containers podem dificultar a configuração.
  • Conjuntos grandes de regras de iptables podem prejudicar o desempenho; ipset ou mecanismos residentes no kernel são preferidos.
  • O próprio Fail2ban já teve CVEs (principalmente DoS, um RCE em uma configuração não padrão), então ele aumenta levemente a superfície de ataque.

Alternativas e Abordagens Arquiteturais

  • Bloqueadores baseados em kernel/API como blacklistd/blocklistd são vistos como mais limpos do que scraping de logs, mas exigem suporte da aplicação.
  • Outras ferramentas: CrowdSec, daemons mínimos personalizados, rate limiting em iptables/nftables, ipset, filtros específicos para DNS/SIP.
  • Alguns defendem evitar a exposição pública de serviços administrativos por completo: VPNs/Wireguard, jump hosts, Zero Trust/redes overlay, port knocking.

Mudança de Portas de SSH e Debates Relacionados

  • Pró: reduz drasticamente o tráfego SSH casual e o ruído nos logs; trivial de gerenciar via ~/.ssh/config; às vezes necessário para contornar redes restritivas.
  • Contra: pode causar lockouts se as portas conflitam, quebrar ferramentas que assumem a porta 22 e é visto como obscuridade fraca. Há preocupações sobre portas não privilegiadas serem rebinding, embora existam mitigations (portas reservadas, DNAT).