Fail2ban 很烂（2020）

原文 ↗ Hacker News 讨论 ↗

Fail2ban 是一种会解析日志并在多次失败后临时封禁 IP 的工具，关于它到底有多大安全价值，系统管理员之间意见分歧很大。批评者认为，在 SSH 已启用基于密钥的认证并做好服务器加固后，它除了增加复杂度和锁定风险之外几乎没什么价值；支持者则认为，它确实能显著减少暴力破解噪音、资源占用和日志量，适用于 SSH、邮件和 Web 服务等场景。讨论还涉及应用集成式阻断器、非标准端口、VPN/Zero Trust 访问，以及“纵深防御”与“安全表演”之间更广泛的取舍。

Fail2ban 的（有限）价值

  • 许多人认为，在禁用密码登录并强制使用基于密钥的认证后，SSH 基本不再需要它。
  • 有些人主要把它看作一种“安全表演”，让管理员感觉更安全，但对真正的攻击者并没有实质性改变风险。
  • 也有人反驳说，它是一个有效的“纵深防御”层，可以减缓或阻止暴力破解和密码喷洒尝试。

Fail2ban 有帮助的使用场景

  • 除 SSH 外也被广泛使用：HTTP(S)、IMAP/SMTP、SIP/VoIP、旧版 PHP 应用、MQTT、NVR、DNS 等。
  • 报告中的收益包括：
    • 减少持续登录/扫描尝试带来的 CPU/内存负载。
    • 减少日志噪音，让真实问题更容易被看见。
    • 对明显的扫描器很有用（例如 phpMyAdmin 路径、wp-login.php、robots.txt 蜜罐）。
  • 一些管理员成功使用了简单的类似 fail2ban 的脚本来缓解 DNS 反射、SIP 滥用和邮件暴力破解。

批评、风险与运维痛点

  • 配置不当可能导致把自己锁在外面（例如阈值过短或永久封禁），尤其是在 Apple Mail 这类激进客户端下。
  • 在某些发行版上，默认安装在显式配置 jail 之前几乎不起作用；结构化日志和容器会让设置更困难。
  • 大量 iptables 规则会影响性能；更推荐 ipset 或驻留在内核中的机制。
  • Fail2ban 本身也出现过 CVE（大多是 DoS，还有一个发生在非默认配置下的 RCE），因此它会略微增加攻击面。

替代方案与架构思路

  • 基于内核/API 的阻断器，如 blacklistd/blocklistd，被认为比抓取日志更干净，但需要应用支持。
  • 其他工具：CrowdSec、自定义精简守护进程、iptables/nftables 限速、ipset、DNS/SIP 专用过滤器。
  • 有些人主张干脆不要把管理服务暴露到公网：VPN/WireGuard、跳板机、Zero Trust/覆盖网络、端口敲门。

更改 SSH 端口及相关争论

  • 优点：大幅减少顺手扫到的 SSH 流量和日志噪音；可通过 ~/.ssh/config 轻松管理；有时还需要用来绕过受限网络。
  • 缺点：如果端口冲突会导致锁定，破坏假定 22 端口的工具，并且被视为一种弱化的隐藏安全。有人担心非特权端口会被重新绑定，不过也存在缓解手段（保留端口、DNAT）。