One technique for mitigating DDoS attacks is redirecting malicious traffic to a scrubbing appliance that can analyze and filter out harmful traffic. BGP FlowSpec is a valuable tool for achieving this redirection, allowing for disseminating traffic flow specification rules through BGP.
Our previous blog post discussed how DDoS traffic could be redirected to a scrubbing appliance using BGP FlowSpec by redirecting traffic to a Virtual Routing and Forwarding (VRF) instance. In this article, we will explore an alternative method for achieving this redirection by redirecting traffic to an IP next hop.
By the end of this article, we will have a deeper understanding of how BGP FlowSpec can redirect suspicious traffic to a scrubbing appliance via IP next hop and how this method can help protect your network from harmful DDoS attacks. More specifically, we learn how to configure a BGP FlowSpec controller and client to detect and redirect Xmas scan traffic to an IPv4 next-hop address, a scrubbing appliance’s IP (Figure 1).
Xmas scans are a type of port scan that send specially crafted packets to targeted systems to identify which ports are open and which are closed. Specifically, an Xmas scan sends TCP packets with the FIN, PSH, and URG flags set to 1, which makes them appear as if they are “Christmas tree” packets with all the lights on.
If the targeted port is open, the Xmas scan packets will be ignored, but if the port is closed, the targeted system will respond with an RST (reset) packet, indicating that the port is closed. Attackers often use Xmas scans to gather information about potential vulnerabilities in a target system.
Xmas scans are popular because they can bypass stateless firewalls and access control lists (ACLs) that only examine the packet header, as the combination of flags in an Xmas scan packet can look similar to legitimate out-of-state FIN and ACK packets. As a result, Xmas scans can often go undetected by these types of security measures.
Figure 1 – BGP FlowSpec Controller P and Clients PE2/PE1
Assuming that OSPF is used for inter-loopback connectivity, define BGP IPv4 unicast and flowspec peers 1.1.1.2 and 2.2.2.2:
router bgp 64500 bgp router-id 3.3.3.3 address-family ipv4 unicast ! address-family ipv4 flowspec ! neighbor 1.1.1.1 remote-as 64500 update-source Loopback0 address-family ipv4 unicast next-hop-self ! address-family ipv4 flowspec ! ! neighbor 2.2.2.2 remote-as 64500 update-source Loopback0 address-family ipv4 unicast ! address-family ipv4 flowspec ! ! !
To ensure that the next-hop address is reachable, a static route can be configured on the flowspec controller:
router static address-family ipv4 unicast 10.1.1.2/32 2.2.2.2
Once this static route is configured, the flowspec controller should be able to reach the next-hop address 10.1.1.2, and the flowspec rule can be advertised to the client PE2 as intended.
Let’s create the xmas-fs class on BGP FlowSpec controller P, a Cisco IOS-XRv 9000:
class-map type traffic match-all xmas-fs match destination-address ipv4 190.160.2.1 255.255.255.255 match protocol tcp match tcp-flag 0x29 end-class-map
The class is matching all IPv4 packets destined to the Server with IP 190.160.2.1 and protocol TCP. The line “match tcp-flag 0x29” tells us that matched packets must have TCP flags Fin, PUSH and URG set in the TCP header (Figure 2).
| Reserved | Reserved | URG | ACK | PSH | RST | SYN | FIN | |
| Bits | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 1 |
| Hex – 0 x | 2 | 9 | ||||||
Figure 2 – TCP Flags in TCP Header
The desired action on the matched traffic is to redirect it to the next-hop IP address of 10.1.1.2. This action will be attached as an extended BGP community.
policy-map type pbr xmas-pbr class type traffic xmass-fs redirect ipv4 nexthop 10.1.1.2 ! class type traffic class-default ! end-policy-map
The following configuration ties FlowSpec to the PBR policy xmas-pbr defined earlier:
flowspec address-family ipv4 service-policy type pbr xmas-pbr
Assuming that OSPF is being used for inter-loopback connectivity, define BGP IPv4 unicast peers and flowspec neighbor 2.2.2.2:
router bgp 64500 bgp router-id 2.2.2.2 bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 64500 neighbor 1.1.1.1 update-source Loopback0 neighbor 3.3.3.3 remote-as 64500 neighbor 3.3.3.3 update-source Loopback0 neighbor 170.1.1.1 remote-as 64402 neighbor 170.1.1.1 ebgp-multihop 2 neighbor 170.1.1.1 update-source Loopback0 ! address-family ipv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 next-hop-self neighbor 3.3.3.3 activate neighbor 3.3.3.3 next-hop-self neighbor 170.1.1.1 activate exit-address-family ! address-family ipv4 flowspec neighbor 3.3.3.3 activate neighbor 3.3.3.3 send-community both exit-address-family
Now, we need to enter FlowSpec configuration mode and issue the local-install interface-all command to enable the local-install feature for FlowSpec on all interfaces that participate in the IPv4 address family. The local-install feature allows the router to install FlowSpec rules directly on the line cards of the router, which can improve performance and reduce the risk of resource contention.
flowspec local-install interface-all address-family ipv4 local-install interface-all
FlowSpec must be disabled on interface GigabitEthernet5 of PE2. This will allow clean traffic from the scrubbing appliance to PE2 to flow eastbound toward PE1 without getting caught in a loop.
interface GigabitEthernet5 ip address 10.2.2.1 255.255.255.252 ip flowspec disable
Path attribute MP_REACH_NLRI with the FlowSpec NLRI sent from controller P to the client PE2 in the BGP Update message is shown in Figure 3. It contains the following matching criteria:
Type 1 – Destination prefix filter – 190.160.2.1/32
Type 3 – IP Protocol
Type 9 – TCP Flags – Urgent, Push and Fin
The action for matching criteria is carried out as an extended BGP community called “Flowspec redirect/mirror to IP next-hop” with type value 0x0800 (Figure 3).
In the 6 bytes of data after the 2-byte type value, the least significant bit is the ‘C’ (copy) bit. If ‘C’ is equal to 1, the originator of the flowspec route is requesting a mirror action. Routers that install this flowspec route should create a copy of every matching packet and forward the copies toward a specified next-hop address while still forwarding the original packets normally [1].
In our case, ‘C’ is equal to 0. The originator of the flowspec route (controller P) requests a simple redirect action. Routers that install this flowspec route (client PE2) should forward the matching packets (the original versions, not copies) towards a new next-hop address – scrubbing center with IP 10.1.1.2.
Figure 3 – Path Attributes MP_REACH_NLRI with FlowSpec NLRI and Extended Community
First of all, let’s check if the flowspec rule is received on the PE2 client (Figure 4).
Figure 4 – FlowSpec Route Received on PE2
$ sudo nmap -sX -P0 -p22 190.160.2.1
Figure 5 – Xmas scan Launched Against Server 190.160.2.1
A screenshot from the packet sniffer output attached to the link between PE2 and the scrubber shows that the scan has been redirected to the scrubber for further inspection (Figure 6).
Figure 6 – Xmas Packets Captured on Link Between PE2 and Scrubbing Center
PE2# show flowspec vrf all afi-all
Figure 7 – Checking FlowSpec rule on Client PE2
One effective technique for mitigating DDoS attacks is redirecting malicious traffic to a scrubbing appliance that can analyze and filter out harmful traffic. BGP FlowSpec is a valuable tool for achieving this redirection, as it enables the distribution of traffic flow specification rules through BGP. This allows for more efficient and effective traffic handling, helping protect the targeted system from the DDoS attack.
We have demonstrated the effectiveness of using BGP FlowSpec to redirect Xmas scan traffic to a scrubbing appliance via IP next-hop. This approach can help to detect and mitigate potential DDoS attacks that utilize Xmas scans. The targeted system is shielded from the attack by redirecting the Xmas scan traffic to a scrubbing appliance. The scrubbing appliance can then analyze traffic to ascertain if it’s part of a larger DDoS attack.
If you’re looking to automate DDoS mitigation within your network, try the Noction Intelligent Routing Platform (IRP). IRP employs sophisticated threat mitigation techniques to safeguard your network against diverse types of DDoS attacks while also providing a user-friendly interface for simple management and monitoring of your network security.