Fail2ban Sucks (2020)

Fail2ban, a tool that parses logs to temporarily block IPs after repeated failures, divides system administrators over its real security value. Critics argue that with SSH key-based authentication and proper server hardening it adds little beyond complexity and lockout risk, while supporters say it meaningfully cuts brute‑force noise, resource usage, and log volume across services like SSH, mail, and web servers. The exchange also touches on alternatives such as application-integrated blockers, nonstandard ports, VPNs/Zero Trust access, and broader “defense in depth” versus “security theater” trade-offs.

Perceived (Limited) Value of Fail2ban

  • Many argue it’s largely unnecessary for SSH once password logins are disabled and key-based auth is enforced.
  • Some see it mainly as “security theater” that makes admins feel safer without materially changing risk against serious attackers.
  • Others counter that it is a valid “defense in depth” layer that can slow or block brute-force and password-spraying attempts.

Use Cases Where Fail2ban Helps

  • Widely used beyond SSH: HTTP(S), IMAP/SMTP, SIP/VoIP, legacy PHP apps, MQTT, NVRs, DNS, etc.
  • Reported benefits:
    • Reduces CPU/memory load from constant login/scan attempts.
    • Cuts down on log noise, making real issues easier to see.
    • Useful for banning obvious scanners (e.g., phpMyAdmin paths, wp-login.php, robots.txt honeypots).
  • Some admins have successfully used simple fail2ban-like scripts to mitigate DNS reflection, SIP abuse, and mail brute force.

Critiques, Risks, and Operational Pain

  • Misconfiguration can cause self‑lockout (e.g., very short thresholds or permanent bans), especially with aggressive clients like Apple Mail.
  • On some distros, default install does little until jails are explicitly configured; structured logging and containers can make setup harder.
  • Large iptables rule sets can hurt performance; ipset or kernel-resident mechanisms are preferred.
  • Fail2ban itself has had CVEs (mostly DoS, one RCE in a non-default setup), so it increases attack surface slightly.

Alternatives and Architectural Approaches

  • Kernel/API-based blockers like blacklistd/blocklistd are viewed as cleaner than log scraping but require application support.
  • Other tools: CrowdSec, custom minimal daemons, iptables/nftables rate limiting, ipset, DNS/SIP-specific filters.
  • Some advocate avoiding public exposure of admin services altogether: VPNs/Wireguard, jump hosts, Zero Trust/overlay networks, port knocking.

Changing SSH Ports and Related Debates

  • Pro: drastically reduces drive‑by SSH traffic and log noise; trivial to manage via ~/.ssh/config; sometimes needed to bypass restrictive networks.
  • Con: can cause lockouts if ports clash, break tools that assume port 22, and is seen as weak obscurity. Concerns about non-privileged ports being re-bound, though mitigations (reserved ports, DNAT) exist.