Home page logo
/

nanog logo nanog mailing list archives

Re: Filtering ICMP (Was Re: SMURF amplifier block list)
From: Marc Slemko <marcs () znep com>
Date: Mon, 20 Apr 1998 14:31:15 -0600 (MDT)

On Mon, 20 Apr 1998, Mark Whitis wrote:

On Sun, 19 Apr 1998 jlixfeld () idirect ca wrote:
You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on

Using "deny icmp" as anything other than an extremely temporary measure
while you (or your customers) are actively under DoS attack and focused
only on the affected hosts/nets (the systems under attack and/or the smurf
amplifiers if it is a smurf attack) is downright irresponsible.  Even
then, it will cause problems but they may be less than those caused by the
DoS attack.  Most ICMP traffic is necessary to the correct operation of
the net.

Filtering ICMP not only breaks ping, it breaks path mtu discovery which
can cause much grief which is hard for the people affected to diagnose.

Agreed.  It is amazing how clueless so many people are about this problem,
even major backbone providers that just don't seem to be able to
understand it.  http://www.worldgate.com/~marcs/mtu/ for newbie-level
details on PMTU-D and why it needs functioning ICMP. 

[...]

This is made much worse by filtering software which does not allow
you to filter specific ICMP types and (unfragmented) packet sizes.
A much better way to handle most of the DoS attacks (except smurf)
is to force fragment reassasembly on a router which is not sucseptible
before forwarding the packets; this puts a significant load on the
router so it is best done on a router/firewall close to the
systems being protected (which is also desireable because it
gives more protection).

If it reassembles fragments then it isn't a router.



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]