Firewall stateful handling of ICMP packets

Jamie Reid Jamie.Reid at
Thu Dec 4 03:09:57 UTC 2003

Personal view: 

This was a problem when filtering Nachi while it pinged networks
to their knees. 

Sometimes I wonder if there is any legitimate reason to allow 
pings from users at all. If the user really needed to use
ping, that is, if they were in a position to do anything about the
results of the ping tests, then they would know enough to 
use traceroute in UDP mode or some other tool. 

There are lots of other useful ICMP types to handle all
the other ICMP needs, but ping seems to be something
that was created for the convenience of a kind of user
that is effectively extinct in todays Internet.  

ICMP echo is unique among ICMP types in that it is the
only one that elicits it's own response. What I mean by
this is that source-quench, <foo>-unreachables, and others
are all generated by hosts and routers in response to 
relatively stateful traffic. There is nothing that echos
do that SNMP (I know, I know) and traceroute don't
accomplish in a more controlled fashion, no? 

It would kill alot of DDoS attacks and render their zombie 
networks useless, retire legacy backdoors and viruses, up 
the ante for network management tools, and slow down
some virus propagation substantially. 

ICMP echos are a bit of a hack and, quite literally, noise, 
and I wonder if it may be time to consider unofficially 
retiring them using filters. 


Jamie.Reid, CISSP, jamie.reid at
Senior Security Specialist, Information Protection Centre 
Corporate Security, MBS  
416 327 2324 
>>> "Sean Donelan" <sean at> 12/03/03 05:12pm >>>

You could drop ICMP packets at your firewall if the firewalls properly
implemented stateful inspection of ICMP packets.  The problem is few
firewalls include ICMP responses in their statefull analysis.  So you are
left with two bad choices, permit "all" ICMP packets or deny "all" ICMP
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TEXT.htm
URL: <>

More information about the NANOG mailing list