ARP-спуфинг в LAN: закрываем дыру на коммутаторе, а не на хостах

На прошлой неделе делали аудит безопасности для клиента - производственная компания, около ста рабочих станций, три этажа, управляемые Cisco Catalyst 2960 на каждом этаже. Сеть формально нормальная: домен, WSUS, антивирус. Но с некоторых пор сисадмин замечал странное - у отдельных пользователей периодически слетали сессии, кто-то жаловался на тормоза при работе с файловым сервером, хотя каналы не были загружены. Стали разбираться.

Запустили Wireshark на нескольких машинах в одном широковещательном домене. Картина стала понятна быстро: в сети активно ходили аномальные ARP-ответы. Кто-то отправлял gratuitous ARP, переназначая MAC-адрес шлюза на свой. Классический ARP-спуфинг - трафик, который должен идти к шлюзу, уходил транзитом через чужую машину. Человек посередине, без всяких дополнительных инструментов.

Откуда ноги растут. ARP как протокол не предусматривает никакой аутентификации - это было сделано сознательно ради простоты ещё при его разработке. Любая машина в сегменте может объявить «я - это MAC такого-то IP», и остальные обновят свой ARP-кеш без каких-либо вопросов. В маленькой сети это не проблема. В корпоративной - вектор атаки.

Виновника в этот раз нашли: на одном из ПК обнаружилось ПО, которое явно выполняло роль перехватчика. Машина принадлежала сотруднику, который, судя по всему, решил посмотреть, чем занимаются коллеги. Инцидент закрыли - но нас больше интересовало не это конкретное лицо, а то, что сеть вообще позволила такому случиться.

Проблема не в хостах, а в архитектуре. Можно было отреагировать так: найти виновника, почистить машину, провести беседу, написать в политику безопасности «запрещено устанавливать инструменты перехвата трафика». Это ничего не даст. Завтра придёт другой сотрудник с другим ноутбуком, или подключится кто-то к незащищённой розетке, и история повторится. Лечить нужно не симптом, а уязвимость в инфраструктуре.

Cisco 2960, которые стоят у клиента, поддерживают два механизма, которые закрывают эту проблему на уровне порта коммутатора.

DHCP Snooping. Коммутатор начинает отслеживать DHCP-обмен и строит таблицу привязок: какой MAC-адрес получил какой IP с какого порта. Порты делятся на trusted (аплинки, порт к DHCP-серверу) и untrusted (порты к конечным устройствам). DHCP-ответы, пришедшие с untrusted-порта, дропаются - то есть поддельный DHCP-сервер внутри сети просто не сработает. Таблица привязок становится основой для следующего механизма.

Dynamic ARP Inspection (DAI). Коммутатор проверяет каждый ARP-пакет, пришедший с untrusted-порта, против таблицы DHCP Snooping. Если MAC и IP в ARP-ответе не совпадают с тем, что коммутатор знает о порте - пакет дропается. Gratuitous ARP от чужой машины с чужим IP просто не проходит дальше. Атака перехвата останавливается не на хосте-жертве, а на коммутаторе.

Включается это несложно. Примерно так выглядит конфигурация для одного VLAN на Catalyst 2960:

ip dhcp snooping
ip dhcp snooping vlan 10
no ip dhcp snooping information option

ip arp inspection vlan 10

interface GigabitEthernet0/1
 description uplink-to-core
 ip dhcp snooping trust
 ip arp inspection trust

interface range FastEthernet0/1 - 24
 description access-ports
 ! untrusted по умолчанию - явно можно не писать, но для читаемости конфига

Нюансов несколько. no ip dhcp snooping information option нужно убрать, если у вас нет DHCP Relay Agent на этой схеме - иначе коммутатор вставляет option 82 в DHCP-запросы, и часть серверов отклоняет их. Аплинки и порты к DHCP-серверу обязательно помечать как trusted, иначе легитимный DHCP-трафик тоже начнёт дропаться - это самая частая ошибка при первом включении.

Если в сети есть хосты со статическими IP (принтеры, серверы, управляющие контроллеры оборудования), их нужно добавить в таблицу привязок вручную через ip source binding. DAI проверяет против этой же таблицы.

Что получили в итоге. После включения на всех трёх коммутаторах аномальный ARP-трафик исчез - видно по счётчикам show ip arp inspection statistics. За первые сутки DAI задропил несколько сотен подозрительных пакетов, потом счётчик остановился. Сессии перестали слетать, жалобы на тормоза ушли.

Отдельно проверили физическую защиту портов. Несколько розеток в переговорных комнатах были в активных VLAN без каких-либо ограничений - подключай что хочешь. Это отдельная история про Port Security и 802.1X, но для начала хотя бы перевели неиспользуемые порты в отдельный «мусорный» VLAN без маршрутизации. Это несложно и убирает самый очевидный вектор несанкционированного подключения.

DAI и DHCP Snooping - фичи, которые есть на управляемых Cisco-коммутаторах уже не первый год, но включены в реальных сетях крайне редко. На пяти последних аудитах, где у клиента стояло управляемое оборудование Cisco, ни на одном они не были активированы. Оборудование позволяет, настройка занимает час - а сеть при этом открыта для атак, которые любой желающий может провести с ноутбука и бесплатного инструментария.

В этом и есть смысл аудита инфраструктуры: найти не только вирусы и пропущенные патчи, но и то, что в конфигурации сети позволяет атакам работать вообще.