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

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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Petri Helenius Sent: Monday, October 04, 2004 1:41 AM To: Stephen J. Wilcox Cc: Abhishek Verma; nanog@merit.edu 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

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

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 <tm> 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

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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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...

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 :(

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 <tm> 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")

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 <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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:6666 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 ian.dickinson@pipex.net http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html

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:6666 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 ian.dickinson@pipex.net http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html

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 ian.dickinson@pipex.net http://www.pipex.net This e-mail is subject to: http://www.pipex.net/disclaimer.html

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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Abhishek Verma Sent: Thursday, September 30, 2004 2:52 AM To: nanog@merit.edu 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

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