Jon Lewis wrote:
This might not be allowed under existing service contracts. Most
providers probably have provisions to disconnect for network abuse...but
not for cluelessness.
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 ...
OTOH, what about just declaring that X.X.X.{0,255} is off limits
regardless of the network size? It would take just 2 access list
entries to make those addresses in networks larger than /24 to be
mostly useless. There aren't that many LANs out there that would
have real non-broadcast use on these addresses, anyway. I block
these coming in to my network as destinations, and I'm tempted to
block them as sources, as well. Once these addresses are indeed
off limits, then the next step is to get backbones to put in the
access lists.
Phil Howard wrote:
Jon Lewis wrote:
> This might not be allowed under existing service contracts. Most
> providers probably have provisions to disconnect for network abuse...but
> not for cluelessness.
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.
OTOH, what about just declaring that X.X.X.{0,255} is off limits
regardless of the network size? It would take just 2 access list
entries to make those addresses in networks larger than /24 to be
mostly useless. There aren't that many LANs out there that would
have real non-broadcast use on these addresses, anyway. I block
these coming in to my network as destinations, and I'm tempted to
block them as sources, as well. Once these addresses are indeed
off limits, then the next step is to get backbones to put in the
access lists.
No. This is not a good plan. There are indeed networks out there with
supernetted LANs. I consult for a large research institution which uses
/22 masks for all subnets, and heavily uses them. The chances of
clobbering perfectly legitimate addresses is real. Beyond this, there
are plenty of /25 networks that'll do a perfectly good job of playing
smurf-amplifier. The solution isn't to apply access lists.
The proper answer to this is to disable directed broadcasts on the
routers themselves. It'd be helpful if routers came out of the box with
this feature disabled by default. Perhaps folks should talk with their
router vendors of choice and ask for this change. I have submitted a
draft into the IETF process to require this change, updating RFC 1812
(router requirements).
Unfortunately directed broadcasts, like ingress filtering, are items
that have to be properly dealt with at the edges of the network. I do
wonder if we will start seeing network providers' legal departments
start taking notice of the situation. Negligence in operating a network
and becoming an unwitting accessory to a crime might raise the level of
urgency in getting folks to address both ingress filtering and directed
broadcast issues. I would prefer to see this handled by the technical
folks without getting the legal types into the fray, but worry that some
will not take the urgency to heart.
Speaking of negligence, I am disappointed at the backbones who continue to
route rfc1918 addresses, and wacko addresses like 0.0.0.0 and
255.255.255.255.
It is REALLY all that much to ask you guys to null0 route these networks?
Sheesh.
-Dan
I'm happy to say that progress is being made in this area. When a vendor
comes to us for the first time, one of things I tell them is that we will
not buy their hardware until they ship with directed broadcast disabled by
default. We've had a lot of success in this area, we'd have even more if
others would do the same.
Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com
ICQ: 2269442
Stop Smurf attacks! Configure your router interfaces to block directed
broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.
Lots of smurf amps are smaller than /24, and there are plenty of networks
larger than /24.
----don't waste your cpu, crack rc5...www.distributed.net team enzo---
Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or
Network Administrator | nestea'd...whatever it takes
Florida Digital Turnpike | to get the job done.
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key________
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.
Not so.
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 205.166.195.0/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 205.166.195.255. 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
destination.
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.
/cah
Since Phil's on my side of this argument, I'll jump back in.
What percentage of the hosts on the internet occupy an address with a
non-broadcast .0 or .255 last octet?
What percentage of smurfs would be stopped bu outbound filters on those
octets?
Which is a bigger win?
Cheers,
-- jra