SMURF amplifier block list

Alex P. Rudnev alex at
Sat Apr 18 19:21:02 UTC 1998

> During an in progress attack, you probably have to take extreme measures,
Do you remember - it's not attack against you or attack by some of your 
customer's networks used as amplifier, but the attack initiated from your 
own network. You never note such thing withouth some permanent 

It's why we saw this 100% helpless against the SMURF's.

> 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 at
>            We Make IT Fly!                (617)242-3091 x246
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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