В обзоре "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
а как с динамическим управлением шириной каналов, можно это сделать?
Class-based queueing для "тупого" CBWFQ, Hierarchical Fair Service Curve для сервисов, требующих гарантированного времени прохода пакета.
HFSC настраивается немного сложновато, но на асимметричных каналах работает лучше классически применяемого для аналогичных целей HTB (на симметричных каналах обе дисциплины работают примерно одинаково хороошо).
Как и прежде - ни одной приктически полезной дисциплины. При сравнении pf, ipf и ipfw можно понять, что только в FreeBSD, что характерно, в родном ipfw это сделано для реального использования а не для "галочки".
Это я про Traffic Control.
А можно пример "одной приктически полезной дисциплины" ... а то может я чего пропустил?
+1.
Где, блин, аналог dummynet'овских раздаваний отдельных очередей на каждый ip одной маской?
Будет ли destination NAT для пула адресов?
> Будет ли 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) не читан?
Тогда уж и quick сделали по-умолчанию - чего уж там.
Единственные плюсы PF -работа с таблицами адресов и удобный NAT.
Но для регулировки скорости -IPFW.
Так что пока два фаерволла оставляем :(
А хотелось бы один!
iptables - only and forever.
Оно уже научилось делать rate limit control со складываением оверлоадящих хостов в таблицу, доступную для манипуляции извне (из userland'а)?
А практическое применение этому можно?Гораздо болеее интересна ситуация, когда у нас есть сеть /22, которая разбита на 4 сетки по /24. Каждому хосту в 1й /24 надо дать 256кбит/с, каждому во 2й - 512кбит/с, каждому в 3й - 1мбит/с, а 4й отдать остатки.
> А практическое применение этому можно?
Ну, хотя бы вот такое, хрестоматийное (взято, кстати, по наводке с OpenNet.ru):===
table <ssh-bruteforce> persistpass 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 из суперкласса.
Ну так это... есть модуль recent в iptables. Содержимое его таблиц доступно через /proc, так что каких-либо проблем не вижу.>CBQ вполне с этим справляется. Делается суперкласс на пропускную способность апстрима, >классы на каждую из трёх сетей с фиксированной bandwidth и borrow от суперкласса
ага-ага. И как у вас полоса поделится внутри одного класса? Какпопало? Всемпоровну?
> Ну так это... есть модуль recent в iptables. Содержимое его таблиц доступно через /proc, так что каких-либо проблем не вижу.
А поменять их тоже можно через /proc?> ага-ага. И как у вас полоса поделится внутри одного класса? Какпопало? Всемпоровну?
Per flow.
>> ага-ага. И как у вас полоса поделится внутри одного класса? Какпопало? Всемпоровну?
> Per flow.
Можно, кстати, и per IP (wrr включить).
wrr - Где можно почитать? давно искал подобное для опенка.
>А поменять их тоже можно через /proc?
а зачем? и прочитали бы вы man iptables в той части что про recent.
Вообще, всё что насчёт таблиц есть ipset.>Per flow.
Ага-ага. Только вот внутри класса надо каждому хосту гарантированные 256/512/etc и не более, а не per flow.
>> А поменять их тоже можно через /proc?
> а зачем?
А хочется. Вот меня всегда убивал аргумент типа "если мы это не умеем, значит, вам это не нужно".
Я спросил _сразу_ про возможность манипуляции через userland.
Йопта, чтобы со snort'ом сдружить хитрыми скриптами!
вообще-то, можно ручками добавлять/выносить. Причём выносить можно как позвав 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 listecho -xx.xx.xx.xx > /proc/net/ipt_recent/DEFAULT
to Remove from the DEFAULT listecho clear > /proc/net/ipt_recent/DEFAULT
to empty the DEFAULT list.
Мнда. Посмотрел я на этот ipt_recent. Удивительная поделка. Она стэйты как дропает? Я, честно говоря, не понял.
>> Per flow.
> Ага-ага. Только вот внутри класса надо каждому хосту гарантированные 256/512/etc и не
> более, а не per flow.
Тогда это делается выносом каждого хоста в отдельный класс.
Согласен, что конфиг получается жопным, и никакого решения, кроме генерации его скриптом нет.
>Тогда это делается выносом каждого хоста в отдельный класс.ага. и т.к. задание полноклассовой дисциплиной может быть кто-то один(т.е. либо вешаем cbq и отказываемся от hfsc, либо вешаем hfsc и забываем про cbq), то упираемся в лимит на количество очередей в hfsc.
>Согласен, что конфиг получается жопным, и никакого решения, кроме генерации его скриптом нет.
К сожалению, у pf много таких вот неочевидных проблем много. Можно ещё вспомнить прохождение через nat "проблемных" протоколов вроде ftp/pptp etc...
>> Тогда это делается выносом каждого хоста в отдельный класс.
> ага. и т.к. задание полноклассовой дисциплиной может быть кто-то один
> (т.е. либо вешаем 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 жопы меньше не становится.
>> что
>>касается PPTP -- то тут, безусловно, жопа. Но, строго говоря, и
>с IPFW жопы меньше не становится.
Какая ещё жопа у вас между ipfw и PPTP??
> Ну, net/ftpsesame решает проблемы с FTP, а что
>касается PPTP -- то тут, безусловно, жопа. Но, строго говоря, и
>с IPFW жопы меньше не становится.Тоже интересно стало про жопу, работаю с этой связкой уже долгое время и не разу не напарывался, просветите где грабли лежат, чтоб заранее их стороной обойти
Сколько PPTP-сессий одновременно ходят через Ваш pf?
>Сколько PPTP-сессий одновременно ходят через Ваш pf?
У нас ipfw, но сути это менять не должно. PPTP самый обычный маршрутизируемый протокол, и инкапсулирует, в отличии от PPPoE, всю информацию в теле пакета с данными, а не поверх заголовков.
Так что открываете порт 1723 и не паритесь =)
С GRE как поступаете?
>С GRE как поступаете?
ipfw allow gre from any to any
http://groups.google.com/group/mailing.freebsd.net/browse_th...Это очень старый тред, но там достаточно чётко описали проблему демультиплексирования GRE-сессий в NAT.
>>Сколько PPTP-сессий одновременно ходят через Ваш pf?
>У нас ipfw, но сути это менять не должно. PPTP самый обычный
>Так что открываете порт 1723 и не паритесь =)
в PPTP опеределено, что с одного src IP может быть один коннект, для ведения таблицы nat в libalias сделали (приятное) ухищирение в виде отслеживанния Call ID самой сесии.детали
src/sys/netinet/libalias/alias_pptp.c
>>>Сколько PPTP-сессий одновременно ходят через Ваш pf?
>>У нас ipfw, но сути это менять не должно. PPTP самый обычный
>>Так что открываете порт 1723 и не паритесь =)
> в PPTP опеределено, что с одного src IP может быть один
>коннект, для ведения таблицы nat в libalias сделали (приятное) ухищирение в
>виде отслеживанния Call ID самой сесии.
>
>детали
>src/sys/netinet/libalias/alias_pptp.c
Не сталкивались пока с такой необходимостью.
Кстати, пользуем ng_nat
>>виде отслеживанния Call ID самой сесии.
>>
>>детали
>>src/sys/netinet/libalias/alias_pptp.c
>Не сталкивались пока с такой необходимостью.
везет :)
>Кстати, пользуем ng_nat
он сделан на базе ядерной libalias.
Таблицы адресов есть и в ipfwNAT через natd :)
> NAT через natd :)
Времени микропроцессора на copyin()/copyout() не жалко?
Угум!Таблицы адресов есть, а ты можешь в одну таблицу вогнать очень много адресов???
Насколько я помню, длина строки там (ipfw) не более чем 255 символов!
В PF ещё Traffic Normalization (e.g. scrub) полезен.
to belkin & co
Все что написал - бред сивой кобылы или не пробовал HFSC.
btw, у hfsc есть лимит на количество очередей.
А у keep-state есть лимит на количество динамических правил. Во _всех_ firewall'ах. И что теперь, пойти топиться в ближайшей луже?
>А у keep-state есть лимит на количество динамических правил. Во _всех_ firewall'ах. И что теперь, пойти топиться в ближайшей луже?Ну в netfilter количество стейтов ограничено лишь количеством доступной памяти.
А число очередей в hfsc by default 64шт(и их количество hardcoded)
Ах, вот ты про что. Тогда не очередей, а классов, это разные вещи.
Ну, поправь константу HFSC_MAX_CLASSES в altq_hfsc.h, и пересобери ядро, делов-то.
>Ну, поправь константу HFSC_MAX_CLASSES в altq_hfsc.h, и пересобери ядро, делов-то.
Это то да. А чего по дефолту столь маленькое значение?
>> Ну, поправь константу HFSC_MAX_CLASSES в altq_hfsc.h, и пересобери ядро, делов-то.
> Это то да. А чего по дефолту столь маленькое значение?
А зачем больше-то?
Я так понимаю, это всё идёт ещё от оригинального ALTQ им. Sony Computing Laboratory, видимо, японцам так показалось адекватным. ;)
Судя по всему господа не видели реализации pf опене, так как во фре он кастрированный.Так что советую изначально внимательно прочитать заголовок новости, а потом уже нести свой "свободный поток сознания" :Е
+1 freebsd'ишки пальцы веером и вперед. Прям атака клоунов, блин.:) Как еще linux и iptables при этом не задели.
А что, в OpenBSD уже спортировали NetGraph?-)Нет?
То есть, mpd работать не будет? Мне не удастся лишить себя на OpenBSD'шном PPTP- (PPPoE-)концентраторе счастья видеть мульён запущеных ppoed/pptpd/pppd?
А зачем оно ? :)Вернее спросим по другому, какие задачи можно решить исключительно с помощью netgraph и которые имеют непосредственное отношение к функциям fw ?
>А зачем оно ? :)Вернее спросим по другому, какие задачи можно решить
>исключительно с помощью netgraph и которые имеют непосредственное отношение к функциям
>fw ?Потому что сказали о Linux с iptables вместо FreeBSD с PF. А мы ответили, что у Linux'a нет аналога MPD, а его главное непобедимое пока преимущество основано на применении ng.
Э-э-э? И чем же он кастрированный? Конечно, multiple kernel forwarding tables во FreeBSD нет (пока?), тут я не спорю, ну а так -- реализация практически идентична.
Хотя, бесспорно, в OpenBSD все новшества появляются быстрее, PF под Опёнком разрабатывается.
Зато работает в ядре и ALTQ есть.
Мда.. естественно, эта новость не для поклоняющихся freebsd..
всяким поклоняющимся место в храме/у идола.
Личные предпочтения не должны играть роли при выборе рабочего инструмента.
-1Самая короткая дорога -- та, которую лучше всего знает водитель.
Самый лучший инструмент -- тот, которым лучше всего владеет тот, кого заставляют работать.
+1абсолютно точно
>-1
>
>Самая короткая дорога -- та, которую лучше всего знает водитель.
>Самый лучший инструмент -- тот, которым лучше всего владеет тот, кого заставляют
>работать.
Почему это ?
Надеюсь в следующий релиз FreeBSD скорее всего портируют новую версию pf.
iptables and iproute рулит уже давно ))))
Да? Его уже попатчили на предмет неработы нескольких таблиц роутинга на ATM-интерфейсах?-)
Люблю слово "рулит" для подсистем, в которых с каждой новой версией ядра что-то новое ломают. ;)
>Да? Его уже попатчили на предмет неработы нескольких таблиц роутинга на ATM-интерфейсах?-)позвольте спросить, а где ж вам пришлось с этим столкнуться?
>> Да? Его уже попатчили на предмет неработы нескольких таблиц роутинга на
>> ATM-интерфейсах?-)
> позвольте спросить, а где ж вам пришлось с этим столкнуться?
Буквально на предыдущем месте работы.
согласен с предыдущим оратором, все прелесть pf (да и остальных базовых систем) в составе OpenBSD это его неразрывная жесткая связь с ядром системы. Так сказать некая защита от человеческого фактора. Чем такое решение и подкупает :)