> Ну тогда и не надо кричать. Надо уметь
>честно признаваться, что "у нас вот этого вот нет, и это
>плохо". Ооох... заглянем в в man:
http://www.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&s...
no-df - есть.
min-ttl - есть
max-mss - есть
random-id - нет(реально, зачем оно надо?)
fragment reassemble
Using scrub rules, fragments can be reassembled by normalization.
In this case, fragments are buffered until they form a complete
packet, and only the completed packet is passed on to the filter.
The advantage is that filter rules have to deal only with complete
packets, and can ignore fragments. The drawback of caching frag-
ments is the additional memory cost. But the full reassembly
method is the only method that currently works with NAT. This is
the default behavior of a scrub rule if no fragmentation modifier
is supplied.
- потенциальный DoS на память. Опять же, зачем это?
fragment crop - опять же, зачем? (плюс fragment crop reassembly mechanism does not yet work with NAT.)
reassemble tcp - всё это есть в iptables.
> Это и есть путь к конструктиву, если фича
>_действительно_ мегакрутая, а не чушь типа сравнения длин пакетов.
не сравнения, а матчинга по длине пакета.
> Во FreeBSD есть значительно более общий способ исследования
>пакетов -- NetGraph. Но включая его, админ берёт на себя ответственность
>за снижение пакетной производительности маршрутизатора из-за удлинения packet flow path.
ага-ага. И эротические экзерцисы с ng_bpf и её своеобразным языком?
Опять же, поиск по маске вы так не сделаете.
> А вот в пакетный фильтр вставлять "тяжёлые" фичи,
>на мой взгляд, конечно -- совершенно не нужно.
iptables - модульный, в отличие от pf.
И кстати, как по-другому эти "тяжелые" фичи реализовать?
btw, написание модулей для iptables весьма просто + внятная документация.
>Для защиты хостов за пакетным фильтром от SYN-based
>атак. А для чего вообще нужен пакетный фильтр, как не для
>защиты хостов за ним?-)
да ну? злоумышленник начнёт бомбить пакетами по 64к мелкими фрагментами и хосту с pf станет плоха. И state modulation - это костыль против ОС с плохой генерацией ISN, а не средство защиты от SYN-flood.
> Правильно! Вот пусть какой-нибудь Asterisk и красит свой
>голосовой траффик! Он же его генерирует -- а пакетный фильтр-то тут
>при чём?!
ага-ага. Только когда у вас 50-60 sip-устройств проще покрасить на шлюзе.
Тем более это куда более правильно с точки зрения безопасности, т.к. в противном случае
_любой_ источник bulk-трафика может поставить раком voip, покрасив свой трафик как ему вздумается. ы?
> Какие Юниксовые распространённые серверные приложения поддерживают SCTP?
cisco pgw-2200. И кстати, причём тут софт? pf стоит на роутере, а за роутером может быть целый зоопарк устройств.
>SYN-флуд фильтруется PF'ным synproxy. Длины пакетов тут ни
>при чём.
ок, закройте pf'ом skype, не тронув dns & rtp.
> А L7-filtering, опять-таки, IMHO, конечно, слишком "тяжёл" для
>того, чтобы его включать в пакетный фильтр, да и малопригоден в
>случае, например, смены протокола. Ядро хачить каждый раз?
Вот для этого и нужен анализ по длине пакета и модули, которые вам кажутся ненужными.
На примере того же skype:
Сначала отбираем udp пакеты + опр. длины. А потом уже отправляем на L7-filter.
pf так может?
>Надо фильтрануть/зашейпить Skype/пиринговые сети -- NetGraph вам в
>руки, только вот зачем?..
зачем? Чтобы несколько десятков юзеров не уложили всё торрентами, чтобы фильтровать нежелательный skype etc.
А с netgraph ещё помучиться придётся.
>> PS: а вот интересно, почему не обратили внимание на такую вещь: pf
>> - это пакетный фильтр, а iptables - это скорее язык программирования
>> правил фильтрации(переходы, возвраты, проверки условий, итп).
> Что называется английским словом "overbloated". :)
> И вызывает сложности в отладке.
в чём сложности? каждый модуль можно отлаживать отдельно, логика iptables весьма прозрачна, traffic path в картинках есть, производить действия над пакетом можно в любой момент. Хоть до nat, хоть после.
