Filtering ICMP (Was Re: SMURF amplifier block list)
Alex P. Rudnev
alex at Relcom.EU.net
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 www.XXX.com, 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 <darcy@{druid|vex}.net> | Democracy is three wolves
> http://www.druid.net/darcy/ | 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