Table of Contents

Introduction· 1

Configuration Prerequisites· 1

Configuration Examples· 1

Network Requirements· 1

Configuration Approach· 2

Configuration Steps· 3

Add Steering Device· 3

Configure the Diversion Script 3

Configure Blackhole Diversion Rules and Trigger Parameters· 4

Verification of Configuration· 6

Verify the Global Total Traffic Diversion· 6

Configure a Single IP Blackhole Diversion Rule· 8

 

Introduction

The AFC system incorporates a Traffic Diversion Management Module. This module primarily functions to intelligently detect protected hosts under abnormal traffic attacks within the traffic cleaning system. When traction conditions are met, it executes corresponding actions specified in the diversion script. This mechanism ensures both the stability of user networks and the security of the traffic cleaning system itself.

Configuration Prerequisites

This document is not strictly version-bound to specific software or hardware. If discrepancies arise between the document and the actual product during use, always prioritize the device's actual status.

All configurations demonstrated in this document were tested in a laboratory environment, with all device parameters initialized to factory default settings prior to configuration. If you have previously configured the device, ensure that your existing settings do not conflict with the examples provided below to guarantee expected outcomes.

Configuration Examples

Network Requirements

This configuration takes a series deployment as an example. For detailed instructions, refer to "AFC Series Deployment Mode Configuration Examples".

The attacker and client access the network through router R1 to reach the protected host with IP addresses 200.0.0.100/24 to 200.0.0.109/24. Both attack traffic and legitimate client traffic will pass through the series-deployed AFC device.

Figure 0‑1 AFC Series Deployment Mode Configuration Topology

 

Configuration Approach

In the traffic diversion configuration, when the total global traffic exceeds the set threshold, of the traffic from specific hosts will be diverted. Each host's traffic must individually exceed the configured trigger threshold. Configure the diversion script by adding static routes for the targeted hosts on router R1, directing the traffic to R1's blackhole route.

Configuration Steps

Add Steering Device

In [Protection] > [Steer Config] > [Steering Device], click "Add". Fill in the following details:

• Device Name: Customizable (user-defined)
• R1 Management Address: IP address of router R1
• Device Port: Management port of the diversion device

The diversion device supports connection via Telnet, SSH, or WebService protocols.

 

Figure 0‑2 Add Steering Device

 

Configure the Diversion Script

[Protection] > [Steer Config] >[Steering Operations] click "Add", and fill in the information as shown in the figure below.

Figure 0‑3 Configure the Diversion Script

 

Example:
To divert traffic to router R1, which is an H3C router with IP address 184.0.0.1/24, username "admin", and password "admin", configure the diversion script to direct traffic to R1's blackhole route as follows:

 

[-TELNET 184.0.0.1-]

admin

admin

<Sysname> system

[Sysname] ip route-static   #IP# 32 null0

[Sysname] quit

<Sysname> save

<Sysname> quit

 

Configure Blackhole Diversion Rules and Trigger Parameters

Navigate to [Protection] > [ Steer Config] > [ Blackhole Policy ], click "Add", and fill in the information as shown in the figure below.

Figure 0‑4 Blackhole Policy

 

The above figure defines a global policy. The global policy monitors the sum of traffic passing through all servers in the current cluster. When the total traffic reaches the set threshold, the server IP with the highest traffic will be blocked at the upper layer until the traffic falls below the set value. The contents are as follows:

·     Name: Define the policy name; 

·     Trigger duration time: The time it takes to trigger the traffic threshold or packet count threshold. Once this value is reached, the associated diversion operation in the lower-left corner will be executed. Usually, keep this at 0 to execute the diversion operation immediately;

·     First duration time: The duration for which the server is diverted;

·     Traffic Iimitation: The traffic threshold preset by the administrator. Here, judgment is made solely based on the size of the traffic;

·     Packet limitation: The packet count threshold preset by the administrator; 

·     Unsteering mode: Select Mode One, after the server diversion time ends, it will immediately perform anti-diversion; Select Mode Two, the administrator can set two additional parameters: traffic threshold or packet count threshold. Then, at the end of the diversion time, it will perform this parameter judgment again, and only if it is less than this threshold, will it execute anti-diversion;

·     Total Steered Traffic: Check the activation option box, which will automatically select the global option. In the local option box, you can set the diversion lower limit, indicating that when the policy threshold is triggered, it will judge whether the traffic of the IP with the largest traffic is greater than this value. Only if it is greater than this value will the diversion operation be executed.

·     Select Steering Device Operation: Select the diversion operation to be performed after triggering the policy, usually to block the IP on the upper-layer switch.

 

Global Total Traffic: After entering the corresponding value for global total traffic, the system checks whether the global total traffic exceeds the set threshold. If it does, traffic diversion is performed according to the configured diversion rules. This parameter is set to defend against segment scanning attacks, where the traffic of individual hosts is low, but the overall global traffic is high.
Note: Used in conjunction with the global total traffic parameter, after the first host diversion is completed, the system checks whether the current total traffic exceeds the "Global Total Traffic" threshold. If it does, a second diversion is performed; otherwise, no further diversion will occur.

Verification of Configuration

Verify the Global Total Traffic Diversion

Before diversion, the attacker sends a UDP flood attack to the protected host, with a global traffic of 1000M and a single host traffic of 100M.

Figure 0‑5 Host Status Before Diversion

 

Configure blackhole diversion rules as follows:

Figure 0‑6 Global Total Traffic Diversion Configuration

 

This configuration means that when the global total traffic exceeds 500M, the traffic is automatically sorted from largest to smallest, and the address with the largest traffic is diverted to the blackhole route of R1 until the total traffic is less than 500M, or the traffic of each individual host is less than 50M, in which case no blackhole diversion will be performed.

 

Upon successful diversion, the diverted host(s) will be displayed in the diversion list.

Figure 0‑7 Blackhole Status

 

The current traffic is still greater than the set global traffic threshold, therefore, hosts are being diverted in sequence, with a total of 10 hosts diverted.

 

After diversion, a static route to null0 can be seen on R1:

Figure 0‑8 Blackhole Route

 

If the diversion is unsuccessful, you can view the logs in the command log of the diversion list.

Figure 0‑9 Command Log

 

The following diagram indicates a timeout or command error in the connection between the AFC device and the blackhole device.

Figure 0‑10 Connection timeout or command error between the AFC device and the blackhole device.

 

Configure a Single IP Blackhole Diversion Rule

The rest is the same as 3.4.1. Configure the blackhole diversion rule as follows:

Figure 0‑11 Single IP Triggered Traffic Diversion Configuration