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

Введение

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

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

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

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

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

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

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

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

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

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

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

Одной из классических техник обхода этого ограничения является атака MAC Flooding (реализуемая с помощью macof или фреймворком Yersinia). Ее суть заключается в генерации лавины кадров со случайными поддельными MAC-адресами отправителя с целью исчерпания емкости CAM-таблицы.

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

В современных корпоративных сетях MAC Flooding в чистом виде неэффективен. Объемы памяти современных 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-ответ, хост кэширует эту связку в своей локальной таблице соседей (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: В сетях, где развернут 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 (подробнее о ней – в мифе 4). Попытка атакующего отправить поддельный 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), реализующей строго формализованную обработку входящих протокольных событий.

Ключевым механизмом обеспечения отказоустойчивости в Enterprise-сетях является семейство протоколов STP (Spanning Tree Protocol). Исторический стандарт 802.1D (STP), а также актуальные 802.1w (RSTP) и 802.1s (MSTP) решают задачу устранения физических петель в топологии путем логического блокирования избыточных линков.

Для координации дерева коммутаторы вычисляют единую точку отсчета – Root Bridge (корневой коммутатор). Остальные устройства рассчитывают кратчайший путь до корня на основе стоимости интерфейсов (Path Cost). Обмен топологической информацией происходит через служебные кадры BPDU (Bridge Protocol Data Unit), транслируемые на зарезервированный мультикаст-адрес.

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

Фундаментальная особенность семейства Spanning Tree заключается в отсутствии криптографической аутентификации BPDU в базовых спецификациях. Коммутатор обрабатывает любой корректно сформированный BPDU как валидное входное событие STP state machine. Протокол не различает «злоумышленника» и «сетевого инженера» – он реагирует исключительно на сравнение параметров superior BPDU / inferior BPDU.

Выбор Root Bridge детерминирован параметром Bridge ID (bridge priority + extended system ID + MAC-адрес в зависимости от реализации STP). В топологии побеждает узел с наименьшим Bridge ID.

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

Инструмент генерирует конфигурационный BPDU (Configuration BPDU в терминах 802.1D / RSTP BPDUs)
В поле приоритета (Bridge Priority) выставляется минимально возможное значение – 0 (или 4096/0 в зависимости от MST/PVST+ domain)
В поле MAC-адреса используется минимально возможное значение, формирующее наименьший Bridge ID в пределах STP domain

Важно: корректный термин здесь – формирование superior BPDU относительно текущего Root Bridge, а не «гарантированный выигрыш у ядра» в абсолютном смысле, так как итог зависит от текущей STP topology view.

Для изменения топологии не требуется DoS-шторм. Достаточно периодической отправки BPDU в пределах Hello Time (обычно ~2 секунды в 802.1D; в RSTP timers логически сохраняются, но обработка событий происходит асинхронно и быстрее за счет proposal/agreement механизма).

Поведение сети при инъекции BPDU

Получив superior BPDU, коммутатор обрабатывает его в рамках STP state machine и выполняет пересчет топологии:

пересчитываются роли портов (Root Port / Designated Port / Alternate Port)
обновляется spanning-tree topology view
при необходимости инициируется выбор нового Root Bridge

Важно уточнение: коммутатор не «ретранслирует осознанно измененную логику», а генерирует собственные BPDU на основе нового состояния state machine.

В RSTP (802.1w) сходимость ускоряется за счет механизмов Proposal/Agreement и локального вычисления альтернативных путей (alternate/backup ports). Это позволяет существенно сократить время convergence по сравнению с классическим 802.1D (где использовались blocking/listening/learning таймеры и максимальное convergence time могло достигать десятков секунд).

Топология может изменяться быстро и без явных признаков деградации доступности, если сеть корректно спроектирована (edge ports, отсутствие L2 loops, корректные STP guards).

Практический импакт

При успешном влиянии на выбор Root Bridge атакующий может изменить дерево кратчайших путей в пределах STP domain. В результате часть транковых линков может перейти в состояние blocking/forwarding в зависимости от новой метрики, а трафик VLAN будет перераспределяться по новому дереву кратчайших путей к Root Bridge.

Если атакующий оказывается на этих путях, появляется возможность перехвата или анализа L2-трафика (MITM на уровне spanning-tree domain). Однако важно уточнение: полный контроль над потоками невозможен без топологической позиции, обеспечивающей фактическое нахождение в transit path графа STP.

Альтернативный вектор – генерация кадров TCN (Topology Change Notification).

Корректная модель:

в 802.1D TCN приводит к ускоренному aging MAC-таблиц (через изменение Forward Delay / Max Age behavior на root bridge)
в RSTP роль TCN фактически заменена TC flag в RST BPDU, что приводит к ускоренному flushing MAC-адресов на соответствующих портах (в рамках TC While timer и scoped propagation)

Непрерывная генерация topology change событий может приводить к:

росту unknown unicast flooding
увеличению нагрузки на CAM table re-learning
transient degradation производительности L2-домена

Однако эффект сильно зависит от реализации ASIC, TC rate limiting и STP optimization (например, TCN suppression на edge ports в современных платформах).

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

Защита топологии строится на строгом разделении ролей портов и ограничении участия edge-интерфейсов в STP state machine.

BPDU Guard (в связке с PortFast / Edge Port)

Edge-порты (PortFast / Edge) предназначены для конечных устройств и переходят в forwarding без стандартных STP listening/learning задержек.

BPDU Guard добавляет жесткое правило: если на edge-порту обнаружен BPDU, порт переводится в err-disable. Это предотвращает участие конечных устройств в STP topology calculation.

Важно уточнение: PortFast не отключает STP – порт продолжает получать и обрабатывать BPDUs, но bypass’ит стандартные задержки convergence для ускорения подключения end-host.

Нюанс дизайна

В средах виртуализации или embedded switching (hypervisor vSwitch / nested L2), BPDU может быть легитимным элементом топологии. Поэтому, BPDU Filter технически отключает обработку BPDU (в некоторых реализациях – ingress/egress suppression), но в Enterprise‑дизайне считается нежелательным, так как отключает механизм обнаружения петель на уровне STP FSM

Корректный подход – явное моделирование STP domain и контроль edge/non-edge сегментов на уровне архитектуры сети.

Root Guard

Root Guard применяется на инфраструктурных (non-edge, typically downstream-facing) портах, где устройство не должно становиться Root Bridge.

Если через такой интерфейс поступает superior BPDU (который в соответствии с логикой STP FSM должен сделать данный порт корневым – Root Port), коммутатор не изменяет root election state и переводит порт в root-inconsistent (или vendor-specific blocking/discarding state)

Порт остается заблокированным до исчезновения superior BPDU.

Ограничение метода: Root Guard защищает только от изменения root election state. Он не предотвращает TCN-driven behavior и не является защитой от L2-flooding или других control-plane атак STP domain.

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

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

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

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

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

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

Access Port (Порт доступа): Предназначен для подключения конечных устройств и логически ассоциирован с одним конкретным VLAN (PVID). VLAN-принадлежность кадра сохраняется во внутренних метаданных ASIC и не обязательно соответствует физическому наличию тега 802.1Q внутри коммутационной фабрики. На 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 (и некоторых других вендоров) использовали проприетарный протокол DTP (Dynamic Trunking Protocol) для автоматического согласования режима работы интерфейса. Если один коммутатор объявлял о готовности сформировать транк (состояния 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, поскольку она использует легитимные аппаратные особенности обработки кадров стандарта 802.1Q, в частности концепт Native VLAN.

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

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

Механика прохождения кадра через фабрику сети:

Кадр поступает на Access-порт первого коммутатора. Для успешной атаки необходимо, чтобы первый коммутатор не отбросил специально сформированный кадр с вложенными тегами на ingress-стадии. Исторически ряд платформ и конфигураций допускал такую обработку, однако современные реализации могут отбрасывать подобные кадры уже на входе. Если политика ingress-обработки платформы допускает прием такого кадра, внешний тег совпадает с VLAN, назначенным данному порту.
При передаче через транк коммутатор обнаруживает, что кадр принадлежит VLAN 10. Так как в классической модели 802.1Q Native VLAN передается по транку без тега, коммутатор легитимно удаляет (strip) внешний тег. При выполнении операции удаления Native VLAN-тега второй тег не рассматривается как отдельный уровень VLAN-классификации и остается частью кадра после снятия внешнего тега.
Второй коммутатор получает из транка кадр. Поскольку внешний тег был удален предыдущим коммутатором, на 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 является механизмом сегментации, а не механизмом контроля доступа. Безопасность достигается не самим фактом разделения на VLAN, а корректной настройкой транков, Native VLAN, ACL, межвлановой маршрутизации (Inter-VLAN Routing) и защитных механизмов коммутатора. Ошибка конфигурации способна превратить границу между VLAN в административную условность, а не в реальный барьер безопасности.

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

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

Вектор 1. Rogue DHCP Server (Инициирование MitM через L3-конфигурацию)

Атака эксплуатирует широковещательную природу доставки сообщений в 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-сервера:

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

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

Архитектурный тезис: Ключевая проблема кроется не в структурных уязвимостях DHCP, а в том, что L2-инфраструктура вынуждена использовать прикладной трафик как event-based correlation mechanism для построения L2 identity binding из-за полного отсутствия собственных встроенных механизмов проверки подлинности узлов на канальном уровне.

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

DHCP Snooping не является частью DHCP-стека. Это механизм L2 enforcement, который использует DHCP-трафик как источник наблюдаемых корреляций для построения локального state machine коммутатора. Его задача – классифицировать DHCP-сообщения на границе trust boundary и извлекать из них корреляции для построения binding state.

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

Trusted (Доверенные порты): Интерфейсы подключения легитимных серверов или магистральные транки, где политика фильтрации полностью отключена.
Untrusted (Недоверенные порты): Пользовательские интерфейсы, на которых коммутатор автоматически уничтожает поступающие серверные сообщения (DHCP Offer, DHCP ACK). Фильтрация реализуется на уровне аппаратного парсинга UDP/DHCP-заголовков в рамках L2/L3 inspection pipeline коммутатора, блокируя нелегитимные сообщения на границе 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-идентичности, что делает невозможным развертывание downstream-механизмов защиты и полностью разрушает гарантии изоляции L2-домена.

С точки зрения модели OSI протокол DHCP относится к прикладному уровню (L7). Мы рассматриваем его в цикле о канальном уровне только потому, что DHCP Snooping переводит этот прикладной протокол в статус «поставщика телеметрии» для коммутатора. Коммутатор вынужден заглядывать в L7-payload не ради обслуживания самого DHCP, а для того, чтобы собрать базу привязок, которая станет единственным источником истины для сугубо канальных фильтров – DAI и IP Source Guard.

Заключение

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

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

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

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

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

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

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

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