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

[Sweik]

Добрый день.

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

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

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

Спасибо

[Chupaka]

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

- 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]

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

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

С уважением

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

[Sweik]

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

Имеем соединение из локальной (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. Лабораторный стенд поднять прямо сейчас нет возможности, приходится писать, прошу понять и простить (с)

[Chupaka]

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

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

[Sweik]

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

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

С уважением

[Chupaka]

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

[Sweik]

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

[Chupaka]

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

[Sweik]

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

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

- нет необходимости делать правила для обратного трафика сервер --> клиент (например, 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

это немного паранойя, но такого трафика там быть не должно

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

С уважением