RE: Blackhole Routes
Pete, If you are in the business of fighting DDoS at the ISP level, I would recommend checking out the NSP-SEC community. Among other things, I think you will find some info regarding DDoS route servers. There are several NANOG presentations and archived emails on this community. If you can't find what you are looking for, drop me a line offlist and I'll see if I can provide more assistance. HTH, ___ Wayne Gustavus, CCIE #7426 IP Operations Support Verizon Internet Services ___ "Can you ping me now? Good!" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Petri Helenius Sent: Monday, October 04, 2004 4:46 PM To: Wayne Gustavus (nanog) Cc: 'Stephen J. Wilcox'; 'Abhishek Verma'; [EMAIL PROTECTED] Subject: Re: Blackhole Routes Wayne Gustavus (nanog) wrote: >You can check out the info here: > >http://www.cymru.com/BGP/bogon-rs.html > > > Sure the bogons by cymru are widely known, anyone for spam and ddos bots/zombies? Pete >___ >Wayne Gustavus, CCIE #7426 >Operations Engineering >Verizon Internet Services >___ >"Entropy isn't what it used to be!" > > > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >Petri Helenius >Sent: Monday, October 04, 2004 1:41 AM >To: Stephen J. Wilcox >Cc: Abhishek Verma; [EMAIL PROTECTED] >Subject: Re: Blackhole Routes > > > >Stephen J. Wilcox wrote: > > > >>There are several sources of eBGP feeds for blackholing, they can be >>very useful >>depending on what your requirements are. You can get feeds for spam, >> >> >ddos bots, > > >>bogon routes etc >> >> >> >> >Can you point to the right direction where to find these feeds? They >don't seem to be advertised widely. > > > >> >> >> >> >Pete > > >
Re: Blackhole Routes
Wayne Gustavus (nanog) wrote: You can check out the info here: http://www.cymru.com/BGP/bogon-rs.html Sure the bogons by cymru are widely known, anyone for spam and ddos bots/zombies? Pete ___ Wayne Gustavus, CCIE #7426 Operations Engineering Verizon Internet Services ___ "Entropy isn't what it used to be!" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Petri Helenius Sent: Monday, October 04, 2004 1:41 AM To: Stephen J. Wilcox Cc: Abhishek Verma; [EMAIL PROTECTED] Subject: Re: Blackhole Routes Stephen J. Wilcox wrote: There are several sources of eBGP feeds for blackholing, they can be very useful depending on what your requirements are. You can get feeds for spam, ddos bots, bogon routes etc Can you point to the right direction where to find these feeds? They don't seem to be advertised widely. Pete
RE: Blackhole Routes
You can check out the info here: http://www.cymru.com/BGP/bogon-rs.html ___ Wayne Gustavus, CCIE #7426 Operations Engineering Verizon Internet Services ___ "Entropy isn't what it used to be!" -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Petri Helenius Sent: Monday, October 04, 2004 1:41 AM To: Stephen J. Wilcox Cc: Abhishek Verma; [EMAIL PROTECTED] Subject: Re: Blackhole Routes Stephen J. Wilcox wrote: >There are several sources of eBGP feeds for blackholing, they can be >very useful >depending on what your requirements are. You can get feeds for spam, ddos bots, >bogon routes etc > > Can you point to the right direction where to find these feeds? They don't seem to be advertised widely. > > Pete
Re: Blackhole Routes
Stephen J. Wilcox wrote: There are several sources of eBGP feeds for blackholing, they can be very useful depending on what your requirements are. You can get feeds for spam, ddos bots, bogon routes etc Can you point to the right direction where to find these feeds? They don't seem to be advertised widely. Pete
Re: Blackhole Routes
I know that my current employer is setup to reject /32s from peers as well as not to send them to peers. (Customers too for that matter save for the ones that have a bgp session to our null router). Having one's upstream propagate out /32s that they want null routed because of an attack probably won't scale past the original upstream. I guess all the tier1s could setup a whole network of special bgp sessions to each other's blackhole routers (those that implement this method) set up to implicitly trust each other's announcements, which in turn means that said network would need to implicitly trust all their peers' downstreams. Call me a realist, but I just don't see that happening anytime soon. Guy Tal On Thu, 30 Sep 2004, Richard A Steenbergen wrote: You can't authentication a prefix coming in from a peer that says to route a /24 to them any better or any worse. What difference does it make if you route the traffic to them and they blackhole it, or if you blackhole it locally based on their routing information? If it is a leak or a malicious route, you track it down and plug it the same way you do with an existing route that doesn't have the blackhole community set. I'm not saying that those methods are perfect by any means, but adding a global blackhole community at least changes nothing from the status quo.
Re: Blackhole Routes
Robert E.Seastrom wrote: >Ian Dickinson wrote: >>Blackholing schemes need to be simple enough >>to employ in a hurry at 4am whilst still achieving the desired effect. > > And Richard's suggestion is just that. Fair enough, but I'm worried that global propagation wouldn't deliver what many customers ask for in their hour of need - that's all. It could potentially have some scaling issues too, but that's not reason to shelve it without investigation either. -- Ian Dickinson Development Engineer PIPEX [EMAIL PROTECTED] http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html
Re: Blackhole Routes
Ian Dickinson <[EMAIL PROTECTED]> writes: > My point is that no-export or no-advertise doesn't play well with > multiple ASNs under common admin control. If this is your situation, perhaps already you have propagation suppression communities that cause the Right Thing to happen at the outer edge of your pile-o-ASes. I've certainly done that when in a similar situation. Send that community along with the blackhole community and you're done. You're correct that the well-known communities don't scale to multiple ASes. > Don't simplify the protocol > unnecessarily based on your specific assumptions on how others may or > may not use a feature. Trying to morph the protocol into something that is arbitrarily complex and custom-tailored to your particular situation is no better in terms of assumptions of how others may or may not use a feature. Provide basic building blocks and let people build out of them what they may. > Blackholing schemes need to be simple enough > to employ in a hurry at 4am whilst still achieving the desired effect. And Richard's suggestion is just that. ---Rob
Re: Blackhole Routes
Richard A Steenbergen wrote: On Sat, Oct 02, 2004 at 11:06:31PM +0100, Ian Dickinson wrote: You'd need an additional community to flag this eg. 65001:666 means to blackhole, 65001: means to propagate it as well. I can't speak for others but when we blackhole the destination (as opposed to blackholing the source or mitigating) we often only do it in the direction from which the attack is coming*. Why drop globally when you can drop traffic from a subset of the Internet? Your victim will thank you if 90% of their customer base can reach them, versus none. Similarly, if they're multi-homed, they may well rely on you NOT propagating. Maybe this looks different from the perspective of a global Tier-1. No, 65001:666 (or whatever value is chosen for a well known community, for the sake of argument) means to set the next-hop to something that discards packets, and otherwise propagate the route as normal. If you don't want it to be exported in a specific direction, you add no-export or no-advertise or just don't advertise it to peer X just like you would do with any other route. Don't complicate the protocol unnecessarily based on your specific assumptions of how you might or might not use a feature. There is nothing more or less complicated about this than adding a value to the end of http://www.iana.org/assignments/bgp-well-known-communities and declaring it a standard blackhole community. How you use it, how you export it, and who you accept it from, are provider specific policy decisions. However, based on the knowledge that a blackhole community route is no different than a regular route in its ability to cause unreachability if incorrectly announced, I would tend to suspect that most people would choose to allow this to be propagated globally. My point is that no-export or no-advertise doesn't play well with multiple ASNs under common admin control. Don't simplify the protocol unnecessarily based on your specific assumptions on how others may or may not use a feature. Blackholing schemes need to be simple enough to employ in a hurry at 4am whilst still achieving the desired effect. -- Ian Dickinson Development Engineer PIPEX [EMAIL PROTECTED] http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html
Re: Blackhole Routes
On Sat, Oct 02, 2004 at 11:06:31PM +0100, Ian Dickinson wrote: > You'd need an additional community to flag this eg. 65001:666 means to > blackhole, 65001: means to propagate it as well. I can't speak for > others but when we blackhole the destination (as opposed to blackholing > the source or mitigating) we often only do it in the direction from > which the attack is coming*. Why drop globally when you can drop > traffic from a subset of the Internet? Your victim will thank you > if 90% of their customer base can reach them, versus none. Similarly, > if they're multi-homed, they may well rely on you NOT propagating. > Maybe this looks different from the perspective of a global Tier-1. No, 65001:666 (or whatever value is chosen for a well known community, for the sake of argument) means to set the next-hop to something that discards packets, and otherwise propagate the route as normal. If you don't want it to be exported in a specific direction, you add no-export or no-advertise or just don't advertise it to peer X just like you would do with any other route. Don't complicate the protocol unnecessarily based on your specific assumptions of how you might or might not use a feature. There is nothing more or less complicated about this than adding a value to the end of http://www.iana.org/assignments/bgp-well-known-communities and declaring it a standard blackhole community. How you use it, how you export it, and who you accept it from, are provider specific policy decisions. However, based on the knowledge that a blackhole community route is no different than a regular route in its ability to cause unreachability if incorrectly announced, I would tend to suspect that most people would choose to allow this to be propagated globally. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Blackhole Routes
Richard A Steenbergen wrote: I'd have to disagree with you. While you and many other networks may be able to handle most DoS attacks without involving your upstreams, there are still plenty (the majority I would say) of networks who can't. In fact, the entire CONCEPT of a blackhole customer community is to move the filtering up one level higher on the Internet, where it should theoretically be easier for the larger network to filter. It would be silly to assume that there is no attack which the person implementing the blackhole community can not handle, or to assume that there will never be tier 2/3 ISPs aggregating or reselling bandwidth. Also, since the point of a blackhole community is to block all traffic to a destination prefix anyways, it doesn't matter whether the blackhole takes place 1 network upstream or 10. Any prefix which can be announced and routed on the global routing table should be able to be blackholed by every network on the global Internet, using a standard well-known community. This changes nothing of the current practices of accountability for your announcements, filtering by prefix length, etc. There would still remain a clear role for no-export and more specifics upto /32 between networks who have negotiated this relationship, but there absolutely no reason you couldn't and shouldn't have global blackholes available as well. You'd need an additional community to flag this eg. 65001:666 means to blackhole, 65001: means to propagate it as well. I can't speak for others but when we blackhole the destination (as opposed to blackholing the source or mitigating) we often only do it in the direction from which the attack is coming*. Why drop globally when you can drop traffic from a subset of the Internet? Your victim will thank you if 90% of their customer base can reach them, versus none. Similarly, if they're multi-homed, they may well rely on you NOT propagating. Maybe this looks different from the perspective of a global Tier-1. * We often find that even with the larger attacks, the vast majority of the traffic comes in from a particular vector (or group of vectors). Rarely does traffic enter via peerings equally. -- Ian Dickinson Development Engineer PIPEX [EMAIL PROTECTED] http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html
RE: Blackhole Routes
Something like http://www.cisco.com/en/US/products/ps5888/index.html? Matt. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Stewart Sent: 01 October 2004 08:23 To: Eric Germann; [EMAIL PROTECTED] Subject: Re: Blackhole Routes On Thu, 30 Sep 2004 10:35:36 -0400, Eric Germann <[EMAIL PROTECTED]> wrote: > What I would to see (and have never researched in depth) is a way to apply > the blackhole routes on a community to port basis (i.e. we set up a specific > BGP community to filter mail, and that community goes to a route map that > kills only port 25, another community applies to a map that kills port 80, A not particularly scalable method of doing that, which should be ok for small data flows, is to set up routers port25killer.example.net, a port80killer.example.net, etc., with ACLs that block those ports regardless of address, use BGP or OSPF to advertise whichever IP address spaces should be routed there, and set up those machines in whatever sort of firewalling location makes sense. It's more of an enterprise solution than an ISP solution, but if you're a small ISP or dealing with a relatively specific set of problem sites you could probably do it. You may need to burn some CPE on GRE tunnels, depending on your topology, but if you're trying to solve a limited problem like letting your users access Korean web sites while blocking Korean email, it may work. -- Live Life in Broadband www.telewest.co.uk The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. ==
Re: Blackhole Routes
On Thu, 30 Sep 2004 10:35:36 -0400, Eric Germann <[EMAIL PROTECTED]> wrote: > What I would to see (and have never researched in depth) is a way to apply > the blackhole routes on a community to port basis (i.e. we set up a specific > BGP community to filter mail, and that community goes to a route map that > kills only port 25, another community applies to a map that kills port 80, A not particularly scalable method of doing that, which should be ok for small data flows, is to set up routers port25killer.example.net, a port80killer.example.net, etc., with ACLs that block those ports regardless of address, use BGP or OSPF to advertise whichever IP address spaces should be routed there, and set up those machines in whatever sort of firewalling location makes sense. It's more of an enterprise solution than an ISP solution, but if you're a small ISP or dealing with a relatively specific set of problem sites you could probably do it. You may need to burn some CPE on GRE tunnels, depending on your topology, but if you're trying to solve a limited problem like letting your users access Korean web sites while blocking Korean email, it may work.
Re: Blackhole Routes
If every BGP session in your network is protected by a max-prefix limit, no matter who leaks, the damage will be limited and contained. >>> true, also not univeral, >> the problem with max-prefix is it does not say *which* prefixes. >> so even if the drop-bgp stoopidity is corrected, you could end >> up holding the bogus prefixes, not the good ones. > true, however, my point was that not even the basics are being > done :( darwinian motion
Re: Blackhole Routes
On Thu, 30 Sep 2004, Randy Bush wrote: > >> If every BGP session in your network is protected by a max-prefix > >> limit, no matter who leaks, the damage will be limited and contained. > > true, also not univeral, > > the problem with max-prefix is it does not say *which* prefixes. > so even if the drop-bgp stoopidity is corrected, you could end > up holding the bogus prefixes, not the good ones. true, however, my point was that not even the basics are being done :(
Re: Blackhole Routes
>> If every BGP session in your network is protected by a max-prefix >> limit, no matter who leaks, the damage will be limited and contained. > true, also not univeral, the problem with max-prefix is it does not say *which* prefixes. so even if the drop-bgp stoopidity is corrected, you could end up holding the bogus prefixes, not the good ones. randy
Re: Blackhole Routes
On Thu, 30 Sep 2004, Richard A Steenbergen wrote: > I'd have to disagree with you. While you and many other networks may be > able to handle most DoS attacks without involving your upstreams, there > are still plenty (the majority I would say) of networks who can't. In > fact, the entire CONCEPT of a blackhole customer community is to move the > filtering up one level higher on the Internet, where it should here is the key point - one level higher one level higher than my customer is me and one level higher than me is my upstream. if my customer is abel to propogate thro to my upstream that would be two levels. but you're absolutely right it depends on individual networks to decide whether they should automatically or manually pass this up the chain however i dont beleive it shoudl automatically be propogated without limits. one level yes; two levels maybe; three+ doubt it. Steve > theoretically be easier for the larger network to filter. It would be > silly to assume that there is no attack which the person implementing the > blackhole community can not handle, or to assume that there will never be > tier 2/3 ISPs aggregating or reselling bandwidth. > > Also, since the point of a blackhole community is to block all traffic to > a destination prefix anyways, it doesn't matter whether the blackhole > takes place 1 network upstream or 10. Any prefix which can be announced > and routed on the global routing table should be able to be blackholed by > every network on the global Internet, using a standard well-known > community. This changes nothing of the current practices of accountability > for your announcements, filtering by prefix length, etc. There would still > remain a clear role for no-export and more specifics upto /32 between > networks who have negotiated this relationship, but there absolutely no > reason you couldn't and shouldn't have global blackholes available as > well. > >
Re: Blackhole Routes
On Thu, Sep 30, 2004 at 04:47:30PM -0400, Mark Kasten wrote: > Richard A Steenbergen wrote: > > >That said, it is still absolutely silly that we can't standardize on a > >globally accepted blackhole community. A provider with many transit > >upstreams who wishes to pass on blackhole routes for their customers could > >quickly find themselves with some very messy configs and announcements > >trying to get everyones' specific blackhole community in place. I know > >we've all been tossing this idea around for a number of years, but if it > >hasn't been done already will someone please get this put into a draft > >already. > > > > The problem with this is authentication. I can authenticate prefixes my > customers advertise me (as much as currently possible anyway). I can't > authenticate a prefix coming in from a peer that is not filtered. If an > ISP were to accept any prefix with 65535:666 as a triggered blackhole, > how do you trust that? As much as I agree that a global blackhole > community would be nice, that's a big gotcha with potential liability > attached. You can't authentication a prefix coming in from a peer that says to route a /24 to them any better or any worse. What difference does it make if you route the traffic to them and they blackhole it, or if you blackhole it locally based on their routing information? If it is a leak or a malicious route, you track it down and plug it the same way you do with an existing route that doesn't have the blackhole community set. I'm not saying that those methods are perfect by any means, but adding a global blackhole community at least changes nothing from the status quo. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Blackhole Routes
Richard A Steenbergen wrote: That said, it is still absolutely silly that we can't standardize on a globally accepted blackhole community. A provider with many transit upstreams who wishes to pass on blackhole routes for their customers could quickly find themselves with some very messy configs and announcements trying to get everyones' specific blackhole community in place. I know we've all been tossing this idea around for a number of years, but if it hasn't been done already will someone please get this put into a draft already. The problem with this is authentication. I can authenticate prefixes my customers advertise me (as much as currently possible anyway). I can't authenticate a prefix coming in from a peer that is not filtered. If an ISP were to accept any prefix with 65535:666 as a triggered blackhole, how do you trust that? As much as I agree that a global blackhole community would be nice, that's a big gotcha with potential liability attached.
Re: Blackhole Routes
Eric Germann wrote: What I would to see (and have never researched in depth) is a way to apply the blackhole routes on a community to port basis (i.e. we set up a specific BGP community to filter mail, and that community goes to a route map that kills only port 25, another community applies to a map that kills port 80, etc). When I have spare time, I may see if there is any way to do that. Of course by then, IPv6 will be obsolete, so . You can ask JunOS to do this. I have yet to figure out a way IOS could do the same. Pete
Re: Blackhole Routes
On Thu, 30 Sep 2004, Jeff Aitken wrote: > > On Thu, Sep 30, 2004 at 02:15:49PM -0400, Deepak Jain wrote: > > provider mistakenly advertises more routes than he should [lets say > > specifics in case #1] you can flood your upstreams' routers with > > specifics and potentially cause flapping or memory overflows... > > > > In case #2, presumably the blackhole community takes precedence, so if a > > customer is mistakenly readvertising their multihome provider's table > > with a 666 tag, all of the upstream providers might be blackholing the > > majority of their non-customer routes. > > If a customer has a prefix filter, he cannot announce bogus routes. > true, but not universal, sadly. > If every BGP session in your network is protected by a max-prefix > limit, no matter who leaks, the damage will be limited and contained. > true, also not univeral, sadly. Many networks out there do NOT use any of these protections...
Re: Blackhole Routes
On Thu, Sep 30, 2004 at 08:03:05PM +0100, Stephen J. Wilcox wrote: > > we can handle most DoS's ourselves, this is the case with a lot/most? upstreams, > we dont automatically forward blackholes upstream > > the only time anyone would need to do that is if a particular upstream's > connection was saturated with the DoS. > > i'd agree automatically propogating these isnt good practice.. (imho) I'd have to disagree with you. While you and many other networks may be able to handle most DoS attacks without involving your upstreams, there are still plenty (the majority I would say) of networks who can't. In fact, the entire CONCEPT of a blackhole customer community is to move the filtering up one level higher on the Internet, where it should theoretically be easier for the larger network to filter. It would be silly to assume that there is no attack which the person implementing the blackhole community can not handle, or to assume that there will never be tier 2/3 ISPs aggregating or reselling bandwidth. Also, since the point of a blackhole community is to block all traffic to a destination prefix anyways, it doesn't matter whether the blackhole takes place 1 network upstream or 10. Any prefix which can be announced and routed on the global routing table should be able to be blackholed by every network on the global Internet, using a standard well-known community. This changes nothing of the current practices of accountability for your announcements, filtering by prefix length, etc. There would still remain a clear role for no-export and more specifics upto /32 between networks who have negotiated this relationship, but there absolutely no reason you couldn't and shouldn't have global blackholes available as well. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Blackhole Routes
On Thu, Sep 30, 2004 at 11:43:42AM -0700, Wayne E. Bouchard wrote: > > Yes, well, in my case, I go through a dedicated server with multi-hop > sessions and set a prefix limit of 25 or so so I don't get bombarded > with 5 billion /32 routes and don't send those routes upstream. (I try > to play nice when possible.) I expect that the upstreams have various > defense mechanisms of their own to protect them against me > misconfiguring my boxes as well. (It only makes sense..) This tends to work better for a variety of reasons. Most importantly, a dedicated session with a dedicated prefix-list can easily be configured to accept up to /32s for blackhole routes only, it can easily be configured to tag all routes received no-export, and it can easily be placed into a seperate prefix-limit which will not affect production traffic forwarding if something goes wrong. Also, if you have customers attached to Juniper routers, you need to have the sessions configured multihop anyways, in order to turn on the ability to rewrite next-hop. That said, it is still absolutely silly that we can't standardize on a globally accepted blackhole community. A provider with many transit upstreams who wishes to pass on blackhole routes for their customers could quickly find themselves with some very messy configs and announcements trying to get everyones' specific blackhole community in place. I know we've all been tossing this idea around for a number of years, but if it hasn't been done already will someone please get this put into a draft already. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Blackhole Routes
Deepak Jain wrote: If providers start tying their customer's blackhole announcements to the provider's upstreams' blackhole announcements in an AUTOMATIC process, bad things are likely to happen. What happens when a customer of a provider mistakenly advertises more routes than he should [lets say specifics in case #1] you can flood your upstreams' routers with specifics and potentially cause flapping or memory overflows... In case #2, presumably the blackhole community takes precedence, so if a customer is mistakenly readvertising their multihome provider's table with a 666 tag, all of the upstream providers might be blackholing the majority of their non-customer routes. I build two prefix lists for each customer. One represents the exact match routes that I'm willing to propagate, and the other covers "le 32" more specifics of what I'm willing to allow special treatment on. They can't blackhole anything outside what they would otherwise be allowed to announce (and I use it for several other special cases as well). Customers who are single-homed and otherwise static routed are welcome to use BGP for these special cases; their prefix lists reflect the fact that their space is not to be propagated. pt
Re: Blackhole Routes
we can handle most DoS's ourselves, this is the case with a lot/most? upstreams, we dont automatically forward blackholes upstream the only time anyone would need to do that is if a particular upstream's connection was saturated with the DoS. i'd agree automatically propogating these isnt good practice.. (imho) Steve On Thu, 30 Sep 2004, Deepak Jain wrote: > > > It goes a little further than that these days. Folks are openly > > allowing customers to advertize routes with something lika a 666 > > community which will then be blackholed within their network. So if > > you're a service provider with your own blackhole system, you can > > easily tie it into your upstream's system and dump the traffic many > > hops away from you meaning that the traffic is getting dumped closer > > to the source than the destination in a fair number of cases. > > > > This is very dangerous however. > > If providers start tying their customer's blackhole announcements to the > provider's upstreams' blackhole announcements in an AUTOMATIC process, > bad things are likely to happen. What happens when a customer of a > provider mistakenly advertises more routes than he should [lets say > specifics in case #1] you can flood your upstreams' routers with > specifics and potentially cause flapping or memory overflows... > > In case #2, presumably the blackhole community takes precedence, so if a > customer is mistakenly readvertising their multihome provider's table > with a 666 tag, all of the upstream providers might be blackholing the > majority of their non-customer routes. > > Non-automatic tying of customer blackholes to upstream or peer > blackholes is a powerful tool to improve the stability of the net as a > whole. > > Deepak Jain > AiNET >
Re: Blackhole Routes
On Thu, Sep 30, 2004 at 02:15:49PM -0400, Deepak Jain wrote: > > It goes a little further than that these days. Folks are openly > > allowing customers to advertize routes with something lika a 666 > > community which will then be blackholed within their network. So if > > you're a service provider with your own blackhole system, you can > > easily tie it into your upstream's system and dump the traffic many > > hops away from you > This is very dangerous however. > If providers start tying their customer's blackhole announcements to the > provider's upstreams' blackhole announcements in an AUTOMATIC process, > bad things are likely to happen. What happens when a customer of a > provider mistakenly advertises more routes than he should [lets say > specifics in case #1] you can flood your upstreams' routers with > specifics and potentially cause flapping or memory overflows... > > In case #2, presumably the blackhole community takes precedence, so if a > customer is mistakenly readvertising their multihome provider's table > with a 666 tag, all of the upstream providers might be blackholing the > majority of their non-customer routes. Well I think in most cases, there are some safeguards, in terms of the number of blackhole prefixes that will be accepted, and the length of the prefix (i.e., accept no more than 10 blackhole routes, only accept blackhole routes that are within prefixes the customer is advertising, only accept prefixes longer than /24). GBLX's docs on this are at: https://robin.gblx.net/api/docs/null_route.html -- one example of a "real life" implementation of such a system. -- "Since when is skepticism un-American? Dissent's not treason but they talk like it's the same..." (Sleater-Kinney - "Combat Rock")
Re: Blackhole Routes
On Thu, Sep 30, 2004 at 02:15:49PM -0400, Deepak Jain wrote: > provider mistakenly advertises more routes than he should [lets say > specifics in case #1] you can flood your upstreams' routers with > specifics and potentially cause flapping or memory overflows... > > In case #2, presumably the blackhole community takes precedence, so if a > customer is mistakenly readvertising their multihome provider's table > with a 666 tag, all of the upstream providers might be blackholing the > majority of their non-customer routes. If a customer has a prefix filter, he cannot announce bogus routes. If every BGP session in your network is protected by a max-prefix limit, no matter who leaks, the damage will be limited and contained. If you apply both types of filter to all customers, the worst that can happen is that one of your larger customers can inject a few thousand of his own more-specifics into your network before he trips the max-prefix limit. Additionally, re: case #1 above, any customer-announced route with your blackhole community attached should be tagged with NO_EXPORT or your internal equivalent. --Jeff
Re: Blackhole Routes
On Thu, Sep 30, 2004 at 02:15:49PM -0400, Deepak Jain wrote: > >It goes a little further than that these days. Folks are openly > >allowing customers to advertize routes with something lika a 666 > >community which will then be blackholed within their network. So if > >you're a service provider with your own blackhole system, you can > >easily tie it into your upstream's system and dump the traffic many > >hops away from you meaning that the traffic is getting dumped closer > >to the source than the destination in a fair number of cases. > > > > This is very dangerous however. > > If providers start tying their customer's blackhole announcements to the > provider's upstreams' blackhole announcements in an AUTOMATIC process, > bad things are likely to happen. What happens when a customer of a > provider mistakenly advertises more routes than he should [lets say > specifics in case #1] you can flood your upstreams' routers with > specifics and potentially cause flapping or memory overflows... Yes, well, in my case, I go through a dedicated server with multi-hop sessions and set a prefix limit of 25 or so so I don't get bombarded with 5 billion /32 routes and don't send those routes upstream. (I try to play nice when possible.) I expect that the upstreams have various defense mechanisms of their own to protect them against me misconfiguring my boxes as well. (It only makes sense..) > In case #2, presumably the blackhole community takes precedence, so if a > customer is mistakenly readvertising their multihome provider's table > with a 666 tag, all of the upstream providers might be blackholing the > majority of their non-customer routes. If the customer does themselves in, thats not something I can really protect against. > Non-automatic tying of customer blackholes to upstream or peer > blackholes is a powerful tool to improve the stability of the net as a > whole. Yes, but far too slow when you're getting DOSd off the face of several planets. --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: Blackhole Routes
It goes a little further than that these days. Folks are openly allowing customers to advertize routes with something lika a 666 community which will then be blackholed within their network. So if you're a service provider with your own blackhole system, you can easily tie it into your upstream's system and dump the traffic many hops away from you meaning that the traffic is getting dumped closer to the source than the destination in a fair number of cases. This is very dangerous however. If providers start tying their customer's blackhole announcements to the provider's upstreams' blackhole announcements in an AUTOMATIC process, bad things are likely to happen. What happens when a customer of a provider mistakenly advertises more routes than he should [lets say specifics in case #1] you can flood your upstreams' routers with specifics and potentially cause flapping or memory overflows... In case #2, presumably the blackhole community takes precedence, so if a customer is mistakenly readvertising their multihome provider's table with a 666 tag, all of the upstream providers might be blackholing the majority of their non-customer routes. Non-automatic tying of customer blackholes to upstream or peer blackholes is a powerful tool to improve the stability of the net as a whole. Deepak Jain AiNET
Re: Blackhole Routes
On Thu, Sep 30, 2004 at 04:40:54PM +0200, Erik Haagsman wrote: > > On Thu, 2004-09-30 at 15:45, Robert A. Hayden wrote: > > There are mechanisms to do it using eBGP and communities as well which I'm > > sure most on this list are more familiar with. > > > > Think of blackholing as a way to surgically remove a specific IP from your > > network, without having to deal with pushing ACLs into multiple entry > > points. At least that's what it accomplishes for us. > > And perhaps more importantly, when using eBGP blackholing communities, > without DDoS traffic hitting your ingress bandwidth from your upstreams. > ACL's can only filter traffic that's already at your edge, whereas > blackholing allows your upstream to filter it for you throughout his > network, reducing the risk of congested links. It goes a little further than that these days. Folks are openly allowing customers to advertize routes with something lika a 666 community which will then be blackholed within their network. So if you're a service provider with your own blackhole system, you can easily tie it into your upstream's system and dump the traffic many hops away from you meaning that the traffic is getting dumped closer to the source than the destination in a fair number of cases. --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: Blackhole Routes
On Thu, 30 Sep 2004, Deepak Jain wrote: > > > It sounds like you are confusing ideas here... > > If BGP is making a forwarding table entry, that's it. Ports are not > really considered in forwarding decisions -- or if they are, the box is > usually called a Firewall, not a router. > Just thinking out loud here... BUT, you could potentially (provided you had the interfaces and time) re-next-hop certain traffic based on source or destination address (dest would be easiest, which means catching syn-ack and discarding it to drop the sessions as embryos) and filter out 'bad' stuff in a more centralized manner. There are risks with this, of course, and complications which you'll probably want to avoid in any decently large network. As Deepak points out though, this is leading down some very dark paths of midnight-troubleshooting on complex configurations :( -Chris
Re: Blackhole Routes
It sounds like you are confusing ideas here... If BGP is making a forwarding table entry, that's it. Ports are not really considered in forwarding decisions -- or if they are, the box is usually called a Firewall, not a router. It would be pretty trivial to take the information you are generating and dump them into an IPFW or similar table and filter them that way. It would not be as effective, but you could watch your netflow data and selectively add holes or filters based on abuse of certain IP:port combinations. However, if you can destroy end-to-end connectivity and your customers are happy, I wouldn't change a thing. Its much simpler to debug a blackhole then it is a more selective filter. Deepak Jain AiNET Eric Germann wrote: We use a variation of this for several things. At the risk of getting in to political policy discussions ... We have a PERL script which looks for the wildcard .com record. If it finds it (the old Verisign SiteFinder), it injects a blackhole route to kill it. Also, we periodically pull in (every 4 hours), allocations from various registries like ARIN, APNIC, LACNIC, etc. and filter by country. It isn't elegant, but it does give us the ability to deny traffic to areas our policies dictate. Pretty effective for getting rid of spam and the offshore phishing sites. If you want to argue the political or policy side of doing this, I really don't have time, but our clients have been happy with it for two plus years. What I would to see (and have never researched in depth) is a way to apply the blackhole routes on a community to port basis (i.e. we set up a specific BGP community to filter mail, and that community goes to a route map that kills only port 25, another community applies to a map that kills port 80, etc). When I have spare time, I may see if there is any way to do that. Of course by then, IPv6 will be obsolete, so . Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhishek Verma Sent: Thursday, September 30, 2004 2:52 AM To: [EMAIL PROTECTED] Subject: Blackhole Routes Hi, There are ways to add static routes that can be blackholed. I can understand the utility of such routes if those are installed in my forwarding table. What bewilders me is why would anyone want to advertise "blackhole" routes using say, BGP? Is it only to prevent some sort of DoS attacks or are there other uses also of advertising black hole routes? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India
RE: Blackhole Routes
We use a variation of this for several things. At the risk of getting in to political policy discussions ... We have a PERL script which looks for the wildcard .com record. If it finds it (the old Verisign SiteFinder), it injects a blackhole route to kill it. Also, we periodically pull in (every 4 hours), allocations from various registries like ARIN, APNIC, LACNIC, etc. and filter by country. It isn't elegant, but it does give us the ability to deny traffic to areas our policies dictate. Pretty effective for getting rid of spam and the offshore phishing sites. If you want to argue the political or policy side of doing this, I really don't have time, but our clients have been happy with it for two plus years. What I would to see (and have never researched in depth) is a way to apply the blackhole routes on a community to port basis (i.e. we set up a specific BGP community to filter mail, and that community goes to a route map that kills only port 25, another community applies to a map that kills port 80, etc). When I have spare time, I may see if there is any way to do that. Of course by then, IPv6 will be obsolete, so . Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abhishek Verma Sent: Thursday, September 30, 2004 2:52 AM To: [EMAIL PROTECTED] Subject: Blackhole Routes Hi, There are ways to add static routes that can be blackholed. I can understand the utility of such routes if those are installed in my forwarding table. What bewilders me is why would anyone want to advertise "blackhole" routes using say, BGP? Is it only to prevent some sort of DoS attacks or are there other uses also of advertising black hole routes? Thanks, Abhishek -- Class of 2004 Institute of Technology, BHU Varanasi, India
Re: Blackhole Routes
On Thu, 2004-09-30 at 15:45, Robert A. Hayden wrote: > There are mechanisms to do it using eBGP and communities as well which I'm > sure most on this list are more familiar with. > > Think of blackholing as a way to surgically remove a specific IP from your > network, without having to deal with pushing ACLs into multiple entry > points. At least that's what it accomplishes for us. And perhaps more importantly, when using eBGP blackholing communities, without DDoS traffic hitting your ingress bandwidth from your upstreams. ACL's can only filter traffic that's already at your edge, whereas blackholing allows your upstream to filter it for you throughout his network, reducing the risk of congested links. Cheers, -- --- Erik Haagsman Network Architect We Dare BV tel: +31(0)10 7507008 fax:+31(0)10 7507005 http://www.we-dare.nl
RE: Blackhole Routes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == NEW Materials = Powersession on Core Security (4-6 May 2004) http://www.ciscoeventreg.net/go/networkers/agenda9.lasso CPN Summit SP Security Materials (April 2004) ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/ == Public Materials SP Security Materials - -- Public On-Line ISP Security Bootcamp - Singapore Summer 2003 http://www.getitmm.com/bootcampflash/launch.html Sign-On: http://palomar.getitmm.com/bootcamp/ Much of the materials presented in the ISP Security Bootcamp builds on and assumes a basic understanding of the principles in the ISP Essentials materials. This whitepaper is now a book - ISP Essentials which can be purchased through Cisco Press (http://www.ciscopress.com/) or through another on-line book store. The supplements for the book along with the tutorials, workshops, and bootcamps presented by Philip and I are at: ftp://ftp-eng.cisco.com/cons/ or http://www.ispbook.com TEAM CYMRU Templates and Tools - -- Team CYMRU provides configuration templates, security templates, and other services to help make the Internet a safer place to network. These can be found at: http://www.cymru.com/ The Original Backscattered Traceback and Customer Triggered Remote Triggered Black Hole Techniques - -- - --- http://www.secsup.org/Tracking/ http://www.secsup.org/CustomerBlackHole/ What is a BOTNET? - - One of the best write ups is from a freeware tool gone commercial (I guess so they can scale). http://swatit.org/bots/index.html BGP 'Attack Tree' - Realities of BGP Security - --- Cisco's CIAG Team moves beyond the armchair hypothesizing of BGP Security Risk and runs test again the industry's multiple implementations of BGP http://wwwin-people.cisco.com/sean/ciag-bgp-blackhatv2.pdf Communities of People Working Together to Mitigate Miscreant Activities - -- - - + Distributed Detection Systems Individuals and Organizations can Participate: Dshield - www.dshield.org My Netwatchman - www.mynetwatchman.com NANOG SP Security Seminars and Talks - - The NANOG Coordination Committee actively works to product sessions and seminars to help foster security on the Internet. All sessions are taped and converted to VOD for all to use for their personal education. Over time, this effort has generated a valuable On-Line Tutorial for engineers and organzations seeking to learn more about running a more secure network. NANOG Security Tutorial Series Tutorial: Implementing a Secure Network Infrastructure (Part I) http://www.nanog.org/mtg-0310/kaeo.html Tutorial: ISP Security - Real World Techniques I - Remote Triggered Black Hole Filtering and Backscatter Traceback. http://www.nanog.org/mtg-0110/greene.html Tutorial: ISP Security - Real World Techniques II - Secure the CPE Edge http://www.nanog.org/mtg-0210/ispsecure.html Tutorial: ISP Security: Deploying and Using Sinkholes http://www.nanog.org/mtg-0306/sink.html Tutorial: Deploying IP Anycast http://www.nanog.org/mtg-0310/miller.html NANOG Security Sessions Watching Your Router Configurations and Detecting Those Exciting Little Changes http://www.nanog.org/mtg-0310/rancid.html Building a Web of Trust http://www.nanog.org/mtg-0310/abley.html The Relationship Between Network Security and Spam http://www.nanog.org/mtg-0310/spam.html Simple Router Security, What Every ISP Router Engineer Should Know and Practice http://www.nanog.org/mtg-0310/routersec.html Flawed Routers Flood University of Wisconsin Internet Time Server http://www.nanog.org/mtg-0310/plonka.html Trends in Denial of Service Attack Technology http://www.nanog.org/mtg-0110/cert.html Recent Internet Worms: Who Are the Victims, and How Good Are We at Getting the Word Out? ` http://www.nanog.org/mtg-0110/moore.html DoS Attacks in the Real World http://www.nanog.org/mtg-0110/irc.html Diversion & Sieving Techniques to Defeat DDoS http://www.nanog.org/mtg-0110/afek.html DNS Damage - Measurements at a Root Server http://www.nanog.org/mtg-0202/evi.html Protecting the BGP Routes to Top Level DNS Servers http://www.nanog.org/mtg-0206/bush.html BGP Security Update http://www.nanog.org/mtg-0206/barry.html Industry/Government Infrastructure Vulnerability Assessment: Background and Recommendations http://www.nanog.org/mtg-0206/avi.html A National Strategy to Secure Cyberspace http://www.nanog.org/mtg-0210/sachs.html How to
Re: Blackhole Routes
We use Blackholing extensively to protect our campus network from "bad" machines. I did a writeup (replete my own personal brand of braindead typos) a while back that details out how we set it up using OSPF and uRPF. http://www.merit.edu/mail.archives/nanog/2003-11/msg00225.html There are mechanisms to do it using eBGP and communities as well which I'm sure most on this list are more familiar with. Think of blackholing as a way to surgically remove a specific IP from your network, without having to deal with pushing ACLs into multiple entry points. At least that's what it accomplishes for us. Robert Hayden Univeristy of Wisconsin Madison On Thu, 30 Sep 2004, Abhishek Verma wrote: > > Hi, > > There are ways to add static routes that can be blackholed. I can > understand the utility of such routes if those are installed in my > forwarding table. What bewilders me is why would anyone want to > advertise "blackhole" routes using say, BGP? > > Is it only to prevent some sort of DoS attacks or are there other uses > also of advertising black hole routes? > > Thanks, > Abhishek > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India >
Re: Blackhole Routes
> There are ways to add static routes that can be blackholed. I can > understand the utility of such routes if those are installed in my > forwarding table. What bewilders me is why would anyone want to > advertise "blackhole" routes using say, BGP? Have you read the presentation from the Feb. NANOG? http://www.nanog.org/mtg-0402/morrow.html All the presentation pages on the NANOG website have Merit's address at the bottom so when I google for this kind of stuff I use a query like the following to get a shortlist with mostly relevant pages. "4251 Plymouth Road" blackhole --Michael Dillon
Re: Blackhole Routes
There are several sources of eBGP feeds for blackholing, they can be very useful depending on what your requirements are. You can get feeds for spam, ddos bots, bogon routes etc For iBGP this can be useful too, if you are being DDoS'd you can inject an iBGP route and have all your routers instantly blackhole traffic at your edge instead of having to static config all of them.. regards Steve On Thu, 30 Sep 2004, Abhishek Verma wrote: > > Hi, > > There are ways to add static routes that can be blackholed. I can > understand the utility of such routes if those are installed in my > forwarding table. What bewilders me is why would anyone want to > advertise "blackhole" routes using say, BGP? > > Is it only to prevent some sort of DoS attacks or are there other uses > also of advertising black hole routes? > > Thanks, > Abhishek > > -- > Class of 2004 > Institute of Technology, BHU > Varanasi, India >
Re: Blackhole Routes
Abhishek Verma wrote: There are ways to add static routes that can be blackholed. I can understand the utility of such routes if those are installed in my forwarding table. What bewilders me is why would anyone want to advertise "blackhole" routes using say, BGP? Is it only to prevent some sort of DoS attacks or are there other uses also of advertising black hole routes? Look at the way the MAPS RBL started. Anybody else who trusts your judgement of what traffic to blackhole can take a bgp feed of the blackhole routes and use it.
