Сетевая топология
Switch_1 и Switch_2 коммутаторы уровня доступа, которые соединяют пользователей с коммутатором уровня ядра Switch_3.
Описание проблемы
Пользователь User host A периодически теряет сеть. Когда он пытается пинговать шлюз по умолчанию, шлюз отвечает с задержкой. Switch_1 часто становится недоступен. Switch_2 работает без перебоев и User host B без проблем пингует шлюз по умолчанию.
Процесс устранения проблемы
1. Проверим загрузку CPU на Switch_1:
<HUAWEI>display cpu-usage
CPU Usage Stat. Cycle: 10 (Second)
CPU Usage : 82% Max: 99%
CPU Usage Stat. Time : 2018-12-12 15:35:56
CPU utilization for five seconds: 68%: one minute: 60%: five minutes: 55%.
В данный момент загрузка CPU составляет 82%.
2. Посмотрим записи в ARP таблице коммутатора.
Как видим, в столбце MAC ADDRESS присутствуют две временные ARP записи - Incomplete.
<HUAWEI>display arp
IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE VPN-INSTANCE INTERFACE
VLAN/CEVLAN
------------------------------------------------------------------------------------------------------
10.137.222.139 00e0-fc01-4422 I - Eth0/0/0
10.137.222.1 0025-9e36-e8c1 20 D-0 Eth0/0/0
10.137.222.100 0025-9e80-b278 6 D-0 Eth0/0/0
10.137.222.99 00e0-4c77-b0e1 9 D-0 Eth0/0/0
10.137.222.173 000f-3d80-cba4 18 D-0 Eth0/0/0
10.137.222.34 0025-9e36-e8c1 1 D-0 Eth0/0/0
10.137.222.172 0016-ec71-ea8c 7 D-0 Eth0/0/0
10.137.222.35 0025-9e36-e8c1 18 D-0 Eth0/0/0
10.137.222.179 0014-2ae2-3128 20 D-0 Eth0/0/0
10.137.222.38 0025-9e36-e8c1 17 D-0 Eth0/0/0
10.137.222.175 0014-2261-2b22 1 D-0 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
192.0.0.4 00e0-fc01-4422 I - Vlanif192
20.1.1.1 00e0-fc01-4422 I - Vlanif200
192.168.2.2 00e0-fc01-4422 I - Vlanif100
------------------------------------------------------------------------------------------------------
Total:16 Dynamic:10 Static:0 Interface:6
3. Возможно, происходит ARP атака на коммутатор.
Проверим статистику ARP запросов, отправленных на CPU коммутатора.
<HUAWEI>display cpu-defend arp-request statistics all
Statistics on mainboard:
---------------------------------------------------------------------------------------------------------------
Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)
---------------------------------------------------------------------------------------------------------------
arp-request 67908288 0 1061067 0
---------------------------------------------------------------------------------------------------------------
Statistics on slot 4:
---------------------------------------------------------------------------------------------------------------
Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)
---------------------------------------------------------------------------------------------------------------
arp-request 80928 44380928 2301 693450
---------------------------------------------------------------------------------------------------------------
Statistics on slot 5:
---------------------------------------------------------------------------------------------------------------
Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)
---------------------------------------------------------------------------------------------------------------
arp-request N/A N/A 0 0
---------------------------------------------------------------------------------------------------------------
Statistics on slot 6:
---------------------------------------------------------------------------------------------------------------
Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)
---------------------------------------------------------------------------------------------------------------
arp-request N/A N/A 0 0
---------------------------------------------------------------------------------------------------------------
Как мы видим, на 4 слоте платы присутствует большое количество дропнутых ARP запросов.
Настроим политику, чтобы определить источник атаки.
<HUAWEI>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-ip source-portvlan
[HUAWEI-cpu-defend-policy-policy1]undo auto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired udp
[HUAWEI-cpu-defend-policy-policy1]quit
[HUAWEI]cpu-defend-policy policy1 global
auto-defend attack-packet sample 5 – коммутатор будет проверять каждый пятый присланный пакет. При уменьшении данного значения, пакеты будут проверяться чаще и будет задействовано больше процессорных ресурсов.
auto-defend threshold 30 – задаем значение в 30 пакетов в секунду, при его достижении следующие пакеты будут считаться как атакующие.
undo auto-defend trace-type source-ip source-portvlan – задаем MAC адрес в качестве источника для проверки пакетов.
undo auto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired udp – задаем ARP пакеты в качестве источника атаки.
Команда display auto-defend attack-source покажет источник атаки.
[HUAWEI]display auto-defend attack-source
Attack Source User Table (MPU):
------------------------------------------------------------------------------------------------
MacAddress InterfaceName Vlan:Outer/Inner TOTAL
------------------------------------------------------------------------------------------------
0000-0000-00db GigabitEthernet2/0/22 193 416
------------------------------------------------------------------------------------------------
0000-0000-00db – MAC адрес, с которого ведется атака, он подключен к порту коммутатора GigabitEthernet2/0/22.
Если в ARP таблице присутствует запись с нужным MAC адресом, вводим команду display arp | include 0000-0000-00db чтобы узнать IP адрес источника.
a) Выберем один из способов для блокировки источника атаки.
1. Блокировка через blacklist.
#
acl number 4000
rule 10 permit type 0806 ffff source-mac 0000-0000-00db ffff-ffff-ffff
#
cpu-defend policy 1
blacklist 1 acl 4000
#
cpu-defend-policy 1 global
#
2. Дроп пакетов через команду auto-defend action deny:
#
cpu-defend policy policy1
auto-defend enable
auto-defend threshold 30
undo auto-defend trace-type source-ip source-portvlan
undo auto-defend protocol 8021x dhcp icmp igmp tcp telnet ttl-expired udp
auto-defend action deny
#
cpu-defend-policy policy1 global
#
b) Если не получилось установить источник атаки, можно воспользоваться одним из следующих способов:
1. Traffic suppression
Ограничим на интерфейсе пропускную способность для broadcast и неизвестного unicast трафика до 100 kbit/s, и ограничим количество multicast трафика до 30%.
#
interface GigabitEthernet 2/0/22
unicast-suppression cir 100 cbs 18800
multicast-suppression 30
broadcast-suppression cir 100 cbs 18800
#
2. Storm control
Применим storm-control для широковещательных пакетов получаемых на интерфейсе GigabitEthernet2/0/22. Эта политика будет применена, если число получаемых пакетов на интерфейсе вырастет до 8000 пакетов в секунду.
#
interface GigabitEthernet2/0/22
storm-control broadcast min-rate 5000 max-rate 8000
#
Введем команду display storm-control interface <interface-type> <interface-number>. Как видим, storm-control заблокировал интерфейс:
<HUAWEI> display storm-control interface gigabitethernet 2/0/22
PortName Type Rate Action Punish- Trap Log Interval Last-
(Min/Max) Status Punish-Time
------------------------------------------------------------------------------
GE12/0/12 Broadcast 14881000 shutdown shutdown off off 180 2018-12-12/14881000 16:30:00
