Маршрутизатор 2wire, рабочий стол Slackware в режиме DMZ, политика iptables agingst ping, но все еще pingable

Question

Я нахожусь в режиме DMZ, так что я сам брандмауэр, скрытно все в порядке, но я получаю ошибочные результаты теста от Shields Up, что есть пинги.

Вчера я не смог установить соединение с игровыми серверами, потому что был включен блок ping (на роутере). Я отключил его, но это сохраняется даже из-за моего брандмауэра. Какая связь между мной и моим маршрутизатором в режиме DMZ (для моей машины за брандмауэром маршрутизатора тоже есть куча других)? Когда это позволяет маршрутизатору влиять на то, могу ли я пинговать или нет, и если у маршрутизатора есть настройка, не блокирующая пинг, правила в моих 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 

пинг и syslog одновременные скриншоты с телефона (пингер) и с ноутбука (пингуются)

http://dl.dropbox.com/u/4160051/slckwr/pingfrom%20mobile.jpg

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

Answer 1

Здесь что-то странное. Согласно вашему сценарию у вас должно быть правило

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

но он не отображается в iptables -nvL . Вместо этого у вас есть правила loopback, 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-пакеты. Ни больше ни меньше. Если хост действительно не существует, последний маршрутизатор перед этим хостом ответит ICMP-пакетом, destination-unreachable для получателя .

Редактировать:

После более внимательного изучения снимков экрана: netfilter регистрирует TCP-пакеты, а не ICMP-пакеты. Попробуйте запустить tcpdump -n icmp на вашем хосте и посмотрите, записывает ли он пакеты echo request и echo reply при пинге хоста.