Remote Triggered Black Hole (RTBH) Routing to Mitigate DDOS

Remote Triggered Black Hole (RTBH) Routing to Mitigate DDOS

Border Gateway Protocol (BGP) is the protocol, which is designed to share routing, reachability and some other information among autonomous systems (AS). Border Gateway Protocol’s concepts and implementation were defined in RFC 1654. This RFC was made obsolete by RFC 1771 and RFC 4271. Autonomous System Numbers (ASNs) are assigned by Internet Assigned Numbers Authority (IANA) and creation, selection, and registration of an Autonomous System (AS) was defined in RFC 1930 and best current practice shown in BCP 6.

As is known, our country has been experiencing DDOS attacks for a week due to political distortions. Most of these attacks were originated from outside of the country, some of them from botnets in Turkey. Even though it is impossible to prevent the effects of DDOS attacks completely, throughout whole week, we observe how unsuccessful misconfigured DDOS boxes and BGP announces are.

In this blog post, I am going to talk about how to implement remote triggered black hole (RTBH) to mitigate the effect of the attacks. While facing with a volumetric DDOS attack that we couldn’t handle by using DDOS box and other conventional methods, the best way to mitigate the effects of the attack is stop the exporting of your IP subnets to the outside of the country by using (RTBH) filtering .

Assume a topology pictured below;

Also assume that;

• We have multi-homed Internet Service Provider (ISP) topology,
• Subnets are  10.20.30.0/30 and 10.20.30.4/30,
• Our ASN is 65000,
• ISP1 and ISP2’s ASNs are 100 and 200 respectively,
• Our public subnet, which is announced to ISPs is 100.100.100.0/24,
• Our default BGP configuration is following.

  set ge-0/0/0 unit 0 description "Uplink to ISP1"
  set ge-0/0/0 unit 0 family inet address 10.20.30.5/30
  set ge-0/0/1 unit 0 description "Uplink to ISP2"
  set ge-0/0/1 unit 0 family inet address 10.20.30.1/30
  
  set routing-options autonomous-system 65000
  
  set protocols bgp group EBGP_Peers type external
  set protocols bgp group EBGP_Peers local-as 65000
  set protocols bgp group EBGP_Peers neighbor 10.20.30.2 export ISP2_OUT
  set protocols bgp group EBGP_Peers neighbor 10.20.30.2 peer-as 200
  set protocols bgp group EBGP_Peers neighbor 10.20.30.6 export ISP1_Out
  set protocols bgp group EBGP_Peers neighbor 10.20.30.6 peer-as 100
  
  set policy-options policy-statement ISP1_OUT term default_accept from route-filter 100.100.100.0/24 exact
  set policy-options policy-statement ISP1_OUT term default_accept then accept
  set policy-options policy-statement ISP1_OUT term default_deny then reject
  
  set policy-options policy-statement ISP2_OUT term default_accept from route-filter 100.100.100.0/24 exact
  set policy-options policy-statement ISP2_OUT term default_accept then accept
  set policy-options policy-statement ISP2_OUT term default_deny then reject

Step 1 : Creating Black Hole Community

ISPs are using 444 community for /24 and lower prefix lengths. And then, we need to inject our black hole community to our BGP neighbor. ie.100:444, 200:444.

set policy-options community ISP1_Blackhole members 100:444
set policy-options community ISP2_Blackhole members 200:444

Step 2 : Export Rule Modification 

As seen above, we have export rules assigned to both ISPs, named as ISP[1-2]_OUT. We need to modify our export rule to trigger our black hole request. There are several ways to prepare trigger method. One of them is modifying the prefix-list every time, the other one I am going to use is triggering by static route is very practical.

set policy-options policy-statement ISP1_OUT term ISP_Blackhole from protocol static 
set policy-options policy-statement ISP1_OUT term ISP_Blackhole from tag 444   
set policy-options policy-statement ISP1_OUT term ISP_Blackhole then community set ISP1_Blackhole  
set policy-options policy-statement ISP1_OUT term ISP_Blackhole then accept

set policy-options policy-statement ISP2_OUT term ISP_Blackhole from protocol static 
set policy-options policy-statement ISP2_OUT term ISP_Blackhole from tag 444   
set policy-options policy-statement ISP2_OUT term ISP_Blackhole then community set ISP2_Blackhole  
set policy-options policy-statement ISP2_OUT term ISP_Blackhole then accept

It is very critical to choose the unused tag and locate the blackhole rules at the top of export rule.

To insert the rules at the top ;

insert policy-options policy-statement ISP1_OUT term ISP_Blackhole before term default_accept

insert policy-options policy-statement ISP2_OUT term ISP_Blackhole before term default_accept

Now, we are ready to trigger the action!

Step 3: Triggering the Configuration

Our blackhole term of export rule was configured to always look for a static routes with the tag 444. So, it is must to commit a static route to tag the DDOS infected subnet.

set routing-options static route 100.100.100.0/24 tag 444

Step 4: Observing the Result

In order to observe the effects of this trick, we use looking glass tools of the global ISPs such as TATA (AS6453), Telecom Italia Sparkle Seabone (AS6762), Telia (AS1299). If your configuration was successful, you won’t see any AS_path available on foreign ISPs’ looking glass. On the contrary,  In Superonline (AS 34984) and TurkTelekom (AS 9121) looking glass, there are going to be AS_path available.

To sum up, brief explanation of the whole steps are;

• We set a static route which stamps our subnets with a tag 444.
• Our export rules are always looking for a criteria that is a static route with 444 tag. If a matching  found, then inject it to the black hole community.
• Then our export rules is going to announce the community to both ISPs.
• And then, Internet service provider stops the announce of the our subnet towards to out side of our country.

If you have a question, please do not hesitate to ask me by leaving a comment.

Edit : Please also note that it is needed to have no-export rule configuration on your internet service provider side.

Best regards.