| 1.2, zedis (?), 17:31, 03/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>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 точно не попадёт под это правило. автор ошибся грубо. | | |
| |
| 2.4, eugene (??), 18:10, 03/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Это Вы грубо ошиблись, автор совершенно прав. Комбинация S/SA обозначает что проверяются флаги S и А (после слеша), пакет попадает под правило, только если S установлен, A - нет (перед слэшем). Состояние остальных флагов не принимается во внимание. | | |
| 2.5, Евгений Миньковский (?), 18:22, 03/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Вот выдержка из 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, то это будет откровенный баг, о котором надо заявить им в список рассылки, прежде всего. | | |
| |
| 3.41, Unknown user (?), 14:34, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Пакетный фильтр бурно развивается, и возможно его поведение в этой области драматически изменилось
"драматически изменилось"?
Не надо так писать. Не надо засорять русский язык, это калька с английского | | |
|
|
| |
| |
| 3.11, автор (?), 20:02, 03/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
гм, вы вручную html верстаете? docbook не подходит? там напрягаться осбо не надо, хочешь хтмл, хочешь пдф, хочешь еще что... | | |
| |
| 4.12, Евгений Миньковский (?), 20:55, 03/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>гм, вы вручную html верстаете? docbook не подходит? там напрягаться осбо не
>надо, хочешь хтмл, хочешь пдф, хочешь еще что...
Это вам только кажется, что в dobook так всё просто. Надо вбухать в его руссификацию много часов. Больше разнообразных форматов - меньше текста. Я один. :( | | |
| |
| 5.22, nobody (??), 09:59, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
русификация занимает от силы 5 мин (xml версия docbook'а), проверено на собственном опыте | | |
|
|
|
|
| 1.8, x0r (?), 18:54, 03/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
орфографическая ошибка на "главной"?!
-- организовать сертификационный экзамен по черырём ->вериям<- систем BSD | | |
| 1.14, Дохтур (?), 23:58, 03/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 не освещены вопросы:
1)"покраски" трафика (DSCP/IP Precedence)
2)пропуска через NAT pptp/sip-клиентов.
3)hfsc, управление задеркой и джиттером
(это то что после беглого просмотра заметил). | | |
| 1.16, Аноним (-), 01:26, 04/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
2 Евгений Миньковский
Хочу добавить, что непосредственно в самом учебнике основной упор сделан на FreeBSD, насчёт OpenBSD есть довольно много неясностей и неточностей, и встречаются такие моменты когда вы пишите что такое есть, а на самом деле его в OpenBSD нет (уже во всяком случае). Например http://house.hcn-strela.ru/BSDCert/BSDA-course/ch02s12.html password.conf и auth.conf в OpenBSD на данный момент не используются. И ещё много подобный неточностей которые скорее всего спицифичны только для FreeBSD.
Желаю что-бы у вас всё получилось :) | | |
| |
| 2.25, Евгений Миньковский (?), 10:14, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Боюсь, что это неизбежно :( к тому моменту, когда я всё допишу, BSD уже выкинут на свалку истории и труд мой будет ценен долько для археологов :) Я смирился.
По существу:
password.conf есть в NetBSD
auth.conf есть в FreeBSD и DragonFly BSD
Об этом сказано в http://house.hcn-strela.ru/BSDCert/BSDA-course/apa.html
Там приведена полная сводная таблица всех обсуждаемых команд и файлов, в которой расписано какая команда и какой файл в какой операционной системе встречается. | | |
|
| |
| |
| 3.19, dimus (??), 07:51, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Очень полезная работа. Надеюсь, что у автора все получится. Желаю ему удачи.
А еще есть вопрос по одному скользкому моменту. Вот цитата из текста:
>Трансляция осуществляется до фильтрации. Правила фильтра увидят уже оттранслированные >пакеты.
Из этого утверждения вытекает, что на машине с NAT невозможно фильтровать трафик от внутренних хостов. Было бы неплохо, чтобы было разъяснение по этому моменту.
Допустим у нас есть сеть 192.168.1.0/24 со шлюзом на *BSD с pf, который натит в IP 1.2.3.4
Хост 192.168.1.3 не должен иметь возможность достучаться до адреса 5.6.7.8 по 80 порту. iptables делает такое одним правилом. Приведите плиз пример конфига pf, который делает то-же самое. | | |
| |
| 4.20, northbear (??), 08:40, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Это утверждение касается порядка фильтрации трафика на одном интерфейсе. В твоем случае, как правило, используется такой вариант: фильтрация производится на том интерфейсе, который смотрит во внутреннюю сеть 192.168.1, а трансляция производится на внешнем интерфейсе.
Но это далеко не единственный вариант. Можно редиректить отфильтрованный траффик внутр. сети во внешний мир на дополнительный loopback-интерфейс и на нем делать трансляцию. Это по-моему самый быстрый вариант.
На худой конец, pf позволяет менять последовательность обработки. Но это крайне не рекомендуется... | | |
| |
| |
| 6.23, dimus (??), 10:00, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Спасибо за иллюстрацию и за разъяснения. Вообще, было бы здорово чтобы этот вопрос более подробно освещался в руководстве. Надеюсь, что автор примет это к сведению. | | |
|
| 5.27, mutronix (?), 10:48, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
 > Это утверждение касается порядка фильтрации трафика на одном интерфейсе. В твоем случае, как правило, используется такой вариант: фильтрация производится на том интерфейсе, который смотрит во внутреннюю сеть 192.168.1, а трансляция производится на внешнем интерфейсе.
Интересно, а почему фильтрация пакета происходит в таком порядке? Не лучше ли было бы как в iptables фильтровать транзитные пакеты в порядке dnat-filter-snat?
> Можно редиректить отфильтрованный траффик внутр. сети во внешний мир на дополнительный loopback-интерфейс и на нем делать трансляцию. Это по-моему самый быстрый вариант.
Может проще маркировать транслируемые пакеты для последующей фильтрации на основе значения tag? Тут главное, чтобы другие правила случайно не заменили маркер.
| | |
| |
| 6.42, northbear (??), 15:56, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Интересно, а почему фильтрация пакета происходит в таком порядке? Не лучше ли было бы как в > iptables фильтровать транзитные пакеты в порядке dnat-filter-snat?
А какая разница? Тогда бы точно так же возникали обратные вопросы.
Мне например, такой вариант намного удобней. Я пишу правила фильтрации на внешнем интерфейсе в контексте внешних адресов, не завязываясь на внутренее устройство сети. А фильтрация, завязанная на топологию внутренней сети и внутренние маршруты, производится на внутренних интерфейсах. И я для себя точно знаю, что если вдруг одна внутренняя сеть переехала с одного порта на другой или маршрутизация изменилась, то в правилах на внешнем порту мне точно ничего менять не нужно. Всему свое место...
>Может проще маркировать транслируемые пакеты для последующей фильтрации на основе значения
>tag? Тут главное, чтобы другие правила случайно не заменили маркер.
Вот-вот... Чтобы, не заменили. Ты это еще должен вспомнить через полгода, когда вдруг понадобиться что-то поправить. Предложенный мною вариант чуть сложнее реализовать, но работать должно быстрее. А главное понятнее, когда через какое-то время снова залазишь в конфиг. | | |
|
|
| 4.24, Евгений Миньковский (?), 10:07, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Было бы странно, если бы это было невозможно.
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
...
Секрет в том, что трансляция осуществляется на внешнем интерфейсе, а фильтрация на внутреннем | | |
|
|
|
| 1.28, muhlik (??), 10:57, 04/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Уважаемые господа, я вот сижу на BSD + ipfw, на Linux + iptables, на Windows + ISA. Мне несколько раз приходила мысль перетащить ipfw на pf, но вот что меня смущает... я как начну представлять логику работы, сразу встает вопрос, в чем преимущество пакетного фильтра у которого выигрывает последнее правило? Я что-то никак не уловлю здесь "правильной" философии, ведь если использовать политику "все запрещено кроме разрешенного", то каждый пакет будет проходить все правила... не влияет ли это на скорость обработки... в ipfw я самые часто срабатываемые правила перемещаю наверх и получается что в большинстве случаев у меня пакет обрабатывается всего несколькими правилами...
Я понимаю что есть "quick"... но что ж применять ко всем правилам его?
| | |
| |
| 2.29, dimus (??), 11:36, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Лично мне тоже кажется, что такой порядок проверки не самый лучший. Однако, если верить тестам, при больших нагрузках pf показывает себя лучше, чем ipfw, идя примерно наравне с iptables. | | |
| 2.30, Евгений Миньковский (?), 11:47, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Да, вы правы, такой порядок обработки правил снижает производительность брандмауера, хотя и весьма незначительно. Производительность пакетного фильтра всё равно выше, чем у ipfw (лично не проверял, пересказываю чужое мнение), повидимому за счёт более грамотного проектирования.
Да, можно применять quick ко всем правилам. Неуклюже выглядит, согласен.
Можно при засасывании правил пременять команду
pfctl -oo -f /etc/myrules
При этом, теоретически, правило quick расставится само и логика будет примерно как у iptables (который и сам обладает рядом недостатков, хотя и не в этом месте).
Наконец, не грех было бы задаться вопросом так ли вам нужна оптимизация? Дональд Кнут говорил: "преждевременная оптимизация - корень всех бед". Маловероятно, что ваш брандмауер работает на 486-й машине. В самом ли деле ваша полоса пропускания страдает от производительности брандмауера? Может быть, если у вас всё работает, то уже пора оставить всё как есть? :) | | |
| |
| 3.31, Евгений Миньковский (?), 11:51, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Да, и ещё: все пакеты всё равно сразу направляются в state-table (в отличие от iptables, где об этом надо ещё позаботиться). Поэтому основная масса пакетов вообще не пойдёт на правила фильтрации. Видимо это обстоятельство переводит данный диспут из разряда практического в разряд академического. | | |
| |
| 4.33, dimus (??), 12:04, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
При объемах среднего офиса оптимизация шибко не требуется. А вот когда через роутер проходит нехилая часть сети класса Б (естественно, разбитой на подсети), то тут уже начинаешь задумываться... | | |
| |
| 5.34, Andrew Kolchoogin (?), 12:24, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
> А вот когда через роутер проходит нехилая часть сети класса Б (естественно,
> разбитой на подсети), то тут уже начинаешь задумываться...
Которой всей срочно нужно в Интернет через единственную гигабитную кишку, вставленную во второй Ethernet-контроллер этого же роутера?
Как-то это мне напоминает сферического коня в вакууме. А если через роутер проходит внутрисетевой траффик, то не лучше ли спроектировать сеть так, чтобы в ядре был L3-свитч помощнее?
Просто как ни оптимизируй программное обеспечение ЭВМ общего назначения, со специализированными ЭВМ с ASIC'ами на борту они всё равно соперничать не смогут, увы.
| | |
| |
| 6.37, Дохтур (?), 13:32, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Которой всей срочно нужно в Интернет через единственную гигабитную кишку, вставленную во второй Ethernet-контроллер этого же роутера?
а зачем тогда этот роутер нужен, если есть гигабитная кошка? :)
И имхо, на машине с каким-нибудь athlon64 и nic-ми на pcie и гигабит можно зароутить. | | |
|
|
| 4.35, Дохтур (?), 13:22, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>все пакеты всё равно сразу направляются в state-table (в отличие от iptables, где об этом надо ещё позаботиться).
генерировать стейты по каждому чиху - имхо, дурной тон. И кстати, заботится как раз не надо.
Ручками заботиться надо именно в том случае, если через nat идёт протокол, нуждающийся в хелпере(вроде того же ftp).
| | |
|
| 3.36, Дохтур (?), 13:28, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Производительность пакетного фильтра всё равно выше, чем у ipfw (лично не проверял,
пересказываю чужое мнение), повидимому за счёт более грамотного проектирования.
категорически неверное высказывание.
советую посмотреть сюда: http://www.tancsa.com/blast.html
Гораздо интереснее вот что: умеет ли pf/ipfw на smp-системе раскидывать нагрузку по камням (матчить на разных процессорах)?
| | |
| |
| 4.49, nuclight (?), 21:15, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >Категорически неверное высказывание. советую посмотреть сюда: 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 все плохо. | | |
|
|
| 2.45, northbear (??), 16:16, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Уважаемые господа, я вот сижу на BSD + ipfw, на Linux +
>iptables, на Windows + ISA. Мне несколько раз приходила мысль перетащить
>ipfw на pf, но вот что меня смущает... я как начну
>представлять логику работы, сразу встает вопрос, в чем преимущество пакетного фильтра
>у которого выигрывает последнее правило? Я что-то никак не уловлю здесь
>"правильной" философии, ведь если использовать политику "все запрещено кроме разрешенного", то
>каждый пакет будет проходить все правила... не влияет ли это на
>скорость обработки... в ipfw я самые часто срабатываемые правила перемещаю наверх
>и получается что в большинстве случаев у меня пакет обрабатывается всего
>несколькими правилами...
>Я понимаю что есть "quick"... но что ж применять ко всем правилам
>его?
Да, мне тоже было по началу тяжеловато после ipfw. Но, когда я свел три страницы правил ipfw в пол страницы правил pf, я это оценил.
Просто в pf по началу многие действуя по старой привычке все сначала все запрещают, а потом а потом начинают разрешать и это превращается в черт знает что.
А, для начала, более правильный подход, сначала все разрешить, а потом отрезать то, что не нужно. наверняка не нужно. Причем нет необходимости писать громоздкие правила. Пишешь кучу мелких с конкретным критерием привязанным к конкретному типу трафика. И quick используешь конкретно для тех правил, которые дальше точно нет смысла смотреть.
| | |
| |
| 3.51, Евгений Миньковский (?), 09:26, 05/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Ох уж вы и насоветуете: сначала всё разрешить. Этож надо!
Значит так: сначала читаем документацию с примерами.
Затем, критически относимся к чужим советам в форуме (это всё советы злобных кракеров, которые будут вас ломать:)!) | | |
| 3.52, Осторожный (?), 10:09, 07/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Да, мне тоже было по началу тяжеловато после ipfw. Но, когда я
>свел три страницы правил ipfw в пол страницы правил pf, я
>это оценил.
>Просто в pf по началу многие действуя по старой привычке все
>сначала все запрещают, а потом а потом начинают разрешать и это
>превращается в черт знает что.
>
>А, для начала, более правильный подход, сначала все разрешить, а потом отрезать
>то, что не нужно. наверняка не нужно. Причем нет необходимости писать
>громоздкие правила. Пишешь кучу мелких с конкретным критерием привязанным к
>конкретному типу трафика. И quick используешь конкретно для тех правил, которые
>дальше точно нет смысла смотреть.
Правильный подход - это когда первое правило
block all
а дальше разрешаем что нужно
А firewall который работает по принципу - запрещать что не нужно - это дуршлаг называется а не firewall :)
| | |
|
|
| 1.32, Andrew Kolchoogin (?), 12:02, 04/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Наконец, не грех было бы задаться вопросом так ли вам нужна оптимизация?
> Дональд Кнут говорил: "преждевременная оптимизация - корень всех бед".
> Маловероятно, что ваш брандмауер работает на 486-й машине. В самом ли деле
> ваша полоса пропускания страдает от производительности брандмауера?
> Может быть, если у вас всё работает, то уже пора оставить всё как есть? :)
Золотые слова! Автору респект!
А вот про FTP информация неполная. Не хочу вмешиваться в стиль изложения автора, но на порт ftp/ftpsesame рекомендую обратить внимание.
Беглый просмотр доки показал, что функциональность этого порта смержена в OpenBSD'шный ftp-proxy. Для FreeBSD рекомендуется использовать этот порт вместо проксирования, особенно, когда по тем или иным причинам не хочется NAT'ить FTP-траффик (или проксировать его).
| | |
| 1.38, proks (?), 13:55, 04/05/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен еще и маршрутизируемый ip ? | | |
| |
| 2.40, Andrew Kolchoogin (?), 14:15, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
> Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен
> еще и маршрутизируемый ip ?
Насколько я понимаю, нет. Можно использовать LoopBack, на манер Cisco'вских маршрутизаторов. | | |
| 2.44, northbear (??), 16:04, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Возможно ли при помощи PF nat-ить на "внутреннем" интерфейсе, на котором установлен
>еще и маршрутизируемый ip ?
А нельзя ли поподробней. Что такое "маршрутизируемый ip"? | | |
| |
| |
| 4.47, proks (?), 17:53, 04/05/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Имел ввиду приватные
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) | | |
|
|
|
|
