关于/var/log/auth.log中preauth日志条目与iptables封禁规则的疑问

嘿，我来帮你逐个理清这些问题：

• 疑问1：auth.log里的preauth条目，是不是说明这些IP没被封禁？
  出现preauth日志不能直接判定封禁失效，但也不是封禁生效的信号。你可以做个简单测试：找一个在你封禁/24段里的IP，尝试SSH连接你的服务器。如果连接直接超时、被拒绝，说明封禁是有效的；如果能进到输入用户名/密码的环节，那大概率是你的iptables规则有问题——比如规则顺序错了（DROP规则放在了允许SSH的规则后面，导致先匹配到允许规则），或者你封禁的IP段和目标IP不匹配，仔细核对下IP段格式哦。

• 疑问2：INPUT链是不是处理SSH连接的正确链？
  完全正确！INPUT链就是用来处理所有发往服务器的入站流量的，SSH连接属于典型的入站请求，所以把封禁规则放在INPUT链是没问题的。这里要特别注意规则顺序：iptables是从上到下匹配规则的，你的DROP规则必须放在允许SSH的规则（比如-A INPUT -p tcp --dport 22 -j ACCEPT）之前，不然允许规则会先被触发，DROP规则就形同虚设了。

• 疑问3：preauth条目是什么？是不是连接刚发起、iptables规则还没生效的阶段？
  刚好反过来！preauth阶段是已经通过iptables流量过滤之后的阶段。当SSH客户端发起连接，首先会经过iptables的检查：如果被DROP，客户端连TCP握手都完成不了，服务器端也不会产生任何日志；只有当流量通过了iptables，SSH服务才会接收连接，进入preauth阶段——这个阶段服务器会和客户端协商SSH版本、交换加密密钥，甚至会提示输入用户名/密码，但还没完成最终的用户认证。所以你看到preauth日志，说明这个IP的流量已经绕过了你的iptables封禁，要么是规则没覆盖到这个IP，要么是规则顺序不对。

另外，你提到了jail.local，如果是用fail2ban来管理封禁的话，可以用fail2ban-client status sshd命令查看当前被封禁的IP列表，确认目标IP是否在里面。还有，手动添加的iptables规则要记得保存（比如Debian/Ubuntu用iptables-save > /etc/iptables/rules.v4），不然服务器重启后规则会丢失。

备注：内容来源于stack exchange，提问作者CvRChameleon