Remote Triggering Black Hole Filtering(RTBH)
INTRODUCTION
Black hole filtering is a flexible ISP Security tool that will route packets to Null0 (i.e.black holed). The Cisco ISP Essentials book covers the fundamentals of the singlerouter based black hole routing technique. It does not cover the remote triggered black hole routing technique. Remote triggering via iBGP allows ISPs to active anetwork wide destination based black hole throughout their network. This techniqueis especially useful in some of the new ISP security classification, traceback, and reaction techniques. This supplement reviews, enhances, and adds to what is already in the book.
BLACK HOLE ROUTING AS A PACKET FILTER (FORWARDING TO NULL0)
Forwarding packets to Null 0 is a common way to filter packets to a specific destination. These are often done by creating specific static host routes and point them to the pseudo interface Null0. This technique commonly refereed as black hole routing or black hole filtering. Null0 is a pseudo-interface, which functions similarly to the null devices available on most operating systems. This interface is always up and can never forward or receive traffic. While Null0 is a pseudo interface, within CEF, it is not a valid interface. Hence, whenever a route is pointed to Null0, itwill be dropped via CEF’s and dCEF’s.
The null interface provides an alternative method of filtering traffic. You can avoid the overhead involved with using access lists by directing undesired network traffic to the null interface. The following example configures a null interface for IP route 127.0.0.0/16 and the specific host 171.68.10.1 (subnet mask 255.255.255.255):
The no icmp unreachables command is used to prevent unnecessary ICMP Unreachable replies whenever traffic is passed to the Null0 interface. This minimizes the risk of router getting overloaded with hundreds of pending ICMP Unreachable replies. So it is common practice to use the no ip unreachablescommand on the Null0 interface. Yet, they may be cases where you want the routerto respond to with ICMP Unreachables. For these cases, you the ip icmp unreachable rate-limit command to minimize the risk of a router getting over loaded with ICMP Unreachable processing. This specific rate-limiting command adjusts the default of on ICMP Unreachable every 500ms to a value between 1ms to4294967295 ms.
Black Hole filtering uses the strength of the router’s forwarding performance to dropblack listed packets. A router's #1 job is for forward packets - not filtering packets. The black hole routing technique uses the packet forwarding power to drop all packets bound for sites on the black list. In the ASIC forwarding world, this black holing has zero impact in the performance of the router (packets black holed to Null0 are cleared through a register clock). Software forwarding devices have some extracycles needed to clear out and black holed packet. If a software-forwarding device is expected to do a lot of black hole work, consider a black hole shunt interface (seethe section on black hole shunts).
There are two main limitations to with the black hole filtering technique.
First, blackhole filtering is L3 only – not L4. So access to all L4 services at a give site will beblocked. If selective L4 filtering is necessary, use extended ACLs. For example, if you wish to drop all packets to a specific destination, the black hole filtering isapplicable. But, if you wish to drop all telnet packets to a destination, then black hole filtering is no applicable and a extended ACL is the optimum mitigation tool. Extended ACLs offer the fine L4 granularity needed to filter at the application level.
Second, it is hard to bypass or provide exceptions with the black hole filteringtechnique. Any organization that wishes to by-pass the black list must actually find away to by-pass the filtering router's forward table. Compensation for either limitationare not trivial tasks. Yet. With due consideration and planning, options are availablefor both.
REMOTE TRIGGERED BLACK HOLE FILTERING
Black Hole Filtering on a single router has been around the industry since the last 1980s. It is a useful tool on a single router. But, how do you use this tool when you have a network of hundreds of routers? How do you log into hundreds of routers onthe edge of a network and configure a black hole filter? The answer is in you don’t. ISPs engineers who respond to a security incident needs to think of their keystrength – routing. ISPs engineers know how to route traffic – putting the traffic where they want it to flow through their network. Remote Triggered Black HoleFiltering uses that routing strength to trigger all the routers in the network with arouting update. The routing update – sent via iBGP by a trigger router – actives apre-configured static route to activate a black hole for the destination address.
Lets use an example to illustrate the concept and strength of this technique. Figure 2 illustrates an ISP’s customer under attack by a DDOS. The DDOS is coming in from all the entry points of the ISP’s network. These entry points can number from a few to thousands – depending on the size of the ISP. DDOS traffic far exceeds the customer’s link, so the circuit saturates, causing either DOS Flapping1 or co-lateral damage inside the POP. This collateral threats other customers, the POP, and that section of the ISP’s network. An immediate reaction is necessary to shift the packet drops from the customer’s circuit and collateral routers to the edge of the network.
Remote Triggered Black Hole filtering is used to push the packet drops off the customer/POP routers and shift them to the edge of the network. Figure 3 shows how an ISP uses a trigger router in the NOC to send an iBGP advertisement. This iBGP advertisement has the prefix of the customer under attack with metric attached to insure it becomes the preferred path. This iBGP “trigger” advertisement goes to all the iBGP specking routers in the ISP’s network. These routers all have an unused prefix that points to Null 0. The iBGP “trigger” advertisement has its next-hop equal to this “Null0ed prefix.” When the “iBGP trigger advertisement reaches the router, it gets glued to the static, activating the Null0 black hole, and having all traffic to the customer’s prefix get dropped on the edge of the ISP’s network.
The key benefit in this situation is that dropping on the edge of the network mitigates the DDOS’s aggregated traffic load. This now gives the ISP and the customer time to work the attack with out the worries of collateral damage to other customers.
REMOTE TRIGGERING SAFETY MEASURES
Remote Triggering via iBGP requires the ISP to take some safety measures to insure the iBGP trigger advertisement does not leak out and affect other networks. There are several ways this can be done. Appling the principle of Murphy’s Law of Networking, it is recommended that an ISP implement several– if not all– of these safety measures.
．No-export BGP community.
The no-export community in BGP is a well-known value that most routers recognize by default. It should – when working properly – keep the prefix within the ISP (i.e. no advertisements to peers).
．Extra Community that filters.
The ISP can add a community that does the same as the no-export community. A BGP community filter will be used on with the ISP’s peers to mark which communities are exported. This step helps prevent a leak by someone who is cleaning up the excess communities in the prefix – inadvertently filtering the no-export community.
．Lower Boundary on the Egress Prefix Filter.
ISPs can place a lower boundary on the prefixes sent to their peers. For example, ISPs can block all prefixes less than /24. This would filter any iBGP trigger advertisement between /25 and /32 – which is a normal range of addresses blocks allocated to customers.
PREPARING THE NETWORK FOR REMOTE TRIGGERED BLACKHOLE FILTERING
It is imperative that ISPs prepare for remote triggered black hole filtering, practice the technique, and have everything ready long before using it to mitigate an attack. Fortunately, all the preparation steps involve non-intrusive configurations that have no impact on the operation of the network.
Step 1- Configure the Static Route to Null0 on All the Routers
The first of these preparation steps is the configuration of a static route on each ofthe routers that will be triggered. This is a prefix that will never be used in thenetwork. It can be a block of addresses allocated from the RIR allocations. It can bea RFC 1918 prefix. The author's favorite is to use the Test-Net: 192.0.2.0/24. Test-Net was a IANA allocation made for people to do documentation. The idea was fordocumentation to use a block of addresses that would never get used. That waycustomers who copy the documentation will not mess up someone else's network.Hence, Test-Net is one of the IANA Designated Special Use Addresses (DUSA) that should never appear on the Internet …… making it a great choice for the static route for remote-triggered Black Hole Filtering.
Step 2 – Prepare the Trigger Router
The trigger router does not have to be a big router. A Cisco 26XX or 36XX router configured as an iBGP route reflector client and accepting no routes works very wellas a trigger router. In fact, the trigger router does not have to be a dedicated router. A production router can be used. For this example, we will be using a dedicatedtrigger router.
On the router, the iBGP is configured to redistribute static routes. That way the “trigger” is an engineer or tool adding and removing static routes. A route-map isused to match the static tag and set all the metrics for the iBGP advertisement. That way all triggering is consistent and done the same way each time.
In the above example, we match a static tag of 66. If matched, we set the iBGP next-hop to the Test-Net (pre-configured on the routers to Null0), set the local preference to 50 (to override the original customer advertisement), set the BGP community to no-export with a safety community of 600:000 (which blocks advertisement, and finally set the origin to igp. This sets up the trigger router to be ready for the timewhen the ISP needs for rapid reaction.
Step 3 - Activation
The ISP adds a static route with a tag of 66 to activate the remote-triggered blackhole. In this example, we'll use 171.68.1.1 as a the address under attack. So we add this static with the tag of 66:
The trigger router will then send a advertisement to all the iBGP speaking routers inthe network (see Figure 3). When the iBGP advertisement is received, the BGP RIB sees the local preference of 50 and selects this new path as the best path. The recursive look-up passes since there is a static route to this new path’s next-hop (i.e. the Test-Net). This iBGP best path is passed from the BGP RIB to the router’s FIB. The FIB sees the prefix, the next-hop of Test-Net, and Test-Net’s next-hop of Null0. It then glues them together (depending on the FIB technology used) resulting 171.68.1.1 now having a next-hop of Null0.
This is visually illustrated in Figure 4.
One of the key advantages of remote triggered black hole is the number of prefixes that can be filtered. The limit is the size of the FIB routers in the network can carry. This would mean thousands of black holed prefixes being added. It is just a factor of adding more static routes to the trigger router. Principles of aggregation can be used, but mindfulness needs to be applied to make sure the iBGP trigger advertisement is equal to or more specific to the original customer advertisement.
Step 4 – Removing Trigger Advertisement
The trigger advertisement will need to be removed when the attack is over or the ISP wishes to move to a different mitigation technique. Removing the static route doesthis. The trigger router will then send out a iBGP withdrawal to all its BGP peers, which in then will withdraw the route from the BGP RIB, which then pulls the routefrom the route's FIB. This clears the path for the router's BGP RIB to select theoriginal customer advertisement, placing that prefix as the best path, and allowingthe FIB to resume normal forwarding to the customer's network.
Black hole filtering is a flexible ISP Security tool that will route packets to Null0 (i.e.black holed). The Cisco ISP Essentials book covers the fundamentals of the singlerouter based black hole routing technique. It does not cover the remote triggered black hole routing technique. Remote triggering via iBGP allows ISPs to active anetwork wide destination based black hole throughout their network. This techniqueis especially useful in some of the new ISP security classification, traceback, and reaction techniques. This supplement reviews, enhances, and adds to what is already in the book.
BLACK HOLE ROUTING AS A PACKET FILTER (FORWARDING TO NULL0)
Forwarding packets to Null 0 is a common way to filter packets to a specific destination. These are often done by creating specific static host routes and point them to the pseudo interface Null0. This technique commonly refereed as black hole routing or black hole filtering. Null0 is a pseudo-interface, which functions similarly to the null devices available on most operating systems. This interface is always up and can never forward or receive traffic. While Null0 is a pseudo interface, within CEF, it is not a valid interface. Hence, whenever a route is pointed to Null0, itwill be dropped via CEF’s and dCEF’s.
The null interface provides an alternative method of filtering traffic. You can avoid the overhead involved with using access lists by directing undesired network traffic to the null interface. The following example configures a null interface for IP route 127.0.0.0/16 and the specific host 171.68.10.1 (subnet mask 255.255.255.255):
interface Null0
no icmp unreachables
ip route 127.0.0.0 255.0.0.0 null 0
ip route 171.68.10.1 255.255.255.255 null 0
The no icmp unreachables command is used to prevent unnecessary ICMP Unreachable replies whenever traffic is passed to the Null0 interface. This minimizes the risk of router getting overloaded with hundreds of pending ICMP Unreachable replies. So it is common practice to use the no ip unreachablescommand on the Null0 interface. Yet, they may be cases where you want the routerto respond to with ICMP Unreachables. For these cases, you the ip icmp unreachable rate-limit command to minimize the risk of a router getting over loaded with ICMP Unreachable processing. This specific rate-limiting command adjusts the default of on ICMP Unreachable every 500ms to a value between 1ms to4294967295 ms.
ip icmp rate-limit unreachable 2000
ip icmp rate-limit unreachable DF 2000Black Hole filtering uses the strength of the router’s forwarding performance to dropblack listed packets. A router's #1 job is for forward packets - not filtering packets. The black hole routing technique uses the packet forwarding power to drop all packets bound for sites on the black list. In the ASIC forwarding world, this black holing has zero impact in the performance of the router (packets black holed to Null0 are cleared through a register clock). Software forwarding devices have some extracycles needed to clear out and black holed packet. If a software-forwarding device is expected to do a lot of black hole work, consider a black hole shunt interface (seethe section on black hole shunts).
There are two main limitations to with the black hole filtering technique.
First, blackhole filtering is L3 only – not L4. So access to all L4 services at a give site will beblocked. If selective L4 filtering is necessary, use extended ACLs. For example, if you wish to drop all packets to a specific destination, the black hole filtering isapplicable. But, if you wish to drop all telnet packets to a destination, then black hole filtering is no applicable and a extended ACL is the optimum mitigation tool. Extended ACLs offer the fine L4 granularity needed to filter at the application level.
Second, it is hard to bypass or provide exceptions with the black hole filteringtechnique. Any organization that wishes to by-pass the black list must actually find away to by-pass the filtering router's forward table. Compensation for either limitationare not trivial tasks. Yet. With due consideration and planning, options are availablefor both.
REMOTE TRIGGERED BLACK HOLE FILTERING
Black Hole Filtering on a single router has been around the industry since the last 1980s. It is a useful tool on a single router. But, how do you use this tool when you have a network of hundreds of routers? How do you log into hundreds of routers onthe edge of a network and configure a black hole filter? The answer is in you don’t. ISPs engineers who respond to a security incident needs to think of their keystrength – routing. ISPs engineers know how to route traffic – putting the traffic where they want it to flow through their network. Remote Triggered Black HoleFiltering uses that routing strength to trigger all the routers in the network with arouting update. The routing update – sent via iBGP by a trigger router – actives apre-configured static route to activate a black hole for the destination address.
Lets use an example to illustrate the concept and strength of this technique. Figure 2 illustrates an ISP’s customer under attack by a DDOS. The DDOS is coming in from all the entry points of the ISP’s network. These entry points can number from a few to thousands – depending on the size of the ISP. DDOS traffic far exceeds the customer’s link, so the circuit saturates, causing either DOS Flapping1 or co-lateral damage inside the POP. This collateral threats other customers, the POP, and that section of the ISP’s network. An immediate reaction is necessary to shift the packet drops from the customer’s circuit and collateral routers to the edge of the network.
Remote Triggered Black Hole filtering is used to push the packet drops off the customer/POP routers and shift them to the edge of the network. Figure 3 shows how an ISP uses a trigger router in the NOC to send an iBGP advertisement. This iBGP advertisement has the prefix of the customer under attack with metric attached to insure it becomes the preferred path. This iBGP “trigger” advertisement goes to all the iBGP specking routers in the ISP’s network. These routers all have an unused prefix that points to Null 0. The iBGP “trigger” advertisement has its next-hop equal to this “Null0ed prefix.” When the “iBGP trigger advertisement reaches the router, it gets glued to the static, activating the Null0 black hole, and having all traffic to the customer’s prefix get dropped on the edge of the ISP’s network.
The key benefit in this situation is that dropping on the edge of the network mitigates the DDOS’s aggregated traffic load. This now gives the ISP and the customer time to work the attack with out the worries of collateral damage to other customers.
REMOTE TRIGGERING SAFETY MEASURES
Remote Triggering via iBGP requires the ISP to take some safety measures to insure the iBGP trigger advertisement does not leak out and affect other networks. There are several ways this can be done. Appling the principle of Murphy’s Law of Networking, it is recommended that an ISP implement several– if not all– of these safety measures.
．No-export BGP community.
The no-export community in BGP is a well-known value that most routers recognize by default. It should – when working properly – keep the prefix within the ISP (i.e. no advertisements to peers).
．Extra Community that filters.
The ISP can add a community that does the same as the no-export community. A BGP community filter will be used on with the ISP’s peers to mark which communities are exported. This step helps prevent a leak by someone who is cleaning up the excess communities in the prefix – inadvertently filtering the no-export community.
．Lower Boundary on the Egress Prefix Filter.
ISPs can place a lower boundary on the prefixes sent to their peers. For example, ISPs can block all prefixes less than /24. This would filter any iBGP trigger advertisement between /25 and /32 – which is a normal range of addresses blocks allocated to customers.
PREPARING THE NETWORK FOR REMOTE TRIGGERED BLACKHOLE FILTERING
It is imperative that ISPs prepare for remote triggered black hole filtering, practice the technique, and have everything ready long before using it to mitigate an attack. Fortunately, all the preparation steps involve non-intrusive configurations that have no impact on the operation of the network.
Step 1- Configure the Static Route to Null0 on All the Routers
The first of these preparation steps is the configuration of a static route on each ofthe routers that will be triggered. This is a prefix that will never be used in thenetwork. It can be a block of addresses allocated from the RIR allocations. It can bea RFC 1918 prefix. The author's favorite is to use the Test-Net: 192.0.2.0/24. Test-Net was a IANA allocation made for people to do documentation. The idea was fordocumentation to use a block of addresses that would never get used. That waycustomers who copy the documentation will not mess up someone else's network.Hence, Test-Net is one of the IANA Designated Special Use Addresses (DUSA) that should never appear on the Internet …… making it a great choice for the static route for remote-triggered Black Hole Filtering.
ip route 192.0.2.0 255.255.255.0 Null0Step 2 – Prepare the Trigger Router
The trigger router does not have to be a big router. A Cisco 26XX or 36XX router configured as an iBGP route reflector client and accepting no routes works very wellas a trigger router. In fact, the trigger router does not have to be a dedicated router. A production router can be used. For this example, we will be using a dedicatedtrigger router.
On the router, the iBGP is configured to redistribute static routes. That way the “trigger” is an engineer or tool adding and removing static routes. A route-map isused to match the static tag and set all the metrics for the iBGP advertisement. That way all triggering is consistent and done the same way each time.
router bgp 109
redistribute static route-map static-to-bgp
!
route-map static-to-bgp permit 10
match tag 66
set ip next-hop 192.0.2.1
set local-preference 50
set community no-export 600:000
set origin igp
!
route-map static-to-bgp permit 20
In the above example, we match a static tag of 66. If matched, we set the iBGP next-hop to the Test-Net (pre-configured on the routers to Null0), set the local preference to 50 (to override the original customer advertisement), set the BGP community to no-export with a safety community of 600:000 (which blocks advertisement, and finally set the origin to igp. This sets up the trigger router to be ready for the timewhen the ISP needs for rapid reaction.
Step 3 - Activation
The ISP adds a static route with a tag of 66 to activate the remote-triggered blackhole. In this example, we'll use 171.68.1.1 as a the address under attack. So we add this static with the tag of 66:
ip route 171.68.1.1 255.255.255.255 Null0 Tag 66The trigger router will then send a advertisement to all the iBGP speaking routers inthe network (see Figure 3). When the iBGP advertisement is received, the BGP RIB sees the local preference of 50 and selects this new path as the best path. The recursive look-up passes since there is a static route to this new path’s next-hop (i.e. the Test-Net). This iBGP best path is passed from the BGP RIB to the router’s FIB. The FIB sees the prefix, the next-hop of Test-Net, and Test-Net’s next-hop of Null0. It then glues them together (depending on the FIB technology used) resulting 171.68.1.1 now having a next-hop of Null0.
This is visually illustrated in Figure 4.
One of the key advantages of remote triggered black hole is the number of prefixes that can be filtered. The limit is the size of the FIB routers in the network can carry. This would mean thousands of black holed prefixes being added. It is just a factor of adding more static routes to the trigger router. Principles of aggregation can be used, but mindfulness needs to be applied to make sure the iBGP trigger advertisement is equal to or more specific to the original customer advertisement.
Step 4 – Removing Trigger Advertisement
The trigger advertisement will need to be removed when the attack is over or the ISP wishes to move to a different mitigation technique. Removing the static route doesthis. The trigger router will then send out a iBGP withdrawal to all its BGP peers, which in then will withdraw the route from the BGP RIB, which then pulls the routefrom the route's FIB. This clears the path for the router's BGP RIB to select theoriginal customer advertisement, placing that prefix as the best path, and allowingthe FIB to resume normal forwarding to the customer's network.
Comments