I'm sure all of us have parts of the Internet that we block for one reason or another. I have existing methods for null routing traffic from annoying hosts and subnets on our border routers today (I'm still working on a network blackhole). However I've never tackled the problem by targeting a bad guy's ASN. What's the best option for null routing traffic by ASN? I could always add another deny statement in my inbound eBGP route-maps to match a new as-path ACL for _BAD-ASN_ to keep from accepting their routes to begin with. Are there any other good tricks that I can employ?
I have another question along those same lines. Once I do have my blackhole up and running I can easily funnel hosts or subnets into the blackhole. What about funneling all routes to a particular ASN into the blackhole? Are there any useful tricks here?
The ASN I'm referring to is that of the Russian Business Network. A Google search should turn up plenty of info for those that haven't heard of them.
This is prior art. (Assuming your hardware has a hardware blackhole (or you have a little router sitting on the end of a circuit)) you adjust your route-map that would deny the entry to set a community or next-hop pointing to your blackhole location.
Nowadays, most equipment can blackhole internally (to null0 say) at full speed, so it isn't an issue. Just set your next hop to a good null0 style location on route import and you are done for traffic destined to those locations.
For inbound traffic from those locations you would need to do policy routing (because you are looking up on source). If you are trying to block SPAM or anything TCP related, you only need to block 1 direction to end the conversation.
I'm sure all of us have parts of the Internet that we block for one reason or another. I have existing methods for null routing traffic from annoying hosts and subnets on our border routers today (I'm still working on a network blackhole). However I've never tackled the problem by targeting a bad guy's ASN. What's the best option for null routing traffic by ASN? I could always add another deny statement in my inbound eBGP route-maps to match a new as-path ACL for _BAD-ASN_ to keep from accepting their routes to begin with. Are there any other good tricks that I can employ?
You could do it with an as-path access-list.
Example:
router bgp 65500
no auto-summary
no synchronization
log-neighbor-changes
neighbor 1.2.3.4 remote-as 65400
neighbor 1.2.3.4 description UPSTREAM1
neighbor 1.2.3.4 filter-list 10 in
neighbor 1.2.3.4 soft-reconfiguration inbound
ip as-path access-list 10 deny (_65300)+$
ip as-path access-list 10 permit .*
This example should drop any prefixes you receive from your upstream
that include 65300 as the origin AS in the AS path, but permit anything else. If you're concerned about prefixes that could have 65300 anywhere in the path, take the $ off of the regex.
You could also probably write a route-map to redirect traffic from your network to prefixes from that AS to null0, or to a traffic analsis box.
I'd recommend you exercise extreme caution with any such
policy.
Specifically, if the origin[?] AS that you're wanting to drop all
traffic from gets wind of such a policy, they could easily announce
other prefixes that result in your dropping that traffic, introducing
a more effective DoS vector. Other ASes could easily spoof an
origin AS and trigger such a policy application as well.
You should probably do this explicitly based on prefix and null
route from some centralized route server w/uRPF and not as a
matter of automated policy based on a given AS Path set.
If you're simply worried about destination reachability to prefixes
provided by those ASes in question, then you could employ a
BGP filter on ingress dropping prefixes with those ASes in the path
-- although I think your query was more concerned with ingress
traffic from those ASes, not egressing destined to those networks.
Finally, as Ferg said, networks of that sort seem to find a need to
diversify their connectivity periodically -- all the more reason to
avoid such policies.
This is prior art. (Assuming your hardware has a hardware blackhole (or
you have a little router sitting on the end of a circuit)) you adjust
your route-map that would deny the entry to set a community or next-hop
pointing to your blackhole location.
Nowadays, most equipment can blackhole internally (to null0 say) at full
speed, so it isn't an issue. Just set your next hop to a good null0
style location on route import and you are done for traffic destined to
those locations.
...do uRPF-loose-mode and you kill FROM these locations as well...
For inbound traffic from those locations you would need to do policy
routing (because you are looking up on source). If you are trying to
(uRPF loose-mode)
block SPAM or anything TCP related, you only need to block 1 direction
to end the conversation.
be cautious of 'synflooding' your internal hosts with this though...
Null0 doesn't generate unreachables at packet-rate, but at a lower
(1:1000 I believe on cisco by default) rate.
Sounds harsh, but hey, its your network.
wee! and for some extra fun, just append the bad-guy's ASN to your
route announcements, force bgp loop-detection to kill the traffic on
their end (presuming they don't default-route as well)
Once upon a time, Christopher Morrow <morrowc.lists@gmail.com> said:
> Nowadays, most equipment can blackhole internally (to null0 say) at full
> speed, so it isn't an issue. Just set your next hop to a good null0
> style location on route import and you are done for traffic destined to
> those locations.
...do uRPF-loose-mode and you kill FROM these locations as well...
The ASN I'm referring to is that of the Russian Business Network. A Google search should turn up plenty of info for those that haven't heard of them.
Thanks for the replies. They were along the lines of what I was expecting (as-path ACL filtering & route-maps). I was wondering if there was some new trick that was easier and more robust. This will work though!
I saw that AS40989 fell off the 'Net a while back. That happened once or twice before if memory serves me correctly and they came back a while later in force. We'll see what happens this time. Some of RBN's old netblocks are also no longer in the global tables. I'm not sure what's going on with that but... I'm going to have to do a little more research on their current Inet sources to see if I can locate them. It looks like Wikipedia has a fair amount of information and a large number of links to additional information.
I'm going to have to put a little more effort towards getting my blackhole operational. If anyone has any good links to docs or advice on what not to do I'd love to see them. I've found a great deal of information on the 'Net but lessons learned from those who've already been there done that is always welcome.
I hadn't considered what Danny pointed out about the origin AS advertising other routes to create an effective DoS mechanism. That would be a concern and would require a great deal of forethought. Null routing prefixes would probably be the best course of action.
wee! and for some extra fun, just append the bad-guy's ASN to your
route announcements, force bgp loop-detection to kill the traffic on
their end (presuming they don't default-route as well)
Even more fun if you are not the only one filtering that ASN.
