Call me Now

Filtering With Holes

Throughout both the Service Provider CCIE track and the Security CCIE (2.0) track, we have things listed on our blueprints bringing the names of blackhole and sinkhole routing to bear.  Of course, if we look through the DocCD we will find nothing specifically bearing this name which leaves us to our own imagination!  (Not always a good thing!)

While this may sound a lot like some Star Trek episode, it’s important for us to understand what each is, and more so how to implement them.  Sinkholes are designed to attract traffic and keep it (for analysis or whatever reason).  Blackholes, on the other hand, are designed to attract traffic and never let it be seen again.

In larger networks (and what we simulate in our CCIE labs) both of these techniques are typically done via BGP.  So let’s start with the sinkhole idea.  To create a sinkhole, we want to attract traffic.  The first question we need to ask is “Why?”

Whenever you advertise a network out, you inadvertently attract traffic to those IPs.  That traffic may be good, or it may be bad.  From a security perspective, I’m sure everyone has heard the term Honeypot used before.  There is a specific purpose to attract traffic.

So let’s say that you have a /24 network advertising to the Internet through various connections.  Traffic can come in and wend its way through your network to the destination network segment.  You notice a DoS attack, or some huge amount of traffic towards one of your web servers.  Where do you secure against this?  How do you secure against it?  Are you still moving traffic all the way through your network to one final router before the segment that has your web server?  Are you tying up all of your link’s bandwidth while doing this?  Or worse, multiple link’s bandwidth?

Sinkholes spread throughout your network are a way to break apart and analyze the traffic, perhaps cleaning it and moving the good stuff on through.  But multiple routers would need a focal point, or different way to route that traffic.  You may simply change the destination for a single IP out of that /24.  Most-specific routing always wins, so that’s an easy way.  Maybe you have multiple analysis points in your network to segment the traffic and reduce load and bottlenecks in your topology.

Either way, if you follow the lab instructions, you are creating a sinkhole.  You may even be advertising extra networks just to attract traffic for analysis (like a Honeypot idea).  Just watch what’s being asked, but that’s the concept of a sinkhole.

Blackhole routing on the other hand wants to kill traffic instead of attracting it.   For the easy solution, we could go to all of our routers and install some Null0 routes.  In real life, this is not a scalable approach.  Hence the term remotely-triggered blackhole routing, and we’ll use BGP.  Killing a route via a routing protocol is not a simple concept.  No matter how hard we try when advertising a route, Null0 is not a valid next-hop to pass along to someone else!

So every router needs to have a seed route to Null0.  Pick something that isn’t used.

Ip route 1.1.1.1 255.255.255.255 null0

That goes on every single router now.  Of course, we would also have BGP setup between all of our internal routers.  Perhaps not really moving any “real” routing information, just used to kill things.  Now we need the trigger.  On  a central router (wherever an admin is anyway) we’ll do our maintenance for what routes we want to kill.

Ip route 192.0.0.0 255.0.0.0 null0 tag 86
ip route 100.100.100.0 255.255.255.0 null0 tag 86
ip route 200.200.200.0 255.255.255.0 null0 tag 86

Notice the tag on those static routes.  This will be used for redistribution to help only get the “bad” routes from a router that may actually have many other static routes.  Ok, not in the real lab, but we’re pretending that the skills we learn on our way to CCIE have some real-life intrinsic value, right?

So once we have decided on our central router what routes we want to kill everywhere, then we pass them out through BGP.

Route-map KillRoutes permit 10
 Match tag 86

Router bgp 65000
 Redistribute static route-map KillRoutes

That all seems very simple, right?  Well, yes it does, but it won’t help us.  At this point, all of our iBGP routers would see the central router as the next hop for each of the routes.  Ok, yes, that creates a blackhole.  Because it pulls all of the packets into the middle of our network and then kills them locally with a Null0 next-hop.  But we are wasting LOTS of bandwidth in doing this.  Always filter as close to the source as possible.  Good design rules!

In order to do this, we need to change the next hop of the route from our central router’s IP address to that of the distributed Null0 route (1.1.1.1 in my example).

Route-map NH-Change permit 10
 Match tag 86
 Set ip next-hop 1.1.1.1
Route-map NH-Change permit 20

Router bgp 65000
 Neighbor x.x.x.x route-map NH-Change out
 (repeat for each of your neighbors unless you’re using peer groups!)

The last permit statement of the route-map was to pass-through any other routes that you may want to run in BGP unchanged.  Only make the next-hop change for those routes that are evil.  You could also set this next-hop within the original redistribute route-map.  I just split it out for pointing out the differences.

At this point, all of your other routers have learned some routes via iBGP, with a next-hop of 1.1.1.1 and since they have a local static route to Null0 for that next hop, all routes learned this way will be killed.

We have now used blackhole routing in a remotely-triggered manner.  Kinda cool, huh?  Not difficult either, just a matter of thinking about what we are trying to accomplish.

One important concept to add on to this here!  Any route that we add affects what?  Our reachability to those networks.  That means outbound traffic will be killed, and NOT close to the source.  Didn’t I mention before that it’s a good design practice to kill things as close to the source as possible.

So what do we do to affect inbound traffic?  We always route based on a packet’s destination address not the source.  But on the other hand, I can use the uRPF feature (Unicast Reverse Path Forwarding) in order to use a route-lookup in order to test the validity of a packet’s source address as it comes in.  This is the missing piece to make RTBH filtering work for inbound traffic!  If you receive a packet inbound on Serial 0/0/0, but the next hop in the routing table is Null0, obviously they don’t match.  And therefore the inbound packets would be discarded.

As noted, these techniques have been listed more explicitly on both the Security (2.0) and Service Provider CCIE tracks.  I don’t see any reason why they can’t be used in Routing & Switching as well, so it never hurts to think these things through!

For some extra information, check out:
http://www.cisco.com/web/about/security/intelligence/worm-mitigation-whitepaper.html

As always…  read your exam scenario carefully.  Makes notes and diagrams as necessary, but think like the router does.  Think things through one step at a time and all of these complicated things suddenly become much easier.