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. 

NETWORK SECURITY WITH uRPF

Hello Networkers,

Today, I am going to discuss a security methodology uRPF (Unicast Reverse Path Forwarding), which is very useful in preventing DDoS attacks sourced from your internal network.

When a routing device receives a packet, by default it checks destination address in the IP header, then lookup into own routing/forwarding table for next hop address and exit interface for this destination. In this process, device doesn’t look into the source field of IP header. Which may open a flaw for an intruder or compromised systems to perform DDoS attack.

DoS and DDoS

DoS or Denial of Service attack is a way to impact serviceability of a Server by overloading it with a huge amount of requests. For example, if a DNS server which can handle 1000 DNS queries per second. A bad machine generating more than 1000 DNS queries/second will overload DNS server. At this time, all legitimate DNS requests from other hosts will be denied, causing Denial of (DNS) Service in network.

DDoS or Distributed Denial of Service also does the same thing, however, now, attackers may be different machines, attacking all together to impact the serviceability of same Server. Now, even 15-20 machines sending less than 100 DNS requests/second will cause DDoS attack. In terms of impact, DDoS is more powerful and hard to prevent.

Considering same example, we observed that a healthy system even in peak usage generates less than 100 queries per second. So, we can apply restriction of 100 DNS requests/second per source IP on server gateway (or at closest firewall). This restriction can help to prevent DoS attack. However, it will not help in case of a DDoS attack.

Usually, Servers are provisioned to serve much greater services than during peak usage. But some infected machine may generate much more traffic than expected. To make the situation worse, these machines may spoof traffic with different source IP addresses. So, it will look like traffic is coming from different hosts, causing DDoS.

In picture below compromized machine M1 is spoofing source address of N1 and N2 and attacking Server host.

In DDoS attack, targeted volume of attack is summed by multiple hosts (or different spoofed addresses). So, it appears as legitimate traffic and becomes harder to detect and prevent.

Spoofing has few other ways to harm your network. Another way is by performing a passive attack. Attacker can generate traffic from a compromised machine by spoofing source IP of the  target machine and send request to one or multiple destination hosts. Destination Server will return response to target (which was masked in spoof packet). DNS-Zone-transfer attack and NTP attacks are executed by spoofing many machines.

In picture below compromized machines M1 is attacking target S1 by spoofing S1's source address and generating request to nodes N1 and N2.

Compromised machines involved in attack remains hidden. After you know about the attack, your logs will point to source IP of machine, which was masked in spoof packets.

In these attacks, not necessarily, you be the victim, but hackers may use your network to attack some other organizations. This may not only degrade the reputation of your origination but, may also lead to legal actions.

Spoof Prevention:

Now when we understood potential harms about Spoofing, Let’s talk about how to mitigate it. Spoofing can be effectively prevented at origin only. Traffic, the farther travels away from the source, gets harder to identify its legitimacy. So, it’s always better to implement any-spoofing close the each network subnets.

Unicast Reverse Path Forwarding (uRPF) is method to enable capability in network devices to do source lookup while doing packet forwarding. An interface with URPF, when receives a packet, along with destination IP, device inspects its source IP also. Same way, how device does lookup for egress interface associated to destination IP, it resolves ingress interface associated to source IP. If packet is received on resolved ingress interface, it is routed further through egress interface, else, packet dropped.

Implementing URPF

uRPF may be applied in different ways, based on network topology and how routes are learned.

Strict Mode

Strict mode lookup for source subnet and resolve active ingress interface. If packet is received on any other interface, its discarded.

Best and most effective use of strict mode is to apply it on a Lan interfaces or an interface which act as single point of ingress/egress to subnet.

On a Cisco device, command at interface to be used

Interface gi0/0

ip verify unicast source reachable-via rx

On a Juniper Device, command at interface to be used

set interfaces ge-0/0/0 unit 0 family inet rpf-check

Loose Mode

In case of Loose mode, router will lookup for Source IP, and it will process it if specific subnet matching source IP is in routing/forwarding table (it will not strictly check the ingress interface). However, if a routing entry is missing for source IP, it will be discarded.

Loose Mode can be used when you have redundant interfaces for a subnet or if you expect asymmetric paths in the network.

On a Cisco device, command at the interface to be used

interface gi0/0

ip verify unicast source reachable-via any

While on Juniper Devices, command at the interface to be used

set interfaces ge-0/0/0 unit 0 family inet rpf-check mode loose

uRPF with Default Route

Interfaces pointing to default route may not be ideal to apply uRPF, Because, it will either match all possible routes and permit all traffic or will discard all unknown sourced traffic.

However, on a Cisco device, there may be a reason to do so. Enabling uRPF on a Cisco device enables option to lookup for blocked routes. If you have blocked a subnet (Cisco- next hop Null 0, Juniper- next hop discard/reject), router will perform uRPF lookup and if source IP matches discarded route, it will discard packet.

Cisco command,

ip verify unicast source reachable-via {rx | any} allow-default

Juniper don’t recommend enabling uRPF on an interface pointing to default route. Instead, suggest to use the following command to discard traffic source matching route next-hop discard.

set forwarding-options rpf-loose-mode-discard family inet

above command doesn’t need to be applied at interface specific and can be used even when you are not enabling uRPF on any interface of the device.

JunOS also gives option for all traffic which fail uRPF check to imply an action. This action can be permit, discard, log, or any instruction permissible in a firewall filter. This is very useful when dealing with special traffic (eg. DHCP or Multicast traffic). 

set interfaces ge-0/0/0 unit 0 family inet rpf-check fail-filter rpf-special-case-dhcp

set interfaces ge-0/0/0 unit 0 family inet rpf-check mode loose fail-filter rpf-special-case-dhcp

Firewall filter in this example (rpf-special-case-dhcp) can be used to permit DHCP traffic. Note that by default Juniper will discard DHCP traffic due to its IP field info (Source IP: 0.0.0.0, Destination IP: 255.255.255.255). 

set firewall filter rpf-special-case-dhcp term allow-dhcp from source-address 0.0.0.0/32

set firewall filter rpf-special-case-dhcp term allow-dhcp from destination-address 255.255.255.255/32

set firewall filter rpf-special-case-dhcp term allow-dhcp then count rpf-dhcp-traffic

set firewall filter rpf-special-case-dhcp term allow-dhcp then accept

set firewall filter rpf-special-case-dhcp term default then log

set firewall filter rpf-special-case-dhcp term default then reject

In Juniper devices, globally, it can be configured to match exact interface (default) or to consider feasible paths also while doing uRPF check.

set routing-options forwarding-table unicast-reverse-path active-paths

set routing-options forwarding-table unicast-reverse-path feasible-paths  

Validating URPF

uRPF related validations can be done using following commands,

Cisco commands,

show cef interface Gi0/0

show ip interface Gi0/0

show ip traffic

Juniper commands,

show interfaces ge-0/0/0.0 extensive | match RPF 

show firewall

URPF should be always done after proper analysis of the network. Validate all different kind of traffic and routes in the table. Implement uRPF closest to user segment and avoid to at wan where it has less effect. 

Please Share your views and comments.