Редактирование: UNИX, весна 2009, 07 лекция (от 08 апреля)

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

ПРЕДУПРЕЖДЕНИЕ: Длина этой страницы составляет 36 килобайт. Страницы, размер которых приближается к 32 КБ или превышает это значение, могут неверно отображаться в некоторых браузерах. Пожалуйста, рассмотрите вариант разбиения страницы на меньшие части.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

* '''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_04_08.ogg

= packet filter (pf) =

Исторически pf появился в openbsd, как и ещё один МЭ, о котором мы говорить не будем, ipf. В openbsd работают весьма суровые люди, они периодически ругаются и пишут своим МЭ, тем не менее, в какой-то момент, в районе BSD 3.0 было решение написать МЭ, функц. на иных принципах, который бы позволял решать задачи ажминистратора чуть на болнн высоком уровне, чем это делалсь с помощью предыд. МЭ. Если ы мы посмотрели, что делал ipf, то это такой инстументарий в классическом бсд-стиле: есть пакет и можно их как-то преобразовывать. С версии 4.0 freebsd был включен в основную ветку freebsd и по сию пору они обновляют, заливая из openbsd. Ребята из openbsd знают своё дело, за всё время у  них было всего два взлома.

Мы уже говорили о разных фаерволлах в двух разных юних-подобных ОС, про ipfw/ipfw2 и про iptables в linux. Зачем их так мноог?: Зачем нужен ещё один фаерволл. Здесь есть две, или три нерешённых задачи:
* Это было хорошо видно из рассказа про iptables и ipfw. Задача 1 в следующем: когда вы сталкиваетесь в реальной проблемой настр. МЭ, то помимо настр. МЭ, приходится иметь дело с большим комплексом разл. задач (огр. трафика, перенапр., проброс портов, вещи, связанные с удобной защитой от вторжения атак снаружи, и . д.), много задач, которые подстерегают системного администратора, на каждую обычно 20-30 правил, потом всё это сливается в виде одного списка, оказывается что они интерферируют, приходится делать обходы, что многократно увел. их количество до декартова произведения и так далее. Было бы неплохо собрать под одной крышей инстр. для решения разл. задач хотя ы на сетевом/трансп. уровне. Понятно, что не залезаем в бриджинг и прикл. уровень, но на осн. уровнях было бы неплохо иметь такой инструмент. Отчасти таким инстр. явл. iptables, но там есть свои огр. в части мелких задач (будут привдеены примеры, когда с помозщью pf они решаются в один пинок, а в ipfw/ipt они решаются нетривиально)
* Если мы сделаем действ. унифиц., одну точку входа для значимого количества администраторских задач, то мы можем попробовать поверх этого делать какие-то высокоуровневые стандарты, связанные, например, с надёжностью, гар. защитой от несанкц. доступа; после того, как мы вместо большого набора разнообр. инструментов, изг. один инстр., который покрывает большую их часть, то мы вокруг него сможем писать, скажем, шелл-скрипты, которых только им решают польз. задачи: мы не будем задумываться, какой фаервол, нат, и так далее.
* Это напр. --- средство из двух первых. По утв. всех практикующих адм., работающих с bsd, pf в разы проще в работе. В этом pf наследует идеологию ipfw, и в очереденой раз убеждаешься, что одна простая команда делает много разл. действий, причём ействий отнюдь неривиальных. Например: делать или не делать фрагментацию трафика. Таким обр., pf позв. множество мелких действий просто не елать.

pf устроен прямо противоположно в отношении применения правил, по отношению к рассм. ранее фаерволам. Есть стратегия first wins. В pf применён противоположный алгоритм, в нём применяются посл. все правила, и с каким действием пакет выйдет, такое действие и удет применено. Это не означает, что нельзя делать правила вида quick (применить и выйти без обработки); правила вида безусл. отсеивания или допуска советуют оформлять именно так. Мы уже говорили о дост. и недост. этой стратегии
* Очевидный недостаток: если правил много, то если процедура матчинга дорогостоящая, то чем их больше, тем дольше пакет пробудет в кернелспейсе. Если стратегия first wins мы можем орг. так, что у нас частые правила применятся сначала. В случае last wins, если не понаставим quick, то оно почти всегда будет пробегать правила полностью
* Достоинства
** Фильтры, постр. по принципу last wins гораздо лучше читаются, просто потому, что можно вставлять правила куда угодно, лишь бы до этого места дошло, а дойти можно куда угодно. Например, если надо добавить правило для отдельного ip, то вам не надо думать, куда его добавлять
*** Косвенным следствием этого достоинства явл. загаживание правил pf
** Если у нас обр. пакетов орг. таким образом, что всё равно все правила применяются, то, по всей видимости, саму процедуру применения шаблона можно сделать намного более быстрой. 
*** Некоторым следствие из этого явл. активное использование таблиц для того, чтобы осущ. составление шаблонов. Если таблицы в ipfw появились только в ipfw2.

Практика показывает, что сложные фаерволы, написанные на pf, работают быстрее, чем аналогичные на ipfw.

Что ещё из таких мелочей, которые делают жизнь красивой: как лектор уже сказал, в pf есть такие приятные штуки, которые резко сокр. количество правил, которые человек пишет, как макрос. Казалось бы, что тут такого, не нужно быть семи пядей во лбу, чтобы написать несколько макросов в началае скрипта, но в действиетнльсти бывает удобно написать макрос вместо того, чтобы писаьт длинную цепочку. Кроме того, в самих правилах pf можно употреблять логич. операторы.

Как лектор уже говорил, в pf входит неск. элементов, связ. с МЭ:
* Таблицы
* Макросы
* Фльтр, NAT, Queue, Normalizing
* Passive OS fingerprinting

С точки зрения отд. пользователя pf выглядит как посл. правил с некоторыми оговрками:
* Подобно тому, как это сделано в iptables, в pf правила группируются по виду и их следуюте писать в искл. правильном порядке. Разделения отдельных кусков в нём нет, а что есть:
** Начинается всё с разного рода определений (макросы и таблицы) (macros, tables)
** Настройки (options) --- tcp timeout, udp tim eot, таймаут на удаление временных правил. В iptables это настравивается через sysctl. Это сделано для того, чтобы оно было в одном месте и можно было писать скрипты
** Нормализация (traffic normalization). Например, пересборка фрагм. пакетов, antispoof правила...
** Ограничение. Traffic shaping, queueing в терминах pf. Мы помним из туманных замечаний лектора про очереди в ipfw, что понятие queue связано с traffic shaping, вся вот эта вот кухня, она опр. в спец. секции правил pf
** Преобразование. Разный nat, port forwarding
** Фильтр (filtering). То, что секция посл., означает, что фильтруме мы преобр. пакеты

Это было первое засечание о том, как выглядит pf.

Второн замечание: в pf есть понятие якоря (anchor). Это такая маленькая таблица, где всетр. опр. правила, и ваше течение правил может выгл. след. образом: можно из правила сказать переход в anchor. Кроме того, в pf есть механизм редактирования якорей и таблиц, не трогая дерево фаерволла.

Чем это ещё хорошо: представить, что у вас написан скрипт, который в зависимости от того, кто залогинился, зарпуск. скрипт, который вности правки в фаерволл. В этот момент что происх. с траффиком? Он на неккоторое время подвисает, часть TCP-соединений может отвалиться. Если у вас грамотно сделаны обработка и хр. в таблице анкоров, то трафик может спокойно ходит, за искл. разве что анкоров. Ещё более, то же самое относится к таблицам. Таблицы --- области памяти, и если пакету нужна таблица, то оно зависнет, но это не так страшно, как подвисание всего трафика. Есть мнение, что это не только эффективно, но и ... . Поэтому есть ряд средств для модиф. таблиц,

Как это всё управляется? С помощью двух утилит:
* pfctl
* /etc/pf.conf

В pf есть механизмы для пассивного определения ОС, аналог p0f. Вообще, это --- очень правильное место для определения. С другой тсороны, есчли например можно по такому трафику можно определить, какой сервис-пак стоит, то можно смело резать 25 порт сразу. Таких мелочей в pf много, они нам будут попадаться и лектор будет их озщвучивать.

Список, в каком порядке правила отдаются pf, взять из мануала по pf.conf.

Что можно сделать с помощью pfctl? 
* Загрузить конф. файл в ФВ
* Проверить синтаксис конфига
* Загрузить часть файла, например, соотв. только нату или только фильтру и т. п.
* Просмотреть все правила, правила, отн. только к опр. секции
* Просм. все правила, включая временные
* Посмотреть всякие сттастики, счётчики, и так далее

Помимо нормализации есть такая штука, как оптимизация самих правил, в pf можно включить режим, что при загрузке ни оптимизируются, например, удаляются дубли. Или если одно есть подмножество другого.

Помимо таблиц, которые обл. св-вом лог. сложности поиска, в pf есть и обычные списки.

Что касается норм. траффика, есть одна главная опция, scrumble(?)

Формат правила.

Общего формата правила нет, у каждой секции формат свой. Это аналогично ipfw. Например, в правилах типа фильтрации обяз. будет шаблон и действие. ЛЕктор не знает, нужно ли опис., как выглядят списки и макросы. Списки --- фигурные скобочки с перечислением.

Лектор приведёт пример правила:
 block out on fxp0 {tcp udp} from {192.168.0.1, 10.5.32.6} to any port {ssh telnet}

Денис Овсиенко написал в составе etcnet конвертер правил из синтаксиса pf в iptables

В альте с использованием etcnet произошла акая ситуация: много случаев разных сложных вещей делаются копированием примеров из документации, если же etcnet не хватает и нужно что-то чудовищное, то вы сами такое чудовище, и вам никаеи etcnet не нужны

Списки это не таблицы, это удобная запись набора правил.

Что касается макросов, то тут всё ещё проще.

ext_if="fxp0"
 block out on $ext_if

Макросы нужны не олько для сокращения размера.

Таблицы.

Таблицы это наборы ip-шаблонов, идея в том, что они это некие отдельные структуры данных, к которым можно иметь доступ со стороны US, и не причиняя вреда осн. течению фаперволла.

tabl <ьаблица> (ip-шаблоны через запятую)

ip-шаблон имеет привычную структуру, вида 192.168.0.0/16. Можно исп. таблицы в тех же местах, где исп. любой шаблон. Можно указ. списко таблиц.
 pass in on fxp0 from <goodguys> to any

Таблицы бывают трёх видов.
* Обычные. Вы их задаёте, они сущ., соответственно, вы с ними как-то работаете
* Persistent. Существуют даже тогда, когда ничего не содержат. Когда она пустая, она сущ., и сопост. с неё ничего не даёт
* Const. Доступ к ней запрещён из userspace. В openbsd есть такая штука как security level, он опр. доступ разл. системных вызовов, и на высшем уровне даже рут не всё может

Что касается правил. Обший вид правила 
 action [направление: in|out] [log] [quick] [on интерфейс] [версия ip: inet|inet6] [proto tcp|udp|icmp|icmp6|номер поротокола из /etc/protocols]  [from откуда [port порт]] [to куда [port порт]] [flags TCP-флаги] [состояние]
* Что такое action. Их довольно много: block, pass, drop
* log — дублировать пакеты на логгирующий вирт. интерфейс, откуда их может забирать pflog
* quick — некая уступка. Реком. изучить pf прежде чем его исп., 
* Версия ip:

Что мы видем в этой некороткой строке: направленность pf на решение как можно большего количества однородных задач. Все правила фильтрации одного вида, применять можно как можно больше всего, и ситуация, когда есть некие однотипные действия, то их мыможем сложить в одно правило.

Лектор хотил обратить внимание на то, что pf вообще не упр. уровнем интерфейсным. если ваша задача — фильтр. уровень eth, или взять первый попавшийся ipfw. Почему ак делается? Когда лектор рисовал картинку, там лыо 5 мест, где пакеты попадают в ipfw. Поск. полное прохождение таблицы — дорогостоящая задача, то ребята из pf свели прохождение пакета к двум, что, в принципе, логично. Лектор, читая документацию по pf, обнаружил, что ручки к pf-подобному для упр. бриджем есть, а в самом pf нет.

Что ещё можно рассказать интересного: как выглядит address range.
* IP
* CIDR
* FQDN
* Имя из /etc/networks
* Имя и/ф [:network] — ip/network возьмётся в момент загрузки правила
* (Имя и/ф) [:network] — ip/network возьмётся в момент применения правила
* <таблица>
* urpf_failed --- елси пакет пришёл не с того интерфейса, куда пойдёт ответ
* ...
* список
* all

Лектор не дошёл до самого вкусного: куча правил, которые выроджаются в одно правило в pf. Про это лектор расскажет в след. раз.

= Конспект Kda =
== Вступление ==
pf
Есть пакеты, их можно преобразовывать, вот инструмент для преобразования пакетов.
С версией 4.0 во FreeBSD был включен pf.
До сих пор периодически обновляют.
До недавнего времени был лишь один взлом OpenBSD, сейчас их ровно два.
Так что если они делают файрвол, то, наверное, это полезно.
ipfw, ipfw2.
Есть разные полезные вкусности.
Говоря о Линукс, был iptables.

== Зачем еще один файрвол? ==
Здесь есть еще две или три нерешенных задачи.
=== Первое ===
iptables, ipfw.
Когда вы сталкиваетесь с реальной проблемой реализации на компьютере, кроме того, что это интерфейс фильтра, приходится
иметь дело с комплексом разного рода рабочих задач, как-то ограничение трафика, преобразование, NAT, проброс портов.
С помощью обеих систем можно сделать NAT, но помимо простейшего NAT набегает еще несколько задач,
получается пара десятков правил.
Правила не интерферируют, количество правил возрастает как декартово произведение.
Инструмент предоставляет решение всех задач для решения на сетевом и транспортном уровнях.
На этих уровнях происходит основная работа с сетевым трафиком.
Было бы неплохо сделать единый инструмент.
Отчасти им является iptables.
Но там есть ограничения.
Попробуем выудить некоторые задачи.
Это первое направление, которое побудило сделать свой файрвол.

=== Второе ===
Если мы сделаем единую точку входа для значимого количества администраторских задач, то мы можем попробовать
сделать высокоуровневые стандарты, связанные с надежностью или гарантированной защитой от несанкционированного доступа.
После того, как мы вместо набора разнообразных инструментов изготовим инструмент, покрывающий набор задач.
Сможем писать шелл-скрипты, чтобы вокруг pf решать различные задачи.
Все вложено в одну кошелку.
Это второе.

=== Третье ===
Третье — следствие двух первых.
Pf на порядок проще и удобнее в освоении с точки зрения конечного пользователя, конфигурирующего межсетевой экран.
Когда вчитываешься в документацию, одна команда делает много действий, не всегда тривиальных.
Делать или не делать дефрагментацию?
После получения мы делаем проверку.
Есть специальные правила, которые ориентированы на фрагментированные пакеты.
Чем сложнее задача, тем больше побочных действий приходится предпринимать межсетевому экрану.
Pf не то чтобы скрывает, но позволяет не делать.

== Last wins ==
Pf устроен прямо противоположным образом.
Мы говорили, что есть стратегия first wins, когда правила, связанные с обработкой нашего трафика, применяются поочередно.
Правило прекращает обработку цепочки.
В pf применен противоположный алгоритм last wins, все правила применяются поочередно, но пакет «перекрашивается».
Каждое правило накладывает свое действие, с чем выйдет — то и будет.
Есть возможность применить и выйти из обработки.
Безусловное отсеивание и пропускание пакета рекомендуют делать так.

=== Достоинства и недостатки ===
Мы говорили о достоинствах и недостатках этой стратегии.
==== Недостаток ====
Если много правил и проверка совпадения шаблона — дорогостоящая процедура, то чем дольше, тем дольше мы будем в 
kernel space.
При first wins возможен быстрый выход.
При last wins скорее всего будет полный просмотр.
Это медленно.

==== Первое достоинство ====
В чем достоинство?
Первое.
Трудно привести пример, но фильтры намного менее заморочены с виду и гораздо легче читаются.
Можно вставлять правила куда угодно, лишь бы до этого места дошло, а дойдет.
Не нужно думать, куда добавить ограничение на айпишник, до фильтрации зеленых компьютеров или после, и т.д.
Косвенным следствием является легкость загаживания свода правил pf.
Другое дело, что если после него стоит отрицание, ничего не сделаешь.

==== Второе достоинство ====
Другое достоинство.
Если у нас обработка пакетов организована так, что все правила применяются.
По видимости, саму процедуру обработки можно сделать намного более быстрой.
Идея в том, что если есть задача прогнать объект через таблицу шаблонов, то такая задача решается быстрее, чем за линейное
время.
Таблицы для осуществления сопоставления шаблонов.
Появились в нормальном виде только в ipfw2.
У BSD в pf поиск по таблице шаблонов, там может быть любой шаблон, идет строго за логарифмическое время.
Сто или сто тысяч компьютеров — время поиска больше в три раза.

== Особенности ==
Что можно сказать про особенности pf?
Как уже было сказано, в pf есть приятные штуки, которые резко сокращают количество правил, которые пишутся, макросы.
Казалось бы, ничего особенного.
В действительности довольно удобно написать макрос и повсюду его вставлять.
В самих правилах можно употреблять логические операторы.
В pf входит сразу несколько элементов, связанных с экранированием.
Фильтрация, NAT, Traffic Shaper, Normalizing.
С точки зрения обычного пользователя pf  выглядит как последовательность правил с некоторыми оговорками.
В pf правила группируются по виду и их следует писать в правильном порядке.
Разделение на много разных кусков в pf нет, в отличие от iptables.

Начинается все с определений.
Макросы и таблицы (macros, tables).
Потом идут настройки (options).
В iptables через sysctl.
Администратор видел и руками настраивал.
Интерфейс писал скрипты и стандартизировал.

=== Traffic Normalization ===
Нормализация.
Есть много веселых вещей, например, пересборка фрагментированных пакетов.
Всякие antispoof-правила.
Ограничения.
Traffic shaping.
Queueing.
Из туманных замечаний относительно pipe в ipfw, связано с traffis shaping.
Выстраиваем в очередь и затем скармливаем.
Преобразования (NAT...).
Фильтр (Filtering).
С точки зрения пользователя так выглядит pf.

=== Якорь ===
В pf есть понятие якорь (anchor).
Линейное течение команд может выглядеть следующим образом.
В силу того, что last wins, ситуация другая.
Модификация, не трогая основного файрвола.
Раньше (сейчас — неизвестно) дергать якорь было нельзя.

Чем полезная штука?
Представим ситуацию: написан скрипт.
Он меняет свод правил.
Что должно происходить?
Залогинился пользователь, запускается скрипт.
Когда запускается скрипт, что происходит с трафиком?
На несколько долей секунды все подвисает.
Возможно, tcp-соединения валятся.
Есть некий момент, когда вся структура не работает по причине ее текущего обновления.

Если грамотно сделаны доступ к таблицам, то реальна ситуация, когда пользователь меняет файрвол и в это время все ждет.
Таблицы.
Ну залочил область памяти, на время лока все повиснет.
Одно дело залочить, другое дело загнать через юзерспейс свод правил межсетевого экрана.
Более эффективны при реальной эксплуатации.
Есть много утилит по модификации.

== Управление ==
Некоторых интересует, как это все управляется.

pfctl

/etc/pfconf

Почему это так сделано?
Делаем двойную работу.
Почему бы не делать в ядре?
Пускай потихоньку себе кумекает, что это за трафик.
Если можно по такому трафику определить, какой сервиспак стоит на виндоусе, если не последний, можно смело резать 25 порт.
Кстати сказать, это взято из мануала.

=== pfctl ===
Что можно сделать с помощью pfctl?
Можно загрузить конфигурационный файл в файрвол.
Часть файла, соответствующую только NAT, или filter.
Просмотреть все правила, правила определенной секции, временные правила, статистики, счетчики.
Там где написано нормализация, помимо нормализации есть оптимизация самих правил.
При загрузке свода правил они оптимизируются.
Они все все равно просматриваются.
Действия одинаковые, фильтры разные.

Помимо таблиц, которые обладают свойством логарифмического поиска.
Зафильтровать эти адреса.
Выливается в три правила, только их никто показывать не будет в виде списка.
Это повышает читаемость.
Одна строчка чуть большей длины — еще терпимо.

Есть ли смысл настраивать, как выглядят списки и макрос.

=== Общий вид правил ===
Общий вид правил выглядит по-разному.
Рассказ о виде правил, начиная с конца.

block out on fxp0 {tcp, udp} from {192.168.0.1, 10.5.32.6} to any port {ssh telnet}

=== Макросы ===
Таблицы — это отдельные структуры доступ, к которым можно иметь или не иметь доступ, модифицировать таблицы, не причиняя вреда течению работы файрвола.

table <название> ( ipшаблон, ... ) 192.168.0.0/16

Вы можете использовать таблицы в тех же местах, что и шаблоны.
Есть ключ all (block all).
Напишем пример.

pass in on fxp0 from <goodguys> to any

=== Таблица ===
Что можно рассказать?
Таблицы бывают трех видов: таблицы обычные, которые мы задаем, они существуют, мы с ними работаем.
Таблица persistent, она существует даже когда ничего не содержит.
Сопоставление с такой persistent ничего не дает.
Таблицы const, которые вообще нельзя трогать.

=== Общий вид правила ===
Попробуем расписать общий вид правила.

action [напр] [log] [quick] [on интерфейс] [{inet, inet6}] [proto протокол] [from откуда [port порт]] [to куда [port порт]] [flags tcp-флаги] [состояние]

=== Журнализация ===
Журнализация организована крайне забавным способом.
Назначаем сетевой интерфейс жертвой потока, на него идет вообще все.
На интерфейс цепляется демон pflog, осуществляющий работу.
Можно нацепить с помощью netgraph кучу безобразия.
Чем это хорошо?
Вы не пользуетесь ничем дополнительно, не делаете систему журнализации.
Если интерфейс виртуальный, никакого performance degradation нет.
Дырка в памяти работает не как дырка, а как дырка фильтрующая.

=== Quick ===
Quick — правило последнее.
Опцию quick не рекомендуется делать неопытным пользователям.

=== Нет интерфейсного уровня ===
Правила не управляют на уровне интерфейса.
Почему это так?
Потому что, когда пакеты попадают в ipfw, там было семь мест, куда они попадают.
На выходе и на входе.
Если мы хотим фильтровать на бридже, используем другие вещи.

== Дополнительно ==
Ядерные вещи есть.

IP
CIDR
FQDN

Есть забавная штука.
Обращаемся к имени интерфейса без скобок или с ними (тогда каждый раз будут считываться настройки).
Обращение к таблице.
arpf_failed
any
список
all

Есть много действий, выражающихся в антиспуф.
Попытка посылки с внешнего интерфейса на лупбэк и т.д.
Все это включается антиспуфом.

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/UN%D0%98X%2C_%D0%B2%D0%B5%D1%81%D0%BD%D0%B0_2009%2C_07_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_08_%D0%B0%D0%BF%D1%80%D0%B5%D0%BB%D1%8F%29

Редактирование: UNИX, весна 2009, 07 лекция (от 08 апреля)

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты

@@ Строка 3: / Строка 3: @@
 = packet filter (pf) =
-Исторически pf появился в openbsd, как и ещё один МЭ, о котором мы говорить не будем, ipf. Появился он взамен ipf из-за того, что разработчикам опенбсд не понравилась лицензия на ipf. В openbsd работают весьма суровые люди, они периодически ругаются и пишут своим МЭ, тем не менее, в какой-то момент, в районе BSD 3.0 было решение написать МЭ, функц. на иных принципах, который бы позволял решать задачи ажминистратора чуть на болнн высоком уровне, чем это делалсь с помощью предыд. МЭ. Если ы мы посмотрели, что делал ipf, то это такой инстументарий в классическом бсд-стиле: есть пакет и можно их как-то преобразовывать. С версии 5.3 Freebsd был включен в основную ветку freebsd и по сию пору они обновляют, заливая из openbsd. Ребята из openbsd знают своё дело, за всё время у  них было всего два взлома.
+Исторически pf появился в openbsd, как и ещё один МЭ, о котором мы говорить не будем, ipf. В openbsd работают весьма суровые люди, они периодически ругаются и пишут своим МЭ, тем не менее, в какой-то момент, в районе BSD 3.0 было решение написать МЭ, функц. на иных принципах, который бы позволял решать задачи ажминистратора чуть на болнн высоком уровне, чем это делалсь с помощью предыд. МЭ. Если ы мы посмотрели, что делал ipf, то это такой инстументарий в классическом бсд-стиле: есть пакет и можно их как-то преобразовывать. С версии 4.0 freebsd был включен в основную ветку freebsd и по сию пору они обновляют, заливая из openbsd. Ребята из openbsd знают своё дело, за всё время у  них было всего два взлома.
 Мы уже говорили о разных фаерволлах в двух разных юних-подобных ОС, про ipfw/ipfw2 и про iptables в linux. Зачем их так мноог?: Зачем нужен ещё один фаерволл. Здесь есть две, или три нерешённых задачи:
@@ Строка 123: / Строка 123: @@
 * all
 Лектор не дошёл до самого вкусного: куча правил, которые выроджаются в одно правило в pf. Про это лектор расскажет в след. раз.
 = Конспект Kda =