Subject: Re: broadcast ping response
To: John Nemeth <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 01/22/2005 20:05:48
In message <200501230042.j0N0gTFp025283@vtn1.victoria.tc.ca>, John Nemeth write
>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.
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb