装了Fail2ban，怎么确认它真的在拦截攻击

Fail2ban装完，systemctl status fail2ban显示绿色的active (running)，看着一切正常，从此就不再管它，默认它一直在尽职尽责地拦截暴力破解。这个假设有风险——Fail2ban显示"运行正常"、甚至显示"已封禁某个IP"，都不代表它真的在起作用，一些常见的配置疏漏会让它变成一个只会报告好消息、实际什么都没拦住的摆设。

改了SSH端口，但没同步告诉Fail2ban

这是最容易被忽略、后果也最严重的一个坑。很多人图安全，把SSH默认端口从22改成别的数字，却忘了Fail2ban的对应规则里，action配置那一行写死了port=ssh（对应端口22）。攻击者其实是冲着你改过的新端口来的，Fail2ban监控日志确实检测到了暴力破解、确实执行了"封禁"动作，fail2ban-client status sshd看着显示封禁成功——但它实际下发的防火墙规则，拦的是22端口，跟攻击者真正在用的端口完全不搭边，等于什么都没拦住，只是自己心理上以为安全了。

改了SSH端口，记得同步改一下jail.local里对应规则的端口设置：

[sshd]
enabled = true
port = 你改过的实际端口号
logpath = /var/log/auth.log

系统时区变过，日志时间跟Fail2ban对不上

如果服务器中途调整过时区（或者之前排查过NTP同步问题动过手脚），日志里记录的时间戳如果跟Fail2ban自己感知的当前时间对不上，会导致它在判断"某个IP在规定时间窗口内失败了几次"这个逻辑上完全错乱，实际效果就是日志明明在报警，Fail2ban却始终判断"还没到触发阈值"，安静地什么都不做。这跟之前写的VPS的时间为什么会跑偏是同一类隐患的连锁反应——时间本身出问题，牵连的往往不只是日志时间戳好不好看，依赖时间判断逻辑的安全工具会跟着一起失灵。

封禁动作报告成功，防火墙规则却压根没插进去

还有一种更隐蔽的失效——fail2ban-client status sshd显示某个IP已经在封禁列表里，回头用iptables -L一查，对应的拦截链条根本不存在，日志里能翻到No chain/target/match by that name这类报错。这种情况下Fail2ban自己以为完成了任务，实际防火墙层面什么规则都没真正生效，攻击者畅通无阻。定期交叉验证一下两边的状态是否一致，比只看Fail2ban自己的汇报靠谱：

fail2ban-client status sshd
iptables -L -n | grep f2b

两边如果对不上号，说明封禁动作在防火墙这一层出了问题，需要单独排查。

验证Fail2ban到底有没有在正常读日志

不用干等着真实攻击发生才能验证，直接拿现有日志测一下正则匹配规则能不能正常识别：

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

如果匹配数量是0，问题可能出在日志格式跟预设的正则对不上——这种情况在用了Docker之类会给日志额外插入字段的环境下尤其常见，日志格式跟原生系统的默认格式有出入，Fail2ban的默认过滤规则可能压根认不出来。

顺带一提

这种"工具装了、开关打开了、看着一切正常，实际却完全没起作用"的情况，跟之前写的ulimit设置了却不生效是同一种性质的陷阱——配置本身可能一个字都没写错，但环境或者关联的另一项设置对不上，整套东西就变成了摆设。装完安全工具，花两分钟做一次真实验证，比事后翻日志才发现从来没生效过要踏实得多。