SMURF amplifier block list

Dan Boehlke dboehlke at
Sat Apr 18 19:50:56 UTC 1998

On Sat, 18 Apr 1998, Alex P. Rudnev wrote:

> > What about people who didn't subnet their class B on the eight bit 
> > boundry, but made larger subnets instead?  What about the class B that 
> > doesn't appear to be subnetted at all?  What about supernetted class C 
> > networks?  A trailing .255 can be a valid host.
> And what's worng? If they di nit subnet their B network, the tail of 
> address should be .255 too.
> If someone have particular .255 host - OK, you should not be able to ping 
> it, not more. The small fee for the free-of-smurfing-from-your-network.
> > > Why don't use the filter
> > > 
> > >  deny icmp any echo-request
> Just now, USA's ISP seems to be absolutely helpless facing SMURF. A lot 
> of networks do not block aroadcast echo-request's; no one even know how 
> to trace thos 'echo-request' packets by their network... may be I am 
> wrong, and it's because there is _a lot of ISP_ there, and even a few af 
> them who do not know how to fight against SMURF compose a good backet - I 
> do not know. 
> Really; does anyone know any sucsessfull attempts to search for the 
> smurfer? What penalty was provided for this hackers? Does exist some 
> legitimate way to establish a lawsuite against them (when they'll be 
> located - last is the only matter of qualification for their nearest ISP, 
> not more).

I agree that ISPs are at the mercy of the smurfers.  At MRNet we have been
fighting an internal battle to get our customers to do the right things 
to block their ability to be used as a multiplier.  Its not just 
ignorance that keeps our customers from acting, it in some cases is their 

We have written SMURF detection software that uses cisco netflow exports 
to let us know when a SMURF is going on, either inbound or outbound.  
Before we had this, we didn't know how bad it was, we never saw the 
majority of the attacks or where our customer nets were being used as a 
multiplier.  We hope to automate a block.

Cisco is working on features to help with this problem.  They need to be 
given time to do it right.

We have implimented a filter that blocks broadcasts on our NSP border 
routers.  However this list only blocks the broadcast addresses in our 
CIDR blocks and on assigment boundries.  It has helped alot.

We can, as network administrators, clamp down this net so hard only the 
hackers would be able to use it.  Blocking all .255 traffic even just 
ICMP is a step too close to that.  Remember the distain for routers and 
hosts that made classfull assumptions when they were given an address?

Dan Boehlke, Senior Network Engineer                          M R N e t
Internet:  dboehlke at                       A MEANS Telcom Company
Phone:  612-362-5814                  2829 SE University Ave. Suite 200
WWW:                Minneapolis, MN  55414

More information about the NANOG mailing list