Attack Defense for S Series Switches
|
Contents 1 Attack Processing for S Series Switches 1 Attack Processing for S Series Switches1.1 Attack Defense OverviewOn networks, there are many risks that may cause overload on the control plane. For example, a large number of viruses and hacker tools are flooded on networks. These viruses and hacker tools may attack network devices, resulting in network breakdown. Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) attacks are often initiated. Attackers use viruses and hacker tools to preempt resources of attacked devices, causing service interruption on the attacked devices. If switches respond to ICMP and ARP packets unconditionally, the CPU usage becomes high when the switches are attacked by viruses. Signaling protocols on the control plane may fail or even switches fail to respond to valid ARP Request packets. Consequently, the switches may break down, causing service interruption. To solve the preceding problem, switches provide security functions and the functions are increasingly optimized. As a main security function on switches, the central processor committed access rate (CPCAR) function allows switches to classify packets sent to the control plane, limit the rate of these packets, and schedule the packets in queues to ensure security of the control plane. Figure 1-1 shows the local attack defense process. The forwarding plane and control plane of the device are protected on hardware and software. Figure 1-1 Local attack defense
Local attack defense is implemented based on the following levels: l Level 1: The ASIC identifies packets sent to the control plane and limits the rate of or discards packets. The attack defense methods include the CPCAR, blacklist, access control list (ACL), and traffic suppression. l Level 2: The ASIC adjusts and shapes various protocol packets using queues. The attack defense methods include the protocol queue adjustment, CPU interface rate limiting, and CPU queue rate limiting (fixed switches). l Level 3: The RISC processor limits the rate of various protocol packets, configures anti-spoofing functions, and identifies the attack source using auto-defend. This level is located on the control plane. The attack defense methods include protocol security, ARP anti-spoofing, attack source identification in auto-defend, and traffic rate limiting. 1.2 Determining the Attack TypeWhen a switch is attacked, the following problems may occur: l Users cannot obtain ARP information. l Users connected to the switch can hardly get online. l Some users cannot access the network. l If the problem is severe, all users connected to the switch cannot access the network. When the preceding situations occur on many users or all users connected to an interface, check whether an attack occurs. Step 1 Run the display cpu-usage command to check the CUP usage on the switch, which is specified by the CPU Usage field. The TaskName field indicates the name of a task that is running. <HUAWEI> display cpu-usage If the CPU usage is continuously high and the CPU usage of the bcmRX, FTS, SOCK, or VPR task is high (typically caused by an attack of a specified type of protocol packets), the switch may receive a large number of packets. Then go to step 2 to check the protocol packet type.
A switch is considered running normally if its long-term average CPU usage does not exceed 80% and its highest temporary CPU usage does not exceed 95%. Step 2 Run the display cpu-defend statistics all command to check whether a large number of protocol packets are discarded and whether the CPCAR value of a specified protocol is increased on the live network. If a large number of packets of a specified protocol are discarded because the rate of these protocol packets exceeds the CPCAR value, an attack has been initiated on the live network. Take attack defense measures based on the type of the discarded protocol packets. Table 1-1 lists the possibly discarded protocol packets. <HUAWEI> display cpu-defend statistics all Table 1-1 Possibly discarded protocol packets and attack types
Switches running V200R003 and later versions support port attack defense. Even if the value of Drop does not increase, attacks may still exist on these switches. Therefore, go to step 3 to further check the type of discarded protocol packets for switches running V200R003 and later versions. Step 3 Use either of the following methods to check the type of discarded protocol packets. Method 1: Run the display auto-port-defend statistics [ slot slot-id ] command in the diagnostic view to check whether protocol packets of a specified type are discarded. Table 1-2 lists the possibly discarded protocol packets. [HUAWEI-diagnose] display auto-port-defend statistics Table 1-2 Possibly discarded protocol packets and attack types
Method 2: Check logs for a port attack. In the log, AttackProtocol indicates the protocol type of attack packets. SECE/4/PORT_ATTACK_OCCUR:Auto port-defend started.(SourceAttackInterface=[STRING], AttackProtocol=[STRING]) SECE/6/PORT_ATTACK_END:Auto port-defend stop.(SourceAttackInterface=[STRING], AttackProtocol=[STRING]) ----End 1.3 Defense Measures for Different Types of Attacks1.3.1 ARP Attack1.3.1.1 ARP FloodAttack Overview In the following figure, LAN users access the Internet by connecting to the gateway through SwitchA and SwitchB. If a large number of ARP packets are forwarded on the network, the CPU of the gateway is overloaded and cannot process other services. If the ARP packets consume a lot of bandwidth, network congestion may occur, affecting network communication.
Symptom l The CPU usage of a network device is high. User devices cannot learn ARP entries and cannot access the network. l A ping fails. l Network devices cannot be managed. Troubleshooting Roadmap
Step 1 Run the display arp command to check whether the affected users learn ARP entries properly. If the value of MAC ADDRESS is displayed as Incomplete, the users do not learn ARP entries. This may be caused by an ARP attack. Go to the next step. <HUAWEI> display arp Step 2 Run the display cpu-defend statistics packet-type arp-request all command to view statistics on ARP Request packets sent to the CPU. The following command output shows that a large number of ARP Request packets are discarded on the card in slot 4. <HUAWEI> display cpu-defend statistics packet-type arp-request all
This command can be executed multiple times, for example, at an interval of 1 second. If the Drop(Packets) counter increases fast, for example, an increment of 100 per second, the switch is undergoing an ARP attack. When the rate of ARP packets exceeds the CPCAR settings on the switch, the attack packets may occupy resources of valid ARP packets. As a result, the switch fails to learn some ARP entries. Step 3 Identify the attack source by the attack source tracing function. Create an attack defense policy policy1 in the system view. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. Run the display auto-defend attack-source slot 4 command to view the MAC address of the attack source. <HUAWEI> display auto-defend attack-source slot 4
The MAC address of the gateway or the connected network device should be excluded from the suspicious attack sources. ----End Root Cause 1. A terminal is infected with viruses and sends a large number of ARP packets. 2. A loop occurs on the network attached to the gateway. As a result, a large number of ARP packets are sent. Procedure Step 1 Configure ARP entry limiting on interfaces. The S series switches support ARP entry limiting on interfaces. If the number of ARP entries learnt by an interface exceeds the maximum value, the system stops learning new ARP entries, and does not delete the learned ARP entries. Instead, the system prompts you to delete the excess ARP entries. The configuration commands are as follows: <HUAWEI> system-view Step 2 Suppress the rate of ARP packets with a specified source IP address. If the number of ARP packets with a specified source IP address received by a switch in a period exceeds the specified threshold, the switch does not process the excess ARP Request packets. <HUAWEI> system-view
By default, the rate of ARP packets is limited to 5 pps through timestamp-based suppression. That is, five ARP packets are processed per second. Step 3 Add the MAC address of the attack source to a blacklist to filter out ARP packets sent from the attack source. [HUAWEI] acl 4444 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. Step 4 If the problem persists, for example, if a user connected to an access device sends the ARP packets with different source MAC or IP addresses, configure a rate limiting policy on the access device to prevent users connected to the access device from affecting the network. [HUAWEI] acl 4445 ----End 1.3.1.2 ARP SpoofingAttack Overview In Figure 1-2, LAN users access the Internet by connecting to the gateway through the switch. Figure 1-2 Networking of ARP spoofing
After UserA, UserB, and UserC go online and exchange ARP packets, the users and gateway generate corresponding ARP entries. If an attacker initiates an attack by sending bogus ARP packets in the broadcast domain, the gateway or UserA, UserB, and UserC will modify their ARP entries. In this situation, the attacker can easily obtain information about UserA, UserB, and UserC or prevent them from accessing the Internet. Symptom LAN users are frequently disconnected from the network. Network devices are out of management, and the gateway prints a large number of address conflict alarms. Troubleshooting Roadmap
l When the ARP packets sent by a bogus gateway pass the switch that functions as a gateway, the packets are sent to the CPU of the switch. The switch can detect the gateway collision and record a log. Run the display logbuffer command to view log information. The log is as follows. MacAddress indicates the MAC address of the attacker. ARP/4/ARP_DUPLICATE_IPADDR:Received an ARP packet with a duplicate IP address from the interface. (IpAddress=[IPADDR], InterfaceName=[STRING], MacAddress=[STRING]) Search the MAC address table according to the recorded attacker's MAC address for the port connected to the attacker. Check the network to find out the attack source and whether a terminal is infected by a virus. l If the ARP packets sent by a bogus gateway do not pass the switch that functions as a gateway, but are directly forwarded to user devices, check the downstream network. For example, use a packet parser (such as Wireshark) to parse ARP Response packets sent by the gateway. If the parsed MAC address is not the gateway's MAC address, a terminal is attacked and this parsed MAC address is the attacker's MAC address. Root Cause 1. A terminal is affected by a virus. 2. The attacker sets the host address to the gateway's address. Procedure
l Method 1: Configure a blacklist to filter packets with the attacker's MAC address (this operation must have the customer's permission). [HUAWEI] acl 4444 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. l Method 2: Add the attacker's MAC address to a blackhole MAC address entry to prevent the attacker from going online. [HUAWEI] mac-address blackhole 1-1-1 vlan 3 l Configure the gateway anti-collision function on the switch that functions as a gateway. After this function is configured, the switch generates an ARP attack defense entry to discard the packets with the same source MAC address, preventing the ARP packets sent by the bogus gateway from being broadcast in the VLAN. [HUAWEI] arp anti-attack gateway-duplicate enable 1.3.2 ARP Miss Attack1.3.2.1 Network Scanning AttackAttack Overview When a switch forwards a Layer 3 packet, if the destination address of the packet is directly connected to the switch and no ARP entry matching the destination address exists on the switch, an ARP Miss packet is triggered. The switch sends an ARP Request packet to the destination address of the Layer 3 packet. After the ARP entry is learned, the switch directly forwards the Layer 3 packet to the correct destination address. Network segment scanning triggers generation of a large number of ARP Miss packets. As a result, the system is busy processing ARP Miss packets and cannot process other services, suffering a scanning attack. Symptom When a switch suffers an ARP Miss attack, the CPU usage of the switch is high and a large number of temporary ARP entries are generated on the switch. ARP Miss packets are discarded by CPCAR, there is a delay in response to the ping operation, or the ping fails. Some user devices are disconnected, user's network access speed is slow, or the switch is out of management. Troubleshooting Roadmap
1. Clear statistics on the ARP Miss packets sent to the CPU. <HUAWEI> reset cpu-defend statistics packet-type arp-miss all 2. Wait for one minute and view statistics on the ARP Miss packets sent to the CPU again. <HUAWEI> display cpu-defend statistics packet-type arp-miss slot 2 View the number of passing and discarded packets. If the number of discarded packets is greater than the number of passing packets, an ARP Miss attack may occur. 3. Check whether a large number of temporary ARP entries are generated on the switch. If the value of MAC ADDRESS is Incomplete in 15 or more temporary entries, an ARP Miss attack occurs. <HUAWEI> display arp all Root Cause A switch receives a large number of ARP Miss packets commonly for the following reasons: 1. A network scanning attack occurs. You can obtain packets or run the display arp anti-attack arpmiss-record-info command to view the attack source. 2. The switch receives TC packets and then ages out ARP entries. For details about the measures for defending against an ARP Miss attack caused by TC messages, see 1.3.8 TC Attack. Procedure
l Decrease the CPCAR value for ARP Miss packets to resolve the high CPU usage problem. <HUAWEI> system-view This method cannot resolve the problem that users' network access speed is slow. l Increase the aging time of fake ARP entries to resolve the high CPU usage problem. When an IP packet triggers the generation of an ARP Miss packet, the switch sends an ARP Request packet and generates a temporary ARP entry. The switch then directly discards the data packets destined for this IP address to protect the CPU. When the switch receives an ARP Response packet, it modifies the temporary ARP entry. If the switch does not receive an ARP Response packet within the specified period, it deletes the temporary entry. The later packets from this IP address can still trigger the generation of ARP Miss packets. <HUAWEI> system-view A long fake entry aging time will cause a delay in ARP entry learning and loss of data packets. l Configure source IP address-based ARP Miss rate limiting. The switch will automatically identify the source IP address from which the packet rate exceeds the limit and deliver an ACL. By default, the ARP Miss suppression limit for all source IP addresses is 30 pps, and the punishment time is 5 seconds. It is recommended to allow packets from the network-side device to pass, preventing it from being punished. <HUAWEI> system-view Run the display arp anti-attack arpmiss-record-info command to view the attack source. [HUAWEI] display arp anti-attack arpmiss-record-info The switch will automatically deliver an ACL to match the ARP Miss packets from the specified source IP address. If these packets do not need to be sent to the control plane, run the cpu-defend policy command with a blacklist configured to block the attack source. 1.3.3 DHCP Attack1.3.3.1 Bogus DHCP Server AttackAttack Overview Due to the lack of an authentication mechanism between DHCP servers and clients, a DHCP server newly configured on a network can allocate IP addresses and other network parameters to DHCP clients. If the allocated IP addresses and network parameters are incorrect, network services may be interrupted. In Figure 1-3, authorized and unauthorized DHCP servers can receive DHCP Discover packets broadcast by DHCP clients. Figure 1-3 DHCP client sending DHCP Discover packets
If a bogus DHCP server sends a fake response packet including an incorrect gateway address, domain name system (DNS) server, and IP address to a DHCP client, as shown in Figure 1-4, the DHCP client cannot obtain the correct IP address and required information. Authorized users then fail to access the network and user information security is affected. Figure 1-4 Bogus DHCP server attack
Symptom DHCP clients cannot obtain correct IP addresses and thereby cannot access the network. Troubleshooting Roadmap Defense against bogus DHCP server attacks is typically configured during service deployment, instead of in the case of those attacks. If such a bogus DHCP server attack occurs, you can check DHCP information on the clients to locate the cause. Root Cause A DHCP client broadcasts DHCP Request packets to DHCP servers to obtain an IP address. As shown in Figure 1-4, a bogus DHCP server intercepts the DHCP Request packet sent from the client and allocate an IP address to the client. Procedure
Method 1: Configure DHCP snooping to control the exchange of DHCP Request and Response packets. This function prevents bogus DHCP servers from allocating IP addresses and other configurations to DHCP clients. l Configure DHCP snooping globally. <HUAWEI> system-view l Configure DHCP snooping on the user-side interface. [HUAWEI] interface GigabitEthernet 8/0/1 l Configure the interface connected to the DHCP server as a trusted interface. [HUAWEI] interface GigabitEthernet 8/0/10 Method 2: DHCP snooping prevents bogus DHCP server attacks by controlling the forwarding of DHCP packets. You can also configure traffic policies to achieve the same purpose. Forward DHCP Request packets only to trusted interfaces, and allow only the trusted interfaces to receive and forward DHCP Response packets. 1. Configure an ACL to match DHCP Response packets. [HUAWEI] acl 3001 Configure two traffic policies. One is for discarding DHCP Response packets and applied to a VLAN. The other is for allowing DHCP Response packets to be forwarded and applied to the interface that connects to the DHCP server. The traffic policy applied to the interface has a higher priority than that applied to the VLAN, so that the interface can receive and forward DHCP Response packets sent from the DHCP server. [HUAWEI] traffic classifier bootpc_dest 2. The following configurations are optional. Configure an ACL to match DHCP Request packets. [HUAWEI] acl 3000 Configure two traffic policies. One is for discarding DHCP Request packets and applied to a VLAN. The other is for allowing DHCP Request packets to be forwarded and applied to the interface that connects to the DHCP server. The traffic policy applied to the interface has a higher priority than that applied to the VLAN, so that DHCP Request packets can only be sent to the DHCP server. [HUAWEI] traffic classifier bootpc_src 1.3.3.2 DHCP Flooding AttackAttack Overview A flooding attack is also called a Denial of Service (DoS) attack. It aims to occupy resources of a device by sending numerous connection requests. As a result, the device cannot provide functions properly or even crash. DoS attacks target a server, making the server deny requests of authorized users. Symptom When the DHCP snooping, DHCP relay, or DHCP server service is deployed on a switch, the CPU usage of the switch is high and users' network access speed is slow. Troubleshooting Roadmap
1. Run the display cpu-usage command to view the task running status to find out the task with high CPU occupation. If a switch receives DoS attack packets, the CPU occupation of the bcmRX, FTS, or SOCK task may be high. <HUAWEI> display cpu-usage 2. Run the display cpu-defend statistics command to view statistics on the packets received by the CPU. Check whether many DHCP protocol packets are discarded based on CPCAR values of the dhcp-server, dhcp-client, dhcpv6-request, and dhcpv6-reply packet types. <HUAWEI> display cpu-defend statistics slot 2 3. View packet statistics on port attack defense to check whether DHCP protocol packets are lost. V200R003 and later versions support port attack defense. [HUAWEI-diagnose] display auto-port-defend statistics Check whether many packets of a protocol are received according to statistics on the tasks and CPU. Check the networking to determine whether the protocol packets are valid. If not, these packets may be attack packets. 4. The source IP or MAC addresses of many DoS attack sources are fixed. Deploy attack source tracing (enabled by default in V200R009 and later versions) to check whether an attack is initiated. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. Wait for 1 minute and check whether an attack source is detected. <HUAWEI> display auto-defend attack-source detail 5. Based on the DHCP function enabled on the switch, run the display dhcp packet process statistics command to check whether the number of corresponding packets increases rapidly. [HUAWEI-diagnose] display dhcp packet process statistics Root Cause A DoS attack of DHCP packets is mainly caused by the following reasons: 1. A user terminal is infected with a virus. 2. A network loop occurs. Procedure
l Method 1: Configure attack source tracing to punish the attacker. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. l Method 2: Configure rate limiting for DHCP packets. Configure the function of checking the rate of sending DHCP packets to the processing unit in the system view, VLAN view, or interface view. The following uses the configuration in the VLAN view as an example: [HUAWEI] vlan 10 1.3.3.3 DHCP Server DoS AttackAttack Overview In Figure 1-5, if many attackers request IP addresses on if1, IP addresses in the IP address pool of the DHCP server are exhausted, and there are no IP addresses for authorized users. A DHCP server identifies the MAC addresses of clients based on the client hardware address (CHADDR) field in DHCP Request packets. If an attacker continuously applies for IP addresses by changing the CHADDR field, IP addresses in the address pool on the DHCP server may be exhausted. As a result, authorized users cannot obtain IP addresses. Figure 1-5 DHCP server DoS attack
Symptom The IP address pool on the DHCP server is exhausted and users cannot obtain IP addresses. Troubleshooting Roadmap
1. Run the display ip pool command to view address pool usage information on the DHCP server. Check whether MAC addresses in the address pool change gradually. If so, a DHCP server DoS attack may occur because valid users are unlikely to have MAC addresses that change gradually. <HUAWEI> display ip pool interface vlanif2050 used 2. If DHCP snooping is configured on the access device, check whether there are many users in a VLAN or on an interface and whether these users' MAC addresses change gradually. <HUAWEI> display dhcp snooping user-bind all Root Cause A user terminal is infected with a virus. Procedure To prevent malicious use of IP addresses, limit the number of DHCP snooping binding entries that can be learned by an interface so as to control the number of online users. When the number of online users reaches the specified limit, no user can obtain IP addresses through this interface. To prevent attackers from applying for IP addresses by sending DHCP Request packets with variable CHADDR values, configure the switch to check whether the CHADDR field matches the source MAC address in the header of a DHCP Request packet. If they are the same, the switch forwards the DHCP Request packet. If they are different, the switch discards the DHCP Request packet.
l Set the maximum number of DHCP snooping binding entries that can be learned by the DHCP server in the interface, VLAN, or system view. [HUAWEI] dhcp enable l Enable the CHADDR field check and alarm functions in the interface, VLAN, or system view. [HUAWEI] dhcp enable 1.3.3.4 DHCP Packets Incorrectly Sent to the CPUAttack Overview After the DHCP function is enabled, DHCP packets are sent to the CPU by a specified interface or all interfaces. Therefore, some unnecessary DHCP packets are sent to the CPU, resulting in high CPU usage or affecting the DHCP service. Symptom When DHCP packets are incorrectly sent to the CPU, the following problems occur: 1. The CPU usage is high. 2. The bandwidth or resources for processing normal DHCP packets are occupied, and users cannot go online or offline properly. Troubleshooting Roadmap 1. Configure an ACL to match DHCP packets. [HUAWEI] acl 3000 2. Run the capture-packet cpu command to capture the packets sent to the CPU. If DHCP packets are captured and the VLAN to which these packets belong does not have the DHCP service enabled, the DHCP packets are incorrectly sent to the CPU. [HUAWEI] capture-packet cpu acl 3000 destination terminal packet-num 10 Root Cause DHCP packets are sent to the CPU by a specified interface or all interfaces. Therefore, some unnecessary DHCP packets in certain VLANs are sent to the CPU. Procedure
l Method 1: Enable transparent transmission of protocol packets in the VLANs that do not process the protocol packets. In this way, protocol packets in these VLANs are transparently forwarded to other devices and will not be sent to the CPU, improving forwarding efficiency. Packets of the following protocols support transparent transmission: CFM, ARP, BFD, DHCPv4, DHCPv6, HTTP, IGMP, MLD, ND, PIM, PIMv6, PPPoE, and TACACS. [HUAWEI] vlan 10 l Method 2: If DHCP packets are incorrectly sent to the CPU due to the DHCP snooping function, disable DHCP snooping and configure a traffic policy. In this way, DHCP packets will not be incorrectly sent to the CPU and the CPU usage will be reduced. For details about how to configure a traffic policy, see 1.3.3.1 Bogus DHCP Server Attack. 1.3.3.5 DHCP SpoofingAttack Overview On a DHCP network, if attackers pretend authorized users to send DHCP Request packets to the DHCP server to renew IP addresses, the IP addresses cannot be reclaimed and other authorized users cannot obtain IP addresses. Symptom A user is disconnected unexpectedly. Troubleshooting Roadmap If a DHCP spoofing attack occurs, enable the function of checking DHCP packets against the DHCP snooping binding table and the DHCP snooping alarm function. Root Cause A user terminal is affected by a virus or attacked. Procedure Enable the function of checking DHCP packets against the DHCP snooping binding table and the DHCP snooping alarm function in the system, VLAN, or interface view. The following uses the configuration in the interface view as an example. [HUAWEI] dhcp enable 1.3.4 ICMP AttackAttack Overview Some switches are located at the core layer on the live network and function as gateways. A gateway responds to ICMP packets from authorized users. The processing capability of the CPU is limited, so the CPU can process a limited number of ICMP packets in a specified period. Attackers use software or control hosts to send a large number of ICMP packets to the gateway. If the attack lasts for a long period, the CPU usage of the gateway becomes high and the gateway discards excess ICMP packets. The gateway cannot identify which ICMP packets need to be discarded or processed. In this case, authorized users may fail to communicate with the gateway and get offline. Symptom 1. When many ping tests are performed using tools for network scanning or other methods, a switch receives a large number of ICMP packets and forwards them to the CPU. As a result, the CPU usage is high and other service functions are affected. 2. A user-side device sends ICMP packets of a specified long length to perform ping tests. The rate of ICMP packets may exceed the CPCAR value set on the switch. As a result, packet loss occurs in the ping tests. Troubleshooting Roadmap
1. Run the display cpu-defend statistics packet-type icmp all command to check whether ICMP packets are lost because they exceed the CPCAR and whether the number of lost ICMP packets increases. <HUAWEI> display cpu-defend statistics packet-type icmp all 2. Check whether rate limiting is configured for ICMP packets on the switch. If the icmp rate-limit enable configuration exists, ICMP packets may be lost. <HUAWEI> display current-configuration | include icmp 3. Check whether packets are lost due to an ICMP flood packet. <HUAWEI> display anti-attack statistics Root Cause 1. A large number of ICMP packets are sent to the CPU due to an ICMP attack, resulting in high CPU usage. 2. Ping packets are lost due to the ICMP anti-attack or CPCAR configuration. Procedure
l When the CPU usage is high, configure a blacklist to filter ICMP packets. a. Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the ping packets sent to the CPU. For example, when the capture-packet cpu command is used to obtain the ping packets sent to the CPU, the source and destination IP addresses of these packets are 172.22.189.62 and 172.22.189.61, respectively. In the following command output, ac 16 bd 3e indicates the source IP address, which can be converted into 172.22.189.62 in dotted decimal notation. ac 16 bd 3d indicates the destination IP address, which can be converted into 172.22.189.61 in dotted decimal notation. [HUAWEI] acl 3333 b. After identifying the attack source, configure a blacklist to filter out excess ICMP packets, preventing high CPU usage and ensuring normal processing of ping packets. [HUAWEI] acl number 3334 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. l If the CPU usage is not high but ping packets are lost, adjust the CPCAR value for ICMP packets. Generally, the CPCAR is set to 256. If packet loss still occurs while the CPU usage is not high, set the CPCAR value greater than 256. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. 1.3.5 TTL AttackAttack Overview The value of the time to live (TTL) field in an IP packet decreases by 1 each time the IP packet is forwarded by a device. When a switch receives a large number of packets with the TTL value less than or equal to 1 within a short period, a network loop may occur. As a result, IP packets cannot be forwarded. Symptom Some Layer 3 traffic fails to be forwarded and the CPU usage of the switch is high. Troubleshooting Roadmap
Run the display cpu-defend statistics packet-type ttl-expired all command to check whether TTL-expired packets are lost because they exceed the CPCAR and whether the number of lost TTL-expired packets increases. <HUAWEI> display cpu-defend statistics packet-type ttl-expired all Root Cause If a network loop occurs, a switch receives a large number of TTL-expired packets. Procedure l If the CPU usage is high, decrease the CPCAR value for TTL-expired packets to reduce the packets sent to the CPU. If TTL-expired packets cannot be forwarded, the configuration will not affect other services. Generally, the CPCAR of TTL-expired packets sent to the CPU is set to 32 kbit/s. If packet loss still occurs but the CPU usage is not high, set the CPCAR value less than 32. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. l The route is unreachable. a. Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the TTL-expired packets sent to the CPU. For example, when the capture-packet cpu command is used to obtain the TTL-expired packets sent to the CPU, the destination IP address of these packets is 222.228.240.4. In the following command output, de e4 f0 04 indicates the destination IP address, which can be converted into 222.228.240.4 in dotted decimal notation. [HUAWEI] acl 3333 b. After identifying the attack source, run the display ip routing-table 222.228.240.4 command to view the routing table. Identify the next hops, determine the device that fails to forward packets, and adjust the route. [HUAWEI] display ip routing-table 222.228.240.4 1.3.6 TCP AttackAttack Overview The TCP SYN attack takes advantage of the vulnerability of three-way handshakes of TCP. During the three-way handshakes of TCP, a receiver sends a SYN+ACK packet to the sender after receiving an initial SYN packet from the sender. When the receiver is waiting for the final ACK packet from the sender, the connection is in half-connected mode. If the receiver fails to receive the ACK packet, it resends a SYN+ACK packet to the sender. If the sender does not return any ACK packet after the receiver retransmits several SYN+ACK packets, the receiver closes the session and refreshes sessions in the memory. The process of transmitting the first SYN+ACK packet to closing the session takes about 30s. During this period, an attacker may send hundreds of thousands of SYN packets to open interfaces and does not respond to the SYN+ACK packet from the receiver. The memory of the receiver is overloaded so it cannot accept any new connection requests; then, the receiver disconnects all active connections. To process TCP SYN attacks, TCP SYN flood attack defense must be enabled on the device and a rate limit must be configured for TCP SYN packets, so that resources of the attacked device are not exhausted. In addition, a hacker may attack the user network with the worm virus through TCP/UDP ports, threatening a large number of users on the user network. Symptom 1. The resource usage, such as CPU and memory usage of a device is high when the device is attacked by a large number of TCP packets. Besides, FTP, SSH, Telnet, and other services using the TCP connections may be affected. The device may fail to be managed. 2. The device forwards IP packets from any TCP/UDP port by default. If a hacker initiates virus attacks through TCP/UDP ports, data of a large number of users will lose. The following table lists high-risk ports frequently used by some well-known viruses.
Troubleshooting Roadmap
1. Run the display cpu-defend statistics packet-type tcp all command to check whether TCP packets are lost because they exceed the CPCAR and whether the number of lost TCP packets increases. <HUAWEI> display cpu-defend statistics packet-type tcp all 2. Run the display tcp status command to check whether the status of many TCP connections is Syn_Rcvd. <HUAWEI> display tcp status Root Cause A TCP connection can be established after three-way handshakes. The large number of TCP connections in half-connected mode occupy many system resources, which affect protocols using TCP for connection establishment. Normal running of services is affected. Procedure l If the resource usage, such as CPU and memory usage of a device is high, FTP, SSH, Telnet, and other services using the TCP connections may be affected. There is a probability that the device cannot be managed. To solve this problem, perform the following steps: a. Configure attack detection on TCP SYN flood attacks. <HUAWEI> system-view b. If the resource usage is high, reduce the CPCAR for TCP packets. Generally, the CPCAR is set to 256. If packet loss still occurs but the device CPU usage is not high, set the CPCAR value greater than 256. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. c. Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the TCP packets sent to the CPU. For example, when the capture-packet cpu command is used to obtain the ping packets sent to the CPU, the source and destination IP addresses of these packets are 172.22.189.62 and 172.22.189.61, respectively. In the following command output, ac 16 bd 3e indicates the source IP address, which can be converted into 172.22.189.62 in dotted decimal notation. ac 16 bd 3d indicates the destination IP address, which can be converted into 172.22.189.61 in dotted decimal notation. [HUAWEI] acl 3333 d. After identifying the attack source, configure a blacklist to filter out useless TCP packets. [HUAWEI] acl number 3334 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. l If hackers take advantage of TCP/UDP port vulnerabilities to initiate virus attacks, data of a large number of users will lose. To solve this problem, perform the following steps: a. Create ACL rules for high-risk ports. [HUAWEI] acl number 3000 //Create an ACL numbered 3000 to 4000, which must not be in use. b. Configure a traffic policy. [HUAWEI] traffic classifier deny-bingdu c. Apply the traffic policy to an interface, interface group, or in the system view. n Apply the traffic policy to an interface. [HUAWEI] interface GigabitEthernet0/0/1 n Apply the traffic policy in the system view. [HUAWEI] traffic-policy deny-bingdu global inbound n Apply the traffic policy to an interface group. In this way, you do not need to apply the traffic policy to multiple interfaces repeatedly. [HUAWEI] port-group deny-bingdu
1. Before the configuration, check whether these high-risk ports provide other services normally. Application of the commands may affect normal use of these services. 2. It is recommended that you configure commands in this section on the core and aggregation switches. If any computer on the intranet is infected with viruses, you need to configure these commands on the access switches to which the computers connect. 3. You are advised to apply the traffic policy to all interfaces. Alternatively, apply the traffic policy in the system view or uplink interfaces. 4. The traffic-policy command can be configured in the system view or on an interface only once. If a traffic policy already exists in the system view or on the interface, the configuration fails. You can add the classifier deny-bingdu behavior deny-bingdu command to the traffic policy. 1.3.7 OSPF AttackAttack Overview OSPF neighbors periodically send Hello packets to maintain neighbor relationships. The rate at which a device sends OSPF packets to the CPU is limited. If a device receives too many OSPF packets, it cannot normally send OSPF Hello packets to the CPU, causing OSPF neighbor flapping. Symptom OSPF routes are unreachable. As a result, Layer 3 service traffic cannot be forwarded. Troubleshooting Roadmap
1. Run the display logbuffer command to check whether the log contains OSPF neighbor flapping information. Feb 15 2017 21:40:20+08:00 HUAWEI %%01OSPF/3/NBR_CHG_DOWN(l)[131]:Neighbor event:neighbor state changed to Down. Feb 15 2017 21:40:20+08:00 HUAWEI %%01OSPF/3/NBR_DOWN_REASON(l)[132]:Neighbor state leaves full or changed to Down. 2. Run the display cpu-defend statistics packet-type ospf all command to check whether OSPF packets are lost because they exceed the CPCAR and whether the number of lost OSPF packets increases. <HUAWEI> display cpu-defend statistics packet-type ospf all Root Cause A loop is detected on the network or there are too many OSPF neighbors, so the device is attacked by a large number of OSPF packets. Procedure Step 1 Run the display cpu-defend statistics packet-type ospf all command to check whether OSPF packets are lost because they exceed the CPCAR and whether the number of lost OSPF packets increases. If the device receives a large number of OSPF packets within a short period of time, check for Layer 2 loops. Step 2 If the default CPCAR does not meet the requirements because there are too many OSPF neighbors, adjust the CPCAR value. Generally, the CPCAR is set to 384. If packet loss still occurs but the device CPU usage is not high, set the CPCAR value greater than 384. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. Step 3 Configure the OSPF sham hello function. This function allows the device to maintain neighbor relationships through not only Hello packets but also all OSPF protocol packets. This prevents OSPF neighbor flapping caused by loss of OSPF Hello packets. <HUAWEI> system-view Step 4 Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the OSPF packets sent to the CPU. For example, when the capture-packet cpu command is used to obtain the OSPF packets sent to the CPU, the source IP address of these packets is 172.22.189.62. In the following command output, ac 16 bd 3e indicates the source IP address, which can be converted into 172.22.189.62 in dotted decimal notation. [HUAWEI] acl 3333 Step 5 After identifying the attack source, configure a blacklist to filter out useless OSPF packets. [HUAWEI] acl number 2001 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. ----End 1.3.8 TC AttackAttack Overview After a device receives a TC packet, it instructs the ARP module to age or delete ARP entries. In this case, the device needs to perform ARP learning to obtain the latest ARP entries. However, if the network topology changes frequently or network devices contain many ARP entries, ARP re-learning will lead to excessive ARP packets on the network. Symptom Packets are lost, or traffic cannot be forwarded. Troubleshooting Roadmap
1. Run the display stp tc-bpdu statistics command to check the number of sent and received TC packets on interfaces. Run this command multiple times and view the values under TC(Send/Receive) increase. <HUAWEI> display stp tc-bpdu statistics 2. Run the display arp command to check whether the device has many (hundreds of) ARP entries. Run the display cpu-defend statistics command to check whether many ARP packets sent to the CPU are lost. <HUAWEI> display arp <HUAWEI> display cpu-defend statistics slot 1 Root Cause TC packet attacks lead to frequent update of ARP entries. As a result, packets are lost, or traffic cannot be forwarded. Procedure Disable the device from responding to TC packets and configure the MAC address triggered ARP entry update function. After that, the device does not age out or delete ARP entries when receiving TC packets. <HUAWEI> system-view 1.3.9 SSH/Telnet AttackAttack Overview The rate at which a device sends SSH/Telnet packets to the CPU is limited. When the device is attacked by unauthorized users or too many users log in to the device simultaneously through SSH/Telnet, the device may fail to be managed. Symptom Users fail to log in to the device. Troubleshooting Roadmap
Run the display cpu-defend statistics packet-type ssh all command to check whether SSH packets are lost because they exceed the CPCAR and whether the number of lost SSH packets increases. <HUAWEI> display cpu-defend statistics packet-type ssh all Run the display cpu-defend statistics packet-type telnet all command to check whether Telnet packets are lost because they exceed the CPCAR and whether the number of lost Telnet packets increases. <HUAWEI> display cpu-defend statistics packet-type telnet all Root Cause Attacks from unauthorized users make authorized users fail to log in to the device through SSH/Telnet. Procedure 1. Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the SSH/Telnet packets sent to the CPU. For example, when the capture-packet cpu command is used to obtain the SSH/Telnet packets sent to the CPU, the source and destination IP addresses of these packets are 172.22.189.62 and 172.22.189.61. Check whether a large number of SSH/Telnet packets are sent to the CPU from the fixed source IP address. In the following command output, ac 16 bd 3e indicates the source IP address, which can be converted into 172.22.189.62 in dotted decimal notation. ac 16 bd 3d indicates the destination IP address, which can be converted into 172.22.189.61 in dotted decimal notation. [HUAWEI] acl 3333 2. After identifying the attack source, configure security policies to control user login. The following is a configuration example: [HUAWEI] acl number 3334 1.3.10 VRRP AttackAttack Overview The master switch in a VRRP group periodically sends VRRP Advertisement packets to other switches to notify them of its normal status. When a backup switch receives too many VRRP protocol packets, the CPU of the backup switch cannot normally process VRRP Advertisement packets. The rate at which a switch sends VRRP protocol packets to the CPU is limited. When the switch receives too many VRRP protocol packets, the VRRP protocol may encounter status flapping. Symptom Packet loss occurs during forwarding of Layer 3 service traffic. Troubleshooting Roadmap
1. Run the display trapbuffer command to check whether the trap contains VRRP protocol status flapping information. #Jan 26 2017 22:00:12+09:00 HUAWEI VRRP/2/VRRPCHANGETOMASTER:OID 1.3.6.1.2.1.68.0.1 The status of VRRP changed to master. (VrrpIfIndex=118, VrId=254, IfIndex=118, IPAddress=10.62.3.251, NodeName=ISJPTSIO01HU106, IfName=Vlanif500, ChangeReason=protocol timer expired) 2. Run the display cpu-defend statistics packet-type vrrp all command to check whether VRRP protocol packets are lost because they exceed the CPCAR and whether the number of lost VRRP protocol packets increases. <HUAWEI> display cpu-defend statistics packet-type vrrp all Root Cause When a loop is detected on a network or the remote device sends VRRP packets at a high frequency, the device is attacked by a large number of VRRP packets. Procedure Step 1 Run the display cpu-defend statistics packet-type vrrp all command to check whether VRRP protocol packets are lost because they exceed the CPCAR and whether the number of lost VRRP protocol packets increases. If the device receives a large number of VRRP protocol packets within a short period of time, check for Layer 2 loops. Step 2 If the default CPCAR does not meet the requirements because there are too many VRRP groups, adjust the CPCAR value. Generally, the CPCAR is set to 256. If packet loss still occurs but the device CPU usage is not high, set the CPCAR value greater than 256. [HUAWEI] cpu-defend policy policy1 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. Step 3 Identify the attack source. In V100R006C05, use the mirroring function to obtain packets and then use a packet parser such as Wireshark to parse the obtained packets. In versions later than V100R006C05, run the capture-packet cpu command to obtain the VRRP packets sent to the CPU. For example, when the capture-packet cpu command is used to obtain the VRRP packets sent to the CPU, the source IP address of these packets is 10.249.63.52. In the following command output, 0a f9 3f 34 indicates the source IP address, which can be converted into 10.249.63.52 in dotted decimal notation. [HUAWEI] acl 3333 Step 4 After identifying the attack source, configure a blacklist to filter out useless VRRP packets. [HUAWEI] acl number 2001 Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy. ----End 1.3.11 IGMP AttackAttack Overview The rate at which a device sends IGMP packets to the CPU is limited. If a device receives too many IGMP packets, it might lead to IGMP multicast protocol flapping. As a result, Layer 2 or Layer 3 multicast service traffic cannot be normally forwarded. Symptom After a device is attacked by multicast IGMP packets, the device screen flickers or goes black intermittently when transmitting multicast services. The following symptoms may occur on the device: 1. The CPU-defense statistics include the Drop count of IGMP protocol packets. 2. Layer 2 IGMP-Snooping entries or Layer 3 IGMP multicast forwarding entries on the device are Up for a short period of time and are prone to be aged incorrectly. 3. The CPU usage is high, with BCMRX, FTS, SNPG, and MFIB tasks consuming many CPU resources. Troubleshooting Roadmap
l View CPU defense statistics. Check whether IGMP packets are lost because they exceed the CPCAR and whether the number of lost IGMP packets increases. <HUAWEI> display cpu-defend statistics packet-type igmp all l View attack source information. A switch calculates the rate of protocol packets restricted by port attack defense on a port. If the packet rate exceeds the threshold (60 pps per line card), the switch considers that an attack occurs. Then the switch traces the source and limits the rate of attack packets on the port, and records a log. Sep 11 2015 15:38:13+01:00 DST Switch %%01SECE/4/PORT_ATTACK_OCCUR(l)[2]:Auto port-defend started.(SourceAttackInterface=GigabitEthernet1/0/38, AttackProtocol=IGMP) The device adds the packets within the rate threshold (similar to the CPCAR for protocol packets in attack defense policies) to the low-priority queue, and then sends them to the CPU. The device discards the excess packets. <HUAWEI> display auto-port-defend attack-source slot 1 l Check the Up time of multicast forwarding entries. Check the Up time of Layer 2 multicast forwarding entries. <HUAWEI> display igmp-snooping port-info verbose Check the Up time of Layer 3 multicast forwarding entries. <HUAWEI> display igmp group l Check multicast protocol packet statistics. Check the counts of various Layer 2 multicast protocol packets. <HUAWEI> display igmp-snooping statistics vlan 3990 Check the counts of various Layer 3 multicast protocol packets. <HUAWEI> display igmp control-message counters Root Cause The Layer 2 or Layer 3 multicast function is enabled on a switch on the network. In versions earlier than V200R0010, the switch may incorrectly send IGMP protocol packets from all VLANs including those VLANs not running the multicast service. Additionally, one or multiple ports on the switch may receive a large number of IGMP protocol packets due to factors such as system configuration, network environment, and connected device. These protocol packets are replicated into multiple copies and forwarded by software, which also result in a high CPU usage. Procedure
l Configure intra-VLAN transparent transmission of protocol packets. Application scenario: A large number of IGMP packets from a VLAN not running the multicast service are incorrectly sent to the CPU. Applicable model: HI series fixed and modular switches Method: Enable transparent transmission of protocol packets in the VLANs that do not process the protocol packets. In this way, protocol packets in these VLANs are transparently forwarded to other devices and will not be sent to the CPU, improving forwarding efficiency. Packets of the following protocols support transparent transmission: CFM, ARP, BFD, DHCPv4, DHCPv6, HTTP, IGMP, MLD, ND, PIM, PIMv6, PPPoE, and TACACS. Precautions: 1. Before running the protocol-transparent command, ensure that IGMP/MLD Snooping is disabled in the VLAN; otherwise, the configuration fails. 2. After the protocol-transparent command is executed in a VLAN, the switch does not participate in protocol calculation in this VLAN. Commands: [HUAWE] vlan 3999 l Drop unnecessary protocol packets by configuring a traffic policy to redirect the packets to a nonexistent VLAN. Applicable scenario: Multicast protocol packets of only one VLAN need to be sent to the CPU, and multicast protocol packets in other VLANs are all unnecessary. Applicable model: modular switches Method: Drop IGMP protocol packets from all VLANs except a specified VLAN. Precautions: Multiple traffic classifiers and traffic behaviors need to be configured, leading to complex configuration. Only modular switches support this method. Commands: The following example commands enable the switch to drop IGMP packets from all VLANs except VLAN 3990. [HUAWEI] acl number 3100 // This ACL number cannot conflict with the existing ACL numbers on the switch. l Configure attack source tracing to drop IGMP attack packets. Applicable scenario: A port receives a large number of IGMP attack packets. Applicable model: all Method: Enable a switch to trace the source of a specified type of packets sent to the CPU. Precautions: If you do not want IGMP packets from certain VLANs to be dropped, configure a whitelist to exclude them from attack source tracing. Commands: [HUAWEI] cpu-defend policy test Apply the attack defense policy. For details, see 3.1 Applying the Attack Defense Policy. l Configure a blacklist to drop Leave packets. Applicable scenario: A port sends a large number of IGMP Leave packets to the CPU. Applicable model: modular switches, S5720HI fixed switches, EI and HI series fixed switches running V200R008 and later versions Method: Configure a blacklist to drop a specified type of Leave packets sent to the CPU. Precautions: It is recommended that you configure a blacklist only for IGMPv2 Leave packets. Commands: [HUAWEI] acl number 3000 Apply the attack defense policy. For details, see 3.1 Applying the Attack Defense Policy. 1.3.12 PIM AttackAttack Overview The rate at which a device sends PIM packets to the CPU is limited. If a device receives too many PIM packets, it might lead to PIM route flapping or PIM neighbor flapping. As a result, Layer 3 multicast service traffic cannot be normally forwarded. Symptom After a device is attacked by multicast PIM packets, the device screen flickers or goes black intermittently when transmitting multicast services. The following symptoms may occur on the device: 1. The CPU defense statistics include the Drop count of PIM protocol packets. 2. Layer 3 multicast forwarding entries on the device are Up for a short period of time and are prone to be aged incorrectly, leading to forwarding exceptions of Layer 3 multicast traffic. 3. The CPU usage is high, with BCMRX, FTS, MFIB, and MCSW tasks consuming many CPU resources. Troubleshooting Roadmap
l View CPU defense statistics. Run the display cpu-defend statistics packet-type pim all command to check whether PIM packets are lost because they exceed the CPCAR and whether the number of lost PIM packets increases. <HUAWEI> display cpu-defend statistics packet-type pim all l Check the Up time of multicast forwarding entries. Run the display pim routing-table fsm command to check the Up time of multicast forwarding entries on each outbound interface. <HUAWEI> display pim routing-table 239.253.92.83 fsm l Check PIM protocol packet statistics. Run the display pim control-message counters command to check the PIM protocol packet statistics. <HUAWEI> display pim control-message counters Root Cause The Layer 3 multicast function is enabled on a switch on the network, and the switch is interconnected to many Layer 3 PIM neighbors. When there are a large number of multicast group entries on the network, or the network is attacked by a large number of PIM protocol packets: 1. If the PIM-SM protocol is configured, the switch will receive a large number of PIM Join packets from multiple interfaces simultaneously. The rate exceeds the default CPCAR value for PIM protocol packets. 2. If the PIM-DM protocol is configured, the switch will receive a large number of PIM State-Refresh packets from multiple interfaces simultaneously. The rate exceeds the default CPCAR value for PIM protocol packets. 3. If the PIM-SM/DM protocol is configured, the switch will receive a large number of PIM attack packets from a specified interface or multiple interfaces. The rate exceeds the default CPCAR value for PIM protocol packets. Procedure Step 1 Set the CPCAR value for PIM protocol packets to a larger value to improve the PIM packet processing capability of the switch. It is recommended that the CIR do not exceed 512 kbit/s. Modify the CPCAR value as follows: 1. Run the cpu-defend policy and then car packet-type pim cir cir-value commands to set a new CIR. <HUAWEI> system-view Apply the attack defense policy. For details, see 3.1 Applying the Attack Defense Policy. Step 2 If the PIM-DM protocol is configured and a large number of PIM State-Refresh packets are transmitted on the network, modify the interval at which the switch sends PIM State-Refresh packets or change the PIM-DM protocol to PIM-SM. The operations are as follows: 1. Modify the interval at which the switch sends PIM State-Refresh packets. Set the interval for sending State-Refresh packets on the device directly connected to a multicast source. [HUAWEI] pim Set the minimum duration before new PIM State-Refresh packets are received on all devices. [HUAWEI] pim 2. Change the PIM-DM protocol to PIM-SM. Pay attention to the following points: − PIM-DM and PIM-SM cannot be configured simultaneously in a VPN instance or the public network instance. − It is recommended that you enable PIM-SM on all interfaces in a PIM-SM domain to ensure that the interfaces can establish neighbor relationships with all connected PIM devices. − If PIM-SM and IGMP need to be enabled on the same interface, enable PIM-SM, and then enable IGMP. ----End
2 Recommended Local Attack Defense Configuration2.1 Modular SwitchesScenario Overview On a live network, there are various types of attacks and the attack type is constantly changing. Therefore, a fixed protection method is unable to defend against all attacks. Instead, protection methods should be adjusted based on the actual scenario. The following provides a widely used attack defense script and attack detection mode to defend against TTL, TCP, ARP, DHCP, and IGMP attacks. After the attack type is determined, the attack defense configuration can be modified according to section 1.3 Defense Measures for Different Types of Attacks. Script Deployment # Deploy the attack defense script on the MPU. cpu-defend policy main-board # Deploy the attack defense script on the LPU. cpu-defend policy io-board Precaution 1. This script applies to V200R008 and earlier versions. In V200R009 and later versions, attack source tracing is enabled by default, and there is no need to deploy this script separately. 2. The TCP CPCAR limits the rate at which local VLANIF or loopback interfaces send packets to the CPU. The rate for other routing protocol packets, such as BGP is not affected by the TCP CPCAR. 3. The ttl-expired parameter is valid for the tracert function only. The rate limit for routing protocol packets containing the TTL field is determined by the CPCAR for each type of routing protocols, but not affected by the ttl-expired parameter. 4. If the customer has modified the cpu-defend policy command, configuration in this script should not conflict with the customer configuration. 2.2 Fixed SwitchesScenario Overview On a live network, there are various types of attacks and the attack type is constantly changing. Therefore, a fixed protection method is unable to defend against all attacks. Instead, protection methods should be adjusted based on the actual scenario. The following provides a widely used attack defense script and attack detection mode to defend against TTL, TCP, ARP, and DHCP attacks. After the attack type is determined, the attack defense configuration can be modified according to section 1.3 Defense Measures for Different Types of Attacks. Script Deployment cpu-defend policy io-board Precaution 1. This script applies to V200R008 and earlier versions. In V200R009 and later versions, attack source tracing is enabled by default, and there is no need to deploy this script separately. 2. The TCP CPCAR limits the rate at which local VLANIF or loopback interfaces send packets to the CPU. The rate for other routing protocol packets, such as BGP is not affected by the TCP CPCAR. 3. The ttl-expired parameter is valid for the tracert function only. The rate limit for routing protocol packets containing the TTL field is determined by the CPCAR for each type of routing protocols, but not affected by the ttl-expired parameter. 4. If the customer has modified the cpu-defend policy command, configuration in this script should not conflict with the customer configuration.
3 Appendix3.1 Applying the Attack Defense Policyl Modular switches Both MPUs and LPUs have their own CPUs. Local attack defense policies are configured differentially for MPUs and LPUs. Before creating and applying attack defense policies, check attack information on the MPUs and LPUs. If the attack information on the MPUs and LPUs is consistent, apply the same attack defense policy to the MPUs and LPUs; otherwise, apply different policies to them. a. Apply an attack defense policy to an MPU. <HUAWEI> system-view b. Apply an attack defense policy to an LPU.
If an attack defense policy has been applied to all LPUs, it cannot be applied to the specified LPU. In a similar manner, if an attack defense policy has been applied to a specified LPU, it cannot be applied to all LPUs. n If all LPUs process similar services, apply an attack defense policy to all LPUs. <HUAWEI> system-view n If LPUs process different services, apply an attack defense policy to the specified LPU. <HUAWEI> system-view l Fixed switches − Apply an attack defense policy to a stand-alone switch. <HUAWEI> system-view − In a stack: n Apply an attack defense policy to the master switch. <HUAWEI> system-view n Apply an attack defense policy to all stacked switches. <HUAWEI> system-view |
Favorite (2)
ReplyHot Group
Members:9595 Posts:9360
Members:2501 Posts:11275
Members:14004 Posts:4898
Members:1125 Posts:14720
Members:4641 Posts:1596