Как заблокировать чужой DHCP-сервер на MikroTik: DHCP Snooping и MAC-фильтр

Сотрудник подключил домашний роутер в офисную розетку — и часть компьютеров получила другой шлюз или DNS. Интернет работает через раз, доступ к внутренним ресурсам пропал. Одна из возможных причин — посторонний DHCP-сервер в том же сегменте сети.

На MikroTik для профилактики используют DHCP Snooping: ответы сервера разрешают только со стороны проверенных портов. Фильтр по известному MAC может помочь в отдельном случае, но не заменяет контроль источника DHCP. Разберём настройку для RouterOS 7, проверку результата и ограничения.

Все имена интерфейсов и MAC-адреса ниже условные. Команды изменения предназначены для согласованной схемы или стенда. Перед работой на удалённом устройстве обеспечьте консольный доступ и сохраните исходные значения.

1. Почему чужой DHCP ломает сеть

DHCP выдаёт клиенту адрес и параметры сети. В обычном IPv4-сегменте клиент отправляет запрос, а доступные серверы могут ответить предложениями. Если домашний роутер подключён LAN-портом к офисной сети, его DHCP может конкурировать со штатным сервером.

В результате компьютер получает неподходящий адрес, шлюз или DNS. Злоумышленник может использовать ту же ситуацию для направления трафика через свой узел. При этом одна только блокировка DHCP не останавливает все способы перехвата и подмены в сети.

Проблема относится к пути DHCP в конкретном сегменте. Если клиент и чужой сервер подключены к одному внешнему неуправляемому коммутатору, их обмен может не проходить через MikroTik. Защита должна стоять на том участке, где она действительно видит трафик. Работа DHCP описана в RFC 2131.

2. Что выбрать: Snooping, Alert или MAC-фильтр

У этих средств разные задачи:

• DHCP Snooping — предотвращать выдачу ответов от серверов за недоверенными портами.
• DHCP Alert — обнаруживать неизвестные серверы и уведомлять администратора.
• Bridge filter по MAC — точечно отбрасывать подходящие пакеты известного источника, если они проходят через программный фильтр.

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

Не запускайте автоматическую блокировку любого обнаруженного MAC без проверки: можно отключить резервный сервер, relay или ошибочно идентифицированный узел.

3. Как подготовить MikroTik к настройке

Посмотрите версию, bridge, порты и уже действующие настройки:

/system resource print
/interface bridge print detail
/interface bridge port print detail
/interface bridge vlan print detail
/ip dhcp-server print detail
/ip dhcp-relay print detail
/interface bridge filter print detail

Наличие DHCP-сервера на самом MikroTik и внешний сервер за портом — разные схемы. Также проверьте VLAN, резервные серверы и промежуточные коммутаторы.

Сохраните конфигурацию:

/export file=before-dhcp-snooping

Экспорт скачайте с устройства и храните как конфиденциальный материал. Не включайте вывод секретов ради этой настройки. Safe Mode в терминале включается Ctrl+X и помогает вернуть изменения при аварийном завершении сеанса, но не заменяет резервную копию и консоль. Ограничения режима описаны в Configuration Management.

4. Как выбрать доверенные порты

Учебная схема: существующий bridge называется bridge-lan; штатный сервер находится за ether1; рабочие места — за ether2 и ether3. DHCP Snooping до настройки выключен, все три порта имеют trusted=no.

Trusted — это доверие всему пути за портом. Если за ether1 есть устройства, способные отправлять чужие DHCP-ответы, они могут попасть в доверенную область. Лучше фильтровать на коммутаторах доступа, ближе к клиентам.

Trunk не становится доверенным только потому, что передаёт VLAN. Разрешение определяется реальным направлением штатного DHCP, работой нижестоящих коммутаторов и используемыми опциями. Параметр trusted задаётся у bridge port; его назначение описано в официальной справке портов.

5. Как включить DHCP Snooping через CLI

Для описанной схемы сначала задайте доверие портов, затем включите проверку:

/interface bridge port set [find where bridge="bridge-lan" and interface="ether1"] trusted=yes
/interface bridge port set [find where bridge="bridge-lan" and interface="ether2"] trusted=no
/interface bridge port set [find where bridge="bridge-lan" and interface="ether3"] trusted=no
/interface bridge set [find where name="bridge-lan"] dhcp-snooping=yes

Перед выполнением убедитесь, что каждое условие find соответствует нужной записи. Здесь не создаётся новый bridge и не меняется VLAN filtering.

Проверьте результат:

/interface bridge print detail where name="bridge-lan"
/interface bridge port print detail where bridge="bridge-lan"

Серверные DHCP-сообщения с недоверенных клиентских портов должны блокироваться. Клиентские запросы не следует запрещать целиком. Механизм и пример настройки приведены в RouterOS: DHCP Snooping.

В WinBox параметры доступны в настройках bridge и его портов; названия вкладок зависят от версии. Проверять нужно фактические значения dhcp-snooping и trusted, а не только состояние окна.

6. Что делать, если сервер работает на самом MikroTik

Локальный DHCP-сервер отправляет ответы от самого устройства. Не нужно назначать случайный физический порт trusted ради его работы. Клиентские порты обычно остаются недоверенными; фактическую выдачу адресов обязательно проверяют.

При DHCP relay учитывайте, где заканчивается клиентский сегмент и каким путём возвращаются ответы. Простой пример с внешним сервером за ether1 нельзя переносить на relay без анализа топологии.

И фильтры bridge, и IP firewall нужно выбирать по пути пакета. Трафик между клиентами, трафик к CPU и сообщения от самого роутера обрабатываются по-разному. Эти различия показаны в Packet Flow in RouterOS.

7. Как учитывать VLAN и hardware offload

Поддержка Snooping совместно с VLAN и аппаратным ускорением зависит от switch chip, модели и RouterOS. Нельзя обещать одинаковое поведение всем hAP, RB и CRS.

Проверьте таблицу возможностей для своей модели в Switch Chip Features и ограничения в Bridging and Switching. Особенно внимательно проверяйте старые CRS, QinQ, bonding и смешанные схемы.

Флаг H у bridge port показывает фактическое аппаратное ускорение, но сам по себе не доказывает, что нужная фильтрация работает. Включение Snooping влияет на bridge Fast Path; изменение некоторых аппаратных параметров может кратковременно прервать работу портов. После изменения оцените нагрузку CPU, пропускную способность и выдачу адресов.

Не отключайте hw на всех портах как универсальное решение. Программная обработка может заметно снизить производительность; конкретный вариант нужно проверить на своей модели.

8. Нужен ли DHCP Option 82

Option 82 добавляет сведения о пути клиента, например о порте. Она полезна, когда сервер использует эти данные для распределения адресов или политик. Для базового запрета чужих серверов включать её без необходимости не требуется.

У промежуточных устройств важно учитывать обработку уже добавленной Option 82. Совместимость сервера и доверие портов проверяют отдельно. В RouterOS менялись параметры этой функции, поэтому не копируйте старые команды add-dhcp-option82 вслепую. Актуальные параметры и правила обработки описаны в руководстве MikroTik.

Основной пример статьи намеренно меняет только dhcp-snooping и trusted. Если Option 82 уже настроена, сохраните её параметры и проверьте совместимость перед внедрением.

9. Как обнаружить посторонний сервер через DHCP Alert

DHCP Alert наблюдает за ответами и сравнивает MAC с разрешённым списком. Он также периодически отправляет DHCP Discover для обнаружения серверов. Поэтому MikroTik не рекомендует использовать Alert на устройстве, которое само работает DHCP-клиентом.

Пример для подходящего устройства со статическим адресом или ролью DHCP-сервера, если такой записи ещё нет:

/ip dhcp-server alert add interface=bridge-lan valid-server=02:00:00:00:00:01 alert-timeout=1h
/ip dhcp-server alert print detail
/log print where topics~"dhcp"

Подставьте MAC штатного сервера, а при нескольких серверах — полный допустимый список. При relay и сложной схеме сопоставьте реально наблюдаемый источник с инфраструктурой.

Alert — уведомление, а не блокировка. За Snooping-фильтром некоторые ответы могут уже отбрасываться: отсутствие предупреждения не доказывает отсутствие чужого сервера. Работа и ограничения описаны в DHCP: Alerts.

10. Когда уместен фильтр DHCP по MAC

Точечный пример для известного чужого источника на ether3: создать выключенное правило, блокирующее его обычные IPv4 DHCP-ответы, проходящие между портами bridge.

/interface bridge filter add chain=forward in-bridge=bridge-lan in-interface=ether3 mac-protocol=ip ip-protocol=udp src-port=67 dst-port=68 src-mac-address=02:00:00:00:00:99/FF:FF:FF:FF:FF:FF action=drop disabled=yes comment="AVG-DHCP-ROGUE-MAC"
/interface bridge filter print detail where comment="AVG-DHCP-ROGUE-MAC"

Это не универсальное правило для tagged VLAN, relay, DHCPv6 или обмена, который проходит целиком в аппаратном switch chip. Ethernet-кадр с VLAN-тегом может требовать другой проверки заголовков. Синтаксис полей есть в справке bridge filter.

Включайте правило только после проверки пути и порядка фильтров. Ранний accept может не дать ему сработать. Комментарий должен быть уникальным; при повторной подготовке не создавайте дубликат.

/interface bridge filter enable [find where comment="AVG-DHCP-ROGUE-MAC"]
/interface bridge filter print stats where comment="AVG-DHCP-ROGUE-MAC"

Почему не chain=input? Эта цепочка относится к трафику в сторону самого bridge/CPU. Для пересылки между портами используется forward. Аппаратно коммутируемые пакеты могут обходить программный фильтр: наличие правила не подтверждает защиту. См. Packet Flow.

В отличие от блокировки всех кадров MAC, пример ограничен DHCP-ответами. Однако MAC остаётся подменяемым идентификатором. Для профилактики появления новых источников предпочтительнее проверенная граница доверенных портов.

11. Как проверить результат и вернуть настройки

Проверка требует нового DHCP-обмена, а не только ping с ранее выданным адресом. На тестовом клиенте получите аренду заново штатным средством ОС и проверьте адрес, сервер, шлюз и DNS.

• Штатный сервер выдаёт ожидаемые параметры.
• На изолированном стенде ответы тестового чужого сервера за недоверенным портом не доходят до клиента.
• Переходы между VLAN, резервный сервер и relay работают согласно схеме.
• Нет недопустимого роста CPU и падения пропускной способности.
• Результат повторяется после возвращения к обычному режиму работы устройства.

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

Для выключения только MAC-правила:

/interface bridge filter disable [find where comment="AVG-DHCP-ROGUE-MAC"]

Для возврата Snooping в исходное состояние именно учебной схемы:

/interface bridge set [find where name="bridge-lan"] dhcp-snooping=no
/interface bridge port set [find where bridge="bridge-lan" and interface="ether1"] trusted=no

Это не универсальный откат: в реальной сети верните записанные исходные значения всех изменённых свойств. Выключение Snooping вновь открывает путь ответам чужих серверов; после устранения причины защиту нужно восстановить.

12. Частые вопросы и чек-лист администратора

Нужно ли делать все trunk-порты trusted? Нет. Доверие определяется путём штатных DHCP-сообщений и защитой устройств за портом. Сам тип trunk не доказывает безопасность.

Можно ли решить задачу только IP firewall? Не для любого L2-обмена. Важен реальный путь пакетов; включение use-ip-firewall меняет обработку bridge-трафика и производительность. Не включайте его только ради копирования чужого правила.

Хватает ли MAC-блокировки? Она ограничивает известный источник в условиях конкретного фильтра. Она не предотвращает появление другого MAC и не работает на пути, который фильтр не видит.

Защищает ли DHCPv4 Snooping от всех проблем IPv6? Нет. DHCPv6 Snooping и защита от чужих Router Advertisement — отдельные механизмы. Проверяйте их доступность в версии RouterOS и switch chip. IPv4-пример не является настройкой IPv6-защиты.

Почему после включения клиенты не получают адрес? Проверьте выбранный trusted-порт, штатный сервер, VLAN, обработку Option 82, relay и ограничения ускорения. Сначала восстановите управляемость, затем исправьте точную причину.

Перед внедрением убедитесь, что:

• Известны штатные серверы и все пути DHCP в каждом сегменте.
• Клиентские порты и доверенные направления определены по схеме.
• Совместимость модели, RouterOS, VLAN и ускорения проверена по документации.
• Сохранены исходные значения и доступна консоль для восстановления.
• Проверены получение новой аренды и отсутствие чужих ответов.
• Назначен ответственный за предупреждения и изменения топологии.

Другие практические приёмы разобраны в статье «Скрипты MikroTik для RouterOS 7». Если нужна помощь с DHCP, VLAN и защитой коммутаторов, свяжитесь с АВАНГАРД ИТ: начнём с топологии и фактического пути пакетов.