[16292] in North American Network Operators' Group
Re: SMURF amplifier block list
daemon@ATHENA.MIT.EDU (Dean Anderson)
Sat Apr 18 15:19:19 1998
In-Reply-To:
<Pine.SUN.3.91.980418224551.14113K-100000@virgin.relcom.eu.net>
Date: Sat, 18 Apr 1998 15:03:29 -0400
To: "Alex P. Rudnev" <alex@Relcom.EU.net>
From: Dean Anderson <dean@av8.com>
Cc: nanog@merit.edu
During an in progress attack, you probably have to take extreme measures,
but they shouldn't be generally applied. No one wants to lose addresses
that *might* be a broadcast address in some possible netmask. /24 is maybe
common, but is not the only netmask. And the people who don't use it won't
want you to break their customers networks.
--Dean
At 2:51 PM -0400 4/18/98, Alex P. Rudnev wrote:
>I am talking about boths blocking exterior smurfers from usage your
>networks as amplifier, and blocking your smurfers from sending such
>packets by your network. Second task allow you to cutch any smurfer in
>your own network in a 5 minutes.
>
>Just now the only thing big ISP can do in case of SMURF is to block
>ECHO_REPLY packets to some attacked networks; it results from preventing
>any PING tests from this networks. Why don't sacrify some addresses
>(*.255, really) from be pinged at all, but save your from be the source
>or amplifier of the SMURF?
>
>And then, if you should not block by 'log' such packets you'll have the
>log records about your own smurfers withouth loosing any ICMP
>capabilities at all.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Plain Aviation, Inc dean@av8.com
LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com
We Make IT Fly! (617)242-3091 x246
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
