SavePearlHarbor

Канальный уровень глазами атакующего: ARP Spoofing, прыжки по VLAN и игры с коммутатором

—

от автора

admin

Введение

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

Предположим, что этот этап уже позади. Кабель подключён, линк поднялся, а устройство стало полноценным участником локального сегмента сети.

На первый взгляд может показаться, что дальше атакующего ждёт серьёзный барьер. Эпоха Ethernet-хабов давно закончилась: современные коммутаторы доставляют трафик точечно, а не дублируют его на все порты подряд, VLAN позволяют логически разделять инфраструктуру на отдельные сегменты сети, а механизмы вроде NAC и 802.1X должны ограничивать подключение неавторизованных устройств.

Логика выглядит вполне убедительно. Если коммутатор больше не рассылает весь трафик на каждый порт, кажется, что проблема прослушивания сети осталась в прошлом. Если устройства находятся в разных VLAN, значит они изолированы друг от друга. Если внедрён контроль доступа к сети, значит постороннее устройство вообще не должно получить полноценный доступ к инфраструктуре.

На практике всё несколько сложнее.

Большинство механизмов канального уровня создавались прежде всего для обеспечения связности, масштабируемости и удобства администрирования сети. Безопасность зачастую была не основной целью их разработки. Поэтому многие протоколы и механизмы внутри Ethernet-сегмента по-прежнему основаны на доверии между устройствами.

А там, где существует доверие, почти всегда появляются способы им злоупотребить.

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

Большинство описанных ниже техник редко встречается в хорошо администрируемых корпоративных сетях, однако продолжает регулярно обнаруживаться во время аудитов, пентестов и анализа устаревшей инфраструктуры.

Миф 1. Коммутатор защищает от перехвата трафика

Во времена использования обычных хабов (концентраторов) сеть была единым домен коллизий. Хаб работал на физическом уровне: получал кадр на один порт и тупо дублировал его на все остальные. Для перехвата трафика атакующему хватало перевести сетевой интерфейс в неразборчивый режим (Promiscuous mode) и запустить анализатор – весь сетевой обмен сегмента ложился как на ладони.

Свитчи принципиально изменили эту логику. Коммутатор осуществляет направленную доставку известного unicast-трафика. Он опирается на CAM-таблицу (Content Addressable Memory), где динамически фиксируются связки между аппаратными MAC-адресами узлов и физическими портами устройства. Из-за этого появилось стойкое заблуждение, что внутри одного сегмента чужие сессии перехватить невозможно.

Классический обход этого ограничения – атака MAC Flooding. Реализуют её обычно с помощью старой доброй утилиты macof или фреймворка Yersinia. Суть в том, чтобы залить свитч множеством кадров со случайными фейковыми MAC-адресами отправителя и полностью исчерпать емкость CAM-таблицы.

Важный нюанс: Распространенное утверждение, что при переполнении таблицы «коммутатор превращается в хаб» – технически неверно. Аппаратная логика никуда не отключается. Однако, когда легитимные записи вытесняются мусорным трафиком, коммутатор перестает находить MAC-адреса назначения в памяти. Такие кадры он обрабатывает как Unknown Unicast. Чтобы не нарушить связность, устройство вынуждено транслировать этот трафик на все порты в пределах конкретного VLAN. При этом легитимные записи, которые успевают обновиться, продолжают коммутироваться точечно. То есть деградация носит селективный характер, и это не эквивалентно поведению классического хаба.

В современных Enterprise-сетях мак-флуд в чистом виде неэффективен. Объемы памяти современных ASIC-чипов велики, а базовая настройка функции Port Security (лимитирование количества MAC-адресов на порт) позволяет автоматически переводить интерфейс в состояние err-disable при первых признаках аномалии.

По этой причине вектор сместился от попыток перегрузки элементов коммутации на Data Plane к эксплуатации архитектурных особенностей сетевых стеков конечных хостов. Коммутатор в данном сценарии остается пассивным ретранслятором, а атака направлена на логику динамического разрешения адресов хостового уровня. Задача атакующего – заставить сами конечные узлы изменить свои таблицы соответствия и направить трафик на его сетевой интерфейс.

Анатомия доверия: ARP Spoofing

Протокол ARP (Address Resolution Protocol) выполняет роль связующего звена между логическими IP-адресами сетевого уровня (L3) и физическими MAC-адресами канального уровня (L2). Когда хосту необходимо отправить пакет, например, на шлюз по умолчанию (192.168.1.1), его сетевой стек генерирует широковещательный запрос (Broadcast): «Кто имеет IP 192.168.1.1? Ответьте со своим MAC». Получив ARP-ответ (ARP Reply), хост кэширует эту связку в своей локальной таблице соседей (neighbor table).

Фундаментальная уязвимость ARP заключается в полном отсутствии встроенных механизмов аутентификации и проверки состояния сессии на хостах. Большинство реализаций сетевых стеков современных ОС по умолчанию принимают и заносят в кэш ответы без предварительного запроса (unsolicited/unrequested ARP replies). Система верит всему, что прилегло в интерфейс, даже если сам узел ничего не спрашивал.

Атакующий использует это свойство для проведения атаки ARP Spoofing (она же ARP Poisoning). Находясь в том же широковещательном домене, он циклически отправляет поддельные ARP-ответы двум целям:

  • В адрес жертвы: заявляя, что IP-адресу шлюза 192.168.1.1 теперь соответствует [MAC_атакующего].

  • В адрес шлюза: заявляя, что IP-адресу жертвы 192.168.1.15 теперь соответствует [MAC_атакующего].

Коммутатор при этом продолжает функционировать в штатном режиме, безошибочно направляя кадры согласно своей CAM-таблице, так как для него это стандартный Data Plane трафик. Однако из-за компрометации ARP-кэша на конечных точках трафик перенаправляется и физически проходит через узел злоумышленника на канальном уровне. Для организации перехвата атакующий активирует форвардинг пакетов на уровне ядра (sysctl -w net.ipv4.ip_forward=1), становясь посредником (Man-in-the-Middle). Пассивный перехват и активные манипуляции реализуются с помощью таких инструментов, как arpspoof, bettercap или ettercap.

Даже с учетом повсеместного шифрования веб-трафика (TLS/HTTPS), позиция MITM внутри сегмента остается крайне опасной. Перехват и активные манипуляции позволяют реализовать следующие векторы:

  • Перехват служебного трафика: До сих пор в корпоративной среде в открытом виде передается критичный массив данных – от DNS-запросов и cleartext-аутентификации в базах данных или устаревших версиях LDAP до трафика сетевых принтеров, VoIP (SIP) и IoT.

  • Перехват аутентификации (SMB Relay): Ключевой вектор в Windows-инфраструктурах. Заняв позицию MITM, атакующий перехватывает легитимный Unicast-трафик аутентификации между рабочей станцией и сервером (например, при обращении к сетевым шарам). С помощью утилит вроде ntlmrelayx эти запросы транслируются (Relay) на соседние ресурсы для выполнения команд. Пентестеру на заметку: В современных сетях эта атака жестко ограничена защитными механизмами Microsoft. Если на целевом сервере включено и затребовано подписание пакетов (SMB Signing Required), либо активировано связывание каналов (Enhanced Protection for Authentication – EPA / Channel Binding), чистый Relay завершится ошибкой аутентификации.

  • Манипуляции с DNS: Перехват классических незашифрованных UDP-запросов к DNS-серверу и выигрыш в гонке ответов (race condition) с легитимным сервером для локального отравления кэша (DNS cache poisoning). Безусловно, в современных ОС атака усложняется механизмами рандомизации TXID и UDP Source Port, однако позиция полноценного MITM позволяет атакующему видеть эти параметры в реальном времени и обходить данную защиту. Внедрение DNSSEC на хостах могло бы минимизировать этот риск, однако в реальном внутреннем корпоративном ландшафте его валидация на конечных рабочих станциях встречается крайне редко.

В сетях, где развернут IPv6, протокол ARP не используется – его функции выполняет NDP (Neighbor Discovery Protocol). Однако логика «доверчивости» осталась прежней: атакующий может проводить аналогичные атаки класса NDP Poisoning (через поддельные Neighbor Advertisement) или Rogue RA (Router Advertisement), перехватывая IPv6-трафик хостов. Базовая DAI против этого бессильна – для защиты IPv6-сегмента на коммутаторах требуется настраивать отдельные функции класса IPv6 First-Hop Security (IPv6 RA Guard, IPv6 Neighbor Discovery Inspection). При этом стоит помнить, что даже IPv6 RA Guard в некоторых реализациях имеет публичные техники обхода через фрагментацию IPv6-пакетов, что требует от администратора повышенного внимания к актуальности прошивок оборудования.

Как защищаться: Host-level и Network-level механизмы

Защита от ARP Spoofing может быть выстроена как на уровне конечных хостов, так и аппаратно на уровне сетевого оборудования.

Хостовый уровень (Host-level)

  • Статические таблицы (Static ARP): Жесткое закрепление пары IP-MAC в операционной системе (arp -s). Метод локально исключает риски успешного ARP Spoofing, но абсолютно не масштабируем в Enterprise-среде, ломает механизмы отказоустойчивости шлюзов (например, при миграции виртуальных IP в VRRP/HSRP failover) и неизбежно приводит к операционному дрейфу конфигураций.

  • Мониторинг (OS-level detection): Использование демонов мониторинга вроде arpwatch или специализированного ПО (XArp), которые анализируют сетевой трафик хоста и сигнализируют об аномальных изменениях MAC-адресов у критических IP (например, шлюза).

Сетевой уровень (Network-level)

Основным аппаратным механизмом защиты на уровне коммутатора является внедрение технологии DAI (Dynamic ARP Inspection) в связке с IP Source Guard (IPSG).

  • DAI (Dynamic ARP Inspection): Функция перехватывает все ARP-кадры на портах доступа и валидирует указанные в них пары IP и MAC перед пересылкой. Зависимо от архитектуры ASIC и настроек операционной системы вендора, этот процесс инспекции может приводить к отправке пакетов на обработку CPU коммутатора (CPU punt), что накладывает ограничения на rate-limit таких кадров во избежание DoS на сам свитч. В качестве эталонной базы данных DAI использует динамическую таблицу DHCP Snooping Binding Table. Попытка атакующего отправить поддельный ARP-ответ с чужим IP мгновенно дропается коммутатором. Для серверов со статической адресацией администратор создает постоянные правила валидации вручную – ARP ACL.

  • IPSG (IP Source Guard): Механизм, защищающий Data Plane хостов. Пока DAI проверяет исключительно ARP-кадры (Control-plane логику хостов), IPSG инспектирует Source IP в заголовке каждого улетающего с клиентского порта IP-пакета. Важно отметить: этот механизм работает исключительно на портах доступа (Access) и технологически не применяется на магистральных транковых интерфейсах или чистых L3-аплинк маршрутизаторах. Без IPSG атакующий, будучи заблокированным на уровне ARP, все еще мог бы отправлять пакеты с поддельным IP-адресом отправителя (IP Spoofing) – например, для совершения деструктивных UDP-атак.

Миф 2. Коммутатор валидирует источники служебных протоколов

Существует заблуждение, что протоколы управления топологией сети имеют встроенные механизмы аутентификации источников. На практике коммутатор не оперирует абстракциями вроде «доверие» или «легитимность» – его поведение определяется детерминированной конечной автоматно-событийной машиной (FSM), исполняемой как Control-plane процесс.

Ключевым механизмом обеспечения отказоустойчивости в Ethernet-сетях является семейство STP (Spanning Tree Protocol). Стандарты 802.1D, 802.1w (RSTP) и 802.1s (MSTP) решают задачу устранения петель в топологии путем логического блокирования избыточных линков. Для координации дерева коммутаторы вычисляют Root Bridge. Обмен топологической информацией происходит через кадры BPDU, которые подаются на вход Control-plane STP process без какой-либо криптографической привязки к источнику.

Суть уязвимости: STP Manipulation (Root Bridge Takeover)

Выборы Root Bridge основаны на параметре Bridge ID (приоритет + MAC-адрес). Побеждает узел с наименьшим значением Bridge ID. Протокол не различает «злоумышленника» и «сетевого инженера» – он реагирует исключительно на структуру сообщения и его метрики согласно алгоритму выбора.

Находясь за портом доступа, атакующий может инициировать изменение топологии:

  1. Инструмент (например, та же Yersinia) генерирует конфигурационный BPDU с минимальным приоритетом (0) и своим MAC-адресом.

  2. Получив такой кадр, коммутатор передает его в Control-plane STP process, где он проходит валидацию и role-dependent STP state machine transitions.

  3. Коммутатор пересчитывает spanning-tree topology, определяя новые роли Root Port и Designated Port, после чего транслирует собственные BPDU с обновленной информацией.

Если в старом 802.1D перестроение дерева занимало до 50 секунд, то в современных RSTP (в типовых топологиях с корректно размеченными edge-портами и наличием alternate paths) сходимость благодаря механизму Proposal/Agreement занимает миллисекунды. В зависимости от топологии это может позволить атакующему влиять на прохождение части трафика или вызвать масштабное нарушение работы сети.

Другой вектор атаки – генерация кадров TCN (Topology Change Notification). Их получение инициирует механизм topology change propagation: корневой мост устанавливает TC-флаг в BPDU, который распространяется по сети. В 802.1D это приводит к временному сокращению MAC aging time до значения Forward Delay. В 802.1w (RSTP) получение BPDU с установленным TC-флагом инициирует механизм flush записей в CAM-таблице на некорневых (non-edge) портах. Непрерывная генерация таких кадров вызывает постоянное вымывание MAC-адресов, рост трафика Unknown Unicast и жесткую деградацию производительности сети.

Как защищаться: Инженерия портов (BPDU Guard и Root Guard)

Защита топологии строится на аппаратном ограничении ролей интерфейсов, исключающем клиентские порты из участия в FSM-расчетах.

  • BPDU Guard (в связке с PortFast / Edge Port): Функция spanning-tree portfast переводит клиентский порт в состояние Forwarding, минуя стандартные STP listening/learning стадии. При этом порт продолжает принимать BPDU, но исключается из участия в расчетах топологии (как edge port). Поверх обязана применяться технология BPDU Guard. При фиксации входящего BPDU на таком интерфейсе, порт превентивно переводится в err-disable. Нюанс дизайна: В средах виртуализации (ESXi, KVM) жесткий BPDU Guard может привести к изоляции сервера. В таких случаях применяется BPDU Filter (игнорирование входящих BPDU). В отдельных legacy или провайдерских edge-сценариях этот метод допустим, однако в типовом Enterprise требует строгого контроля L2-домена.

  • Root Guard: Применяется на инфраструктурных Downlink-интерфейсах коммутаторов агрегации. Если через такой интерфейс поступает BPDU с более предпочтительным Root ID по сравнению с текущим, коммутатор блокирует изменение топологии. Он переводит интерфейс в состояние root-inconsistent (или аналогичный статус блокировки в зависимости от вендора). Блокировка сохраняется до тех пор, пока поступление superior BPDU не прекратится.

Миф 3. VLAN обеспечивает абсолютную изоляцию

После знакомства с атаками на ARP и служебные протоколы многие приходят к следующему логичному выводу: если разделить пользователей по разным VLAN, проблема исчезнет. На первый взгляд, это выглядит разумно. Устройства из VLAN 10 не получают широковещательный трафик VLAN 20, имеют изолированные IP-подсети и не могут напрямую взаимодействовать на канальном уровне. Именно поэтому технология VLAN (IEEE 802.1Q) часто ошибочно воспринимается как полноценный механизм безопасности.

На практике VLAN обеспечивает логическую сегментацию широковещательных доменов. Коммутация кадров и обучение MAC-адресов обычно выполняются независимо для каждого VLAN (модель Independent VLAN Learning, IVL), что исключает пересечение таблиц коммутации между широковещательными domains. Безопасность здесь является лишь побочным эффектом корректной архитектуры. Ошибки конфигурации конечных автоматов портов или особенности обработки тегированного трафика способны полностью разрушить предполагаемую изоляцию.

Как работает VLAN на уровне ASIC

Стандарт IEEE 802.1Q определяет инкапсуляцию Ethernet-кадра специальным 4-байтовым тегом, содержащим идентификатор VLAN (VID). Коммутаторы используют этот идентификатор для ограничения пересылки кадра рамками соответствующего широковещательного домена.

С точки зрения логики обработки порты делятся на два базовых типа:

  • Access Port (Порт доступа): Предназначен для подключения конечных устройств и логически ассоциирован с одним конкретным VLAN (PVID). VLAN-принадлежность кадра сохраняется во внутренних метаданных ASIC. На Egress-стадии трафик покидает порт в нетегированном виде.

  • Trunk Port (Магистральный порт): Способен мультиплексировать трафик нескольких VLAN одновременно. Кадры передаются с явным добавлением тегов 802.1Q. Используется для линковки infrastructure-узлов (коммутаторы, маршрутизаторы, гипервизоры).

Взаимодействие между Ingress-правилами Access-портов и Egress-правилами Trunk-портов исторически породило класс атак VLAN Hopping. Известны два фундаментальных вектора: Switch Spoofing и Double Tagging. В современных Enterprise-сетях первый вариант практически всегда блокируется базовыми настройками безопасности, тогда как второй до сих пор регулярно фигурирует в аудитах из-за ошибок проектирования Native VLAN.

Вектор 1. Switch Spoofing (Эксплуатация DTP)

Ранние версии оборудования Cisco (и некоторых других вендоров) использовали протокол Dynamic Trunking Protocol (DTP) для автоматического согласования транковых соединений. Если один коммутатор объявлял о готовности сформировать транк (состояния Dynamic Desirable или Dynamic Auto), соседний интерфейс автоматически адаптировал свою роль.

Атакующий подключает хост к клиентскому порту и генерирует DTP-кадры со статусом Desirable. DTP FSM инициирует формирование транкового соединения, переводя интерфейс в режим Trunk при совместимой конфигурации противоположной стороны. Атакующий получает транковый линк. Подняв 802.1Q-сабинтерфейсы на своей ОС, он получает доступ ко всем VLAN, разрешенным на сформированном транке (что в плохо настроенных сетях нередко означает большинство VLAN инфраструктуры).

Почему это редко встречается сегодня: В современных сетях транковые и клиентские порты обычно настраиваются явно, без автоматического согласования:

  • Явная фиксация роли клиентского порта (switchport mode access);

  • Полное отключение DTP через директиву switchport nonegotiate;

  • Запрет динамического формирования транков на пользовательских интерфейсах. Поэтому атака Switch Spoofing сегодня актуальна преимущественно для legacy-инфраструктур или сегментов с грубыми ошибками конфигурации.

Вектор 2. Double Tagging (Вложенные теги)

Double Tagging интересна тем, что не требует ошибок в реализации протокола. Атака использует штатный механизм Native VLAN, предусмотренный стандартом 802.1Q.

Для реализации инъекции атакующий формирует кастомный кадр сразу с двумя VLAN-тегами:

  • Внешний тег (Outer VLAN): соответствует Native VLAN транкового линка (например, VLAN 10).

  • Внутренний тег (Inner VLAN): соответствует целевому VLAN-сегменту (например, VLAN 20).

Механика прохождения кадра через фабрику сети выглядит следующим образом:

  1. Кадр поступает на Access-порт первого коммутатора. Внешний тег совпадает с VLAN, назначенным данному порту. Для успешной атаки необходимо, чтобы первый коммутатор не отбросил специально сформированный кадр с вложенными тегами на ingress-стадии (современные платформы часто отбрасывают подобные кадры уже на входе, но ряд конфигураций допускает такую обработку).

  2. При передаче через транк коммутатор обнаруживает, что кадр принадлежит VLAN 10. Так как в классической модели 802.1Q Native VLAN передается по транку без тега, коммутатор легитимно удаляет (strip) внешний тег. При выполнении операции удаления Native VLAN-тега второй тег не рассматривается как отдельный уровень VLAN-классификации и остается частью кадра.

  3. Второй коммутатор получает из транка кадр. Поскольку внешний тег был удален предыдущим коммутатором, на Ingress-стадии ASIC читает первый доступный заголовок – оставшийся внутренний тег (VLAN 20). Для второго коммутатора такой кадр уже выглядит как обычный 802.1Q-кадр VLAN 20, после чего выполняется стандартная коммутация внутри данного сегмента, направляя пакет жертве.

Архитектурные ограничения Double Tagging

В популярном изложении часто утверждается, что Double Tagging позволяет полностью обойти VLAN-изоляцию. Это технически неверно в силу нескольких жестких ограничений:

  • Зависимость от Native VLAN: Атакующий обязан физически находиться в той же VLAN, которая используется как Native VLAN на транке между коммутаторами. Без этого коммутатор не выполнит процедуру удаления внешнего тега на egress-стадии транкового порта.

  • Строгая односторонность (Unidirectional): Классический вариант Double Tagging носит преимущественно односторонний характер и сам по себе не обеспечивает полноценный двусторонний обмен (Full TCP Handshake). Ответные пакеты от жертвы формируются легитимно, не имеют двойного тега и маршрутизируются по стандартным L3-правилам, не возвращаясь к злоумышленнику на L2.

Практическая ценность атаки сводится к доставке одиночных кадров в другой VLAN, обходу отдельных ACL-политик, инъекции UDP/ICMP-трафика и ограниченным DoS-сценариям на инфраструктурные сервисы, не требующие полноценного двустороннего обмена.

Как защищаться: Native VLAN и контроль транков

Защита L2-домена строится не вокруг самого VLAN-механизма, а вокруг строгого контроля тегированного трафика и параметров интерфейсов:

  • Отключение DTP: Все пользовательские интерфейсы должны быть явно настроены как Access-порты. Динамическое согласование транков должно быть отключено (switchport nonegotiate). Это полностью устраняет класс атак Switch Spoofing.

  • Отказ от использования VLAN 1: VLAN 1 традиционно используется многими вендорами как служебный VLAN по умолчанию и тесно связан с обработкой ряда инфраструктурных протоколов (например, CDP, VTP, PAgP на платформах Cisco). Размещать пользовательские устройства или Native VLAN в VLAN 1 считается нежелательной практикой проектирования и нарушением распространенных рекомендаций по безопасности.

  • Выделенная Native VLAN (Parking Lot): Для транков рекомендуется использовать отдельную, изолированную и неиспользуемую VLAN (например, VLAN 999). Такая VLAN не должна содержать пользовательские устройства, серверы или L3-шлюзы. Это устраняет классический сценарий Double Tagging, поскольку атакующий лишается возможности находиться в VLAN, используемом как Native VLAN магистрали.

  • Принудительное тегирование Native VLAN (Tag Native): Многие современные платформы позволяют принудительно тегировать Native VLAN в транке (например, директива vlan dot1q tag native). В этом случае отказ от нетегированного Native VLAN-трафика меняет логику: второй коммутатор больше не увидит ситуацию, при которой внутренний тег станет первым VLAN-заголовком кадра после удаления Native VLAN-тега, поэтому классическая схема Double Tagging перестает работать.

  • Ограничение списка VLAN на транках (Trunk Pruning): Следует явно задавать список допустимых VLAN (switchport trunk allowed vlan), вместо использования настроек по умолчанию (all). Кадр будет отбросен на первом транковом интерфейсе, где данный VLAN отсутствует в списке разрешенных.

VLAN является механизмом сегментации, а не механизмом контроля доступа. Безопасность достигается не самим фактом разделения на VLAN, а корректной настройкой транков, Native VLAN, ACL, межвлановой маршрутизации и защитных механизмов коммутатора. Ошибка конфигурации способна превратить границу между VLAN в административную условность, а не в реальный барьер безопасности.

Миф 4. DHCP просто выдает адреса

Протокол динамической конфигурации узлов (DHCP) традиционно воспринимается как изолированный сервис прикладного уровня (L7), чья роль ограничивается автоматизацией распределения IP-адресов. В контексте безопасности коммутируемых сетей действует базовая аксиома: DHCP не участвует в плоскости передачи данных (Data Plane) и не влияет на CAM/forwarding state напрямую.

DHCP становится основным источником информации для построения таблицы соответствий IP-адресов, MAC-адресов и портов коммутатора.

Вектор 1. Rogue DHCP Server

Атака эксплуатирует широковещательную природу доставки сообщений в L2-сегменте. Поскольку запросы DHCP Discover рассылаются на широковещательный адрес FF:FF:FF:FF:FF:FF, их получает любой узел в том же широковещательном домене. Разворачивая ложный DHCP-сервер, атакующий стремится выдать ответ хосту быстрее легитимного сервиса.

Механика компрометации: Злоумышленник передает клиенту измененные сетевые параметры, где в DHCP Option 3 (Router) указывает собственный IP-адрес. На данном этапе прикладной протокол никак не влияет на топологию или таблицы коммутатора – он лишь подменяет конфигурацию default gateway в L3-стеке хоста.

L2-эффект возникает исключительно постфактум, как вторичное следствие: операционная система жертвы принимает маршрутное решение (L3 Control Plane хоста) и инициирует процедуру ARP-разрешения для этого нового next-hop адреса. Коммутатор при этом выполняет стандартный L2-forwarding на основе CAM-таблицы, доставляя кадры к MAC-адресу, полученному в результате ARP-разрешения next-hop, заданного через DHCP. DHCP не осуществляет перенаправление трафика на уровне канальной доставки – он дестабилизирует L3-логику хоста, которая затем штатно использует механизмы канального уровня для доставки пакетов перехватчику.

Вектор 2. DHCP Starvation

Цель атаки – вызвать искусственный дефицит IP-адресов в пуле сервера и перевести сервис в состояние DoS для новых устройств. В этом векторе неэффективность стандартного механизма Port Security (лимит MAC-адресов на порту) обусловлена разрывом между физической идентичностью L2 и логической моделью идентификации DHCP-сервера:

  1. Коммутатор на L2 обрабатывает исключительно заголовки Ethernet-кадров. Во всех пакетах атаки указан один и тот же реальный MAC-адрес источника, принадлежащий интерфейсу атакующего хоста. С точки зрения логики коммутации лимит MAC-адресов на порту не превышен.

  2. DHCP-сервер оперирует исключительно логической идентичностью клиента и не имеет доступа к информации о физическом порте или канальном домене, в котором был сформирован запрос. Он формирует записи об аренде (lease state) на основе изменчивых идентификаторов прикладного уровня – параметра chaddr (Client Hardware Address) или Option 61 (Client-ID).

Даже в тех архитектурах, где сервер получает косвенный L2/L3-контекст через Relay Agent (поле giaddr или Option 82), эта информация указывает лишь на сетевой сегмент или идентификатор самого релея, но принципиально не решает проблему аутентификации конечного клиента. В результате возникает фундаментальный разрыв: генерируя случайные значения в payload, утилиты атаки заставляют сервер создавать новые аренды под каждый запрос и последовательно исчерпывать пул, в то время как для базовой логики коммутатора структура трафика на интерфейсе остается абсолютно легитимной.

Ключевая проблема кроется не в структурных уязвимостях DHCP, а в том, что L2-инфраструктура вынуждена использовать DHCP как источник информации о том, какой IP-адрес принадлежит какому MAC-адресу и порту из-за полного отсутствия собственных встроенных механизмов проверки подлинности узлов на канальном уровне.

DHCP Snooping как механизм принудительного доверия

DHCP Snooping не является частью DHCP-протокола. Это функция безопасности коммутатора, которая анализирует DHCP-обмен и формирует таблицу соответствий IP-адресов, MAC-адресов и портов. Для этого коммутатор различает доверенные и недоверенные интерфейсы, контролирует прохождение DHCP-сообщений и на основании полученной информации заполняет таблицу привязок.

Технология реализует контроль периметра за счет жесткого разделения интерфейсов доступа на две роли:

  • Trusted (Доверенные порты): Интерфейсы подключения легитимных серверов или магистральные транки, где политика фильтрации полностью отключена.

  • Untrusted (Недоверенные порты): Пользовательские интерфейсы, на которых коммутатор автоматически уничтожает поступающие серверные сообщения (DHCP Offer, DHCP ACK). Фильтрация реализуется на уровне аппаратного парсинга UDP/DHCP-заголовков в рамках L2/L3 механизма проверки пакетов коммутатора, блокируя нелегитимные сообщения на границе trust boundary.

Пассивно инспектируя успешный обмен сообщениями (DORA) на недоверенных портах, коммутатор фиксирует телеметрию верхних уровней и транслирует её в локальный источник истины – таблицу привязок (DHCP Snooping Binding Table), содержащую соответствия: MAC ↔ IP ↔ Порт ↔ VLAN. В зависимости от платформы коммутатор также может использовать эту информацию на ingress-стадии для автоматической сверки L2 Source MAC с полем chaddr внутри payload, аппаратно отсекая вектор DHCP Starvation на границе порта.

База привязок как основа enforcement-политик Сформированная binding-таблица сама по себе не меняет логику форвардинга, но служит обязательным пререквизитом (необходимое условие для работы функций) контроля плоскости данных (Data Plane):

  • DAI (Dynamic ARP Inspection): обращается к таблице привязок для валидации транзитных ARP-ответов, предотвращая ARP Spoofing (Миф 1).

  • IPSG (IP Source Guard): на основе этих же записей строит динамические списки доступа (ACL) на физических интерфейсах, блокируя пакеты с поддельными IP-источниками.

Манипуляции с DHCP-параметрами на уровне приложения не влияют на L2-коммутацию напрямую. Однако без включенного DHCP Snooping у коммутационной фабрики отсутствует источник для корреляции L2-идентичности, что делает невозможным развертывание последующих механизмов защиты и полностью разрушает гарантии изоляции L2-домена. Коммутатор буквально вынужден заглядывать в L7-payload, чтобы обеспечить базовую безопасность канального уровня.

Важно понимать, что механизмы вроде DHCP Snooping, DAI и IPSG не заменяют контроль доступа на уровне подключения. В современных корпоративных сетях роль первой линии защиты всё чаще выполняют 802.1X и NAC-решения, предотвращающие подключение неавторизованных устройств ещё до получения сетевого доступа.

Заключение

Это вторая статья цикла, в котором модель OSI рассматривается с точки зрения атакующего. Канальный уровень в этой логике выступает не как абстрактный второй слой, а как набор инженерных механизмов, обеспечивающих связность и управляемость локальной сети.

Разобранные в статье примеры показывают, что большая часть механизмов L2 построена на предположении о доверенной среде. Коммутаторы, протоколы соседства, сегментация VLAN и сервисные механизмы автоматической конфигурации не предполагают строгой проверки подлинности участников – они ориентированы на корректное поведение узлов внутри одного широковещательного домена.

В результате атаки на этом уровне редко выглядят как классическое “взломать протокол”. Чаще это использование допустимых состояний и переходов самих протоколов: манипуляции таблицами соседства, влияние на служебный обмен, эксплуатация особенностей логики STP, VLAN или DHCP. Коммутатор при этом продолжает работать в штатной модели – изменяется не его “намерение”, а входные данные, на которых это намерение основано.

Канальный уровень в таком рассмотрении – это не слой защиты, а слой предположений. И как только эти предположения нарушаются, граница между корректной работой сети и эксплуатацией становится вопросом интерпретации состояния, а не явного взлома.

Спасибо за внимание!

Если у вас есть комментарии, замечания или дополнения – буду рад обсудить.

Дополнительные материалы и заметки по пентесту, CTF и сетевой безопасности публикую в своём Telegram-блоге: https://t.me/curly_overfl0w

ссылка на оригинал статьи https://habr.com/ru/articles/1054472/