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. Rudnevdeny 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:
- Re: SMURF amplifier block list, (continued)
- Re: SMURF amplifier block list Pete Ashdown (Apr 20)
- Re: SMURF amplifier block list Jason Lixfeld (Apr 24)
- Filtering ICMP (Was Re: SMURF amplifier block list) Mark Whitis (Apr 20)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Marc Slemko (Apr 20)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Michael Dillon (Apr 20)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Mark Whitis (Apr 22)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Michael Dillon (Apr 20)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Michael Shields (Apr 22)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Alex P. Rudnev (Apr 21)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) D'Arcy J.M. Cain (Apr 22)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Alex P. Rudnev (Apr 21)
- Message not available
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Eric Germann (Apr 21)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Jason Lixfeld (Apr 24)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Pete Ashdown (Apr 24)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Richard Irving (Apr 24)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Brandon Ross (Apr 26)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Michael Dillon (Apr 24)
- Re: Filtering ICMP (Was Re: SMURF amplifier block list) Mark Whitis (Apr 26)
- Re: SMURF amplifier block list Dean Anderson (Apr 18)
- Re: SMURF amplifier block list Phil Howard (Apr 18)
- Message not available
- Re: SMURF amplifier block list Jay R. Ashworth (Apr 19)