Router 2wire, Slackware desktop in DMZ mode, iptables policy aginst ping, but still pingable
- by user135501
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
