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

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

= Конспект eSyr =

<div style="fornt-size:60%">

Продолжается разговор про МЭ, точнее, конкретно про pf, который разрабатывается непрерывно в openbsd и вытягивается периодически в другие bsd. Всё идёт к тому, что рассказ про pf сведётся к рассказу про pgf в openbsd, поск. вся азработка и передний край именно там. Почему лектор делает это замечание: в процессе чтения документации выяснилась забавная вещь: то направление, а которое лектор хотел указать, расск. про pf, развивается в openbsd и только появляется других bsd. ОДно из напправлений ---- stateful firewall. С точки зрения pf, экран с сост. выгл. след образом: есть большой кусок, связанный с фильтрацией нашего трафика, и этот самый кусок хотелось бы вообще обойти след. путём: мы, когда применяем некое правило к tcp-соед., мы начинаем понимать, что в рамках этого соед., если мы его допустили, то и все ост. пакеты в его рамках под это правило отлично попадают, и тем самым мы можем устроить наш фаерволлл так, что в опред. месте, там, где говорим checkstatre? все ситуации, когда пакет считается принадл. к уже пропущ. tcp-трафику, запомненное правило к нему применяется. С точки зр. pf это выгл. след. образом: для потока запоминается специфич. временное правило, которое запоминается для потока и применяется впоследствии. Пример:

pass out tcp from any to $www port 80 flags S/SA keep-state

То есть, пропускать tcp от любого к $www по 80 порту, у которого есть влаги SYN или SYN,ACK, и соед. запоминается как состояние. После чего можно соверш. смело соед. данного типа пропускать через фаерволл, не прогоняя через таблицу правил. Это важно. Если мы не исп. таблицу сост., то время проверки линейно зависит от кол. правил, тем более, что это pf, вместо этого в самом начале делается поиск по таблице.

В bsd 4.1 было сделано сильное переписывание pf в интерсном лектору направлении, в частности, теперь все правила по-умолчани kepp-state. Какой у этого недостаток: будет отжирать больше памяти. С другой стороны, память ныняе большая. Второй недостаток: возможно, вы захотите странного, и может быть захотите пропускать такой трафик, а потом брать и не пропускать. Например, если вы исп. аналог l7filter. На самом еле, из этих двух недостатков важен первый, поскольку людей, страдающих dos-ом, много. Но, тем не менее, у pf емть ряд механизмов, позв. этому противодействовать.

Какой же с этого бонус: главный бонус в том, что оно работает существенно быстрее. Второе — воспр. та же идея разраб. pf, что фаервол, вне зависимости от того, как вы его накривили, более менее ровно. Потому что это last wins и тут, хотя, казалось бы, должен быть degradation, но скорость будет константной почти всегда.

Второе: если идёт соед. по tcp, то по умолчанию, когда пишете такое правило, то раз уж оно по умолчанию keep-state, то у него по умолч. пишутся флаги S,S/A. Обр. внимание, что таким обр. количество писанины уменьш. раза в полтора, и осн. задачу мы решаем ничуть не менее легко, чем в первом случае. Кроме того, правило, оба правило делают одно и то же, то ленивый адм. будет применять первый вид, даже не смотря на то, что в bsd старше 4.1 оно медлоеннее. И это очень важная тенденция, которая просм. в pf очень отчётливо и явно, а именно: pf изн. не был разраб. как МЭ с подходом исклю от инструмента, мы видели, что его дизайн был разр. с подходом от задачи. Этот подход от задачи делается всё более глубоким: мы упрощаем внеш. вид правил, причём таким обр., чтобы умолч., которые вклчаются, увел. эффективность и правильность, и упрощаем поведение нашего фаерволла по структуре: мы вспоминаем, что для данного правила есть флаги и кипстейт, и происх. две вещи. То есть, мы упрощ. польз. инт. и услож. подложку.

Другой пример: списки: мы пишем одно длинрное, но читаемое правило, и в подложке но разворачивается в их произведение.

Ещё есть такая штука, как modulate state, она подменяет плохой seqno на случайный.

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

Антифлуд. Когда мы гвоорим о том, что у нас каждое правило в openbsd теперь созд. временное правило, то мы начинаем заботиться вот чем: как бороться с ситуацией, когда придёт человек с syn flood. Что касается таблиц tcp, то там понятно: там есть счётчик, к которому говорим: первую тысячу соед. в секунду принимаем, а потом подвесить. У pf есть богатый раздел, посвящённый илмитам и счётчикам. Посему, никто не говорит, что будет созд. беск. количество временных правил, их может созд. огр. количество на праввило. Можно сказать в скобочках некоторое количество опций. Вспомнил про это лектор потому, что среди опций можно вписать след. штуку: max-per-conn 10, overload <badguys>, и в таблице сказать drop all from <badguys>. Это правило на ip.

Таблички доступны из userspace, и можно с ними делять разные вещи: письма начальству их рассылать...

Ещё одна фишка — syn proxy. Вообще, pf очень любит пересобирать проходящий через него траффик, и это --- одна из них.

Последовательность слов в правиле может быть дост. произвольной, лишь бы это нормально читалось. Это ещё одно подтверждение openbsd.

Можно в port 80 написать synproxy. Весь 3-level handshake проделывается фаерволлом, если коннектятся не с ней. как олько подкл. произошло, он проигрывает вторую процедуру подкл., посчле чего начинает гонять трафик. В чём смысл: если у нас снаружи идёт syn flood, то машина по сторону не увидит никогда. Дальше мы с флудером сами разбираемся, а сервер и не видит ничего.

Антиспуф. Можно написать antispoof [log] for dl0. Фактически, это всего два правила: первое блокирует приём всех пакетов на ip-адрес, связанный с указанных интерфейом, через другие интерфейсы. Это правило запрещает прохождение чрез другие интерфейсы трафика с ip-адресом в данную сеть, и блокирует траффик, если у него src ip с данного интерфейса. Аналогич. правила:

block '''in''' on ~fxp0 inet from 10.0.0.0/24 to any

block '''in''' inet from 10.0.0.1 to any

Но тогда блокируется и ситуация, когда приходит пакет с иным ip с лупбэка, и для предотвр. этого можно написать set skip on lo0 10.0.0.1/24, и тогда lo0 вообще не будет принимать участие в фаерволле.

Ещё одна фича --- URPF, про неё расск. в прошлый раз.

Пассивное опр. ОС: лежит файл в /etc с фингерпринтами.

Packet forwarding нужно включать вне pf в sysctl.

Что касается ната: поддерживается нат 1 в 1, много в 1, много в много. Пример:

nat on tl0 from 192.168.1.0/24 to any -> 24.5.0.5

Что может предст. проблему: 24.5.0.5 может предст. проблему, поск. мы можем его сменить, 192.168.1.0/24 может предст. проблему, потому что мы его можем сменить. Для испр. этого можно сделать следующее:

nat on tl0 from fxp0:network to any -> tl0

Наконец, если эти адреса переменные, если мы ожидаем, что адрес на tl0 может меняться, то можно сказать

nat on tl0 from fxp0:network to any -> (tl0)

Мы помним, что tl0 быстрее (tl0), так как резолвинг в первом случае делаетсчя один раз, а не каждый раз, как во втором.

Когда nat один в много или много в много

binat on tl0 from fxp0:network to any -> (tl0)

покольку тут некоторые вещи могут работать по-другому.

Очередная вкусность: предположим, есть машины, которым (временно) запрещён доступ в интернет. Как их обслуживать: очевдно, пост. временное правило. Где его поставить, если сначала идёт нат, потом фильтр? Можно написать

no nat tl0 from $dummy to any

Почему придумано такое правило, если вместо него можно написать фильтруещее? Чтобы решение о натинге и ненатинге лежали рядом.

pfctl -s state

dnat:

rdr on tl0 proto tcp from any to any port 80 -> $www port 80

Можно писать диапазон портов.

Как разруливать запросы изнутри:

* split horizon

* proxy: netcat, пропис. в inetd: 127.0.0.1:5000 stream tcp row all nobody /usr/bin/nc nc -w 20 192.168.1.10 80. Что делает эта команда: как только приходит соед. на 127.0.0.1:5000, то запускается nc, который редиректит трафик на 192.168.1.10:80. После чего пишется правило: rdr on $int_ip proto tcp from $int_net to $ext_if port 80 -> 127.0.0.1 port 5000

То, что создатели pf думали оп приближенности к пользователю, подтв. один пункт в документации --- shortcuts:

* Макросы

* Списки

* Разннобр. штуки, привод. к размножению правил

Options. Их такое количество, что лектору как-то даже непонятно, что говорить про них, поэтому он про них скажет вцелом. Одну группу опций составл. счётчики, лимиты и таймауты. Вторая группа по поводу того, где что лежит. Опции относительно таблиц. Опции, тон. к лимитам на оличество таблиц, правил, ... . Опции для логи-интерфейса. Всевозм. настр. оптимизации, напр., оптимизации поведения фаерволла (просто оптимизации, оптимиз. для медл. сетей, есть настройки, чтобы сеть работала во что бы то ни стало; можно самост. написать профайл по оптимизации и использовать его)

Лектор уже упоминал, что pf луюит пересобирать трафик. Ни с того, ни с сего, фаерволл, вместо того, чтобы траффик передавать, его накапливал и ретранслировал. Это и рекомм. делать по умолчанию. pf умеет делать довольно много интересных вещей тем же способом: например, собрать ip-пакет, а потом послать в правильном порядке. Вклю эот след. способом: scrub in all. Там есть много разных доп. параметров, про которые мы погвоорим. что аткое scrub. ... . Что можно делать: reassemble, crop.

Что касается пересборки tcp: в pf есть пересборка tcp-фреймов. Есть разные стеки, у которых разные стеки и пакеты разного качества (openbsd их понимает, а винда приходит в глубокое изумление), и pf их может пересобирать, после чего отпр. дальше, но уже в openbsd-стандарте.

Последнее, про что лектор успевате расскзаать, это якорь. Это такой набор правил, где может быть filter,nat,redirect, binat. Может быть их 4 типа, на якорь можно ссылаться из основного набора правил pf. идея якорей в том, чтобы бесп. такие хранилища фв-правил, которые вы часто модиф. из юзерспейса. Если их не исп., то для изм. правил нужно ост. фаерволл. А при исп. останавливать не надо. Кроме того, якоря можно отключать. Ссылок на якорь можно делать много. Это что-то вроде польз. цепочки в iptables. Главная фишка якоря в том, что его обновление не сказывается на работе фаерволла.

</div>

{{UNИX, весна 2009}}

{{Lection-stub}}