Коротко — есть два пути, в зависимости от того, готовы ли вы отойти от аппаратного switch‑чипа CRS112 (рекомендуемая опция) или нужно обязательно оставаться на hw‑switch (ограниченная, но рабочая защита).
Ниже — что делать и почему, с практическими шагами и вариантами.
1) Рекомендованный вариант — перевести VLAN‑ы в bridge (software), включить VLAN‑filtering и использовать встроенные средства Bridge (DHCP‑snooping / bridge‑filter / ARP‑inspection)
- Зачем: все «умные» фильтры RouterOS (bridge firewall, DHCP‑snooping, ARP inspection, фильтрация gratuitous ARP и т. п.) работают на уровне bridge, а не на уровне аппаратного switch‑чипа. Это даёт наиболее корректную и гибкую защиту от rogue‑DHCP и ARP‑spoof.
- Минус: на старых CRS112 производительность переключения будет ниже, т. к. пакеты будут обрабатываться CPU, а не полностью hw‑chip (проверьте нагрузку).
- Общая последовательность:
1. Создать bridge, добавить в него физические порты (ether1…).
2. Включить bridge VLAN filtering (bridge vlan‑filtering=yes).
3. Настроить мостовую таблицу VLAN (bridge vlan add …) — разграничить access/tagged порты.
4. Развернуть DHCP‑сервер(а) на соответствующих bridge‑интерфейсах / VLAN‑интерфейсах.
5. Включить DHCP‑snooping / arp‑inspection (если ваша версия RouterOS поддерживает эти функции) или использовать bridge‑filter правила:
- DHCP: блокировать BOOTP/DHCP ответ на портах, которые не являются доверенными (drop UDP dst‑port 67/68 на in‑interface = порт доступа, кроме порта с доверенным DHCP‑сервером).
- ARP: создать bridge‑filter правила, которые запрещают ARP‑ответы/gratuitous ARP с тех портов, где они не ожидаются, привязать ARP к DHCP‑lease (вытягивать список известных mac↔ip и запрещать все остальное).
- Примерные (общие) направления команд — могу подготовить точный конфиг, если скажете версию RouterOS и список портов/VLANов.
2) Если нужно/нужно оставаться на аппаратном switch (hw offload) — использовать возможности switch‑чипа (ACL / port security) + дополнительные меры
- Пояснение: когда вы оставляете VLAN на switch‑чипе, трафик не идёт через bridge/ip‑стек, поэтому обычные bridge‑фильтры и ip‑firewall не сработают. Но у CRS‑чипа есть собственные acl/port‑security механизмы — их и надо применять.
- Что можно сделать:
1. Ограничить возможность появления rogue DHCP‑server:
- На каждом access‑порту (порт где подключены клиенты) запретить DHCP‑offer/DHCP‑ack пакеты оттуда. На уровне switch ACL заблокировать входящие UDP dst‑port 67 (вроде: от access портов служебный трафик DHCP‑server) — т.е. разрешить UDP/67 только для uplink/трастового порта, а на остальных портах — drop.
- На uplink (или на порту, где DHCP‑сервер) отметить как trusted.
2. Защита от ARP‑spoofing:
- Включить port‑security — ограничить число MAC адресов на порту (максимум 1–4 для доступа).
- Включить привязку MAC→порт (static MACs) для важных клиентов/серверов.
- Использовать switch ACL для блокировки ARP‑reply/gratuitous ARP с access‑портов или разрешать ARP только между конкретными MAC/IP парочками (если чип поддерживает L3‑matching).
3. Дополнительно:
- Использовать порт‑изоляцию (port isolation) для guest портов.
- Вести мониторинг / скрипты, которые проверяют дубли ip↔mac в dhcp‑leases и отключают порт при подозрениях.
- Минус: синтаксис switch‑acl сильно зависит от версии RouterOS и модели чипа. Некорректная ACL может нарушить работу сети, поэтому я могу подготовить точный набор команд, если вы сообщите RouterOS версию и покажете вывод:
/interface ethernet switch print
и
/interface bridge print
3) Практические советы и «быстрые» меры (подходят в любых условиях)
- Везде, где возможно — делайте DHCP только на центральном/доверенном сервере; запрещайте DHCP серверы на access‑портов на уровне switch/ACL.
- Ограничьте максимальное число MAC на портах (limit‑mac) — это сильно уменьшает возможность MAC‑spoofing.
- Для критичных устройств используйте статические ARP записи и статические DHCP lease (make static).
- Включите логирование и скрипты, реагирующие на появление новых MAC с уже существующими IP (или наоборот).
- Обновите RouterOS до последней стабильной версии — в новых версиях часто добавляют улучшения работы bridge/switch и новые ACL‑возможности.
4) Что мне нужно от вас, чтобы дать готовый конфиг
- Точная модель CRS112 (полная), версия RouterOS (system resource print → version).
- Топология: какие порты — access, какие — trunk/uplink; где находится легитимный DHCP‑сервер (на роутере/на сервере в VLAN X).
- Готовы ли вы перевести VLANы на bridge (производительность/нагрузка важна?) или нет.
Если скажете версию RouterOS и пришлёте выводы / короткое описание портов и где DHCP‑сервер, я подготовлю конкретный пошаговый конфиг для одного VLAN (пример) и покажу команды как для варианта с bridge, так и для варианта с hw‑switch (switch ACL / port‑security).