In the last article, we introduced Remotely Triggered Black Hole (RTBH) and configured destination-based RTBH. In this article, we will look at the second type of RTBH, which is source-based RTBH, and also discuss another method that can be used to configure RTBH other than using the next-hop approach.

Source-based RTBH

As discussed in the previous article, one of the problems with destination-based RTBH is that all traffic to the target of the attack is dropped, whether it’s legitimate traffic or malicious traffic. If we can determine the source of the attack, then it is definitely better to filter traffic from just that source address.

Note: It may not always be possible to determine the source of a DoS attack (because the spoofed address is always changing) and so one may have to rely more on destination-based RTBH than source-based RTBH.

The diagram below, which is available from Cisco, illustrates how source-based RTBH works:

From a configuration standpoint, source-based RTBH is very similar to destination-based RTBH with the addition of one thing – Unicast Reverse Path Forwarding (uRPF). By default, routers forward IP traffic by looking at the destination only, but to perform source-based RTBH, we want to drop traffic from a source. So how do we go about it?

uRPF enables a router to verify the source address of traffic that is being forwarded. The two main modes that uRPF can operate in are strict mode and loose mode.

Note: There is a third mode on the Cisco IOS called VRF mode but it is not relevant to our discussion.

In strict mode, the router verifies that the interface on which it receives a packet is the same interface it will use to forward the return packet. In short, strict mode does not allow for asymmetric routing. For source-based RTBH though, we usually use loose mode which just verifies that there is a valid route for the source address in the routing table of the router.

The reason we prefer uRPF in loose mode is that if the source address is pointing to null0, it is dropped. Therefore, all we need is for the trigger router to advertise the identified source address of the attack with a next-hop that will eventually point to null0 on the edge routers.

Source-based RTBH can therefore be explained in the following points:

  • The trigger router and edge routers have iBGP peering relationships. If a route reflector is configured for the edge routers, then the trigger router only needs to peer with the route reflector.
  • The edge routers have a static route for an unused IP address space (e.g. 192.0.2.2) pointing to the null0 interface. These routers also have uRPF enabled on their external facing interfaces.
  • When an attack occurs, a network administrator configures a static route for the source address on the trigger router. This trigger router is then configured to advertise the static route, setting the next-hop of that route to the unused IP address configured on the edge routers.
  • When the edge routers receive this route advertisement, the next-hop for that source address points to the unused IP address which is in turn configured to point to null0. This makes the RPF check fail and thus, any traffic from the attacker’s source address sent to the edge routers is effectively dropped.
  • When the attack passes, the network administrator only has to remove the static route configured on the trigger router so that the route is withdrawn and traffic from the source address can be forwarded again.

To see this in action, we will use the same topology we used in the previous article:

The configuration on the trigger router remains fairly the same, but to keep in line with best practices, I will use a different route tag and also a different “unused IP address” for our source-based RTBH configuration from the one we used for destination-based RTBH.

<PRE>

interface Ethernet0/0

ip address 192.168.20.2 255.255.255.0

!

route-map TRIGGER permit 10

match tag 999

set ip next-hop 192.0.2.1

set local-preference 200

set origin igp

set community no-export

!

route-map TRIGGER permit 20

match tag 666

set ip next-hop 192.0.2.2

set local-preference 200

set origin igp

set community no-export

!

route-map TRIGGER deny 30

!

router bgp 1

neighbor EDGE-RTRS peer-group

neighbor EDGE-RTRS remote-as 1

neighbor EDGE-RTRS send-community

neighbor 192.168.20.1 peer-group EDGE-RTRS

redistribute static route-map TRIGGER

!

ip route 192.0.2.1 255.255.255.255 null0

ip route 192.0.2.2 255.255.255.255 null0

</PRE>

With this configuration, when an attack is occurring and we can determine the source address, we just configure a static route for that source address with a tag of 666. If we can’t determine the source address, then we fall back to destination-based RTBH and configure a static route for the target address with a tag of 999.

The configuration on the edge router is also similar to our last configuration but since I am using a different unused IP address space, I have to point that address to null0.

<PRE>

interface Ethernet0/0

ip address 192.168.20.1 255.255.255.0

!

interface Ethernet0/1

ip address 192.168.10.1 255.255.255.0

!

interface Ethernet0/2

ip address 10.0.0.1 255.255.255.0

!

router bgp 1

neighbor 192.168.20.2 remote-as 1

!

ip route 192.0.2.1 255.255.255.255 null0

ip route 192.0.2.2 255.255.255.255 null0

</PRE>

Let us test this configuration. As in the last article, we will simulate a DoS attack by sending large ping packets with a high repeat count from the attacker (192.168.10.100) to the target (10.0.0.100).

As the administrator, we notice that the target is under attack and we have determined the source of that attack as 192.168.10.100. Therefore, we can configure a static route on the trigger router for that source IP address with a tag of 666:

<PRE>ip route 192.168.10.100 255.255.255.255 null0 tag 666</PRE>

Because this route matches the TRIGGER route-map sequence 20, it will be redistributed via BGP to the edge router with the BGP attributes we configured:

Looking at the CEF table, we see that this route will eventually point to null0:

Once the edge router receives that route from the trigger router, traffic from the attacker is dropped:

We can check the verification drops using the commands show ip interface and show ip traffic:

To show you that traffic to the target from other source addresses are not dropped, let us change the IP address of the attacker and ping again.

Community-based Approach

Rather than the trigger router setting the next-hop for the traffic to be black holed, we can configure the trigger router to set different communities which may have different policies on the edge routers. This allows for more flexibility and control of how traffic is dropped.

For example, in the diagram below, we will configure the trigger router to set different community values for the two edge routers. On the edge routers, we can then configure what policies should apply to the received community values.

An example of where this is useful is when it has been determined that an attack is coming in through one of the edge routers and not the other. By applying different policies, we can ensure that only traffic from the edge router in the attack path is dropped – traffic forwarded by the other edge router to the target still goes through.

The configuration on the trigger router is as follows:

<PRE>

ip bgp-community new-format

!

route-map RTBH permit 10

match tag 9991

set community 999:1 no-export

route-map RTBH permit 20

match tag 9992

set community 999:2 no-export

!

router bgp 1

redistribute static route-map RTBH

neighbor EDGE-RTRS peer-group

neighbor EDGE-RTRS remote-as 1

neighbor EDGE-RTRS send-community

neighbor 192.168.20.1 peer-group EDGE-RTRS

neighbor 192.168.20.254 peer-group EDGE-RTRS

</PRE>

On EDGE-RTR, the relevant configuration is as follows:

<PRE>

ip bgp-community new-format

ip community-list 1 permit 999:1

!

route-map RTBH permit 10

match community 1

set ip next-hop 192.0.2.1

!

router bgp 1

neighbor 192.168.20.2 route-map RTBH in

</PRE>

On EDGE-RTR2, the relevant configuration is as follows:

<PRE>

ip bgp-community new-format

ip community-list 1 permit 999:2

!

route-map RTBH permit 10

match community 1

set ip next-hop 192.0.2.1

!

router bgp 1

neighbor 192.168.20.2 route-map RTBH in

</PRE>

With this configuration, if the trigger router advertises a route with a tag of 9991, only EDGE-RTR will black hole the traffic; EDGE-RTR2 will forward traffic normally:

However, if we also advertise that route with a tag of 9992, EDGE-RTR2 will also drop the traffic:

 

Summary

This brings us to the end of this two-part series where we have looked at Remotely Triggered Black Hole. In this article, we configured source-based RTBH and also looked at another approach, using communities, to configure RTBH.

I hope you have found this series insightful.

References and Further reading