+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта

правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта, RouterOS

onlineuser

Guest

18.10.2018 12:20:00

Привет! В дополнение к этой теме (все еще не решено) — **http://forum.mikrotik.com/t/no-firewall-rules-for-dhcp-renewing-for-wan-interface-dhcp-parameter-list/92680/1** — хочу задать тот же вопрос снова. Когда на моём тестовом роутере с ROS 6.40 мои правила файрвола блокировали весь трафик WAN, порт WAN не мог получить IP от провайдера. Но в ROS 6.42.9 и 6.43, которые я тоже проверял, порт WAN может получить IP, даже если мои правила файрвола блокируют весь трафик на этом интерфейсе. Я заметил такое странное поведение, потому что у меня есть правила для WAN, которые считаются и по обновлениям DHCP. И в ROS 6.42 счётчик остаётся на нуле, но IP всё равно присваивается. Также UDP-соединения отображаются в списке соединений. Как такое может быть, что порт WAN получает IP от провайдера, хотя весь трафик заблокирован (возможно, сервис файрвола загружается слишком поздно при старте)? Есть ли скрытые правила или даже ещё более скрытые правила в новых прошивках? Большое спасибо!

sebastia

Guest

22.01.2019 15:11:00

DHCP работает поверх UDP и МОЖЕТ блокироваться файрволом, поэтому ЕГО НУЖНО разрешить, иначе он не будет работать… Подробнее о протоколе — https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

В контексте исходного вопроса, MT разрешает первоначальный DHCP-запрос с порта 68 на 67 по UDP, а правило «разрешить установленные/связанные» обрабатывает ответ.
Правка: исправлено в соответствии с текущей ситуацией.

nescafe2002 Guest	#3 0 22.01.2019 20:19:00 Снова: клиент DHCP не может быть заблокирован с помощью ip firewall. Только в бриджевом файерволе.

sebastia

Guest

22.01.2019 21:58:00

К сожалению, вы правы. И я говорю «к сожалению», потому что это просто не имеет смысла и противоречит логике, ведь протокол использует UDP поверх IP, который обычно обрабатывается IP-файрволом. Раньше это явно нужно было разрешать. Я сталкивался с этим в ROS 2, 3 и, кажется, даже 4-й версии. Позже я просто взял стандартную конфигурацию, поэтому не знаю, когда произошло изменение. Интересно, почему MT сделал тут исключение? И спасибо за ваш очень подробный ответ.

nescafe2002

Guest

23.01.2019 09:19:00

Есть ещё одна дискуссия по этой теме: http://forum.mikrotik.com/t/impossible-to-block-dhcp-server-by-design-or-bug/32434/1. Я не понимаю почему, но это поведение зафиксировано, подтверждено MT, и есть приемлемое решение — использовать фильтр моста. Возможно, было бы полезно иметь документацию по этому конкретному ограничению.

sebastia Guest	#6 0 23.01.2019 18:41:00 Спасибо, действительно, doc было бы здорово. Ради забавы попытался вставить в таблицу RAW, но «не повезло».

onlineuser

Guest

24.03.2019 06:40:00

До версии 6.40.1 фильтрация DHCP-запросов на WAN-порту работала. В более поздних версиях я пытался включить функцию «use-ip-firewall» и добавить ложное правило DHCP.
/interface bridge settings set use-ip-firewall yes/no
[admin@Client] > /interface bridge settings print
use-ip-firewall: yes
use-ip-firewall-for-vlan: no
use-ip-firewall-for-pppoe: no
allow-fast-path: yes
bridge-fast-path-active: no
bridge-fast-path-packets: 0
bridge-fast-path-bytes: 0
bridge-fast-forward-packets: 0
bridge-fast-forward-bytes: 0
rougeDHCP: input,udp,src67,dst68,wan,log

Это работает частично. Но почему Mikrotik изменил такое поведение?

PackElend

Guest

13.07.2022 14:04:00

Привет! Я наткнулся на вашу беседу, так как у MikroTik в расширенном руководстве по файрволу есть правило для DHCP, и мне было интересно, зачем оно нужно. В итоге я пришёл к выводу, что забыли чётко указать сценарий использования этого туториала.

Читайте эту тему — мне кажется, что варианты использования нужно явно прописать.

DHCP-сервер находится в том же широковещательном домене.
Это, как объяснил cdiedrich в посте №2. Единственный способ предотвратить неправильную работу DHCP — это добавить DHCP Snooping и DHCP Option 82. Но не все чипы коммутаторов это поддерживают, иначе придётся обеспечивать прохождение трафика через CPU или работать с ACL.
Если это программный мост (без аппаратного ускорения портов), можно использовать Bridge Filter, как показано в разделе «Flow of Bridged Packet». Возможно, поможет и этот форум: http://forum.mikrotik.com/t/exact-steps-to-block-rogue-dhcp-servers/20839/13.

DHCP-сервер не в том же широковещательном домене.
В таком случае DHCP-запросы покидают домен и маршрутизируются на третьем уровне. IP-Firewall может их заблокировать (и только тогда).

anav Guest	#9 0 13.07.2022 14:10:00 На практике это часто случается потому, что люди удивляются — как так, можно пинговать интерфейсы, которые заблокированы правилами фаервола, и получать ответ? Пример: VLANX пингует IP-адрес VLANY и наоборот, и начинается паника… Нет, ничего страшного. Это ожидаемое поведение интерфейсов на устройстве MT. L2-структура VLAN предотвращает передачу реальных данных между VLAN, так что с этой стороны переживать не стоит. К тому же, блокировка трафика с vlanx на vlany с помощью правил «drop all» или явных правил полностью останавливает передачу любых данных между VLAN на уровне L3. Не падает ли небо? Нет. В итоге, происходят забавные вещи, причины которых уже объясняли другие, но какая разница? Главное — данные между VLAN не проходят, а это и есть цель. Всем хорошего «удовлетворённого» дня!

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры