Filtering ICMP (Was Re: SMURF amplifier block list)

Alex P. Rudnev alex at
Tue Apr 21 16:45:58 UTC 1998

1) Traceroute is not affected by this filter;
2) ICMP is really blocked at many different places of Internet; we answer 
every day _no matter you can't ping, it's becuase they refuse 
PING's to their network_. 
3) Please, found any sugnificant host at *.255 address.

No doubt this is not 100% correct method; but it's worst to allow 
smurfers to send their packets withouth any punishment.

> Thus spake Alex P. Rudnev
> >  deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-request log
> > 
> > to prevent smurf originating, or
> > 
> >  deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-reply
> > 
> > to prevent smurf flooding into your network.
> > 
> > No important ICMP are affected this case.
> Depends what you (or your users) consider important.  Consider that
> users think that they understand networking because they know how
> to ping or traceroute and your support lines will be busy explaining
> that you aren't really down just because they can't traceroute to you.
> We have a little script that looks at network usage and when it sees
> a spike in traffic it temporarily blocks echo-reply in.  It isn't
It's good way to prevent SMURF attack against your customers; we have 
SMURF detecting (at the same principle) and I though abiut such 
auto-blocking. Not bad idea.

But the real question is _how to trace smurfers at 50% cases at least_, 
not how to prevent existing attack from been successfull... Last task is 
solved a lot of times, but what's about the first one?

> perfect but it helps.  We know what our normal traffic is and when
> it goes much higher we kick the filter into place.  If the script
> makes a mistake and blocks when it isn't really an attack then we
> haven't actually cut anyone off but we don't flood our downstreams
> when there is an actual attack.
> -- 
> D'Arcy J.M. Cain <[email protected]{druid|vex}.net>   |  Democracy is three wolves
>                |  and a sheep voting on
> +1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

More information about the NANOG mailing list