В учебнике BSD дописан раздел (http://house.hcn-strela.ru/BSDCert/BSDA-course/apc.html) посвящённый пакетному фильтру OpenBSD. Данный раздел не является только переводом документации с официального сайта. Текст переработан и дополнен из других источников, снабжён собственными примерами.
В качестве примера на интеграцию пакетного фильтра с прочим программным окружением, показано как при помощи PF, syslog, python и SQLite осуществить защиту от bruteforce атак на SSH.URL: http://house.hcn-strela.ru/BSDCert/BSDA-course/apc.html
Новость: http://www.opennet.me/opennews/art.shtml?num=10683
Сообщения об опечатках высланы с помощью "Орфус".
Спасибо. Исправления появятся в следующем релизе.
>pass in on fxp0 proto tcp from any to any port ssh flags S/SA
>Приведённое правило пропускает весь TCP трафик c установленным флагом SYN, при >этом изучаются флаги SYN и ACK. Пакет с флагами SYN и ECE будет пропущен данным >правилом, а пакет в котором выставлены флаги SYN и ACK или просто ACK не будет >пропущен.Что за бред собачий сам это проверял с помощью hping'a - пакетного генератора.
Правило flags S/SA указывает на то что пропускаем все пакеты с флагами S и/или SA но не как не запрещаем, а вот пакет с флагами SYN и ECE точно не попадёт под это правило. автор ошибся грубо.
Это Вы грубо ошиблись, автор совершенно прав. Комбинация S/SA обозначает что проверяются флаги S и А (после слеша), пакет попадает под правило, только если S установлен, A - нет (перед слэшем). Состояние остальных флагов не принимается во внимание.
Вот выдержка из man pf.conf(5)flags <a>/<b> | /<b>
This rule only applies to TCP packets that have the flags <a> set
out of set <b>. Flags not specified in <b> are ignored. The flags
are: (F)IN, (S)YN, (R)ST, (P)USH, (A)CK, (U)RG, (E)CE, and C(W)R.flags S/S Flag SYN is set. The other flags are ignored.
flags S/SA Out of SYN and ACK, exactly SYN may be set. SYN,
SYN+PSH and SYN+RST match, but SYN+ACK, ACK and ACK+RST
do not. This is more restrictive than the previous
example.flags /SFRA
If the first set is not specified, it defaults to none.
All of SYN, FIN, RST and ACK must be unset.Из этого документа следует, что маска S/SA означает, то, что я и описал в "учебнике": Выставлен из влагов SYN и ACK выставлен только SYN. Маске соответствует пакет с флагом SYN, SYN+PSH и SYN+RST, но не соответсвует пакет c сочетаниями флагов SYN+ACK, ACK и ACK+RST.
Поэтому, если верить документации, прав я а не вы.
Причина разночтений, на мой взгляд, может заключаться в:
1) Некорректном эксперименте с hping. Например: пакету с флагами SYN+ACK предшествовал пакет SYN, и он прошёл благодаря опции keep state. Или пакет прошёл благодаря другим правилам фильтра.
2) Устаревшая версия пакетного фильтра. Пакетный фильтр бурно развивается, и возможно его поведение в этой области драматически изменилось со времени вашего эксперимента.Я не проводил своего эксперимента на эту тему. У меня нет причин не доверять документации. Но если я проведу эксперимент и, паче чаяния, увижу, что правы вы, а не авторы OpenBSD, то это будет откровенный баг, о котором надо заявить им в список рассылки, прежде всего.
>Пакетный фильтр бурно развивается, и возможно его поведение в этой области драматически изменилось
"драматически изменилось"?
Не надо так писать. Не надо засорять русский язык, это калька с английского
Очень хотелось бы в PDF'е весь документ увидеть.
Это отвлечёт меня не менее чем на месяц от написания текста. Текст, для меня превыше его оформления. Если вы лично готовы мне помочь, пишите на мыло. А пока рецепт такой: скачивайте учебник BSD одной страницей в формате HTML: http://house.hcn-strela.ru/BSDCert/BSDA-course/single.html и сохраните его в OpenOffice как PDF.
гм, вы вручную html верстаете? docbook не подходит? там напрягаться осбо не надо, хочешь хтмл, хочешь пдф, хочешь еще что...
>гм, вы вручную html верстаете? docbook не подходит? там напрягаться осбо не
>надо, хочешь хтмл, хочешь пдф, хочешь еще что...Это вам только кажется, что в dobook так всё просто. Надо вбухать в его руссификацию много часов. Больше разнообразных форматов - меньше текста. Я один. :(
русификация занимает от силы 5 мин (xml версия docbook'а), проверено на собственном опыте
Хорошо, давайте спишемся через мыло. Помогите мне и будет всем PDF. Моё мыло приведено на первой странице моей писанины: http://house.hcn-strela.ru/BSDCert/BSDA-course/index.html на самом верху.
Есть стандартный формат - HTML. Можете преобразовывать его во что угодно.
орфографическая ошибка на "главной"?!-- организовать сертификационный экзамен по черырём ->вериям<- систем BSD
[url://Sgibnev-CARP-2006]
2006. Сгибнев Михаил. hping2. http://www.opennet.me/base/net/carp_freebsd.txt.html .Должно быть что то, типа:
[url://Sgibnev-CARP-2006]
2006. Сгибнев Михаил. CARP(4) Руководство по интерфейсам ядра FreeBSD .
http://www.opennet.me/base/net/carp_freebsd.txt.html .
Спасибо. Будет исправлено в следующем релизе.
а мне в целом понравилось, хотя чувствуется некоторая незаконченность.
не освещены вопросы:
1)"покраски" трафика (DSCP/IP Precedence)
2)пропуска через NAT pptp/sip-клиентов.
3)hfsc, управление задеркой и джиттером(это то что после беглого просмотра заметил).
ого. вот это труд. спасибо, очень кстати
2 Евгений МиньковскийХочу добавить, что непосредственно в самом учебнике основной упор сделан на FreeBSD, насчёт OpenBSD есть довольно много неясностей и неточностей, и встречаются такие моменты когда вы пишите что такое есть, а на самом деле его в OpenBSD нет (уже во всяком случае). Например http://house.hcn-strela.ru/BSDCert/BSDA-course/ch02s12.html password.conf и auth.conf в OpenBSD на данный момент не используются. И ещё много подобный неточностей которые скорее всего спицифичны только для FreeBSD.
Желаю что-бы у вас всё получилось :)
Боюсь, что это неизбежно :( к тому моменту, когда я всё допишу, BSD уже выкинут на свалку истории и труд мой будет ценен долько для археологов :) Я смирился.По существу:
password.conf есть в NetBSD
auth.conf есть в FreeBSD и DragonFly BSDОб этом сказано в http://house.hcn-strela.ru/BSDCert/BSDA-course/apa.html
Там приведена полная сводная таблица всех обсуждаемых команд и файлов, в которой расписано какая команда и какой файл в какой операционной системе встречается.
Автору Огромное спасибо!
да-да, за работу мегареспект, спасибо огромное
Очень полезная работа. Надеюсь, что у автора все получится. Желаю ему удачи.А еще есть вопрос по одному скользкому моменту. Вот цитата из текста:
>Трансляция осуществляется до фильтрации. Правила фильтра увидят уже оттранслированные >пакеты.Из этого утверждения вытекает, что на машине с NAT невозможно фильтровать трафик от внутренних хостов. Было бы неплохо, чтобы было разъяснение по этому моменту.
Допустим у нас есть сеть 192.168.1.0/24 со шлюзом на *BSD с pf, который натит в IP 1.2.3.4
Хост 192.168.1.3 не должен иметь возможность достучаться до адреса 5.6.7.8 по 80 порту. iptables делает такое одним правилом. Приведите плиз пример конфига pf, который делает то-же самое.
Это утверждение касается порядка фильтрации трафика на одном интерфейсе. В твоем случае, как правило, используется такой вариант: фильтрация производится на том интерфейсе, который смотрит во внутреннюю сеть 192.168.1, а трансляция производится на внешнем интерфейсе.Но это далеко не единственный вариант. Можно редиректить отфильтрованный траффик внутр. сети во внешний мир на дополнительный loopback-интерфейс и на нем делать трансляцию. Это по-моему самый быстрый вариант.
На худой конец, pf позволяет менять последовательность обработки. Но это крайне не рекомендуется...
По этому вопросу есть не плохая иллюстрация.
http://homepage.mac.com/quension/pf/flow.png
Спасибо за иллюстрацию и за разъяснения. Вообще, было бы здорово чтобы этот вопрос более подробно освещался в руководстве. Надеюсь, что автор примет это к сведению.
> Это утверждение касается порядка фильтрации трафика на одном интерфейсе. В твоем случае, как правило, используется такой вариант: фильтрация производится на том интерфейсе, который смотрит во внутреннюю сеть 192.168.1, а трансляция производится на внешнем интерфейсе.
Интересно, а почему фильтрация пакета происходит в таком порядке? Не лучше ли было бы как в iptables фильтровать транзитные пакеты в порядке dnat-filter-snat?
> Можно редиректить отфильтрованный траффик внутр. сети во внешний мир на дополнительный loopback-интерфейс и на нем делать трансляцию. Это по-моему самый быстрый вариант.
Может проще маркировать транслируемые пакеты для последующей фильтрации на основе значения tag? Тут главное, чтобы другие правила случайно не заменили маркер.
>Интересно, а почему фильтрация пакета происходит в таком порядке? Не лучше ли было бы как в > iptables фильтровать транзитные пакеты в порядке dnat-filter-snat?А какая разница? Тогда бы точно так же возникали обратные вопросы.
Мне например, такой вариант намного удобней. Я пишу правила фильтрации на внешнем интерфейсе в контексте внешних адресов, не завязываясь на внутренее устройство сети. А фильтрация, завязанная на топологию внутренней сети и внутренние маршруты, производится на внутренних интерфейсах. И я для себя точно знаю, что если вдруг одна внутренняя сеть переехала с одного порта на другой или маршрутизация изменилась, то в правилах на внешнем порту мне точно ничего менять не нужно. Всему свое место...
>Может проще маркировать транслируемые пакеты для последующей фильтрации на основе значения
>tag? Тут главное, чтобы другие правила случайно не заменили маркер.Вот-вот... Чтобы, не заменили. Ты это еще должен вспомнить через полгода, когда вдруг понадобиться что-то поправить. Предложенный мною вариант чуть сложнее реализовать, но работать должно быстрее. А главное понятнее, когда через какое-то время снова залазишь в конфиг.
Было бы странно, если бы это было невозможно.ext_if=rl0
int_if=rl1
...
nat on $ext_if from $int_if:network to any -> $ext_if
...
block in quick on $int_if from 192.168.1.3 to 5.6.7.8 port 80
...Секрет в том, что трансляция осуществляется на внешнем интерфейсе, а фильтрация на внутреннем
Уважаемые господа, я вот сижу на BSD + ipfw, на Linux + iptables, на Windows + ISA. Мне несколько раз приходила мысль перетащить ipfw на pf, но вот что меня смущает... я как начну представлять логику работы, сразу встает вопрос, в чем преимущество пакетного фильтра у которого выигрывает последнее правило? Я что-то никак не уловлю здесь "правильной" философии, ведь если использовать политику "все запрещено кроме разрешенного", то каждый пакет будет проходить все правила... не влияет ли это на скорость обработки... в ipfw я самые часто срабатываемые правила перемещаю наверх и получается что в большинстве случаев у меня пакет обрабатывается всего несколькими правилами...
Я понимаю что есть "quick"... но что ж применять ко всем правилам его?
Лично мне тоже кажется, что такой порядок проверки не самый лучший. Однако, если верить тестам, при больших нагрузках pf показывает себя лучше, чем ipfw, идя примерно наравне с iptables.
Да, вы правы, такой порядок обработки правил снижает производительность брандмауера, хотя и весьма незначительно. Производительность пакетного фильтра всё равно выше, чем у ipfw (лично не проверял, пересказываю чужое мнение), повидимому за счёт более грамотного проектирования.Да, можно применять quick ко всем правилам. Неуклюже выглядит, согласен.
Можно при засасывании правил пременять команду
pfctl -oo -f /etc/myrules
При этом, теоретически, правило quick расставится само и логика будет примерно как у iptables (который и сам обладает рядом недостатков, хотя и не в этом месте).Наконец, не грех было бы задаться вопросом так ли вам нужна оптимизация? Дональд Кнут говорил: "преждевременная оптимизация - корень всех бед". Маловероятно, что ваш брандмауер работает на 486-й машине. В самом ли деле ваша полоса пропускания страдает от производительности брандмауера? Может быть, если у вас всё работает, то уже пора оставить всё как есть? :)
Да, и ещё: все пакеты всё равно сразу направляются в state-table (в отличие от iptables, где об этом надо ещё позаботиться). Поэтому основная масса пакетов вообще не пойдёт на правила фильтрации. Видимо это обстоятельство переводит данный диспут из разряда практического в разряд академического.
При объемах среднего офиса оптимизация шибко не требуется. А вот когда через роутер проходит нехилая часть сети класса Б (естественно, разбитой на подсети), то тут уже начинаешь задумываться...
> А вот когда через роутер проходит нехилая часть сети класса Б (естественно,
> разбитой на подсети), то тут уже начинаешь задумываться...
Которой всей срочно нужно в Интернет через единственную гигабитную кишку, вставленную во второй Ethernet-контроллер этого же роутера?Как-то это мне напоминает сферического коня в вакууме. А если через роутер проходит внутрисетевой траффик, то не лучше ли спроектировать сеть так, чтобы в ядре был L3-свитч помощнее?
Просто как ни оптимизируй программное обеспечение ЭВМ общего назначения, со специализированными ЭВМ с ASIC'ами на борту они всё равно соперничать не смогут, увы.
>Которой всей срочно нужно в Интернет через единственную гигабитную кишку, вставленную во второй Ethernet-контроллер этого же роутера?а зачем тогда этот роутер нужен, если есть гигабитная кошка? :)
И имхо, на машине с каким-нибудь athlon64 и nic-ми на pcie и гигабит можно зароутить.
Я не про Cisco. :) Кишка -- это, в смысле, гигабитный канал. ;)
>все пакеты всё равно сразу направляются в state-table (в отличие от iptables, где об этом надо ещё позаботиться).генерировать стейты по каждому чиху - имхо, дурной тон. И кстати, заботится как раз не надо.
Ручками заботиться надо именно в том случае, если через nat идёт протокол, нуждающийся в хелпере(вроде того же ftp).
>Производительность пакетного фильтра всё равно выше, чем у ipfw (лично не проверял,
пересказываю чужое мнение), повидимому за счёт более грамотного проектирования.категорически неверное высказывание.
советую посмотреть сюда: http://www.tancsa.com/blast.htmlГораздо интереснее вот что: умеет ли pf/ipfw на smp-системе раскидывать нагрузку по камням (матчить на разных процессорах)?
>Категорически неверное высказывание. советую посмотреть сюда: http://www.tancsa.com/blast.htmlУгу, ipfw быстрее. Я списался с автором теста, узнать, какие он использовал правила, дабы не было обвинений в намеренном использовании "медленных" фич. Всё было корректно, ответ был таков:
They were just a bunch of random rules that would not match (e.g
ipfw add 10 deny log ip from 10.0.0.3 to any
ipfw add 20 deny log ip from any to 10.0.0.4
ipfw add 30 deny log tcp from 172.3.3.3 to 10.0.99.4 port 24
i.e. they were "worst case scenario" rules, and all would need to be evaluated and none would match.
I plan to re-test in a month or so.>Гораздо интереснее вот что: умеет ли pf/ipfw на smp-системе раскидывать нагрузку по камням (матчить на разных процессорах)?
Насколько мне известно, ipfw умеет работать на разных процессорах, во всяком случае, к параллельной работе он подготовлен. Другое дело, что сейчас это реализовано захватом лока на весь ruleset сразу, соответственно, толку с этого распараллеливания очень мало. Думаю, что в pf дело обстоит не лучше, поскольку в OpenBSD, откуда он пришел, с использованием SMP все плохо.
>Уважаемые господа, я вот сижу на BSD + ipfw, на Linux +
>iptables, на Windows + ISA. Мне несколько раз приходила мысль перетащить
>ipfw на pf, но вот что меня смущает... я как начну
>представлять логику работы, сразу встает вопрос, в чем преимущество пакетного фильтра
>у которого выигрывает последнее правило? Я что-то никак не уловлю здесь
>"правильной" философии, ведь если использовать политику "все запрещено кроме разрешенного", то
>каждый пакет будет проходить все правила... не влияет ли это на
>скорость обработки... в ipfw я самые часто срабатываемые правила перемещаю наверх
>и получается что в большинстве случаев у меня пакет обрабатывается всего
>несколькими правилами...
>Я понимаю что есть "quick"... но что ж применять ко всем правилам
>его?Да, мне тоже было по началу тяжеловато после ipfw. Но, когда я свел три страницы правил ipfw в пол страницы правил pf, я это оценил.
Просто в pf по началу многие действуя по старой привычке все сначала все запрещают, а потом а потом начинают разрешать и это превращается в черт знает что.А, для начала, более правильный подход, сначала все разрешить, а потом отрезать то, что не нужно. наверняка не нужно. Причем нет необходимости писать громоздкие правила. Пишешь кучу мелких с конкретным критерием привязанным к конкретному типу трафика. И quick используешь конкретно для тех правил, которые дальше точно нет смысла смотреть.
Ох уж вы и насоветуете: сначала всё разрешить. Этож надо!Значит так: сначала читаем документацию с примерами.
Затем, критически относимся к чужим советам в форуме (это всё советы злобных кракеров, которые будут вас ломать:)!)
>Да, мне тоже было по началу тяжеловато после ipfw. Но, когда я
>свел три страницы правил ipfw в пол страницы правил pf, я
>это оценил.
>Просто в pf по началу многие действуя по старой привычке все
>сначала все запрещают, а потом а потом начинают разрешать и это
>превращается в черт знает что.
>
>А, для начала, более правильный подход, сначала все разрешить, а потом отрезать
>то, что не нужно. наверняка не нужно. Причем нет необходимости писать
>громоздкие правила. Пишешь кучу мелких с конкретным критерием привязанным к
>конкретному типу трафика. И quick используешь конкретно для тех правил, которые
>дальше точно нет смысла смотреть.Правильный подход - это когда первое правило
block all
а дальше разрешаем что нужно
А firewall который работает по принципу - запрещать что не нужно - это дуршлаг называется а не firewall :)
> Наконец, не грех было бы задаться вопросом так ли вам нужна оптимизация?
> Дональд Кнут говорил: "преждевременная оптимизация - корень всех бед".
> Маловероятно, что ваш брандмауер работает на 486-й машине. В самом ли деле
> ваша полоса пропускания страдает от производительности брандмауера?
> Может быть, если у вас всё работает, то уже пора оставить всё как есть? :)
Золотые слова! Автору респект!А вот про FTP информация неполная. Не хочу вмешиваться в стиль изложения автора, но на порт ftp/ftpsesame рекомендую обратить внимание.
Беглый просмотр доки показал, что функциональность этого порта смержена в OpenBSD'шный ftp-proxy. Для FreeBSD рекомендуется использовать этот порт вместо проксирования, особенно, когда по тем или иным причинам не хочется NAT'ить FTP-траффик (или проксировать его).
Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен еще и маршрутизируемый ip ?
> Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен
> еще и маршрутизируемый ip ?
Насколько я понимаю, нет. Можно использовать LoopBack, на манер Cisco'вских маршрутизаторов.
>Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен
>еще и маршрутизируемый ip ?А нельзя ли поподробней. Что такое "маршрутизируемый ip"?
Видимо, не перечисленный в RFC1918 :)
Имел ввиду приватные3. Private Address Space
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Именно так
В таком случае, можно. Не вижу в чем тут может быть сложность.