ARP-спуфинг и MITM (и защита)

Разбираем, почему протокол ARP доверчив по своей природе, как из этого вырастает «человек посередине» в локальной сети — и как защитник закрывает эту брешь на коммутаторе и хосте.

ARP-спуфинг — подмена соответствия IP-адреса и MAC-адреса в локальной сети, при которой атакующий выдаёт свой MAC за чужой IP (например, за адрес шлюза), чтобы трафик жертвы пошёл через его машину.

Этот урок — концептуальный разбор на безопасном стенде: пара виртуальных машин в изолированной локальной сети (или лаборатория TryHackMe/HackTheBox). Мы не перехватываем чужой трафик: ARP-спуфинг изучается, чтобы научиться обнаруживать и предотвращать его в своей сети. Перехват чужих данных в сети — это статьи 272 и 274 УК РФ, и «любопытство» этого не оправдывает. Тренируемся только там, где вы владелец или есть письменное разрешение.

Зачем это знать защитнику

ARP — фундамент любого Ethernet-сегмента: без него хосты не найдут друг друга по MAC. Но протокол проектировался в эпоху доверенных сетей и не имеет аутентификации — это его врождённое свойство, а не баг конкретной реализации. Понимая механику подмены, сетевой инженер видит, какие именно функции коммутатора (Dynamic ARP Inspection, DHCP snooping) закрывают брешь, а специалист Blue Team умеет распознать атаку по аномалиям в ARP-таблице. Это знание превращается в конкретную конфигурацию оборудования.

Как работает ARP и почему он уязвим

Когда хост хочет отправить пакет на IP в своей подсети, он должен узнать MAC получателя. Он шлёт широковещательный запрос «у кого IP 192.168.1.1? сообщите свой MAC», и владелец отвечает unicast-ом со своим MAC. Ответ кешируется в ARP-таблице. Проблема в двух местах:

• В ответе нет подписи — хост верит любому, кто прислал ARP-reply.
• Многие стеки принимают незапрошенные ответы (gratuitous ARP) и обновляют кеш, даже не отправляв запрос.

Посмотреть текущее соответствие на своей машине можно штатной командой — это нормальная диагностика, а не атака:

# Посмотреть ARP-таблицу своего хоста (диагностика)
arp -a
ip neigh show   # современный аналог в Linux

Если атакующий регулярно рассылает поддельные ответы вида «IP шлюза = мой MAC», кеш жертвы перезаписывается, и пакеты, адресованные шлюзу, уходят на машину атакующего. Симметрично он убеждает шлюз, что MAC жертвы — это его MAC. Теперь он стоит между ними (MITM) и видит/может изменять транзитный трафик. Заметьте: мы описали принцип, а не пошаговый рецепт против чужой сети — цель в том, чтобы вы узнавали эту аномалию и гасили её.

Признаки атаки в сети

Главный индикатор — один MAC-адрес внезапно соответствует нескольким IP (особенно IP шлюза и жертвы одновременно), либо MAC шлюза в таблице меняется без причины. На стенде это видно невооружённым глазом в выводе arp -a до и после. Утилита arpwatch ведёт журнал пар IP/MAC и шлёт уведомление при изменении — её ставят именно для раннего обнаружения:

# arpwatch журналирует изменения пар IP↔MAC и сигналит об аномалиях
sudo arpwatch -i eth0

Косвенные признаки: рост дублированных пакетов, неожиданные ICMP-redirect, падение задержек «через раз». В коммутируемой сети нормальный хост чужой трафик видеть не должен — если видит, это сигнал.

Чем атака на ARP отличается от спуфинга на других уровнях

Важно не путать уровни. ARP-спуфинг работает только внутри одного широковещательного домена (одной подсети/VLAN): атакующий обязан физически находиться в том же сегменте, потому что ARP не маршрутизируется через роутер. Это отличает его от атак на DNS или TLS, которые могут идти и удалённо. Практический вывод для защитника двоякий. Во-первых, граница защиты — это сам L2-сегмент: меры (DAI, port security) ставятся на коммутаторе доступа, ближе всего к хостам. Во-вторых, чем меньше сегмент, тем меньше потенциальных целей и тем заметнее аномалия — поэтому продуманная нарезка на VLAN-ы это не только удобство адресации, но и мера безопасности. Гостевые устройства, IP-телефония, серверы и рабочие станции в разных VLAN-ах не могут спуфить друг друга по ARP.

Как это работает под капотом

ARP-кеш — это таблица в памяти ядра, отображающая IP в MAC, с коротким временем жизни записи. Ядро не хранит «кто имеет право представлять данный IP» — такой информации в протоколе просто нет. Поэтому фильтровать «плохие» ARP-ответы на хосте по содержимому бессмысленно: формат у поддельного и настоящего ответа одинаковый, отличается лишь источник. Единственное надёжное решение — добавить точку доверия выше хоста: коммутатор, который знает легитимные пары IP/MAC/порт и отбрасывает противоречащие им ARP-сообщения. Именно так устроена защита Dynamic ARP Inspection.

Как защититься

1. Dynamic ARP Inspection (DAI) — главная защита на коммутаторе. DAI проверяет каждый ARP-пакет на access-портах против доверенной базы пар IP/MAC, которую коммутатор формирует из DHCP snooping (см. урок о канальном уровне). Пакет, где MAC не соответствует выданному этому порту IP, отбрасывается. Концептуальная настройка на управляемом коммутаторе:

# Псевдоконфигурация: включить DAI в VLAN и довериться аплинку
ip arp inspection vlan 10
interface Gi0/24            ! порт к роутеру/ядру
  ip arp inspection trust   ! доверенный аплинк, его ARP не проверяем
# access-порты остаются untrusted — их ARP инспектируется

2. Статические ARP-записи для критичных узлов. Для немногих важных адресов (шлюз, сервер БД) можно прописать MAC вручную — такая запись не перезаписывается gratuitous-ответами. Подходит для серверного сегмента, но не масштабируется на сотни рабочих станций:

# Статическая запись: MAC шлюза зафиксирован и не перезапишется
sudo ip neigh replace 192.168.1.1 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent

3. Сегментация и шифрование как рубеж в глубину. Разделение сети на VLAN-ы уменьшает «радиус поражения»: в одном широковещательном домене меньше целей. А поскольку MITM на L2 опасен только если трафик не защищён, сквозное шифрование (HTTPS/TLS, см. урок о перехвате TLS) превращает перехват в бесполезный поток шифртекста. Спуфинг становится виден, но данные не читаются.

4. Обнаружение как постоянный контроль. Разверните arpwatch или аналог в каждом сегменте, заведите алерт на «MAC шлюза изменился» в системе мониторинга, периодически сверяйте ARP-таблицы ключевых узлов. Защита (DAI) предотвращает атаку, мониторинг ловит то, что прошло мимо, — работают они вместе.

Итоги

• ARP не имеет аутентификации: хост верит любому ARP-ответу — отсюда возможность подмены пары IP/MAC и MITM.
• Признак атаки — один MAC на нескольких IP и спонтанная смена MAC шлюза; ловит это arpwatch и алерты мониторинга.
• Главная защита — Dynamic ARP Inspection на коммутаторе (опирается на DHCP snooping); для критичных узлов — статические записи.
• Рубежи в глубину: сегментация на VLAN и сквозное шифрование (TLS), обесценивающее перехват.
• Любая практика — только в своей сети/лаборатории. Перехват чужого трафика = ст. 272/274 УК РФ.