spa*_*17X 3 iptables iptables-persistent
我有以下设置:/etc/iptables/rules.v4
# Generated by iptables-save v1.4.21 on Mon Jul 1 11:32:00 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3:620]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.35.107/32 -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -s 192.168.35.0/24 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -s 192.168.35.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Mon Jul 1 11:32:00 2019
Run Code Online (Sandbox Code Playgroud)
从上面我们看到我想阻止来自特定 IP 的 ping。在我使用 保存规则并iptables-restore < /etc/iptables/rules.v4
使用 列出规则后iptables -L
,我可以得出结论,IP 为 192.168.35.107 的计算机无法 ping 服务器。
但是,具有该 IP 的计算机能够无限期地执行 ping 操作,直到我中断会话。即使在我中断 ping 之后,我仍然需要暂停约 60 秒,直到我无法再次 ping。如果我在 ping 命令之间暂停 5-10 秒,防火墙就会让我通过。
有趣的是,当我通过 iptables 启用 ping 时,它会立即起作用。我也尝试过 Samba 端口 445。相同的。
有没有办法让 iptables 丢弃的端口立即生效?
您遇到这种行为是因为您的系统启用了 netfilter 的连接跟踪系统(nf_conntrack*
模块系列),并且您的--state RELATED,ESTABLISHED
规则(显然设置为ACCEPT
)被放置在 ping 的特定DROP
规则之前。
这些-m state
规则以及更细粒度的-m conntrack
规则依赖于连接跟踪系统,该系统还跟踪 UDP 和 ICMP 等协议,即使这些协议在技术上不是面向连接的。它通过在其列表中构建具有默认到期超时的“连接”条目来跟踪这些协议。这些默认值可以通过 下的特定文件(/proc/sys/net/netfilter/
通常是名为nf_conntrack_*_timeout
.
由于 ICMP 是一种无连接协议,连接跟踪系统无法检测任何此类“连接”何时真正完成,因此只能依赖超时驱动的启发式方法。因此,只要连接跟踪列表中存在与您的源 ip/目标 ip icmp“对话”匹配的条目,任何-m state --state ESTABLISHED
规则都将匹配该流量,在您的情况下根据您的特定规则接受它。
您注意到的“~60 秒”超时实际上应该是 30 秒,因为这通常是/proc/sys/net/netfilter/nf_conntrack_icmp_timeout
. echo
然而,它可能已经通过仅在该文件中输入不同的值而被更改。
另请注意,这些文件中的值适用于从那时起的新“连接”。要查看连接跟踪系统已知的当前条目及其当前到期超时,您可以使用conntrack
可能需要安装的命令。使用该命令您还可以修改或删除条目。
\n\n\n有没有办法让 iptables 丢弃的端口立即生效?
\n
最简单的方法是始终将DROP
规则放在-m state
\xc2\xa0ACCEPT 规则之前。
一种替代方法可能是:每次添加DROP
规则时,还运行相应的conntrack
命令来删除当前活动的条目。
归档时间: |
|
查看次数: |
3188 次 |
最近记录: |