>> On Jun 14,  1:00pm, Eric Haszlakiewicz wrote:
>> } On Sat, Jan 22, 2005 at 03:57:21PM -0800, John Nemeth wrote:
>> } >      Why is NetBSD 2.0 responding to broadcast ICMP ECHO REQUEST 
>> (ping)
>> } > packets?  Is there any way to stop it.  Because this is a well 
>> known
>> } > DOS most modern OSes don't respond, so I'm surprised that current
>> } > versions of NetBSD do.
>> }
>> }       DoS?  How so?  I would think that responding to a ping takes
>> } considerably less resources than, say, responding to a connection 
>> attempt.
>>
>>     It is a traffic amplification attack.  Picture a network with 50+
>> machines, which respond to broadcast packets.  You send one ping 
>> packet
>> to the broadcast address and get 50 back.  A great way to flood a
>> network with very little effort.  Send a continuous stream of packets
>> and even if you don't have a very high speed network, due to the
>> amplification effect you can completely saturate a remote network thus
>> making it useless.  An even better trick is to fake the source address
>> (since ICMP is a connectionless protocol this is easy) and you can get
>> some sucker to flood the crap out of a third party.  Tracing packets
>> with faked source addresses is not easy.
>
> That's called a smurf attack.  The usual defense is to make sure that
> your routers don't send out broadcasts to a local LAN when the packet
> originated somewhere else.  Those are known as directed broadcasts, and
> they've been known to be a bad idea since 1998 -- see
> http://www.cert.org/advisories/CA-1998-01.html .  It's only an issue if
> the attacker is on your own LAN, and those are relatively easy to 
> trace.

hm, that should be the standard ever since (and way before 1998). 
routers are broadcast borders, and that /includes/ directed broadcasts 
as well.

there were problems called 'broadcast storms' ever since hubs, and 
later switches, became payable ;)

regards,

timo