SMURF amplifier block list

Dean Anderson dean at
Mon Apr 20 22:44:38 UTC 1998

This isn't really so surprising, because 0 used to be the broadcast address
before being changed to 255. (~1986 or so, I think, right around the time
4.3 BSD came out if I remember correctly.)  Many systems still respond to 0
as a broadcast address.  Older Sun systems still default the broadcast
address to 0.  It's an anachronism that could be dropped.

But it is interesting that the person would have thought to use it in a
smurf attack...  If they know that much, they really should have known
better than to smurf. I hope they throw the whole bookcase at them...


At 3:02 PM -0400 4/20/98, Brandon Ross wrote:
>On Sun, 19 Apr 1998, Jeremiah Kristal wrote:
>> On Sat, 18 Apr 1998, Alex P. Rudnev wrote:  >
>> I know that this week there was a smurf attack that was tracked to the
>> source.  I'm not sure what will happen to him.  Hopefully someone from the
>> NOC that caught him will let us know.
>That was us, and we do plan on prosecuting.  We're in the process of
>collecting information now.
>Something that happened during this attack should be a great concern to
>all of us.  In addition to the usual broadcast addresses being used as
>amplifiers for this smurf attack, the attacker also used network
>addresses.  It seems that many stacks and routers will respond to a
>packet with a network address in the same way as a broadcast address.
>Luckily Cisco's "no ip directed-broadcast" already took that into account
>and blocks those packets, however, if you don't have a Cisco and are
>having to configure manual filters to avoid being an amplifier site, you
>_must_ filter out network addresses as well as broadcast addresses.
>Please, spread the word.
>P.S. I'd like to publicly thank Icon, Digex, and BBN as well as the EPA
>(yes folks, the Environmental Protection Agency, they were being used as
>an amplifier in this attack) for their help in tracing this attack to the
>Brandon Ross            Network Engineering     404-815-0770 800-719-4664
>Director, Network Engineering, MindSpring Ent., Inc.  info at
>Mosher's Law of Software Engineering:  Don't worry if it doesn't work
>right.  If everything did, you'd be out of a job.

           Plain Aviation, Inc                  dean at
           We Make IT Fly!                (617)242-3091 x246

More information about the NANOG mailing list