Редактирование: UNИX, весна 2009, 07 лекция (от 08 апреля)
Материал из eSyr's wiki.
Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.
Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.
Текущая версия | Ваш текст | ||
Строка 124: | Строка 124: | ||
Лектор не дошёл до самого вкусного: куча правил, которые выроджаются в одно правило в 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}} |