Правила FW для обработки трафика. Сухая скучная теория

RIP, OSFP, BGP, MPLS/VPLS
Ответить
Аватара пользователя
Sweik
Сообщения: 76
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Правила FW для обработки трафика. Сухая скучная теория

Сообщение Sweik » 10 апр 2019, 11:41

Добрый день.

Прошу не отсылать на RFC-768 :)

Вопрос по обработке UPD-трафика (DNS-запросы / ответы, NTP, DHCP и прочее).
Правильно ли я понимаю, что для Mikrotika каждое UDP-соединение вопринимается, как новое (т.е. нет related, established, invalid) и поэтому в правилах FW надо либо:
- всегда указывать connection state=new
- не указывать ничего?

т.е. не будет established UPD-соединений?

Спасибо
Последний раз редактировалось Sweik 10 апр 2019, 19:29, всего редактировалось 1 раз.
С уважением

Аватара пользователя
Chupaka
Сообщения: 2064
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Правила FW для обработки UDP-трафика

Сообщение Chupaka » 10 апр 2019, 12:02

Добрый. Из информации нескольколетней давности вспоминается вот такое (вряд ли что-то принципиально поменялось, но можно и перепроверить):

- DHCP работает на RAW-сокетах, поэтому на него в обычной конфигурации правила IP Firewall не влияют;
- первый наблюдаемый пакет UDP имеет connection-state=new;
- если в обратную сторону (в ответ) не идёт пакетов (т.е. поток односторонний) - каждый следующий пакет имеет connection-state=new;
- как только пришёл ответный пакет - все пакеты между этими отправителем и получателем (IP:Port) имеют connection-state=established.

Т.е. для DNS это будет такое:
- клиент шлёт запрос на роутер, connection-state=new
- роутер отвечает клиенту, connection-state=established

Но если роутер, например, не настроен как DNS-сервер, и клиент будет с одного и того же порта флудить на 53 порт роутера DNS-запросами, то каждый пакет будет с connection-state=new.

В целом, UDP-соединения очень даже могут быть established. Без этого на стандартной конфигурации (chain=input; accept established; drop new from WAN) DNS-запросы от сервера провайдера не могли бы возвратиться роутеру, Интернетиков не было бы :)

Аватара пользователя
Sweik
Сообщения: 76
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Правила FW для обработки UDP-трафика

Сообщение Sweik » 10 апр 2019, 13:17

Понял, спасибо.

Отдельное спасибо за пример с DNS-запросами. Действительно, если бы DNS-ответ от публичных DNS шел к рутеру, как новое соединение, то соединение бы блокировалось.
Значит, для TCP и UDP connection state-ы вопринимаются [почти] одинаково.

С уважением

P.S. Вроде, отладишь политику правил на FW, а потом при ревизии глядь - цирк какой-то :)
С уважением

Аватара пользователя
Sweik
Сообщения: 76
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Правила FW для обработки UDP-трафика

Сообщение Sweik » 10 апр 2019, 19:13

Блин.
То ли весеннее обострение, то ли просто усталость :(
Продложаем теоретизировать.

Имеем соединение из локальной (Trusted) сети к рутеру. По протоколу TCP (так интереснее)
Исходные данные:
- обрабатываем новые соединение
- пропускаем established и related

Тогда правила будут такие

Код: Выделить всё

/ip firewall filter
add action=accept chain=input disabled=no protocol=tcp in-interface=LAN-Bridge connection-state=new
add action=accept chain=input disabled=no protocol=tcp in-interface=LAN-Bridge connection-state= established,related
потом блокируем все прочее со всех сторон

Что получается:
- клиент шлёт запрос на роутер. connection-state=new. TCP Flag=SYN
- сервер подтверждает соединение. TCP Flag=SYN, ACK
- клиент подтверждает получение. connection-state=established. TCP Flag= ACK
- обмен информации TCP Flag= ACK
.....

Вопрос следующий:
по какому правилу будет проходить трафик от рутера к клиенту, например, вот этот этап соединения:
- сервер подтверждает соединение. TCP Flag=SYN, ACK
???
Ведь, получается, что это уже исходящий (output) трафик, а для него правил не создавали.

Для наглядности:
- клиент шлёт запрос на роутер. connection-state=new. TCP Flag=SYN // соединение проходит по первому правилу
- сервер подтверждает соединение. TCP Flag=SYN, ACK //????
- клиент подтверждает получение. connection-state=established. TCP Flag= ACK // соединение проходит по второму правилу
- обмен информации TCP Flag= ACK // ????


P.S. Лабораторный стенд поднять прямо сейчас нет возможности, приходится писать, прошу понять и простить (с) :D :D :D
С уважением

Аватара пользователя
Chupaka
Сообщения: 2064
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Правила FW для обработки трафика. Сухая скучная теория

Сообщение Chupaka » 10 апр 2019, 21:57

Первый пакет соединения (даже TCP) - это conn-state=new. Всё остальное - established.

Если в output правила не создавали - там все пакеты разрешены. В очень древних версиях (в районе второй, что ли), насколько помню, можно было указывать действие по умолчанию для цепочек, сейчас всегда accept.

Аватара пользователя
Sweik
Сообщения: 76
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Правила FW для обработки трафика. Сухая скучная теория

Сообщение Sweik » 11 апр 2019, 11:04

Правильно ли я понимаю (в официальной доке не нашел подтверждения), что output-трафик (исходящий в любую сторону) считается доверительным и для него никаких правил настраивать не надо?

Работаем только по цепочкам input и forward?

С уважением
С уважением

Аватара пользователя
Chupaka
Сообщения: 2064
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Правила FW для обработки трафика. Сухая скучная теория

Сообщение Chupaka » 11 апр 2019, 12:27

Неправильно. Если вы никаких правил никуда не добавляете ни в какие цепочки (input/output/forward) - весь трафик разрешён. Если вам надо настроить правила в output - вы настраиваете правила в output. Всё зависит от задачи.

Аватара пользователя
Sweik
Сообщения: 76
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Правила FW для обработки трафика. Сухая скучная теория

Сообщение Sweik » 11 апр 2019, 17:18

Добрался до внятных рабочих условий, сделал лабораторный стенд.
Вы праы, спасибо
С уважением

Аватара пользователя
Chupaka
Сообщения: 2064
Зарегистрирован: 29 фев 2016, 15:26
Откуда: Минск
Контактная информация:

Re: Правила FW для обработки трафика. Сухая скучная теория

Сообщение Chupaka » 11 апр 2019, 22:09

Таки заскриншотили свой ответ и удалили? :)

Аватара пользователя
Sweik
Сообщения: 76
Зарегистрирован: 14 июн 2018, 11:05
Откуда: Оттуда

Re: Правила FW для обработки трафика. Сухая скучная теория

Сообщение Sweik » 12 апр 2019, 10:34

Да он как-то глупо выглядел и мог запутать :) Я не со зла, честное слово.

Если кратко, то выводы следующие:
- сетевой экран Mikrotik-a работает по принципу "нормально-открытого". Т.е., если нет правил, запрещающих определенные соеднинения, то эти соединения разрешены. Проверял на "настройках с нуля", т.е. открыл вкладу Firewall, удалил все дефлотные правила и добавил свои. Насколько удобен такой принцип -тема отдельного обсуждения :D :D :D

- нет необходимости делать правила для обратного трафика сервер --> клиент (например, SYN ACK) . Если разрешен трафик типа

Код: Выделить всё

chain=input, connection state=new, in-interface=lan
chain=input, connection state=established, related, in-interface=lan
и явным образом не запрещен трафик типа

Код: Выделить всё

chain=output, connection state=established, related, out-interface=lan 
то будет работать.


Отдельно скажу, что если за рутером нет публичных сервисов (Web, почта и пр.) то имеет смысл
запретить исходящий из wan трафик типа established, related

Код: Выделить всё

chain=output, connection state=established, related, out-interface=wan
это немного паранойя, но такого трафика там быть не должно

В принципе, это повторяет стертое мною предыдущее сообщение, просто изложено в более адекватном виде.

С уважением
С уважением

Ответить