☰

iptables 在端口 80 上丢弃了一些数据包，但我不知道原因

tag-icon • tag-icon iptables
iptables 在端口 80 上丢弃了一些数据包，但我不知道原因

我们在 Debian Lenny 系统上运行了带有 iptables 的防火墙。我仅向您展示了防火墙的相关条目。

Chain INPUT (policy DROP 0 packets, 0 bytes)
target  prot opt in out  source     destination         
ACCEPT  all  --  lo *    0.0.0.0/0  0.0.0.0/0
ACCEPT  all  --  *  *    0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED
ACCEPT  tcp  --  *  *    0.0.0.0/0  0.0.0.0/0  tcp dpt:80 state NEW

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
target  prot opt in out  source     destination
ACCEPT  all  --  *  lo   0.0.0.0/0  0.0.0.0/0           
ACCEPT  all  --  *  *    0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED 
LOGDROP all  --  *  *    0.0.0.0/0  0.0.0.0/0

每天都会有一些数据包被丢弃，并出现如下日志消息：

2 月 5 日 15:11:02 host1 内核：[104332.409003] 丢弃 IN= OUT=eth0 SRC=<OWN_IP> DST=<REMOTE_IP> LEN=1420 TOS=0x00 PREC=0x00 TTL=64 ID=18576 DF PROTO=TCP SPT=80 DPT=59327 WINDOW=54 RES=0x00 ACK URGP=0

出于隐私原因，我用 <OWN_IP> 和 <REMOTE_IP> 替换了 IP 地址

这没什么好担心的，我只是想了解发生了什么。Web 服务器尝试向客户端发送一个数据包，但防火墙不知何故得出结论，认为该数据包与任何先前的流量“无关”。

我已经将内核参数 ip_conntrack_ma 设置为足够高的值，以确保 iptables 状态模块跟踪所有连接：

sysctl -w net.ipv4.netfilter.ip_conntrack_max=524288

有趣的是，我每 20 分钟就会断开一次连接：

06:34:54
06:52:10 
07:10:48 
07:30:55 
07:51:29 
08:10:47 
08:31:00 
08:50:52
09:10:50
09:30:52 
09:50:49 
10:11:00 
10:30:50 
10:50:56 
11:10:53 
11:31:00 
11:50:49 
12:10:49 
12:30:50 
12:50:51 
13:10:49 
13:30:57 
13:51:01 
14:11:12
14:31:32 
14:50:59 
15:11:02

这是今天的情况，但在其他日子也看起来像这样（有时比率会有所不同）。

可能是什么原因呢？

非常感谢您的帮助。 问候 Janning

答案1

我在自己的系统上看到了非常类似的问题，并且我可能知道发生了什么。

显然，TCP 允许客户端发送 FIN 数据包，并允许您确认该 FIN 数据包，但仍保持您这端的连接打开并通过它推送更多数据，并在将来的某个时间发送您自己的 FIN 数据包。我记得读到过这是在内核 2.6 中的某个时刻实现的，尽管我对这一点的记忆可能不准确/不相关。

许多防火墙（包括 IPTables）似乎尚未实现此功能或错误地实现了此功能，只要看到 FIN 后跟 ACK，就会认为连接已关闭。结果就是，我的服务器时不时会向客户端发送一个数据包，而防火墙认为该数据包不是已建立连接的一部分，也不是新数据包，因此会将其丢弃。

实际上，我没有在最后丢弃的几个数据包中看到任何重要数据，因此其效果是一些额外的重置数据包被丢弃，一些额外的连接处于 FIN_WAIT 状态，但没有损坏或半加载的页面。

我不知道您看到的 20 分钟计时，但我猜测它是某种客户端，每 20 分钟定期运行一次，并发出请求，导致您的服务器执行 FIN ACK PSH FIN RST 序列。

这篇文章可能会提供有关 IPTables 丢弃这些数据包的具体原因的更多信息：http://lists.netfilter.org/pipermail/netfilter/2005-August/062059.html

按照 Chris Brenton 的说法，这是由于客户端、服务器和防火墙在单侧关闭状态下对数据包的超时不匹配造成的。

答案2

原始/源 IP 是否显示在日志输出中？如果是，该 IP 是否在 http 日志中显示任何有效请求？也许某种监控系统正在检查您服务器上的 http，因为您说它是以一致的间隔进行的。只是随便说说而已。

答案3

如果有人试图通过发送 ACK 数据包来扫描您，并且您的防火墙需要 STATE（已建立的连接），它将被丢弃。

无状态防火墙仅丢弃传入的 SYN 数据包并让 ACK 通过。这意味着即使端口被阻止，您也可以在防火墙后面进行扫描。如何扫描？由于无法识别 ACK，系统将正常运行并发送 RST（RESET）数据包，告诉您我们没有连接。您现在知道有东西正在监听该端口。

查看您提供的信息，确实有一个 ACK​​ 数据包被丢弃。

您可以使用以下方法确认nmap（从外部系统）：
nmap -sA -p80 your_ip

答案4

我不明白的是：为什么 iptables 日志消息会显示数据包被丢弃，而传出，而后一个日志显示数据包丢失进入？

我怀疑你可能有两个不同的问题。也许有人试图欺骗你的地址，因此 iptables 捕获了与（欺骗地址）无关的回复并将其丢弃。这将覆盖传出的丢弃。

关于传入丢包，20 分钟的时间间隔很可疑。也许是 ARP？某种 DHCP 身份验证。20 分钟是 1200 秒；也许有 3 个单独的链正在进行，每个链加起来为 3600（默认 DHCP 租约时间），但您只能看到单个数据包。只是一个提示。

相关内容