Fail2Ban 有效运营: 实战案例基础安全优化指南

1. 开始

在运营 Linux 服务器时，仅仅开放 SSH 端口就会经历大量的登录尝试。为了阻止这种情况，许多人使用的工具便是 Fail2Ban。但是，单单安装和配置是不够的。长时间运营后，封禁列表可能会累积到数百、数千个，从而影响服务器性能。

本文将基于实际的服务器运营经验，分享如何 更有效、更高效 地运营 Fail2Ban。

对于如何安装 Fail2Ban 及其基本配置感兴趣的朋友，可以参考之前的文章！ 守护 Linux 服务器的卫士，Fail2Ban

2. 实战经验: 3 周内 1,113 个 IP 被封禁

在我运营的测试用 Linux 服务器上设置 fail2ban 大约 3 周后，有一天我执行了以下命令:

sudo fail2ban-client status sshd

结果如下:

当前失败: 1
总失败: 5330
当前封禁: 1110
总封禁: 1113

3 周内，1,113 个 IP 被封禁，其中 1,110 个仍处于封禁状态。这是因为我配置了 bantime = -1 以进行永久封禁。

最初我设定的心态是 “尝试过一次的人不留情！” 但在数千个被封禁的 IP 堆积到 iptables 中后，我开始担心系统资源的消耗和管理的效率。

最终，我开始思考 可持续和战略性的 Fail2Ban 运用方式。

Tux 想保护 recidive jail 的样子

3. Fail2Ban 配置优化策略

✅ 灵活调节 bantime

  • 时间基础的封禁比单纯永久封禁更现实。
  • 示例:
  • bantime = 86400        # 封禁 1 天
findtime = 600         # 在 10 分钟内
maxretry = 3           # 3 次失败时

Fail2Ban 封禁流程图

✅ 利用 recidive jail

🔎 什么是 recidive jail?

fail2ban 监视管理的 fail2ban.log 文件，如果特定 IP 在多个 jail 中被反复封禁，则对该 IP 实施 长期再封禁 的高级功能。简而言之，这是 对重复犯处以更严厉的惩罚的 '再犯监视系统'。

一般来说，sshd、nginx、ftp 等个别 jail 只会在短时间内封禁，但 recidive jail 会 筛选出有 ‘累积犯罪记录’ 的 IP 进行更长时间的封禁。

  • 仅对重复被封禁的 IP 实施长期封禁
  • 一般攻击者一天就消失，而不断重试的攻击者可以进行筛选
  • 示例配置:
  • [recidive]
enabled = true
logpath = /var/log/fail2ban.log
bantime = 604800        # 1 周
findtime = 86400
maxretry = 5

✅ 日志管理自动化

  • 通过 logrotate 设置自动清理 /var/log/fail2ban.log ，防止文件过大
  • 通过 cron 或 systemd timer 将 fail2ban-client status 的结果进行汇总并发邮件

4. 参考脚本示例

#!/bin/bash
fail2ban-client status sshd > /tmp/sshd-status.log
echo "当前封禁数量: $(grep 'Currently banned' /tmp/sshd-status.log)" | mail -s "Fail2Ban SSHD 状态" your@email.com

5. 总结: Fail2Ban 是工具而非武器

Fail2Ban 是抵御随机攻击的非常有用的工具，但过度使用可能会导致 封禁不再是目的而成为服务器过载的原因。

合理的封禁政策与自动化管理工具的组合，可以使 Fail2Ban 从头疼的难题变成 值得信赖的安全伙伴。

下篇文章预告

我将介绍如何设置 logrotate 以防止 Fail2Ban 的日志文件 /var/log/fail2ban.log 变大。对这一主题感兴趣的朋友请订阅！