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

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

Перейти к: навигация, поиск

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

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

Текущая версия Ваш текст
Строка 1: Строка 1:
-
* '''Диктофонная запись:''' http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_04_08.ogg
 
- 
= packet filter (pf) =
= 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. Зачем их так мноог?: Зачем нужен ещё один фаерволл. Здесь есть две, или три нерешённых задачи:
Мы уже говорили о разных фаерволлах в двух разных юних-подобных ОС, про ipfw/ipfw2 и про iptables в linux. Зачем их так мноог?: Зачем нужен ещё один фаерволл. Здесь есть две, или три нерешённых задачи:
Строка 123: Строка 121:
* all
* all
-
Лектор не дошёл до самого вкусного: куча правил, которые выроджаются в одно правило в pf. Про это лектор расскажет в след. раз.
+
Лектор не дошёл до самого вкусного: куча правил, которые выроджаются в одно правило в 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
+
-
 
+
-
Есть много действий, выражающихся в антиспуф.
+
-
Попытка посылки с внешнего интерфейса на лупбэк и т.д.
+
-
Все это включается антиспуфом.
+
-
 
+
{{UNИX, весна 2009}}
{{UNИX, весна 2009}}
{{Lection-stub}}
{{Lection-stub}}

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. 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
Личные инструменты
Разделы