Посторонний DHCP-сервер опасен не тем, что он «занимает адреса». Он успевает ответить клиенту раньше штатного сервера и передаёт ему собственный шлюз, DNS-сервер, маску и время аренды. После этого компьютер может потерять доступ к корпоративным ресурсам, начать отправлять DNS-запросы неизвестному узлу или вывести пользовательский трафик через чужой шлюз. Источником бывает не только атака: чаще в розетку включают домашний роутер LAN-портом, запускают общий доступ к интернету на ноутбуке или неправильно подключают тестовый стенд.
На MikroTik проблему решают в два этапа. DHCP Alert помогает обнаружить неизвестный сервер, а DHCP Snooping на bridge отбрасывает серверные DHCP-пакеты, пришедшие с недоверенных портов. Фильтр по MAC-адресу для этой задачи слабее: MAC можно изменить, несколько допустимых серверов могут находиться за одним транковым портом, а DHCP-пакеты в коммутируемой сети не обязаны проходить через обычный IP Firewall.
В статье используется RouterOS 7.26 и пример сети, где bridge-lan объединяет клиентские порты ether3–ether8, а штатный DHCP-сервер подключён через ether2. Если DHCP работает на самом MikroTik, доверенный физический порт сервера не нужен: ответ формирует процесс RouterOS через CPU-порт bridge. Перед изменением сопоставьте имена интерфейсов со своей схемой и не копируйте пример вслепую.
Как DHCP-клиент выбирает сервер и где возникает атака
Получение IPv4-адреса состоит из четырёх сообщений DORA: клиент рассылает DHCPDISCOVER, сервер предлагает параметры в DHCPOFFER, клиент сообщает о выборе в DHCPREQUEST, а сервер подтверждает аренду DHCPACK. До получения адреса клиент использует широковещательные кадры и UDP-порты 68 и 67. Если два сервера прислали предложение, поведение зависит от клиента; обычно выигрывает один из первых ответов. Поэтому «правильный сервер тоже отвечает» не является защитой.
| Сообщение | Направление | Что может подменить посторонний сервер |
|---|---|---|
| DHCPDISCOVER | Клиент → широковещательная сеть | Сервер узнаёт запрос и готовит предложение |
| DHCPOFFER | Сервер → клиент | Адрес, маску, шлюз, DNS, доменное имя, маршруты |
| DHCPREQUEST | Клиент → сеть | Клиент указывает выбранный Server Identifier |
| DHCPACK | Выбранный сервер → клиент | Окончательно подтверждает вредные параметры |
DHCP Snooping рассматривает порты bridge как доверенные и недоверенные. С недоверенного порта разрешены клиентские сообщения, но серверные ответы отбрасываются. Доверенным делают только путь к известному DHCP-серверу или relay. Это правило относится к порту, а не к устройству: если за доверенным портом стоит неуправляемый коммутатор, любой подключённый к нему узел тоже фактически оказывается на доверенной стороне.
Сначала сохраните состояние и определите путь к серверу
Подключайтесь по кабелю и используйте Safe Mode в WinBox или терминале. Перед изменением bridge сохраните экспорт без секретов и бинарную резервную копию. Экспорт пригоден для сравнения, а .backup быстрее возвращает устройство целиком на том же типе оборудования и версии RouterOS.
/system resource print
/system package print
/interface bridge print detail
/interface bridge port print detail
/ip dhcp-server print detail
/ip dhcp-relay print detail
/export hide-sensitive file=before-dhcp-snooping
/system backup save name=before-dhcp-snooping password=<BACKUP_PASSWORD>В выводе проверьте, что RouterOS относится к седьмой ветке, найдите bridge нужного пользовательского сегмента и каждый порт внутри него. Команда /ip dhcp-server print detail показывает локальный сервер RouterOS, а /ip dhcp-relay print detail — пересылку запросов на внешний сервер. Если адреса раздаёт Windows Server за коммутатором, доверенным будет порт или транк в его сторону. Если работает relay, доверять нужно путь, по которому bridge получает допустимые серверные ответы.
Сразу нарисуйте таблицу портов. Особенно внимательно отметьте транки между коммутаторами: доверие должно образовать непрерывный путь от сервера до клиентов, но не распространяться на пользовательские access-порты.
| Порт | Роль | trusted | Обоснование |
|---|---|---|---|
ether2 | Аплинк к штатному DHCP-серверу | yes | По этому пути приходят допустимые DHCPOFFER и DHCPACK |
ether3–ether8 | Рабочие места и точки доступа | no | Клиенты не должны отправлять серверные ответы |
| trunk к следующему управляемому коммутатору | Транк | Зависит от направления | Доверять только если за ним находится допустимый сервер или уже защищённая цепочка |
| порт неуправляемого коммутатора | Группа клиентов | no | Иначе один ошибочный узел обходит защиту всей группы |
Быстро обнаружить неизвестный DHCP с помощью DHCP Alert
DHCP Alert не блокирует пакеты. Он наблюдает ответы, сравнивает MAC источника со списком допустимых серверов и пишет событие в журнал. Кроме пассивного наблюдения alert примерно раз в минуту посылает собственный DHCPDISCOVER, поэтому видит сервер даже без переподключения рабочего компьютера. Однако одноадресные ответы другим клиентам могут пройти незамеченными.
Сначала узнайте MAC штатного сервера. Его можно увидеть в аренде клиента, в сетевом захвате или в ARP/host-таблице рядом с известным IP. Не принимайте первый найденный MAC за правильный: подтвердите его по конфигурации сервера и коммутатора.
/interface bridge host print where bridge=bridge-lan
/tool sniffer quick interface=bridge-lan ip-protocol=udp port=67,68После подтверждения добавьте alert. В valid-server указывается MAC штатного DHCP-сервера; несколько адресов перечисляются через запятую. Новые alerts создаются выключенными, поэтому их надо включить отдельно.
/ip dhcp-server alert add interface=bridge-lan \
valid-server=AA:BB:CC:DD:EE:FF \
alert-timeout=1h disabled=no \
comment="Detect rogue DHCP on users LAN"
/ip dhcp-server alert print detail
/log print where topics~"dhcp"Ожидаемый журнал при обнаружении содержит текст discovered unknown dhcp server, MAC и IP неизвестного узла. Alert нельзя включать на интерфейсе, где сам MikroTik является DHCP-клиентом: его пробные DHCPDISCOVER способны мешать получению адреса самим маршрутизатором. На WAN с DHCP-клиентом этот метод не применяют.
Включить DHCP Snooping и назначить доверенный порт
В примере штатный сервер находится за ether2. Сначала убедитесь, что выбор однозначен, затем пометьте только этот bridge port доверенным и включите snooping на нужном bridge.
/interface bridge port set \
[find where bridge=bridge-lan and interface=ether2] trusted=yes
/interface bridge set \
[find where name=bridge-lan] dhcp-snooping=yes
/interface bridge print detail where name=bridge-lan
/interface bridge port print detail where bridge=bridge-lanВ результате у bridge-lan должно появиться dhcp-snooping=yes, у ether2 — trusted=yes, а клиентские порты должны остаться trusted=no. Если команда find не нашла объект, RouterOS не выдаст ожидаемого изменения: поэтому следующий print detail обязателен.
Не включайте trusted=yes на всех портах ради восстановления связи. Такая конфигурация формально включает функцию, но не блокирует ни одного постороннего сервера. Если после включения клиенты перестали получать адреса, сначала выключите snooping, проверьте фактический путь ответа и только затем исправьте доверенный порт.
/interface bridge set [find where name=bridge-lan] dhcp-snooping=noЧто делать с Option 82 в RouterOS 7.23 и новее
Option 82 добавляет к DHCP-пакету сведения о коммутаторе и порте клиента. DHCP-сервер может использовать Circuit ID и Remote ID для политики выдачи адресов и аудита. Для самой блокировки постороннего сервера Option 82 не требуется. Если сервер не настроен на её обработку, оставьте значения по умолчанию.
В RouterOS 7.23 прежний параметр add-dhcp-option82 удалён. Теперь содержимое задают через dhcp-agent-circuit-id и dhcp-agent-remote-id. Символ $ в терминале RouterOS необходимо экранировать обратной косой чертой, иначе он будет воспринят как ссылка на переменную скрипта.
/interface bridge set [find where name=bridge-lan] \
dhcp-agent-circuit-id="\$(INTERFACE):\$(VID)" \
dhcp-agent-remote-id="\$(HOSTNAME):\$(BRIDGEMAC)"Эту настройку вводят только после проверки совместимости DHCP-сервера. В сети с несколькими коммутаторами порт, принимающий уже помеченные Option 82 сообщения, должен быть доверенным; иначе кадры будут отброшены. Перед массовым внедрением проверьте одну VLAN и одну тестовую аренду, затем сопоставьте значение Option 82 в журнале сервера с реальным портом.
Проверить блокировку, а не только наличие флага
Для приёмки нужен контролируемый тестовый сервер на недоверенном порту. Не проводите опыт в рабочей VLAN без окна: тестовый DHCP способен успеть выдать параметры до активации защиты. После включения snooping обновите аренду тестового клиента и одновременно наблюдайте пакеты и таблицу bridge.
/tool sniffer quick interface=bridge-lan ip-protocol=udp port=67,68
/interface bridge host print detail where bridge=bridge-lan
/log print follow-only where topics~"dhcp|bridge"На клиенте Windows удобно удалить старую аренду и запросить новую:
ipconfig /release
ipconfig /renew
ipconfig /all
route print
Resolve-DnsName avg-it.ruНа Linux с NetworkManager можно переподключить профиль, а затем проверить адрес, маршрут и DNS:
nmcli connection show --active
nmcli connection down "Проводное подключение 1"
nmcli connection up "Проводное подключение 1"
ip -4 address
ip route
resolvectl statusКритерий успеха состоит из трёх проверок: клиент получает аренду от штатного сервера; предложение тестового rogue DHCP не применяется; после выключения штатного сервера клиент не получает адрес от постороннего. Последнюю проверку проводите только на изолированном тестовом порту, иначе вы создадите простой всей VLAN.
Таблица привязок, ARP Inspection и IP Source Guard
RouterOS 7.26 строит runtime-таблицу привязок DHCP Snooping: MAC клиента, выданный IPv4-адрес, срок аренды, VLAN и входной порт. На ней основаны arp-inspection и ip-source-guard. Первая функция отбрасывает ARP с несоответствующей парой MAC/IP, вторая проверяет исходный IPv4-адрес на недоверенном порту.
/interface bridge host print detail where dhcpv4-status!=""
/interface bridge port set \
[find where bridge=bridge-lan and interface=ether2] trusted-arp=yes
/interface bridge set [find where name=bridge-lan] arp-inspection=yes
/interface bridge set [find where name=bridge-lan] ip-source-guard=yesНе добавляйте последние две строки сразу в первую настройку. Они способны отключить статически адресованные принтеры, телефоны, гипервизоры и серверы, которых нет в DHCP binding table. Кроме того, любое изменение bridge, включая активацию этих функций, очищает таблицу привязок. До повторного получения аренды IPv4 и ARP-трафик клиентов может прерваться. Сначала соберите перечень статических узлов, проверьте поддержку switch chip и выполните пилот на одной VLAN.
| Функция | Что блокирует | Источник решения | Главный риск |
|---|---|---|---|
| DHCP Alert | Ничего, только обнаруживает | MAC допустимых серверов | Не видит каждый unicast-ответ |
| DHCP Snooping | Ответы DHCP-сервера с недоверенных портов | Роль bridge port | Ошибка с trusted-портом прекращает выдачу адресов |
| ARP Inspection | Несоответствующий ARP | DHCP binding table | Статические адреса требуют отдельного проектирования |
| IP Source Guard | IPv4 с неподтверждённой парой MAC/IP/порт | DHCP binding table | До появления binding клиент теряет связность |
Производительность и аппаратная разгрузка
Включение DHCP Snooping отключает bridge Fast Path, что может повлиять на FastTrack для трафика через этот bridge. Аппаратная поддержка зависит от switch chip, версии RouterOS, VLAN и используемых функций. Marvell Prestera и семейства 88E6393X/88E6191X/88E6190 поддерживают аппаратно разгруженный DHCP Snooping; у ряда других чипов функция работает в software path или имеет ограничения вместе с VLAN filtering. Название модели недостаточно — проверяйте таблицу Switch Chip Features и флаг H у bridge ports.
/interface bridge port print
/interface bridge settings print
/interface bridge monitor bridge-lan
/tool profileЗафиксируйте CPU и пропускную способность до и после включения. На маршрутизаторе малой мощности программная обработка большого L2-трафика может оказаться заметной. Если сеть построена на CRS, отдельно проверьте, что DHCP-пакеты идут с правильными VLAN-тегами и что выбранная комбинация функций действительно поддерживается аппаратно.
Почему фильтр по MAC и IP Firewall не заменяют Snooping
MAC-правило привязывает доверие к легко изменяемому адресу, а не к физическому направлению трафика. Обычный /ip firewall filter обрабатывает L3-трафик, который попал в IP stack маршрутизатора. Кадры между портами одного аппаратно разгруженного bridge могут пройти через switch chip и не попасть в IP Firewall. Включение use-ip-firewall=yes меняет путь обработки и производительность, но всё равно не превращает универсальное правило UDP 67/68 в корректную модель доверия для транков, relay и VLAN.
Bridge filter можно использовать на старом оборудовании как специально спроектированный запасной вариант, но его нужно проверять с VLAN и hardware offload. Для RouterOS 7 штатная функция DHCP Snooping понятнее: она различает клиентские и серверные сообщения и работает с ролью порта.
Диагностика типичных сбоев
Если клиент не получает адрес, проверьте четыре точки: DHCPDISCOVER входит с клиентского порта, запрос доходит до сервера, DHCPOFFER возвращается через доверенный порт, а VLAN на обоих направлениях совпадает. Sniffer запускайте сначала на bridge, затем на конкретных интерфейсах. Если offer виден на аплинке и исчезает на клиентском порту, наиболее вероятна ошибка trusted или VLAN.
Если посторонний сервер продолжает выдавать аренды, убедитесь, что клиент и сервер действительно находятся в том же bridge, а нужный порт не отмечен trusted. Проверьте аппаратную поддержку комбинации DHCP Snooping и VLAN filtering. Не забывайте о беспроводных клиентах: все виртуальные Wi‑Fi интерфейсы или CAPsMAN datapath должны попадать в тот bridge и VLAN, где включена защита.
Если после включения ARP Inspection пропали статические устройства, немедленно отключите эту дополнительную функцию, не снимая основную блокировку rogue DHCP:
/interface bridge set [find where name=bridge-lan] \
arp-inspection=no ip-source-guard=noКак вернуть исходное состояние
Откат DHCP Snooping прост и не требует удаления bridge. Отключите расширенные проверки, сам snooping и снимите доверие с ранее изменённого порта. Alert можно оставить для наблюдения или тоже выключить.
/interface bridge set [find where name=bridge-lan] \
arp-inspection=no ip-source-guard=no dhcp-snooping=no
/interface bridge port set \
[find where bridge=bridge-lan and interface=ether2] \
trusted=no trusted-arp=no
/ip dhcp-server alert disable [find where interface=bridge-lan]После отката обновите аренду тестового клиента и сравните /export hide-sensitive с файлом before-dhcp-snooping.rsc. Восстановление бинарной копии оставляют последней мерой, потому что оно возвращает всю конфигурацию, включая изменения, не связанные с DHCP.
Что зафиксировать после внедрения
В эксплуатационной документации должны остаться схема VLAN, имя bridge, список доверенных портов с обоснованием, MAC штатных серверов, версия RouterOS, модель и switch chip, результат теста rogue DHCP, влияние на CPU и инструкция отката. Без этой записи следующий специалист может переставить кабель DHCP-сервера в другой порт и получить массовый отказ выдачи адресов.
Полезно сохранить заполненный протокол проверки DHCP Snooping. Он заставляет проверить не только флаг в конфигурации, но и реальное получение аренды, блокировку тестового сервера, журнал, производительность и восстановление после перезапуска.
Актуальные параметры и ограничения сверены с разделом DHCP Snooping в руководстве RouterOS 7.26, описанием DHCP и последовательности DORA и документацией DHCP Alert.