Remotely-Triggered Black Hole (RTBH) Routing
Based on my experience, and some of recommendation documents, today we are going to look through how to protect your Enterprise Network from DDOS attack, targeting your organization. This article serve as a best practice in Network Design and Architect. Please test it in your testing environment first before applying to your production network.
There are several good articles that wrote about how to protect your enterprise network security:
1. What Can Enterprises Learn as Security Practice Practice from Service Providers from Service Providers – CiscoLive2009
2. RFC Remote Triggered Black Hole filtering with uRPF
http://tools.ietf.org/html/draft-ietf-opsec-blackhole-urpf-03
3. Remotely-Triggered Black Hole (RTBH) routing - http://packetlife.net
http://packetlife.net/blog/2009/jul/6/remotely-triggered-black-hole-rtbh-routing/
Network Security Layer
First of all, there are no security tools with one package that suite and protect your asset/business as a whole. The best practice, you should separate your network into below layer security design:
Network Architect Structure
- IP Addressing Design
- Maintain seperation between infrastruture and edge
- Create good security policies and maintain overview of traffic flows
- Separate data traffic from management traffic
The Secret Service Provider Security Tools: BGP
- It has robust authentication and you have to manually define who you exchange information with
- It uses TCP for transport and is easy to secure with IPSec
- Can carry additonal information natively and is easily extended
- Powerful tools available for controlling, manipulating and acting upon information carried in BGP
Using BGP Blackhole at your edge router and at your ISP provider level is the most effective to minimize your business impact. It depend on scenario, you can blackhole it by source-ip-address or by destination-ip-address. However, be remember try to blackhole it as close as possible to the attacker source. e.g. your ISP Provider.
BGP Security tool: # Remotely-Triggered Black Hole (RTBH)
Remotely-Triggered Black Hole (RTBH) routing is an interesting application of BGP as a security tool within service provider networks. One common use is mitigation of distributed denial of service (DDoS) attacks, as this article will explore.
Note: Make sure you have IPS/ or NTOP or any device that can help to you identify which ip address is the victim, or what is the source ip attack. Best option is Web-Application-Firewall (WAF)
Pictured below is a (very) simplified service provider architecture.
Routers 1 through 4 compose the network core, and router 9 functions as a standalone “management” router for route injection. OSPF is running across the core to exchange internal routes. Each router in this core square also maintains an iBGP adjacency with the other core routers, and with router 9. The server at 172.16.10.100 represents the target of a DDoS attack.
Assume a DDoS attack is launched from the public Internet toward the customer server at 172.16.10.100. The throughput consumed is so excessive that the attack is impacting the entire internal infrastructure and must be blocked at the edge. Due to the distributed nature of the attack, we must block at the edge all inbound traffic destined for the victim. Rather than resorting to laborious and error-prone access lists, we can utilize BGP and RTBH to quickly achieve the desired result.
Step 1: Null route preparation
The first two steps in configuring RTBH should ideally be completed prior to an attack.
RTBH works by injecting a specially-crafted BGP route into the network, forcing routers to drop all traffic with a specific next-hop — effectively creating a “black hole.” We create a static route on all BGP routers for this next-hop address:
R1(config)# ip route 192.0.2.1 255.255.255.255 Null0
This route forces any traffic destined for 192.0.2.1/32 to be immediately dropped by the router. This route is added to all edge routers (R1 and R2) in our example lab.
Note that any IP address can be used for this black hole route; we use an IP from the reserved Test-Net range (see RFC 3330) here out of convenience, as this IP should never appear on a routed network.
Step 2: Route-map preparation
As with the first step, this configuration should also be completed prior to an attack.
A route-map is created to redistribute certain tagged static routes into BGP with a modified next-hop value:
R9(config)# route-map RTBH R9(config-route-map)# match tag 666 R9(config-route-map)# set ip next-hop 192.0.2.1 R9(config-route-map)# set origin igp R9(config-route-map)# set community no-export
This is the key component to RTBH: any route advertised to an edge router with a next-hop of 192.0.2.1 will force recursion to the static Null0 route we implemented in the prior configuration, and any matching traffic will be dropped.
Enable static route redistribution into BGP for the route-map to take effect:
R9(config)# router bgp 65100 R9(config-router)# redistribute static route-map RTBH
Step 3: Create a victim route on the management router
Once an attack is detected and the decision is made to block traffic, a static route for the victim address is created on the management router (R9):
R9(config)# ip route 172.16.10.100 255.255.255.255 Null0 tag 666
Ideally, we would like to simply advertise this route to the edge BGP routers, but a route cannot be advertised as having an invalid next-hop. So, we’ve added a tag value to ensure that our RTBH route-map redistributes the route into BGP with a modified next-hop. Note that the no-export community has been appended here to avoid accidentally exporting the route beyond the local AS.
With our victim route injected, we can verify that the edge routers now drop all traffic bound for that prefix:
R1# show ip route 172.16.10.100 Routing entry for 172.16.10.100/32 Known via "bgp 65100", distance 200, metric 0, type internal Last update from 192.0.2.1 00:06:14 ago Routing Descriptor Blocks: * 192.0.2.1, from 10.0.99.9, 00:06:14 ago Route metric is 0, traffic share count is 1 AS Hops 0 R1# show ip route 192.0.2.1 Routing entry for 192.0.2.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 0, traffic share count is 1
Of course, the victim is now unreachable, and we’ve effectively assisted the DDoS in accomplishing its goal. However we have protected our internal infrastructure (and other customers) from the flood of traffic, affording us time to better investigate and more eloquently mitigate the attack. As you might imagine, there are more advanced implementations of this method which can be used, as future articles will cover.
Thanks to Steinthor Bjarnason and his BRKSEC-2204 presentation at Cisco Live for inspiring this article!
Appendix A: Cisco Router Configuration Sample
Announcing router: ! The discard route ip route 192.0.2.1 255.255.255.255 Null0 ! ! Matches and empty AS-PATH only. ip as-path access-list 10 permit ^$ ! ! This route-map matches routes with tag 666 and sets the next-hop ! to be the discard route. route-map remote-trigger-black-hole permit 10 match tag 666 set ip next-hop 192.0.2.1 set local-preference 200 set community no-export ! The community used internally to tag RTBH announcements. set community 65505:666 set origin igp ! route-map remote-trigger-black-hole permit 20 ! router bgp 65505 no synchronization bgp log-neighbor-changes redistribute static route-map remote-trigger-black-hole no auto-summary ! ! An example IP that we are applying RTBH filtering to. ! All traffic destined to 10.0.0.1 will now be dropped! ip route 10.0.0.1 255.255.255.255 null0 tag 666 ! Filtering router: ! ! The discard route ip route 192.0.2.1 255.255.255.255 Null0 ! ! Matches and empty AS-PATH only. ip as-path access-list 10 permit ^$ ! route-map black-hole-filter permit 10 match ip address prefix-list only-host-routes match as-path 10 match community 65505:666 no-export ! ! Don't accept any other announcements with the RTBH community. route-map black-hole-filter deny 20 match community 65505:666 ! route-map black-hole-filter permit 30 ! ! An interface for source-based RTBH filtering with uRPF loose mode. interface FastEthernet 0/0 ip verify unicast source reachable-via any
Appendix B: Juniper Configuration Sample
Announcing router:
routing-options {
static {
/* EXAMPLE ATTACK SOURCE */
route 10.11.12.66/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
/* EXAMPLE ATTACK DESTINATION */
route 10.128.0.2/32 {
next-hop 192.0.2.1;
resolve;
tag 666;
}
}
autonomous-system 100;
}
protocols {
bgp {
group ibgp {
type internal;
export rtbh;
neighbor 172.16.0.2;
}
}
}
policy-options {
policy-statement rtbh {
term black-hole-filter {
from {
tag 666;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
local-preference 200;
origin igp;
community set black-hole;
community add no-export;
next-hop 192.0.2.1;
accept;
}
}
}
community black-hole members 100:666;
community no-export members no-export;
}
Filtering router:
policy-statement black-hole-filter {
from {
protocol bgp;
as-path LocalOnly;
community black-hole;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
community set no-export;
next-hop 192.0.2.1;
}
}
community black-hole members 100:666;
community no-export members no-export;
routing-options {
forwarding-table {
unicast-reverse-path feasible-paths;
}
static {
route 192.0.2.1/32 discard;
}
}
interfaces {
xe-1/0/0 {
vlan-tagging;
mtu 9192;
unit 201 {
vlan-id 201;
family inet {
rpf-check;
address 10.11.12.1/24;
}
}
}
}