ルーター2ワイヤ、DMZモードのSlackwareデスクトップ、iptablesポリシーaginst ping、しかしまだping可能

私はDMZモードになっているので、自分でファイアウォールを設定しています。ステルスは問題ありませんが、Shields Upからpingがあるという誤ったテスト結果が出ます。

昨日、pingブロックが有効化されていたため（ルーターで）、ゲームサーバーへの接続を確立できませんでした。私はそれを無効にしましたが、これは私のファイアウォールが原因でも持続します。私とDMZモードのルーターとの接続はどうなっていますか（私のマシンには、ルーターファイアウォールの背後にもたくさんあります）？pingが可能かどうかに影響を与えるルーターを許可し、ルーターにpingをブロックしない設定がある場合、このシナリオのiptablesのルールは機能しません。コメント化されたルールは無視してください。必要に応じてコメントを外します。

これら2つは仕事を正しくする必要がありますか？

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

http://dl.dropbox.com/u/4160051/slckwr/tailsyslog.jpg

ここで何かがおかしい。スクリプトによると、ルールが必要です

0   0 DROP    icmp --  *    *     0.0.0.0/0     0.0.0.0/0      icmptype 8

しかし、iptables -nvL出力には表示されません。代わりに、ループバック、ESTABLISHED、RELATED、およびLOGルールが2回あります。スクリプトの一部が実行されないように見えます。次のコマンドの出力は何ですか？

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-unreachableICMPパケットで応答します。

編集：

スクリーンショットを詳しく見ると、netfilterICMPパケットではなく、TCPパケットがログに記録されています。tcpdump -n icmpホストで実行してみて、ホストにping echo request を echo reply送信するときにパケットとパケットの両方が記録されるかどうかを確認してください。