Solution: Re: Huge smurf attack
Craig A. Huegen
chuegen at quadrunner.com
Tue Jan 12 15:41:35 UTC 1999
I think it's time to do a technical refresh for those of you
who think routing 0.0.0.0, 10/8, 172.16/12, 192.168/16, etc. to
null0 will solve the smurf problem.
Routing in the Internet is done on a DESTINATION basis.
The reason you see 0.0.0.0 and/or 255.255.255.255 devices
in a smurf is that many times there are IP-capable network
devices never configured within some networks which will
respond with their default IP address (0.0.0.0 or 255.255.255.255).
I have 18.104.22.168/24. Let's say I put some manageable hub
on the wire, but never configure it -- its default IP address
remains at 0.0.0.0. Remember that the spoofed echo-request
packet is sent to 22.214.171.124. If directed broadcasts are
on, the router sending the packet onto the wire will send it
to the broadcast MAC address. Because it was a broadcast, this
device then responds to the originally spoofed source address,
with a *source* IP address of 0.0.0.0. Unless you're using a
feature such as unicast RPF checking, a router doesn't care
what source address you're using -- it gets the packet to its
RFC 2267 gives informative guidelines on how to configure
networks to prevent source-spoofed addresses from exiting the
network. This has limited scalability, though, as you move
closer to the core -- as you stack a few service providers
together, it gets pretty difficult to manage those filters.
Unicast RPF-checking is a very good way to automatically filter
source spoofs; however, it only works at the edge of the network,
because multi-homing can cause traffic to be dropped if this
check is enabled in the wrong place.
Now, with that said, I agree that providers should be filtering
routing announcements, whether it be through static routes or
distribute-lists; however, it will not keep packets with source
addresses of 0.0.0.0 or 255.255.255.255 from being delivered to you.
On Mon, Jan 11, 1999 at 08:23:44PM -0800, Dan Hollis wrote:
==>On Mon, 11 Jan 1999, Daniel Senie wrote:
==>> > Then we need to re-classify having an open broadcast amplifier as an
==>> > abuse. If we can get upstreams and backbones to give a formal 30 day
==>> > notice, then start cutting lines ...
==>> I think this could easily be classified as abuse or abuse through
==>> negligence (reckless endangerment?). Provider contracts should specify
==>> that downstreams must deal with ingress filtering and must ensure their
==>> networks will not respond to directed broadcasts from outside.
==>Speaking of negligence, I am disappointed at the backbones who continue to
==>route rfc1918 addresses, and wacko addresses like 0.0.0.0 and
==>It is REALLY all that much to ask you guys to null0 route these networks?
More information about the NANOG