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.