Login
- Table of Contents
-
- 11-Security Configuration Guide
- 00-Preface
- 01-AAA configuration
- 02-Portal configuration
- 03-User profile configuration
- 04-Password control configuration
- 05-Keychain configuration
- 06-Public key management
- 07-PKI configuration
- 08-IPsec configuration
- 09-Group domain VPN configuration
- 10-SSH configuration
- 11-SSL configuration
- 12-SSL VPN configuration
- 13-ASPF configuration
- 14-APR configuration
- 15-Session management
- 16-Connection limit configuration
- 17-Object group configuration
- 18-Object policy configuration
- 19-Attack detection and prevention configuration
- 20-ARP attack protection configuration
- 21-ND attack defense configuration
- 22-uRPF configuration
- 23-Crypto engine configuration
- 24-FIPS configuration
- 25-SMA configuration
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 19-Attack detection and prevention configuration | 346.74 KB |
Contents
Configuring attack detection and prevention
Attacks that the device can prevent
Address object group whitelist
Attack detection and prevention configuration task list
Configuring an attack defense policy
Creating an attack defense policy
Configuring a single-packet attack defense policy
Configuring a scanning attack defense policy
Configuring a flood attack defense policy
Configuring attack detection exemption
Applying an attack defense policy to an interface
Applying an attack defense policy to the device
Applying an attack defense policy to a security zone
Enabling log non-aggregation for single-packet attack events
Configuring TCP fragment attack prevention
Enabling the top attack statistics ranking feature
Configuring TCP client verification
Configuring DNS client verification
Configuring HTTP client verification
Configuring the address object group whitelist
Displaying and maintaining attack detection and prevention
Attack detection and prevention configuration examples
Address object group whitelist configuration example
Interface-based TCP client verification configuration example
Security zone-based TCP client verification configuration example
Interface-based DNS client verification configuration example
Security zone-based DNS client verification configuration example
Interface-based HTTP client verification configuration example
Security zone-based HTTP client verification configuration example
Configuring attack detection and prevention
Overview
Attack detection and prevention enables a device to detect attacks by inspecting arriving packets, and to take prevention actions to protect a private network. Prevention actions include logging, packet dropping, and client verification.
Attacks that the device can prevent
This section describes the attacks that the device can detect and prevent.
Single-packet attacks
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).
Table 1 lists the single-packet attack types that the device can detect and prevent.
Table 1 Types of single-packet attacks
|
Single-packet attack |
Description |
|
ICMP redirect |
An attacker sends ICMP redirect messages to modify the victim's routing table. The victim cannot forward packets correctly. |
|
ICMP destination unreachable |
An attacker sends ICMP destination unreachable messages to cut off the connections between the victim and its destinations. |
|
ICMP type |
A receiver responds to an ICMP packet according to its type. An attacker sends forged ICMP packets of a specific type to affect the packet processing of the victim. |
|
ICMPv6 type |
A receiver responds to an ICMPv6 packet according to its type. An attacker sends forged ICMPv6 packets of specific types to affect the packet processing of the victim. |
|
Land |
An attacker sends the victim a large number of TCP SYN packets, which contain the victim's IP address as the source and destination IP addresses. This attack exhausts the half-open connection resources on the victim, and locks the victim's system. |
|
Large ICMP packet |
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 packet |
An attacker sends large ICMPv6 packets to crash the victim. Large ICMPv6 packets can cause memory allocation error and crash the protocol stack. |
|
IP options |
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. |
|
IP fragment |
An attacker sends the victim an IP datagram with an offset smaller than or equal to 5, which causes the victim to malfunction or crash. |
|
IP impossible packet |
An attacker sends IP packets whose source IP address is the same as the destination IP address, which causes the victim to malfunction. |
|
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. |
|
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. |
|
TCP flag |
An attacker sends packets with defective TCP flags to probe the operating system of the target host. Different operating systems process unconventional TCP flags differently. The target system will break down if it processes this type of packets incorrectly. |
|
Traceroute |
An attacker uses traceroute tools to probe the topology of the victim network. |
|
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 chargen packets with source UDP port 7 and destination UDP port 19 to a network. These packets use the victim's IP address as the source IP address. Replies will flood the victim, resulting in DoS. |
|
Teardrop |
An attacker sends a stream of overlapping fragments. The victim will crash when it tries to reassemble the overlapping fragments. |
|
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. |
Scanning attacks
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 and port scan attacks. If an attacker performs port scanning from multiple hosts to the target host, distributed port scan attacks occur.
Flood attacks
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.
The device can detect and prevent the following types of flood attacks:
· SYN flood attack.
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.
· ACK flood attack.
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.
· SYN-ACK flood attack.
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.
· FIN flood attack.
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.
· RST flood attack.
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.
· DNS flood attack.
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.
· HTTP flood attack.
Upon receiving an HTTP GET 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 requests that exceed the processing capacity of the HTTP server, which causes the server to crash.
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 flood attack.
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.
· UDP flood attack.
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.
TCP fragment attack
An attacker launches TCP fragment attacks by sending attack TCP fragments defined in RFC 1858:
· First fragments in which the TCP header is smaller than 20 bytes.
· Non-first fragments with a fragment offset of 8 bytes (FO=1).
Typically, packet filter detects the source and destination IP addresses, source and destination ports, and transport layer protocol of the first fragment of a TCP packet. If the first fragment passes the detection, all subsequent fragments of the TCP packet are allowed to pass through.
Because the first fragment of attack TCP packets does not hit any match in the packet filter, the subsequent fragments can all pass through. After the receiving host reassembles the fragments, a TCP fragment attack occurs.
To prevent TCP fragment attacks, enable TCP fragment attack prevention to drop attack TCP fragments.
Login dictionary attack
The login dictionary attack is an automated process to attempt to log in by trying all possible passwords from a pre-arranged list of values (the dictionary). Multiple login attempts can occur in a short period of time.
You can configure the login delay feature to slow down the login dictionary attacks. This feature enables the device to delay accepting another login request after detecting a failed login attempt for a user.
Whitelist
Address object group whitelist
The address object group whitelist feature exempts packets from the whitelisted address object group from attack detection. Packets from the whitelisted address object group are directly forwarded whether they are attack packets or not. The address object group whitelist feature must be used together with the address object group feature. An address object group is a set of IP address objects. For more information about address object groups, see "Configuring object groups."
Client verification
TCP client verification
The TCP client verification feature protects TCP servers against the following flood attacks:
· SYN.
· ACK.
· SYN-ACK.
· FIN.
· RST.
The TCP client verification feature enables a TCP proxy on the device.
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.
As shown in Figure 1, if packets from TCP clients pass through the proxy device, but the packets from servers do not, only the safe reset mode can be used.
Figure 1 Safe reset mode application
· SYN cookie—Enables bidirectional TCP proxy for TCP clients and servers.
As shown in Figure 2, if packets from clients and servers pass through the TCP proxy device, either safe reset or SYN cookie can be used.
Figure 2 Safe reset/SYN cookie mode application
TCP proxy in safe reset mode
As shown in Figure 3, 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.
Figure 3 TCP proxy in safe reset mode
TCP proxy in SYN cookie mode
As shown in Figure 4, 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.
Figure 4 TCP proxy in SYN cookie mode
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.
As shown in Figure 5, 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.
Figure 5 DNS client verification process
The DNS client 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 client verification, the first DNS resolution takes more time than normal DNS resolution.
HTTP client verification
The HTTP client verification feature protects HTTP servers against HTTP flood attacks. It is configured on the device where 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.
As shown in Figure 6, the HTTP client verification functions 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. For more information about TCP client verification, see "TCP client verification."
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.
Figure 6 HTTP client verification process
Attack detection and prevention configuration task list
|
Tasks at a glance |
|
(Required.) Configuring an attack defense policy: · (Required.) Creating an attack defense policy · (Required.) Perform at least one of the following tasks: ¡ Configuring a single-packet attack defense policy ¡ Configuring a scanning attack defense policy ¡ Configuring a flood attack defense policy · (Optional.) Configuring attack detection exemption |
|
(Required.) Perform at least one of the tasks: |
|
(Required.) Applying an attack defense policy to a security zone |
|
(Optional.) Enabling log non-aggregation for single-packet attack events |
|
(Optional.) Configuring TCP fragment attack prevention |
|
(Optional.) Enabling the top attack statistics ranking feature |
|
(Optional.) Configuring client verification: · Configuring TCP client verification |
|
(Optional.) Configuring the address object group whitelist |
|
(Optional.) Enabling the login delay |
Configuring an attack defense policy
Creating an attack defense policy
An attack defense policy can contain a set of attack detection and prevention configuration against multiple attacks.
To create an attack defense policy:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Create an attack defense policy and enter its view. |
attack-defense policy policy-name |
By default, no attack defense policy exists. |
Configuring a single-packet attack defense policy
Apply the single-packet attack defense policy to the interface or 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 (the default action).
· Drop attack packets.
You can also configure the device to not take any actions.
To configure a single-packet attack defense policy:
|
Step |
Command |
Remarks |
|
3. Enter system view. |
system-view |
N/A |
|
4. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
5. Configure signature detection for single-packet attacks. |
· signature detect { fraggle | fragment | impossible | land | large-icmp | large-icmpv6 | smurf | snork | tcp-all-flags | tcp-fin-only | tcp-invalid-flags | tcp-null-flag | tcp-syn-fin | tiny-fragment | traceroute | udp-bomb | winnuke } [ action { { drop | logging } * | none } ] · signature detect { ip-option-abnormal | ping-of-death | teardrop } action { drop | logging } * · signature detect icmp-type { icmp-type-value | address-mask-reply | address-mask-request | destination-unreachable | echo-reply | echo-request | information-reply | information-request | parameter-problem | redirect | source-quench | time-exceeded | timestamp-reply | timestamp-request } [ action { { drop | logging } * | none } ] · signature detect icmpv6-type { icmpv6-type-value | destination-unreachable | echo-reply | echo-request | group-query | group-reduction | group-report | packet-too-big | parameter-problem | time-exceeded } [ action { { drop | logging } * | none } ] · signature detect ip-option { option-code | internet-timestamp | loose-source-routing | record-route | route-alert | security | stream-id | strict-source-routing } [ action { { drop | logging } * | none } ] · signature detect ipv6-ext-header ext-header-value [ action { { drop | logging } * | none } ] |
By default, signature detection is not configured for single-packet attacks. You can configure signature detection for multiple single-packet attacks. |
|
6. (Optional.) Set the maximum length of safe ICMP or ICMPv6 packets. |
signature { large-icmp | large-icmpv6 } max-length length |
By default, the maximum length of safe ICMP or ICMPv6 packets is 4000 bytes. A large ICMP or ICMPv6 attack occurs if an ICMP or ICMPv6 packet larger than the specified length is detected. |
|
7. (Optional.) Specify the actions against single-packet attacks of a specific level. |
signature level { high | info | low | medium } action { { drop | logging } * | none } |
The default action is logging for single-packet attacks of the informational and low levels. The default actions are logging and drop for single-packet attacks of the medium and high levels. |
|
8. (Optional.) Enable signature detection for single-packet attacks of a specific level. |
signature level { high | info | low | medium } detect |
By default, signature detection is disabled for all levels of single-packet attacks. |
Configuring a scanning attack defense policy
Apply a scanning attack defense policy to the interface or 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.
To configure a scanning attack defense policy:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Configure scanning attack detection. |
scan detect level { high | low | medium } action { drop | logging } * |
By default, scanning attack detection is not configured. |
Configuring a flood attack defense policy
Apply a flood attack defense policy to the interface or 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 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.
If a device has multiple service cards, the global trigger threshold you set takes effect on each service card. The global trigger threshold of the device is the product of multiplying the value you set by the service card quantity.
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.
Configuring a SYN flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global SYN flood attack detection. |
By default, global SYN flood attack detection is disabled. |
|
|
4. Set the global trigger threshold for SYN flood attack prevention. |
syn-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against SYN flood attacks. |
syn-flood action { client-verify | drop | logging } * |
By default, no global action is specified for SYN flood attacks. |
|
6. Configure IP address-specific SYN flood attack detection. |
syn-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { client-verify | drop | logging } * | none } ] |
By default, IP address-specific SYN flood attack detection is not configured. |
Configuring an ACK flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global ACK flood attack detection. |
ack-flood detect non-specific |
By default, global ACK flood attack detection is disabled. |
|
4. Set the global trigger threshold for ACK flood attack prevention. |
ack-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against ACK flood attacks. |
ack-flood action { client-verify | drop | logging } * |
By default, no global action is specified for ACK flood attacks. |
|
6. Configure IP address-specific ACK flood attack detection. |
ack-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { client-verify | drop | logging } * | none } ] |
By default, IP address-specific ACK flood attack detection is not configured. |
Configuring a SYN-ACK flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global SYN-ACK flood attack detection. |
syn-ack-flood detect non-specific |
By default, global SYN-ACK flood attack detection is disabled. |
|
4. Set the global trigger threshold for SYN-ACK flood attack prevention. |
syn-ack-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against SYN-ACK flood attacks. |
syn-ack-flood action { client-verify | drop | logging } * |
By default, no global action is specified for SYN-ACK flood attacks. |
|
6. Configure IP address-specific SYN-ACK flood attack detection. |
syn-ack-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { client-verify | drop | logging } * | none } ] |
By default, IP address-specific SYN-ACK flood attack detection is not configured. |
Configuring a FIN flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global FIN flood attack detection. |
fin-flood detect non-specific |
By default, global FIN flood attack detection is disabled. |
|
4. Set the global trigger threshold for FIN flood attack prevention. |
fin-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against FIN flood attacks. |
fin-flood action { client-verify | drop | logging } * |
By default, no global action is specified for FIN flood attacks. |
|
6. Configure IP address-specific FIN flood attack detection. |
fin-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { client-verify | drop | logging } * | none } ] |
By default, IP address-specific FIN flood attack detection is not configured. |
Configuring an RST flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global RST flood attack detection. |
rst-flood detect non-specific |
By default, global RST flood attack detection is disabled. |
|
4. Set the global trigger threshold for RST flood attack prevention. |
rst-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against RST flood attacks. |
rst-flood action { client-verify | drop | logging } * |
By default, no global action is specified for RST flood attacks. |
|
6. Configure IP address-specific RST flood attack detection. |
rst-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { client-verify | drop | logging } * | none } ] |
By default, IP address-specific RST flood attack detection is not configured. |
Configuring an ICMP flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global ICMP flood attack detection. |
icmp-flood detect non-specific |
By default, global ICMP flood attack detection is disabled. |
|
4. Set the global trigger threshold for ICMP flood attack prevention. |
icmp-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against ICMP flood attacks. |
icmp-flood action { drop | logging } * |
By default, no global action is specified for ICMP flood attacks. |
|
6. Configure IP address-specific ICMP flood attack detection. |
icmp-flood detect ip ip-address [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { drop | logging } * | none } ] |
By default, IP address-specific ICMP flood attack detection is not configured. |
Configuring an ICMPv6 flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global ICMPv6 flood attack detection. |
icmpv6-flood detect non-specific |
By default, global ICMPv6 flood attack detection is disabled. |
|
4. Set the global trigger threshold for ICMPv6 flood attack prevention. |
icmpv6-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against ICMPv6 flood attacks. |
icmpv6-flood action { drop | logging } * |
By default, no global action is specified for ICMPv6 flood attacks. |
|
6. Configure IP address-specific ICMPv6 flood attack detection. |
icmpv6-flood detect ipv6 ipv6-address [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { drop | logging } * | none } ] |
By default, IP address-specific ICMPv6 flood attack detection is not configured. |
Configuring a UDP flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global UDP flood attack detection. |
udp-flood detect non-specific |
By default, global UDP flood attack detection is disabled. |
|
4. Set the global trigger threshold for UDP flood attack prevention. |
udp-flood threshold threshold-value |
The default setting is 1000. |
|
5. Specify global actions against UDP flood attacks. |
udp-flood action { drop | logging } * |
By default, no global action is specified for UDP flood attacks. |
|
6. Configure IP address-specific UDP flood attack detection. |
udp-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ threshold threshold-value ] [ action { { drop | logging } * | none } ] |
By default, IP address-specific UDP flood attack detection is not configured. |
Configuring a DNS flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global DNS flood attack detection. |
dns-flood detect non-specific |
By default, global DNS flood attack detection is disabled. |
|
4. Set the global trigger threshold for DNS flood attack prevention. |
dns-flood threshold threshold-value |
The default setting is 1000. |
|
5. (Optional.) Specify the global ports to be protected against DNS flood attacks. |
dns-flood port port-list |
By default, DNS flood attack prevention protects port 53. |
|
6. Specify global actions against DNS flood attacks. |
dns-flood action { client-verify | drop | logging } * |
By default, no global action is specified for DNS flood attacks. |
|
7. Configure IP address-specific DNS flood attack detection. |
dns-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ port port-list ] [ threshold threshold-value ] [ action { { client-verify | drop | logging } * | none } ] |
By default, IP address-specific DNS flood attack detection is not configured. |
Configuring an HTTP flood attack defense policy
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Enable global HTTP flood attack detection. |
http-flood detect non-specific |
By default, global HTTP flood attack detection is disabled. |
|
4. Set the global trigger threshold for HTTP flood attack prevention. |
http-flood threshold threshold-value |
The default setting is 1000. |
|
5. (Optional.) Specify the global ports to be protected against HTTP flood attacks. |
http-flood port port-list |
By default, HTTP flood attack prevention protects port 80. |
|
6. Specify global actions against HTTP flood attacks. |
http-flood action { client-verify | drop | logging } * |
By default, no global action is specified for HTTP flood attacks. |
|
7. Configure IP address-specific HTTP flood attack detection. |
http-flood detect { ip ipv4-address | ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] [ port port-list ] [ threshold threshold-value ] [ action { { client-verify | drop | logging } * | none } ] |
By default, IP address-specific HTTP flood attack detection is not configured. |
Configuring 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. For example, the attack defense policy identifies multicast packets with the same source addresses and different destination addresses as scanning attack packets (for example, OSPF or PIM packets). You can configure an ACL to exempt such packets from attack detection.
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.
· L3VPN instance.
· fragment keyword for matching non-first fragments.
To configure attack detection exemption:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter attack defense policy view. |
attack-defense policy policy-name |
N/A |
|
3. Configure attack detection exemption. |
exempt acl [ ipv6 ] { acl-number | name acl-name } |
By default, attack detection exemption is not configured. |
Applying an attack defense policy to an interface
An attack defense policy does not take effect unless you apply it to an interface.
If you apply an attack defense policy to a global interface, specify a service card to process traffic for the interface. If you do not specify a service card, the policy cannot correctly detect and prevent scanning and flood attacks.
To apply an attack defense policy to an interface:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter system view. |
interface interface-type interface-number |
N/A |
|
3. Apply an attack defense policy to the interface. |
attack-defense apply policy policy-name |
By default, no attack defense policy is applied to the interface. |
|
4. (Optional.) Specify a traffic processing slot for the interface. |
· In standalone mode: · In IRF mode: |
By default, no traffic processing slot is specified for an interface. Traffic on an interface is processed on the slot at which the traffic arrives. |
Applying an attack defense policy to the device
An attack defense policy applied to the device itself rather than the interfaces detects packets destined for the device and prevents attacks targeted at the device.
Applying an attack defense policy to a device can improve the efficiency of processing attack packets destined for the device.
If a device and its interfaces have attack defense policies applied, a packet destined for the device is processed as follows:
1. The policy applied to the receiving interface processes the packet.
2. If the packet is not dropped by the receiving interface, the policy applied to the device processes the packet.
To apply an attack defense policy to the device:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Apply an attack defense policy to the device. |
attack-defense local apply policy policy-name |
By default, no attack defense policy is applied to the device. |
Applying an attack defense policy to a security zone
An attack defense policy does not take effect unless you apply it to a security zone.
To apply an attack defense policy to a security zone:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enter security zone view. |
security-zone name zone-name |
N/A |
|
3. Apply an attack defense policy to the security zone. |
attack-defense apply policy policy-name |
By default, no attack defense policy is applied to the security zone. |
Enabling log non-aggregation for single-packet attack events
Log aggregation aggregates multiple logs generated during a period of time and sends one log. Logs that are aggregated must have the following attributes in common:
· Attacks are detected on the same interface or security zone or are destined for the device.
· Attack type.
· Attack defense action.
· Source and destination IP addresses.
· VPN instance to which the victim IP address belongs.
As a best practice, do not disable log aggregation. A large number of logs will consume the display resources of the console.
To enable log non-aggregation for single-packet attack events:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable log non-aggregation for single-packet attack events. |
attack-defense signature log non-aggregate |
By default, log non-aggregation is disabled for single-packet attack events. |
Configuring TCP fragment attack prevention
The TCP fragment attack prevention feature detects the length and fragment offset of received TCP fragments and drops attack TCP fragments.
TCP fragment attack prevention takes precedence over single-packet attack prevention. When both are used, incoming TCP packets are processed first by TCP fragment attack prevention and then by the single-packet attack defense policy.
TCP fragment attack prevention is independent of the attack defense policy.
To configure TCP fragment attack prevention:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable TCP fragment attack prevention. |
attack-defense tcp fragment enable |
By default, TCP fragment attack prevention is enabled. |
Enabling the top attack statistics ranking feature
This feature collects statistics about dropped attack packets based on attacker, victim, and attack type and ranks the top attack statistics by attacker and victim. To display the top attack statistics rankings, use the display attack-defense top-attack-statistics command.
To enable the top attack statistics feature:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable the top attack statistics ranking feature. |
attack-defense top-attack-statistics enable |
By default, the top attack statistics ranking feature is disabled. |
Configuring TCP client verification
Configure TCP client verification on the interface or security zone that is connected to the external network. TCP client verification protects internal TCP servers against TCP flood attacks, including the following flood attacks:
· SYN.
· SYN-ACK.
· RST.
· FIN.
· ACK.
IP addresses protected by TCP 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 SYN packet destined for a protected IP address.
· The TCP client verification can automatically add victims' IP addresses to the protected IP list when collaborating with flood attack detection. Make sure client-verify is specified as the flood attack prevention action. For more information, see "Configuring a flood attack defense policy."
If a TCP client is verified legitimate in safe reset mode, the device adds the client's IP address to the trusted IP list. The device directly forwards TCP packets from trusted IP addresses.
TCP client verification can be used alone or together with a TCP flood attack defense policy.
To configure TCP client verification:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. (Optional.) Specify an IP address to be protected by the TCP client verification feature. |
client-verify tcp protected { ip destination-ip-address | ipv6 destination-ipv6-address } [ vpn-instance vpn-instance-name ] [ port port-number ] |
By default, the TCP client verification feature does not protect any IP address. |
|
3. Enter interface view. |
interface interface-type interface-number |
N/A |
|
4. Enter security zone view. |
security-zone name zone-name |
N/A |
|
5. Enable TCP client verification. |
· To set the safe reset mode: · To set the SYN cookie mode: |
By default, TCP client verification is disabled. |
Configuring DNS client verification
Configure DNS client verification the interface or security zone that is connected to the external network. The DNS client verification protects internal DNS servers against DNS flood attacks.
IP addresses protected by DNS 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 DNS query destined for a protected IP address.
· The DNS client verification can automatically add victims' IP addresses to the protected IP list when collaborating with DNS flood attack detection. Make sure client-verify is specified as the DNS flood attack prevention action. For more information, see "Configuring a DNS flood attack defense policy."
If a DNS client is verified legitimate, the device adds the client's IP address to the trusted IP list. The device directly forwards DNS packets from trusted IP addresses.
DNS client verification can be used alone or together with a DNS flood attack defense policy.
To configure DNS client verification:
|
Step |
Command |
Remarks |
|
|
1. Enter system view. |
system-view |
N/A |
|
|
2. (Optional.) Specify an IP address to be protected by the DNS client verification feature. |
client-verify dns protected { ip destination-ip-address | ipv6 destination-ipv6-address } [ vpn-instance vpn-instance-name ] [ port port-number ] |
By default, the DNS client verification feature does not protect any IP address. |
|
|
3. Enter interface view. |
interface interface-type interface-number |
N/A |
|
|
4. Enter security zone view. |
security-zone name zone-name |
N/A |
|
|
5. Enable DNS client verification. |
client-verify dns enable |
By default, DNS client verification is disabled. |
|
Configuring HTTP client verification
Configure HTTP client verification on the interface or security zone that is connected to the external network. The HTTP client verification protects internal HTTP servers against HTTP flood attacks.
IP addresses protected by HTTP 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 HTTP Get packet destined for a protected IP address.
· The HTTP client verification can automatically add victims' IP addresses to the protected IP list when collaborating with HTTP flood attack detection. Make sure client-verify is specified as the HTTP flood attack prevention action. For more information, see "Configuring an HTTP flood attack defense policy."
If an HTTP client is verified legitimate, the device adds the client's IP address to the trusted IP list. The device directly forwards HTTP packets from trusted IP addresses.
HTTP client verification can be used alone or together with an HTTP flood attack defense policy.
To configure HTTP client verification:
|
Step |
Command |
Remarks |
|
|
1. Enter system view. |
system-view |
N/A |
|
|
2. (Optional.) Specify an IP address to be protected by the HTTP client verification feature. |
client-verify http protected { ip destination-ip-address | ipv6 destination-ipv6-address } [ vpn-instance vpn-instance-name ] [ port port-number ] |
By default, the HTTP client verification feature does not protect any IP address. |
|
|
3. Enter interface view. |
interface interface-type interface-number |
N/A |
|
|
4. Enter security zone view. |
security-zone name zone-name |
N/A |
|
|
5. Enable HTTP client verification. |
client-verify http enable |
By default, HTTP client verification is disabled. |
|
Configuring the address object group whitelist
The address object group whitelist feature exempts packets sourced from the subnets 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.
The address object group whitelist feature must be used together with the address object group feature. For more information about address object groups, see "Configuring object groups."
The address object group whitelist is independent of the attack defense policy.
To configure the address object group whitelist:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. (Optional.) Enable the global whitelist feature. |
whitelist global enable |
By default, the global whitelist feature is disabled. |
|
3. Add an address object group to the whitelist. |
whitelist object-group object-group-name |
By default, no address object group is added to the whitelist. |
|
4. Enter interface view. |
interface interface-type interface-number |
N/A |
|
5. Enter security zone view. |
security-zone name zone-name |
N/A |
|
6. Enable the whitelist feature on the interface or security zone. |
whitelist enable |
By default, the whitelist feature is disabled on the interface or security zone. |
Enabling the login delay
The login delay feature delays the device from accepting a login request from a user after the user fails a login attempt. This feature can slow down login dictionary attacks.
Login delay is independent of the attack defense policy.
To enable the login delay:
|
Step |
Command |
Remarks |
|
1. Enter system view. |
system-view |
N/A |
|
2. Enable the login delay feature. |
attack-defense login reauthentication-delay seconds |
By default, the login delay feature is disabled. The device does not delay accepting a login request from a user who has failed a login attempt. |
Displaying and maintaining attack detection and prevention
Use the display commands in any view and the reset commands in user view.
To display and maintain attack detection and prevention:
|
Task |
Command |
|
Display attack detection and prevention statistics on an interface. |
display attack-defense statistics interface interface-type interface-number |
|
Display attack detection and prevention statistics for the device (in standalone mode). |
display attack-defense statistics local [ slot slot-number ] |
|
Display attack detection and prevention statistics for the device (in IRF mode). |
display attack-defense statistics local [ chassis chassis-number slot slot-number ] |
|
Display attack defense policy configuration. |
display attack-defense policy [ policy-name ] |
|
Display information about IPv4 scanning attackers. |
display attack-defense scan attacker ip [ interface interface-type interface-number | local ] [ count ] |
|
Display information about IPv6 scanning attackers. |
display attack-defense scan attacker ipv6 [ interface interface-type interface-number | local ] [ count ] |
|
Display information about IPv4 scanning attack victims. |
display attack-defense scan victim ip [ interface interface-type interface-number | local ] [ count ] |
|
Display information about IPv6 scanning attack victims. |
display attack-defense scan victim ipv6 [ interface interface-type interface-number | local ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv4 address (in standalone mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ip [ ip-address [ vpn vpn-instance-name ] ] [ [ interface interface-type interface-number | local ] [ slot slot-number ] ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv4 address (in IRF mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ip [ ip-address [ vpn vpn-instance-name ] ] [ [ interface interface-type interface-number | local ] [ chassis chassis-number slot slot-number ] ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv6 address (in standalone mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ [ interface interface-type interface-number | local ] [ slot slot-number ] ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv6 address (in IRF mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ [ interface interface-type interface-number | local ] [ chassis chassis-number slot slot-number ] ] [ count ] |
|
Display information about IPv4 addresses protected by flood attack detection and prevention (in standalone mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ip [ ip-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display information about IPv4 addresses protected by flood attack detection and prevention (in IRF mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ip [ ip-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display information about IPv6 addresses protected by flood attack detection and prevention (in standalone mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display information about IPv6 addresses protected by flood attack detection and prevention (in IRF mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display top ten attack statistics. |
display attack-defense top-attack-statistics { last-1-hour | last-24-hours | last-30-days } [ by-attacker | by-type | by-victim ] |
|
Display protected IPv4 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } protected ip [ ip-address [ vpn vpn-instance-name ] ] [ port port-number ] [ slot slot-number ] [ count ] |
|
Display protected IPv4 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } protected ip [ ip-address [ vpn vpn-instance-name ] ] [ port port-number ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display protected IPv6 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } protected ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ port port-number ] [ slot slot-number ] [ count ] |
|
Display protected IPv6 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } protected ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ port port-number ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display trusted IPv4 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } trusted ip [ ip-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display trusted IPv4 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } trusted ip [ ip-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display trusted IPv6 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } trusted ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display trusted IPv6 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } trusted ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Clear attack detection and prevention statistics for an interface. |
reset attack-defense statistics interface interface-type interface-number |
|
Clear attack detection and prevention statistics for the device. |
reset attack-defense statistics local |
|
Clear flood attack detection and prevention statistics. |
reset attack-defense policy policy-name flood protected { ip | ipv6 } statistics |
|
Clear top ten attack statistics. |
reset attack-defense top-attack-statistics |
|
Clear protected IP statistics for client verification. |
reset client-verify { dns | http | tcp } protected { ip | ipv6 } statistics |
|
Clear the trusted IP list for client verification. |
reset client-verify { dns | http | tcp } trusted { ip | ipv6 } |
To display and maintain attack detection and prevention:
|
Task |
Command |
|
Display attack detection and prevention statistics on a security zone (in standalone mode). |
display attack-defense statistics security-zone zone-name [ slot slot-number ] |
|
Display attack detection and prevention statistics on a security zone (in IRF mode). |
display attack-defense statistics security-zone zone-name [ chassis chassis-number slot slot-number ] |
|
Display attack defense policy configuration. |
display attack-defense policy [ policy-name ] |
|
Display information about IPv4 scanning attackers (in standalone mode). |
display attack-defense scan attacker ip [ security-zone zone-name [ slot slot-number ] ] [ count ] |
|
Display information about IPv4 scanning attackers (in IRF mode). |
display attack-defense scan attacker ip [ security-zone zone-name [ chassis chassis-number slot slot-number ] ] [ count ] |
|
Display information about IPv6 scanning attackers (in standalone mode). |
display attack-defense scan attacker ipv6 [ security-zone zone-name [ slot slot-number ] ] [ count ] |
|
Display information about IPv6 scanning attackers (in IRF mode). |
display attack-defense scan attacker ipv6 [ security-zone zone-name [ chassis chassis-number slot slot-number ] ] [ count ] |
|
Display information about IPv4 scanning attack victims (in standalone mode). |
display attack-defense scan victim ip [ security-zone zone-name [ slot slot-number ] ] [ count ] |
|
Display information about IPv4 scanning attack victims (in IRF mode). |
display attack-defense scan victim ip [ security-zone zone-name [ chassis chassis-number slot slot-number ] ] [ count ] |
|
Display information about IPv6 scanning attack victims (in standalone mode). |
display attack-defense scan victim ipv6 [ security-zone zone-name [ slot slot-number ] ] [ count ] |
|
Display information about IPv6 scanning attack victims (in IRF mode). |
display attack-defense scan victim ipv6 [ security-zone zone-name [ chassis chassis-number slot slot-number ] ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv4 address (in standalone mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ip [ ip-address [ vpn vpn-instance-name ] ] [ security-zone zone-name ] [ slot slot-number ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv4 address (in IRF mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ip [ ip-address [ vpn vpn-instance-name ] ] [ security-zone zone-name ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv6 address (in standalone mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ security-zone zone-name ] [ slot slot-number ] [ count ] |
|
Display flood attack detection and prevention statistics for an IPv6 address (in IRF mode). |
display attack-defense { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } statistics ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ security-zone zone-name ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display information about IPv4 addresses protected by flood attack detection and prevention (in standalone mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ip [ ip-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display information about IPv4 addresses protected by flood attack detection and prevention (in IRF mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmp-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ip [ ip-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display information about IPv6 addresses protected by flood attack detection and prevention (in standalone mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display information about IPv6 addresses protected by flood attack detection and prevention (in IRF mode). |
display attack-defense policy policy-name { ack-flood | dns-flood | fin-flood | flood | http-flood | icmpv6-flood | rst-flood | syn-ack-flood | syn-flood | udp-flood } ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display top ten attack statistics. |
display attack-defense top-attack-statistics { last-1-hour | last-24-hours | last-30-days } [ by-attacker | by-type | by-victim ] |
|
Display protected IPv4 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } protected ip [ ip-address [ vpn vpn-instance-name ] ] [ port port-number ] [ slot slot-number ] [ count ] |
|
Display protected IPv4 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } protected ip [ ip-address [ vpn vpn-instance-name ] ] [ port port-number ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display protected IPv6 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } protected ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ port port-number ] [ slot slot-number ] [ count ] |
|
Display protected IPv6 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } protected ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ port port-number ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display trusted IPv4 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } trusted ip [ ip-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display trusted IPv4 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } trusted ip [ ip-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Display trusted IPv6 addresses for client verification (in standalone mode). |
display client-verify { dns | http | tcp } trusted ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ slot slot-number ] [ count ] |
|
Display trusted IPv6 addresses for client verification (in IRF mode). |
display client-verify { dns | http | tcp } trusted ipv6 [ ipv6-address [ vpn vpn-instance-name ] ] [ chassis chassis-number slot slot-number ] [ count ] |
|
Clear attack detection and prevention statistics for a security zone. |
reset attack-defense statistics security-zone zone-name |
|
Clear flood attack detection and prevention statistics. |
reset attack-defense policy policy-name flood protected { ip | ipv6 } statistics |
|
Clear top ten attack statistics. |
reset attack-defense top-attack-statistics |
|
Clear protected IP statistics for client verification. |
reset client-verify { dns | http | tcp } protected { ip | ipv6 } statistics |
|
Clear the trusted IP list for client verification. |
reset client-verify { dns | http | tcp } trusted { ip | ipv6 } |
Attack detection and prevention configuration examples
Address object group whitelist configuration example
Network requirements
As shown in Figure 7, configure the address object group whitelist feature on the router to allow all packets from subnet 5.5.5.0/24 to pass through.
Configuration procedure
# Configure IP addresses for the interfaces on the router. (Details not shown.)
# Enable the global whitelist feature.
<Router> system-view
[Router] whitelist global enable
# Create IPv4 address object group obj1. Configure an IPv4 address object with subnet 5.5.5.0/24.
[Router] object-group ip address obj1
[Router-obj-grp-ip-obj1] network subnet 5.5.5.0 24
[Router] quit
# Add IPv4 address object group obj1 to the whitelist.
[Router] whitelist object-group obj1
Verifying the configuration
# Verify that the router allows all packets from subnet 5.5.5.0/24 to pass through unless you execute the undo whitelist object-group obj1 command on the router. (Details not shown.)
Interface-based TCP client verification configuration example
Network requirements
As shown in Figure 8, configure TCP client verification in SYN cookie mode on the router to protect the internal servers against SYN flood attacks.
Configuration procedure
# Configure IP addresses for the interfaces on the router. (Details not shown.)
# Create attack defense policy a1.
<Router> system-view
[Router] attack-defense policy a1
# Enable global SYN flood attack detection.
[Router-attack-defense-policy-a1] syn-flood detect non-specific
# Set the global threshold for triggering SYN flood attack prevention to 10000.
[Router-attack-defense-policy-a1] syn-flood threshold 10000
# Specify logging and client-verify as the global actions against SYN flood attacks.
[Router-attack-defense-policy-a1] syn-flood action logging client-verify
[Router-attack-defense-policy-a1] quit
# Apply the attack defense policy a1 to interface GigabitEthernet 2/1/1.
[Router] interface gigabitethernet 2/1/1
[Router-GigabitEthernet2/1/1] attack-defense apply policy a1
[Router-GigabitEthernet2/1/1] quit
# Enable TCP client verification in SYN cookie mode on interface GigabitEthernet 2/1/1.
[Router] interface gigabitethernet 2/1/1
[Router-GigabitEthernet2/1/1] client-verify tcp enable mode syn-cookie
[Router-GigabitEthernet2/1/1] quit
Verifying the configuration
# Launch a SYN flood attack. (Details not shown.)
# Verify that the victim's IP address is added to the protected IP list for TCP client verification.
[Router] display client-verify tcp protected ip
IP address VPN instance Port Type Requested Trusted
192.168.1.10 -- any Dynamic 20 12
Security zone-based TCP client verification configuration example
Network requirements
As shown in Figure 9, configure TCP client verification in SYN cookie mode on the router to protect the internal servers against SYN flood attacks.
Configuration procedure
# Configure IP addresses for the interfaces on the router. (Details not shown.)
# Add GigabitEthernet 2/1/2 to the security zone Trust.
<Router> system-view
[Router] security-zone name trust
[Router-security-zone-Trust] import interface gigabitethernet 2/1/2
[Router-security-zone-Trust] quit
# Add GigabitEthernet 2/1/1 to the security zone Untrust.
[Router] security-zone name untrust
[Router-security-zone-Untrust] import interface gigabitethernet 2/1/1
[Router-security-zone-Untrust] quit
# Create a zone pair with the source security zone Untrust and the destination security zone Trust.
[Router] zone-pair security source untrust destination trust
# Configure a security policy and apply it to the zone pair, so security zones Untrust and Trust can communicate. (Details not shown.)
# Return to system view.
[Router-zone-pair-security-Untrust-Trust] quit
# Create attack defense policy a1.
[Router] attack-defense policy a1
# Enable global SYN flood attack detection.
[Router-attack-defense-policy-a1] syn-flood detect non-specific
# Set the global threshold for triggering SYN flood attack prevention to 10000.
[Router-attack-defense-policy-a1] syn-flood threshold 10000
# Specify logging and client-verify as the global actions against SYN flood attacks.
[Router-attack-defense-policy-a1] syn-flood action logging client-verify
[Router-attack-defense-policy-a1] quit
# Apply the attack defense policy a1 to the security zone Untrust.
[Router] security-zone name untrust
[Router-security-zone-Untrust] attack-defense apply policy a1
# Enable TCP client verification in SYN cookie mode on the security zone Untrust.
[Router-security-zone-Untrust] client-verify tcp enable mode syn-cookie
[Router-security-zone-Untrust] quit
Verifying the configuration
# Launch a SYN flood attack. (Details not shown.)
# Verify that the victim's IP address is added to the protected IP list for TCP client verification.
[Router] display client-verify tcp protected ip
IP address VPN instance Port Type Requested Trusted
192.168.1.10 -- any Dynamic 20 12
Interface-based DNS client verification configuration example
Network requirements
As shown in Figure 10, configure DNS client verification on the router to protect internal servers against DNS flood attacks.
Configuration procedure
# Configure IP addresses for the interfaces on the router. (Details not shown.)
# Create attack defense policy a1.
<Router> system-view
[Router] attack-defense policy a1
# Enable global DNS flood attack detection.
[Router-attack-defense-policy-a1] dns-flood detect non-specific
# Set the global threshold for triggering DNS flood attack prevention to 10000.
[Router-attack-defense-policy-a1] dns-flood threshold 10000
# Specify logging and client-verify as the global actions against DNS flood attacks.
[Router-attack-defense-policy-a1] dns-flood action logging client-verify
[Router-attack-defense-policy-a1] quit
# Apply the attack defense policy a1 to interface GigabitEthernet 2/1/1.
[Router] interface gigabitethernet 2/1/1
[Router-GigabitEthernet2/1/1] attack-defense apply policy a1
[Router-GigabitEthernet2/1/1] quit
# Enable DNS client verification on interface GigabitEthernet 2/1/1.
[Router] interface gigabitethernet 2/1/1
[Router-GigabitEthernet2/1/1] client-verify dns enable
[Router-GigabitEthernet2/1/1] quit
Verifying the configuration
# Launch a DNS flood attack. (Details not shown.)
# Verify that the victim's IP address is added to the protected IP list for DNS client verification.
[Router] display client-verify dns protected ip
IP address VPN instance Port Type Requested Trusted
192.168.1.10 -- 53 Dynamic 20 12
Security zone-based DNS client verification configuration example
Network requirements
As shown in Figure 11, configure DNS client verification on the router to protect internal servers against DNS flood attacks.
Configuration procedure
# Configure IP addresses for the interfaces on the router. (Details not shown.)
# Add GigabitEthernet 2/1/2 to the security zone Trust.
<Router> system-view
[Router] security-zone name trust
[Router-security-zone-Trust] import interface gigabitethernet 2/1/2
[Router-security-zone-Trust] quit
# Add GigabitEthernet 2/1/1 to the security zone Untrust.
[Router] security-zone name untrust
[Router-security-zone-Untrust] import interface gigabitethernet 2/1/1
[Router-security-zone-Untrust] quit
# Create a zone pair with the source security zone Untrust and the destination security zone Trust.
[Router] zone-pair security source untrust destination trust
# Configure a security policy and apply it to the zone pair, so security zones Untrust and Trust can communicate. (Details not shown.)
# Return to system view.
[Router-zone-pair-security-Untrust-Trust] quit
# Create attack defense policy a1.
[Router] attack-defense policy a1
# Enable global DNS flood attack detection.
[Router-attack-defense-policy-a1] dns-flood detect non-specific
# Set the global threshold for triggering DNS flood attack prevention to 10000.
[Router-attack-defense-policy-a1] dns-flood threshold 10000
# Specify logging and client-verify as the global actions against DNS flood attacks.
[Router-attack-defense-policy-a1] dns-flood action logging client-verify
[Router-attack-defense-policy-a1] quit
# Apply the attack defense policy a1 to the security zone Untrust.
[Router] security-zone name untrust
[Router-security-zone-Untrust] attack-defense apply policy a1
# Enable DNS client verification on the security zone Untrust.
[Router-security-zone-untrust] client-verify dns enable
[Router-security-zone-Untrust] quit
Verifying the configuration
# Launch a DNS flood attack. (Details not shown.)
# Verify that the victim's IP address is added to the protected IP list for DNS client verification.
[Router] display client-verify dns protected ip
IP address VPN instance Port Type Requested Trusted
192.168.1.10 -- 53 Dynamic 20 12
Interface-based HTTP client verification configuration example
Network requirements
As shown in Figure 12, configure HTTP client verification on the router to protect internal servers against HTTP flood attacks.
Configuration procedure
# Configure IP addresses for the interfaces on the router. (Details not shown.)
# Create attack defense policy a1.
<Router> system-view
[Router] attack-defense policy a1
# Enable global HTTP flood attack detection.
[Router-attack-defense-policy-a1] http-flood detect non-specific
# Set the global threshold to 10000 for triggering HTTP flood attack prevention.
[Router-attack-defense-policy-a1] http-flood threshold 10000
# Specify logging and client-verify as the global actions against HTTP flood attacks.
[Router-attack-defense-policy-a1] http-flood action logging client-verify
[Router-attack-defense-policy-a1] quit
# Apply the attack defense policy a1 to interface GigabitEthernet 2/1/1.
[Router] interface gigabitethernet 2/1/1
[Router-GigabitEthernet2/1/1] attack-defense apply policy a1
[Router-GigabitEthernet2/1/1] quit
# Enable HTTP client verification on interface GigabitEthernet 2/1/1.
[Router] interface gigabitethernet 2/1/1
[Router-GigabitEthernet2/1/1] client-verify http enable
[Router-GigabitEthernet2/1/1] quit
Verifying the configuration
# Launch an HTTP flood attack. (Details not shown.)
# Verify that the victim's IP address is added to the protected IP list for HTTP client verification.
[Router] display client-verify http protected ip
IP address VPN instance Port Type Requested Trusted
192.168.1.10 -- 8080 Dynamic 20 12
Security zone-based HTTP client verification configuration example
Network requirements
As shown in Figure 13, configure HTTP client verification on the router to protect internal servers against HTTP flood attacks.
Configuration procedure
# Configure IP addresses for the interfaces on the router. (Details not shown.)
# Add GigabitEthernet 2/1/2 to the security zone Trust.
<Router> system-view
[Router] security-zone name trust
[Router-security-zone-Trust] import interface gigabitethernet 2/1/2
[Router-security-zone-Trust] quit
# Add GigabitEthernet 2/1/1 to the security zone Untrust.
[Router] security-zone name untrust
[Router-security-zone-Untrust] import interface gigabitethernet 2/1/1
[Router-security-zone-Untrust] quit
# Create a zone pair with the source security zone Untrust and the destination security zone Trust.
[Router] zone-pair security source untrust destination trust
# Configure a security policy and apply it to the zone pair, so security zones Untrust and Trust can communicate. (Details not shown.)
# Return to system view.
[Router-zone-pair-security-Untrust-Trust] quit
# Create attack defense policy a1.
[Router] attack-defense policy a1
# Enable global HTTP flood attack detection.
[Router-attack-defense-policy-a1] http-flood detect non-specific
# Set the global threshold for triggering HTTP flood attack prevention to 10000.
[Router-attack-defense-policy-a1] http-flood threshold 10000
# Specify logging and client-verify as the global actions against HTTP flood attacks.
[Router-attack-defense-policy-a1] http-flood action logging client-verify
[Router-attack-defense-policy-a1] quit
# Apply the attack defense policy a1 to the security zone Untrust.
[Router] security-zone name untrust
[Router-security-zone-Untrust] attack-defense apply policy a1
# Enable HTTP client verification on the security zone Untrust.
[Router-security-zone-Untrust] client-verify http enable
[Router-security-zone-Untrust] quit
Verifying the configuration
# Launch an HTTP flood attack. (Details not shown.)
# Verify that the victim's IP address is added to the protected IP list for HTTP client verification.
[Router] display client-verify http protected ip
IP address VPN instance Port Type Requested Trusted
192.168.1.10 -- 8080 Dynamic 20 12
