This help contains the following topics:

·     Introduction

¡     Attack defense policy

¡     Client verification

¡     Blacklist

¡     Whitelist

·     Restrictions and guidelines

·     Configure attack defense and prevention

¡     Configure an attack defense policy

¡     Configure protected IP addresses

¡     Configure the blacklist

¡     Configure the whitelist

¡     Configure security zone settings

Introduction

As an important network security feature, attack defense enables the device to detect attacks by inspecting arriving packets and to take prevention actions.

Attack defense policy

An attack defense policy contains a set of attack detection and prevention action configuration. Prevention actions include logging, packet dropping, blacklisting, and client verification. The device supports the following attack defense policies:

·     Scanning attack defense policy.

·     Flood attack defense policy.

·     Single-attack defense policy.

Apply an attack defense policy to a security zone to inspect packet received in the security zone.

Scanning attack detection and prevention

Scanning is a preintrusion activity used to prepare for intrusion into a network. The scanning allows the attacker to find a way into the target network and to disguise the attacker's identity.

Attackers use scanning tools to probe a network, find vulnerable hosts, and discover services that are running on the hosts. Attackers can use the information to launch attacks.

The device can detect and prevent the IP sweep (address scanning) and port scanning attacks. If an attacker performs port scanning from multiple hosts to the target host, distributed port scan attacks occur.

Apply a scanning attack defense policy to the security zone that is connected to the external network. Scanning attack detection inspects the incoming packet rate of connections to the target system. If a source initiates connections at a rate equal to or exceeding the pre-defined threshold, the device can take the following actions:

·     Output logs.

·     Drop subsequent packets from the IP address of the attacker.

·     Add the attacker's IP address to the IP blacklist.

You can specify a detection sensitivity level for a scanning attack defense policy. The threshold values and detection periods are fixed for detection sensitivity levels high, medium, and low. To customize the threshold and the detection period, set the detection level to User-defined.

If the prevention action is adding attacker's IP address to the IP blacklist, you must enable the blacklist feature on the security zone to which the scanning attack defense policy is applied.

Flood attack detection and prevention

An attacker launches a flood attack by sending a large number of forged requests to the victim in a short period of time. The victim is too busy responding to these forged requests to provide services for legal users, and a DoS attack occurs.

Apply a flood attack defense policy to the security zone that is connected to the external network to protect internal servers. Flood attack detection monitors the rate at which connections are initiated to the internal servers. With flood attack detection enabled, the device is in attack detection state. When the packet sending rate to an IP address reaches or exceeds the threshold, the device enters prevention state and takes the specified actions. When the rate is below the silence threshold (three-fourths of the threshold), the device returns to the attack detection state.

You can configure flood attack detection and prevention for a specific IP address. For non-specific IP addresses, the device uses the global attack prevention settings.

An appropriate threshold can effectively prevent attacks. The system provides the threshold learning feature to automatically learn the global threshold. This feature allows the device to learn the global threshold based on the traffic flows in the network as follows:

1.     Monitors the packet sending rate in the network.

2.     Calculates the global threshold based on the peak rate learned within the threshold learning duration.

The threshold learning feature includes the following modes:

·     One-time learning—The device performs threshold learning only once.

·     Periodic learning—The device performs threshold learning at intervals. The most recent learned threshold always takes effect.

The threshold learning learns the threshold of all types of flood attacks. You can enable auto application of the learned threshold.

If the network traffic statistics is not known yet, use the default settings of the flood attack prevention parameters first, and then adjust the threshold based on the threshold learning result.

Single-packet attack detection and prevention

Single-packet attacks are also known as malformed packet attacks. An attacker typically launches single-packet attacks by using the following methods:

·     An attacker sends defective packets to a device, which causes the device to malfunction or crash.

·     An attacker sends normal packets to a device, which interrupts connections or probes network topologies.

·     An attacker sends a large number of forged packets to a target device, which consumes network bandwidth and causes denial of service (DoS).

Apply the single-packet attack defense policy to the security zone that is connected to the external network. Single-packet attack detection inspects incoming packets based on the packet signature. If an attack packet is detected, the device can take the following actions:

·     Output logs.

·     Drop attack packets.

The device supports detecting both well-known single-packet attacks and attack packets with user-defined signatures.

Attack detection exemption

The attack defense policy uses the ACL to identify exempted packets. The policy does not check the packets permitted by the ACL. You can configure the ACL to identify packets from trusted servers. The exemption feature reduces the false alarm rate and improves packet processing efficiency.

If an ACL is used for attack detection exemption, only the following match criteria in the ACL permit rules take effect:

·     Source IP address.

·     Destination IP address.

·     Source port.

·     Destination port.

·     Protocol.

·     VRF.

·     Non-first fragments.

Client verification

The client verification feature protects servers against TCP, DNS, DNS reply, HTTP, and SIP flood attacks. The device enabled with client verification is located between the client and the protected server, and verifies the connection initiated by the client.

IP addresses protected by client verification can be manually added or automatically learned:

·     You can manually add protected IP addresses. The device performs client verification when it receives the first packet destined for a protected IP address.

·     The client verification can automatically add victims' IP addresses to the protected IP list when collaborating with flood attack detection. Make sure client verification is specified as the flood attack prevention action.

The device directly forwards packets from trusted IP addresses.

TCP client verification

The TCP client verification feature protects TCP servers against the following flood attacks:

·     SYN.

·     ACK.

·     SYN-ACK.

·     FIN.

·     RST.

TCP client verification can operate in the following modes:

·     Safe reset—Enables unidirectional TCP proxy for packets only from TCP connection initiators. The unidirectional TCP proxy is sufficient for most scenarios because attacks are often seen from clients.

·     SYN cookie—Enables bidirectional TCP proxy for TCP clients and servers.

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 client verification, the TCP connection establishment takes more time than normal TCP connection establishment.

SYN cookie mode requires two TCP connections to be established as follows:

1.     After receiving a SYN packet from a client to a protected server, the TCP proxy sends back a SYN ACK packet with the window size 0. If the client responds with an ACK packet, the client is verified as legitimate. The proxy device establishes a TCP connection with the client.

2.     The TCP proxy device establishes a connection with the server through a new three-way handshake that has a different window size. This connection uses a different sequence number from the connection between the client and proxy device.

In SYN cookie mode, the TCP proxy is the server proxy that communicates with clients and the client proxy that communicates with server. Choose this mode when the following requirements are met:

·     The TCP proxy device is deployed on the key path that passes through the ingress and egress of the protected server.

·     All packets exchanged between clients and server pass through the TCP proxy device.

DNS client verification

The DNS client verification feature protects DNS servers against DNS flood attacks. It is configured on the device where packets from the DNS clients to the DNS servers pass through. The device with DNS client verification feature configured is called a DNS client authenticator.

The DNS client 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.

The DNS client verification feature requires that DNS clients comply with the TCP/IP protocol suite. The DNS client authenticator will deny a legitimate client to access the server if the client does not comply with the TCP protocol suite. With client verification, the DNS connection establishment takes more time than normal TCP connection establishment.

DNS reply source verification

The DNS reply source verification feature protects DNS clients from DNS reply flood attacks. The device with DNS reply source verification feature configured is called a DNS reply authenticator.

The DNS reply source 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.

HTTP client verification

The HTTP client verification feature protects HTTP servers against HTTP flood attacks. It is configured on the device where HTTP GET or POST request packets from the HTTP clients to the HTTP servers pass through. A device with HTTP client verification feature configured is called an HTTP client authenticator.

The HTTP client authenticator uses HTTP GET 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 client verification in SYN cookie mode. If the client passes the TCP client verification, a TCP connection is established between the client and the authenticator.

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

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

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

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

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 client verification in SYN Cookie mode. If the client passes the TCP client 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.

SIP client verification

The SIP client verification feature protects SIP servers against SIP flood attacks.

The device with SIP client verification feature configured is called a SIP client authenticator. The SIP client verification process is 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 a reply to the SIP client authenticator.

3.     When receiving the reply, the SIP client authenticator verifies the branch value in the reply. If the branch value in the reply packet is the same as the branch value in the OPTIONS packets that the SIP client authenticator has sent, the client passes verification. The authenticator will forward subsequent packets from the client.

A legitimate SIP client might not pass the client verification if packets sent by the SIP client do not contain complete header information due to fragmentation.

Blacklist

The blacklist feature is an attack prevention method that filters packets by IP addresses in blacklist entries. Compared with ACL-based packet filtering, IP blacklist filtering is simpler and provides effective screening at a faster speed.

Blacklist entries can be manually added or dynamically learned:

·     You can manually add an IP blacklist entry. These entries do not age out by default. You can set an aging time for each entry.

·     The device can automatically add IP blacklist entries when collaborating with scanning attack detection. Each dynamically learned IP blacklist entry has an aging time, which is user configurable. Make sure adding the attacker's IP address to the IP blacklist is specified as the scanning attack prevention action.

Whitelist

This feature exempts packets sourced from the subnets specified in the whitelisted address object group from attack detection. Packets from the whitelisted address are directly forwarded whether they are attack packets or not.

The whitelist can contain only one address object group. The address object group can only be manually added to or deleted from the whitelist.

Restrictions and guidelines

·     If a device has multiple service cards, the threshold value in a flood attack policy is card specific. The global threshold of the device is the product of multiplying the threshold value by the service card quantity.

·     Blacklist entries takes effect only when the blacklist feature is enabled in the security zone.

·     The client verification action in the attack defense policy takes effect only when the client verification is enabled in the security zone.

·     Adjust the threshold according to the application scenarios. If the number of packets sent to a protected server is normally large, set a large threshold. A small threshold might affect the server services. For a network that is unstable or susceptible to attacks, set a small threshold.

·     If the specified ACL does not exist or does not contain a rule, attack detection exemption does not take effect.

·     If an ACL is used for attack detection exemption, only the following match criteria in the ACL permit rules take effect:

¡     Source IP address.

¡     Destination IP address.

¡     Source port.

¡     Destination port.

¡     Protocol.

¡     VRF.

¡     Non-first fragments.

·     The threshold learning feature learns the thresholds of the following attacks only on the default ports:

¡     DNS flood attacks.

¡     DNS reply flood attacks.

¡     SIP flood attacks.

¡     HTTP flood attacks.

·     Once you set the source IP-based threshold to 0 for a flood attack type, the device does not apply the source IP-based learning result to this attack type even if learning result automatic application is enabled. You cannot manually apply the source IP-based learning result to this attack type, neither. The same restriction applies when you set the destination IP-based threshold to 0.

Configure attack defense and prevention

Figure 1 Attack defense and prevention configuration procedure

 

Configure an attack defense policy

Before you configure attack defense and prevention, create an attack defense policy. Specify the attack detection criteria and prevention actions in the policy based on the network security requirements.

Procedure

1.     Click the Policies tab.

2.     In the navigation pane, select Attack Defense > Attack Defense Policies.

3.     Click Create.

4.     Create an attack defense policy.

Table 1 Configuration items for an attack defense policy

Item	Description
Policy name	Name of an attack defense policy. Valid characters include letters, digits, underscores (_), and hyphens (-).
Apply to	Select a security zone to which the attack defense policy is applied. A security zone can have only one attack defense policy applied. An attack defense policy can be applied to multiple security zones. The list includes the default security zone and security zones that have been configured on the Network > Security Zones page.

 

Table 2 Configuration items for a scanning attack defense policy

Item	Description
Detection sensitivity	Scanning attack detection level: ·     Close—Disables the scanning attack defense. ·     Low—Specifies the low level. This level provides basic scanning attack detection and has a low false alarm rate, but many scanning attacks cannot be detected. ·     Medium—Specifies the medium level. Compared with the high and low levels, this level has medium false alarm rate and attack detection accuracy. ·     High—Specifies the high level. This level can detect most of the scanning attacks, but has a high false alarm rate. Some packets from active hosts might be considered as attack packets. ·     User-defined—Specifies the user-defined level. You can set a threshold for scanning attack prevention. Configure the following parameters as needed: ·     Enable port scan attack prevention—This feature is enabled when Detection sensitivity is set to Low, Medium, or High. You can determine whether to enable this feature when Detection sensitivity is set to User-defined. ·     Threshold (packets)—Threshold that triggers port scanning attack prevention. The value is 100000 for the low detection sensitivity level, 40000 for the medium detection sensitivity level, and 5000 for the high detection sensitivity level. You can specify a threshold when Detection sensitivity is set to User-defined. This parameter is not displayed when Detection sensitivity is disabled. ·     Enable address scan attack prevention—This feature is enabled when Detection sensitivity is set to Low, Medium, or High. You can determine whether to enable this feature when Detection sensitivity is set to User-defined. ·     Threshold (packets)—Threshold that triggers address scanning attack prevention. The value is 100000 for the low detection sensitivity level, 40000 for the medium detection sensitivity level, and 5000 for the high detection sensitivity level. You can specify a threshold when Detection sensitivity is set to User-defined. This parameter is not displayed when Detection sensitivity is disabled. ·     Detection period—Scanning attack detection cycle. The detection period is 10 seconds when Detection sensitivity is set to Low, Medium, or High. You can specify a detection cycle when Detection sensitivity is set to User-defined. This parameter is not displayed when Detection sensitivity is disabled.
Actions	Prevention actions against scanning attacks. ·     Generate logs. ·     Drop attack packets. ·     Add attackers' IP addresses to blacklist. ·     Age out after n minutes—Aging time for the dynamically added blacklist entries. This parameter is available only when Add attackers' IP addresses to blacklist is selected. Prevention actions are not available when Detection sensitivity is disabled.

 

Table 3 Configuration items for flood attack defense global settings

Item	Description
Attack type	Flood attack types: ·     ACK—Specifies the ACK flood attack type. An ACK packet is a TCP packet only with the ACK flag set. Upon receiving an ACK packet from a client, the server must search half-open connections for a match. An ACK flood attacker sends a large number of ACK packets to the server. This causes the server to be busy searching for half-open connections, and the server is unable to process packets for normal services. ·     DNS—Specifies the DNS flood attack type. The DNS server processes and replies all DNS queries that it receives. A DNS flood attacker sends a large number of forged DNS queries. This attack consumes the bandwidth and resources of the DNS server, which prevents the server from processing and replying legal DNS queries. ·     DNS reply—Specifies the DNS reply flood attack type. The DNS server processes all DNS replies that it receives. A DNS reply flood attacker sends a large number of forged DNS replies. This attack consumes the bandwidth and resources of the DNS server, which prevents the server from processing legal DNS replies. ·     FIN—Specifies the FIN flood attack type. FIN packets are used to shut down TCP connections. A FIN flood attacker sends a large number of forged FIN packets to a server. The victim might shut down correct connections, or be unable to provide services because it is busy searching for matching connections. ·     HTTP—Specifies the HTTP flood attack type. 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 amount of system resources. An HTTP flood attacker sends a large number of HTTP GET or POST requests that exceed the processing capacity of the HTTP server, which causes the server to crash. ·     ICMP—Specifies the ICMP flood attack type. An ICMP flood attacker sends ICMP request packets, such as ping packets, to a host at a fast rate. Because the target host is busy replying to these requests, it is unable to provide services. ·     ICMPv6—Specifies the ICMPv6 flood attack type. An ICMPv6 flood attacker sends ICMPv6 request packets, such as ping packets, to a host at a fast rate. Because the target host is busy replying to these requests, it is unable to provide services. ·     RST—Specifies the RST flood attack type. RST packets are used to abort TCP connections when TCP connection errors occur. An RST flood attacker sends a large number of forged RST packets to a server. The victim might shut down correct connections, or be unable to provide services because it is busy searching for matching connections. ·     SIP—Specifies the SIP flood attack type. After receiving a SIP INVITE packet from a SIP client, the server must allocate resources to establish and trace the session with the SIP client. A SIP flood attacker sends a large number of fake INVITE request packets at a rate exceeding the processing capacity of the SIP server, which causes the server to crash. ·     SYN—Specifies the SYN flood attack type. A SYN flood attacker exploits the TCP three-way handshake characteristics and makes the victim unresponsive to legal users. An attacker sends a large number of SYN packets with forged source addresses to a server. This causes the server to open a large number of half-open connections and respond to the requests. However, the server will never receive the expected ACK packets. The server is unable to accept new incoming connection requests because all of its resources are bound to half-open connections. ·     SYN-ACK—Specifies the SYN-ACK flood attack type. Upon receiving a SYN-ACK packet, the server must search for the matching SYN packet it has sent. A SYN-ACK flood attacker sends a large number of SYN-ACK packets to the server. This causes the server to be busy searching for SYN packets, and the server is unable to process packets for normal services. ·     UDP—Specifies the UDP flood attack type. A UDP flood attacker sends UDP packets to a host at a fast rate. These packets consume a large amount of the target host's bandwidth, so the host cannot provide other services.
Threshold(pps)	Global threshold value in the range of 1 to 1000000. The default value is 40000 for ACK flood attack detection and 10000 for other types of flood attack detection. With global flood attack detection configured, the device is in attack detection state. When the sending rate of packets to an IP address reaches the threshold, the device enters prevention state and takes the specified actions. The global threshold applies to global flood attack detection. Adjust the threshold according to the application scenarios. If the number of packets sent to a protected server is normally large, set a large threshold. A small threshold might affect the server services. For a network that is unstable or susceptible to attacks, set a small threshold.
Logging	Enable logging for flood attack events. Log messages are sent to the log system.
Detect All IPs	Enable global flood attack detection.
Client verification	Enable client verification. The device automatically adds the victim IP addresses to the protected IP list, and provides proxy services for protected IP addresses.
Packet drop	Use packet dropping as the prevention action. The device drops subsequent attack packets destined for the victim IP addresses.
Target ports	A comma-separated list of up to 32 port number items, for example, 1-10,80. Each item specifies a port by its port number or a range of ports in the form of start-port-number to end-port-number. The end-port-number cannot be smaller than the start-port-number. The port number is in the range of 1 to 65535. The device performs flood attack detection only on packets received from the target ports. The target port setting applies to global flood attack detection and IP address-specific flood attack detection with no port specified. If IP address-specific flood attack detection is configured with specific ports, the device detects flood attacks on these ports for the specified IP address. This parameter is available only for DNS, DNS reply, HTTP, and SIP flood attack types.
Set threshold learning	Configure threshold learning parameters as shown in Table 4. Before configuring the threshold learning feature on the Edit page, you must complete the configuration of the attack defense policy first.
Apply learned threshold	Use the learned threshold as the threshold for flood attack prevention. This setting takes effect only on attack types that are enabled with Detect All IPs and have the threshold learning result.

 

Table 4 Configuration items for threshold learning

Item	Description
Threshold learning	As a best practice, enable threshold learning to provide a reference for threshold setting.
Learning duration	Duration of threshold learning. The system calculates the thresholds for different attacks based on the peak rate learned within the threshold learning duration.
Learning mode	The following modes are available: ·     One-time learning—The device performs threshold learning only once. ·     Periodic learning—The device performs threshold learning at intervals.
Auto apply	Automatically apply the most recent threshold that the device has learned. This parameter takes effect only on attack types that are enabled with Detect All IPs and have the threshold learning result.
Tolerance	Threshold learning tolerance value that increases the learned threshold to a larger value before threshold application. This mechanism enables the threshold learning feature to promptly respond to traffic fluctuation.

 

To add protected IP addresses against flood attacks, click Create on the IP-Specific Flood Attack Defense page.

Table 5 Configuration items for IP-specific flood attack defense

Item	Description
IP version	Select an IP version, IPv4 or IPv6.
Attack type	For more information, see Table 3.
VRF	VRF to which the protected IP address belongs. You can select an existing VRF or create a new one. The newly created VRF will be displayed on the Network > VRF page.
IP address	Enter an IP address to be protected. The protected IPv4 address cannot be 255.255.255.255 or 0.0.0.0.
Threshold (pps)	Set the threshold that triggers flood attack prevention. The global threshold setting applies if you do not set the threshold for the protected IP address.
Target ports	A comma-separated list of 32 port number items, for example, 1-10,80. Each item specifies a port by its port number or a range of ports in the form of start-port-number to end-port-number. The end-port-number cannot be smaller than the start-port-number. The port number is in the range of 1 to 65535. This parameter is available only for DNS, DNS reply, HTTP, and SIP attack types.
Global settings	Apply the prevention actions defined in Table 3.
Logging	Enable logging for flood attack events. Log messages are sent to the log system.
Packet drop	Use packet dropping as the prevention action. The device drops subsequent attack packets destined for the victim IP addresses.
Client verification	Enable client verification as the prevention action. The device automatically adds the victim IP addresses to the protected IP list, and provides proxy services for protected IP addresses.

 

Table 6 Configuration items for well-known single packet attack defense

Item	Description
Attack type	Specify a well-known single packet attack type: ·     IP fragment—An attacker sends the victim an IP datagram with an offset smaller than 5, which causes the victim to malfunction or crash. ·     IP impossible—An attacker sends IP packets whose source IP address is the same as the destination IP address, which causes the victim to malfunction. ·     Teardrop—An attacker sends a stream of overlapping fragments. The victim will crash when it tries to reassemble the overlapping fragments. ·     Tiny fragment—An attacker makes the fragment size small enough to force Layer 4 header fields into the second fragment. These fragments can pass the packet filtering because they do not hit any match. ·     IP option abnormal—An attacker sends IP datagrams in which the IP options are abnormal. This attack intends to probe the network topology. The target system will break down if it is incapable of processing error packets. ·     Smurf—An attacker broadcasts an ICMP echo request to target networks. These requests contain the victim's IP address as the source IP address. Every receiver on the target networks will send an ICMP echo reply to the victim. The victim will be flooded with replies, and will be unable to provide services. Network congestion might occur. ·     Traceroute—An attacker uses traceroute tools to probe the topology of the victim network. ·     Ping of death—An attacker sends the victim an ICMP echo request larger than 65535 bytes that violates the IP protocol. When the victim reassembles the packet, a buffer overflow can occur, which causes a system crash. ·     Large ICMP—An attacker sends large ICMP packets to crash the victim. Large ICMP packets can cause memory allocation error and crash the protocol stack. ·     Large ICMPv6—An attacker sends large ICMPv6 packets to crash the victim. Large ICMPv6 packets can cause memory allocation error and crash the protocol stack. ·     TCP invalid flags—An attacker sends packets with invalid TCP flags to the target host, which can cause the target system to crash. ·     TCP null flag—An attacker sends TCP packet with no flags to the target host, which can cause the target system to crash. ·     TCP all flags—An attacker sends TCP packet with all flags set to the target host, which can cause the target system to crash. ·     TCP SYN-FIN—An attacker sends TCP packet with both SYN and FIN flags set to the target host, which can cause the target system to crash. ·     TCP FIN only flag—An attacker sends TCP packet with only the FIN flag set to the target host, which can cause the target system to crash. ·     TCP Land—An attacker sends the target a large number of TCP SYN packets with the source and destination IP addresses same as the IP of the target. The half connection resources on the target will run out and the target cannot operate correctly. ·     WinNuke—An attacker sends Out-Of-Band (OOB) data to the TCP port 139 (NetBIOS) on the victim that runs Windows system. The malicious packets contain an illegal Urgent Pointer, which causes the victim's operating system to crash. ·     UDP Bomb—An attacker sends a malformed UDP packet. The length value in the IP header is larger than the IP header length plus the length value in the UDP header. When the target system processes the packet, a buffer overflow can occur, which causes a system crash. ·     UDP snork—An attacker sends a UDP packet with destination port 135 (the Microsoft location service) and source port 135, 7, or 19. This attack causes an NT system to exhaust its CPU. ·     UDP fraggle—An attacker sends a large number of packets with source UDP port 7 and destination UDP port 19 (UDP chargen port) to a network. These packets use the victim's IP address as the source IP address. Replies will flood the victim, resulting in DoS. ·     IPv6 ext header abnormal—An attacker sends IPv6 packets with disordered or repeated IPv6 extension headers to the target. ·     IPv6 ext header exceed—An attacker sends IPv6 packets with IPv6 extension headers exceeding the upper limit to the target. In abnormal IPv6 extension header and IPv6 extension header exceeded attack detection, the device examines the ESP header and headers before it. Headers after the ESP header are not examined.
Logging	Enable logging for the single-packet attack events. Log messages are sent to the log system.
Packet drop	Use packet dropping as the prevention action. The device drops subsequent attack packets destined for the victim IP addresses.
Threshold (bytes)	Maximum length of safe ICMP or ICMPv6 packets, in bytes. ·     28 to 65534 for ICMP packets. ·     48 to 65534 for ICMPv6 packets.

 

To create a single-packet attack defense policy to detect packets with user-defined signatures, access the Custom Single-Packet Attack Defense page, and then click Create.

Table 7 Configuration items for a single-packet attack defense policy with user-defined packet signatures

Item	Description
Signature	Packet signatures: ·     IP option—Specifies attack packets with a specific IP option. ·     ICMP—Specifies ICMP attack packets. ·     ICMPv6—Specifies ICMPv6 attack packets ·     IPv6 extension header—Specifies attack packets with IPv6 extension headers.
Value	Signature value in the range of 0 to 255. This value indicates the IP option code, or the type value in  ICMP packets, ICMPv6 packets, or IPv6 extension headers.
Logging	Enable logging for the single-packet attack events. Log messages are sent to the log system.
Packet drop	Use packet dropping as the prevention action. The device drops subsequent attack packets destined for the victim IP addresses.

 

Table 8 Attack detection exemption configuration items

Item	Description
IPv4 exemption	IPv4 ACL for attack detection exemption. You can select an existing IPv4 ACL or create a new IPv4 ACL. The created ACL will be displayed on the Objects > ACLs > IPv4 ACLs page. If the specified ACL does not exist or does not contain a rule, attack detection exemption does not take effect.
IPv6 exemption	IPv6 ACL for attack detection exemption. You can select an existing IPv6 ACL or create a new IPv6 ACL. The created ACL will be displayed on the Objects > ACLs > IPv6 ACLs page. If the specified ACL does not exist or does not contain a rule, attack detection exemption does not take effect.

 

5.     Click OK.

Configure protected IP addresses

IP addresses protected by client verification can be manually added or automatically learned. The device can automatically add victims' IP addresses to the protected IP list when client verification collaborates with flood attack detection. The device directly forwards packets from trusted IP addresses. Make sure client verification is specified as the flood attack prevention action.

The Protected IP Addresses page displays protected IP addresses manually added and automatically learned.

Procedure

1.     Click the Policies tab.

2.     In the navigation pane, select Attack Defense > Protected IP Addresses.

3.     Click Create.

4.     Configure protected IP addresses.

Table 9 Configuration items for protected IP addresses

Item	Description
Protocol	Protocol type for client verification: ·     TCP—Specifies TCP client verification. ·     DNS—Specifies DNS client verification. ·     DNS reply—Specifies DNS reply source verification. ·     HTTP—Specifies HTTP client verification. ·     SIP—Specifies SIP client verification.
VRF	VRF to which the protected IP address belongs. You can select an existing VRF or create a new one. The newly created VRF will be displayed on the Network > VRF page.
IP version	Select an IP version, IPv4 or IPv6.
IP address	Protected IP address. All connection requests destined for this address are verified by the client verification feature. The attacker sends TCP connection requests, DNS queries, DNS replies, HTTP GET requests, HTTP POST requests, or SIP UDP INVITE requests to the protected IP.
Port number	Number of a protected port. By default, DNS client verification protects port 53, HTTP client verification protects port 80, SIP client verification protects port 5060, and TCP client verification protects all ports.

 

5.     Click OK.

Configure the blacklist

The blacklist feature is an attack prevention method that filters packets by IP addresses in blacklist entries.

Blacklist entries can be manually added or dynamically learned. The device can automatically add IP blacklist entries when the blacklist feature collaborates with scanning attack detection. Make sure adding the attacker's IP address to the IP blacklist is specified as the scanning attack prevention action. Each dynamically learned IP blacklist entry has an aging time, which is configured on the Policies > Attack Defense >Attack Defense Policies > Scanning Attack Defense page.

Procedure

1.     Click the Policies tab.

2.     In the navigation pane, select Attack Defense > Blacklist.

3.     Click Create.

4.     Add a blacklist entry.

Table 10 Blacklist configuration items

Item	Description
VRF	VRF to which the blacklist belongs. You can select an existing VRF or create a new one. The newly created VRF will be displayed on the Network > VRF page.
IP version	Select an IP version, IPv4 or IPv6.
Match field	Packet field to compare with the criterion: ·     Source IP address. ·     Destination IP address.
IP address	IP address in the blacklist entry. Packets sourced from or destined to the IP address will be dropped.
DS-Lite tunnel peer address	IPv6 address of the B4 element of the DS-Lite tunnel that transmits packets from the blacklisted IPv4 address. This parameter is available when IPv4 is selected for IP version, and Source IP is selected for the match field.
Aging time (sec)	Remaining aging time of the blacklist entry. If you do not set the aging time, the blacklist entry never ages out. You must delete it manually.

 

5.     Click OK.

Configure the whitelist

The whitelist feature exempts packets sourced from the IP addresses specified in the whitelisted address object group from attack detection.

An address object group can only be manually added to or deleted from the whitelist. To configure an address object group, access the Objects > Object Groups page.

Procedure

1.     Click the Policies tab.

2.     In the navigation pane, select Attack Defense > Whitelist.

3.     Click Create.

4.     Add an address object group to the whitelist.

Table 11 Whitelist configuration items

Item	Description
Object group type	Select an IP version, IPv4 or IPv6.
Object group name	You can select an existing address object group or create a new one. The newly created address object group will be displayed on the Objects > Object Groups page.

 

5.     Click OK.

Configure security zone settings

The client verification configuration includes adding protected IP addresses and enabling client verification on security zones.

The blacklist configuration includes enabling the blacklist feature and adding blacklist entries. The blacklist feature can be globally enabled or on a per security zone basis. If the blacklist feature is globally enabled, all security zones are enabled with the blacklist feature. To enable the global blacklist feature, access the Policies > Attack Defense > Blacklist page.

The whitelist configuration includes enabling the whitelist feature and adding whitelist entries. The whitelist feature can be globally enabled or on a per security zone basis. If the whitelist feature is globally enabled, all security zones are enabled with the whitelist feature. To enable the global whitelist feature, access the Policies > Attack Defense > Whitelist page.

Procedure

1.     Click the Policies tab.

2.     In the navigation pane, select Attack Defense > Security Zone Settings.

3.     Enable the client verification, blacklist, or whitelist feature on a security zone.

Table 12 Security zone configuration items

Item	Description
Security zone	Select a security zone. You can create a new security zone on the Network > Security Zones page.
TCP verification	TCP client verification setting on the a security zone: ·     Disable—Disables TCP client verification. ·     SYN Cookie—Enables bidirectional TCP proxy for TCP client verification. ·     Safe Reset—Enables unidirectional TCP proxy for TCP client verification.
DNS verification	Enable or disable DNS client verification on a security zone.
DNS reply source verification	Enable or disable DNS reply source verification on a security zone.
HTTP verification	Enable or disable HTTP client verification on a security zone.
SIP verification	Enable or disable SIP client verification on a security zone.
Blacklist	Enable or disable the blacklist feature on a security zone.
Whitelist	Enable or disable the whitelist feature on a security zone.

 

4.     Click Apply.