Подопытным будет выступать коммутатор DES-3028. Все работы с ним будет осуществлять через подключение по консольному порту. Представим, что у нас в сети есть атакующих хост 10.0.0.100, трафик от которого мы должны заблокировать. Атаку на наш коммутатор (10.90.90.90) будем осуществлять при помощи примитивного python-скрипта:
#!/usr/local/bin/python
import socket
udp = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while True:
udp.sendto("test",("10.90.90.90",50001))
Проверим его в действии и убедимся, что загрузка CPU коммутатора очень быстро достигает 100%. Прервем работу скрипта и попробуем защитить коммутатор. Для начала используем trusted host. "Заблокируем" вообще все хосты путем указания несуществующего в нашей сети адреса:
Подключиться к коммутатору теперь нельзя - соединение сразу же рвется. При этом на "ping" коммутатор отвечает (в данной модели trusted host не распространяется на ICMP ECHO). Снова атакуем коммутатор скриптом и по загрузке CPU делаем вывод, что ничего не поменялось.
Попробуем более тяжелую артиллерию и создадим блокирующее правило:
Не поменялось вообще ничего - "пинги" все так же ходят, соединение устанавливается и тут же обрывается. Тогда вспомним, что для работы с трафиком, попадающим на CPU коммутатора, следует использовать CPU ACL. Создадим правила и не забудем включить сам функционал (последняя строка).
Вот теперь доступ к коммутатору пропал полностью. Причем коммутатор перестал отвечать нам на наш флуд пакетами ICMP (Destination unreachable). Снова атакуем коммутатор скриптом и видим... 100% загрузку CPU. Это говорит нам о том, что защитить коммутатор собственными средствами... проблематично. Нужно иметь это ввиду при проектировании сети - в идеале нежелательный трафик вообще не должен попадать на интерфейс коммутатора.
#!/usr/local/bin/python
import socket
udp = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while True:
udp.sendto("test",("10.90.90.90",50001))
Проверим его в действии и убедимся, что загрузка CPU коммутатора очень быстро достигает 100%. Прервем работу скрипта и попробуем защитить коммутатор. Для начала используем trusted host. "Заблокируем" вообще все хосты путем указания несуществующего в нашей сети адреса:
create trusted_host 1.1.1.1
Подключиться к коммутатору теперь нельзя - соединение сразу же рвется. При этом на "ping" коммутатор отвечает (в данной модели trusted host не распространяется на ICMP ECHO). Снова атакуем коммутатор скриптом и по загрузке CPU делаем вывод, что ничего не поменялось.
Попробуем более тяжелую артиллерию и создадим блокирующее правило:
create access_profile ip source_ip_mask 255.255.255.255 profile_id 1
config access_profile profile_id 1 add access_id auto_assign ip source_ip 10.0.0.100 port all deny
Не поменялось вообще ничего - "пинги" все так же ходят, соединение устанавливается и тут же обрывается. Тогда вспомним, что для работы с трафиком, попадающим на CPU коммутатора, следует использовать CPU ACL. Создадим правила и не забудем включить сам функционал (последняя строка).
create cpu access_profile profile_id 1 ip source_ip_mask 255.255.255.255
config cpu access_profile profile_id 1 add access_id 1 ip source_ip 10.0.0.100 port all deny
enable cpu_interface_filtering
Вот теперь доступ к коммутатору пропал полностью. Причем коммутатор перестал отвечать нам на наш флуд пакетами ICMP (Destination unreachable). Снова атакуем коммутатор скриптом и видим... 100% загрузку CPU. Это говорит нам о том, что защитить коммутатор собственными средствами... проблематично. Нужно иметь это ввиду при проектировании сети - в идеале нежелательный трафик вообще не должен попадать на интерфейс коммутатора.
Комментариев нет:
Отправить комментарий