Here is what I have been using for years :
$ACCEPTIPS is extern ip 192.168.100.138 is LAN Last lines are for traceroutes to work correctly. Default is deny all. ## block icmp types ports , accept others ## incoming BLOCKTYPES="13" for port in $BLOCKTYPES do $IPTABLES -A INPUT -d $ACCEPTIPS -p icmp --icmp-type $port -j DROP $IPTABLES -A INPUT -d 192.168.100.138 -p icmp --icmp-type $port -j DROP done ## outgoing BLOCKTYPES="14" for port in $BLOCKTYPES do $IPTABLES -A OUTPUT -s $ACCEPTIPS -p icmp --icmp-type $port -j DROP $IPTABLES -A OUTPUT -s 192.168.100.138 -p icmp --icmp-type $port -j DROP done $IPTABLES -A INPUT -d $ACCEPTIPS -p icmp -j ACCEPT $IPTABLES -A INPUT -d 192.168.100.138 -p icmp -j ACCEPT $IPTABLES -A INPUT -d $ACCEPTIPS -p udp --dport 33400:33500 -j ACCEPT $IPTABLES -A INPUT -d 192.168.100.138 -p udp --dport 33400:33500 -j ACCEPT On Mon, 19 Mar 2007, Chuck Swiger wrote: > On Mar 18, 2007, at 1:40 PM, Jeffrey Goldberg wrote: >> On Mar 18, 2007, at 12:20 PM, Rob Janssen wrote: >>> This made many block all ICMP packets, of course severely breaking >>> their communications in the process. (usually without noticing it >>> immediately) >> >> I am guilty of this. I just took a default deny approach and applied >> that to ICMP as well as TCP and UDP. > > "default deny" is a fine approach, but using it means that one does > have to figure out which stuff ought to be allowed. Some forms of > ICMP traffic are highly desirable to permit. > >> Because I failed to understand (and I still don't really get it) what >> ICMP packets are for (other than echo), and because I didn't see an >> immediate problems with the blocks, I just stuck with my default deny >> policy for ICMP until this discussion. > > ICMP is used for error reporting, network control (router discovery > and routing redirects), pings, and many other things: > > http://www.faqs.org/rfcs/rfc792.html > >> So thanks to all how have participated in this discussion and helped >> enlighten me. >> >> If, as you say, ICMP is needed for smooth network operation, then a >> default deny policy (which still makes sense) should specifically >> open those up. > > Yes. If you check an earlier message in the thread, I recommended > opening at least ICMP types 0,3,4,8,11,12. > >>> Asides from that, it is indeed quite common to get "administratively >>> blocked" ICMP messages when you run an NTP server. >>> Those are just ignorant users. They have set up an NTP client but >>> have not allowed incoming NTP in their firewall. They don't >>> notice that >>> their clock is not being synced. >> >> Won't such people have a set up where they allow incoming packets >> related to outgoing packets? Doesn't that work well enough for UDP? >> Or is there more that I am failing to understand? > > UDP is a stateless protocol; many firewalls aren't smart enough to > properly allow return traffic for NTP requests back in without being > explicitly configured to pass NTP replies inbound.... > > -- > -Chuck > > _______________________________________________ > timekeepers mailing list > [email protected] > https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers > Louis _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
