Search
Home Search Center IP Encyclopedia Online Courses

What Is Local Attack Defense?

Local attack defense is a central processing unit (CPU) protection mechanism designed to ensure that the CPU can properly process normal services. With this function enabled, the CPU can run properly even when it receives malicious attack packets or burst traffic, ensuring normal service running. Basic functions of local attack defense include packet filtering, CPU attack defense, port attack defense, user-level rate limiting, attack source tracing, and attack defense.

Why Do We Need Local Attack Defense?

Network security services are measures designed to address or mitigate network security threats, and local attack defense is one type of such services. In normal cases, a device sends some packets to the CPU for processing. However, when the device is subjected to malicious attacks or service overload, a large number of packets are sent to the CPU. If a large number of normal service packets are sent to the CPU, its usage surges. This severely impacts device performance, affecting or even interrupting services. Local attack defense is specifically designed to solve this problem, ensuring that when a device is under attack or overloaded, it can still prioritize the processing of critical protocol packets.

How Does Local Attack Defense Work?

The local attack defense function is designed to safeguard the CPU by implementing hierarchical control over the entire process of packet delivery to the CPU. Based on the packet processing workflow, it can be divided into three key stages: before delivery, during delivery, and after delivery. By building a multi-dimensional protection system across these stages, the function effectively resists various types of attacks and ensures stable device operation.

Hierarchical protection of local attack defense
Hierarchical protection of local attack defense
  • Before packet delivery:

    The main approaches in this stage include packet filtering and attack source tracing. By identifying attack sources or creating filters, the system filters or discards attack packets or the packets that match filtering rules.

  • During packet delivery:

    The main approaches in this stage include CPU attack defense, user-level rate limiting, and port attack defense. Traffic control is implemented through Control Plane Committed Access Rate (CPCAR) and queue-based scheduling and rate limiting. CPCAR is protocol-based packet rate limiting. After rate limiting, protocol packets enter queues allocated based on priorities or weights, ensuring that different services are processed based on priorities. This stage also supports applying CAR uniformly to all packets, regardless of the protocol type. This unified rate limiting before packets are delivered to the CPU serves as the final line of defense against CPU-targeted attacks.

  • After packet delivery:

    The main approaches in this stage include attack defense and attack source tracing analysis. By analyzing whether packets delivered to the CPU may constitute an attack, the system can generate logs or alarms to notify network administrators of potentially harmful packets. Administrators can then take measures to protect the device, or the system can directly identify and discard the attack packets based on their characteristics.

Common Functions of Local Attack Defense

Basic functions of local attack defense include packet filtering, CPU attack defense, port attack defense, user-level rate limiting, attack source tracing, and attack defense. Among these, packet filtering, CPU attack defense, port attack defense, and user-level rate limiting are used to handle issues caused by excessive packets on the network that affect services. Attack source tracing is used to identify the source of attacks and deploy defensive measures against them. Attack defense is used to identify and process malicious attack packets, addressing situations where services are affected by a large number of malicious attack packets received by the CPU. The following sections describe some common functions.

CPU Attack Defense

CPU attack defense controls packet traffic through protocol-based rate limiting and queue-based scheduling and rate limiting.

Its core mechanism is CPCAR, which sets a committed information rate (CIR) and committed burst size (CBS) for each protocol. Protocol packets exceeding the rate limit are directly discarded, ensuring that services corresponding to each protocol can be processed properly, while preventing one protocol's excessive traffic from affecting others. After protocol rate limiting, the device can assign protocols to different queues—for example, Telnet and SSH management protocols in one queue, routing protocols in another. Queues are scheduled by weight or priority, ensuring higher-priority services are more likely to be processed by the CPU. Each queue can also be rate-limited, restricting the maximum rate of packets sent from each queue to the CPU. Packets exceeding this maximum are discarded.

CPU attack defense also supports modifying CPCAR values after protocol association, and when default CPCAR values cannot meet service requirements, it supports dynamic adaptive adjustment of default CPCAR values for protocol packets.
  • Protocol association

    Protocol association protects application-layer 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 protocol association to rate-limit the transmitted packets. Typically, the CPCAR value configured for each protocol in protocol 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.

Port Attack Defense

Port attack defense is an anti-Denial of Service (DoS) method. It defends against attacks based on ports, preventing service interruptions caused by a failure to send protocol packets from normal ports to the CPU, as protocol packets from attacked ports may exhaust the bandwidth. The processing flow is as follows:

  1. The device analyzes packets by port, and counts the number of protocol packets received on the port where port attack defense is applied.
  2. The device considers a port to be under attack if the number of packets sent to the CPU in a unit time exceeds the rate threshold.
  3. After detecting an attack, the device sends a log, moves the packets received by the port within the protocol rate limit to a low-priority queue before sending them to the CPU for processing, and discards excess packets.

Port attack defense also provides whitelist, aging detection, and port attack defense event reporting functions.

  • Whitelist

    After legitimate users are added to a whitelist, their packets are not processed by the device based on port attack defense and are instead sent to the CPU for processing. A whitelist can be flexibly configured based on ACLs or ports.

  • Aging detection

    Upon detection of a port under attack, the device continuously moves attack packets on the port to low-priority queues for processing within the aging time (in seconds). When the aging time expires, the device calculates the protocol packet rate on the port again. If the rate is still above the rate threshold (meaning the attack persists), the device continues moving packets to low-priority queues. Otherwise, the device normally sends them to the CPU.

  • Port attack defense event reporting

    When a port is attacked, the device reports an event to the administrators so they can take appropriate measures to protect the device.

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 impacts services. To address this issue, you can configure user-level rate limiting, which identifies users based on MAC addresses.

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 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 processing flow 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 and threshold detection: The device counts the number of received protocol packets based on IP addresses, MAC addresses, or port information. If the number of received protocol packets exceeds the threshold, the device determines that the packets are attack packets.
  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 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

A device with attack defense enabled analyzes and detects the content of packets sent to the CPU to determine whether the packets have attack characteristics. If the packets are attack packets, the device takes defense measures on these packets based on the configuration before rate-limiting all 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
    A malformed packet attack is a type of attack in which malformed IP packets are sent to a target device, causing the device to encounter an error or even crash when processing such packets and ultimately impacting services running on the device. Defense against malformed packet attacks enables a device to detect and discard malformed packets in real time to protect the device. The following table lists the types of malformed packet attacks.
    Table 1-1 Malformed packet attack types

    Attack Type

    Characteristics

    Identification Criteria

    Flood attack from IP null payload packets

    An IP null payload packet has only a 20-byte IP header, and no data section.

    The data section of an IP packet is missing.

    Attack from IGMP null payload packets

    A normal IGMP packet consists of a 20-byte IP header and an 8-byte data part, equating to a total length of 28 bytes. An IGMP null payload packet, on the other hand, consists of less than 28 bytes.

    The total length of an IGMP packet is less than 28 bytes.

    LAND attack

    A Local Area Network Denial (LAND) attacker targets the defects in the three-way handshake mechanism of TCP, sending a SYN packet in which both the source and destination addresses are the target host's address and the source and destination ports are the same. After receiving the SYN packet, the target host creates a null TCP connection by using its own address as both the source and destination addresses, and retains this connection until it times out, wasting network resources or even crashing the system.

    The source and destination addresses or source and destination ports of TCP SYN packets are the same.

    Smurf attack

    An attacker sends an ICMP Request packet with a source address as the target host's address and a destination address as the broadcast address of the target network. As such, all hosts on the target network receive the ICMP Request packet, after which they send ICMP Reply packets to the target host. This inevitably leads to the target host receiving an excessive number of packets, consuming excessive resources or even crashing the system or network.

    The destination address of an ICMP Request packet is a broadcast address or subnet broadcast address.

    Attack from packets with invalid TCP flag bits

    A TCP packet contains six flag bits: URG, ACK, PSH, RST, SYN, and FIN.

    • If the six flag bits are all 1s, the attack is a Christmas tree attack.
    • An attacker sends a TCP packet in which SYN and FIN are 1 to a target host. If the receiving interface is disabled, the receiver replies with an RST | ACK message. If the receiving interface is enabled, the receiver replies with an SYN | ACK message. Such an attack is used to detect whether a host is online or offline and whether an interface is enabled or disabled.
    • An attacker sends a TCP packet in which the six flag bits are all 0s to a target host. If the receiving interface is disabled, the receiver replies with an RST | ACK message, which can be used by the attacker to detect whether the host is online or offline. If the receiving interface is enabled, the target host does not respond if running Linux or UNIX but replies with an RST | ACK message if running Windows. This attack is used to detect the type of operating system on the target host.

    The flag bits of a TCP packet meet one of the following conditions:

    • The six flag bits are all 1s.
    • Both SYN and FIN are 1.
    • The six flag bits are all 0s.
  • 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 number 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.
    • 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, 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 a large number 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
    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
      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 device sends an ICMP Echo Request message to a target device.
    2. Upon receiving the ICMP Echo Request message, the target device sends an ICMP Echo Reply message to the source device.
    If the target device receives many ICMP Echo Request messages from an attacker, it becomes occupied and unable to process other data packets. As a result, normal services are affected.
    ICMP flood attack
    ICMP flood attack

    With defense against ICMP flood attacks enabled, the device rate-limits ICMP messages. When the number of ICMP messages received by the target device per second exceeds the rate limit, the device discards excess ICMP messages to ensure that resources are not exhausted when the device is attacked.

About This Topic
  • Author: Yin Rongrong, Meng Xianhai
  • Updated on: 2026-10-13
  • Views: 10571
  • Average rating:
Share link to