使用 iptables 在网络服务器上丢弃 ACK FIN、ACK RST、RST 数据包

Question

我在 Debian 7 机器上运行网络服务器 (Apache)，并在同一台机器上运行 iptables。iptables 规则由 ConfigServer Firewall (CSF) 脚本生成。那里托管的网站对我来说没有问题，但是我看到端口 80 上的入站流量大量下降。

以下是日志的摘录（网络服务器 IP：11.22.33.44）：

Jan 27 15:21:36 [hostname] kernel: [1229124.817624] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3144 DF PROTO=TCP SPT=36879 DPT=80 WINDOW=510 RES=0x00 ACK FIN URGP=0
Jan 27 15:21:36 [hostname] kernel: [1229124.872795] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=199.30.24.209 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=3183 DF PROTO=TCP SPT=36684 DPT=80 WINDOW=513 RES=0x00 ACK FIN URGP=0
Jan 27 16:03:36 [hostname] kernel: [1231642.223513] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=19101 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK FIN URGP=0
Jan 27 16:03:41 [hostname] kernel: [1231647.015463] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=26215 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=508 RES=0x00 ACK RST URGP=0
Jan 27 16:03:51 [hostname] kernel: [1231656.677627] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=5.39.50.0 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=122 ID=10630 DF PROTO=TCP SPT=51394 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0
Jan 27 16:04:42 [hostname] kernel: [1231707.911962] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3513 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Jan 27 16:04:42 [hostname] kernel: [1231707.911976] Firewall: *TCP_IN Blocked* IN=venet0 OUT= MAC= SRC=86.217.34.8 DST=11.22.33.44 LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3514 DF PROTO=TCP SPT=54465 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

数百行这样的东西。没有特定的计时模式，并且随机客户端会发生丢弃。

但这些丢弃的数据包始终标记为 ACK FIN、RST、ACK RST，很少标记为 SYN。我知道这些是“确认传输和结束连接”数据包。

相关iptables规则：

Chain INPUT (policy DROP)
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:80
LOGDROPIN  all  --  anywhere             anywhere

Chain LOGDROPIN (1 references)
LOG        tcp  --  anywhere             anywhere             limit: avg 30/min burst 5 LOG level warning prefix "Firewall: *TCP_IN Blocked* "
DROP       all  --  anywhere             anywhere

因此，从表面上看，这些数据包正在被丢弃，因为它们相应的连接不再打开，即“相关”或“已建立”。这意味着传输成功，并且服务器在客户端有时间确认收到的数据之前关闭连接，从而使连接（可能还有 HTTP 请求？）挂在客户端。

我真的很好奇这可能是什么原因造成的。我还想知道客户是否受到影响，因为我似乎无法复制这个问题。希望大家能够帮助我理解！

感谢您的阅读=）

编辑：好的，我去钓鱼并对 [ACK,FIN] 数据包被丢弃的这些情况之一进行了数据包跟踪（遵循下面我的评论中描述的方法）。最后三个数据包是被防火墙丢弃的数据包：

Source                Destination           Protocol Length Info                                                                            Time
[CLIENT COMP]         [WEBSERVER]           TCP      68     55478 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1400 WS=4 SACK_PERM=1               2014-01-29 20:44:36.044009
[WEBSERVER]           [CLIENT COMP]         TCP      68     http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:36.044052
[WEBSERVER]           [CLIENT COMP]         TCP      68     http > 55478 [SYN, ACK] Seq=0 Ack=1 Win=14600 Len=0 MSS=1460 SACK_PERM=1 WS=512 2014-01-29 20:44:37.243948
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=1 Ack=1 Win=16800 Len=0                                  2014-01-29 20:44:37.421123
[CLIENT COMP]         [WEBSERVER]           HTTP     464    GET /sites/default/files/js/js_R9UbiVw2xuTUI0GZoaqMDOdX0lrZt....js HTTP/1.1     2014-01-29 20:44:37.432097
[WEBSERVER]           [CLIENT COMP]         TCP      56     http > 55478 [ACK] Seq=1 Ack=409 Win=15872 Len=0                                2014-01-29 20:44:37.432122
[WEBSERVER]           [CLIENT COMP]         HTTP     963    HTTP/1.1 200 OK  (text/javascript)                                              2014-01-29 20:44:37.432703
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=409 Ack=908 Win=15892 Len=0                              2014-01-29 20:44:37.769928
[WEBSERVER]           [CLIENT COMP]         TCP      56     http > 55478 [FIN, ACK] Seq=908 Ack=409 Win=15872 Len=0                         2014-01-29 20:44:42.437129
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [ACK] Seq=409 Ack=909 Win=15892 Len=0                              2014-01-29 20:44:42.580378
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:44.668730
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:49.194316
[CLIENT COMP]         [WEBSERVER]           TCP      56     55478 > http [FIN, ACK] Seq=409 Ack=909 Win=15892 Len=0                         2014-01-29 20:49:58.869659

根据这个：

1. 服务器发送 HTTP 200 OK 响应
2. 希望关闭连接。它向客户端发送一个 [FIN, ACK] 数据包，因为我猜测它正在尝试关闭同时连接。
3. 客户端用 [ACK] 响应服务器的 [FIN, ACK]（Seq/Ack 编号的顺序正确），但没有 [FIN]，根据规范，这意味着连接只是半关闭的。
4. 但是，5 分钟后，客户端发送了一个 [FIN，ACK]，这是不寻常的，因为它已经向服务器的“连接结束”发送了一个 ACK​​。我猜测涉及某种形式的 TCP 超时，并且客户端只是尝试关闭保持打开状态的连接。

很明显，连接终止握手没有按正确的顺序发生。看起来问题出在客户端，客户端直到 5 分钟超时才关闭连接。

我注意到三件事：

• 这个特定的客户端正在运行现代浏览器，因此浏览器不是问题。
• 他/她正在发送/接收大量 TCP 重传，表明连接有损。事实证明，这个家伙是从摩洛哥通过 3G 连接的，所以它确实加起来了^^。
• 最后，Apache 日志显示他确实获得了正确的 HTTP 响应，因此站点流量没有受到“问题”的影响。

有趣的东西。有的话就拍吧！

Answer 1

根据netfilter上的邮件链，这似乎是iptables的正常功能。如果您不想在日志中收到这些消息，您可以尝试添加INVALID到端口 80 上接受的状态列表，看看该问题是否消失。

否则，除了烦人和日志填充之外，它是无害的流量，您的客户不会遇到任何问题。