Конфигурирование PF

Параметры настройки PF хранятся в файле /etc/pf.conf. В этом файле содержатся определения и правила, формат которых меняется в зависимости от конфигурируемых функций. Порядок следования правил имеет чрезвычайно важное значение, но не менее важен и порядок настройки функциональных особенностей. Если, например, попытаться реализовать контроль состояния до сборки фрагментированных пакетов, то соединения не будут устанавливаться должным образом.

Файл по умолчанию /etc/pf.conf содержит примеры правил, расположенные в нужном порядке, но если вы боитесь запутаться в правилах, я рекомендую в нужных местах отделять разделы комментариями, набранными заглавными буквами. (Комментарии в pf.conf начинаются с символа решетки (#).) Функциональные конструкции конфигурации должны вводиться в следующем порядке:

•                 Макроопределения

•                 Таблицы

•                 Параметры

•                 Нормализация пакетов

•     Управление полосой пропускания

•     Преобразование адресов

•     Перенаправление

•     Фильтрация пакетов

Да, PF – это больше, чем просто фильтр пакетов. Это многоцелевой инструмент манипулирования протоколом TCP/IP. Мы не будем рассматривать все его возможности, потому что это тема отдельной книги.

Макроопределения

Макроопределения позволяют определять переменные, которые упрощают создание и чтение правил. Например, ниже приводятся макроопределения, которые определяют сетевой интерфейс и его IP-адрес:

interface="fxpO" serveraddr="192.168.1.2"

Потом в правилах можно будет ссылаться на сетевой интерфейс по имени $interface, а на IP-адрес – по имени $serveraddr. Благодаря этому в случае смены IP-адреса сервера или замены сетевой карты достаточно будет внести всего одно изменение в pf.conf, чтобы приспособить правила под новые условия.

Таблицы и параметры

Фильтр пакетов PF может хранить в таблицах длинные списки адресов. Мы не будем использовать эту возможность, но вы должны знать о ее существовании.

Точно так же в PF имеются различные параметры, которые позволяют управлять синхронизацией сетевых соединений, размерами таблиц и другими внутренними настройками. Значения параметров по умолчанию вполне адекватны для использования в большинстве нормальных (и ненормальных) ситуаций.

Нормализация пакетов

Пакеты TCP/IP по пути следования могут быть разбиты на фрагменты, что повышает нагрузку на систему и увеличивает объем работы, которую придется выполнять серверу, чтобы иметь возможность обслуживать запросы и фильтровать пакеты. Прежде чем передать полученные данные клиентской программе, система должна собрать эти фрагменты, попутно решая, что делать с любыми другими случайно пришедшими частями. Сборка фрагментов в PF называется очисткой (scrubbing). Например, следующее правило выполняет сборку всех фрагментов, полученных сетевым интерфейсом, отвергает все фрагменты, слишком маленькие, чтобы считаться легитимными, и выполняет другие функции обработки потока входных данных:

scrub in all on $interface

Это правило будет воздействовать на все пакеты, поступающие в компьютер.

Несмотря на то, что очистка кажется хотя и удобной, но маловажной функцией, в действительности она имеет большое значение, так как фильтры PF могут работать только с полными пакетами. В отсутствие функции сборки работа с фрагментами становится чрезвычайно сложной и требует специальной обработки. Без очистки трафика будут наблюдаться проблемы обеспечения связи.

Полоса пропускания, преобразование адресов и перенаправление

Принципы управления полосой пропускания будут обсуждаться немного ниже, а пока лишь замечу, что PF может управлять объемом трафика, пропускаемого к определенному порту или IP-адресу.

Функции преобразования сетевых адресов (Network Address Translation, NAT) и перенаправления портов являются критически важными частями брандмауэра. Фильтр пакетов PF обладает множеством функций, обеспечивающих поддержку NAT и перенаправление, которые, впрочем, мы не будем рассматривать, так как перед нами не стоит задача построения брандмауэра.

Правила фильтрации трафика

Теперь рассмотрим то, что нам действительно необходимо. Правила фильтрации трафика в общем случае имеют следующий формат:

Opass ©out ©on $interface proto ©{ top, udp } all ©keep state

Первым в строке стоит ключевое слово О, которое определяет тип правила. Для каждого типа правила имеется свое ключевое слово. В данном случае – это правило фильтрации. Далее указывается, в каком направлении © движутся пакеты. Кроме того, правила PF содержат наименование интерфейса ©, к которому применяется это правило. Остальное содержимое правила зависит от его типа. В данном случае под действие правила подпадают только те пакеты, которые покидают систему через интерфейс, заданный макроопределением $interface, и только если они соответствуют остальным условиям.

Далее определяется тип трафика, соответствующий правилу. Тип трафика определяется по протоколу, номеру порта или флагам TCP/IP ©. Данному простому правилу соответствует весь трафик, который передается с использованием протоколов TCP и UDP. Далее говорится, что PF должен использовать механизм контроля состояния соединения, разрешая прохождение дальнейшего трафика, являющегося частью этого соединения.

Если говорить в целом, то это правило пропускает весь трафик TCP и UDP, покидающий систему. Данный сервер может открывать любые исходящие соединения, что весьма типично для сервера Интернета.

Обработка входящих соединений выполняется немного сложнее. Следующее правило разрешает доступ к веб-серверу извне:

pass in on $interface proto Otcp from ©any to ©($interface) ©port 80 ©flags S/SA keep state

Благодаря предыдущему примеру многое здесь вы сможете понять сами. Это правило пропускает входящий трафик при условии, что это трафик TCP О. Допустимым считается трафик, пришедший из любого источника ©, входящий через указанный сетевой интерфейс ©. (Круглые скобки, окружающие имя интерфейса, означают: «независимо от IP-адреса, присвоенного интерфейсу», что очень удобно при использовании DHCP.) Дале уточняется, что пропускаться должен только тот трафик, который идет на порт с номером 80 ©.

Единственное сложное место в этом правиле – это ключевое слово flags ©. Первый символ, стоящий перед символом слэша, указывает, какой флаг TCP должен быть установлен в пакете, а символы, стоящие за символом слэша, указывают флаги, которые должны проверяться. Символ S обозначает SYN, а символ А – АСК. Это означает: «Из флагов SYN и АСК должен быть установлен только флаг SYN». Каким бы сложным не выглядело это утверждение, в действительности оно означает лишь: «Данному правилу соответствуют только входящие запросы на открытие соединения».

Дополнительное выражение keep state, находящееся в конце правила, предписывает фильтру PF отслеживать это соединение и пропускать весь остальной трафик, принадлежащий этому соединению.

Если говорить в целом, то это правило гласит: «Разрешить открытие входящих соединений по протоколу TCP с портом 80». Порт с номером 80 обычно используется веб-серверами.

С флагами или без флагов?

В версии FreeBSD 6.0 и более ранних ключевое слово flags было обязательным. В версии FreeBSD 7.0 оно подразумевается по умолчанию. Если у вас возникают сомнения, включайте ключевое слово flags в правила.

Пример полного правила PF

Ниже приводится набор правил PF, реализующих защиту небольшого сервера Интернета. Вы можете принять этот набор за основу и приспособить его под свои требования.

interface="emO" scrub in all

О block in on $interface

© ft         разрешить входящий трафик SSH и РОРЗ из локальной сети

pass    in on $interface proto tcp from 192.168.1.0/24 to $interface port 22

pass    in on $interface proto tcp from 192.168.1.0/24 to $interface port 110

© ft         разрешить входящий трафик SMTP (25), HTTP (80) и HTTPS (443)

pass    in on $interface proto tcp from any to $interface port 25

pass    in on $interface proto tcp from any to $interface port 80

pass    in on $interface proto tcp from any to $interface port 443

© ft         разрешить входящие запросы к серверу DNS

pass    in on $interface proto tcp from any to $interface port 53

pass    in on $interface proto udp from any to $interface port 53

© ft         разрешить исходящий трафик

pass    out on $interface proto { tcp, udp } all

Набор правил начинается с макроопределения, которое задает имя сетевого интерфейса, благодаря чему после замены сетевой карты нам не придется переписывать все правила в наборе. Далее производится очистка входящего трафика. Оба эти правила были взяты непосредственно из предыдущих примеров.

Первое интересное правило, которое встречается в данном наборе, – это установка стратегии запрета по умолчанию с помощью оператора block О. Все, что явно не разрешено, – запрещено.

Следующие два правила пропускают трафик по определенным протоколам, исходящий с определенных IP-адресов ©. Благодаря этим правилам имеется возможность соединяться с сервером по протоколам РОРЗ и SSH из сети 192.168.1.0/24, которая, скорее всего, является локальной офисной или административной сетью.

Для всеобщего пользования предлагаются службы электронной почты, веб-сервера и HTTPS ©. Доступ к этим службам обеспечивается с помощью правил, которые уже встречались в предыдущих примерах, но с другими номерами портов. Кроме того, всем желающим разрешается доступ к серверу DNS ©, но для этой цели используются несколько иные правила. Служба DNS работает как с протоколом TCP, так и с протоколом UDP. Такого рода знания можно получить только из толстых книг, посвященных описанию протоколов TCP/IP, или в архивах почтовых рассылок, попутно вырывая волосы на голове1 при попытках заставить эти правила работать. Как могли бы заметить ярые сторонники PF, эти правила можно ужать и оптимизировать, но для небольшого сервера вполне пригоден и такой стиль. Наконец, сервер может инициировать исходящие соединения TCP и UDP с любыми портами ©.

Такая простая стратегия определяет основные правила, обеспечивающие возможность взаимодействий с нашим сервером. Несмотря на несовершенство, этот набор может стать серьезной преградой для злоумышленников. Предположим, что кто-то смог взломать веб-сервер и получить доступ к командной строке с привилегиями суперпользователя root через порт с номером 10000. Однако все его усилия пойдут

Именно по этой причине я рекомендую делать очень короткую стрижку.

прахом, так как брандмауэр не пропускает входящие соединения с этим портом.

Источник: ЛукасМ. FreeBSD. Подробное руководство, 2-е издание. – Пер. с англ. – СПб.: Символ- Плюс, 2009. – 864 е., ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий