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
