我处于 DMZ 模式,因此我自己设置了防火墙,隐身一切正常,但是我从 Shields Up 获得了错误的测试结果,表明有 ping。
昨天我无法连接到游戏服务器,因为启用了 ping 阻止(在路由器上)。我禁用了它,但由于我的防火墙,这种情况仍然存在。在 DMZ 模式下,我和路由器之间的连接是什么(对于我的机器,路由器防火墙后面还有许多其他机器)?当它允许路由器影响我是否可以 ping 以及路由器是否设置了不阻止 ping 时,我的 iptables 中针对这种情况的规则不起作用。请忽略注释规则,我会根据需要取消注释它们。
这两位应该可以胜任这个工作吧?
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
这是我的 iptables:
#!/bin/sh
# Begin /bin/firewall-start
# Insert connection-tracking modules (not needed if built into the kernel).
#modprobe ip_tables
#modprobe iptable_filter
#modprobe ip_conntrack
#modprobe ip_conntrack_ftp
#modprobe ipt_state
#modprobe ipt_LOG
# allow local-only connections
iptables -A INPUT -i lo -j ACCEPT
# free output on any interface to any ip for any service
# (equal to -P ACCEPT)
iptables -A OUTPUT -j ACCEPT
# permit answers on already established connections
# and permit new connections related to established ones (eg active-ftp)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#Gamespy&NWN
#iptables -A INPUT -p tcp -m tcp -m multiport --ports 5120:5129 -j ACCEPT
#iptables -A INPUT -p tcp -m tcp --dport 6667 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
#iptables -A INPUT -p tcp -m tcp --dport 28910 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
#iptables -A INPUT -p tcp -m tcp --dport 29900 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
#iptables -A INPUT -p tcp -m tcp --dport 29901 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
#iptables -A INPUT -p tcp -m tcp --dport 29920 --tcp-flags SYN,RST,ACK SYN -j ACCEPT
#iptables -A INPUT -p udp -m udp -m multiport --ports 5120:5129 -j ACCEPT
#iptables -A INPUT -p udp -m udp --dport 6500 -j ACCEPT
#iptables -A INPUT -p udp -m udp --dport 27900 -j ACCEPT
#iptables -A INPUT -p udp -m udp --dport 27901 -j ACCEPT
#iptables -A INPUT -p udp -m udp --dport 29910 -j ACCEPT
# Log everything else: What's Windows' latest exploitable vulnerability?
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT"
# set a sane policy: everything not accepted > /dev/null
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
# be verbose on dynamic ip-addresses (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr
# disable ExplicitCongestionNotification - too many routers are still
# ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn
#ping death
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# If you are frequently accessing ftp-servers or enjoy chatting you might
# notice certain delays because some implementations of these daemons have
# the feature of querying an identd on your box for your username for
# logging. Although there's really no harm in this, having an identd
# running is not recommended because some implementations are known to be
# vulnerable.
# To avoid these delays you could reject the requests with a 'tcp-reset':
#iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset
#iptables -A OUTPUT -p tcp --sport 113 -m state --state RELATED -j ACCEPT
# To log and drop invalid packets, mostly harmless packets that came in
# after netfilter's timeout, sometimes scans:
#iptables -I INPUT 1 -p tcp -m state --state INVALID -j LOG --log-prefix \ "FIREWALL:INVALID"
#iptables -I INPUT 2 -p tcp -m state --state INVALID -j DROP
# End /bin/firewall-start
活动规则集:
bash-4.1# iptables -L -n -v
Chain INPUT (policy DROP 38 packets, 2228 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
844 542K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
38 2228 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FIREWALL:INPUT'
0 0 ACCEPT all -- lo * 0.0.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
38 2228 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FIREWALL:INPUT'
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1158 111K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
活动规则集:(将 iptables 编辑为以下建议的形式后)
bash-4.1# iptables -L -n -v
Chain INPUT (policy DROP 2567 packets, 172K bytes)
pkts bytes target prot opt in out source destination
49 4157 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
412K 441M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2567 172K LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FIREWALL:INPUT'
0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 312K packets, 25M bytes)
pkts bytes target prot opt in out source destination
从手机 (pinger) 和笔记本电脑 (被 ping) 同时截取 ping 和 syslog 屏幕截图
http://dl.dropbox.com/u/4160051/slckwr/pingfrom%20mobile.jpg
答案1
这里有些奇怪。根据你的脚本,你应该有一个规则
0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
但它没有显示在iptables -nvL
输出中。相反,您有两次环回、ESTABLISHED、RELATED 和 LOG 规则。看起来几乎有部分脚本从未执行过。以下命令的输出是什么?
cat /proc/sys/net/ipv4/icmp_echo_ignore_all
顺便说一句,脚本中的命令顺序有点……不合常规。通常,人们会先设置内核参数,然后设置默认策略,然后刷新链以删除所有先前的条目(您根本不会这样做),然后再(重新)创建规则集。当您将链设置OUTPUT
为ACCEPT
任何内容时,您也可以将该链的默认策略设置为ACCEPT
。它具有相同的效果,同时不那么令人困惑。
echo 2 > /proc/sys/net/ipv4/ip_dynaddr
echo 0 > /proc/sys/net/ipv4/tcp_ecn
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -X # delete user-defined chains
iptables -F # flush chains
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT"
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
FTR:“隐身”完全是胡说八道。这个词是由那些完全不了解 TCP/IP 工作原理或故意误导同行的人创造的。对 ICMP 回显请求缺乏响应确实不是意味着主机不存在(或“不可见”或其他原因)。这意味着路由中的某个设备正在丢弃 ICMP 数据包。仅此而已。如果主机确实不存在,则最后一个路由器前该主机将以destination-unreachable
ICMP 数据包进行响应。
编辑:
仔细查看您的屏幕截图后发现:netfilter
正在记录 TCP 数据包,而不是 ICMP 数据包。尝试tcpdump -n icmp
在您的主机上运行,看看是否同时记录了echo request
和 echo reply
ping 主机时发送的数据包。