H3C DDoS Protection Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Contents

Overview·· 1

Technical background· 1

Benefits· 1

Joint and collaborative operation of three components· 1

Two deployment modes applicable to various service scenarios· 3

Multiple technologies that effectively defend against various DDoS attacks· 5

DDoS attacks that the solution can defend against 6

About the defendable DDoS attacks· 6

Common defendable DDoS attacks· 6

Custom defendable DDoS attacks· 7

Resource-consuming DDoS attacks· 7

About resource-consuming DDoS attacks· 7

DNS query flood attack· 7

DNS reply flood attack· 7

HTTP flood attack· 8

HTTPS flood attack· 8

SIP flood attack· 8

HTTP slow attack· 9

SSL renegotiation attack· 9

Connection-based DDoS attacks· 1

About connection-based DDoS attacks· 1

SYN flood attack· 1

SYN-ACK flood attack· 2

ACK flood attack· 3

RST flood attack· 4

TCP fragment flood attack· 4

Volumetric DDoS attacks· 5

About volumetric DDoS attacks· 5

UDP flood attack· 5

UDP fragment flood attack· 5

ICMP flood attack· 6

ICMP fragment flood attack· 6

IP traffic flood attack· 6

User-defined DDoS attacks· 6

H3C anti-DDoS implementation· 7

DDoS attack detection modes· 7

About DDoS attack detection modes· 7

Deep packet inspection· 8

Deep flow detection· 9

Permitting management traffic· 9

Anti-DDoS zone· 10

Anti-DDoS zone· 10

How packets match anti-DDoS zones· 10

DDoS attack prevention thresholds· 10

Thresholds for defending against various types of DDoS attacks· 10

DDoS attack prevention threshold learning· 13

Traffic cleaning· 13

Traffic cleaning overview· 13

Blacklist and whitelist 14

Filters· 17

Fingerprint protection· 18

Attack source verification· 18

Packet rate limiting· 25

DDoS protection logs· 26

Traffic analysis logs· 26

Attack alarm logs· 26

Attack information logs· 26

Logs of top 5 fingerprints· 26

Anti-DDoS diversion and injection techniques (applicable only in one-arm deployment mode) 26

About diversion and injection· 26

PBR-based diversion· 29

BGP-based diversion· 29

Static route injection· 30

Layer 2 injection· 31

PBR-based injection· 32

GRE injection· 33

MPLS LSP injection· 34

Typical applications· 35

Overview of typical applications· 35

Inline deployment mode· 37

Static route injection in one-arm deployment mode· 37

Layer 2 injection method in one-arm deployment mode· 38

PBR-based injection in one-arm deployment mode· 39

GRE injection in one-arm deployment mode· 40

MPLS LSP injection in one-arm deployment mode· 41

Overview

Technical background

Distributed Denial of Service (DDoS) attacks are a common type of network attack. DDoS attackers exploit infected computers or devices (also called zombies or bots) in different regions or networks to simultaneously send a large volume of malicious traffic to overwhelm the target servers. As a result, services become unavailable or degrade.

DDoS attacks have the following characteristics:

·     Large scale—DDoS attacks are typically launched by a large number of hosts (often a botnet) simultaneously. The large-scale attack traffic overloads the target server, causing the server to operate incorrectly.

·     Hard attack source identification—An attacker exploits multiple source addresses to launch attacks, which makes it difficult to identify the attack source.

·     Duration—A DDoS attack can last for several hours, days, or even months. It is extremely fatal for the victim and often causes significant economic losses.

·     Various attack methods—An attacker can use various attack methods such as SYN flood attack, UDP flood attack, ICMP flood attack, and HTTP POST request attack, which makes the attack unpredictable.

·     Difficult defense—Because an attacker constantly changes the DDoS attack strategy, the cybersecurity personnel must continually update and maintain devices to adapt to the changing attack methods.

·     High anonymity—An attacker often uses a self-built botnet to launch attacks and pays anonymously, which makes it impossible to trace the attacker.

The networks of large or medium-sized enterprises and data centers typically require a large number of servers to meet requirements. The servers, such as mail servers and Web servers, are main network attack targets. The network attacks often involve DDoS attacks with high volumes of traffic, including SYN flood attacks, SIP flood attacks, UDP flood attacks, ICMP flood attacks, DNS flood attacks, HTTP flood attacks, and HTTPS flood attacks. Such DDoS attacks cause network congestion, severely affect normal service operation on the servers, and might even cause the servers to go down. Therefore, effectively defending against DDoS attacks in the network is crucial for network security. To address DDoS attacks, H3C has launched the H3C anti-DDoS solution.

The H3C anti-DDoS solution is specifically designed for handling DDoS attack threats.

·     The solution allows only legitimate traffic to enter the network by detecting, identifying, and filtering out attack traffic, thereby achieving DDoS protection.

·     The solution provides the one-arm and inline deployment modes to meet DDoS defense requirements in various service scenarios.

Benefits

Joint and collaborative operation of three components

Clear division of labor

In one-arm deployment mode, the solution includes three components: management center, detection device, and cleaning device. They are responsible for device management, attack detection, and traffic cleaning, respectively.

·     Management center—Acts as the core of the DDoS protection framework and provides a Web-based management interface. It performs the following tasks:

¡     Centrally configures and manages the detection device and the cleaning device.

¡     Analyzes logs reported by the detection device and the cleaning device.

¡     Deploys a traffic redirection policy to the cleaning device deployed in one-arm mode.

¡     Displays DDoS protection statistics.

·     Detection device—Detects DDoS attacks and reports attack information (including target IP address, target port number, and attack type) to the management center in attack alarm logs.

·     Cleaning device—Detects DDoS attacks, and scrubs DDoS attack traffic by dropping or rate limiting attack packets.

Collaborative work

Figure 1 Collaborative work of three components in one-arm deployment mode

 

In one-arm deployment mode, the three components implement DDoS protection as follows:

·     The detection device performs DDoS attack detection on traffic mirrored or sampled by NetStream or sFlow.

·     Once the detection device detects a DDoS attack, it reports the attack information to the management center.

·     The management center deploys a defense policy and a traffic redirection rule to the cleaning device.

·     The core device redirects the DDoS attack-related traffic to the cleaning device and the cleaning device drops the attack traffic.

·     The cleaning device injects the clean traffic to the core device.

·     The core device forwards the traffic to the original destination IP address.

Two deployment modes applicable to various service scenarios

Inline deployment mode

The inline deployment mode is applicable to networks with small and medium volumes of traffic, such as networks in small and medium-sized enterprises. It has the following characteristics:

·     The network is simple. No detection device is deployed.

·     The cleaning device is deployed at the egress of the internal network as a gateway and directly cleans DDoS attack traffic. The cleaning device might encounter a performance bottleneck when it processes both incoming and outgoing traffic.

·     The management center configures, manages, and monitors the cleaning device.

Figure 2 Inline deployment mode

 

1.     The cleaning device performs DDoS attack detection on all incoming traffic.

2.     The cleaning device reports attack information to the management center.

3.     The management center deploys a defense policy to the cleaning device.

4.     The cleaning device drops or rate limits the attack traffic.

5.     The cleaning device forwards normal traffic to its destination.

One-arm deployment mode

The one-arm deployment mode is applicable to networks with high volumes of traffic, such as data centers. It has the following characteristics:

·     The detection device and cleaning device perform attack detection and traffic cleaning, respectively. They work together to efficiently defend DDoS attacks.

·     Deployed at the network egress, the detection device and cleaning device have a slight impact on other services. The network will not crash when a device has failed.

·     The one-arm deployment mode supports various traffic redirection and injection technologies that can meet the requirements of different network structures and protocols. For more information, see "Anti-DDoS diversion and injection techniques (applicable only in one-arm deployment mode)."

·     In dynamic traffic redirection mode, the cleaning device scrubs only DDoS attack-related traffic.

·     The management center configures, manages, and monitors both the detection device and the cleaning device.

Figure 3 One-arm deployment mode

 

1.     The core device copies or samples traffic to the detection device for DDoS attack detection.

2.     The detection device reports attack information to the management center.

3.     The management center deploys a defense policy and a traffic redirection rule to the cleaning device.

4.     The core device redirects traffic to the cleaning device and the cleaning device drops the attack traffic.

5.     The cleaning device injects the clean traffic to the core device.

6.     The core device forwards the clean traffic to its destination.

Comparison between two deployment modes

The solution provides the one-arm and inline deployment modes, which can meet DDoS defense requirements in different service scenarios.

Table 1 Comparison between two deployment modes

Item	One-arm deployment mode	Inline deployment mode
Applicable scenarios	Networks with high volumes of traffic, such as data centers	Networks with small and medium volumes of traffic, such as networks in small and medium-sized enterprises
Required components	Management center: Yes Detection device: Yes Cleaning device: Yes (deployed independently)	Management center: Yes Detection device: No Cleaning device: Yes (a gateway that supports traffic cleaning)

 

Multiple technologies that effectively defend against various DDoS attacks

The comprehensive H3C anti-DDoS solution includes the following elements:

·     Three components: detection device, cleaning device, and management center.

·     Two deployment modes: inline deployment mode and one-arm deployment mode.

·     Multiple detection and cleaning technologies.

The solution is applicable to multiple scenarios and can effectively defend against various DDoS attacks.

Figure 4 Application of multiple technologies

 

DDoS attacks that the solution can defend against

About the defendable DDoS attacks

Common defendable DDoS attacks

DDoS attacks can be divided into three types based on the characteristics: resource-consuming attack, connection-based attack, and volumetric attack. Table 2 lists the common DDoS attacks that the solution can effectively defend against.

Table 2 Common DDoS attacks

DDoS attack type	Attack principle	Common attack method	DDoS attack target
Resource-consuming attack	An attacker sends a large number of forged application layer requests, which causes the target server to be unable to process normal services.	DNS query flood attack	DNS servers
		DNS reply flood attack	DNS clients
		HTTP flood attack	Web servers that support the HTTP protocol
		HTTPS flood attack	Web servers that support the HTTPS protocol
		SIP flood attack	VoIP servers
		HTTP slow attack	Web servers that support the HTTP protocol
		SSL renegotiation attack	Web servers or application servers that support the SSL protocol
Connection-based DDoS attack	An attacker frequently establishes or disconnects TCP connections to exhaust the TCP connection resources of the attack target.	SYN flood attack	Servers that support the TCP protocol
		SYN-ACK flood attack	Clients that support the TCP protocol
		ACK flood attack	Servers that support the TCP protocol
		RST flood attack	Servers that support the TCP protocol
		TCP fragment flood attack	Servers that support the TCP protocol
Volumetric DDoS attack	An attacker sends a large number of connectionless packets to congest the network links of the target server.	UDP flood attack	Servers that support the UDP protocol
		UDP fragment flood attack	Servers that support the UDP protocol
		ICMP flood attack	Servers that support the ICMP protocol
		ICMP fragment flood attack	Servers that support the ICMP protocol
		IP traffic flood attack	All serve

 

Custom defendable DDoS attacks

You can define a DDoS attack type and specify the packet signature to implement DDoS protection more flexibly.

·     Protocol-specific DDoS attack type.

·     ICMP-based DDoS attack type.

·     ICMPv6-based DDoS attack type.

·     TCP-based DDoS attack type.

·     UDP-based DDoS attack type.

Resource-consuming DDoS attacks

About resource-consuming DDoS attacks

An attacker sends a large amount of malicious data traffic to consume the compute resources and network bandwidth of the target server. As a result, resources on the target server run out and the server cannot process legitimate requests correctly or provide normal services. A resource-consuming DDoS attack is typically launched by multiple attack sources simultaneously. The attacker typically uses technologies to control a large number of machines, for example, botnets or DDoS attacks, to conceal the identity and location of the attack source.

DNS query flood attack

The DNS query flood attack is a type of DDoS attack that is targeted at DNS servers. A DNS server processes and replies to all incoming DNS queries. A DNS query flood attacker sends a large number of forged DNS queries to consume the network bandwidth and compute resources of the target DNS server. As a result, the server cannot process normal DNS queries.

The detailed attack process is as follows:

1.     An attacker uses multiple zombie hosts to send a large number of DNS queries to the target DNS server. The attacker can prevent the victim from performing vulnerability scanning and assessment by constantly changing fake source IP addresses, querying random domain names, and changing the target DNS server.

2.     The DNS server attempts to reply to each query and identifies whether the domain names in the queries match any DNS records. Enormous malicious queries overload the DNS server and exhaust its resources. As a result, the DNS server cannot reply to legitimate DNS queries.

DNS reply flood attack

The DNS reply flood attack is a type of DDoS attack that is targeted at DNS clients. A DNS client processes all incoming DNS replies. A DNS reply flood attacker sends a large number of forged DNS replies to consume the resources of the DNS client. As a result, the DNS client cannot process normal DNS replies.

The detailed attack process is as follows:

1.     An attacker sends a large number of forged DNS replies to the target DNS client.

2.     The DNS client processes the received DNS replies. Because the source IP address in the forged DNS replies is the IP address of the DNS server corresponding to the DNS client, the DNS client considers that the DNS replies are from a legitimate DNS server. Then, the DNS client stores the forged DNS reply information in the DNS cache.

3.     The forged DNS replies exhaust the DNS cache resources and the DNS client cannot process legitimate DNS replies.

HTTP flood attack

An HTTP flood attacker sends a large number of HTTP requests to consume the server resources, which causes website service performance degradation or website availability.

The detailed attack process is as follows:

1.     An attacker exploits multiple zombie hosts to send a large number of forged HTTP GET or POST requests to the target website.

2.     Upon receiving an HTTP GET or POST request, the HTTP server performs complex operations, including character string searching, database traversal, data reassembly, and format switching. These operations consume a large number of system resources.

3.     The forged requests exhaust the resources of the HTTP server, which degrades the HTTP server performance or even paralyzes the HTTP server.

HTTPS flood attack

An HTTPS flood attacker sends a large number of HTTPS requests to consume the server resources, which causes website service performance degradation or website availability.

The detailed attack process is as follows:

1.     An attacker exploits multiple zombie hosts to send a large number of forged HTTPS requests to the target website.

2.     Upon receiving an HTTPS request, the HTTPS server performs complex operations, including certificate verification and key negotiation. These operations consume a large number of system resources.

3.     The forged requests exhaust the resources of the HTTPS server, which degrades the HTTPS server performance or even paralyzes the HTTPS server.

SIP flood attack

A SIP flood attacker sends a large number of fake SIP requests to the SIP phone system to consume the resources of the SIP server, which causes the IP phone or multimedia conference services to be unavailable.

The detailed attack process is as follows:

1.     A SIP flood attacker uses an automation tool to send a large number of SIP INVITE requests to the target SIP phone server. The requests might use different source IP addresses and ports and seem to be from different phone endpoints.

2.     The SIP server attempts to respond to each received request by allocating resources for tracing and establishing sessions.

3.     The forged SIP requests exhaust the resources of the SIP server, which degrades the SIP server performance or even paralyzes the SIP server. IP phone or multimedia conference services of normal users are affected or become unavailable.

HTTP slow attack

The HTTP slow attack is a type of DDoS attack that is targeted at Web servers. An HTTP slow attacker establishes a connection to an HTTP server and holds the connection for a long time by sending HTTP requests that take a long time to process or using special characters. This consumes the server resources and causes server performance issues or service interruption.

The detailed attack process is as follows:

1.     An attacker holds the connection with the HTTP server by sending HTTP requests that take a long time to process. For example, the attacker might send fragmented HTTP headers, add special characters such as redundant spaces or carriage returns to the HTTP headers, or send HTTP headers byte by byte. The attacker might also send very small packets during data transmission.

2.     Upon receiving an HTTP request, the Web server establishes an HTTP connection for it, which consumes connection resources of the server.

3.     The server fails or crashes and cannot respond to normal requests.

SSL renegotiation attack

The SSL renegotiation attack is a type of DDoS attack that is targeted at servers that use the SSL protocol for communication. The SSL protocol is an encryption protocol used for protecting network communication security. The renegotiation feature of the SSL protocol performs identification authentication and key exchange again based on the established secure connections. An attacker can exploit the renegotiation feature to attack servers that use the SSL protocol for communication.

After the attacker uses the legitimate SSL mechanism to establish an SSL connection with the server, the attacker keeps sending SSL renegotiation packets to exhaust the system resources of the HTTPS server.

The detailed attack process is as follows:

1.     An attacker simulates multiple clients or uses proxy to establish SSL connections with the target server. Then, the attacker sends some normal packets to establish sessions and obtains session information of the server.

2.     The attacker sends a large number of renegotiation requests to the server. The requests seem to be the same as normal negotiation requests but they are not complete immediately. The requests continuously consume server resources before completion, which causes slow server responses or server crashes.

Connection-based DDoS attacks

About connection-based DDoS attacks

The two ends of a TCP connection exchange SYN, ACK, SYN-ACK, and RST packets to establish or terminate the connection. Connection-based DDoS attacks use these packets to exhaust the connection resources and increase the processing burden of the target system.

A connection-based DDoS attack uses the connection establishment process of network layer protocols to attack the target server. The attacker occupies the connection queues and resources of the target server with numerous invalid connection requests to prevent legitimate user requests from being processed. This ultimately makes the server unavailable or significantly degraded.

In a connection-based DDoS attack, the attacker sends numerous connection requests without actually establishing connections or transmitting data. The attacker exploits the TCP three-way handshake process to flood the target server with useless requests, as shown in Figure 5. This prevents the server from processing legitimate connection requests, because the processing capacity of the server gets exhausted. That is, the attacker exploits the establishment process of TCP connections on the target server. The attacker establishes abnormal connections with the victim, which prevents legitimate users from connecting to the victim correctly and paralyzes the victim's system.

Attackers use tools and techniques to launch connection-based DDoS attacks to conceal their identities and locations to avoid detection and identification.

Figure 5 Establishing a TCP connection via the three-way handshake mechanism

 

SYN flood attack

The attacker attempts to establish new TCP connections by sending SYN packets to the target server. The server responds with SYN/ACK packets to confirm the connection, but the attacker does not send ACK packets for confirmation. This causes the server to wait indefinitely for connection acknowledgments until the connection queue fills up. As a result, the server fails to respond to legitimate client requests. In this case, the attack implements the denial of service successfully.

Figure 6 SYN flood attack

 

The process of the attack is as follows:

1.     An attacker typically uses software or scripts to automatically generate and send a large number of SYN packets to the target server to request establishing TCP connections.

2.     After the server receives SYN packets, it allocates resources to each connection request and sends a SYN/ACK packet to confirm the connection.

3.     In a SYN flood attack, the attacker sends SYN packets by hiding the real sender. These fake clients do not send ACK packets to confirm the connections, which causes the server to wait long for confirmation.

4.     Because the attacker rapidly sends numerous forged SYN packets, the server's connection resources are quickly depleted. This prevents the server from processing new legitimate connection requests, blocking normal users from establishing TCP connections and resulting in a denial of service.

A SYN flood attack can target any server that supports the TCP protocol, such as a Web server, DNS server, mail server, or FTP server.

SYN-ACK flood attack

When a client (the connection initiator) receives a SYN ACK packet, it must search for the corresponding TCP connection based on the packet's four-tuple (source IP address, source port number, destination IP address, and destination port number). This process consumes the client's computing resources. A SYN-ACK flood attacker can send a large number of forged SYN-ACK packets to the client to reduce the processing performance of the client, which affects the processing of normal packets. This results in the denial of service.

Figure 7 SYN-ACK flood attack

 

The process of the attack is as follows:

1.     An attacker sends a large number of forged SYN-ACK packets to the target client. These packets are typically generated automatically by using software or scripts.

2.     When the client receives these forged SYN - ACK packets, it must search for the corresponding TCP connections based on each packet's four-tuple (source IP address, source port number, destination IP address, and destination port number). This process consumes the client's computing resources.

3.     Because the attacker rapidly sends numerous forged SYN-ACK packets, the client's connection resources are quickly depleted. This prevents the client from processing new legitimate connection requests.

ACK flood attack

ACK packets are used in the TCP connection establishment, data transmission, and connection termination stages. When the server receives an ACK packet, it searches for a matching TCP connection based on the four-tuple of the packet. This operation consumes computing resources of the server. When an attacker sends a large number of forged ACK packets to the server, the workload of the server will increase, which prevents the server from processing normal requests. This results in the denial of service.

Figure 8 ACK flood attack

 

The process of the attack is as follows:

1.     An attacker sends a large number of forged ACK packets to the target server. These packets are typically generated automatically by using software or scripts.

2.     When the server receives a forged ACK packet, it searches for a matching TCP connection based on the four-tuple of the packet. This operation consumes computing resources of the server.

3.     Because the attacker rapidly sends numerous forged ACK packets, the server's connection resources are quickly depleted. This results in the target server experiencing performance degradation or even crashing.

An ACK flood attack can target any server that supports the TCP protocol, such as a Web server, DNS server, mail server, or FTP server. The attacker can use forged source addresses and port numbers, making it difficult for the target server to accurately determine the origin of the forged requests. This makes it more difficult to trace and locate the source of the attack.

RST flood attack

RST packets are used to abort TCP connections when TCP connection errors occur. An attacker sends a large number of forged RST packets to the target server, causing the server to interrupt the existing TCP connections or reject new ones. This results in the denial of service.

The process of the attack is as follows:

1.     An attacker can use network sniffing and port scanning to obtain the target server's TCP connection information, and then send a large number of forged RST packets to the server.

2.     When the target server receives a forged RST packet with the correct source IP, destination IP, source port, destination port, TCP serial number, and TCP acknowledgment number, the server might consider the RST packet legitimate. As a result, the target server mistakenly determines that the TCP connection is closed. Then, the server immediately clears related resources, and sends an RST packet to terminate the TCP connection.

3.     After the server receives an RST packet, the server searches for the corresponding TCP connection. As the attacker rapidly sends a large number of RST packets, the server performs numerous invalid searches. This degrades the server's performance.

A RST flood attack can target any server that supports the TCP protocol, such as a Web server, DNS server, mail server, or FTP server. The attacker can use forged source addresses and port numbers, making it difficult for the target server to accurately determine the origin of the forged requests. This makes it more difficult to trace and locate the source of the attack.

TCP fragment flood attack

A TCP fragment flood attack exploits the characteristics of the TCP fragment protocol by sending a large number of fragmented TCP packets to consume network bandwidth and the resources of the target server. An attacker sends a large number of specially forged fragmented packets to confuse and exhaust the target server's resources. This potentially leads to service unavailability or crash on the server. This type of attack imposes a high consumption of the target server's memory and CPU resources as well as network bandwidth. This is one of typical DDoS attacks.

The process of the attack is as follows:

1.     An attacker sends a large number of forged TCP fragments to the target server. These fragments are directed to the same IP address and port number as the target server, but each fragment has a different serial number and offset.

2.     The target server needs to restore the original packets by reassembling these fragments according to the serial numbers and offsets in the TCP fragment headers. As the attacker deliberately staggered and overlapped the fragments, the target server cannot correctly reassemble the fragments.

3.     To reassemble these fragments as accurately as possible, the target server saves these fragments to the data buffer in its memory. As more and more fragments arrive, the data buffer will gradually be filled up. When the data buffer fills up, the target server's processing capacity faces great pressure, and network bandwidth will be consumed. As a result, the server fails to process normal requests and becomes unavailable.

A TCP fragment flood attack can target any server that supports the TCP protocol and can cause performance degrade or crash on the server.

Volumetric DDoS attacks

About volumetric DDoS attacks

In a volumetric DDoS attack, an attacker sends a large amount of useless requests or malicious data traffic to the target server to intentionally consume the bandwidth and commutating resources of the target server. The attack is to exhaust the server's bandwidth and resources, preventing the server from processing legitimate requests or providing normal services. This type of attack is a typical DDoS attack.

·     In a volumetric DDoS attack, the attacker typically controls many zombie computers by using DDoS to generate massive data traffic and attack the target server. The attacker uses specific tools or scripts to automatically generate numerous requests and simultaneously send them to multiple ports on the target server. As a result, the target server cannot process normal requests.

·     The attacker often uses protocols, such as UDP and ICMP to launch attacks. This is because these two protocols do not require establishing connections like TCP and allow the attacker to quickly generate a large amount of attack traffic. The attacker will also uses specially designed attack tools to increase attack traffic and speed to exhaust the target server's bandwidth and computing resources.

UDP flood attack

A UDP flood attack is a type of DDoS attack that uses the UDP protocol. An attacker sends a large number of UDP packets to the target server in a short period of time to occupy the network bandwidth and CPU resources of the target server. As a result, the server fails to process legitimate requests properly.

The process of the attack is as follows:

1.     An attacker sends a large number of forged UDP packets to the target server. These UDP packets are typically randomly sent and do not comply with any specific data format or protocol.

2.     The target server consumes a significant amount of network bandwidth and computational resources to handle the large number of the received UDP packets. If the processing of the received UDP packets exceeds the capabilities of the target server, it will result in degraded server performance, system downtime, and other issues.

A UDP flood attack can target any server that supports the UDP protocol and can cause performance degrade or crash on the server.

UDP fragment flood attack

A UDP fragment flood attack is a type of DDoS attack based on UDP fragments. An attacker sends a large number of UDP fragment requests to the target server in a short period of time to occupy the network bandwidth, CPU resources, and memory resources of the target server. As a result, the server fails to process legitimate requests properly.

The process of the attack is as follows:

1.     An attacker uses malicious scripts or tools to generate a large number of forged UDP fragment requests, and split them into smaller fragments, and then send them at a high rate to the target server.

2.     The target server reassembles the received UDP fragments to restore the original requests and respond to these requests. After the target server receives a large number of fragment requests, it has to use a lot of computing resources and bandwidth to process these requests. If the processing of the received UDP fragments exceeds the capabilities of the target server, it will result in degraded server performance, system downtime, and other issues.

A UDP fragment flood attack can target any server that supports the UDP protocol and can cause performance degrade or crash on the server.

ICMP flood attack

An attacker sends excessive ICMP packets to the server, which makes the server unable to process normal services. Network congestion also occurs because ICMP attack packets are usually of a big size.

The process of the attack is as follows:

1.     An attacker typically uses tools or malicious scripts to generate a large number of ICMP packets with forged source IP addresses, and send them to the target server at a high rate.

2.     When the target server receives these ICMP packets, it has to resolve these packets. The target server consumes a significant amount of network bandwidth and computational resources to handle the large number of the received ICMP packets. If the processing of the received ICMP packets exceeds the capabilities of the target server, it will result in degraded server performance, system downtime, and other issues.

An ICMP flood attack can target any server that supports the ICMP protocol and can cause performance degrade or crash on the server.

ICMP fragment flood attack

An ICMP fragment flood attack is a type of DDoS attack based on ICMP fragments. An attacker sends a large number of forged ICMP requests to the target server and divides them into many small fragments. The target server has to spend a lot of processing time reassembling these fragments and respond to the forged packets. This occupies a large amount of system resources and network bandwidth.

The process of the attack is as follows:

1.     An attacker uses malicious scripts or tools to generate a large number of forged ICMP fragment requests, and split them into smaller fragments, and then send them at a high rate to the target server.

2.     The target server reassembles the received ICMP fragments to restore the original requests and respond to these requests. After the target server receives a large number of fragment requests, it has to use a lot of computing resources and bandwidth to process these requests. If the processing of the received ICMP fragments exceeds the capabilities of the target server, it will result in degraded server performance, system downtime, and other issues.

An ICMP fragment flood attack can target any server that supports the ICMP protocol and can cause performance degrade or crash on the server.

IP traffic flood attack

An attacker sends a large number of IP packets to the target server to occupy the server's bandwidth and key resources, which causes the network link congestion on the server. As a result, the server degrades in performance or becomes unavailable and cannot process legitimate requests.

User-defined DDoS attacks

You can define a protocol-specific DDoS attack type and specify the packet signature to implement DDoS protection more flexibly.

Table 3 Description for user-defined DDoS attack types

User-defined DDoS attack type	Description
Protocol-specific user-defined DDoS attack	1.     Identify DDoS attack packets sent over a protocol. 2.     You can also specify a packet length match criterion for a protocol-specific DDoS attack type. You can configure the device to match an attack packet when the packet length is smaller than, greater than, or equal to the specified length.
User-defined ICMP-based DDoS attack type	1.     Identify user-defined DDoS attack packets sent over the ICMP protocol. 2.     You can use the packet length, ICMP type, and ICMP code as the packet match criteria for an ICMP-based DDoS attack type. You can configure the device to match an attack packet when the packet length is smaller than, greater than, or equal to the specified length.
User-defined ICMPv6-based DDoS attack type	1.     Identify user-defined DDoS attack packets sent over the ICMPv6 protocol. 2.     You can use the packet length, ICMPv6 type, and ICMPv6 code as the packet match criteria for an ICMPv6-based DDoS attack type. You can configure the device to match an attack packet when the packet length is smaller than, greater than, or equal to the specified length.
User-defined TCP-based DDoS attack type	1.     Identify user-defined DDoS attack packets sent over the TCP protocol. 2.     You can use the packet length, port, and TCP flag as the packet match criteria for a TCP-based DDoS attack type. If all criteria are specified, a TCP packet is an attack packet only if it matches all criteria. ¡     Packet length criterion: The packet length must be smaller than, greater than, or equal to the specified length as required. ¡     Port criterion: Specifies a source port or destination port. ¡     TCP flag criterion: Value for the TCP flags field.
User-defined UDP-based DDoS attack type	1.     Identify user-defined DDoS attack packets sent over the TCP protocol. 2.     You can use the packet length and port number as the packet match criteria for a UDP-based DDoS attack type. If both criteria are specified, a UDP packet is an attack packet only if it matches these criteria ¡     Packet length criterion: The packet length must be smaller than, greater than, or equal to the specified length as required. ¡     Port criterion: Specifies a source port or destination port.

 

H3C anti-DDoS implementation

DDoS attack detection modes

About DDoS attack detection modes

The device supports two DDoS attack detection modes: Deep packet inspection and deep flow inspection. It detects DDoS attacks on the traffic flowing through the network, meeting different requirements for DDoS attack detection and protection various traffic scenarios. The following table shows the difference between these two detection modes:

Table 4 Deep packet inspection and deep flow inspection

Item	Deep packet inspection	Deep flow inspection
Data detection volume	All traffic is detected in this mode. Therefore, this mode requires a greater detection workload. ·     In an inline deployment solution, the gateway performs DDoS attack detection on all incoming traffic, as the gateway has detection capabilities. ·     In an one-arm deployment solution, the cord device uses port mirroring to replicate all packets passing through the network and send them to the detection device where they will be examined.	Deep flow inspection only samples packets in this mode. Therefore, this mode requires a less detection workload. Deep flow inspection uses traffic collection technologies to sample packets passing through the network core device, encapsulates sampling results in the flow statistics packets, and then sends them to the detection device. The supported traffic collection protocols include NetFlow, NetStream, and sFlow.
Detection content	Supports deep application layer inspection.	Supports only extensive DDoS detection.
Application scenarios	·     Scenarios that have small volumes of traffic, such as small-to-medium enterprises. ·     Scenarios that require detailed DDoS detection or application layer detection.	·     Scenarios that have high volumes of traffic, such as data centers. ·     Scenarios that require only extensive DDoS detection.

 

Deep packet inspection

Deep packet inspection (DPI) is a traffic analysis technology that analyzes the content and header information of packets to gain a comprehensive understanding of the applications, protocols, and payloads in network traffic. DPI can identify protocol types, application programs, data content, and traffic characteristics by examining the details in the packets.

With DPI configured, the device directs all incoming traffic to the detection device for DDoS attack detection.

·     In an inline deployment, the gateway directly detects all incoming traffic for DDoS attacks.

·     In a one-arm deployment, the core network device uses port mirroring to create a 1:1 copy of the traffic passing through it and sends it to a dedicated detection device for DDoS attack detection.

With DPI configured, the detection device must analyze all network traffic. This requires high processing power, especially with heavy traffic. Therefore, DPI is applicable to scenarios that have small volumes of traffic and requires intensive DDoS attack detection, or scenarios that require detection at the application layer, such as enterprise networks.

 

NOTE: In an inline deployment, the cleaning device supports only DPI.

 

With DPI configured, the detection device analyzes all network traffic, filtering out potential attack traffic. It pays special attention to characteristics such as the source and destination addresses, packet size, and packet rate to help identify potential attacks. The specific operating principle is as follows:

·     Behavior identification—DPI identifies potential attack behavior characteristics by analyzing packet information such as the source address, destination address, and packet size. For example, SYN attacks, ICMP attacks, and UDP/TCP hijacking.

·     Traffic analysis—DPI analyzes the traffic of each source address and destination address to determine their status and traffic proportion in the network. By analyzing traffic statistics, administrators can identify which addresses generate significant traffic or occupy network bandwidth.

·     Attack detection—DPI uses predefined rules and algorithms to identify potential attack behaviors based on traffic statistics and behavior identification. By analyzing traffic statistics and identified behavioral patterns, DPI can detect potential attack behaviors and respond accordingly. This can include blocking specific IP addresses, generating alarms, adjusting traffic policies, and more to protect network security and stability.

Deep flow detection

NOTE: Only the one-arm deployment mode supports deep flow detection.

 

Deep flow inspection (DFI) is an advanced network traffic analysis technology that performs deep analysis and processing of network traffic by examining the content and header information of packets. It identifies application layer protocols, conducts traffic analysis, and implements policy matching.

DFI uses traffic collection technologies to sample packets passing through the network core device, encapsulates sampling results in the flow statistics packets, and then sends them to the detection device. Supported traffic collection protocols include NetFlow, NetStream, and sFlow. Traffic collection packets contains the following traffic summary information about the packets passing through the network core device: destination IP address, source IP address, destination port number, source port number, protocol, ToS, and packet length. The application layer information is not contained. This mode is applicable to scenarios that have high volumes of traffic and require extensive DDoS attack detection, such as MAN networks.

DFI primarily relies on deep analysis of network traffic characteristics and modeling to identify and defend against DDoS attack. The specific operating principle is as follows:

·     Traffic identification—DFI first identifies the flows in network traffic. A flow represents a sequence of packets in a network, sharing the same source address, destination address, protocol type, source port, and destination port. DFI groups packets by identifying the characteristics of the flow, allowing for more detailed analysis and processing.

·     Flow analysis—DFI conducts in-depth analysis of identified flows, including breaking them down into packets, extracting various fields from the packets (such as source and destination addresses, protocol types, and port numbers), and obtaining information about the flow's duration and traffic size. By conducting a detailed analysis of the flow, DFI can understand the flow's characteristics, behavior patterns, and the data it carries.

·     Flow detection—DFI uses predefined rules, algorithms, and models to detect and analyze flows, identifying potential security threats or violations. These rules and algorithms can be based on specific protocols, application layer characteristics, behavior patterns, and network threat intelligence. DFI can detect various network threats and attacks, such as the propagation of malicious software (malware), DDoS attacks, and zombie attacks.

·     Response and management—Based on the detection results, DFI can take appropriate response and handling measures. For example, block specific traffic flow, log relevant information, generate alert notifications, and adjust network policies. DFI can also integrate with other security devices and systems to collectively respond to and handle threats.

Permitting management traffic

To prevent management packets sent to the device from being dropped by the cleaning device, which would render management methods such as Telnet, SSH, and HTTP unavailable, both the detection device and the cleaning device support the function to allow management traffic through.

By configuring the out-of-band management traffic function, set the physical interface as the out-of-band interface for DDoS attack detection and prevention services. The device will not perform DDoS attack detection and prevention on the traffic entering the out-of-band interface.

Anti-DDoS zone

Anti-DDoS zone

An anti-DDoS zone is a set of protected IP addresses.

 

NOTE: To simplify DDoS protection configuration, you can add IP addresses that require the same DDoS protection to one zone.

 

Anti-DDoS zones can be categorized into the default anti-DDoS zone and non-default anti-DDoS zones.

Default anti-DDoS zone:

·     By default, it always exists and protects all IP addresses by default. You do not need to assign IP addresses to the zone.

·     The default anti-DDoS zone is used for configuring the default DDoS protection parameters.

·     If the IP addresses of packets passing through the device do not belong to any non-default anti-DDoS zone, the DDoS protection in the default anti-DDoS zone applies.

Non-default anti-DDoS zone:

·     Users need to manually create and configure the protected IP addresses.

·     The DDoS protection configuration in an anti-DDoS zone applies to all IP addresses in that zone.

How packets match anti-DDoS zones

To process a packet for DDoS protection, the device first determines whether the destination IP address of the packet is in a non-default anti-DDoS zone.

·     If the destination IP address is in a non-default zone, the device processes the packet based on the DDoS protection configuration in the zone.

·     If the destination IP address is not in any non-default zone, the device processes the packet as follows:

¡If the default anti-DDoS zone is enabled, the device processes the packet based on the DDoS protection configuration of the default zone.

¡If the default anti-DDoS zone is disabled, the device sends the packet to the subsequent process without DDoS protection processing.

DDoS attack prevention thresholds

Thresholds for defending against various types of DDoS attacks

DDoS attack detection relies on prevention thresholds, so you can determine if the traffic is a DDoS attack for a specified protocol by configuring prevention thresholds for various DDoS attacks.

·     When you set the detection threshold for traffic of a protocol in a zone, the DDoS attack detection is enabled for packets of this protocol in this zone.

·     The device counts the number of the protocol packets per second sent to each IP address in the zone. If the number of the packets destined for an IP address exceeds the prevention threshold, the IP address is being attacked.

 

NOTE: Configuring a DDoS attack prevention threshold also enables DDoS attack prevention.

 

Table 5 DDoS attack defense threshold and its role

DDoS attack type	DDoS attack method	Configurable attack prevention threshold	Role of the prevention threshold
Resource-consuming DDoS attacks	SSL renegotiation attack	SSL renegotiation attack prevention threshold	With the SSL renegotiation protection enabled, the device starts the following operations when an SSL session fails the first negotiation: ·     Counting the number of renegotiations for the session. ·     Counting down the renegotiation check interval and the abnormal SSL session check interval. If the number of renegotiations exceeds the threshold within the renegotiation check interval, the device identifies this session as abnormal. If the number of abnormal sessions originated from an IP address exceeds the threshold within the abnormal session check interval, the device adds this IP address to the blacklist.
	HTTP slow attack	HTTP slow attack prevention threshold	With HTTP slow attack detection enabled, the device counts the number of concurrent HTTP connections on a per-destination IP basis. When the number of concurrent connections to an IP address exceeds the threshold, the device inspects the following types of HTTP packets and counts the number of attack packets: ·     Slow headers—If the packet header does not start with \r\n\r\n, the device marks those packets as attack packets. ·     Slow POST—If the value in the Content-Length field is greater than the content length threshold and the payload size is smaller than the payload length threshold, the device marks those packets as attack packets. When the number of HTTP attack packets destined for an IP address exceeds the threshold, the device blocks subsequent packets to this IP address and sends an attack alarm log. If you specify the block-source action, the device adds the packet source IP address to the dynamic blacklist.
	DNS query flood attack	DNS query flood attack prevention threshold	After you enable flood attack detection for a zone, the device enters attack detection state and monitors the sending rate of packets per destination IP address in that zone. When the sending rate of packets destined for an IP address keeps exceeding the threshold, a flood attack occurs and triggers one of the following protection actions: ·     In the one-arm deployment mode, the detection device sends an attack alarm log to the management center. Upon receiving the log, the management center assigns a traffic redirection policy to guide the attack traffic to the cleaning device where the attack traffic will be cleaned. ·     In the inline deployment mode, the cleaning device cleans the attack traffic locally. When the sending rate of packets destined for the IP address drops below the silence threshold (three-fourths of the detection threshold), the device returns to the attack detection state.
	DNS reply flood attack	DNS reply flood attack prevention threshold
	HTTP flood attack	HTTP flood attack prevention threshold
	HTTPS flood attack	HTTPS flood attack prevention threshold
	SIP flood attack	SIP flood attack prevention threshold
Connection-based DDoS attacks	SYN flood attack	SYN flood attack prevention threshold
	SYN-ACK flood attack	SYN-ACK flood attack prevention threshold
	ACK flood attack	ACK flood attack prevention threshold
	RST flood attack	RST flood attack prevention threshold
	TCP fragment flood attack	TCP fragment flood attack prevention threshold
Volumetric DDoS attacks	UDP flood attack	UDP flood attack prevention threshold
	UDP fragment flood attack	UDP fragment flood attack prevention threshold
	ICMP flood attack	ICMP flood attack prevention threshold
	ICMP fragment flood attack	ICMP fragment flood attack prevention threshold
	IP traffic attack	IP traffic attack prevention threshold
Custom DDoS attacks	User-defined protocol-specific DDoS attack	User-defined protocol-specific DDoS attack prevention threshold	After you enable user-defined attack detection for a zone, the device enters attack detection state and monitors the sending rate of incoming protocol packets in that zone. When the sending rate of protocol packets destined for an IP address keeps exceeding the threshold, a user-defined attack occurs and triggers one of the following protection actions: ·     In the one-arm deployment mode, the detection device sends an attack alarm log to the management center. Upon receiving the log, the management center assigns a traffic redirection policy to guide the attack traffic to the cleaning device where the attack traffic will be cleaned. ·     In the inline deployment mode, the cleaning device cleans the attack traffic locally. When the sending rate of packets destined for the IP address drops below the silence threshold (three-fourths of the detection threshold), the device returns to the attack detection state.
	User-defined ICMP-based DDoS attack	User-defined ICMP-based DDoS attack prevention threshold
	User-defined ICMPv6-based DDoS attack	User-defined ICMPv6-based DDoS attack prevention threshold
	User-defined TCP-based DDoS attack	User-defined TCP-based DDoS attack prevention threshold
	User-defined UDP-based DDoS attack	User-defined UDP-based DDoS attack prevention threshold

 

DDoS attack prevention threshold learning

If the types and volumes of traffic passing through the device change frequently, user-defined detection thresholds cannot meet the actual anti-DDoS needs.

·     A higher threshold might mistakenly permit the DDoS attack traffic to pass though, bringing severe security risk to the network.

·     A lower threshold might mistakenly drop legitimate traffic, blocking normal network access

To obtain a reasonable threshold in the live network, enable automatic threshold learning in the zone. This feature allows the device to periodically collect statistics of protocol packets destined for IP addresses in the zone, and report statistics to the management center. The management center analyzes the statistics, calculates the detection threshold, and deploys the defense policy.

 

NOTE: Only non-default anti-DDoS zones support this feature.

 

Traffic cleaning

Traffic cleaning overview

H3C's comprehensive anti-DDoS solution supports five core cleaning technologies (blacklist and whitelist, filter, fingerprint protection, source verification, and rate limiting) to effectively prevent various types of DDoS attacks. By detecting and identifying DDoS attacks in traffic, the solution drops or rate limits DDoS attack traffic through traffic cleaning. This ensures that normal business traffic in the network remains unaffected while removing attack traffic.

 

Cleaning technology	Prevention method
Blacklist	Add known malicious IPs, domain names, and URLs to the blacklist and drop packets from known unsafe IP addresses.
Filters	Drop or limit packets that match certain packet fields or attributes.
Fingerprint protection	Drop or limit packets that match certain characteristics.
Source verification	Drop packets that fail source verification.
Packet rate limiting	Drop packets destined for an IP address that exceed the specified rate limit.

 

The H3C anti-DDoS solution supports the combined application of cleaning technologies, gradually filtering out DDoS attack traffic through multiple composite cleaning techniques. The cleaning device processes attack traffic in the order shown in Figure 9.

Figure 9 Combined application of cleaning technologies

 

Blacklist and whitelist

Principle

In DDoS protection, blacklist and whitelist are a common IP address-based access control method. Using the blacklist and whitelist enhances the defense efficiency of cleaning devices while ensuring effective protection.

·     Blacklist: Identify the IP address of the attack source and add it to the blacklist to prevent its traffic from further affecting the destination host. The cleaning device immediately drops traffic from IP addresses on the blacklist and does not conduct further detection and analysis.

·     Whitelist: Add trusted source IP addresses to the whitelist. The cleaning device does not detect or prevent DDoS attacks on traffic from IP addresses on the whitelist, except for packet rate limiting. For traffic from IP addresses not on the whitelist, the device will continue with subsequent detection and cleaning processes.

Figure 10 Using the blacklist and whitelist for traffic cleaning.

 

Blacklist implementation

NOTE: ·     Use the blacklist technology for defending against only DDoS attacks based on IP addresses. It is not suitable for other types of DDoS attacks, such as DNS and NTP attacks. ·     To ensure the effectiveness of DDoS attack defense, continuously update and monitor the blacklist to promptly respond to new attack sources and types, as DDoS attacks often use multiple attack methods and origins.

 

Users can manually add blacklist entries or other cleaning technologies can trigger their creation. The device drops packets whose source IP address matches a blacklist entry.

H3C cleaning devices support the following types of blacklists:

·     Global static blacklist

¡The entries are manually configured. They never expire unless they are manually deleted from the blacklist.

¡The device drops packets whose source IP addresses match the global static blacklist entries.

¡Configure the global static blacklist by using the IP address and subnet mask to drop packets from the specified network.

·     Anti-DDoS zone-based static blacklist

¡The entries are manually configured. They never expire unless they are manually deleted from the blacklist.

¡The device drops packets destined for an anti-DDoS zone if their source IP addresses match the static blacklist entries of that zone.

¡An anti-DDoS zone-based static blacklist takes effect on an individual anti-DDoS zone. Configure an anti-DDoS zone-based static blacklist by using the IP address and subnet mask to drop packets from the specified network.

·     Dynamic blacklist

¡The device automatically adds IP addresses that fail source verification to the dynamic blacklist. H3C supports the following types of source verification:

-     DNS query source verification.

-     DNS reply source verification.

-     HTTP packet source verification.

-     HTTPS packet source verification.

-     SIP packet source verification.

-     SYN packet source verification.

¡If you specify the block-source action and the attack HTTP packets destined for an IP address exceeds the threshold, the device adds the packet source IP address to the dynamic blacklist.

¡During the aging time of the dynamic blacklist entry, the device will drop all packets from that IP address.

¡The aging time for dynamic blacklist entries is configured globally, and any changes to the aging time will apply to all dynamic blacklist entries.

Whitelist implementation

NOTE: Use the blacklist technology for defending against only DDoS attacks based on IP addresses. It is not suitable for other types of DDoS attacks, such as DNS and NTP attacks.

 

Whitelist entries are manually added by users or automatically generated by other cleaning technologies. Devices allow packets with source IP addresses that match whitelist entries and then only apply rate limiting to them, without processing them through other filtering units.

H3C cleaning devices support the following types of whitelists:

·     Global static whitelist

¡The entries are manually configured. They never expire unless they are manually deleted from the whitelist.

¡Packets whose source IP addresses match the global static whitelist entries are permitted to pass through. The device takes only the rate limiting action on these packets if their rate exceeds the threshold.

¡Configure the global static whitelist by using the IP address and subnet mask to permit packets from the specified network.

·     Anti-DDoS zone-based static whitelist

¡The entries are manually configured. They never expire unless they are manually deleted from the whitelist.

¡Packets destined for an anti-DDoS zone are permitted to pass through if their source IP addresses match the static whitelist entries of this zone. The device takes only the rate limiting action on these packets if their rate exceeds the threshold.

¡An anti-DDoS zone-based static whitelist takes effect on an individual anti-DDoS zone. Configure an anti-DDoS zone-based static whitelist by using the IP address and subnet mask to permit packets from the specified network.

·     Dynamic whitelist (trusted IP list)

¡The device automatically adds IP addresses that pass source verification to the dynamic whitelist (trusted IP list). H3C supports the following types of source verification:

-     DNS query source verification.

-     DNS reply source verification.

-     HTTP packet source verification.

-     HTTPS packet source verification.

-     SIP packet source verification.

-     SYN packet source verification.

¡Packets with the source IP address on the trusted IP list are allowed to pass through before the whitelist entry expires. The device takes only the rate limiting action on these packets if the packet rate exceeds the threshold. Packets that fail source verification will be dropped.

¡The aging time for dynamic whitelist entries is configured globally, and any changes to the aging time will apply to all dynamic whitelist entries.

Filters

A filter allows you to configure match rules based on various packet attributes to implement packet filtering in a finer granularity. The cleaning device can take the specified action, such as drop or rate-limit, on the packets that match a filter. The filter allows you to specify a set of rules to match packets for packet filtering. You can create match rules by using the protocol, port number, IP address, and other protocol-specific fields to achieve fine-grained packet filtering.

Figure 11 Diagram of a filter

 

You can configure both general rules and protocol-specific rules in a filter:

·     General rules—Include rules to match general packet fields, such as source IP address, destination IP address, DSCP value, TTL, fragmentation status, and packet length.

·     Protocol-specific rules—Vary by the filter type as follows:

¡     IP filter—Matches the protocol field.

¡     TCP filter—Matches the TCP flags, source port number, and destination port number fields.

¡     UDP filter—Matches the source port number and destination port number fields.

¡     DNS filter—Matches the packet type, QR field, domain name field, and source port number fields.

¡     HTTP packet filter—Matches the cookie, host, referer, user-agent, TCP flags, request packet type, and request URI fields. HTTP filters support using source verification as a defensive action.

¡     SIP filter—Matches the callee, caller, and source port number fields.

Fingerprint protection

Fingerprint signatures include the packet length, TTL, source port number, destination port number, and payload information. The fingerprint protection uses fingerprint signatures to match packets, and filters out or rate limits the matching packets. It can effectively defend against volumetric DDoS attacks, such as UDP flood attack.

Fingerprint signatures on a cleaning device can be manually configured or automatically learned.

 

NOTE: ·     A fingerprint policy contains fingerprint signatures for packet match and a defensive action on the matching packets. Fingerprint signatures can be manually configured or automatically learned. ·     For a fingerprint policy to take effect in an anti-DDoS zone, configure the policy in a fingerprint protection group, and apply the group to the zone.

 

·     To manually configure fingerprint signatures, specify the fingerprint content, the fingerprint offset in the IP header, and fingerprint length. The device counts the number of packets that have the matching fingerprint signature in the IP header. A fingerprint signature is hit if the fingerprint content obtained based on the offset value and fingerprint length is the same as the defined fingerprint content. When the number of matching packets exceeds the fingerprint protection threshold, the device takes an action on the subsequent matching packets.

·     To enable the cleaning device to automatically learn fingerprint signatures from attack packets, specify the fingerprint offset in the IP header and the fingerprint length. The cleaning device collects the packet signature based on the fingerprint offset value and fingerprint length. A packet signature becomes a fingerprint signature if the packet signature has a high occurrence. When the number of packets with the matching signature exceeds the threshold, the device takes an action on the subsequent matching packets.

Attack source verification

This feature prevents application flood attacks and SYN flood attack. After you enable this feature for a protocol on the cleaning device, the device will act as a proxy to protect application layer or TCP connections. When the cleaning device detects an application attack or SYN flood attack aimed to a server, the device adds the server IP address as a protected IP address for source verification, and verifies the source. Packets that fail the source verification are dropped.

DDoS attack source verification protects IP addresses in an anti-DDoS zone against flood attacks of application layer packets and SYN packets. When detecting a DDoS attack of a specific protocol on an IP address, the cleaning device performs one of the following operations:

·     If source verification is enabled for the protocol packets, the device adds the IP address to the protected IP list and verifies the source IP address of the packet:

¡     If the source IP address passes source verification, the device adds the IP address to the trusted IP list and allows packets from this IP address to pass through.

¡     If the source IP address fails source verification, the device adds the IP address to the dynamic blacklist and drops packets from this IP address. The aging time of dynamic blacklist entries is configurable.

·     If source verification is not enabled for the protocol packets, the device limits the packet receiving rate below the silence threshold. The protocol packets that exceed the threshold are dropped.

 

IMPORTANT: ·     The DNS reply source verification feature requires that servers use the standard TCP/IP protocol suite and DNS protocol. Legitimate servers that use non-standard protocols will be verified as illegitimate by the DNS reply authenticator. ·     A legitimate user might fail SIP source verification and cannot access the server if the SIP packet header information is incomplete and the device fails to resolve header fields.

 

With the source verification feature enabled, the cleaning device will respond to connection requests on behalf of the destination device. This helps prevent DDoS attacks featuring connection and resource consumption.

 

During the source verification process, the cleaning device actively initiates verification with the client. If the client responds with valid information, the verification succeeds. If not, the cleaning device will reject subsequent traffic from the client.

DNS query source verification

IMPORTANT: ·     The DNS source verification feature requires that clients use the standard TCP/IP protocol suite and DNS protocol. Legitimate clients that use non-standard protocols will be verified as illegitimate by the DNS client authenticator. ·     With source verification, the first DNS resolution takes more time than normal DNS resolution.

 

Figure 12 DNS query source verification process

 

The device with DNS query source verification feature configured is called a DNS client authenticator.

The DNS source verification functions as follows:

1.     Upon receiving a UDP DNS query destined for a protected server, the DNS client authenticator responds with a DNS truncate (TC) packet. The DNS truncate packet requires the client to initiate a query in a TCP packet.

2.     When the authenticator receives a DNS query in a TCP SYN packet to port 53 from the client, the authenticator responds with a SYN-ACK packet that contains an incorrect sequence number.

3.     When the authenticator receives a RST packet from the client, the authenticator verifies the client as legitimate.

4.     The authenticator adds the client's IP address to the trusted IP list and forwards the trusted client's subsequent packets to the server.

DNS reply source verification

The device with DNS reply source verification feature configured is called a DNS reply authenticator.

As shown in Figure 13, the DNS reply verification functions as follows:

1.     Upon receiving a UDP DNS reply destined for a protected client, the DNS reply authenticator sends back a DNS query packet with the locally generated query ID and port number.

2.     After receiving the DNS query, a valid DNS server responds with a DNS reply that contains a new query ID and destination port.

3.     The DNS reply authenticator verifies the query ID and destination port in the reply. If the query ID and destination port are the same as the query ID and port number the authenticator has sent, the DNS server passes verification. The authenticator will forward subsequent packets from the server.

Figure 13 DNS reply verification process

 

HTTP GET source verification

The device with HTTP source verification feature configured is called an HTTP client authenticator.

When an HTTP client authenticator receives a SYN packet from a client, the authenticator first performs TCP source verification in SYN Cookie mode as a TCP proxy, as shown in Figure 14.

After the client passes TCP source verification, the HTTP client authenticator uses HTTP GET requests to verify the HTTP client as follows:

1.     When the authenticator receives an HTTP GET packet from the client, it performs the first redirect verification. The authenticator records the client information and responds with an HTTP Redirect packet. The HTTP Redirect packet contains a redirect URI and requires the client to terminate the TCP connection.

2.     After receiving the HTTP Redirect packet, the client terminates the TCP connection and then establishes a new TCP connection with the authenticator.

3.     When the authenticator receives the HTTP GET packet, it performs the second redirection verification. The authenticator verifies the following information:

¡     The client has passed the first redirection verification.

¡     The URI in the HTTP GET packet is the redirect URI.

4.     If the client passes the second redirection verification, the authenticator adds its IP address to the trusted IP list, and responds a Redirect packet. The Redirect packet contains the URI that the client originally carried and requires the client to terminate the TCP connection.

5.     The authenticator directly forwards the trusted client's subsequent packets to the server.

Figure 14 HTTP GET source verification process

 

HTTP POST source verification

As shown in Figure 15, the HTTP client authenticator uses HTTP POST requests to verify the HTTP client as follows:

1.     Upon receiving a SYN packet destined for a protected HTTP server, the HTTP client authenticator performs TCP source verification in SYN Cookie mode. If the client passes the TCP source verification, a TCP connection is established between the client and the authenticator.

2.     When the authenticator receives an HTTP POST request from the client, it performs the redirect verification. The authenticator records the client information and responds with an HTTP Redirect packet. The HTTP Redirect packet contains a redirect URI and the Set-Cookie header, and requires the client to terminate the TCP connection.

3.     After receiving the HTTP Redirect packet, the client terminates the TCP connection and then establishes a new TCP connection with the authenticator.

4.     When the authenticator receives the HTTP POST request, it performs the timeout verification. The authenticator verifies the following information:

¡     The client has passed the redirection verification.

¡     The HTTP POST request contains a valid cookie.

5.     If the client passes the timeout verification, the authenticator adds its IP address to the trusted IP list, and responds with an HTTP Timeout packet. The Timeout packet contains the URI that the client originally carried and requires the client to terminate the TCP connection.

6.     The authenticator directly forwards the trusted client's subsequent packets to the server.

Figure 15 HTTP POST source verification process

 

HTTPS source verification

As shown in Figure 16, the HTTPS source verification functions as follows:

1.     After the HTTPS client and the HTTPS client authenticator establish a TCP connection, the client sends a client hello message to the authenticator.

¡     If the authenticator receives this hello message, it verifies the client as legitimate and adds the client address to the trusted IP list. The authenticator will forward subsequent packets from this client.

¡     If the authenticator does not receive the client hello message, the authenticator verifies the client as illegitimate, and it will drop subsequent packets from the client.

2.     The authenticator sends an RST packet to the legitimate client to terminate the TCP connection. The client then can establish an SSL connection with the HTTPS server.

Figure 16 HTTPS source verification process

 

SIP source verification

A device with the SIP source verification feature configured is called an SIP client authenticator.

As shown in Figure 17, the SIP source verification functions as follows:

1.     Upon receiving a UDP INVITE packet destined for a protected server, the SIP client authenticator sends back an OPTIONS packet with a branch value.

2.     After receiving the OPTIONS packet, the client sends an OPTIONS ACK to the SIP client authenticator.

3.     When receiving the OPTIONS ACK, the SIP client authenticator verifies the branch value in the OPTIONS ACK.

¡     If the branch value in the OPTIONS ACK is the same as the branch value in the OPTIONS packet that the SIP client authenticator has sent, the client passes verification. The authenticator will forward subsequent packets from the client.

¡     If the branch value in the OPTIONS ACK is different from the branch value in the OPTIONS packet that the SIP client authenticator has sent, the client fails verification. The authenticator drops packets from the client.

Figure 17 SIP source verification process

 

SYN source verification

This feature supports only the safe reset mode. This mode is also known as the unidirectional TCP proxy mode because the device processes only external SYN packets destined for the internal network.

As shown in Figure 18, the safe reset mode functions as follows:

1.     After receiving a SYN packet destined for a protected server, the TCP proxy sends back a SYN ACK packet with an invalid sequence number.

2.     If the TCP proxy receives an RST packet from the client, the client is verified as legitimate.

3.     The TCP proxy adds the client's IP address to the trusted IP list. The client initiates the connection again and the TCP proxy directly forwards the TCP packets to the server.

The safe reset mode requires that TCP clients comply with the TCP protocol suite. The TCP proxy will deny a legitimate client to access the server if the client does not comply with the TCP protocol suite. With source verification, the TCP connection establishment takes more time than normal TCP connection establishment.

Figure 18 TCP proxy in safe reset mode

 

Packet rate limiting

Packet rate limiting limits the rate for different types of traffic destined for each IP address in an anti-DDoS zone. After you enable this feature for traffic of a specific type and set a rate threshold in a zone, the cleaning device drops incoming packets of this traffic type that exceed the threshold.

When packets of a specified type destined for an IP address in an anti-DDoS zone exceeds the rate threshold, the cleaning device drops packets that exceed the threshold.

If you set the total rate threshold and thresholds for both packets and fragments of a protocol, the device rate limits packets of this protocol as follows:

·     Rate limits non-fragment packets by using the packet threshold and the total rate threshold in the descending order.

·     Rate limits fragments by using the packet threshold, fragment threshold, and the total threshold in the descending order.

When you set rate thresholds for both packets and fragments of a protocol, set the threshold for the fragments to a smaller value as a best practice.

DDoS protection logs

The management center collects traffic types and volumes and traces DDoS attacks based on different types of DDoS protection logs. By configuring the DDoS protection log output feature, you can enable the device to send DDoS protection logs to the management center.

Traffic analysis logs

A traffic analysis log contains the packet rate and protocol type.

·     The cleaning device deployed in the inline mode and the detection device regularly send traffic analysis logs to the management center during their running period.

·     The cleaning device deployed in the one-arm mode starts regularly sending traffic analysis logs to the management center after receiving the protection instruction from the management center. It stops reporting traffic analysis logs after receiving the protection end instruction.

Attack alarm logs

A DDoS attack alarm log contains the attack target IP address, port number, and attack traffic information. The cleaning device deployed in the inline mode or the detection device can report attack start and end events to the management center in attack alarm logs.

·     When a DDoS detection threshold is violated, the device detects a DDoS attack and sends an attack start log to the management center.

·     When the attack packet rate drops below the silence threshold (three-fourths of the threshold), the DDoS attack ends and the device sends an attack end log to the management center.

The similar mechanism applies when the fingerprint protection reports DDoS attack logs to the management center.

Attack information logs

When a DDoS attack occurs, the detection device regularly reports attack information logs to the management center. An attack information log contains the following information: destination IP address, destination port number, source IP address, source port, and attack traffic information. The detection device stops reporting attack information logs when it detects that the DDoS attack ends.

Cleaning devices do not support reporting attack log information.

Logs of top 5 fingerprints

Logs of this type record top 5 fingerprint hit statistics in each fingerprint policy group. Cleaning devices report top 5 fingerprint logs at intervals of 1 minute.

Anti-DDoS diversion and injection techniques (applicable only in one-arm deployment mode)

About diversion and injection

Diversion techniques

In one-arm deployment mode, the anti-DDoS system needs to use the traffic diversion (also known as redirection) techniques to divert DDoS attack traffic to a cleaning device for scrubbing.

·     Anti-DDoS diversion techniques include static diversion (PBR-based diversion) and dynamic diversion (BGP-based diversion).

·     Typically, the cleaning device needs both static diversion and dynamic diversion configurations to meet the diverse requirements of DDoS protection.

Table 6 Diversion technique comparison

Diversion technique	Configuration guidelines and diversion mechanism	Applicable scenarios
Static diversion (PBR-based diversion)	·     Configure policy-based routing (PBR) on the core device to forward to the cleaning device the traffic that accesses the protected network and is received on the external-facing interface. ·     Packets matching the diversion policy will be diverted to the cleaning device, regardless of whether the detection device detects a DDoS attack.	·     Use this technique for real-time DDoS protection on key protection targets. ·     This technique is suitable for comprehensive defense of a few high-risk network segments.
Dynamic diversion (BGP-based diversion)	·     Configure BGP on both the core device and the cleaning device. ·     When the detection device detects DDoS attacks, the management center generates diversion policies to divert the attack traffic to the cleaning device.	This technique is suitable for DDoS protection on a massive number of IPs.

 

Injection techniques

In one-arm deployment mode, because the core device has pre-learned the diversion routes, the traffic injected into the core device might be diverted back to the cleaning device again, creating a routing loop. To avoid this issue, configure the cleaning device to inject cleaned traffic back to the original network, which then forwards the traffic to the protected network. Injection techniques include the following types:

·     Static injection—Static injection rules are manually configured. Static injection techniques include static route injection, Layer 2 injection, PBR-based injection, and GRE injection.

·     Dynamic injection—Dynamic injection rules are dynamically generated by related protocols. MPLS LSP injection is one such technique.

Table 7 Injection technique comparison

Injection technique		Configuration guidelines	Applicable scenarios
Static injection techniques	Static route injection	Configure static routes between the cleaning device and core device.	When PBR-based diversion is used
	Layer 2 injection	You need to obtain the VLAN of each protected network segment, and create VLAN interfaces on the cleaning device for these VLANs for traffic injection.	Layer 2 injection is suitable for scenarios where only Layer 2 forwarding devices and no Layer 3 forwarding devices exist between the anti-DDoS system and the protected network.
	PBR-based injection	Configure PBR on the injection interface connecting the core device to the cleaning device, and configure the next hop of the PBR policy as an interface address of a downstream distribution device.	·     Because PBR-based injection requires you to manually configure PBR for the target network segments, it is suitable for scenarios with fewer network segment addresses and fewer downstream distribution devices. ·     If the network topology changes, you must manually adjust the configuration of static routes and PBR. Therefore, this method is suitable for a Layer 3 network with a stable topology. ·     You must have permissions to configure the core device.
	GRE injection	Manually establish a one-to-one GRE tunnel between the cleaning device and each distribution device.	Because this method requires you to manually establish a one-to-one GRE tunnel between the cleaning device and each distribution device, this method is suitable for scenarios with fewer distribution devices. If the network topology changes, you must manually adjust the GRE tunnel configuration. This method is suitable for a Layer 3 network with a stable topology.
Dynamic injection techniques	MPLS LSP injection	This injection method requires both the core device and the distribution devices to support MPLS. You must enable LDP on the interfaces that interconnect the cleaning device, core device, and distribution devices to dynamically establish LSPs.	N/A

 

Cooperation of diversion and injection techniques

In one-arm deployment mode, the anti-DDoS system uses the traffic diversion techniques to divert DDoS attack traffic to the cleaning device for scrubbing. Then, the anti-DDoS system uses the injection techniques to inject the cleaned traffic back to the core device, which then forwards traffic to the original destination address.

The anti-DDoS system supports various diversion and injection techniques. You can combine the appropriate techniques based on different deployment scenarios and network environments.

Table 8 Cooperation of diversion and injection techniques

Injection type	Injection technique	Matching diversion technique	Remarks
Static injection	Static route injection	PBR-based diversion	When PBR-based diversion is used, the PBR policy applied to the external-facing interface of the core device will not affect the injection of cleaned traffic. The cleaning device only needs to inject cleaned traffic to the core device through static routing.
	Layer 2 injection	BGP-based diversion	When BGP-based diversion is used, the core device has diversion routes with the next hop as the cleaning device. As a result, the traffic injected into the core device might be diverted to the cleaning device again, creating a loop. To address this issue, you must configure Layer 2 injection or PBR-based injection on the cleaning device to send the cleaned traffic to the distribution devices. Doing so will prevent the traffic from matching the diversion routes on the core device.
	PBR-based injection
	GRE injection
Dynamic injection	MPLS LSP injection

 

PBR-based diversion

PBR-based diversion is a static diversion method. In this method, you must configure PBR on the core device to forward all traffic that matches the PBR policy and is received on the external-facing interface of the core device to the cleaning device for scrubbing.

PBR is manually configured and PBR-based diversion does not require the detection device to check for DDoS attacks before diversion. This diversion method is suitable for comprehensive real-time DDoS attack protection for key protection targets.

Figure 19 Schematic diagram of PBR-based diversion

 

BGP-based diversion

BGP-based diversion is a dynamic diversion method. When the detection device detects a DDoS attack, it reports the attack logs to the management center. The management center generates a diversion policy and either automatically deploys it to the cleaning device or waits for the user to manually acknowledge it before deployment. Then, the DDoS attack traffic will be diverted to the cleaning device for scrubbing. In this diversion mode, the destination IP address of packets matching the diversion policy is inevitably an IP address under DDoS attack. This mode avoids DDoS protection on unrelated traffic, and enhances the device processing efficiency.

Figure 20 Schematic diagram of BGP-based diversion

 

1.     The management center automatically generates diversion routes (also called guard routes) based on attack information and deploys them to the cleaning device.

2.     The cleaning device uses BGP to advertise the diversion routes to the core device.

3.     The core device forwards the DDoS attack traffic to the cleaning device based on the diversion routes.

Static route injection

Static route injection is a static injection method. In this method, the PBR policy applied to the external-facing interface of the core device will not affect the injection of cleaned traffic. The cleaning device only needs to inject cleaned traffic to the core device through static routing.

Figure 21 Schematic diagram of static route injection

 

Layer 2 injection

Layer 2 injection is a static injection method. The cleaning device injects cleaned traffic back to the protected network through Layer 2 forwarding.

·     You need to obtain the VLAN of each protected network segment, and create VLAN interfaces on the cleaning device for these VLANs for traffic injection. The cleaning device uses the VLAN interfaces to inject cleaned traffic to the protected networks with the matching VLAN IDs.

·     Layer 2 injection is suitable for scenarios where only Layer 2 forwarding devices and no Layer 3 forwarding devices exist between the anti-DDoS system and the protected network.

Figure 22 Schematic diagram of Layer 2 injection

 

PBR-based injection

PBR-based injection is a static injection method. The cleaning device uses static routes to forward cleaned traffic to the core device. The core device uses the PBR policy to forward to a distribution device the traffic that accesses the protected network and is received on the injection interface. Then, the distribution device sends the traffic to the original destination.

·     On both the cleaning device and core device, you must manually configure static routes and PBR with the next hop as an interface address of a downstream distribution device for different protected segments. Therefore, PBR-based injection is suitable for scenarios with fewer segment addresses and fewer downstream distribution devices.

·     If the network topology changes, you must manually adjust the configuration of static routes and PBR. Therefore, PBR-based injection is suitable for a Layer 3 network with a stable topology.

Figure 23 Schematic diagram of PBR-based injection

 

1.     The cleaning device uses static routes to forward cleaned traffic to the core device.

2.     The core device uses the PBR policy to forward to the distribution device the traffic that accesses the protected network and is received on the injection interface.

GRE injection

GRE injection is a static injection method. The cleaning device sends the cleaned traffic directly back to a distribution device through a GRE tunnel. Then, the distribution device forwards traffic to the protected network.

·     Because GRE injection requires you to manually establish a one-to-one GRE tunnel between the cleaning device and each distribution device, GRE injection is suitable for scenarios with fewer distribution devices.

·     If the network topology changes, you must manually adjust the GRE tunnel configuration. Therefore, GRE injection is suitable for a Layer 3 network with a stable topology.

Figure 24 Schematic diagram of GRE injection

 

MPLS LSP injection

MPLS LSP injection is a dynamic injection method. The cleaning device injects cleaned traffic carrying MPLS labels back into the core device. The core device forwards traffic to the distribution devices based on MPLS labels, with higher priority than diversion routes. Then, the distribution devices forward the packets to their original destinations.

·     MPLS LSP injection requires both the core device and distribution devices to support MPLS.

·     You must enable LDP on the interfaces that interconnect the cleaning device, core device, and distribution devices to dynamically establish LSPs.

·     In this method, LSPs are dynamically established, and you do not need to manually configure routes to the protected network segments. Therefore, this method is suitable for scenarios with many distribution devices and dispersed protected network segments.

·     MPLS LSP injection is insensitive to network topology changes and can automatically adapt to these changes. It is highly scalable and easy to maintain, making it suitable for Layer 3 networks with frequently changing network topologies.

Figure 25 Schematic diagram of MPLS LSP injection

 

1.     The distribution device uses BGP to advertises to the cleaning device the routes to the protected networks.

2.     After the cleaning device recurse the routes to the LSPs, the cleaning device forwards the cleaned traffic to the distribution devices through the LSPs.

Typical applications

Overview of typical applications

The H3C anti-DDoS solution offers multiple typical network solutions. You can select an appropriate solution as needed.

Table 9 Typical applications of H3C anti-DDoS

Typical network	Device configuration requirements	Applicable scenarios
Inline deployment mode	·     No detection devices ·     Deploy the cleaning device directly at the egress of the internal network as a gateway ·     As a best practice, deploy the management center. If you do not do that, although DDoS attack defense can still operate, the impacts and effectiveness of the defense will not be visible.	DDoS attacks with small or medium traffic (such as protection for small and medium-sized business networks)
Static route injection in one-arm deployment mode	·     Deploy the detection device, cleaning device, and management center separately. ·     Use PBR to divert traffic that requires enhanced protection without detecting DDoS attacks by using the detection device before diversion.	In scenarios requiring comprehensive, real-time DDoS protection for key protection targets, this method can effectively handle large-traffic DDoS attacks.
Layer 2 injection in one-arm deployment mode	·     Deploy the detection device, cleaning device, and management center separately. ·     You need to obtain the VLAN of each protected network segment, and create VLAN interfaces on the cleaning device for these VLANs for traffic injection.	Use this method in scenarios with large-traffic DDoS attacks, where only Layer 2 forwarding devices and no Layer 3 forwarding devices exist between the anti-DDoS system and the protected network.
PBR-based injection in one-arm deployment mode	·     Deploy the detection device, cleaning device, and management center separately. ·     You must manually configure static routes and PBR policies on the cleaning device and core device for different protected network segments. If the network topology changes, you must manually modify the configurations of static routes and PBR policies.	Use this feature in a Layer 3 network that requires handling large-traffic DDoS attacks, has few protected network segments and downstream distribution device, and has a stable network topology.
GRE injection in one-arm deployment mode	·     Deploy the detection device, cleaning device, and management center separately. ·     You must manually establish one-to-one GRE tunnels between the cleaning device and different distribution devices. If the network topology changes, you must manually modify the GRE tunnel configuration.	Use this method in a Layer 3 network that has large-traffic DDoS attacks, few distribution devices, and a stable network topology.
MPLS LSP injection method in one-arm deployment mode	·     Deploy the detection device, cleaning device, and management center separately. ·     Both the core device and distribution devices must support MPLS. ·     Enable LDP on the interfaces that interconnect the cleaning device, core device, and distribution devices to dynamically establish LSPs.	This method is suitable for a Layer 3 network with large-traffic DDoS attacks, many distribution devices, dispersed protected network segments, and frequently changing topology.

 

Inline deployment mode

As shown in Figure 26, the egress bandwidth of the network where the hosts reside is relatively small (about 1 to 2 Gbps), and the core device at the network egress does not accept the one-arm deployment of other devices. Deploy an abnormal flow cleaning system to protect some key services on the network where hosts reside from DDoS attacks.

Based on the network conditions, deploy the abnormal flow cleaning system as follows:

·     Deploy the cleaning device in inline mode at the egress of the network where hosts reside to provide real-time DDoS protection for bidirectional traffic.

·     Configure protection policies to prevent DDoS attacks on network segments where key services operate.

·     Configure both the uplink and downlink interfaces of the cleaning device to operate in Layer 2 mode without changing the Layer 3 network topology.

Figure 26 Network diagram

 

Static route injection in one-arm deployment mode

As shown in Figure 27, both the core device Switch A and the distribution device Switch B are switches. Deploy an abnormal flow cleaning system to protect some key services on the network where hosts reside from DDoS attacks.

Based on the network conditions, deploy the abnormal flow cleaning system as follows:

·     Deploy the abnormal flow cleaning system in one-arm mode to minimize the risk of network failures.

·     Configure protection policies to prevent DDoS attacks on network segments where key services operate.

·     Configure PBR on the core device to forward to the cleaning device the traffic that accesses the protected network and is received on the external-facing interface.

·     Configure a static route on the cleaning device to inject cleaned traffic back to the core device.

Figure 27 Network diagram

 

Layer 2 injection method in one-arm deployment mode

As shown in Figure 28, both the core device Switch A and the distribution device Switch B are switches, and the downstream network is a Layer 2 network. Deploy an abnormal flow cleaning system to protect some key services on the network where hosts reside from DDoS attacks.

Based on the network conditions, deploy the abnormal flow cleaning system as follows:

·     Deploy the abnormal flow cleaning system in one-arm mode to minimize the risk of network failures.

·     Configure protection policies to prevent DDoS attacks on network segments where key services operate.

·     Configure BGP on both the core device and the cleaning device, and make sure the core device has diversion routes with the next hop as the cleaning device.

·     You need to obtain the VLAN of each protected network segment, and create VLAN interfaces on the cleaning device for these VLANs for traffic injection. The cleaning device uses the VLAN interfaces to inject cleaned traffic to the protected networks with the matching VLAN IDs.

Figure 28 Network diagram

 

PBR-based injection in one-arm deployment mode

As shown in Figure 29, Router A is the core device, and Router B is the distribution device. The downstream network is a Layer 3 network. The Layer 3 network has few distribution devices and the protected service address ranges are centralized. Deploy an abnormal flow cleaning system to protect some key services on the network where hosts reside from DDoS attacks.

Based on the network conditions, deploy the abnormal flow cleaning system as follows:

·     Deploy the abnormal flow cleaning system in one-arm mode to minimize the risk of network failures.

·     Configure protection policies to prevent DDoS attacks on network segments where key services operate.

·     Configure BGP on both the core device and the cleaning device, and make sure the core device has diversion routes with the next hop as the cleaning device.

·     You must manually configure static routes and PBR policies for different protected network segments on the cleaning device and core device to inject cleaned traffic to the distribution devices.

Figure 29 Network diagram

 

GRE injection in one-arm deployment mode

As shown in Figure 30, Router A is the core device, and Router B is the distribution device. The downstream network is a Layer 3 network with few distribution devices. The devices on the network do not support MPLS. Deploy an abnormal flow cleaning system to protect some key services on the network where hosts reside from DDoS attacks.

Based on the network conditions, deploy the abnormal flow cleaning system as follows:

·     Deploy the abnormal flow cleaning system in one-arm mode to minimize the risk of network failures.

·     Configure protection policies to prevent DDoS attacks on network segments where key services operate.

·     Configure BGP on both the core device and the cleaning device, and make sure the core device has diversion routes with the next hop as the cleaning device.

·     You must manually establish one-to-one GRE tunnels between the cleaning device and the distribution devices to inject cleaned traffic to the distribution devices.

Figure 30 Network diagram

 

MPLS LSP injection in one-arm deployment mode

As shown in Figure 31, Router A is the core device, and Router B is the distribution device. The downstream network is a Layer 3 network with many distribution devices and dispersed protected network segments. The devices on the network support MPLS. Deploy an abnormal flow cleaning system to protect some key services on the network where hosts reside from DDoS attacks.

Based on the network conditions, deploy the abnormal flow cleaning system as follows:

·     Deploy the abnormal flow cleaning system in one-arm mode to minimize the risk of network failures.

·     Configure protection policies to prevent DDoS attacks on network segments where key services operate.

·     Configure BGP on both the core device and the cleaning device, and make sure the core device has diversion routes with the next hop as the cleaning device.

·     Enable LDP on the interfaces that interconnect the cleaning device, core device, and distribution devices to dynamically establish LSPs. Then, the cleaned traffic can be injected to the distribution devices.

Figure 31 Network diagram