IOS-XE Remote Triggered Blackhole

IOS-XE Remote Triggered Blackhole

Remotely Triggered Black Hole (RTBH) is a filtering technique that is used for mitigating Distributed Denial of Service (DDoS)/worm attacks and quarantine all traffic destined for the target host. RTBH is used by Large Enterprise customers and Internet Service Providers (ISPs) to black hole the undesirable traffic.

A trigger router is used to send a static route via iBGP to the edge router(s), which sets the next hop IP address to an unused IP address, the route to this IP address is via the null0 interface, resulting in the undesirable traffic to be dropped at the edge.

There are two types of RTBH:

  • Destination-based RTBH – the destination IP address of the host being attack is black holed at the network edge. This obviously means the destination host server is inaccessible, but this results in conserving the routing infrastructure resources (CPU, memory etc) in the rest of the network.
  • Source-based RTBH – black holes the source IP address of the attacker(s) at the network edge. The destination host is still active and could theoretically still process other requests.

The figure below represents RTBH topology at a very high-level, highlighting the key components and traffic flow.

In this post RTBH will be configured on Cisco IOS-XE routers.

Source Based RTBH

Source based RTBH relies on Unicast Reverse Path Forwarding (uRPF) feature, which will drop any source route with a next hop of null0. Refer to the previous post for more information about uRPF.

Trigger Router

Define a static route for the “source” IP address to match the malicious host, with a tag of 666 to ensure this matches the route-map. Traffic matching the IP address 1.1.1.1 will be dropped on the edge router.

ip route 1.1.1.1 255.255.255.255 192.0.2.1 tag 666

A static route for the next hop (192.0.2.1) defined in the route-map must be defined for the RTBH route to be redistributed.

ip route 192.0.2.1 255.255.255.255 Null0

A route-map is defined with the following configuration:

  • Match on the tag number (666) of the static route, defined above. Only static routes with a tag of 666 will be sent to the edge router.
  • Set the next hop of 192.0.2.1, which on the edge router is routed to the null0 interface
  • Set community no-export, to ensure the edge routers do not export the prefix to external BGP peers.
  • Set the local preference greater than 100
  • Set the origin of the route to be igp
route-map RTBH permit 10
 match tag 666
 set local-preference 200
 set origin igp
 set community no-export
 set ip next-hop 192.0.2.1
route-map RTBH deny 20

Configure BGP AS, establish adjacency to the Edge router and redistribute static routes matching the route-map RTBH.

router bgp 65000
 bgp router-id 192.168.251.2
 redistribute static route-map RTBH
 neighbor 192.168.251.1 remote-as 65000
 neighbor 192.168.251.1 route-reflector-client

Edge Router

Configure the outside facing interface with uRPF

interface GigabitEthernet0/0
 ip address 192.168.249.1 255.255.255.0
 ip verify unicast source reachable-via any allow-default 101

Configure a BGP relationship with the “trigger router” to receive the RTBH routes.

router bgp 65000
 bgp router-id 192.168.251.1
 bgp log-neighbor-changes
 neighbor 192.168.251.2 remote-as 65000

Configure a static route for 192.0.2.1 via null0. This IP address is the next hop IP address sent from the trigger router and must be routed to null0.

ip route 192.0.2.1 255.255.255.255 Null0

Optional, create an ACL for uRPF logging for additional visibility.

ip access-list logging hash-generation
 access-list 101 deny ip any any log ANTI-SPOOF

Verification

From the Edge router, run show ip bgp. From the output below we can determine that the static route has been learnt from the trigger router. The route 1.1.1.1 has the next hop of 192.0.2.1, which would result in the packet being routed to the null0 interface.

RTR#show ip bgp
BGP table version is 5, local router ID is 192.168.251.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found
     Network          Next Hop            Metric LocPrf Weight Path
 *>i  1.1.1.1/32       192.0.2.1                0    200      0 i
 *>i  192.168.10.0     192.168.251.2            0    100      0 i

By generating traffic from the source IP address of 1.1.1.1 we can confirm the communication fails but attempts from a different IP address works as expected. Confirming the source based RTBH is working as expected.

R5#ping 10.10.10.10 source loopback 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)
!
R5#ping 10.10.10.10 source loopback 2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/18/24 ms

With uRPF logging enabled on the Edge router, we can confirm the ICMP packet from 1.1.1.1 is denied.

*Aug 16 14:58:59.033: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 1.1.1.1 -> 10.10.10.10 (0/0), 5 packets [ANTI-SPOOF]

You can confirm the routing updates are received on the edge router, run debug bgp all updates in. From the output below you can confirm the correct next hop, localpref and IP address which was added to the global routing table.

*Aug 16 15:16:35.716: BGP(0): 192.168.251.2 rcvd UPDATE w/ attr: nexthop 192.0.2.1, origin i, localpref 200, metric 0
*Aug 16 15:16:35.721: BGP(0): 192.168.251.2 rcvd 1.1.1.1/32
*Aug 16 15:16:35.723: BGP(0): Revise route installing 1 of 1 routes for 1.1.1.1/32 -> 192.0.2.1(global) to main IP table

Destination Based RTBH

The only difference between source based and destination based RTBH, is with destination based uRPF is not used. The configuration is the same, except a static IP address for the destination host is defined as a static route on the trigger route and sent via iBGP to the edge router, which sends any traffic destined to that IP address to the null0 interface.

Trigger Router

Define a static route “destination” IP address to match the malicious host, with a tag of 666 to ensure this matches the route-map. Traffic sent to thes IP address 192.168.251.2 will be dropped on the edge router.

ip route 10.10.10.10 255.255.255.255 192.0.2.1 tag 666

A static route for the next hop (192.0.2.1) defined in the route-map must be defined for the RTBH route to be redistributed.

ip route 192.0.2.1 255.255.255.255 Null0

A route-map with the following configuration:

  • Match on the tag number (666) of the static route, defined above.
  • Set the next hop of 192.0.2.1, which on the edge router is routed to the null0 interface
  • Set community no-export, to ensure the edge routers do not export the prefix to external BGP peers.
  • Set the local preference greater than 100
  • Set the origin of the route to be igp
route-map RTBH permit 10
 match tag 666
 set local-preference 200
 set origin igp
 set community no-export
 set ip next-hop 192.0.2.1
route-map RTBH deny 20

Configure BGP AS, establish adjacency to the Edge router and redistribute static routes matching the route-map RTBH.

router bgp 65000
 redistribute static route-map RTBH
 neighbor 192.168.251.1 remote-as 65000
 neighbor 192.168.251.1 route-reflector-client

Edge Router

interface GigabitEthernet0/0
 ip address 192.168.249.1 255.255.255.0

Configure a BGP relationship with the “trigger router” to receive the RTBH routes.

router bgp 65000
 bgp router-id 192.168.251.1
 bgp log-neighbor-changes
 neighbor 192.168.251.2 remote-as 65000

Configure a static route for 192.0.2.1 via null0. This IP address is the next hop IP address sent from the trigger router and must be routed to null0.

ip route 192.0.2.1 255.255.255.255 Null0

Verification

From the attacker host ping 10.10.10.10 and confirm there is no communication

R5#ping 10.10.10.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

On the edge router, run show ip route 10.10.10.10 and confirm the next hop is 192.0.2.1

SWI1#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
  Known via "bgp 65000", distance 200, metric 0, type internal
  Last update from 192.0.2.1 00:00:10 ago
  Routing Descriptor Blocks:
  * 192.0.2.1, from 192.168.251.2, 00:00:10 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0
      MPLS label: none

Unlike with Source based RTBH there is no confirmation via uRPF logging that connection is dropped.

With destination based RTBH, all connections via the Edge router to the destination host will be black holed, this would include legitimate traffic.

Tags: , ,