我有一个小型 VPS，具有以下 IPTables 规则：
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:f2b-ssh - [0:0]
:f2b-sshd - [0:0]
# Allow incoming SSH.
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED --sport 22 -j ACCEPT
# Allow outgoing SSH to port 22.
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 22 -j ACCEPT
# Allow all response packets.
# Accept forwarding of all response packets.
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Special rule for logging weird outgoing SSH packets <---- HERE
-A OUTPUT -p tcp --sport 22 -m limit --limit 3/min -j LOG --log-prefix "[SSH_OUTPUT_debug]: " --log-level 7
# Reject any packets which don't fit the rules above...
-A INPUT -j REJECT
-A FORWARD -j REJECT
-A OUTPUT -j REJECT
-A f2b-ssh -j RETURN
-A f2b-sshd -j RETURN
COMMIT
时不时地，我的日志中会出现一些奇怪的传出 SSH 数据包，我不知道它们来自哪里。我不认为它们只是对 ssh 连接尝试的尝试响应，因为我一周只记录了大约十几个这样的数据包（而我每月会收到数千次 ssh 登录尝试）。
它们也不只是我定期进行的传出 ssh 尝试：我进行的任何传出 ssh 连接都工作正常，并且不会在我的记录中记录；此外，我从未尝试连接这些 IP（因为它们不属于我）。
到目前为止，我没有理由怀疑我的 VPS 已被入侵（我只使用 ssh 密钥身份验证）。这些奇怪的 TCP 数据包出现在我的日志中的原因是什么？我的服务器被入侵了吗？我对规则的理解有误吗？或者这些是来自外部的某种欺骗数据包？
[SSH_OUTPUT_debug]: IN= OUT=eth0 SRC=my.vps.ip.x DST=175.139.201.77 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=60227 DF PROTO=TCP SPT=22 DPT=39829 WINDOW=227 RES=0x00 ACK FIN URGP=0
[SSH_OUTPUT_debug]: IN= OUT=eth0 SRC=my.vps.ip.x DST=203.106.103.129 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=23755 DF PROTO=TCP SPT=22 DPT=58792 WINDOW=227 RES=0x00 ACK FIN URGP=0
[SSH_OUTPUT_debug]: IN= OUT=eth0 SRC=my.vps.ip.x DST=121.46.27.10 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=54345 DF PROTO=TCP SPT=22 DPT=51662 WINDOW=227 RES=0x00 ACK FIN URGP=0
[SSH_OUTPUT_debug]: IN= OUT=eth0 SRC=my.vps.ip.x DST=114.116.143.41 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=46056 WINDOW=28960 RES=0x00 ACK SYN URGP=0
[SSH_OUTPUT_debug]: IN= OUT=eth0 SRC=my.vps.ip.x DST=103.231.4.198 LEN=81 TOS=0x00 PREC=0x00 TTL=64 ID=55949 DF PROTO=TCP SPT=22 DPT=59049 WINDOW=229 RES=0x00 ACK PSH URGP=0
[SSH_OUTPUT_debug]: IN= OUT=eth0 SRC=my.vps.ip.x DST=86.21.205.149 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=42840 DF PROTO=TCP SPT=22 DPT=36050 WINDOW=0 RES=0x00 RST URGP=0
答案1
半开连接将在 conntrack 中单方面超时（假定已关闭），它不会等待超时。如果超时时间过长，相关数据包将不再被识别为相关数据包，并会像您看到的那样被标记。这是一个已知问题，下面有一些讨论：
https://bugzilla.redhat.com/show_bug.cgi?id=1215927
https://lists.netfilter.org/pipermail/netfilter/2005-August/062059.html
答案2
我注意到它们都是 FIN。我敢打赌，这是因为 iptables 和 TCP 堆栈对正在关闭的连接的状态有不同的看法。
也许 TCP 堆栈已将 FIN 排队，但在发送之前，远端已收到 RST。因此，现在由于 RST，iptables 不再认为连接已建立，因此会记录 FIN。
对其中一个会话进行完整的数据包捕获可能会准确地揭示出正在发生的事情。