URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 37272
[ Назад ]

Исходное сообщение
"OpenNews: Обзор последних новшеств в пакетном фильтре PF"

Отправлено opennews , 24-Апр-07 14:35 
В обзоре "What's new with PF in 4.1? (http://undeadly.org/cgi?action=article&sid=20070424020008)" рассказано о новшествах пакетного фильтра PF, вошедшего в комплект операционной системы OpenBSD 4.1 (http://www.openbsd.org/41.html), релиз которой намечен на 1 мая 2007 года.


-  "keep state" включен по умолчанию для "pass" правил, для отмены слежения за состоянием соединения нужно явно указывать "no state";
-  флаг S/SA (out of SYN and ACK, exactly SYN may be set) используется по умолчанию для TCP сессий для которых включен контроль состояния;
-  оптимизатор правил может быть включен через pf.conf (set ruleset-optimization basic);
-  утилита pfctl может использоваться для задания времени жизни записей в таблицах состояния (pfctl -t badssh -T expire 86400);
-  новый демон для балансировки нагрузки hoststated;
-  возможность использования нескольких раздельных псевдоинтерфейсов в pflog и pfsync;
-  средства для прямого указания макросов-контейнеров правил (anchor) в файле pf.conf (ранее только через включение из внешнего файла).
-  в pf может манипулировать несколькими таблицами маршрутизации (rtable).

URL: http://undeadly.org/cgi?action=article&sid=20070424020008
Новость: http://www.opennet.me/opennews/art.shtml?num=10572


Содержание

Сообщения в этом обсуждении
"Обзор последних новшеств в пакетном фильтре PF"
Отправлено hedgehog , 24-Апр-07 14:35 
а как с динамическим управлением шириной каналов, можно это сделать?

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 08:47 
Class-based queueing для "тупого" CBWFQ, Hierarchical Fair Service Curve для сервисов, требующих гарантированного времени прохода пакета.
HFSC настраивается немного сложновато, но на асимметричных каналах работает лучше классически применяемого для аналогичных целей HTB (на симметричных каналах обе дисциплины работают примерно одинаково хороошо).

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено belkin , 24-Апр-07 15:49 
Как и прежде - ни одной приктически полезной дисциплины. При сравнении pf, ipf и ipfw можно понять, что только в FreeBSD, что характерно, в родном ipfw это сделано для реального использования а не для "галочки".

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено belkin , 24-Апр-07 15:52 
Это я про Traffic Control.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Linus Torvalds , 24-Апр-07 21:41 
А можно пример "одной приктически полезной дисциплины" ... а то может я чего пропустил?

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Dyr , 24-Апр-07 22:20 
+1.
Где, блин, аналог dummynet'овских раздаваний отдельных очередей на каждый ip одной маской?
Будет ли destination NAT для пула адресов?

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 08:44 
> Будет ли destination NAT для пула адресов?
Э-э-э-э-э?

Это как?

А что, его не было когда-то?

===
     bitmask
           The bitmask option applies the network portion of the redirection
           address to the address to be modified (source with nat, destination
           with rdr).
===

pf.conf(5) не читан?


"Обзор последних новшеств в пакетном фильтре PF"
Отправлено belkin , 24-Апр-07 15:51 
Тогда уж и quick сделали по-умолчанию - чего уж там.

"PF :("
Отправлено WAG , 24-Апр-07 20:52 
Единственные плюсы PF -работа с таблицами адресов и удобный NAT.
Но для регулировки скорости -IPFW.
Так что пока два фаерволла оставляем :(
А хотелось бы один!

"PF :("
Отправлено guest , 24-Апр-07 21:19 
iptables - only and forever.

"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 08:51 
Оно уже научилось делать rate limit control со складываением оверлоадящих хостов в таблицу, доступную для манипуляции извне (из userland'а)?

"PF :("
Отправлено Дохтур , 25-Апр-07 09:10 
А практическое применение этому можно?

Гораздо болеее интересна ситуация, когда у нас есть сеть /22, которая разбита на 4 сетки по /24. Каждому хосту в 1й /24 надо дать 256кбит/с, каждому во 2й - 512кбит/с, каждому в 3й - 1мбит/с, а 4й отдать остатки.


"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 09:23 
> А практическое применение этому можно?
Ну, хотя бы вот такое, хрестоматийное (взято, кстати, по наводке с OpenNet.ru):

===
table <ssh-bruteforce> persist

pass all

block drop in quick on $if_195 from <ssh-bruteforce> probability 65%
block drop in quick on $if_62 from <ssh-bruteforce> probability 65%

pass in quick on $if_195 inet proto tcp from any to $if_195_ip port ssh flags S/SFRA keep state \
        (max-src-conn 5, max-src-conn-rate 3/60, overload <ssh-bruteforce> flush global)
pass in quick on $if_62 inet proto tcp from any to $if_62_ip port ssh flags S/SFRA keep state \
        (max-src-conn 5, max-src-conn-rate 3/60, overload <ssh-bruteforce> flush global)
===

Можно не обязательно block drop, можно, там, шейперу скормить, или ещё что-нибудь...

> Гораздо болеее интересна ситуация, когда у нас есть сеть /22, которая разбита на 4 сетки > по /24. Каждому хосту в 1й /24 надо дать 256кбит/с, каждому во 2й - 512кбит/с, каждому в > 3й - 1мбит/с, а 4й отдать остатки.
CBQ вполне с этим справляется. Делается суперкласс на пропускную способность апстрима, классы на каждую из трёх сетей с фиксированной bandwidth и borrow от суперкласса, и четвёртый класс на четвёртую сеть просто с borrow из суперкласса.


"PF :("
Отправлено Дохтур , 25-Апр-07 09:51 
Ну так это... есть модуль recent в iptables. Содержимое его таблиц доступно через /proc, так что каких-либо проблем не вижу.

>CBQ вполне с этим справляется. Делается суперкласс на пропускную способность апстрима, >классы на каждую из трёх сетей с фиксированной bandwidth и borrow от суперкласса

ага-ага. И как у вас полоса поделится внутри одного класса? Какпопало? Всемпоровну?


"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 10:29 
> Ну так это... есть модуль recent в iptables. Содержимое его таблиц доступно через /proc, так что каких-либо проблем не вижу.
А поменять их тоже можно через /proc?

> ага-ага. И как у вас полоса поделится внутри одного класса? Какпопало? Всемпоровну?
Per flow.


"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 10:33 
>> ага-ага. И как у вас полоса поделится внутри одного класса? Какпопало? Всемпоровну?
> Per flow.
Можно, кстати, и per IP (wrr включить).

"PF :("
Отправлено dem , 25-Апр-07 23:44 
wrr - Где можно почитать? давно искал подобное для опенка.

"PF :("
Отправлено Дохтур , 25-Апр-07 10:40 
>А поменять их тоже можно через /proc?
а зачем? и прочитали бы вы man iptables в той части что про recent.
Вообще, всё что насчёт таблиц есть ipset.

>Per flow.
Ага-ага. Только вот внутри класса надо каждому хосту гарантированные 256/512/etc и не более, а не per flow.


"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 10:50 
>> А поменять их тоже можно через /proc?
> а зачем?
А хочется. Вот меня всегда убивал аргумент типа "если мы это не умеем, значит, вам это не нужно".
Я спросил _сразу_ про возможность манипуляции через userland.
Йопта, чтобы со snort'ом сдружить хитрыми скриптами!

"PF :("
Отправлено Дохтур , 25-Апр-07 12:05 
вообще-то, можно ручками добавлять/выносить. Причём выносить можно как позвав iptables -m recent --remove bla-bla-bla, так и как в мане:

Each  file in /proc/net/ipt_recent/ can be read from to see the current
       list or written two using the following commands to modify the list:

       echo xx.xx.xx.xx > /proc/net/ipt_recent/DEFAULT
              to Add to the DEFAULT list

       echo -xx.xx.xx.xx > /proc/net/ipt_recent/DEFAULT
              to Remove from the DEFAULT list

       echo clear > /proc/net/ipt_recent/DEFAULT
              to empty the DEFAULT list.


"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 13:31 
Мнда. Посмотрел я на этот ipt_recent. Удивительная поделка. Она стэйты как дропает? Я, честно говоря, не понял.

"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 10:54 
>> Per flow.
> Ага-ага. Только вот внутри класса надо каждому хосту гарантированные 256/512/etc и не
> более, а не per flow.
Тогда это делается выносом каждого хоста в отдельный класс.
Согласен, что конфиг получается жопным, и никакого решения, кроме генерации его скриптом нет.

"PF :("
Отправлено Дохтур , 25-Апр-07 11:12 
>Тогда это делается выносом каждого хоста в отдельный класс.

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

>Согласен, что конфиг получается жопным, и никакого решения, кроме генерации его скриптом нет.

К сожалению, у pf много таких вот неочевидных проблем много. Можно ещё вспомнить прохождение через nat "проблемных" протоколов вроде ftp/pptp etc...


"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 11:48 
>> Тогда это делается выносом каждого хоста в отдельный класс.
> ага. и т.к. задание полноклассовой дисциплиной может быть кто-то один
> (т.е. либо вешаем cbq и отказываемся от hfsc, либо вешаем hfsc и забываем про cbq),
> то упираемся в лимит на количество очередей в hfsc.
    Ну, про HFSC в оригинальном задании не было ни слова, а у CBQ таких ограничений нет, да и пересобрать ядро с повышенным количеством HFSC-классов -- тоже не rocket science, просто дело в том, что ставить FreeBSD для обеспечения HFSC QoS для ТЫСЯЧИ хостов -- это какая-то не совсем тривиальная задача. ;)

>> Согласен, что конфиг получается жопным, и никакого решения, кроме генерации его
>> скриптом нет.
> К сожалению, у pf много таких вот неочевидных проблем много.
    Проблемы _PF_ я здесь не вижу в принципе. Это проблема, скорее, ALTQ, которая появилась лет за семь до PF.

> Можно ещё вспомнить прохождение через nat "проблемных" протоколов вроде ftp/pptp etc...
    Ну, net/ftpsesame решает проблемы с FTP, а что касается PPTP -- то тут, безусловно, жопа. Но, строго говоря, и с IPFW жопы меньше не становится.


"PF :("
Отправлено Dyr , 26-Апр-07 17:49 
>> что
>>касается PPTP -- то тут, безусловно, жопа. Но, строго говоря, и
>с IPFW жопы меньше не становится.
Какая ещё жопа у вас между ipfw и PPTP??



"PF :("
Отправлено гомег , 27-Апр-07 22:47 
>    Ну, net/ftpsesame решает проблемы с FTP, а что
>касается PPTP -- то тут, безусловно, жопа. Но, строго говоря, и
>с IPFW жопы меньше не становится.

Тоже интересно стало про жопу, работаю с этой связкой уже долгое время и не разу не напарывался, просветите где грабли лежат, чтоб заранее их стороной обойти


"PF :("
Отправлено GateKeeper , 28-Апр-07 07:06 
Сколько PPTP-сессий одновременно ходят через Ваш pf?

"PF :("
Отправлено Dyr , 28-Апр-07 09:01 
>Сколько PPTP-сессий одновременно ходят через Ваш pf?
У нас ipfw, но сути это менять не должно. PPTP самый обычный маршрутизируемый протокол, и инкапсулирует, в отличии от PPPoE, всю информацию в теле пакета с данными, а не поверх заголовков.
Так что открываете порт 1723 и не паритесь =)

"PF :("
Отправлено GateKeeper , 28-Апр-07 16:19 
С GRE как поступаете?

"PF :("
Отправлено Dyr , 28-Апр-07 23:19 
>С GRE как поступаете?
ipfw allow gre from any to any

"PF :("
Отправлено GateKeeper , 29-Апр-07 15:12 
http://groups.google.com/group/mailing.freebsd.net/browse_th...

Это очень старый тред, но там достаточно чётко описали проблему демультиплексирования GRE-сессий в NAT.


"PF :("
Отправлено Freedom , 28-Апр-07 16:27 
>>Сколько PPTP-сессий одновременно ходят через Ваш pf?
>У нас ipfw, но сути это менять не должно. PPTP самый обычный
>Так что открываете порт 1723 и не паритесь =)
в PPTP опеределено, что с одного src IP может быть один коннект, для ведения таблицы nat в libalias сделали (приятное) ухищирение в виде отслеживанния  Call ID самой сесии.

детали
src/sys/netinet/libalias/alias_pptp.c


"PF :("
Отправлено Dyr , 28-Апр-07 23:20 
>>>Сколько PPTP-сессий одновременно ходят через Ваш pf?
>>У нас ipfw, но сути это менять не должно. PPTP самый обычный
>>Так что открываете порт 1723 и не паритесь =)
> в PPTP опеределено, что с одного src IP может быть один
>коннект, для ведения таблицы nat в libalias сделали (приятное) ухищирение в
>виде отслеживанния  Call ID самой сесии.
>
>детали
>src/sys/netinet/libalias/alias_pptp.c
Не сталкивались пока с такой необходимостью.
Кстати, пользуем ng_nat

"PF :("
Отправлено Freedom , 06-Май-07 16:56 
>>виде отслеживанния  Call ID самой сесии.
>>
>>детали
>>src/sys/netinet/libalias/alias_pptp.c
>Не сталкивались пока с такой необходимостью.
везет :)
>Кстати, пользуем ng_nat
он сделан на базе ядерной libalias.



"PF :("
Отправлено Осторожный , 25-Апр-07 08:27 
Таблицы адресов есть и в ipfw

NAT через natd :)


"PF :("
Отправлено Andrew Kolchoogin , 25-Апр-07 08:45 
> NAT через natd :)
Времени микропроцессора на copyin()/copyout() не жалко?

"PF :("
Отправлено michelle , 25-Апр-07 10:10 
Угум!

Таблицы адресов есть, а ты можешь в одну таблицу вогнать очень много адресов???
Насколько я помню, длина строки там (ipfw) не более чем 255 символов!


"PF :("
Отправлено belkin , 25-Апр-07 12:59 
В PF ещё Traffic Normalization (e.g. scrub) полезен.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено dem , 24-Апр-07 21:32 
to belkin & co
Все что написал - бред сивой кобылы или не пробовал HFSC.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Дохтур , 25-Апр-07 09:12 
btw, у hfsc есть лимит на количество очередей.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 09:26 
А у keep-state есть лимит на количество динамических правил. Во _всех_ firewall'ах. И что теперь, пойти топиться в ближайшей луже?

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Дохтур , 25-Апр-07 09:54 
>А у keep-state есть лимит на количество динамических правил. Во _всех_ firewall'ах. И что теперь, пойти топиться в ближайшей луже?

Ну в netfilter количество стейтов ограничено лишь количеством доступной памяти.
А число очередей в hfsc by default 64шт(и их количество hardcoded)


"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 10:32 
Ах, вот ты про что. Тогда не очередей, а классов, это разные вещи.
Ну, поправь константу HFSC_MAX_CLASSES в altq_hfsc.h, и пересобери ядро, делов-то.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Дохтур , 25-Апр-07 11:19 
>Ну, поправь константу HFSC_MAX_CLASSES в altq_hfsc.h, и пересобери ядро, делов-то.
Это то да. А чего по дефолту столь маленькое значение?

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 11:44 
>> Ну, поправь константу HFSC_MAX_CLASSES в altq_hfsc.h, и пересобери ядро, делов-то.
> Это то да. А чего по дефолту столь маленькое значение?
А зачем больше-то?
Я так понимаю, это всё идёт ещё от оригинального ALTQ им. Sony Computing Laboratory, видимо, японцам так показалось адекватным. ;)

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено BB , 24-Апр-07 21:57 
Судя по всему господа не видели реализации pf опене, так как во фре он кастрированный.Так что советую изначально внимательно прочитать заголовок новости, а потом уже нести свой "свободный поток сознания" :Е

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Аноним , 25-Апр-07 06:45 
+1 freebsd'ишки пальцы веером и вперед. Прям атака клоунов, блин.:) Как еще linux и iptables при этом не задели.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 08:54 
А что, в OpenBSD уже спортировали NetGraph?-)

Нет?

То есть, mpd работать не будет? Мне не удастся лишить себя на OpenBSD'шном PPTP- (PPPoE-)концентраторе счастья видеть мульён запущеных ppoed/pptpd/pppd?


"Обзор последних новшеств в пакетном фильтре PF"
Отправлено BB , 25-Апр-07 21:18 
А зачем оно ? :)Вернее спросим по другому, какие задачи можно решить исключительно с помощью netgraph и которые имеют непосредственное отношение к функциям fw ?

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено belkin , 26-Апр-07 10:45 
>А зачем оно ? :)Вернее спросим по другому, какие задачи можно решить
>исключительно с помощью netgraph и которые имеют непосредственное отношение к функциям
>fw ?

Потому что сказали о Linux с iptables вместо FreeBSD с PF. А мы ответили, что у Linux'a нет аналога MPD, а его главное непобедимое пока преимущество основано на применении ng.


"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 08:50 
Э-э-э? И чем же он кастрированный? Конечно, multiple kernel forwarding tables во FreeBSD нет (пока?), тут я не спорю, ну а так -- реализация практически идентична.
Хотя, бесспорно, в OpenBSD все новшества появляются быстрее, PF под Опёнком разрабатывается.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Till , 24-Апр-07 23:48 
Зато работает в ядре и ALTQ есть.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Stelz , 24-Апр-07 23:57 
Мда.. естественно, эта новость не для поклоняющихся freebsd..

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Дохтур , 25-Апр-07 09:14 
всяким поклоняющимся место в храме/у идола.
Личные предпочтения не должны играть роли при выборе рабочего инструмента.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 09:24 
-1

Самая короткая дорога -- та, которую лучше всего знает водитель.
Самый лучший инструмент -- тот, которым лучше всего владеет тот, кого заставляют работать.


"Обзор последних новшеств в пакетном фильтре PF"
Отправлено TrecK , 26-Апр-07 17:34 
+1

абсолютно точно

>-1
>
>Самая короткая дорога -- та, которую лучше всего знает водитель.
>Самый лучший инструмент -- тот, которым лучше всего владеет тот, кого заставляют
>работать.



"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Осторожный , 25-Апр-07 08:26 
Почему это ?
Надеюсь в следующий релиз FreeBSD скорее всего портируют новую версию pf.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Аноним , 25-Апр-07 10:06 
iptables and iproute рулит уже давно ))))

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 10:34 
Да? Его уже попатчили на предмет неработы нескольких таблиц роутинга на ATM-интерфейсах?-)
Люблю слово "рулит" для подсистем, в которых с каждой новой версией ядра что-то новое ломают. ;)

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Дохтур , 25-Апр-07 12:06 
>Да? Его уже попатчили на предмет неработы нескольких таблиц роутинга на ATM-интерфейсах?-)

позвольте спросить, а где ж вам пришлось с этим столкнуться?


"Обзор последних новшеств в пакетном фильтре PF"
Отправлено Andrew Kolchoogin , 25-Апр-07 13:26 
>> Да? Его уже попатчили на предмет неработы нескольких таблиц роутинга на
>> ATM-интерфейсах?-)
> позвольте спросить, а где ж вам пришлось с этим столкнуться?
Буквально на предыдущем месте работы.

"Обзор последних новшеств в пакетном фильтре PF"
Отправлено BB , 25-Апр-07 21:22 
согласен с предыдущим оратором, все прелесть pf (да и остальных базовых систем) в составе OpenBSD это его неразрывная жесткая связь с ядром системы. Так сказать некая защита от человеческого фактора. Чем такое решение и подкупает :)