pf и асиметричный раутинг

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

pf и асиметричный раутинг

Igor Grabin
Утро добрым иногда бывает,

если так исторически сложилось, что мне нужно через pf пропускать
'встречные' пакеты tcp-потока, то есть он не видит изначального syn'а,
и вообще всех пакетов, едущих от инициирующего хоста - как выглядит
такое правило?
логика подсказывает, что нужно отключать scrub. дальше логика в данном
вопросе сдала.

то, что сеть бы перестроить так, чтобы таких вопросов не возникало -
тоже ответ, но я его и сам знаю. :-)

--
Igor "CacoDem0n" Grabin, http://violent.death.kiev.ua/


Reply | Threaded
Open this post in threaded view
|

Re: pf и асиметричный раутинг

Pavel Labushev
Igor Grabin пишет:
> Утро добрым иногда бывает,
>
> если так исторически сложилось, что мне нужно через pf пропускать
> 'встречные' пакеты tcp-потока, то есть он не видит изначального syn'а,
> и вообще всех пакетов, едущих от инициирующего хоста - как выглядит
> такое правило?

Попробуйте так:
pass in on $your_if proto tcp from any to $your_addrs flags SA/SA keep state

Плюс это, если другими правилами прием SYN-пакетов у вас не запрещен:
block in on $your_if proto tcp from any to $your_addrs flags S/SA


Reply | Threaded
Open this post in threaded view
|

Re: pf и асиметричный раутинг

Ilya A. Kovalenko
In reply to this post by Igor Grabin
> если так исторически сложилось, что мне нужно через pf пропускать
> 'встречные' пакеты tcp-потока, то есть он не видит изначального syn'а,
> и вообще всех пакетов, едущих от инициирующего хоста - как выглядит
> такое правило?
> логика подсказывает, что нужно отключать scrub. дальше логика в данном
> вопросе сдала.

> то, что сеть бы перестроить так, чтобы таких вопросов не возникало -
> тоже ответ, но я его и сам знаю. :-)

кроме всего, правила должны быть stateless, иначе будут работать
только медленные соединения, вроде консоли и т.п. а быстрые будут
убиваться в одном из направлений (не видя ACKs в одном из направлений
фильтр пропускает пакеты данных не выше некой скорости, а что выше ее
- не ассоциируется со state-ом и дропается, видимо, как флуд-атака)

комментарий Henning Brauer (HB):

Me>> 1.2 Too restictive (without option to weak restrictions)
Me>>     You cannot use PF's stateful inspection, if you're using
Me>>     asymmetrical and/or dynamic routing (i.e. than gateway does not
Me>>     control both inbound & outbound traffic directions), for example,
Me>>     in case of 2 gateways on network.
Me>>
Me>>     Otherwise, PF will harm your traffic. For example, PF will break
Me>>     fast TCP-connections, because will consider it flood attacks
Me>>     when can't see back ACK-s ...

HB> well, that is not true as written, but there is some truth to it. It
HB> has annoyed me in the past, I plan to fix that somewhen in the future.


Reply | Threaded
Open this post in threaded view
|

Ha: pf и асиметричный раутинг

Vasiliy.Bochin
In reply to this post by Igor Grabin
У меня примерно такая-же проблема, после продолжительных экспериментов на
такие потоки было поставлено правило no state.


С уважением, Бочин Василий
Главный специалист по безопасности
внешних и корпоративных информационных систем

"Igor 'CacoDem0n' Grabin" <[hidden email]> wrote on 06.12.2007 02:42:49:

> Утро добрым иногда бывает,
>
> если так исторически сложилось, что мне нужно через pf пропускать
> 'встречные' пакеты tcp-потока, то есть он не видит изначального syn'а,
> и вообще всех пакетов, едущих от инициирующего хоста - как выглядит
> такое правило?
> логика подсказывает, что нужно отключать scrub. дальше логика в данном
> вопросе сдала.
>
> то, что сеть бы перестроить так, чтобы таких вопросов не возникало -
> тоже ответ, но я его и сам знаю. :-)
>
> --
> Igor "CacoDem0n" Grabin, http://violent.death.kiev.ua/
>
>

Reply | Threaded
Open this post in threaded view
|

Re: pf и асиметричный раутинг

Pavel Labushev
In reply to this post by Pavel Labushev

> Попробуйте так:
> pass in on $your_if proto tcp from any to $your_addrs flags SA/SA keep
> state

Из-за того, что у PF, как выясняется, проблемы со стейтами на
асинхронных потоках, в голову приходит только такой вариант: оставить
правило, блокирующее входящие транзитные SYN-пакеты, остальные
разрешить. Тогда любой входящий трафик либо будет принят конечными
узлами в рамках сессий, инициированных ими же, либо отброшен.

Модулировать параметры пакетов при такой схеме не получится в обоих
случаях, это оставляет больше возможностей для инъекций. Конфиг сети
нужно менять.

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

> Плюс это, если другими правилами прием SYN-пакетов у вас не запрещен:
> block in on $your_if proto tcp from any to $your_addrs flags S/SA