The Number of the Beast or the Practical usage of the Blackhole...

The Number of the Beast or the Practical usage of the Blackhole Community

    BGP Blackhole CommunitiesBGP blackhole filtering is a routing technique used to drop unwanted traffic. Black holes are placed in the parts of a network where unwanted traffic should be dropped. For example, a customer can ask a provider to install black hole on its provider edge (PE) routers to prevent unwanted traffic from entering a customer’s network.

    Unwanted traffic that floods networks and machines from many different sources is often intentionally generated by the distributed-denial-of-service (DDoS) attack. The goal of a DDoS attack is the depletion of resources (CPU, RAM, bandwidth) of a remote target so that the service becomes unavailable for legitimate users. Typical symptoms of a DDoS attack are excessive bandwidth utilization on a targeted network and services crashing on victim’s machines. At the time when the day-long DDoS attacks against a small organization are offered for as low as $100, with a 5-minute test DDoS attack free of charge (showing the attacker capabilities), the importance of having a reactive defense strategy against such attacks is hard to underestimate.

    DDoS traffic should be blackholed (dropped) closest to the source of the attack. Blackholing is based on either the source or destination IP address. Remote black hole filtering based on the destination IP address is a commonly used technique. The ISP sets a permanent static route utilizing the unused prefix pointing to the null interface on its PE routers, e.g. 192.0.2.1/32. It is a precaution measure that ISP installs in advance along with building a trigger machine. The trigger machine is a router or Unix machine running BGP daemon that is a part of ISP infrastructure. It has established internal BGP (iBGP) sessions with PE routers.

    Let’s say that a DDoS attack is launched against a customer web server with IP address 172.12.0.1. As soon as a customer asks an ISP to filter the currently running DDoS, the ISP creates a static route to the targeted prefix 172.12.0.1/32 on the trigger machine pointing to a null interface. The static route to 172.12.0.1/32 is then redistributed via iBGP sessions from the trigger to PE routers but with the next hop changed to the IP 192.0.2.1. As a result, all traffic to the IP address 172.12.0.1 is sent to the 192.0.2.1 thus is effectively being dropped by the null route on PE routers. When the DDoS attack is finished, the static route 172.12.0.1/32 is removed from the trigger machine and withdrawn via iBGP session from the PE routers.

    The method mentioned above requires customers to send an email to a service provider, requesting manual configuration of the null static route for targeted prefix on a trigger machine when DDoS attack is launched. Subsequently, a customer needs to send an email requesting the removal of a static null route once the DDoS attack is finished. Although this method has been  proven to work, it inserts a time delay into the attack mitigation process. Luckily, there is another, automated method for destination-based remote blackholing using Blackhole Community, which gives customers better control over the black holed prefixes.

    The BGP blackhole transitive community is one of the well-known BGP communities defined in RFC 7999. The BGP blackhole community is attached to an announced prefix by an origin Autonomous System (AS) during a DDoS attack. Its purpose consists of signaling to a neighboring network that a neighbor router should discard all traffic destined for the received prefix with the attached BGP blackhole community. With this approach, customers can trigger blackholing of the targeted prefix by remote ISP routers, adding a simple configuration to their customer edge routers. In other words, blackholing can be initiated any time by customers requiring no cooperation with ISP during a DDoS attack. However according to RFC, accepting  the blackhole community, or ignoring it, is a choice that is made by each operator. That is why accepting blackhole community must be agreed by both networks prior to advertising it.

    The blackhole community is registered in the “BGP Well-known Communities” registry as 0xFFFF029A. The low-order two octets in decimal are 666. We can only speculate why the value 666 (the number of the beast from the Bible) was chosen for this purpose. Nevertheless, the value is commonly used with BGP blackholing by network operators. As for a length of the blackhole prefix, it should be as long as possible. This prevents discarding traffic sent to the IP addresses that are not under the DDoS attack. Typically the length of a blackhole prefix is /32 (a single IP address). In any case, the length of the announced blackhole prefix must be equal or longer than the length of the entire IP prefix assigned to a customer.     

    Below is a network topology that we use for testing of blackhole community usage. In our scenario, an attacker launched a DDoS attack against the customer web server (IP 198.51.100.2). If our configuration is correct as soon as the customer configures the commands below, DDoS traffic should be discarded on a router ISP. Traffic from the attacker to IP address 198.51.100.1 should not be discarded.

    ip route 198.51.100.2 255.255.255.255 Null0
    !
    router bgp 64501
    network 198.51.100.2 mask 255.255.255.255 route-map blackhole

     
    BGP blackhole

    Picture 1 – Network Topology

    1. Customer Router Configuration

    ip bgp-community new-format

    router bgp 64501
    bgp log-neighbor-changes
    network 198.51.100.0
    network 198.51.100.2 mask 255.255.255.255 route-map blackhole
    neighbor 198.51.200.1 remote-as 64500
    neighbor 198.51.200.1 send-community

    ip route 198.51.100.2 255.255.255.255 Null0

    route-map blackhole permit 10
    set community 64500:666

    2. ISP Router Configuration

    interface Null0
    no ip unreachables

     
    The command above stops sending ICMP unreachables to the attacker when DDoS packets are discarded on an ISP router.

    router bgp 64500
    bgp log-neighbor-changes
    network 198.51.200.0 mask 255.255.255.252
    network 198.51.200.4 mask 255.255.255.252
    neighbor 198.51.200.2 remote-as 64501
    neighbor 198.51.200.2 ebgp-multihop 255
    neighbor 198.51.200.2 route-map customer-in in
    neighbor 198.51.200.6 remote-as 64502ip bgp-community new-format
    ip community-list 10 permit 64500:666ip route 192.0.2.1 255.255.255.255 Null0route-map customer-in permit 10
    match community 10
    set community no-export
    set ip next-hop 192.0.2.1route-map customer-in permit 20

     

    NOTE: Altering the next-hop for blackhole services requires multihop on the EBGP sessions otherwise the route 198.51.100.2/30 won’t be selected as a best route and inserted into the routing table of an ISP router.

    3. Additional Configuration on ISP PE Router

    3.1. Restrict Customer to Advertise Only Authorized Prefix with Length from /24 to /32

    Customer should only announce a prefix that is authorized to advertise (198.51.100.0), with the length from /24 to /32. For this reason ISP needs to filter BGP announcements carrying the blackhole community that are not authorized.

    ip prefix-list AS64501-in seq 5 permit 198.51.100.0/24 le 32

    router bgp 64500
    neighbor 198.51.200.2 prefix-list AS64501-in in

    3.2. Prevent ISP to send Blackhole Prefix to eBGP Peers

    A BGP speaker receiving an announcement tagged with the blackhole community (ISP) should add no_export community as to prevent propagation of the blackhole prefixes to eBGP peers. We have already done it with the command under the route-map customer-in in the ISP configuration.

    4. Testing

    If the DDoS attack is not launched, the attacker can ping the IP address 198.51.100.2.

    Attacker# ping 198.51.100.2 repeat 50
    Type escape sequence to abort.
    Sending 50, 100-byte ICMP Echos to 198.51.100.2, timeout is 2 seconds:
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    Success rate is 100 percent (50/50), round-trip min/avg/max = 1/1/2 ms

     
    Below is the RIB of the ISP router.

    ISP# show ip bgp | begin Network 
        Network          Next Hop            Metric LocPrf Weight Path 
    *>  198.51.100.0     198.51.200.2             0             0 64501 i 
    *>  198.51.200.0/30  0.0.0.0                  0         32768 i 
    *>  198.51.200.4/30  0.0.0.0                  0         32768 i

     
    Once the DDoS attack is launched and detected by the customer, the customer adds the following lines to its router. Subsequently, once the attack is finished, the customer removes the lines from the configuration.

    ip route 198.51.100.2 255.255.255.255 Null0

    router bgp 64501
    network 198.51.100.2 mask 255.255.255.255 route-map blackhole

     
    The RIB of an ISP router changes adequately. We see that route 198.51.100.2/32 with the next hope 192.0.2.1 was added.

    ISP#show ip bgp | begin Network 
        Network          Next Hop            Metric LocPrf Weight Path 
    *>  198.51.100.0     198.51.200.2             0             0 64501 i 
    *>  198.51.100.2/32  192.0.2.1                0             0 64501 i 
    *>  198.51.200.0/30  0.0.0.0                  0         32768 i 
    *>  198.51.200.4/30  0.0.0.0                  0         32768 i

     
    Inspection of the static route to 192.0.2.0 reveals that packets to the IP address 192.0.2.1 are discarded.

    ISP# show ip route static | begin 192.0.2.0 
         192.0.2.0/32 is subnetted, 1 subnets 
    S        192.0.2.1 is directly connected, Null0

     
    The RIB of the attacker router has not changed.

    Attacker# show ip bgp | begin Network 
        Network          Next Hop            Metric LocPrf Weight Path 
    *>  198.51.100.0     198.51.200.5                           0 64500 64501 i 
    *>  198.51.200.0/30  198.51.200.5             0             0 64500 i 
    r>  198.51.200.4/30  198.51.200.5             0             0 64500 i
    

     
    However DDoS traffic is successfully discarded on the ISP router.

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

     
    The traffic to the IP address 198.51.100.1 should not be discarded as the DDoS attack is launched only against the web server.

    Attacker# ping 198.51.100.1 repeat 50
    Type escape sequence to abort.
    Sending 50, 100-byte ICMP Echos to 198.51.100.1, timeout is 2 seconds:
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    Success rate is 100 percent (50/50), round-trip min/avg/max = 1/1/2 ms

     


    In this article we focused on the explanation of Destination-Based Remotely Triggered Blackhole Filtering using a trigger machine in an ISP infrastructure. We have gone further and practically configured and tested usage of blackhole community with destination IP address filtering. As a result, we have successfully stopped a DDoS attack against the customer web server, adding configuration only to a customer router.

    We should note that there are some pros and cons associated with the use of the BLACKHOLE community. While this approach is widely supported by transit providers, accepting the blackhole community, or ignoring it, as mentioned above, is a choice that is made by each operator. The use of the community should be agreed by both networks.

    While the approach allows to keep a network up during an attack, this is more of a mitigation technique, rather than protection. Although the use of the technique allows the wider network to stay up, ultimately the target machine is still going down.

    Boost BGP Preformance

    Automate BGP Routing optimization with Noction IRP

    NO COMMENTS

    Leave a Reply