nanog mailing list archives

Re: Filtering ICMP (Was Re: SMURF amplifier block list)


From: "Alex P. Rudnev" <alex () Relcom EU net>
Date: Tue, 21 Apr 1998 20:45:58 +0400 (MSD)

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)



Current thread: