This post highlights the Attack Defense for S series switches as part of the All About Switches section. Please have a look below for more details.
Contents
1 Attack Processing for S Series Switches
1.1 Attack Defense Overview
1.2Determining the Attack Type
1.3 Defense Measures for Different Types of Attacks
1.3.1 ARP Attack
1.3.1.1 ARP Flood
1.3.1.2 ARP Spoofing
1.3.2 ARP Miss Attack
1.3.2.1 Network Scanning Attack
1.3.3 DHCP Attack
1.3.3.1 Bogus DHCP Server Attack
1.3.3.2 DHCP Flooding Attack
1.3.3.3 DHCP Server DoS Attack
1.3.3.4 DHCP Packets Incorrectly Sent to the CPU
1.3.3.5 DHCP Spoofing
1.3.4 ICMP Attack
1.3.5 TTL Attack
1.3.6 TCP Attack
1.3.7 OSPF Attack
1.3.8 TC Attack
1.3.9SSH/Telnet Attack
1.3.10 VRRP Attack
1.3.11 IGMP Attack
1.3.12 PIM Attack
2 Recommended Local Attack Defense Configuration
2.1 Modular Switches
2.2 Fixed Switches
3 A Appendix
3.1 Applying the Attack Defense Policy
1 Attack Processing for S Series Switches
1.1 Attack Defense Overview
On 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: Identify packets to be sent to the control plane, limit the rate of packets, or discard packets. The attack defense methods include the CPCAR, blacklist, access control list (ACL), and traffic suppression.
l Level 2: Adjust and shape 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: Limit the rate of various protocol packets, use anti-spoofing functions, and identify attack sources using auto-defend. This level is located on the control plane. The attack defense methods include protocol security, ARP anti-spoofing, attack source tracing, and traffic rate limiting.
1.2 Determining the Attack Type
When a switch is attacked, the following problems may occur:
l Users cannot obtain ARP information.
l The CPU usage of the switch is high.
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 Usagefield. The TaskName field indicates the name of a task that is running.
<HUAWEI> display cpu-usage
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage
: 11% Max: 94%
CPU Usage Stat. Time : 2017-06-19 15:18:54
CPU utilization for five seconds: 11%: one minute: 11%: five minutes:
11%
Max CPU Usage Stat. Time : 2017-06-06 06:57.
TaskName CPU Runtime(CPU
Tick High/Tick Low) Task
Explanation
VIDL
89%
e/eb7733fe DOPRA IDLE
OS
8%
1/57529fff Operation System
bcmRX
20% 0/
17a14c bcmRX
FTS
20% 0/
ff707 FTS
SOCK
20% 0/
26ac89 SOCKPacket sched
ule and process
VPR
0% 0/
16e3600 VPR VP Receive
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 allcommand 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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
arp-mff
0
0 -
0
0
arp-miss
0
0 -
0
0
arp-reply
0
0 -
0
0
arp-request
8423
1284 2017-06-06 06:57
...
Table 1-1 Possibly discarded protocol packets and attack types
Packet Type | Attack Type |
arp-reply, arp-request | 1.3.1 ARP Attack, 1.3.8 TC Attack |
arp-miss | 1.3.2 ARP Miss Attack |
dhcp-client, dhcp-server, dhcpv6-reply, dhcpv6-request | 1.3.3 DHCP Attack |
icmp | 1.3.4 ICMP Attack |
ttl-expired | 1.3.5 TTL Attack |
tcp | 1.3.6 TCP Attack |
ospf | 1.3.7 OSPF Attack |
ssh, telnet | 1.3.9 SSH/Telnet Attack |
vrrp | 1.3.10 VRRP Attack |
igmp | 1.3.11 IGMP Attack |
pim | 1.3.12 PIM Attack |
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
Statistics on MPU:
--------------------------------------------------------------------------------
Protocol Vlan Queue Cir(Kbps)
Pass(Packet/Byte) Drop(Packet/Byte)
--------------------------------------------------------------------------------
arp-request NA 2
256
0
0
NA
NA
arp-reply NA 2
256
0
0
NA
NA
dhcp NA
2 1024
0 0
NA
NA
igmp NA
2 768
0
0
NA
NA
icmp NA
2 256
23095
3
NA
NA
--------------------------------------------------------------------------------
Table 1-2 Possibly discarded protocol packets and attack types
Protocol | Attack Type |
arp-reply, arp-request | 1.3.1 ARP Attack, 1.3.8 TC Attack |
arp-miss | 1.3.2 ARP Miss Attack |
dhcp-client, dhcp-server, dhcpv6-reply, dhcpv6-request | 1.3.3 DHCP Attack |
icmp | 1.3.4 ICMP Attack |
ttl-expired | 1.3.5 TTL Attack |
tcp | 1.3.6 TCP Attack |
ospf | 1.3.7 OSPF Attack |
ssh, telnet | 1.3.9 SSH/Telnet Attack |
vrrp | 1.3.10 VRRP Attack |
igmp | 1.3.11 IGMP Attack |
pim | 1.3.12 PIM Attack |
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 Attacks
1.3.1 ARP Attack
1.3.1.1 ARP Flood
Attack 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
Fault Location Method | Command | Models and Versions |
View temporary ARP entries. | display arp | V100R006C05 and later versions |
View statistics on ARP Request packets. | display cpu-defend statistics packet-type arp-request all | V100R006C05 and later versions |
View the attack source tracing result. | display auto-defend attack-source [ slot slot-id ] | V200R003 and later versions |
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
IP ADDRESS MAC ADDRESS
EXPIRE(M) TYPE INTERFACE
VPN-INSTANCE
VLAN/CEVLAN
------------------------------------------------------------------------------------------------------
10.137.222.139
00e0-fc01-4422
I - Eth0/0/0
50.1.1.3
Incomplete
1
D-0 GE5/0/0
500/-
50.1.1.2
Incomplete
1
D-0 GE5/0/0
500/-
6.1.1.2
00e0-fc01-4422
I - Vlanif6
10.0.0.139
00e0-fc01-4422
I - Vlanif10
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
Statistics on mainboard:
------------------------------------------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
------------------------------------------------------------------------------------------------------------------
arp-request
18265
0
4164330
0
------------------------------------------------------------------------------------------------------------------
Statistics on slot 4:
------------------------------------------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
------------------------------------------------------------------------------------------------------------------
arp-request
2132
3748 2017-06-06 06:57
272896
479744
------------------------------------------------------------------------------------------------------------------
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 policy1in the system view.
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] auto-defend enable
[HUAWEI-cpu-defend-policy-policy1] auto-defend attack-packet sample 5
[HUAWEI-cpu-defend-policy-policy1] auto-defend threshold 30
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend trace-type
source-portvlan //After the auto-defend enable command is
configured, the device traces attack sources based on the source IP address,
source MAC address, and source interface plus VLAN by default. Because the
source interface plus VLAN is not precise enough, disable attack source tracing
based on the source interface plug VLAN.
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend protocol dhcp icmp igmp
tcp telnet ttl-expired udp //After the auto-defend enable command is
configured, the device traces attack sources for many protocols by default.
Here, the device is configured to trace sources of only ARP packets in attack
source tracing. If attack source tracing is required for other protocols, do
not specify the protocols in the undo auto-defend protocol command.
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
Attack Source User Table (slot 4):
------------------------------------------------------------------------------------------------
MacAddress
InterfaceName
Vlan:Outer/Inner TOTAL
------------------------------------------------------------------------------------------------
0000-0000-0001
GigabitEthernet4/0/22
193 416
Attack Source IP Table (slot 4):
-------------------------------------
IPAddress TOTAL Packets
-------------------------------------
198.19.1.2 245
50.1.1.2 125
-------------------------------------
Total: 2
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
[HUAWEI] interface gigabitethernet 1/0/1
[HUAWEI-GigabitEthernet1/0/1] arp-limit vlan 10 maximum 20
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
[HUAWEI] arp speed-limit source-ip 10.0.0.1 maximum 50
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
[HUAWEI-acl-L2-4444] rule permit l2-protocol arp source-mac 0-0-1 vlan-id 3
[HUAWEI-acl-L2-4444] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 4444
[HUAWEI-cpu-defend-policy-policy1] quit
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
[HUAWEI-acl-L2-4445] rule permit l2-protocol arp
[HUAWEI-acl-L2-4445] quit
[HUAWEI] traffic classifier policy1
[HUAWEI-classifier-policy1] if-match acl 4445
[HUAWEI-classifier-policy1] quit
[HUAWEI] traffic behavior policy1
[HUAWEI-behavior-policy1] car cir 32
[HUAWEI-behavior-policy1] quit
[HUAWEI] traffic policy policy1
[HUAWEI-trafficpolicy-policy1] classifier policy1 behavior policy1
[HUAWEI-trafficpolicy-policy1] quit
[HUAWEI] interface GigabitEthernet 1/0/1
[HUAWEI-GigabitEthernet1/0/1] traffic-policy policy1 inbound
----End
1.3.1.2 ARP Spoofing
Attack 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
Fault Location Method | Command | Models and Versions |
View log information. | display logbuffer | V100R006C05 and later versions |
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 Reply packets sent by the gateway. If the parsed MAC address is not the gateway's, a terminal is attacked and this parsed MAC address is the attacker's MAC address. If the parsed MAC address is the gateway's but the parsed IP address is not the gateway's, the attacker simulates the gateway's MAC address to initiate an attack. In this case, MAC address flapping occurs on the access switch. Therefore, locate the attack source based on the interface on which MAC address flapping occurs.
Root Cause
1. A terminal is affected by a virus.
2. The attacker sets the host address to the gateway's address.
Procedure
Method | Advantage | Disadvantage |
Configure a blacklist. | Packets sent to the CPU are discarded based on the blacklist. | The attack source needs to be found first. |
Configure a blackhole MAC address. | All packets sent from the attack source, including those forwarded by the attack source, are discarded. | The attack source needs to be found first. |
Configure ARP gateway anti-conflict. | Packets with the same source MAC address are directly discarded. | The local device functions as a gateway. |
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
[HUAWEI-acl-L2-4444] rule permit l2-protocol arp source-mac 1-1-1
[HUAWEI-acl-L2-4444] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 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 Attack
1.3.2.1 Network Scanning Attack
Attack 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
Fault Location Method | Command | Models and Versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type arp-miss { all | slot slot-id } | V100R006C05 and later versions |
View temporary ARP entries. | display arp | V100R006C05 and later versions |
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
Statistics on slot 2:
------------------------------------------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
------------------------------------------------------------------------------------------------------------------
arp-miss
40800
357680 2017-06-06 06:57
------------------------------------------------------------------------------------------------------------------
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 Incompletein 15 or more temporary entries, an ARP Miss attack occurs.
<HUAWEI> display arp all
IP ADDRESS MAC ADDRESS
EXPIRE(M) TYPE INTERFACE
VPN-INSTANCE
VLAN/CEVLAN
------------------------------------------------------------------------------
10.137.217.202
00e0-0987-7890
I - Eth0/0/0
10.137.216.1 0000-5e00-0149
20
D-0 Eth0/0/0
10.1.1.2
00e0-0987-7899
I - GE6/1/1
10.1.20.1 00e0-0987-789a
I - GE6/1/2
10.1.10.6
00e0-0987-789b
I - GE6/1/3
10.1.11.6
00e0-0987-789c
I - GE6/1/4
192.168.11.1
00e0-0987-789c
I - Vlanif11
192.168.11.254 Incomplete 12
D-0 Eth-Trunk1
11/-
192.168.11.253 Incomplete
16
D-0 Eth-Trunk1
11/-
------------------------------------------------------------------------------
Total:9
Dynamic:3 Static:0
Interface:6
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, causing a large number of ARP Miss messages. For details about the measures for defending against an ARP Miss attack caused by TC messages, see 1.3.8 TC Attack.
Procedure
Method | Advantage | Disadvantage |
Decrease the CPCAR value for ARP Miss packets. | The number of packets sent to the CPU is decreased quickly. | Normal ARP Miss packets may be discarded. |
Set the aging time o fake ARP entries. | Packets sent to a specified destination address are suppressed, and no ARP Miss packet is triggered during the aging time. | A proper aging time must be set. |
Configure ARP Miss suppression. | Packets sent from a specified source address are suppressed, and no ARP Miss packet is sent to the CPU during the block time. | A whitelist needs to be configured to prevent the network-side device from being punished. |
Configure a blacklist to discard packets sent from a specified attack source. | The blacklist can be applied on the switch or a specified card to drop attack packets. | 1. The blacklisted source cannot access the switch after the attack is eliminated. |
l Decrease the CPCAR value for ARP Miss packets to resolve the high CPU usage problem.
<HUAWEI> system-view
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type arp-miss cir 64
[HUAWEI-cpu-defend-policy-policy1] quit
[HUAWEI] cpu-defend-policy policy1 global
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 Reply packet, it modifies the temporary ARP entry. If the switch does not receive an ARP Reply 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
[HUAWEI] interface Vlanif 500
[HUAWEI-Vlanif500] arp-fake expire-time 30 //The default aging
time of fake ARP entries is 30 seconds.
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
[HUAWEI] arp-miss speed-limit source-ip maximum 10 //The ARP Miss
rate limit for each source IP address is set to 10 pps. The default limit is 30
pps.
[HUAWEI] arp-miss speed-limit source-ip 1.1.1.1 maximum 200
//Allow packets from the network-side device to pass, preventing it from being
punished.
Run the display arp anti-attack arpmiss-record-info command to view the attack source.
[HUAWEI] display arp anti-attack
arpmiss-record-info
Interface
IP address Attack
time Block
time Aging-time
----------------------------------------------------------------------------------------------------------------
GigabitEthernet5/0/0 10.0.0.1 2017-06-06 06:57 2017-06-06 06:57 50
----------------------------------------------------------------------------------------------------------------
There are 1 records in Arp-miss table
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 Attack
1.3.3.1 Bogus DHCP Server Attack
Attack 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 allocates an IP address to the client.
Procedure
Method | Advantage | Disadvantage |
Configure DHCP snooping. | It is easy to configure and commonly used. | Packets are sent to the CPU, which may result in high CPU usage. |
Configure a traffic policy. | Packets are not sent to the CPU. | The configuration is complex and ACL resources are required. |
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
[HUAWEI] dhcp enable
[HUAWEI] dhcp snooping enable
l Configure DHCP snooping on the user-side interface. You can configure DHCP snooping on an interface or in a VLAN based on the site requirements.
[HUAWEI] interface GigabitEthernet
8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping enable
l Configure the interface connected to the DHCP server as a trusted interface.
[HUAWEI] interface GigabitEthernet
8/0/10
[HUAWEI-GigabitEthernet8/0/10] dhcp snooping trusted
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
[HUAWEI-acl-adv-3001] rule permit udp destination-port eq bootpc
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
[HUAWEI-classifier-bootpc_dest] if-match acl 3001
[HUAWEI-classifier-bootpc_dest] quit
[HUAWEI] traffic behavior deny
[HUAWEI-behavior-deny] deny
[HUAWEI-behavior-deny] quit
[HUAWEI] traffic behavior permit
[HUAWEI-behavior-permit] permit
[HUAWEI-behavior-permit] quit
[HUAWEI] traffic policy bootpc_dest_permit
[HUAWEI-trafficpolicy-bootpc_dest_permit] classifier bootpc_dest behavior
permit //Configure a traffic policy to allow DHCP Response
packets to be forwarded.
[HUAWEI-trafficpolicy-bootpc_dest_permit] quit
[HUAWEI] traffic policy bootpc_dest_deny
[HUAWEI-trafficpolicy-bootpc_dest_deny] classifier bootpc_dest behavior deny
//Configure a traffic policy to discard DHCP Response packets.
[HUAWEI-trafficpolicy-bootpc_dest_deny] quit
[HUAWEI] interface GigabitEthernet 8/0/10
[HUAWEI-GigabitEthernet8/0/10] traffic-policy bootpc_dest_permit inbound
//Apply the traffic policy with the permit behavior to the trusted interface.
[HUAWEI-GigabitEthernet8/0/10] quit
[HUAWEI] vlan 172
[HUAWEI-vlan172] traffic-policy bootpc_dest_deny inbound //Apply
the traffic policy with the deny behavior to the VLAN.
[HUAWEI-vlan172] quit
2. The following configurations are optional.
Configure an ACL to match DHCP Request packets.
[HUAWEI] acl 3000
[HUAWEI-acl-adv-3000] rule permit udp source-port eq bootpc
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
[HUAWEI-classifier-bootpc_src] if-match acl 3000
[HUAWEI-classifier-bootpc_src] quit
[HUAWEI] traffic behavior deny
[HUAWEI-behavior-deny] deny
[HUAWEI-behavior-deny] quit
[HUAWEI] traffic behavior permit
[HUAWEI-behavior-permit] permit
[HUAWEI-behavior-permit] quit
[HUAWEI] traffic policy bootpc_src_permit
[HUAWEI-trafficpolicy-bootpc_src_permit] classifier bootpc_src behavior
permit //Configure a traffic policy to allow DHCP Request
packets to be forwarded.
[HUAWEI-trafficpolicy-bootpc_src_permit] quit
[HUAWEI] traffic policy bootpc_src_deny
[HUAWEI-trafficpolicy-bootpc_src_deny] classifier bootpc_src behavior deny
//Configure a traffic policy to discard DHCP Request packets.
[HUAWEI-trafficpolicy-bootpc_src_deny] quit
[HUAWEI] interface GigabitEthernet 8/0/10
[HUAWEI-GigabitEthernet8/0/10] traffic-policy bootpc_src_permit outbound
//Apply the traffic policy with the permit behavior to the trusted interface in
the outbound direction.
[HUAWEI-GigabitEthernet8/0/10] quit
[HUAWEI] vlan 172
[HUAWEI-vlan172] traffic-policy bootpc_src_deny outbound //Apply
the traffic policy with the deny behavior to the VLAN in the outbound
direction.
[HUAWEI-vlan172] quit
1.3.3.2 DHCP Flooding Attack
Attack 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
Fault Location Method | Command | Models and Versions |
View the CPU usage. | display cpu-usage [ slave | slot slot-id ] | V100R006C05 and later versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics [ packet-type packet-type ] { all | slot slot-id | mcu } | V100R006C05 and later versions |
View port attack defense statistics. | display auto-port-defend statistics [ slot slot-id ] | V200R003 and later versions |
Configure attack source tracing. | auto-defend enable | V100R006C05 and later versions |
View information about attack source tracing. | display auto-defend attack-source detail | V100R006C05 and later versions |
View DHCP packet statistics. | display dhcp statistics | V100R006C05 and later versions |
View packet statistics on a DHCP relay agent. | display dhcp relay statistics | V100R006C05 and later versions |
View statistics on a DHCP server. | display dhcp server statistics | V100R006C05 and later versions |
View the rate limit of DHCP packets. | display dhcp packet process statistics | V100R006C05 and later versions |
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
CPU Usage Stat. Cycle: 10 (Second)
CPU Usage : 68% Max: 99%
CPU Usage Stat. Time : 2016-12-18 15:35:56
CPU utilization for five seconds: 68%: one minute: 60%: five minutes: 55%.
TaskName CPU Runtime(CPU Tick
High/Tick Low) Task Explanation
BOX
0% 0/
11ad0
BOX Output
_TIL
0%
0/
0
Infinite loop event task
_EXC
0%
0/
0
Exception Agent Task
VIDL
60%
0/e7615b10
DOPRA IDLE
TICK
0% 0/ d4afc
bcmRX
20% 0/
17a14c bcmRX
FTS
20% 0/
ff707
FTS
SOCK
20% 0/
26ac89
SOCKPacket schedule and process
2. Run the display cpu-defend statisticscommand 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
Statistics on slot 2:
-----------------------------------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
-----------------------------------------------------------------------------------------------------------
...
dhcp-client 0
0
-
0
0
dhcp-server 0
0 -
0
0
dhcpv6-reply 0
0
-
0
0
dhcpv6-request 0
0 -
...
-----------------------------------------------------------------------------------------------------------
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
Statistics on
MPU:
--------------------------------------------------------------------------------
Protocol Vlan Queue Cir(Kbps)
Pass(Packet/Byte)
Drop(Packet/Byte)
--------------------------------------------------------------------------------
arp-request NA 2
256 0 0
NA
NA
arp-reply NA 2
256
0
0
NA
NA
dhcp NA
2 1024
0
0
NA
NA
igmp NA
2 768
0
0
NA
NA
--------------------------------------------------------------------------------
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
[HUAWEI-cpu-defend-policy-policy1] auto-defend enable
[HUAWEI-cpu-defend-policy-policy1] auto-defend attack-packet sample 5
[HUAWEI-cpu-defend-policy-policy1] auto-defend threshold 30
[HUAWEI-cpu-defend-policy-policy1] auto-defend trace-type source-mac
source-ip
[HUAWEI-cpu-defend-policy-policy1] auto-defend protocol dhcp
[HUAWEI-cpu-defend-policy-policy1] quit
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
Attack Source User Table (MPU):
----------------------------------------------------
MAC Address 0000-c123-0102
Interface GigabitEthernet1/0/1
VLAN: Outer/Inner 1000
DHCP: 416
Total 416
----------------------------------------------------
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
Packet process
rate:
DHCPv4
:80
DHCPv6
:0
ND
:0
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
Method | Advantage | Disadvantage |
Configure attack source tracing. | A specific user is punished. | ACL resources are consumed. |
Configure software-based rate limiting. | Rate limiting can be configured globally, in a VLAN, or on an interface. | The CPU usage cannot be efficiently reduced. |
l Method 1: Configure attack source tracing to punish the attacker.
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] auto-defend enable
[HUAWEI-cpu-defend-policy-policy1] auto-defend attack-packet sample 5
[HUAWEI-cpu-defend-policy-policy1] auto-defend threshold 30
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend trace-type
source-portvlan
[HUAWEI-cpu-defend-policy-policy1] undo auto-defend protocol tcp ttl-expired //Enable or disable attack source sourcing for a protocol.
[HUAWEI-cpu-defend-policy-policy1] auto-defend whitelist 1 interface
GigabitEthernet 8/0/10 //Add the uplink interface to the whitelist so
that it will not be punished.
[HUAWEI-cpu-defend-policy-policy1] auto-defend action deny
[HUAWEI-cpu-defend-policy-policy1] quit
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
[HUAWEI-vlan10] dhcp snooping check dhcp-rate enable
[HUAWEI-vlan10] dhcp snooping check dhcp-rate 80
[HUAWEI-vlan10] quit
1.3.3.3 DHCP Server DoS Attack
Attack Overview
In Figure 1-5, if many attackers request IP addresses on GE1/0/1, 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
Fault Location Method | Command | Models and Versions |
Check address pool usage information. | display ip pool | V100R006C05 and later versions |
View DHCP snooping binding entries. | display dhcp snooping user-bind all | V100R006C05 and later versions |
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
Pool-name :
Vlanif2050
Pool-No :
1
Lease
: 1 Days 0 Hours 0
Minutes
Domain-name :
-
DNS-server0 :
-
NBNS-server0 :
-
Netbios-type :
-
Position :
Interface
Status
: Unlocked
Gateway-0 :
-
Network :
25.25.25.0
Mask :
255.255.255.0
VPN instance :
--
Logging : Disable
Conflicted address recycle interval:
-
Address Statistic: Total
:254
Used
:5
Idle
:249 Expired
:0
Conflict :0
Disabled :0
-------------------------------------------------------------------------------
Network
section
Start
End Total Used
Idle(Expired) Conflict Disabled
-------------------------------------------------------------------------------
25.25.25.1
25.25.25.254 254
5
249(0) 0 0
-------------------------------------------------------------------------------
Client-ID format as
follows:
DHCP :
mac-address
PPPoE :
mac-address
IPSec : user-id/portnumber/vrf
PPP : interface
index
L2TP :
cpu-slot/session-id SSL-VPN :
user-id/session-id
-------------------------------------------------------------------------------
Index
IP Client-ID
Type Left
Status
-------------------------------------------------------------------------------
117
25.25.25.2 0-0-1
DHCP 86397 Used
118
25.25.25.3 0-0-2
DHCP 86397 Used
119 25.25.25.4
0-0-3 DHCP 86397
Used
120
25.25.25.5 0-0-4
DHCP 86397 Used
121
25.25.25.6 0-0-5
DHCP 86397
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
DHCP Dynamic Bind-table:
Flags:O - outer vlan ,I - inner vlan ,P - map vlan
IP Address MAC
Address VSI/VLAN(O/I/P)
Interface
Lease
--------------------------------------------------------------------------------
16.1.28.1 0-0-1 10 /--
/-- Eth0/0/1
2016.10.17-07:31
16.1.28.2 0-0-2 10 /--
/-- Eth0/0/1
2016.10.17-07:31
16.1.28.3 0-0-3 10 /--
/-- Eth0/0/1
2016.10.17-07:31
16.1.28.4 0-0-4 10 /--
/-- Eth0/0/1
2016.10.17-07:31
--------------------------------------------------------------------------------
print count: 1 total
count:
1
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.
Method | Advantage | Disadvantage |
Limit the number of online users. | The limit can be configured globally, in a VLAN, or on an interface. | Packets are sent to the CPU. |
Enable packet validity check. | Packet validity check can be configured globally, in a VLAN, or on an interface. | Packets are sent to the CPU. This method depends on correctness of binding entries established for the first time. |
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
[HUAWEI] dhcp snooping enable //Enable DHCP snooping globally.
[HUAWEI] interface GigabitEthernet 8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping max-user-number 10
//Limit the number of DHCP users on the interface.
l Enable the CHADDR field check and alarm functions in the interface, VLAN, or system view.
[HUAWEI] dhcp enable
[HUAWEI] dhcp snooping enable //Enable DHCP snooping globally.
[HUAWEI] interface GigabitEthernet 8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping check dhcp-chaddr enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping alarm dhcp-chaddr enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping check dhcp-request enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping alarm dhcp-request enable
1.3.3.4 DHCP Packets Incorrectly Sent to the CPU
Attack 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
[HUAWEI-acl-adv-3000] rule permit udp destination-port eq bootpc
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
Method | Advantage | Disadvantage |
Configure intra-VLAN transparent transmission of protocol packets. | Protocol packets that do not need to be sent to the CPU can be transmitted transparently by VLAN. | 1. Only HI series fixed and modular switches support this function. 2. The VLANs in which DHCP packets exist must be identified first. 3. If there are many VLANs having DHCP packets, the configuration is complex. |
Configure a traffic policy, instead of DHCP snooping. | The CPU usage will be reduced. | The configuration is complex. |
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
[HUAWEI-vlan10] protocol-transparent
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 Spoofing
Attack 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
[HUAWEI] dhcp snooping enable //Enable DHCP snooping globally.
[HUAWEI] interface GigabitEthernet 8/0/1
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping enable
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping check dhcp-request enable//Check DHCP packets on the interface.
[HUAWEI-GigabitEthernet8/0/1] dhcp snooping alarm dhcp-request enable
1.3.4 ICMP Attack
Attack 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
Fault Location Method | Command | Models and Versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type icmp all | V100R006C05 and later versions |
View the rate limit for ICMP packets. | display current-configuration | include icmp | V100R006C05 and later versions |
View ICMP flood attack information. | display anti-attack statistics | V100R006C05 and later versions |
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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
icmp
371078 8620 2017-06-06 06:57
NA
NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
icmp
371078 8620 2017-06-06 06:57
178623204
4266203
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
icmp rate-limit enable
3. Check whether packets are lost due to an ICMP flood packet.
<HUAWEI> display anti-attack
statistics
Packets Statistic Information:
-------------------------------------------------------------------------------
AntiAtkType TotalPacketNum DropPacketNum PassPacketNum
(H)
(L)
(H)
(L) (H)
(L)
-------------------------------------------------------------------------------
URPF
0
0
0
0
0 0
Abnormal
0
0 0
0
0 0
Fragment
0
0
0
0
0 0
Tcp-syn
0
0
0
0
0 0
Udp-flood
0
0
0
0
0 0
Icmp-flood 0
5783
0 1347 0
4436
-------------------------------------------------------------------------------
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
Symptom | Method | Advantage | Disadvantage |
The CPU usage of the switch is high. | Configure a blacklist to filter ICMP packets. | Authorized users are not affected. | The attack source needs to be identified first. |
Ping packets are lost. | Adjust the CPCAR value for ICMP packets. | Ping tests of more users or with super large packets can be performed. | A large number of packets are sent to the CPU, resulting in high CPU usage. |
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
[HUAWEI-acl-adv-3333] rule 5 permit icmp
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb
c7
08 00 45 00 00 54 cc 56 00 00 ff 01 1c a9 ac
16
bd 3e ac 16 bd 3d 08 00 95 13 b0 99 00 01 10
75
85 d6 07 e1 06 16 50 4e 47 01 57 17 a2 16 00 01
-------------------------------------------------------
Packet: 2
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb
c7
08 00 45 00 00 54 cc 56 00 00 ff 01 1c a9 ac
16
bd 3e ac 16 bd 3d 08 00 95 13 b0 99 00 01 10
75
85 d6 07 e1 06 16 50 4e 47 01 57 17 a2 16 00 01
-------------------------------------------------------
Packet: 3
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb
c7
08 00 45 00 00 54 cc 56 00 00 ff 01 1c a9 ac
16
bd 3e ac 16 bd 3d 08 00 95 13 b0 99 00 01 10
75
85 d6 07 e1 06 16 50 4e 47 01 57 17 a2 16 00 01
-------------------------------------------------------
-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
----------------
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
[HUAWEI-acl-basic-3334] rule 5 permit icmp source 172.22.189.62 0
destination 172.22.189.61 0
[HUAWEI-acl-basic-3334] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 3334
[HUAWEI-cpu-defend-policy-policy1] quit
Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.
c. The fast ICMP reply function reduces the CPU usage on the MPU. By default, this function is enabled on fixed switches running V100R006C05 and later versions and modular switches running V200R010 and later versions. If the CPU usage on the MPU is high, enable the fast ICMP reply function.
<HUAWEI> system-view
[HUAWEI] icmp-reply fast
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
[HUAWEI-cpu-defend-policy-policy1] car packet-type icmp cir 256
[HUAWEI-cpu-defend-policy-policy1] quit
Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.
1.3.5 TTL Attack
Attack 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
Fault Location Method | Command | Models and Versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type ttl-expired all | V100R006C05 and later versions |
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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ttl-expired
1159 34050 2017-06-06 06:57
NA
NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte)
Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ttl-expired
1159 34050 2017-06-06 06:57
139344 4093755
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ttl-expired
0
0 -
0
0
--------------------------------------------------------------------------------
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
[HUAWEI-cpu-defend-policy-policy1] car packet-type ttl-expired cir 32
[HUAWEI-cpu-defend-policy-policy1] quit
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
[HUAWEI-acl-adv-3333] rule 5 permit ip ttl-expired
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
a8 ca 71 ff b0 02 84 ad 58 b5 09 02 81 00 0f ff
08 00 45 c0 00 28 ef 9d 00 00 ff 06 2d 99 de e4
f0 0a de e4 f0 04 d5 01 02 86 7d 91 98 04 24 3a
aa f2 50 10 20 00 35 b1 00 00 00 00 00 00 00 00
-------------------------------------------------------
Packet: 2
-------------------------------------------------------
a8 ca 71 ff b0 02 84 ad 58 b5 09 02 81 00 0f ff
08 00 45 c0 00 28 ef 9d 00 00 ff 06 2d 99 de e4
f0 0a de e4 f0 04 d5 01 02 86 7d 91 98 04 24 3a
aa f2 50 10 20 00 35 b1 00 00 00 00 00 00 00 00
-------------------------------------------------------
Packet: 3
-------------------------------------------------------
a8 ca 71 ff b0 02 84 ad 58 b5 09 02 81 00 0f ff
08 00 45 c0 00 28 ef 9d 00 00 ff 06 2d 99 de e4
f0 0a de e4 f0 04 d5 01 02 86 7d 91 98 04 24 3a
aa f2 50 10 20 00 35 b1 00 00 00 00 00 00 00 00
-------------------------------------------------------
-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------
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 drops packets based on the traffic statistics or captured packets, and adjust the route.
[HUAWEI] display ip
routing-table 222.228.240.4
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : Public
Summary Count : 1
Destination/Mask Proto Pre
Cost Flags
NextHop Interface
222.228.240.4/32 Direct 0
0 D
127.0.0.1 LoopBack0
1.3.6 TCP Attack
Attack 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.
Port Number | Function | Virus | Impact |
135 | DCOM and RPC services | Worm | System restart |
137 | NetBIOS service | Worm | System restart and remote control |
139 | NetBIOS session service | Rbot | System permission theft |
445 | File transfer and remote network management | Blackmail virus | Data damage |
4444 | Dynamic port | Blaster virus | System restart |
5554 | Dynamic port | Sasser virus | Virus spreading |
Troubleshooting Roadmap
Fault Location Method | Command | Models and Versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type tcp all | V100R006C05 and later versions |
View the TCP connection status. | display tcp status | V100R006C05 and later versions |
Defend against viruses taking advantage of port vulnerabilities. | Apply traffic policies to filter out packets from high-risk ports. | V100R006C05 and later versions |
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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
tcp
251484 31436 2017-06-06 06:57
NA
NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte)
Last-dropping-time
--------------------------------------------------------------------------------
tcp
251484 31436 2017-06-06 06:57
34785192
2352384
--------------------------------------------------------------------------------
2. Run the display tcp status command to check whether the status of many TCP connections is Syn_Rcvd.
<HUAWEI> display tcp status
TCPCB Tid/Soid Local
Add:port Foreign
Add:port VPNID
State
ae66b700 115/5
0.0.0.0:22
0.0.0.0:0
-1 Listening
b36882d4 115/3
0.0.0.0:23
0.0.0.0:0
-1 Listening
ae66c384 220/3
0.0.0.0:179
222.228.240.55:0 0
Listening
ae66bdf4 220/6
0.0.0.0:179
222.228.240.56:0 0
Listening
ae8ff950 115/27 192.92.42.221:23
192.192.240.128:33970 0
Established
ae66c64c 115/24 192.92.42.221:23
192.192.240.203:59438 0
Established
526d3158 286/1 192.92.42.221:60920
192.192.255.1:21 0 Syn_Rcvd
526d2bc8 223/19 222.228.240.3:646
222.228.240.4:52186 0
Established
526d3b14 223/16 222.228.240.3:646
222.228.240.9:55388 0
Established
ae8ff7ec 223/23 222.228.240.3:646
222.228.240.59:65037 0 Syn_Rcvd
ae66bb2c 220/20 222.228.240.3:53850
222.228.240.56:179 0
Established
ae8ff688 220/28 222.228.240.3:56789
222.228.240.55:179 0
Established
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. Disable the HTTP service because HTTP connection requests received on the device pose security risks. Note that the web system cannot be used after the HTTP service is disabled.
<HUAWEI> system-view
[HUAWEI] undo http server enable
[HUAWEI] undo http secure-server enable
b. Configure attack detection on TCP SYN flood attacks.
<HUAWEI> system-view
[HUAWEI] anti-attack tcp-syn enable
[HUAWEI] anti-attack tcp-syn car cir 8000
c. 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
[HUAWEI-cpu-defend-policy-policy1] car packet-type tcp cir 256
[HUAWEI-cpu-defend-policy-policy1] quit
Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.
d. 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 TCP 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
[HUAWEI-acl-adv-3333] rule 5 permit tcp
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 2c d2 05 00 00 ff 06 16 5d ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f6 00 00
00 00 60 02 20 00 14 9c 00 00 02 04 05 b4 00 00
-------------------------------------------------------
Packet: 2
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 2c d2 05 00 00 ff 06 16 5d ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f6 00 00
00 00 60 02 20 00 14 9c 00 00 02 04 05 b4 00 00
-------------------------------------------------------
Packet: 3
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 2c d2 05 00 00 ff 06 16 5d ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f6 00 00
00 00 60 02 20 00 14 9c 00 00 02 04 05 b4 00 00
-------------------------------------------------------
-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------
e. After identifying the attack source, configure a blacklist to filter out useless TCP packets.
[HUAWEI] acl number 3334
[HUAWEI-acl-adv-3334] rule 5 permit tcp source 172.22.189.62 0
[HUAWEI-acl-adv-3334] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 3334
[HUAWEI-cpu-defend-policy-policy1] quit
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 //The
ACL number ranges from 3000 to 4000 and is not used.
[HUAWEI-acl-adv-3000] rule 5 permit tcp destination-port eq 445
[HUAWEI-acl-adv-3000] rule 10 permit tcp destination-port eq 135
[HUAWEI-acl-adv-3000] rule 15 permit tcp destination-port eq 137
[HUAWEI-acl-adv-3000] rule 20 permit tcp destination-port eq 139
[HUAWEI-acl-adv-3000] rule 25 permit udp destination-port eq 445
[HUAWEI-acl-adv-3000] rule 30 permit udp destination-port eq 135
[HUAWEI-acl-adv-3000] rule 35 permit udp destination-port eq 137
[HUAWEI-acl-adv-3000] rule 40 permit udp destination-port eq 139
[HUAWEI-acl-adv-3000] quit
b. Configure a traffic policy.
[HUAWEI] traffic classifier
deny-bingdu
[HUAWEI-classifier-deny-bingdu] if-match acl 3000
[HUAWEI-classifier-deny-bingdu] quit
[HUAWEI] traffic behavior deny-bingdu
[HUAWEI-behavior-deny-bingdu] deny
[HUAWEI-behavior-deny-bingdu] quit
[HUAWEI] traffic policy deny-bingdu
[HUAWEI-trafficpolicy-deny-bingdu] classifier deny-bingdu behavior
deny-bingdu
[HUAWEI-trafficpolicy-deny-bingdu] quit
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
[HUAWEI-GigabitEthernet0/0/1] traffic-policy deny-bingdu inbound
[HUAWEI-GigabitEthernet0/0/1] traffic-policy deny-bingdu outbound
n Apply the traffic policy in the system view.
[HUAWEI] traffic-policy
deny-bingdu global inbound
[HUAWEI] traffic-policy deny-bingdu global outbound
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
[HUAWEI-port-group-deny-bingdu] group-member GigabitEthernet0/0/1 to
GigabitEthernet0/0/10
[HUAWEI-port-group-deny-bingdu] traffic-policy deny-bingdu inbound
[HUAWEI-port-group-deny-bingdu] traffic-policy deny-bingdu outbound
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 Attack
Attack 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
Fault Location Method | Command | Models and Versions |
Check whether the log contains OSPF neighbor flapping information. | display logbuffer | V100R006C05 and later versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type tcp all | V100R006C05 and later versions |
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
%OSPF/3/NBR_CHG_DOWN(l)[131]:Neighbor event:neighbor state changed to
Down.
(ProcessId=1, NeighborAddress=10.136.1.25, NeighborEvent=InactivityTimer,
NeighborPreviousState=Full, NeighborCurrentState=Down)
Feb 15 2017 21:40:20+08:00 HUAWEI
%OSPF/3/NBR_DOWN_REASON(l)[132]:Neighbor state leaves full or changed to
Down.
(ProcessId=1, NeighborRouterId=10.136.0.253, NeighborAreaId=0,
NeighborInterface=Vlanif903,NeighborDownImmediate reason=Neighbor Down Due to
Inactivity, NeighborDownPrimeReason=Hello Not Seen,
NeighborChangeTime=2017-06-06 06:57+08:00)
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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ospf
36678 48790
2017-06-06 06:57
NA
NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ospf
18265 24327 2017-06-06 06:57
4164330
5546436
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ospf
18413 24463 2017-06-06 06:57
4119574
5473151
--------------------------------------------------------------------------------
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
[HUAWEI-cpu-defend-policy-policy1] car packet-type ospf cir 384
[HUAWEI-cpu-defend-policy-policy1] quit
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
[HUAWEI] ospf 100
[HUAWEI-ospf-100] sham-hello enable
Step 4 Run the silent-interface command to disable an interface from receiving and sending OSPF packets. After the configuration, the interface cannot set up OSPF neighbor relationships, reducing OSPF packet exchanges.
<HUAWEI> system-view
[HUAWEI] ospf 100
[HUAWEI-ospf-100] silent-interface vlanif 200
Step 5 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 cpucommand 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
[HUAWEI-acl-adv-3333] rule 5 permit ip destination 224.0.0.5 0
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
01 00 5e 00 00 05 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 44 5a 39 00 00 01 59 15 0e ac 16
bd 3e e0 00 00 05 02 01 00 30 ac 11 07 c2 00 00
00 00 95 17 00 00 00 00 00 00 00 00 00 00 ff ff
-------------------------------------------------------
Packet: 2
-------------------------------------------------------
01 00 5e 00 00 05 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 44 5a 39 00 00 01 59 15 0e ac 16
bd 3e e0 00 00 05 02 01 00 30 ac 11 07 c2 00 00
00 00 95 17 00 00 00 00 00 00 00 00 00 00 ff ff
-------------------------------------------------------
Packet: 3
-------------------------------------------------------
01 00 5e 00 00 05 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 44 5a 39 00 00 01 59 15 0e ac 16
bd 3e e0 00 00 05 02 01 00 30 ac 11 07 c2 00 00
00 00 95 17 00 00 00 00 00 00 00 00 00 00 ff ff
-------------------------------------------------------
-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------
Step 6 After identifying the attack source, configure a blacklist to filter out useless OSPF packets.
[HUAWEI] acl number 2001
[HUAWEI-acl-basic-2001] rule 5 permit source 172.22.189.62 0
[HUAWEI-acl-basic-2001] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 2001
[HUAWEI-cpu-defend-policy-policy1] quit
Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.
----End
1.3.8 TC Attack
Attack 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
Fault Location Method | Command | Models and Versions |
Check whether the device generates a large number of TC packets. | display stp tc-bpdu statistics | V100R006C05 and later versions |
Check whether the device has many ARP entries. | display arp | V100R006C05 and later versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics slot slot-id | V100R006C05 and later versions |
1. Run the display stp tc-bpdu statisticscommand 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
-------------------------- STP TC/TCN information
--------------------------
MSTID
Port TC(Send/Receive) TCN(Send/Receive)
0 GigabitEthernet1/0/9 3/2 0/0
0
GigabitEthernet1/0/10 1/0
0/0
1
GigabitEthernet1/0/9 14/9
-/-
1
GigabitEthernet1/0/10 8/10
-/-
2
GigabitEthernet1/0/9 3/2
-/-
2
GigabitEthernet1/0/10 1/0 -/-
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
IP ADDRESS MAC ADDRESS
EXPIRE(M) TYPE INTERFACE
VPN-INSTANCE
VLAN/CEVLAN
------------------------------------------------------------------------------
157.101.86.2
dcd2-fcf6-e2d1
I -
Vlanif3900
157.101.86.1 643e-8c49-6101
12
D-0
XGE1/0/0
3900/-
...
157.101.86.9
dcd2-fcf6-e2db
I -
Vlanif3940
------------------------------------------------------------------------------
Total:1058
Dynamic:1053
Static:0 Interface:45
<HUAWEI> display cpu-defend
statistics slot 1
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-droppingtime
--------------------------------------------------------------------------------
arp-miss 0 0-00
arp-reply
13688251
2 2017-06-06 06:57
931881104
136
arp-request
176181433
39657 2017-06-06 06:57
11661818724 2580864
Root Cause
TC packet attacks lead to frequent update of ARP entries. As a result, packets are lost, or traffic cannot be forwarded.
Procedure
1. A device deletes MAC address entries and ARP entries after receiving TC packets. Frequent entry deletion may cause high CPU usage. To reduce the CPU usage, increase the interval for processing TC packets. For example, set the interval to 120 seconds.
<HUAWEI> system-view
[HUAWEI] stp tc-protection interval 120
2. Disable the device from responding to TC packets and configure the MAC address triggered ARP entry update function. After that, the device neither ages out nor deletes ARP entries when receiving TC packets.
<HUAWEI> system-view
[HUAWEI] mac-address update arp
[HUAWEI] arp topology-change disable
1.3.9 SSH/Telnet Attack
Attack 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. It is recommended that whitelists be used to control the users who can log in to devices, preventing bogus devices and unauthorized access.
Symptom
Users fail to log in to the device.
Troubleshooting Roadmap
Fault Location Method | Command | Models and Versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type ssh all display cpu-defend statistics packet-type telnet all | V100R006C05 and later versions |
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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ssh
159810 2739 2017-06-06 06:57
NA
NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
ssh 159810 2739 2017-06-06 06:57
13790778
207864
--------------------------------------------------------------------------------
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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
telnet
1577093 13922 2017-06-06 06:57
NA
NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
telnet
1577093
13922 2017-06-06 06:57
127671081
974564
--------------------------------------------------------------------------------
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
[HUAWEI-acl-adv-3333] rule 5 permit tcp destination-port eq 22
[HUAWEI-acl-adv-3333] rule 10 permit tcp destination-port eq telnet
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 31 d2 07 00 00 ff 06 16 56 ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f7 a6 c1
e0 42 50 18 20 00 8e 36 00 00 ff fd 01 ff fd 03
-------------------------------------------------------
Packet: 2
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 31 d2 07 00 00 ff 06 16 56 ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f7 a6 c1
e0 42 50 18 20 00 8e 36 00 00 ff fd 01 ff fd 03
-------------------------------------------------------
Packet: 3
-------------------------------------------------------
00 00 11 00 22 01 00 00 0a 88 1c d0 81 00 cb c7
08 00 45 c0 00 31 d2 07 00 00 ff 06 16 56 ac 16
bd 3e ac 16 bd 3d d3 c7 00 17 83 0c 39 f7 a6 c1
e0 42 50 18 20 00 8e 36 00 00 ff fd 01 ff fd 03
-------------------------------------------------------
-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------
2. After identifying the attack source, configure security policies to control user login. The following is a configuration example:
[HUAWEI] acl number 3334
[HUAWEI-acl-adv-3334] rule 5 permit ip source 172.22.189.62 0
[HUAWEI-acl-adv-3334] quit
[HUAWEI] aaa
[HUAWEI-aaa] local-user admin1234 password irreversible-cipher
Helloworld@6789
[HUAWEI-aaa] local-user admin1234 privilege level 3
[HUAWEI-aaa] local-user admin1234 service-type telnet
[HUAWEI-aaa] quit
[HUAWEI] user-interface maximum-vty 15
[HUAWEI] user-interface vty 0 14
[HUAWEI-ui-vty0-14] acl 3334 inbound
[HUAWEI-ui-vty0-14] authentication-mode aaa
[HUAWEI-ui-vty0-14] idle-timeout 20 0
[HUAWEI-ui-vty0-14] screen-length 0
[HUAWEI-ui-vty0-14] protocol inbound telnet
3. Disable the Telnet server function if Telnet login is not required.
<HUAWEI> system-view
[HUAWEI] undo telnet server enable
1.3.10 VRRP Attack
Attack 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
Fault Location Method | Command | Models and Versions |
Check whether the VRRP protocol encounters status flapping. | display trapbuffer | V100R006C05 and later versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type vrrp all | V100R006C05 and later versions |
1. Run the display trapbuffer command to check whether the log contains VRRP neighbor 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)
#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=124, VrId=254, IfIndex=124,
IPAddress=10.173.7.251, NodeName=ISJPTSIO01HU106, IfName=Vlanif3300,
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
Statistics on mainboard:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp
8423 1284
2017-06-06 06:57
NA
NA
--------------------------------------------------------------------------------
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp
0
0 -
0
0
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type Pass(Packet/Byte) Drop(Packet/Byte) Last-dropping-time
--------------------------------------------------------------------------------
vrrp
8413 1294 2017-06-06 06:57
1808574
277464
------------------------------------
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 of too many VRRP groups, configure an mVRRP group to reduce VRRP packet exchanges.
<HUAWEI> system-view
[HUAWEI] interface vlanif 10
[HUAWEI-Vlanif10] ip address 10.1.1.1 24
[HUAWEI-Vlanif10] vrrp vrid 1 virtual-ip 10.1.1.111
[HUAWEI-Vlanif10] admin-vrrp vrid 1
If the device CPU usage is not high, increase the CPCAR value for VRRP protocol packets.
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] car packet-type vrrp cir 256
[HUAWEI-cpu-defend-policy-policy1] quit
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 cpucommand 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
[HUAWEI-acl-adv-3333] rule 5 permit ip destination 224.0.0.18 0
[HUAWEI-acl-adv-3333] quit
[HUAWEI] capture-packet cpu acl 3333 destination terminal packet-num 3
Warning: Mirrored packets will be shown on terminal.
[HUAWEI]
Packet: 1
-------------------------------------------------------
01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 03 89
08 00 45 c0 00 28 26 10 00 00 ff 70 6a 56 0a f9
3f 34 e0 00 00 12 21 01 78 01 00 01 1c cd 0a f9
3f 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------
Packet: 2
-------------------------------------------------------
01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 03 89
08 00 45 c0 00 28 26 10 00 00 ff 70 6a 56 0a f9
3f 34 e0 00 00 12 21 01 78 01 00 01 1c cd 0a f9
3f 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------
Packet: 3
-------------------------------------------------------
01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 03 89
08 00 45 c0 00 28 26 10 00 00 ff 70 6a 56 0a f9
3f 34 e0 00 00 12 21 01 78 01 00 01 1c cd 0a f9
3f 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------
-----------------packet getting report-----------------
file: NULL
packets getting: cpu
acl: 3333
vlan: - cvlan: -
car: -- timeout: 60s
packets: 3 (expected) 3 (actual)
length: 64 (expected)
-------------------------------------------------------
Step 4 After identifying the attack source, configure a blacklist to filter out useless VRRP packets.
[HUAWEI] acl number 2001
[HUAWEI-acl-basic-2001] rule 5 permit source 10.249.63.52 0
[HUAWEI-acl-basic-2001] quit
[HUAWEI] cpu-defend policy policy1
[HUAWEI-cpu-defend-policy-policy1] blacklist 1 acl 2001
[HUAWEI-cpu-defend-policy-policy1] quit
Apply the attack defense policy policy1. For details, see 3.1 Applying the Attack Defense Policy.
----End
1.3.11 IGMP Attack
Attack 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
Fault Location Method | Command | Models and Versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type igmp all | V100R006C05 and later versions |
View attack source information. | display auto-port-defend attack-source | V200R003 and later versions |
Check the Up time of multicast forwarding entries. | display igmp group | V100R006C05 and later versions |
display igmp-snooping port-info verbose | V100R006C05 and later versions | |
Check multicast protocol packet statistics. | display igmp control-message counters | V100R006C05 and later versions |
display igmp-snooping statistics vlan | V100R006C05 and later versions |
l View statistics on packets sent to the CPU.
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
Warning: This feature is not supported on slot mainboard.
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte)
Last-dropping-time
--------------------------------------------------------------------------------
igmp
494 297619 2017-06-06 06:57
63232
38095232
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte)
Last-dropping-time
--------------------------------------------------------------------------------
igmp
0
0
-
0
0
--------------------------------------------------------------------------------
Statistics on slot 3:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte)
Last-dropping-time
--------------------------------------------------------------------------------
igmp
0
0
-
0
0
--------------------------------------------------------------------------------
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 %SECE/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
Attack source table on slot 1:
Total : 1
--------------------------------------------------------------------------------
Interface Vlan Protocol
Expire(s) PacketRate(pps)
LastAttackTime
--------------------------------------------------------------------------------
GE1/0/38 NA
igmp
299 110
2017-06-06 06:57
--------------------------------------------------------------------------------
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
The port information of Group 229.0.0.1 on VLAN 3990:
Time of this group has been up : 00:10:19
The port information of (0.0.0.0, 229.0.0.1):
Time of this source has been up : 00:10:19
Port Table on this source(0.0.0.0):
No.1
Port name : GE1/0/38
Time of this port has been
up as a host-port : 00:10:19
Remain time of port expire as
dynamic host-port : 00:02:10
Host-port flags : Dynamic
Check the Up time of Layer 3 multicast forwarding entries.
<HUAWEI> display igmp group
Interface group report information of VPN-Instance: public net
Vlanif3990(19.19.19.199):
Total 1 IGMP Group reported
Group Address Last Reporter
Uptime Expires
229.0.0.1
192.85.1.2 00:00:07 00:02:10
l Check multicast protocol packet statistics.
Check the counts of various Layer 2 multicast protocol packets.
<HUAWEI> display
igmp-snooping statistics vlan 3990
IGMP Snooping Packets Counter
Statistics for VLAN 3990
Recv V1
Report 0
Recv V2
Report 7245
Recv V3
Report 0
Recv V1
Query 0
Recv V2
Query 0
Recv V3
Query 0
Recv
Leave
0
Recv Pim
Hello 0
Send
Query(S=0) 0
Send
Query(S!=0) 0
Suppress
Report 0
Suppress
Leave 0
Proxy Send General
Query
0
Proxy Send Group-Specific
Query 0
Proxy Send Group-Source-Specific Query 0
Check the counts of various Layer 3 multicast protocol packets.
<HUAWEI> display igmp
control-message counters
Interface message counter information of VPN-Instance: public net
Vlanif3990(19.19.19.199):
Message
Type
Sent
Valid Invalid
Ignore
------------------------------------------------------------------
General
Query
3
0
0
0
Group
Query
0
0
0
0
Source Group Query
0
0
0
0
------------------------------------------------------------------
IGMPV1V2
Report ASM 0
10612 0
0
Report
SSM
0
0 0
0
------------------------------------------------------------------
LEAVE
ASM
0
0 0
0
LEAVE
SSM
0
0 0
0
------------------------------------------------------------------
IGMPV3
ISIN
Report
0
0 0
0
ISEX
Report
0
0 0
0
TOIN
Report
0
0 0
0
TOEX
Report
0
0 0
0
ALLOW Report
0
0
0
0
BLOCK
Report
0
0
0
0
Source Records Total
0
0
0
0
------------------------------------------------------------------
Others
-
-
0
0
------------------------------------------------------------------
Root Cause
The Layer 2 or Layer 3 multicast function is enabled on a switch on the network. In versions earlier than V200R010, 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
Attack Model | Method | Advantage | Disadvantage |
A VLAN not running the multicast service has a large number of IGMP packets. | Configure intra-VLAN transparent transmission of protocol packets. | Protocol packets that do not need to be sent to the CPU can be transmitted transparently by VLAN. | 1. Only HI series fixed and modular switches support this method 2. The VLANs in which IGMP packets exist must be determined first. 3. If there are many VLANs having IGMP packets, the configuration is complex. |
Drop unnecessary protocol packets by configuring a traffic policy to redirect the packets to a nonexistent VLAN. | All IGMP packets except those from a specified VLAN are discarded on port or globally. | Multiple traffic classifiers and traffic behaviors need to be configured, leading to complex configuration. Only modular switches support this method. | |
A specific port is attacked by IGMP packets of a specific type. | Configure attack source tracing to drop IGMP attack packets. | Attack source tracing can be applied on the switch or a specified card to identify and drop packets from a specified port and VLAN. | Users need to determine whether packets are attack packets according to the threshold. Packets are not dropped permanently. They are dropped only within the penalty time. |
User-side interfaces receive a large number of Leave packets. | Configure a blacklist to drop Leave packets. | The blacklist can be applied on the switch or a specified card to drop attack packets. | The CPU usage is not effectively reduced. |
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-transparentcommand, 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
[HUAWEI-vlan3999] protocol-transparent
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.
[HUAWEI-acl-adv-3100] rule 5 permit igmp // Match IGMP protocol packets.
[HUAWEI-acl-adv-3100] quit
[HUAWEI] traffic classifier igmp-permit-cvlan
[HUAWEI-classifier-igmp-permit-cvlan] if-match acl 3100
[HUAWEI-classifier-igmp-permit-cvlan] if-match cvlan-id 3990 //Allow
IGMP packets with inner VLAN ID 3990 to pass.
[HUAWEI-classifier-igmp-permit-cvlan] quit
[HUAWEI] traffic classifier igmp-permit-vlan
[HUAWEI-classifier-igmp-permit-vlan] if-match acl 3100
[HUAWEI-classifier-igmp-permit-cvlan] if-match cvlan-id 3990 //Allow
IGMP packets from VLAN 3990 to pass.
[HUAWEI-classifier-igmp-permit-vlan] quit
[HUAWEI] traffic classifier igmp-deny
[HUAWEI-classifier-igmp-deny] if-match acl 3100 //Redirect all the
other IGMP packets to a nonexistent VLAN.
[HUAWEI-classifier-igmp-deny] quit
[HUAWEI] traffic behavior igmp-deny
[HUAWEI-behavior-igmp-deny] permit
[HUAWEI-behavior-igmp-deny] remark vlan-id 4090 // Create a
VLAN not in use according to the actual situation.
[HUAWEI-behavior-igmp-deny] quit
[HUAWEI] traffic behavior igmp-permit
[HUAWEI-behavior-igmp-permit] permit
[HUAWEI-behavior-igmp-permit] remark vlan-id 3990
[HUAWEI-behavior-igmp-permit] quit
[HUAWEI] traffic policy igmp
[HUAWEI-trafficpolicy-igmp] classifier igmp-permit-cvlan behavior igmp-permit
[HUAWEI-trafficpolicy-igmp] classifier igmp-permit-vlan behavior igmp-permit
[HUAWEI-trafficpolicy-igmp] classifier igmp-deny behavior igmp-deny
[HUAWEI-trafficpolicy-igmp] quit
[HUAWEI] traffic-policy igmp global inbound //Apply
the traffic policy globally.
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
[HUAWEI-cpu-defend-policy-test] auto-port-defend enable //Enable
attack source tracing.
[HUAWEI-cpu-defend-policy-test] undo auto-defend protocol arp dhcp icmp tcp
telnet ttl-expired //Match IGMP packets.
[HUAWEI-cpu-defend-policy-test] auto-defend threshold 70 //Determine
packets whose rate exceeds 70 pps as attack packets.
[HUAWEI-cpu-defend-policy-test] auto-defend action deny timer 3600 //Drop
packets within the penalty time, which is 1 hour. (The default value is 300s.)
[HUAWEI-cpu-defend-policy-test] auto-defend trace-type source-portvlan
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
[HUAWEI-acl-adv-3000] rule 5 permit igmp destination 224.0.0.2 0 //Match
IGMP Leave packets.
[HUAWEI-acl-adv-3000] quit
[HUAWEI] cpu-defend policy test
[HUAWEI-cpu-defend-policy-test] blacklist 1 acl 3000 //Set a
blacklist.
[HUAWEI-cpu-defend-policy-test] quit
Apply the attack defense policy. For details, see 3.1 Applying the Attack Defense Policy.
1.3.12 PIM Attack
Attack 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
Fault Location Method | Command | Models and Versions |
View statistics on packets sent to the CPU. | display cpu-defend statistics packet-type pim all | V100R006C05 and later versions, which support Layer 3 multicast features |
Check the Up time of multicast forwarding entries. | display pim routing-table fsm | V100R006C05 and later versions, which support Layer 3 multicast features |
Check PIM protocol packet statistics. | display pim control-message counters | V100R006C05 and later versions, which support Layer 3 multicast features |
l View statistics on packets sent to the CPU.
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
Warning: This feature is not supported on slot mainboard.
Statistics on slot 1:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte)
Last-dropping-time
--------------------------------------------------------------------------------
pim 2132 3748 2017-06-06 06:57
272896
479744
--------------------------------------------------------------------------------
Statistics on slot 2:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte)
Last-dropping-time
--------------------------------------------------------------------------------
pim 0
0 -
0
0
--------------------------------------------------------------------------------
Statistics on slot 3:
--------------------------------------------------------------------------------
Packet Type
Pass(Packet/Byte) Drop(Packet/Byte)
Last-dropping-time
--------------------------------------------------------------------------------
pim
0
0
-
0
0
--------------------------------------------------------------------------------
l Check the Up time of multicast forwarding entries.
Run the display pim routing-table fsmcommand to check the Up time of multicast forwarding entries on each outbound interface.
<HUAWEI> display pim
routing-table 239.253.92.83 fsm
VPN-Instance: public net
Total 420 (*, G) entries; 343 (S, G) entries
Total matched 1 (*, G) entry; 1 (S, G) entry
Abbreviations for FSM states and Timers:
NI - no info, J - joined, NJ - not joined, P - pruned,
NP - not pruned, PP - prune pending, W - winner, L -
loser,
F - forwarding, AP - ack pending, DR - designated
router,
NDR - non-designated router, RCVR - downstream
receivers,
PPT - prunepending timer, GRT - graft retry timer,
OT - override timer, PLT - prune limit timer,
ET - join expiry timer, JT - join timer,
AT - assert timer, PT - prune timer
(*, 239.253.92.83)
RP: 61.55.156.51
Protocol: pim-sm, Flag: WC
UpTime: 32w:4d
Upstream interface: Vlanif323
Upstream neighbor: 10.0.4.98
RPF prime neighbor: 10.0.4.98
Join/Prune FSM: [J, JT
Expires: 00:00:08]
Downstream interface(s) information:
Total number of downstreams: 12
1: Vlanif441
Protocol: pim-sm, UpTime: 6w:6d, Expires: 00:03:29
DR
state: [NDR]
Join/Prune FSM: [J]
Assert
FSM: [NI]
2: Vlanif506
Protocol: pim-sm, UpTime: 08:37:57, Expires: 00:03:21
DR
state: [NDR]
Join/Prune FSM: [J]
Assert
FSM: [NI]
3: Vlanif330
Protocol:
pim-sm, UpTime: 08:37:58, Expires: 00:03:26
DR
state: [DR]
Join/Prune FSM: [J]
Assert
FSM: [NI]
4: Vlanif313
Protocol: pim-sm, UpTime: 14w:1d, Expires: 00:03:27
DR
state: [NDR]
Join/Prune FSM: [J]
Assert
FSM: [NI]
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
VPN-Instance: public
net
PIM global control-message
counters:
Message Type
Received
Sent
Invalid Filtered
Register
51
0
0
0
Register-Stop
0
48
0
0
Probe
44
0
0
0
C-RP 0
0
0
0
PIM control-message counters for interface: Vlanif10
Message Type
Received
Sent Invalid
Filtered
Assert
0
6
0
0
Graft
0
0
0
0
Graft-Ack
0
0
0 0
Hello 34496 34495
0
0
Join-prune 26171
90
0
0
State-Refresh
0
0
0 0
BSR
0
0
0
0
PIM control-message counters for interface: Vlanif20
Message Type Received
Sent
Invalid
Filtered
Assert
0
0
0
0
Graft
0
0
0
0
Graft-Ack
0 0
0
0
Hello
34491
34495
0
0
Join-prune
0
41
0
0
State-Refresh
0
0 0
0
BSR
0
0
0
0
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 carpacket-type pim cir cir-value commands to set a new CIR.
<HUAWEI> system-view
[HUAWEI] cpu-defend policy pim
[HUAWEI-cpu-defend-policy-pim] car packet-type pim cir 512
[HUAWEI-cpu-defend-policy-pim] quit
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
[HUAWEI-pim] state-refresh-interval interval
Set the minimum duration before new PIM State-Refresh packets are received on all devices.
[HUAWEI] pim
[HUAWEI-pim] state-refresh-rate-limit interval
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 Configuration
2.1 Modular Switches
Scenario 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
# If VLAN 1 is not used on the live network, but interfaces on the access devices and gateways are still in VLAN 1, attacks or storms may occur. Remove interfaces from VLAN 1.
l The interface type is hybrid.
interface GigabitEthernet x/x/x
undo port hybrid vlan 1
l The interface type is trunk.
interface GigabitEthernet x/x/x
port link-type trunk
undo port trunk allow-pass vlan 1
l The interface type is access.
interface GigabitEthernet x/x/x
port link-type access
undo port default vlan 1
# Deploy the attack defense script on the MPU.
cpu-defend policy main-board
# Create the attack defense policy main-board.
car packet-type ttl-expired cir 16 # Set the CIR value to for TTL-expired
packets 16 kbit/s.
car packet-type tcp cir
32 # Set the CIR value to
for TCP packets 32 kbit/s.
auto-defend
enable
# Enable attack source tracing.
auto-defend attack-packet sample 5 # Set the packet sampling ratio for
attack source tracing to 5.
auto-defend threshold
30 # Set the
checking threshold for attack source tracing to 30 pps.
undo auto-defend trace-type source-portvlan # Configure attack
source tracing based on the source MAC address and source IP address.
undo auto-defend protocol tcp telnet ttl-expired # Delete TCP, Telnet, and
TTL-expired packets from the list of traced packets in attack source tracing.
auto-defend whitelist 1 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for attack
source tracing.
auto-defend whitelist 2 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for attack
source tracing.
auto-port-defend whitelist 1 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for port attack
defense. By default, port attack defense is enabled in V200R003 and later
versions.
auto-port-defend whitelist 2 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for port
attack defense. By default, port attack defense is enabled in V200R003 and
later versions.
cpu-defend-policy main-board # Apply the
attack defense policy.
# Deploy the attack defense script on the LPU.
cpu-defend policy
io-board # Create the
attack defense policy io-board.
car packet-type ttl-expired cir 8 # Set the CIR value to for
TTL-expired packets 8 kbit/s.
car packet-type tcp cir
16 # Set the CIR value to
for TCP packets 16 kbit/s.
auto-defend
enable
# Enable attack source tracing.
auto-defend attack-packet sample 5 # Set the packet sampling ratio for
attack source tracing to 5.
auto-defend threshold
30 # Set the
checking threshold for attack source tracing to 30 pps.
undo auto-defend trace-type source-portvlan # Configure attack
source tracing based on the source MAC address and source IP address.
undo auto-defend protocol tcp telnet ttl-expired # Delete TCP, Telnet,
and TTL-expired packets from the list of traced packets in attack source
tracing.
auto-defend whitelist 1 interface GigabitEthernet x/x/x # Add
the interconnection interface and upstream interface to the whitelist for
attack source tracing.
auto-defend whitelist 2 interface GigabitEthernet x/x/x # Add
the interconnection interface and upstream interface to the whitelist for
attack source tracing.
auto-port-defend whitelist 1 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for port
attack defense. By default, port attack defense is enabled in V200R003 and
later versions.
auto-port-defend whitelist 2 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for port
attack defense. By default, port attack defense is enabled in V200R003 and
later versions.
cpu-defend-policy io-board global # Apply the attack defense policy.
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 Switches
Scenario 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
# If VLAN 1 is not used on the live network, but interfaces on the access devices and gateways are still in VLAN 1, attacks or storms may occur. Remove interfaces from VLAN 1.
l The interface type is hybrid.
interface GigabitEthernet x/x/x
undo port hybrid vlan 1
l The interface type is trunk.
interface GigabitEthernet x/x/x
port link-type trunk
undo port trunk allow-pass vlan 1
l The interface type is access.
interface GigabitEthernet x/x/x
port link-type access
undo port default vlan 1
# Deploy the attack defense script on a switch.
cpu-defend policy
io-board # Create
the attack defense policy io-board.
car packet-type ttl-expired cir 8 # Set the CIR value to for
TTL-expired packets 8 kbit/s.
car packet-type tcp cir 16 #
Set the CIR value to for TCP packets 16 kbit/s.
auto-defend
enable
# Enable attack source tracing.
auto-defend attack-packet sample 5 # Set the packet sampling ratio
for attack source tracing to 5.
auto-defend threshold 30 #
Set the checking threshold for attack source tracing to 30 pps.
undo auto-defend trace-type source-portvlan # Configure attack
source tracing based on the source MAC address and source IP address.
undo auto-defend protocol tcp igmp telnet ttl-expired # Delete TCP,
IGMP, Telnet, and TTL-expired packets from the list of traced packets in attack
source tracing.
auto-defend whitelist 1 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for attack
source tracing.
auto-defend whitelist 2 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for attack
source tracing.
auto-port-defend whitelist 1 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for port
attack defense. By default, port attack defense is enabled in V200R003 and
later versions.
auto-port-defend whitelist 2 interface GigabitEthernet x/x/x # Add the
interconnection interface and upstream interface to the whitelist for port
attack defense. By default, port attack defense is enabled in V200R003 and
later versions.
cpu-defend-policy io-board global # Apply the attack defense
policy.
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 A Appendix
3.1 Applying the Attack Defense Policy
l 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
[HUAWEI] cpu-defend-policy policy1
[HUAWEI] quit
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
[HUAWEI] cpu-defend-policy policy2 global
n If LPUs process different services, apply an attack defense policy to the specified LPU.
<HUAWEI> system-view
[HUAWEI] slot 1
[HUAWEI-slot-1] cpu-defend-policy policy2
l Fixed switches
− Apply an attack defense policy to a stand-alone switch.
<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy1 global
− In a stack:
n Apply an attack defense policy to the master switch.
<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy1
n Apply an attack defense policy to all stacked switches.
<HUAWEI> system-view
[HUAWEI] cpu-defend-policy policy1 global