Tuesday, April 26, 2022

BGP Remotely Triggered Blackhole (RTBH)

DDoS attacks and BGP Flowspec responses describes how to simulate and mitigate common DDoS attacks. This article builds on the previous examples to show how BGP Remotely Triggered Blackhole (RTBH) controls can be applied in situations where BGP Flowpsec is not available, or is unsuitable as a mitigation response.
docker run --rm -it --privileged --network host --pid="host" \
  -v /var/run/docker.sock:/var/run/docker.sock -v /run/netns:/run/netns \
  -v ~/clab:/home/clab -w /home/clab \
  ghcr.io/srl-labs/clab bash
Start Containerlab.
curl -O https://raw.githubusercontent.com/sflow-rt/containerlab/master/ddos.yml
Download the Containerlab topology file.
sed -i "s/\\.ip_flood\\.action=filter/\\.ip_flood\\.action=drop/g" ddos.yml
Change mitigation policy for IP Flood attacks from Flowspec filter to RTBH.
containerlab deploy -t ddos.yml
Deploy the topology.
Access the DDoS Protect screen at http://localhost:8008/app/ddos-protect/html/
docker exec -it clab-ddos-attacker hping3 \
--flood --rawip -H 47 192.0.2.129
Launch an IP Flood attack. The DDoS Protect dashboard shows that as soon as the ip_flood attack traffic reaches the threshold a control is implemented and the attack traffic is immediately dropped. The entire process between the attack being launched, detected, and mitigated happens within a second, ensuring minimal impact on network capacity and services.
docker exec -it clab-ddos-sp-router vtysh -c "show running-config"
See sp-router configuration.
Building configuration...

Current configuration:
!
frr version 8.2.2_git
frr defaults datacenter
hostname sp-router
no ipv6 forwarding
log stdout
!
ip route 203.0.113.2/32 Null0
!
interface eth2
 ip address 198.51.100.1/24
exit
!
router bgp 64496
 bgp bestpath as-path multipath-relax
 bgp bestpath compare-routerid
 neighbor fabric peer-group
 neighbor fabric remote-as external
 neighbor fabric description Internal Fabric Network
 neighbor fabric ebgp-multihop 255
 neighbor fabric capability extended-nexthop
 neighbor eth1 interface peer-group fabric
 no neighbor eth1 capability extended-nexthop
 !
 address-family ipv4 unicast
  redistribute connected route-map HOST_ROUTES
  neighbor fabric route-map RTBH in
 exit-address-family
 !
 address-family ipv4 flowspec
  neighbor fabric activate
 exit-address-family
exit
!
bgp community-list standard BLACKHOLE seq 5 permit blackhole
!
route-map HOST_ROUTES permit 10
 match interface eth2
exit
!
route-map RTBH permit 10
 match community BLACKHOLE
 set ip next-hop 203.0.113.2
exit
!
route-map RTBH permit 20
exit
!
ip nht resolve-via-default
!
end
The configuration creates null route for 203.0.113.2/32 and rewrites the next-hop address to 203.0.113.2 for routes that are marked with the BGP blackhole community.
docker exec -it clab-ddos-sp-router vtysh -c "show ip route"
Show the forwarding state on sp-router.
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

K>* 0.0.0.0/0 [0/0] via 172.100.100.1, eth0, 12:36:08
C>* 172.100.100.0/24 is directly connected, eth0, 12:36:08
B>* 192.0.2.0/24 [20/0] via fe80::a8c1:abff:fe32:b21e, eth1, weight 1, 12:36:03
B>  192.0.2.129/32 [20/0] via 203.0.113.2 (recursive), weight 1, 00:00:04
  *                         unreachable (blackhole), weight 1, 00:00:04
C>* 198.51.100.0/24 is directly connected, eth2, 12:36:08
S>* 203.0.113.2/32 [1/0] unreachable (blackhole), weight 1, 12:36:08
Traffic to the victim IP address, 192.0.2.129, is directed to the 203.0.113.2 next-hop, where it is discarded before it can saturate the link to the customer router, ce-router.

Monday, April 4, 2022

Real-time flow telemetry for routers

The last few years have seen leading router vendors add support for sFlow monitoring technology that has long been the industry standard for switch monitoring. Router implementations of sFlow include:
  • Arista 7020R Series Routers, 7280R Series Routers, 7500R Series Routers, 7800R3 Series Routers
  • Cisco 8000 Series Routers, ASR 9000 Series Routers, NCS 5500 Series Routers
  • Juniper ACX Series Routers, MX Series Routers, PTX Series Routers
  • Huawei NetEngine 8000 Series Routers
Broad support of sFlow in both switching and routing platforms ensures comprehensive end-to-end monitoring of traffic, see sFlow.org Network Equipment for a list of vendors and products.
Note: Most routers also support Cisco Netflow/IPFIX. Rapidly detecting large flows, sFlow vs. NetFlow/IPFIX describes why you should choose sFlow if you are interested in real-time monitoring and control applications.
DDoS mitigation is a popular use case for sFlow telemetry in routers. The combination of sFlow for real-time DDoS detection with BGP RTBH / Flowspec mitigation on routing platforms makes for a compelling solution.
DDoS protection quickstart guide describes how to deploy sFlow along with BGP RTBH/Flowspec to automatically detect and mitigate DDoS flood attacks. The use of sFlow provides sub-second visibility into network traffic during the periods of high packet loss experienced during a DDoS attack. The result is a system that can reliably detect and respond to attacks in real-time.

The following links provide detailed configuration examples:

The examples above make use of the sFlow-RT real-time analytics platform, which provides real-time visibility to drive Software Defined Networking (SDN), DevOps and Orchestration tasks.