irp demo
Request Noction IRP Demo

Request a personalized demo/review session of our Intelligent Routing Platform

irp trial
Start Noction IRP Trial

Evaluate Noction IRP, and see how it meets your network optimization challenges

nfa demo
Noction Flow Analyzer Demo

Schedule a one-on-one demonstration of our network traffic analysis product

nfa trial
Free Noction Flow Analyzer Trial

Test drive NFA today with your own fully featured 30-day free trial

Diverting DDoS traffic using the FlowSpec redirect-to-IP next-hop capability (configuration example)

flowspec redirect-to-ipDistributed denial-of-service (DDoS) attacks can be a major threat to the availability and security of networks. These attacks can overwhelm network resources and cause disruptions to legitimate traffic, leading to downtime and potential financial losses. As such, it’s important to have effective DDoS mitigation techniques in place.

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 Scan

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.

BGP FlowSpec Controller

Figure 1 – BGP FlowSpec Controller P and Clients PE2/PE1

1. BGP FlowSpec Configuration on Controller P

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 configuration below is for a policy-map of type PBR (Policy-Based Routing) named xmas-pbr. The policy-map contains one class named xmass-fs, which is used to match traffic that matches the BGP FlowSpec filter for Xmas packets (a type of packet that sets the URG, PSH, and FIN flags).

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

2. BGP FlowSpec Configuration on Client PE2

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

3. FlowSpec NLRI (Network Layer Reachability Information)

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.

Path Attributes MP_REACH_NLRI

Figure 3 – Path Attributes MP_REACH_NLRI with FlowSpec NLRI and Extended Community

Troubleshooting and Testing

First of all, let’s check if the flowspec rule is received on the PE2 client (Figure 4).

FlowSpec Route Received on PE2

Figure 4 – FlowSpec Route Received on PE2

The SSH server runs on server 190.160.2.1. Let’s run an Xmas scan against the server to check if TCP port 22 (SSH) is open.

$ sudo nmap -sX -P0 -p22 190.160.2.1
Xmas scan Launched

Figure 5 – Xmas scan Launched Against Server 190.160.2.1

The nmap status is open|filtered. This means the firewall is blocking the connection to port 22 or the port is open. As a result, we did not receive a packet from the server with the RST flag set. If TCP port 22 was closed (SSH service is not running on port 22), the server would respond with an RST packet and nmap would report the port as closed.

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).

Xmas Packets

Figure 6 – Xmas Packets Captured on Link Between PE2 and Scrubbing Center

However, we can use CLI to check if the BGP FlowSpec rule is installed on the PE2 client and it filters traffic as expected:

PE2# show flowspec vrf all afi-all
Checking FlowSpec

Figure 7 – Checking FlowSpec rule on Client PE2

There are two packets matched that corresponds to our Xmas scan.

Conclusion

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.

Boost BGP Performance

Automate BGP Routing optimization with Noction IRP

bgp demo


SUBSCRIBE TO NEWSLETTER

You May Also Like