What Is Local Attack Defense?

CPU Attack Defense

The core of CPU attack defense is CPCAR, that is, rate limiting based on protocol packets. A network administrator can run commands to configure the CPCAR values for each type of protocol packets, CPCAR value of all packets sent to the CPU, and application layer association. In addition, when the default CPCAR cannot meet service requirements, adaptive adjustment of the default CPCAR value for protocol packets is supported.

Application layer association

Application layer association protects data transmitted over sessions of a specific protocol, such as OSPF, BGP, and FTP. After such a session is established, the protocol-based default CPCAR value no longer takes effect. Instead, the device uses the CPCAR value configured for the protocol in application layer association to rate-limit the transmitted packets. Typically, the CPCAR value configured for each protocol in application layer association is much greater than the protocol-based default CPCAR value, ensuring the reliability and stability of service operations.

Adaptive adjustment of the default CPCAR value for protocol packets

Adaptive adjustment of the default CPCAR value for protocol packets applies to protocol packets related to user access, such as ARP packets, covering scenarios where a fixed default CPCAR value cannot meet rate requirements. After this function is enabled, the device dynamically adjusts the protocol-based default CPCAR value based on the packet loss rate and CPU usage of protocol packets.

User-Level Rate Limiting

When user-side hosts are infected with viruses, they send a large number of protocol packets, overloading device CPUs and deteriorating their performance, which ultimately impacting services. To address this issue, a network administrator can configure user-level rate limiting, which identifies users based on MAC addresses and rate-limits only the user who initiates an attack, ensuring other normal users are unaffected. User-level rate limiting (based on users) is more precise and has less of an impact on normal users than CPCAR (based on devices). The processing flow is as follows:

1. When receiving users' protocol packets, the device performs a hash calculation on the source MAC addresses and places packets from different source MAC addresses into different buckets.
2. When the number of packets placed in a bucket within the unit time exceeds the rate limit, the bucket discards the excess packets. The device counts the number of packets discarded by a bucket at a specified interval. If the number exceeds the rate limit, the device reports a packet loss log for the bucket.

Attack Source Tracing

Attack source tracing protects the CPU against denial of service (DoS) attacks. A device enabled with attack source tracing analyzes packets sent to the CPU, collects statistics on the packets, and considers packets exceeding the configured threshold as attack packets. The device finds the source user address and port based on packet information, generates logs and alarms to alert network administrators, and takes punishment actions.

The detailed process is as follows:

1. Packet parsing: The device parses packets to be sent to the CPU based on IP addresses, MAC addresses, and ports. A port is identified by physical port plus VLAN.
2. Traffic analysis: The device counts the number of received protocol packets based on IP addresses, MAC addresses, or ports.
3. Attack source identification: When the number of packets sent to the CPU in a unit time exceeds the threshold, the device considers that an attack has occurred.
4. Processing after identification: After detecting an attack, the device sends a log or alarm to notify the network administrator or directly implements punishment (for example, discarding attack packets).
   
   Attack source tracing process

   Attack source tracing also provides the whitelist function. After legitimate users are added to a whitelist, the device does not perform source tracing or punishment actions on packets from these users, so that such packets can be sent to the CPU for processing. A whitelist can be flexibly configured based on ACLs or ports.

Attack Defense

Before rate-limiting all packets, a device enabled with attack defense analyzes the content and behavior of packets sent to the CPU to determine whether these packets are attack packets. If so, the device takes defense approaches on these packets. Attack defense mainly defends against the following attacks: malformed packet attacks, fragmentation attacks, TCP SYN flood attacks, UDP flood attacks, and ICMP flood attacks.

Malformed Packet Attack

Fragmentation Attack

A fragmentation attack is an attack in which error fragments are sent to a target device, which then crashes, restarts, or consumes a large amount of CPU resources when processing such fragments, ultimately impacting services. Fragmentation attack defense enables a device to detect packet fragments in real time and discard or rate-limit them to protect the device.

Fragmentation attacks are classified into the following types.

• Excess-fragment attack: An IP packet is fragmented into over 8189 fragments, causing the device to consume a large amount of CPU resources when reassembling packets.
• Excess-offset attack: An attacker sends a fragment with an offset value larger than 8189 to a target device, which then allocates memory space to store all fragments, consuming a large amount of resources.
• Repeated fragment attack: In a repeated fragment attack, fragments are sent to a target host multiple times. As a result, the target host may experience high CPU usage or a memory error. Such an attack is carried out in one of the two ways: The same fragments are sent multiple times, or different fragments with the same offset are sent.
• Syndrop attack: A Syndrop attack exploits the mechanism of IP fragmentation to put the second fragment into the first. The offset of the second fragment is smaller than that of the first fragment, and the offset plus the data field of the second fragment does not exceed the tail of the first fragment. A Syndrop attack uses TCP packets that carry a SYN flag and also IP payload.
• Error fragment attack: The second fragment of an IP packet is put into the first. That is, the offset of the second fragment is smaller than that of the first fragment. Based on protocols and payload lengths, such attacks are classified into Syndrop attacks, NewTear attacks, Bonk attacks, and Nesta attacks.

When an excess-fragment attack, an excess-offset attack, a Syndrop attack, or an error fragment attack occurs, the device discards all fragments. When a repeated fragment attack occurs, the device applies the committed access rate (CAR) limit to packet fragments, reserves the first fragment, and discards all the remaining repeated fragments to protect the CPU.

TCP SYN Flood Attack

A TCP SYN flood attack exploits the vulnerability of the TCP three-way handshake. During the TCP three-way handshake, when the receiver (target device) receives the initial SYN packet from the sender (attacker), it returns a SYN+ACK packet to the sender. The connection remains in a half-open state while the receiver waits for the final ACK packet from the sender. If the receiver does not receive the ACK packet, it retransmits a SYN+ACK packet to the sender. Finally, after several retransmission attempts, the receiver shuts down the session and then updates the session in memory. The period from the first SYN+ACK packet being sent to session teardown is approximately 30 seconds.

During this period, an attacker may send thousands of SYN packets to all open interfaces, and never responds to SYN+ACK packets from the receiver. This causes memory overloading on the receiver and prevents the receiver from accepting new connection requests. The receiver then disconnects all existing connections.

TCP SYN flood attack

With defense against TCP SYN flood attacks enabled, the device rate-limits TCP SYN packets and discards SYN packets exceeding the rate limit to ensure that system resources are not exhausted if an attack occurs.

UDP Flood Attack

A UDP flood attack is an attack in which a large number of UDP packets are sent to a target device within a short time, causing the target device to be busy with these UDP packets and fail to process normal services. UDP flood attacks are classified into two types:

• Fraggle attack: An attacker sends UDP packets where the source address is the target device's address, the destination address is the broadcast address of the target network, and the destination port is port 7. If multiple hosts use UDP echo services on the broadcast network, the target device receives excessive response packets from these hosts and becomes occupied while processing these packets.

Fraggle attack

The device with defense against UDP flood attacks enabled considers packets from UDP port 7 as attack packets and discards them.

• UDP diagnosis port attack: An attacker sends a large number of UDP request packets to the target device's UDP diagnosis ports (such as 7-echo, 13-daytime, and 19-Chargen), causing flooding and consuming network bandwidth resources. In addition, as the target device consumes CPU resources when responding to these UDP request packets, the system becomes overloaded and cannot process normal services.

The device with flood attack defense enabled considers packets from UDP ports 7, 13, and 19 as attack packets and discards them.

ICMP Flood Attack

A network administrator typically monitors a network and rectifies faults using the ping tool as follows:

1. The source host sends an ICMP Echo message to a target device.
2. Upon receiving the ICMP Echo message, the target device sends an ICMP Echo Reply message to the source host.

If the target device receives many ICMP Echo messages from an attacker, it becomes occupied and unable to process other data packets. As a result, normal services are affected.

ICMP flood attack

With defense against ICMP flood attacks enabled, the device rate-limits ICMP messages to ensure that system resources are not exhausted if an attack occurs.