HOW-TO: Как защитить локальную сеть от ARP-спуфинга
Если хакер запустит снифер (к примеру, Wireshark) в локальной сети, то ничего интересного, кроме своих бродкастов и прочей служебной информации, он не увидит. Поэтому для перехвата трафика обычно используются слабости самого протокола ARP. Разберемся, как можно компенсировать их.
Протокол ARP используется для преобразования IP-адреса в MAC-адрес. Исторически ARP не имеет никакой защиты или хотя бы проверки подлинности запросов. Повторю: совсем никакой! А еще возможна отправка ARP-ответов без ARP-запросов — это так называемый gratuitous ARP. Он-то нас и интересует. Чтобы провернуть подобную схему, можно воспользоваться тулзой Cain & Abel. Думаю, ты о ней знаешь.
С помощью Cain & Abel злоумышленник может вклиниться и перехватить трафик в одном широковещательном домене. Защититься от этой напасти можно при помощи механизма Dynamic ARP Inspection (Protection).
Для корректной работы Dynamic ARP Inspection необходимо указывать, какие порты коммутатора будут доверенными, а какие — нет. Под ненадежным портом подразумевается тот порт, к которому подключены клиенты. Для ненадежных портов выполняется ряд проверок сообщений ARP. А к доверенным портам коммутатора относятся те порты, к которым подключен другой коммутатор. Сообщения протокола ARP, полученные с доверенных портов, не отбрасываются.
Коммутатор перехватывает все ARP-запросы и ARP-ответы на ненадежных портах, прежде чем перенаправлять их. Также на ненадежных портах коммутатор проверяет соответствие MAC-адреса IP-адресу.
Проверка соответствия MAC-адреса IP-адресу может выполняться на основании статических записей или базы данных привязки DHCP.
На коммутаторах Cisco этот механизм во VLAN включается командой
А вот как выглядит настройка доверенного порта:
Если у тебя нет коммутатора, способного защитить от атак подобного типа, можешь установить arpwatch: это демон, который отслеживает соответствие между IP- и MAC-адресами и при обнаружении аномалий фиксирует это в системном логе. Документацию можно глянуть вот здесь.
Как сам понимаешь, главный недостаток arpwatch, как и, в принципе, всех программ подобного рода, в том, что он должен работать на хостах, которые он защищает, или хотя бы на маршрутизаторе, ведущем в защищаемую сеть. Однако маршрутизатор не всегда работает под управлением UNIX или Linux. Чаще всего это специализированный аппаратный маршрутизатор или коммутатор третьего уровня.
Чтобы защитить такой маршрутизатор, нужно получать от него ARP-таблицу по SNMP и анализировать ее на другой машине. Так, к примеру, действует программа remarp.
Атака канального уровня ARP-spoofing и как защитить коммутатор Cisco
Данная статья не является руководством для кулхацкеров. Все ниже написанное является частью изучения курса Cisco SECURE.
В данном материале я покажу как на практике провести атаку канального уровня на коммутатор Cisco, а также покажу как защитить свою сеть от этого. Для лабораторного стенда я использовал Cisco 881 и Catalyst 3750G.
Наверное все, кто сталкивался хоть немного с сетями знают, что такое протокол ARP.
Вкратце напомню. Протокол ARP используется для преобразования IP-адреса в MAC-адрес. Рассмотрим такую топологию:
Что произойдет, если с хоста H1 пропинговать Gateway? Первым делом будет работать ARP протокол. H1 отправит широковещательный запрос (ARP-request), в котором будут указаны MAC и IP хоста H1 и IP получателя (GATEWAY). Далее GATEWAY получит запрос и видя, что в поле IP получателя содержится его адрес, дописывает к нему свой MAC и отправляет ответ ARP-reply. Хост H1 получает ответ и заносит его в ARP-таблицу.
Как можно перехватить трафик идущий от H1 к GATEWAY? Допустим атакующий (ATTACKER) находится в одном широковещательно домене с GATEWAY и H1. Если атакующий запустит сниффер, к примеру Wireshark, то в сниффере ничего интересного он не увидит, кроме своих броадкастов и прочей служебной информации. Для перехвата трафика можно использовать слабости протокола ARP. Данный протокол не имеет никакой защиты, никакой проверки подлинности запросов. А еще возможна отправка ARP ответов без ARP запросов, это так называемый gratuitous-ARP.
Это как раз то, что нужно. Использовать для атаки будем софт Cain & Abel, но для начала посмотрим ARP-таблицы на хосте H1 и на ATTACKER:
Далее запускаем Cain&Abel, включаем сниффер и добавляем все хосты из широковещательного домена.
Далее переходим на вкладку ARP, жмем + и выбираем адрес шлюза и хост, с которого будем перехватывать трафик.
Жмем кнопку ARP-poisoning и процесс изменения таблицы ARP на хосте H1 запустился.
Теперь посмотрим, как изменилась ARP-таблица на хосте H1.
Видим подмену MAC-адреса для IP 192.168.1.1
Теперь запустим на хосте H1 putty и попробуем зайти на GATEWAY через небезопасный протокол telnet. Так как протокол telnet передает данные в plain text, то атакующий в сниффере должен будет увидеть всю нужную информацию, то есть логин и пароль. Заходим и вводим логин/пароль и пароль enable.
Теперь на ATTACKER в сниффер, вкладка Passwords. Видно что какую-то информацию отловили
Смотрим эту запись и видим текст такого содержания:
Username: яы яы яы яы’яэ яы яэ яъ P яряю яъ яряю’яэ яъ XTERMяряы$яю$admin
Все. Пароль от телнета перехвачен.
А теперь самое главное. Как защитить свою сеть от таких атак. На помощь нам приходит инструмент Dynamic ARP Inspection (DAI).
DAI предназначен для регулировки ARP-запросов, то есть решает — какие пропускать, а какие отбросить. Грубо говоря, DAI полностью защищает сеть от атаки ARP-spoofing, которая происходит на канальном уровне, благодаря незащищенности протокола ARP.
Немного о том, как работает DAI. Для того, чтобы работал этот механизм, нам необходимо в сети использовать DHCP и на коммутаторе должен быть включен DHCP Snooping. Если в сети используется статическая адресация, то DAI работать не будет.
Как работает DHCP Snooping. Допустим DHCP сервер у нас настроен на GATEWAY. Злоумышленник ATTACKER решил поднять у себя dhcp сервер и раздавать какие-то свои адреса. DHCP snooping предназначен для регулировки запросов и будет отбрасывать запросы сервера злоумышленника. Все очень просто. Есть Untrusted и Trusted порты. Надежным портом мы назначаем порт, которые ведет к GATEWAY, так как он у нас будет авторизованным DHCP сервером. Все остальные порты будут ненадежными и серверные запросы от них будут отбрасываться.
При этом строится таблица соответствия адресов dchp snooping database. Включаем на коммутаторе SW функцию DHCP snooping
ip dhcp snooping database flash:/dhcp-snoop.db
ip dhcp snooping
На порту, смотрящему в сторону GATEWAY
SW(config-if)# ip dhcp snooping trust
SW#sh ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
DHCP snooping is configured on the following Interfaces:
Insertion of option 82 is enabled
circuit-id format: vlan-mod-port
remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface Trusted Rate limit (pps)
— — — FastEthernet1/0/47 yes unlimited
И посмотрим, что появилось в таблице соответствия
SW#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
— — — — — — E8:03:9A:BE:0C:D8 192.168.1.50 26268 dhcp-snooping 1 FastEthernet1/0/13
50:B7:C3:78:B4:1A 192.168.1.10 69421 dhcp-snooping 1 FastEthernet1/0/1
Total number of bindings: 2
Теперь, если атакующий захочет стать dhcp сервером, то запросы его коммутатор будет отбрасывать.
На основании базы dhcp snooping, где содержится соответствие всех MAC и IP адресов и будет работать механизм Dynamic ARP Inspection.
Перейдем к настройке. На коммутаторе Cisco данный инструмент включается для каждого vlan отдельно. В нашем случае, достаточно на коммутаторе SW дать команду:
SW(config)#ip arp inspection vlan 1
Оба хоста и шлюз находятся в vlan 1. В DAI для портов коммутатора есть две настройки: Trusted и Untrusted. По-умолчанию, все порты коммутатора
Untrusted, то есть ненадежные. Порт, который идет к шлюзу или порт, в который включен транком еще один коммутатор можно сделать Trusted, тогда ARP-запросы приходящие через него будут считаться надежными.
SW(config-if)#ip arp inspection trust
Теперь повторим атаку с самого начала. Пробуем делать ARP-poisoning через Cain&Abel. Атака не проходит и в логах коммутатора появились следующие записи:
18:11:19: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa1/0/1, vlan 1.([50b7.c378.b41a/192.168.1.10/0000.0000.0000/192.168.1.1/18:11:19 UTC Mon Mar 1 1993])
18:11:19: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa1/0/1, vlan 1.([50b7.c378.b41a/192.168.1.10/001d.4641.02b4/192.168.1.1/18:11:19 UTC Mon Mar 1 1993])
18:11:19: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa1/0/13, vlan 1.([e803.9abe.0cd8/192.168.1.1/50b7.c378.b41a/192.168.1.10/18:11:19 UTC Mon Mar 1 1993])
18:11:19: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa1/0/13, vlan 1.([e803.9abe.0cd8/192.168.1.10/001d.4641.02b4/192.168.1.1/18:11:19 UTC Mon Mar 1 1993])
18:11:21: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa1/0/1, vlan 1.([50b7.c378.b41a/192.168.1.10/001d.4641.02b4/192.168.1.1/18:11:21 UTC Mon Mar 1 1993])
18:11:21: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa1/0/13, vlan 1.([e803.9abe.0cd8/192.168.1.1/50b7.c378.b41a/192.168.1.10/18:11:21 UTC Mon Mar 1 1993])
18:11:21: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa1/0/13, vlan 1.([e803.9abe.0cd8/192.168.1.10/001d.4641.02b4/192.168.1.1/18:11:21 UTC Mon Mar 1 1993])
18:11:24: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Req) on Fa1/0/1, vlan 1.([50b7.c378.b41a/192.168.1.10/001d.4641.02b4/192.168.1.1/18:11:24 UTC Mon Mar 1 1993])
18:11:25: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Fa1/0/1, vlan 1.([50b7.c378.b41a/192.168.1.10/001d.4641.02b4/192.168.1.1/18:11:25 UTC Mon Mar 1 1993])
Коммутатор отбрасывает «неправильные» arp-запросы. Теперь атакующий ничего не сможет перехватить.
Включим еще дополнительную проверку DAI
SW(config)#errdisable recovery cause arp-inspection
Данная опция позволяет восстановить порт и состояния errdisabled через 300 секунд. Если конечно несоответствие MAC-IP будет на этом порту продолжаться, то порт восстановлен не будет.
Просмотреть trusted и untrusted порты и статистику можно командой
SW#show ip arp inspection interfaces
На этом всё.
Спасибо за внимание.
