Редактирование: 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}} | ||
