You don't need a tool. People already have provisioning/configuration tools or are doing it by hand. Whichever is the case, just add a rule to your customers interface. You know when you configure the interface what the mask is and what the broadcast is. All you need to do is add an access list entry which applies to that customers interface. The only real problem with this approach is customers which have large blocks. If you have a /16, you are almost certainly not using x.y.255.255 as a broadcast. It is hard to know or predict what their subnet strategy might be, but for such customers, you probably don't really need to worry, and can expect a higher clue level from them. They can put their own filters in place. --Dean At 03:41 PM 12/1/1998 -0500, Jon Zeeff wrote:
Who is willing to write a tool to do broadcast address discovery and access-list generation? Ideally with a config file that would allow one to avoid serious self smurfing (ie, ranges to check and patterns to assume are broadcasts without trying them).
Filtering broadcast addresses is pretty ugly. Consider that a single Class C broken down into /30's can have 64 broadcast addresses. Maybe if it was just filtering your own assigned subnets, it would be possible, but this also applies to customer-subnetted broadcast addresses, so you'd have to coordinate your filter with every one of your customers, every time they change subnets. Not impossible, but pretty close.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Tue, 1 Dec 1998, Dean Anderson wrote:
You don't need a tool. People already have provisioning/configuration tools or are doing it by hand. Whichever is the case, just add a rule to your customers interface. You know when you configure the interface what the mask is and what the broadcast is. All you need to do is add an access list entry which applies to that customers interface.
That works fine as long as you either manage your customers' equipment or your customers don't subnet blocks you give them. However, in real-world experience, neither of those apply, especially to a larger ISP/NSP (UUNet was mentioned in this thread at the beginning). It certainly doesn't hurt to put in access-list's where you can, to reduce the problem, but that is not a scalable solution. It is an incredible management nightmare, especially if you're having to keep track of autonomous customer routing changes. Not to mention that it adds to the burden of tracking down problems (imagine a DHCP server which assignes what used to be a broadcast address, but is no longer because the subnets were combined, and everytime a machine gets that address, it can't get outside the network because the administrator hasn't updated the 5,000-line access-list). Pete.
I've got to go with Pete K. on this one. In our current, cidr-ized world, it is simply not possible for an upstream provider to determine what is, or is not, a broadcast address in a downstream network. This is something that needs to be implemented from the edge in, not from the core out. On 2-Dec-98 at 00:55, Pete Kruckenberg (pete@kruckenberg.com) wrote:
On Tue, 1 Dec 1998, Dean Anderson wrote:
You don't need a tool. People already have provisioning/configuration tools or are doing it by hand. Whichever is the case, just add a rule to your customers interface. You know when you configure the interface what the mask is and what the broadcast is. All you need to do is add an access list entry which applies to that customers interface.
That works fine as long as you either manage your customers' equipment or your customers don't subnet blocks you give them. However, in real-world experience, neither of those apply, especially to a larger ISP/NSP (UUNet was mentioned in this thread at the beginning).
-- Rusty Zickefoose | The most exciting phrase to hear in science, rusty@cw.net | the one that heralds new discoveries, is not | "Eureka!", but "That's funny ..." | -- Isaac Asimov
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 08:38 PM 12/1/98 -0500, you wrote:
I've got to go with Pete K. on this one. In our current, cidr-ized world, it is simply not possible for an upstream provider to determine what is, or is not, a broadcast address in a downstream network. This is something that needs to be implemented from the edge in, not from the core out.
I agree that it is difficult if not impossible to implement at the core. One would think that having an extra 30 - 155Mb of traffic on their network that they're paying to transit to the world would motivate them to take a look at the edge/customer router(s) that are allowing the broadcast however. I would certainly let one of our customers know that it is in their best interest to either implement the filters/access lists or give us a map of their subnetting and let us do it for them. - ------------------------------------------------------------------ Get your *FREE* Parked Domain account at http://www.EZ-Hosting.Com - ------------------------------------------------------------------ John Fraizer | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation PGP Key fingerprint = 7DB6 1CA2 DAA6 43DA 3AAF 44CD 258C 3D7E B425 81A8 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com> iQA/AwUBNmSl7iWMPX60JYGoEQJPeQCeOD2jPRM4kKME5a+5lerf155Kxn0AoMGb PYYXUcGTQ/tlxwf3uGdVsLnz =v1Yj -----END PGP SIGNATURE-----
Rusty Zickefoose wrote:
I've got to go with Pete K. on this one. In our current, cidr-ized world, it is simply not possible for an upstream provider to determine what is, or is not, a broadcast address in a downstream network. This is something that needs to be implemented from the edge in, not from the core out.
I'll second the agreement. I know my own subnetting strategy, and I also know what blocks I assign to my customers. Although few of my customers are sophisticated enough to subnet them on their own, even if we go do it for them (which is one of the services we offer) this is not something that we record in the database that will be used to build all our configurations. I do have an access list deny for incoming destinations to *.*.*.255 since I do know that the only customer we have with larger than a /24 from us (via cw.net) also happens to have nothing larger than /26 in their network. AFAIK, today, smurfers are only using *.*.*.255. They would have to track a lot more information to use others, so for now I can generally expect that deny to prevent us from being an amplifier. As more and more *.*.*.255's get blocked, smurfer kiddies may look for other broadcast addresses as well. It may come down to literally having to build an access list from my assignment database. Of course those smaller subnets will typically have fewer hosts to amplify from, but when servers are carefully concentrated in a subnet, there can still be a lot. I cannot expect C&W to block *.*.*.255 incoming for me. Even though in my case it would cause no problems, in the case of others, it can, and they have no reason (or database) to know which is which. But when the smurfers start using 127, 63, etc., that won't do any good, and I don't want them blocking those all the way down to /30's (let's just cut the IPv4 address space in half). I do block outgoing sources with addresses other than our network blocks. Thus we can't be the source of an amplified attack other than an attack on our own network, or only amplified here, which limits it to our pipe size, and makes tracking it (to here) very easy. Such blocking helps on forgeries, too. I would expect the backbones to do broadcast address blocking in their own subnet space where a lot of broadcast replyable servers exist (surely their Cisco routers aren't replying to broadcasts since that is easy to turn off). But these can be thought of as an "edge", anyway, and they do know the subnet mask there. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --
I do have an access list deny for incoming destinations to *.*.*.255 since I do know that the only customer we have with larger than a /24 from us (via cw.net) also happens to have nothing larger than /26 in their network. AFAIK, today, smurfers are only using *.*.*.255. They would have to track a lot more information to use others, so for now I can generally expect that deny to prevent us from being an amplifier.
It's not difficult to find subnet broadcast addresses, since few routers (if they even support it) are configured to filter ICMP replies. If there isn't already software out there, it will take all of a few hours to add broadcast-finding code to the smurfing software in existence. I find the parallel between Internet attacks and terrorist activities very interesting. Though they are obviously not related as far as humanitarian issues go, they both require so much effort to track and prevent one wonders if it's even possible. When you consider that a single 28.8k (or even 2.4k, I guess) dial-up connection can cripple whole organizations, and the only defense is to get every router to filter or at least block directed broadcasts, it's very frustrating. Similar to the scenario that a single person with a few small devices or an aerosol can can maim or kill tens or hundreds of people. The most frustrating difference is that I suspect that most terrorists have some concept of what they're doing and how it impacts their victims; I suspect that many of the people who smurf or mail bomb or ping-flood or crack a system have little understanding of the real impact of their actions (this based on the number of times I've seen someone hack a Unix machine and get root access, then not know what to do and leave tracks all over the place--best when they use a Linux cracker kit to break into a BSDI machine, and then they don't know how to proceed). Obviously a lot of these issues could be resolved if ISP/NSP's installed address-verification filters in the core and at the edges of their networks, but that translates into more load for already-loaded routers, and who's going to do that. And again, the scaling and management issues, not to mention the fact that many organizations may not have a capable router or the expertise to do this. And as long as it's someone else, it's just news and never would happen to you anyways... Pete.
At 11:32 AM 12/2/98 -0700, Pete Kruckenberg wrote:
I do have an access list deny for incoming destinations to *.*.*.255 since I do know that the only customer we have with larger than a /24 from us (via cw.net) also happens to have nothing larger than /26 in their network. AFAIK, today, smurfers are only using *.*.*.255. They would have to track a lot more information to use others, so for now I can generally expect that deny to prevent us from being an amplifier.
It's not difficult to find subnet broadcast addresses, since few routers (if they even support it) are configured to filter ICMP replies. If there isn't already software out there, it will take all of a few hours to add broadcast-finding code to the smurfing software in existence.
Guys, Why not make your down-stream fill out a *complete* IN-ADDR.ARPA file which lists their sub-net bcast and base addresses? That way yo could use the DNS system itself to find those addresses. ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: staff<http://www.mhsc.com/~rmeyer>.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com ___________________________________________________ Who is John Galt? "Atlas Shrugged" - Ayn Rand
this makes sense...until someone gets lazy, and takes a week to filter, and the smurf brats catch on, and start querying DNS to find amplifiers. -Taz -- Jonathan "Taz" Mischo -- Network Slave -- supertaz@mindspring.net Mindspring Enterprises, Inc. 1430 W. Peachtree St. Suite 400 Atlanta, GA 30309 1.800.719.4664 x2705 404.287.0770 x2705 fax: 404.287.0885 pager: pagetaz@netops.mindspring.net M-F2-10pET On Thu, 3 Dec 1998, Roeland M.J. Meyer wrote:
At 11:32 AM 12/2/98 -0700, Pete Kruckenberg wrote:
I do have an access list deny for incoming destinations to *.*.*.255 since I do know that the only customer we have with larger than a /24 from us (via cw.net) also happens to have nothing larger than /26 in their network. AFAIK, today, smurfers are only using *.*.*.255. They would have to track a lot more information to use others, so for now I can generally expect that deny to prevent us from being an amplifier.
It's not difficult to find subnet broadcast addresses, since few routers (if they even support it) are configured to filter ICMP replies. If there isn't already software out there, it will take all of a few hours to add broadcast-finding code to the smurfing software in existence.
Guys,
Why not make your down-stream fill out a *complete* IN-ADDR.ARPA file which lists their sub-net bcast and base addresses? That way yo could use the DNS system itself to find those addresses. ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: staff<http://www.mhsc.com/~rmeyer>.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com ___________________________________________________ Who is John Galt? "Atlas Shrugged" - Ayn Rand
On Wed, Dec 02, 1998 at 08:53:59AM -0600, Phil Howard wrote: ==>I do have an access list deny for incoming destinations to *.*.*.255 ==>since I do know that the only customer we have with larger than a /24 ==>from us (via cw.net) also happens to have nothing larger than /26 in ==>their network. AFAIK, today, smurfers are only using *.*.*.255. They They also tend to use *.*.*.0. You wouldn't believe the number of hosts that still respond to the old all-zeros broadcast address. /cah
On Wed, 2 Dec 1998, Phil Howard wrote:
AFAIK, today, smurfers are only using *.*.*.255. They would have to track a lot more information to use others, so for now I can generally expect that deny to prevent us from being an amplifier.
I'm afraid that in my experience, that's not true at all. I've seen smurf attacks bounced off of networks as small as /30's and all the way up to one network that was a /22, as well as everything inbetween, and I'm not just talking about the last /30 in a /24 either. 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.
I've got to go with Pete K. on this one. In our current, cidr-ized world, it is simply not possible for an upstream provider to determine what is, or is not, a broadcast address in a downstream network. This is something that needs to be implemented from the edge in, not from the core out.
Don't forget that the original suggestion at the beginning of this thread was that UUnet should filter broadcast addresses on their Cisco routers because their Max TNT's couldn't do it, in other words take care of the networks on which the TNT's sit. It got escalated into a suggestion that they protect all their networks and all their customers networks in their core. Of course that's next to impossible! Point: Yes, people who have routers in their networks that can't be configured not to forward directed broadcasts should have this problem patched by filtering, (although it won't protect them from their own dialup users from being initiators) -Phil
On Wed, Dec 02, 1998 at 11:40:37AM -0500, Phillip Vandry wrote: ==>Don't forget that the original suggestion at the beginning of this thread ==>was that UUnet should filter broadcast addresses on their Cisco routers ==>because their Max TNT's couldn't do it, in other words take care of the ==>networks on which the TNT's sit. Not that anyone follows the rules, but: RFC 1812, "Requirements for IP Version 4 Routers", Section 5.3.5, specifies: --- A router [...] MUST have an option to disable forwarding network-prefix-directed broadcasts. --- That particular sentence is followed by another sentence which states that directed-broadcast MUST default to on; obviously, the RFC was written before the time of smurf attacks. /cah
participants (10)
-
Brandon Ross -
Craig A. Huegen -
Dean Anderson -
John Fraizer -
Jonathan Mischo -
Pete Kruckenberg -
Phil Howard -
Phillip Vandry -
Roeland M.J. Meyer -
Rusty Zickefoose