This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:
4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)
Stay tuned! 😉
Today I drew inspiration from a brand new RFC to add a post to this little series: RFC-5635, Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF).
Especially, I would like to focus on section 4 of this RFC, Source Address RTBH Filtering.
To fully understand this post I would suggest to read my previous post Remote Triggered Black Holing.
What is source-based RTBH? and what are the differences with destination-based RTBH?
This mitigation technique allows an ISP to stop malicious traffic (let’s think to DDOS) on the basis of the source address it comes from. Indeed, destination-based RTBH can just be used to stop traffic on the basis of the attacked hosts addresses, or in the best case, on the couple attacked-hosts/incoming-upstream-provider (you can use different BGP communities to black-hole a prefix only on specific edge routers).
As mentioned in the RFC, if a DDOS software is instructed to attack an host name rather than an IP address, even if you change the IP address resolved by that host name, the attack won’t stop. In this scenario you just have to disrupt the whole service by filtering out the attacked prefix. Source-based RTBH can help you!
How does it work?
Source-based RTBH uses Unicast Reverse Path Forwarding (uRPF) as background mechanism to work.
As RFC says…
uRPF performs a route lookup of the source address of the packet and checks to see if the ingress interface of the packet is a valid egress interface for the packet source address (strict mode) or if any route to the source address of the packet exists (loose mode). If the check fails, the packet is typically dropped.
So, in order to stop incoming traffic from hosts A, B and C toward host Z through router R we just need to add discard routes for A, B and C on router R. And, as seen for destination-based RTBH, we can do it using BGP and communities.
Is that all?
Well, no! Some policy enforcements are due!
As first, in the same way we did for destination-based RTBH, we must use the no-export community to be sure our black-holed prefix doesn’t leave our AS.
Our policy must accept prefixes outside our network (while destination-based RTBH only accepts prefixes within our network) and, as a rule of thumb, we should not accept source-based RTBH prefixes from our customers, but we should just use this tool from management workstations under our control.
The starting configuration is the one we left on the post BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB.
In our scenario source-based RTBH is triggered from the Core router, using tagged static routes redistribution in BGP; nothing different from destination-based RTBH. So, let’s define the tags and communities:
300:300 - tag 300 - global source-based black-hole 300:301 - tag 301 - ISP1 source-based black-hole 300:302 - tag 302 - ISP2 source-based black-hole
On the Core router, here used as RTBH trigger, we have to enable BGP redistribution of static routes tagged with the news tags; indeed, we will trigger RTBH by adding tagged static routes:
route-map RTBH permit 50 match tag 300 set local-preference 200 set origin igp set community 300:300 no-export route-map RTBH permit 60 match tag 301 set local-preference 200 set origin igp set community 300:301 no-export route-map RTBH permit 70 match tag 302 set local-preference 200 set origin igp set community 300:302 no-export
On edge routers facing upstream providers we have to implement our new communities in the route-map:
ip community-list 5 permit 19661100 ! 300:300 ip community-list 5 permit 19661101 ! 300:301 ip community-list 6 permit 19661102 ! 300:302 ! ip as-path access-list 2 permit ^$ ! ip access-list extended InternalNetworks permit ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 deny ip any any ! route-map FROM_RR deny 30 match community 6 ! route-map FROM_RR deny 35 match ip address InternalNetworks match community 5 ! route-map FROM_RR permit 40 match as-path 2 match community 5 set community no-export no-advertise set ip next-hop 192.0.2.1
Here, 300:300 and 300:301 communities (community-list 5) are welcome, while 300:302 community is not accepted – it’s only for ISP2 facing router. Moreover, we just accept prefixes external to our network (192.168.0.0/16).
Similar config is on Edge2:
ip community-list 5 permit 19661100 ! 300:300 ip community-list 5 permit 19661102 ! 300:302 ip community-list 6 permit 19661101 ! 300:301 ! ip as-path access-list 2 permit ^$ ! ip access-list extended InternalNetworks permit ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255 deny ip any any ! route-map FROM_RR deny 30 match community 6 ! route-map FROM_RR deny 35 match ip address InternalNetworks match community 5 ! route-map FROM_RR permit 40 match as-path 2 match community 5 set community no-export no-advertise set ip next-hop 192.0.2.1
Finally, we have to enable uRPF on ISP-facing interfaces; we use the loose mode here:
interface Serial1/0 ip address 172.16.1.1 255.255.255.252 ip verify unicast source reachable-via any
interface Serial1/0 ip address 172.16.2.1 255.255.255.252 ip verify unicast source reachable-via any
To test the solution we have to add another loopback interface to ISPs routers, in order to have two different source IP addresses for each ISP:
interface Loopback1 ip address 10.0.1.2 255.255.255.255 ! router bgp 100 network 10.0.1.2 mask 255.255.255.255
interface Loopback1 ip address 10.0.2.2 255.255.255.255 ! router bgp 200 network 10.0.2.2 mask 255.255.255.255
Now, suppose we have an attack from ISP1 Loopback1 toward Cust10 (so, from 10.0.1.2 to 192.168.10.1).
We can stop the attack using destination-based RTBH, but traffic from Loopback0 will be disrupted too:
Core(config)#ip route 192.168.10.1 255.255.255.255 null0 tag 101
ISP1#ping 192.168.10.1 so lo1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds: Packet sent with a source address of 10.0.1.2 ..... Success rate is 0 percent (0/5) ISP1#ping 192.168.10.1 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 ..... Success rate is 0 percent (0/5)
As you can see, both source addresses can’t reach our host.
So, let’s try our new solution; as first remove the previous RTBH filter:
Core(config)#no ip route 192.168.10.1 255.255.255.255 null0 tag 101
then trigger the source-based filtering for the attacking IP address:
Core(config)#ip route 10.0.1.2 255.255.255.255 null0 tag 301
Edge1 receives the new BGP announcement and it adds the discard interface route:
Edge1#sh ip route bgp | i 10.0.1.2 B 10.0.1.2 [200/0] via 192.0.2.1, 00:01:03 Edge1#sh ip cef 10.0.1.2 10.0.1.2/32, version 32, epoch 0 0 packets, 0 bytes via 192.0.2.1, 0 dependencies, recursive next hop 192.0.2.1, Null0 via 192.0.2.1/32 valid null adjacency
As we can see, packets from ISP1 Loopback1 are dropped at Edge1, while packets from Loopback0 pass:
ISP1#ping 192.168.10.1 so lo1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds: Packet sent with a source address of 10.0.1.2 ..... Success rate is 0 percent (0/5) ISP1#ping 192.168.10.1 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds: Packet sent with a source address of 10.0.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 476/608/724 ms
You can download the updated GNS3 file and configs here. The ZIP file contains multiple config subdirectories, one for each step covered on previous posts, and the new “6. Source-based RTBH filtering”.
Latest posts by Pier Carlo Chiodi (see all)
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
- RFC7050 (DNS64 prefix via ipv4only.arpa) on RIPE Atlas probes - 9 March 2016