Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm in DMZ mode, so I'm firewalling myself, stealthy all ok, but I get faulty test results from Shields Up that there are pings.

Yesterday I couldn't make a connection to game servers work, because ping block was enabled (on the router). I disabled it, but this persists even due to my firewall. What is the connection between me and my router in DMZ mode (for my machine, there is bunch of others too behind router firewall)? When it allows router affecting if I'm pingable or not and if router has setting not blocking ping, rules in my iptables for this scenario do not work. Please ignore commented rules, I do uncomment them as I want.

These two should do the job right?

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

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

Here are my 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

Active ruleset:

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   

Active ruleset: (after editing iptables into below sugested form)

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 and syslog simultaneous screenshots from phone (pinger) and from laptop (being pinged)

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

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

share|improve this question

migrated from serverfault.com Sep 12 '12 at 21:54

This question came from our site for system and network administrators.

    
Please paste the output of iptables -L -n -v. –  MadHatter Sep 11 '12 at 11:08
    
edited, information added –  skriatok Sep 12 '12 at 18:13

1 Answer 1

Something is strange here. According to your script you should have a rule

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

but it doesn't show in the iptables -nvL output. Instead you have the loopback, ESTABLISHED,RELATED and LOG rules twice. Looks almost like part of the script never gets executed. What is the output of the following command?

cat /proc/sys/net/ipv4/icmp_echo_ignore_all

BTW, the order of the commands in your script is somewhat ... unorthodox. Usually one would put the kernel parameters first, then set the default policies, then flush the chains to remove all previous entries (which you don't do at all) before (re-)creating the ruleset. And when you set the OUTPUT chain to ACCEPT anything, you could just as well set the default policy of that chain to ACCEPT. It has the same effect while being less confusing.

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

And FTR: "Stealth" is utter nonsense. A term coined by people who either entirely failed to understand how TCP/IP works or deliberately misguided their peers. Lack of response to ICMP echo requests does not mean that a host doesn't exist (or is "invisible" or something). It means that some device en route is dropping ICMP packets. Nothing more, nothing less. If a host really doesn't exist, the last router before that host will respond with a destination-unreachable ICMP packet.

Edit:

After taking a closer look at your screenshots: netfilter is logging TCP packets, not ICMP packets. Try running tcpdump -n icmp on your host and see if that records both echo request and echo reply packets when you ping the host.

share|improve this answer
    
cat /proc/sys/net/ipv4/icmp_echo_ignore_all gives output 1, iptables -X INPUT gives me error form your script: iptables invalid argument –  skriatok Sep 13 '12 at 10:59
    
My bad. iptables -X and iptables -F are called without chains. Fixed in my answer. –  Ansgar Wiechers Sep 13 '12 at 11:56
    
Okay! Now it seems my system likes the tidy script of yours more and the iptables -nvL gives output you have been expecting. But haven't solved problem of being pinged. –  skriatok Sep 13 '12 at 12:06
    
Please provide evidence. –  Ansgar Wiechers Sep 13 '12 at 19:07
    
original question edited with all extra info... –  skriatok Sep 13 '12 at 21:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.