當設備遭受攻擊時，通常伴隨著如下現象：
- 用戶無法獲取ARP。
- 用戶上線成功率較低。
- 用戶無法訪問網絡。
當大量用戶或固定某個端口下的所有用戶出現上述現象時，可以先通過如下定位手段分析是否為攻擊問題。
步驟 1 執行命令display cpu-usage查看設備CPU佔用率的統計信息，CPU Usage表示的是CPU佔用率，TaskName表示的是設備當前正在運行的任務名稱。
如果CPU利用率持續較高，並且bcmRX、FTS、SOCK或者VPR任務過高（通常協議報文攻擊會導致這些任務過高），則較大可能是收到的報文過多，接下來需要執行步驟2繼續判斷設備收到的報文類型。
一般情況下，交換機長時間運行時CPU佔用率不超過80%，短時間內CPU佔用率不超過95%，可認為交換機狀態是正常的。
步驟 2 執行命令display cpu-defend statistics all查看相關協議是否有CPCAR丟包、丟包是否多，並確認現網設備是否放大相關協議的CPCAR值。如果CPCAR存在大量丟包，就基本可以確認現網存在攻擊，根據丟包的協議，採用相關防攻擊措施。具體有哪些常見的丟包協議，請參見表1-1。
表1-1 丟包協議以及相應的防攻擊部署手段
Packet Type
可以參考的攻擊類型
arp-reply、arp-request
1.2.1 ARP攻擊、1.2.8 TC攻擊
arp-miss
1.2.2 ARP-Miss攻擊
dhcp-client、dhcp-server、dhcpv6-reply、dhcpv6-request
1.2.3 DHCP攻擊
icmp
1.2.4 ICMP攻擊
ttl-expired
1.2.5 TTL攻擊
tcp
1.2.6 TCP攻擊
ospf
1.2.7 OSPF攻擊
ssh、telnet
1.2.9 SSH/Telnet攻擊
vrrp
1.2.10 VRRP攻擊
igmp
1.2.11 IGMP攻擊
pim
1.2.12 PIM攻擊
V200R003版本以及之後版本支持端口防攻擊功能，對於V200R003版本以及之後版本，有可能存在這樣的情況：即使Drop計數不再增長，也是有可能存在攻擊的。所以對於V200R003版本以及之後版本，還需要繼續執行步驟3進一步確認丟包協議。
步驟 3 可以通過如下兩種方式確認。
方法一：在診斷視圖中執行命令display auto-port-defend statistics [ slot slot-id ]查看是否有對應協議的丟包。具體有哪些常見的丟包協議，請參見表1-2。
表1-2 丟包協議以及相應的防攻擊部署手段
Protocol
可以參考的攻擊類型
arp-reply、arp-request
1.2.1 ARP攻擊、1.3.8 TC攻擊
arp-miss
1.2.2 ARP-Miss攻擊
dhcp-client、dhcp-server、dhcpv6-reply、dhcpv6-request
1.2.3 DHCP攻擊
icmp
1.2.4 ICMP攻擊
ttl-expired
1.2.5 TTL攻擊
tcp
1.2.6 TCP攻擊
ospf
1.2.7 OSPF攻擊
ssh、telnet
1.2.9 SSH/Telnet攻擊
vrrp
1.2.10 VRRP攻擊
igmp
1.2.11 IGMP攻擊
pim
1.2.12 PIM攻擊
方法二：對於歷史上曾經觸發過端口防攻擊也可以通過日誌來確定。日誌格式如下，其中AttackProtocol表示的是攻擊報文的協議類型。
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])
閱讀更多 愛學習de小烏龜 的文章
