Remotely Triggered Black Hole with uRPF

When you get to know about malicious IPs, how do you control traffic to or from there?
Apply an ACL or a firewall policy at your internet gateway... Easy one. 
But what if you have multiple gateways... Login to each one of them and apply policies or maybe use an automation server to do that... Okay.
How about, if that IP belongs to one of your internal machines? Or multiple machines in different subnets or from remote sites? Or an internal machine spoofing as an external IP?
You may take significant time locating the hosts or blocking those IPs using ALC. Complicated?
And in case of DDoS, DoS or security events, an action at slight delay may be catastrophic. Isn't it?

In such situations, especially when you are managing a large network, with multiple gateways, spread across different regions, with remote and hub offices, you may need an intelligent way to block malicious IPs. Also, it's desirable to block them closest to their origin in your network, so it doesn't consume network bandwidth and have less scope for further infections.

Remote Triggered Black Hole (RTBH)is a way to advertise bad IPs from one central node to the rest of the network. Other nodes, who learn through BGP about Bad IP, take local measurement to block it. It's really that simple. If you are running BGP for most of your route advertisements, RTBH may work as a great defense. Let's see how it work.

Consider a router which is acting as an announcement unit in network, call it Bogon. Bogon means Bogus, and bogon actually refers to a group of IPs which are unallocated by IANA and should not exist on the internet. The Bogon router, running BGP, will communicate with all your BGP aware routes either via full mesh or via a Route Reflector. Whenever you learn about a bad IP, you simply add it in Bogon, and Bogon will advertise it to all BGP peers.

All BGP active routers in the network will have a static route for a common auxiliary IP ( eg. 192.0.2.1/32), with next-hop black-hole (Null0 or Discard). There may be multiple ways to match Bogon routes and then set next hop to this auxiliary IP (I will discuss more on it at the end of this section). This will result in pointing Bogon routes to Null0 or Discard after recursive lookup. 
Running RTBH, you empower your internal routers, to identify and discard malicious traffic. Thus, malicious traffic will now be dropped at the initial or intermediate level. 

Now, if you are running URPF (Unicast Reverse Path Forward) in your network, you can enhance the security capability of your devices at the next level. Running URPF along with RTBH, your routers will not only drop traffic destined to Bogon IPs, but they will also scan traffic sourced from them and drop instantly. This way, the malicious payload will not even reach to the targeted device. For more detail about uRPF, refer to my previous blog.
If you are not comfortable with uRPF and don't want to implement uRPF with full capacity, still if you want to get the benefit of both, refer to subsection "uRPF with Default Route" under "Implementing URPF". :)

Okay, now let's discuss the strategy to implement RTBH. You can actually implement it in many different ways, based on your network architecture. I am discussing here, my two preferred styles. Although, real configurations may differ with different vendors, however, the concept is going to be 

Option-1: When your network is simple and running only on a single AS. You need to add bad IPs in Bogon as a static route with a TAG or Community value attached to it. Set next hop to null0 or discard. Then advertise these routes through BGP, by redistributing static and matching that TAG/Community value.
While advertising these routes, use a policy or route-map to set next-hop to the auxiliary IP (eg. 192.0.2.1, which need be present in all BGP aware routers with next-hop Null0/ Discard). In an iBGP advertisement (either via full mesh or via Route Reflector) next hop value will remain unchanged (192.0.2.1). This will end-up installing Bogon routes with Black-Hole in all BGP active routers.

Option-2: If you are running sub-ASs (Private AS for different regions, or Confederation, for easy administration), you might be having eBGP peering at different stages in different segments. Since, next-hop behavior will change with eBGP peering, with option-1, you may end-up fine tuning next-hop value at all those eBGP peers. In these scenarios, simply attach a community value, while advertising it to BGP peers. All BGP aware routers will receive Bogon routes with this community value. Configure all BGP aware routers, with an import policy/route-map matching this community value and set next-hop black-hole.

Someone may be wondering why only BGP for this setup. well, only BGP can advertise routes over non-connected peers and also has the capability to manipulate next-hop value from remote. While IGPs, advertise routes only to their directly connected peers, and they always set the next-hop value to advertising neighbor. 

Caution: 
RTBH, with uRPF (RFC-5635 can be referred for more details), is going to add an extra layer of defense in your network. However, it's really important to understand your network and plan well before you deploy it. 
When you setup RTBH, make sure in any situation, you don't advertise blocked IPs to your external peers. Else, you may end up poisoning your neighbor's network and may also attract traffic for those blocked IPs from your external peers... :P (You can match communities at egress routes and do manual filtering, or use community No-Export).
In some vendors, Auxiliary IPs like 192.0.2.0/24 are treated as Martian or Special Use IPs (Kind of Bogon IP and defined in RFC-3330). If you are having trouble installing them in the routing table. You can either add an exception in Martian list or pick another free private IP.