Router 2wire, Slackware desktop in DMZ mode, iptables policy aginst ping, but still pingable
Posted
by
skriatok
on Super User
See other posts from Super User
or by skriatok
Published on 2012-09-11T10:41:52Z
Indexed on
2012/09/13
21:40 UTC
Read the original article
Hit count: 295
iptables
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
© Super User or respective owner
