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


City sport интернет магазин спортивной обуви http://freeshoes.com.ua/.
На сайте компании www.sigma-trans.ru можно заказать грузоперевозки на Газели.

Инструменты FreeBSD для фильтрации пакетов на уровне ядра используются, когда необходимо управлять доступом к сетевым приложениям, не поддерживающим TCP Wrappers, или когда требуется нечто, превосходящее TCP Wrappers по своим возможностям. Если вам потребовался фильтр пакетов, то лучше полностью заменить им реализацию TCP Wrappers. Применение двух инструментов на одном компьютере будет просто запутывать вас.

При фильтрации пакетов каждый сетевой пакет, поступающий в систему, сверяется со списком правил. Когда соответствующее правило найдено, ядро действует, исходя из этого правила. Правила могут пропустить, удалить или видоизменить пакет. Однако здесь нельзя применять замечательные параметры, разрешенные в TCP Wrappers; клиенту не отправляется сравнительно дружелюбное «сообщение о запрете» — вместо этого соединение разрывается на сетевом уровне еще до того, как пакеты будут доставлены приложению.

Идея фильтрации пакетов достаточно проста, но первая реализация этой стратегии может стать нелегким испытанием — как говорится, «ценным опытом». Будьте готовы потратить несколько часов на эксперименты с фильтрацией пакетов и не отчаивайтесь при неудачах. По своему опыту могу сказать, что источником разочарований является не пакетный фильтр, а незнание TCP/IP. Пытаться фильтровать трафик — занятие неблагодарное и бессмысленное. Единственный способ по-настоящему изучить протокол TCP/IP состоит в том, чтобы работать с ним. Если информации в главе 6 для вас оказалось недостаточно, приобретите книгу «The TCP/IP Guide» Чарльза М. Козиерока (Charles M. Kozierok) (No Starch Press, 2005).

Операционная система FreeBSD обладает богатым набором пакетных фильтров: IPFW, IP Filter и PF.

IPFW — это программное обеспечение фильтрации пакетов, изначально входившее в состав FreeBSD. Оно очень тесно интегрировано в операционную систему — файлы с говорящими названиями, /etc/rc.firewall и /etc/rc.firewall6, предназначены исключительно для нужд IPFW. Это очень мощное программное обеспечение, пользующееся большой популярностью у опытных системных администраторов FreeBSD, но для начинающих оно является довольно сложным.

Второй пакетный фильтр — IP Filter — не является программным обеспечением построения брандмауэров, разработанным исключительно для FreeBSD, но поддерживается некоторыми другими UNIX-подобными операционными системами. Этот фильтр разрабатывался в основном одним человеком — Дарреном Ридом (Darren Reed), который приложил героические усилия, написав большую часть программного кода и выполнив перенос на разные операционные системы. Однако IP Filter не получил широкой популярности.

Основное внимание мы будем уделять продукту с названием PF, или packet filter (фильтр пакетов). Впервые PF появился в OpenBSD и разрабатывался как очень мощный, гибкий и простой в использовании. Обычный администратор FreeBSD может, используя PF, добиться любых эффектов, которые можно получить с помощью двух других фильтров пакетов.

Примечание
Более подробную информацию о PF вы найдете в книге Питера Н. М. Ханстена (Peter N. М. Hansteen) «The Book of PF» (No Starch Press, 2007) или в моей книге «Absolute OpenBSD» (No Starch Press, 2003), в которую включено несколько глав о PF. Можно также заглянуть в сборник часто задаваемых вопросов PF FAQ в Интернете, но там вы не найдете простых ответов.

Активизация PF

Фильтр пакетов PF состоит из модуля ядра pf.ko и программы, работающей в пространстве пользователя, — pfctl(8). Прежде чем можно будет начать использовать PF, необходимо загрузить модуль ядра. Проще всего это сделать, поместив в rc.conf следующую строку:

pf_enable="YES"

По умолчанию фильтр PF пропускает все пакеты; это означает, что простая активизация брандмауэра не обеспечивает никакой защиты.

Фильтрация пакетов: принимать по умолчанию или отвергать

Стратегии принятия и запрета по умолчанию чрезвычайно важны в фильтрации пакетов. Если выбрано принятие по умолчанию и необходимо защитить систему или сеть, то для блокирования всех возможных атак потребуется множество правил. При выборе запрета по умолчанию необходимо явно открыть «лазейки» для каждого предлагаемого сервиса. В большинстве случаев предпочтительнее использовать стратегию запрета по умолчанию. Хотя при такой стратегии управлять фильтром значительно сложнее, тем не менее повышенный уровень безопасности с лихвой окупит все трудозатраты.

При запрете по умолчанию очень легко полностью заблокировать удаленный доступ к системе даже для самого себя. Если у вас имеется SSH-соединение с удаленной системой, и вы по ошибке нарушите правило, разрешающее доступ по SSH, у вас появятся проблемы. Такое случается со всеми, хотя бы один раз, поэтому особо не смущайтесь, если это произойдет и с вами. Однако будет лучше, если вы начнете изучать принципы фильтрации пакетов не на удаленной машине — начните с машины, к которой у вас имеется физический доступ, чтобы проще было исправить свою ошибку. Я много раз закрывал доступ самому себе — обычно, когда не утруждал себя размышлениями при устранении неполадок, связанных с фильтрацией пакетов. Единственное решение — проклиная себя, лезть в машину, ехать на удаленную точку, долго извиняться перед людьми, которым я причинил неудобство, и на ходу устранять проблему. К счастью, с возрастом такое случается все реже и реже.*

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

Основы фильтрации пакетов и контроль за состоянием соединения

Вспомним из главы 6, что соединение TCP может пребывать в различных состояниях. Оно может быть открытым, открываться, закрываться и т. д. Например, пытаясь открыть соединение, клиент посылает серверу пакет SYN, запрашивая синхронизацию. Если сервер ожидает получение запросов на соединение, в ответ он посылает клиенту пакет SYN-ACK, что означает следующее: «Я получил ваш запрос на соединение. Вот базовая информация для установления соединения». Клиент подтверждает прием информации, отвечая пакетом АСК, что означает: «Я получил и подтверждаю вашу информацию о соединении». Каждая часть процесса «тройного рукопожатия» должна быть выполнена, чтобы соединение было действительно установлено. Правила фильтрации пакетов должны разрешать каждую часть «тройного рукопожатия», а также саму передачу данных. Разрешение на получение входящих запросов соединений бесполезно, если правила фильтрации пакетов не позволяют отправить обратно уведомление.

В 1990-х годах фильтры пакетов проверяли каждый пакет по отдельности. Если пакет отвечал правилу, он проходил дальше. Система не анализировала предыдущие пакеты и не могла определить, был ли тот или иной пакет частью легитимной транзакции или нет. Например, если пакет SYN-ACK, привязанный к адресу «изнутри» фильтра пакетов, прибывал к нему «снаружи», фильтр пакетов решал, что этот пакет должен быть ответом на пакет, одобренный ранее. Для завершения «тройного рукопожатия» такой пакет необходимо было принять. В результате злоумышлениники могли подделывать пакеты SYN-ACK и использовать их для обхода казавшихся надежными устройств. Поскольку фильтру пакетов не был известен отправитель предыдущего пакета SYN, он не мог отклонить такие подложные пакеты SYN-ACK. Когда пакеты, отправленные злоумышленниками, проникали в сеть, они инициировали ответ от того или иного устройства и выведывали информацию о системе.

Контроль состояния, введенный в большинстве современных пакетных фильтров, призван противодействовать таким атакам. Контроль состояния — это сохранение информации о каждом соединении и его текущем состоянии. Если входящий пакет SYN-ACK представляется частью действующего соединения, но никто не посылал соответствующий запрос SYN, он отклоняется. Хотя это усложняет работу ядра, написать правила фильтрации пакетов для stateful inspection на самом деле легче. Фильтр пакетов должен отслеживать множество других возможных состояний, то есть это труднее, чем может показаться; особенно, если добавить контроль за фрагментацией пакетов, противодействие мистификации адресов и т. п.

Те, кто подумал: «А-а, фильтрация пакетов — это все равно, что брандмауэр», по сути правы. Слово брандмауэр применимо к множеству устройств, предназначенных для защиты сети. Некоторые из них довольно замысловаты, некоторые по уровню своего интеллекта сравнимы с бетонной стеной. Сейчас слово брандмауэр превратилось в модное словечко из лексикона маркетоидов, не имеющее точного значения. Оно подобно слову автомобиль. Имеете ли вы в виду Gremlin 1972 года с двигателем в шесть лошадиных сил и по количеству выхлопных газов не соответствующий Киотскому договору, или сверкающий Chevy SSR 2005 года, причудливой трехцветной раскраски, оснащенный пятисотсильным двигателем и стереосистемой Apocalypse? Оба автомобиля нашли свою нишу, но один из них, очевидно, эффективнее. Хотя Gremlin’ы среди брандмауэров находят свою нишу, лучше приобрести что-нибудь получше.

Итак, система FreeBSD может стать таким крепким брандмауэром, каким ее желает сделать администратор. Фильтрация пакетов — это только начало, в каталогах /usr/ports/net и /usr/ports/security можно найти множество приложений-представителей (proxy), которые позволят вашей системе FreeBSD стать вровень с Checkpoint или PIX и даже победить в состязании, затратив на десятки тысяч долларов меньше.

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

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

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

  • Макроопределения
  • Таблицы
  • Параметры
  • Нормализация пакетов
  • Управление полосой пропускания
  • Преобразование адресов
  • Перенаправление
  • Фильтрация пакетов

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

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

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

interface="fxp0"
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 и перенаправление, которые, впрочем, мы не будем рассматривать, так как перед нами не стоит задача построения брандмауэра.

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии запрещены.