已通过UFW封禁IP仍收到auth.log登录失败记录的原因排查

这事儿我在运维过程中碰到过好多次，其实背后可能有好几个原因，咱们一个个排查：

• UFW规则顺序搞反了
  UFW的规则是按顺序匹配的，一旦匹配到某条规则就会停止后续检查。如果你先设置了允许SSH的规则（比如ufw allow ssh），之后才添加封禁该IP的规则，那允许规则会先被触发，封禁规则根本没机会生效。
  验证方法：运行ufw status numbered查看规则顺序，看封禁规则是不是排在允许SSH规则的前面。
  解决办法：用ufw insert 1 deny from xxx.xxx.xxx.xxx把封禁规则插到第一条，确保它优先匹配。

• 你封禁的不是真实的攻击源IP
  有些攻击者会用动态IP、代理服务器或者NAT转发，你封禁的只是它某次使用的临时IP，换个IP又能继续尝试。另外，TCP协议下IP欺骗很难成功，除非你的网络存在路由漏洞，这种情况比较少见。
  验证方法：用tcpdump -i any host xxx.xxx.xxx.xxx and port 22抓包，看看是不是真的有来自该IP的流量，或者是不是有其他IP伪装成它。

• UFW规则没生效或配置错误
  可能你添加了规则但没保存，或者UFW根本没启动？也有可能是你输入的IP地址写错了（比如少打了一段数字）。另外，如果系统里还有其他防火墙工具（比如直接配置了iptables规则），可能会覆盖UFW的设置——毕竟UFW本质是iptables的前端工具。
  验证方法：运行ufw status verbose确认UFW处于active状态，并且封禁规则确实在列表里；再运行iptables -L -n检查底层的iptables规则是否包含你的封禁条目。

• SSH监听了多个端口
  如果你修改过SSH配置，让它同时监听多个端口（比如默认22加上自定义的2222），但你的UFW封禁规则只针对了其中一个端口，那攻击者还能通过未被封禁的端口发起尝试，日志自然会有记录。
  验证方法：查看SSH配置文件/etc/ssh/sshd_config里的Port字段，确认所有监听的端口都被添加到封禁规则里。

• 日志里的IP是反向解析错误
  极少数情况下，auth.log里显示的IP是DNS反向解析的结果，而不是真实的源IP。比如某个真实IP反向解析成了你封禁的那个域名/IP，导致你误以为是同一个源。
  验证方法：结合tcpdump抓包的真实源IP和日志里的IP对比，确认是否一致。

内容的提问来源于stack exchange，提问作者Allen King