Roteador 2wire, área de trabalho do Slackware no modo DMZ, diretiva do iptables, ping de aginst, mas ainda pingável

Question

Eu estou no modo DMZ, então estou me protegendo, furtivo, tudo bem, mas recebo resultados de teste defeituosos do Shields Up que há pings.

Ontem eu não consegui fazer uma conexão com servidores de jogos funcionar, porque o bloco de ping estava habilitado (no roteador). Eu desativei, mas isso persiste até mesmo devido ao meu firewall. Qual é a conexão entre mim e meu roteador no modo DMZ (para minha máquina, há muitos outros também por trás do firewall do roteador)? Quando ele permite que o roteador afete se eu sou pingável ou não, e se o roteador tiver configurações que não bloqueiam o ping, as regras do meu iptables para esse cenário não funcionam. Por favor, ignore as regras comentadas, eu descomente-as como eu quero.

Estes dois devem fazer o trabalho certo?

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

Aqui estão os meus 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

Conjunto de regras ativo:

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   

Conjunto de regras ativo: (depois de editar o iptables no formulário abaixo sugerido)

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 

Ping e syslog screenshots simultâneos do telefone (pinger) e do laptop (sendo pingado)

link

link

    

Answer 1

Algo é estranho aqui. De acordo com o seu roteiro, você deve ter uma regra

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

mas não aparece na saída iptables -nvL . Em vez disso, você tem as regras de loopback, ESTABLISHED, RELATED e LOG duas vezes. Parece quase como parte do script nunca é executado. Qual é a saída do seguinte comando?

cat /proc/sys/net/ipv4/icmp_echo_ignore_all

BTW, a ordem dos comandos no seu script é um pouco ... não ortodoxa. Normalmente, um colocaria os parâmetros do kernel primeiro, depois definiria as políticas padrão, depois liberaria as cadeias para remover todas as entradas anteriores (que você não faz nada) antes de (re) criar o conjunto de regras. E quando você define a OUTPUT chain como ACCEPT , você pode também definir a política padrão dessa cadeia como ACCEPT . Tem o mesmo efeito, sendo menos confuso.

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

E FTR: "Stealth" é um absurdo total. Um termo cunhado por pessoas que não conseguiram entender como o TCP / IP funciona ou deliberadamente desorientaram seus colegas. A falta de resposta a solicitações de eco ICMP não significa que um host não exista (ou seja, "invisível" ou algo assim). Isso significa que algum dispositivo em rota está descartando pacotes ICMP. Nada mais nada menos. Se um host realmente não existir, o último roteador antes desse host responderá com um pacote destination-unreachable ICMP.

Editar:

Depois de olhar mais de perto suas capturas de tela: netfilter está registrando pacotes TCP, não pacotes ICMP. Tente executar tcpdump -n icmp no seu host e ver se isso registra os pacotes echo request echo reply quando você faz ping no host.