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

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

Версия от 16:45, 8 апреля 2009; ESyr01 (Обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

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.