The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Создание межсетевого экрана с помощью PF OpenBSD (openbsd pf firewall nat altq carp bandwidth limit)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: openbsd, pf, firewall, nat, altq, carp, bandwidth, limit,  (найти похожие документы)
From: Михаил Сгибнев <mixa(@).dreamcatcher.ru> Date: 2006-09-13 16:04:07 Subject: Создание межсетевого экрана с помощью PF OpenBSD
Copyright ╘ 2005 Peter N. M. Hansteen

Перевод: Сгибнев Михаил
  1. Предварительные комментарии
  2. PF?
  3. Пакетный фильтр? Межсетевой кран?
  4. NAT?
  5. PF сегодня
  6. BSD vs Linux - Конфигурация
  7. Самый простой вариант - одиночная машина (OpenBSD)
  8. Самый простой вариант - одиночная машина (FreeBSD)
  9. Чуть более сложный
  10. Статистика из pfctl
  11. Простой маршрутизатор с NAT
  12. Старый грустный FTP
  13. Решение проблем - утилиты ping и traceroute
  14. Работа с внутренними web и почтовыми серверами
  15. Таблицы, делающие вашу жизнь легче
  16. Журнал событий
  17. Следим за всем с помощью pftop
  18. Невидимый маршрутизатор - bridge
  19. Управление трафиком с помощью altq
  20. ALTQ - распределение пропускной способности
  21. ALTQ - приоритезация трафика различных типов
  22. ALTQ - обработка нежелательного трафика
  23. CARP и pfsync
  24. Тяжелое врямя для спамера
  25. Ссылки

Предварительные комментарии

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

Внимание:

Этот документ является переводом с норвежского, лекции, прокомментированной следующим образом: "Эта лекция - о системах сетевой защиты и связанных с ними вопросах, с примерами из реальной жизни На основе пакетного фильтра PF проекта OpenBSD. Данный пакетный фильтр предлагает использование систем защиты сетей, трансляцию сетевых адресов (Network Address Translation), управление трафиком и управление полосой пропускания в единственной, гибкой и дружественной администратору системе. Питер надеется, что лекция даст вам некоторые идеи о том, как управлять вашим сетевым трафиком, решая все стоящие перед вами задачи. "

PF?

Сначала скажем несколько слов о предмете нашего разговора, пакетном фильтре PF операционной системы OpenBSD.

PF был написан в течении лета-осени 2001 года Дэниелом Хартмеиром(Daniel Hartmeier) и сообществом разработчиков OpenBSD. В декабре 2001 года PF вошел в основной состав ОС OpenBSD 3.0.

Потребность в системе сетевой защиты для OpenBSD назрела тогда, когда Даррен Рид(Darren Reed) обьявил миру, что IPFilter, интегрированный в OpenBSD не будет распространяться по лицензии BSD. На самом деле, в тексте лицензии ничего не изменилось, из слова в слово повторяя текст BSD, было запрещено только делать изменения в исходном коде. OpenBSD версия IPFilter содержала множество изменений и настроек, которые не соответствовали тексту лицензии. IPFilter был удален из дерева исходных текстов OpenBSD 29-ого мая 2001 и в течение нескольких недель OpenBSD-current не содержал программного обеспечения для фильтрации пакетов.

К счастью, в Швейцарии, Дэниел Хартмеир уже экспериментировал с кодом ядра.

Когда случился кризис лицензирования, патч Дэниэла вклинивался в сетевой стэк и у него появились мысли о возможности фильтрации пакетов.

IPFilter был удален из дерева исходных текстов 29 мая. ервый коммит кода PF был сделан в воскресенье, 24 июня 2001 в 19:48:58 UTC.

Затем последовали несколько месяцев интенсивной работы и версия PF в составе OpenBSD 3.0 была уже вполне законченным вариантом пакетного фильтра, включающего в себя возможность NAT.

Дэниел Хартмеир и другие разработчики PF учли опыт работы с IPFilter. На USENIX 2002 были проведены тесты, показавшие, что на OpenBSD 3.1 PF показал производительность сравнимую, а иногда и превосходящую работу IPFilter на той же системе и iptables под Linux на аналогичном оборудовании.

Кроме того, некоторые тесты были проведены на оригинальном PF из OpenBSD 3.0. Они проводились главным образом для сравнения версий 3.0 и 3.1. Информция по этим тестам доступна на странице Дэниела Хартмеира http://www.benzedrine.cx/pf-paper.html.

Я не видел результатов тестов, выполненных недавно, но на собственном опыте могу сказать что PF не требователен к машинным ресурсам. Например, маршрутизацию между сетью Datadok и внешним миром осуществляет Pentium III 450MHz с 384MB RAM. В моменты наблюдений 'idle' составляло не меньше 96%.

Пакетный фильтр? Межсетевой кран?

Ранее по тексту я уже использовал некоторые термины без дачи их определений и вскоре я исправлю это упущение.

PF работает в мире, который состоит из пакетов, протоколов, подключений и портов.

Анализируя порт иточника или назначения, используемый протокол и адреса PF принимает решение о том, куда пропускать пакет и пропускать ли его вообще.

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

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

NAT?

Другая вещь, о которой мы будем много говорить - это "внутренние" и "внешние" адреса, "маршрутизируемые" и "не маршрутизирумые". Этот вопрос не связан непосредственно с системами сетевой защиты и фильтрации пакетов, но мы вынуждены будем немного его коснуться. Все началось в в начале 1990-ых, когда кто-то подсчитал, сколько всего возможно пользователей Интернета.

Во времена разработки системы адресации компьютеры были большими, очень дорогими и обычно обслуживали большое количество пользователей. Тогда подключенными к сети были лишь университеты и компании с заказами Пентагона. По сути дела 32 битная адресация в 4 октетах позволила бы подключить миллионы машин.

Но тут случилась коммерциализация Интернет и в сеть попали сотни тысяч дешевых маленьких машин, в результате чего адресное пространство стало таять с катастрофической скоростью. Для решения этой проблемы был разработан протокол IP version 6, если коротко - IPv6, использующий 128 битную адресацию. OpenBSD по умолчанию поддерживает IPv6 и PF способен работать с трафиком IPv6.

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

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

Это - то, что называют "Трансляцией сетевых адресов"(NAT), иногда упоминается "подмена IP адресов", маскарадинг или нечто подобное.

Узнать диапазоны не маршрутизитуемых сетей можно в "RFC 1918 addresses".

Внимание:

Два документа определяют работу NAT: RFC 1631, "The IP Network Address Translator (NAT)", датированный маем 1994 и RFC 1918, "Address Allocation for Private Internets", dдатированный февралем 1996.

PF сегодня

К этому моменту мы прошли некоторую подготовку и можем непосредственно приступить к рассмотрению основного вопроса. Прошло несколько лет с момента выхода PF и теперь, в составе OpenBSD 3.6 PF стал пакетным фильтром, способным на очень многие вещи.

С одной стороны, PF классифицирует пакеты, основываясь на типе протокола, порта, типе пакета, источнике или адресе назначения и, с некоторой долей уверенности, на исходной операционной системе.

И даже если NAT не является самой необходимой частью пакетного фильтра, по практическим соображениям все же в функции PF включена логика NAT.

PF способен на основе протокола, адреса и других данных пропускать трафик адресатам, таким как удаленные машины или сервисные службы.

Еще до написания PF, OpenBSD содержал код altq для балансировки нагрузки и гибкого управления трафиком, в проследствии они были интегрированы между собой.

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

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

BSD vs Linux - Конфигурация

Я предполагаю, что нынешние читатели больше знакомы с одним из дистрибутивов Linux, чем с семейством BSD и поэтому кратко упомяну ключевые отличия.

В BSD системах сетевые интерфейсы не обозначаются как eth0 и т.д. Имя каждого интерфейса соответствует имени драйвера устройства и его порядковому номеру, например сетевые карты 3Com, использующие драйвер xl обозначаются как xl0, xl1 и т.д.

Дистрибутивы BSD организованы таким образом, чтобы читать конфигурацию из файла /etc/rc.conf, который читается сценарием/etc/rc при запуске. OpenBSD рекомендует использовать /etc/rc.conf.local для локальных настроек, так как rc.conf содержит значения по умолчанию, в то время как FreeBSD использует /etc/defaults/rc.conf, чтобы сохранить настройки по умолчанию, используя /etc/rc.conf для хранения пользовательских настроек.

PF конфигурируется редактированием /etc/pf.conf и использованием утилиты командной строки pfctl. pfctl имеет очень много опций. Сегодня мы рассмотрим только наиболее используемые.

Если вас интересует вопрос наличия web-интерфейса для управления PF, то предупреждаем, что они не являются частью основной системы. Создатели PF не против наличия таких средств, но они не представляют пока себе графического интерфейса для редактирования pf.conf, передачи опций pfctl и еще некоторых особенностей unix.

Самый простой вариант - одиночная машина (OpenBSD)

Ну, вот мы и подошли к установке PF на выделенную машину в самой простой конфигурации. По условиям вводной машина непосредственно подключена к Интернет.

Для запуска PF при старте системы необходимо внести следующую строку в /etc/rc.conf.local: Очень просто. Там же вы можете указать местоположение файла конфигурации: После перезагрузки PF должен будет выдать на консоль сообщение "PF enabled", что говорит об активизации пакетного фильтра. Файл конфигурации /etc/pf.conf, устанавливаемый вместе с OpenBSD или FreeBSD, содержит множество полезных примеров, но они все прокомментированы.

Если мы не хотим перегружаться, то можно использовать утилиту pfctl:

Внимание:

В качестве отступления от темы, хочу указать, что при необходимости повышения привелегий я использую утилиту sudo. Она доступна в коллекции портов BSD систем или поставляется с базовой системой.

Самый простой вариант - одиночная машина (FreeBSD)

В операционной системе FreeBSD вам необходимо внести несколько больше изменений в /etc/rc.conf, руководствуясь FreeBSD Handbook: В FreeBSD, PF по умолчанию скомпилирован как загружаемый модуль ядра. Это означает, что для запуска PF вы должны выполнить команды: Теперь мы нуждаемся в некотором наборе правил фильтрации. Сейчас мы приведем пример самого простого варианта, для машины, на которой не выполняются никакие сервисы, которая подключена к локальной сети или сразу в Интернет. Итак, наш etc/pf.conf пока будет выглядеть так: Этими правилами будет запрещен любой входящий трафик, разрешен наш исходящий и пропущен входящий трафик, являющийся ответным на наши запросы. Если вы готовы к использованию такого набора правил, то загружаем их:

Чуть более сложный

Для написания несколько более структурированной и законченной системы правил фильтрации мы запретим весь трафик, чтобы впоследствии разрешить только необходимый. Делать это мы будем используя отличительные особенности PF: списки и макросы.

Теперь наш /etc/pf.conf будет начинаться так: Макросы требуют определения перед использованием: Теперь мы можем продемонстрировать сразу несколько вещей - то, что макрос может быть списком и то, что PF понимает в качестве номера порта название службы. Именование служб берется из /etc/services. Теперь наши правила будут выглядеть следующим образом: Здесь, особо образованные из наших читателей могут указать, что протокол UDP не предусматривает обратной связи, но PF, не смотря на это, может обработать такие соединения. Например, вы, скорее всего, захотите принять ответ от сервера имен DNS.

После выполненных изменений нам необходимо перезагрузить правила: Если нет никаких синтаксических ошибок, то pfctl не выдаст никаких сообщений. Установленный флаг -v укажет pfctl сделать более подробный вывод.

Статистика из pfctl

В процессе работы PF возможен просмотр некоторой статистики, это делается с помощью утилиты pfctl. Для этого используется флаг "-s" и тип отображаемой информации.

Следующий пример взят с моего домашнего шлюза, в то время как я готовил эту лекцию: В первой строке указывается, что PF работает уже несколько дней, отсчет ведется со времени последней перезагрузки. pfctl -s all даст вам еще более детальную информацию. Для получения дополнительных сведений, обратитесь к man 8 pfctl.

К настоящему моменту мы имеем одну единственную машину, защищенную достаточно для подключения к Интернет.

Нам не хватает еще несколько вещей. Например, все же стоило разрешить проходить некоторому icmp и udp трафику, например, для работы утилит ping и traceroute.

Хотя в настоящее время и доступны более современные и безопасные сервисы, нам скорее всего потребуется нормальная работа ftp.

Вскоре мы вернемся к рассмотрению этих вопросов.

Простой маршрутизатор с NAT

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

Мы предполагаем, что в машину была установлена дополнительная сетевая плата или организовано подключение к внешней сети через дополнительные средства, такие как PPP. В данной лекции мы не будем привязываться к конкретному интерфейсу, поэтому тип подключения не так важен. Для примеров приведенных ниже, в зависимости от типа соединения будет меняться только обозначение интерфейса ppp или ethernet.

Первым делом нам необходимо подготовить машину к транзиту трафика, то есть чтобы трафик принимаемый на один интерфейс мог быть перенаправлен в другую сеть через другой интерфейс. Первоначально мы сделаем это с помощью утилиты sysctl для протокола IPv4: Для включения маршрутизации протокола IPv6 необходимо выполнить: Для того, чтобы сделать эти изменения постоянными внесем следущие изменения в /etc/sysctl.conf (OpenBSD): Или в /etc/rc.conf (FreeBSD): Для FreeBSD необходимые параметры можно выставить и с помощью sysctl, но более предпочтительным было бы использование файла rc.conf.

Для просмотра параметров интерфейсов, которые вы планируете использовать, служит команда ifconfig -a:

Если вы намереваетесь пропускать трафик из вашей внутренней сети наружу, то ваш /etc/pf.conf будет выглядеть следующим образом: Обратите внимание на использование макросов для определения сетевых карт. Здесь используются сетевые карты 3Com, но в дальнейшем мы убедимся, что тип интерфейса не играет особой роли. Использование макросов позволяет абстрагироваться от типа интерфейса, сетевой карты или ее адреса.

Обратите внимание на правило NAT. В этом правиле мы транслируем "немаршрутизируемые" адреса нашей локальной сети в один внешний адрес сетевого интерфейса нашего маршрутизатора.

Использование выражения ($ext_if) позволяет нам использовать правило в случае, если адрес назначается динамически.

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

Кроме того, у нас имеется в запасе еще несколько интересных правил разрешения трафика, их мы покажем ниже. Например, для доступа к нашей машине из интернета по ssh: или так: Разрешим работу службы DNS. Определим макрос: И добавим само правило: Обратите внимание на ключевое слово quick. Если пакет соответствует правилу с этим ключевым словом то пакет прекращает дальнейшее прохождение по цепочке правил и к нему применяется то действие, которое указано в правиле. Использование ключегого слова quick весьма удобно, когда вам требуется сделать несколько правил-исключений.

Вместе со службой DNS мы разрешим службу сетевого времени(NTP), которая используется для синхронизации системных часов. Отличительная особенность обоих протоколов заключается в том, что они посылают данные и по tcp и по udp.

Внимание:

Для пользователей модемного соединения, ADSL или PPP over Ethernet (PPPoE) внешним интерфейсом будет tun0, вместо интерфейса типа ethernet.

Старый грустный FTP

Оглавление:

В списке разрешенных портов мы можем увидеть порты протокола передачи файлов FTP. Этот протокол очень стар и полон загадок, которые вызывают массу проблем, в том числе и с безопасностью. Ключевыми проблемами использования этого протокола: Эти факторы осложняют построение системы сетевой защиты и вызывают проблемы при функционировании системы.

В настоящее время существуют более безопасные и удобные протоколы передачи файлов, такие как sftp или scp, которые обеспечивают идентификацию и передачу данных через зашифрованные соединения. Настоящие профессионалы IT должны предпочесть что-либо отличное от ftp.

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

Ftp через NAT: ftp-proxy

ftp-proxy является частью базовой системы OpenBSD и других систем, содержащих PF. Обычно она вызывается "супер-сервером" inetd через конфигурацию /etc/inetd.conf. Приведенная ниже строка запустит ftp-proxy при работе NAT на кольцевом интерфейсе lo0: Эта строка находится по умолчанию в вашем inetd.conf, но она прокомментирована символом # в начале строки. Для того, чтобы изменения вступили в силу, перезапустите сервис inetd. На *BSD дистрибутивах это делается командой: или аналогичной. Если вы не уверены, то обратитесь к man 8 inetd. В OpenBSD можно сделать таким образом: С этого момента inetd выполняется с новыми параметрами настройки.

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

Мы вставляем наше правило rdr сразу после правила NAT в нашем /etc/pf.conf: Также необходимо добавить правило, разрешающее прохождение перенаправленного трафика: Сохраним pf.conf и загрузим новые правила: После таких вот нехитрых действий ftp должен прекрасно работать.

Этот пример предполагает, что Вы используете трансляцию сетевых адресов (Network Address Translation) на шлюзе и внутри локальной сети используете адреса из диапазона частных сетей.

Ftp через pf с маршрутизируемыми адресами: ftpsesame

В случаях, когда локальная сеть использует официальные, маршрутизируемые адреса, то могут определенные проблемы в защите ftp-соединений. Так как такие случаи достаточно редки, то я не буду их рассматривать, а прямиком направлю вас на http://www.sentia.org/projects/ftpsesame/. ftpsesame присоединяется к набору правил через якорь, называемый sub-ruleset. Документация включает в себя страницу руководства man и множество примеров, которые вы можете использовать.

Решение проблем - утилиты ping и traceroute

Написанный нами набор правил имеет один существенный недостаток - не работают средства диагностики и поиска неисправностей в сети, а именно утилиты ping и traceroute. Это не будет иметь значение для большинства ваших пользователей, особенно работающих с Windows и тех, кто считает, что утилита ping - опасная команда и что icmp должен быть вне закона. Но вам скорее всего эти утилиты будут нужны. Для успешного решения это проблемы выполним несколько простых шагов. Добавляем макрос: И соответствующее правило: Если вам необходимо попускать и другие типы icmp пакетов, то добавьте их в макрос icmp_types.

traceroute - другая команда, которая является весьма полезной, когда ваши пользователи утверждают, что Internet не работает. Правило ниже работает с командой traceroute на всех Unix, к которым я имел доступ, включая GNU/Linux: Если в каких-либо других операционных системах это правило не будет работать, то вам придется откорректировать его. Это решение было найдено в списке рассылки openbsd-misc и в случаях проблем с PF я советую вам обратиться к архиву рассылки на http://marc.theaimsgroup.com/.

Работа с внутренними web и почтовыми серверами

Проходит время и нам необходимо внести изменения в наши правила. Довольно обычной является ситуация, когда необходимо предоставлять внешние сервисы, а свободных маршрутизируемых адресов дря размешения серверов попросту нет, а выполнение на одной машине нескольких сервисов не самое безопасное решение.

Механизмы перенаправления в PF довольно просты и позволяют легко разместить серверы внутри локальной сети. Если мы планируем разместить в локальной сети сервера http, https и почтовый сервер для приема и отправки почты, то этот отрезок списка правил будет выглядеть так: Обратите внимание на флажок "synproxy" в новых правилах. Это означает, что pf будет перехватывать входящие соединения и отправлять их на внутренние сервера, выполняя роль прокси-сервера.Это обеспечивает некоторую защиту против нескольких типов атак.

Правила, описывающие работу с демилитаризованной зоной(DMZ), когда локальная сеть отделаяется от сети, в которой размещены серверы, не будут сильно отличаться от вышеприведенных, достаточно только пределить интерфейсы локальной сети и сети DMZ.

Таблицы, делающие вашу жизнь легче

К моменту прочтения этой главы вы можете придти к мысли, что написанные правила недостаточно гибки, ведь могут быть случаи, когда определенный трафик должен быть разрешен или заблокирован, но нет желания вносить правило в основной список правил фильтрации. PF предлагает очень удобный механизм для решения этой проблемы. Таблица - это структура, главным образом полезная как список правил, которые могут управляться, не вызывая перезагрузки основного набора правил. В нет также можно осуществлять быстрый поиск. Имена таблиц всегда включаются в < >, подобно этому: Здесь в таблице содержатся адреса сети 192.168.2.0/24 за исключением адреса 192.168.2.5, что указано оператором !(логическое NOT). Также возможна загрузка таблицы из выделенного файла, например /etc/clients, значения в котором указываются по одному в строке: Имя файла в свою очередь используется, чтобы инициализировать таблицу в /etc/pf.conf: Тогда, например, Вы можете заменить одно из наших более ранних правил на следущее: Имея в руках такой инструмент, вы можете оперативно изменять правила фильтрации. Например, для редактирования таблицы достаточно воспользоваться командой: Вы могли бы решить сохранять копию таблицы на диск, используя планировщик заданий cron. В качестве альтернативы, вы можете редактировать файл /etc/clients и заменить им находящуюся в памяти содержание таблицы с данными файла: Для выполнения рутинных действий по добавлению/удалению элементов таблиц советую вам написать соответствующие скрипты. Единственные реальные ограничения лежат в ваших собственных потребностях и вашем творческом потенциале.

Вскоре мы вернемся к другим примерам использования таблиц.

Журнал событий

до сих пор мы не слова не сказали о регистрации событий. PF позволяет вести регистрацию с помощью ключевого слова "log", указываемого после интересующего нас правила. Для ограничения обьема регистрируемых данных можно также указать интересующий нас сетевой интерфейс. Сделать это можно правилом: И соответствующим образом отредактировать правила: В результате этого, весь трафик, подходящий под это правило будет зарегистрирован в формате вывода утилиты tcpdump. Это может быть довольно удобно при а=выставлении счета за использованный трафика.

Можно было бы разместить такое правило: Для того, чтобы удостовериться что вы не пропускаетет ничего лишнего. Руководство пользователя PF содержит детальное описание того, как привести журнальный файл к читаемому текстовому формату через syslog и это действительно звучит довольно привлекательно. Регистрация событий - очень полезная функция, но она в любом случае должна быть выборочной, так как есть опасность неконтролируемого разрастания файлов журналов.

Следим за всем с помощью pftop

Если вы интересуетесь, что и как ходит по сети, то поможет утилита pftop Эркина Акара. Название довольно символично, поскольку внешний вид очень похож на вывод программы top. Подключения можно вывести отсортированыым по различным критериям, таким как правил, обьему, возрасту и т.д.

Эта утилита не входит в базовый комплект поставки, но в OpenBSD и FreeBSD она может быть установлена из системы портов - /usr/ports/sysutils/pftop.

Невидимый маршрутизатор - bridge

Бридж, в нашем контексте, машина с двумя или больше сетевыми интерфейсами, расположенная между Интернет и внутренней сетью/сетями, причем интерфейсам не назначены IP адреса. Если на рассматриваемой машине установлена OpenBSD или другая операционная система с поддержкой PF, то все еще остается возможность фильтрации и переадресации трафика. Преимущество такой схемы очевидно - становится значительно труднее атаковать систему сетевой защиты. Недостаток - невозможность удаленного управления и конфигурирования, если вы только не назначите адрес интерфейсу, находящемуся внутри защищенной сети.

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

В дополнение, команда brconfig, входящая в состав OpenBSD предлагает собственный механизм фильтрации. Для получения дополнительной информации, обратитесь к страницам руководства bridge(4) и brconfig(8).

Управление трафиком с помощью altq

ALTQ - сокращение от ALternate Queueing, являющегося очень гибким средством перенаправления, приоритезации и балансировки сетевого трафика и существовавшего отдельным механизмом до интеграции в PF.

Altq использует понятие "очереди"(queue) в качестве главного механизма контроля трафика. Очереди определяются определенной полосой пропускания, выраженной в неком количестве от общей полосы канала и может состоять из подочередей различных типов.

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

Очереди базируются на классах(CBQ), что на практике означает определение полосы пропускания очереди как количество данных в секунду или процентах и указание приоритета . Приоритеты могут иметь значение от 0 до 7 для cbq очередей и от 0 до 15 для priq очередей, Чем выше значение, тем выше приоритет. Упрощенный синтаксис выглядит следующим образом: Если Вы будете использовать эти возможности в собственных наборах правил, вы должны при любых обстоятельствах прочитать страницу руководства man pf.conf и руководство пользователя PF. Эти документы содержат очень детальное и доходчивоее объяснение синтаксиса.

ALTQ - распределение пропускной способност

Теперь приведем пример из жизни. Очереди установлены на внешнем интерфейсе. Это, по всей видимости обычный подход, так как ограничения на полосу пропускания на внешнем интерфейсе более неблагоприятны. Хотя принципе, очереди распределения полосы и балансировки трафика можут быть сделаны на любом сетевом интерфейсе. В этом примере правила включают в себя cbq очередь для полной полосы пропускания 640 КБ с шестью sub очередями. Мы видим, что определенная по умолчанию очередь имеет 18 процентов полосы пропускания, в нее будет направляться весь трафик, не подходящий под остальные очереди. Ключевые слова borrow и red подразумевают, что очередь может'заимствовать' полосу пропускания от родительской очереди, в то время как система пытается избегнуть перегрузки, применяя алгоритм RED (Random Early Detection). Другие очереди следуют более или менее тому же образцу, за исключением подочереди ssh, которая имеет две подочереди с индивидуальными приоритетами.

Наконец, правила, в которых указывается, какой трафик назначен в очереди и их критерии: Мы можем предположить, что такое распределение удовлетворяет потребности сайта.

ALTQ - приоритезация трафика различных типов

Мы переходим к другому примеру, взятому из сети Дэниела Хартмеира. Подобно довольно многим из нас, Дэниел подключен по ADSL , и естественно он хотел бы использовать полосу пропускания более эффективно.

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

Анализ данных показал, что пакеты ACK для каждого пакета переданных данных вызвали непропорционально большое замедление, возможно из-за очереди FIFO (First In, First Out) в исходящем трафике. То есть, складывалась ситуация, когда запросы на новые пакеты проходили не самым оптималным способом.

Сформированная рабочая гипотеза состояла в том, что если бы между большими пакетами данных могли бы проходить маленькие пакеты ACK, то полоса пропускания использользовалась бы более эффективно. Для решения были созданы две очереди с разными приоритетами. Вот образцы правил: В результате работа канала действительно улучшилась. Статья Дэниела доступна на его домашней страничке http://www.benzedrine.cx/ackpri.html

ALTQ - обработка нежелательного трафика

Наш последний пример использования altq обусловлен событиями последнего времени - проблема спама и вирусных штормов. Практически все машины, зараженные вирусами и троянскими конями работают под управлением ОС Windows. PF имеет довольно точный механизм определения удаленной операционной системы и однажды, один из пользователей OpenBSD написал несколько правил для фильтрации лишнего трафика с зараженных машин: Эти правила написаны Randal L. Schwartz, 29. januar 2004, http://use.perl.org/~merlyn/journal/17094

В этом примере для почтового трафика выделена полоса пропускания в 1mb/sec, в то время, как почтовый трафик, отправленный с Windows машин ограничивается 56Kb/sec.

Я должен признать, что это достаточно смелый шаг, готорый я всегда хотел сделать, но не смел. Скоро мы рассмотрим другой подход, позволяющий достигнуть почти такого же эффекта.

CARP и pfsync

CARP и pfsync - это два новшештва, появившееся в OpenBSD 3.5. CARP - сокращение от Common Address Redundancy Protocol. Он был разработан как альтернатива VRRP (Virtual Router Redundancy Protocol, RFC 2281, RFC 3768), который был весьма близок к стандартизации IETF.

Оба протокола предназначены для создания избыточности сетевых соединений с возможностью автоматического восстановления.

CARP основан на установке группы машин, одна из которых является "главной" и одна или несколько "подчиненной". При падении главной машины одна из подчиненных берет ее IP адрес и, если была правильно настроена синхронизация, активные подключения.

Одна из основных целей CARP заключается в обеспечении функционирования работоспособности сети даже в случае отказа системы сетевой защиты или плановых остановок системы.

При использовании PF pfsync поможет вам разрешить проблему синхронизации машин группы. pfsync - это разработанный специально для обмена между пакетными фильтрами PF виртуальный интерфейс. Интерфейсы pfsync назначаются на физические интерфейсы с помощью команды ifconfig. В сетях, где требования к безотказной работе высоки, число одновременных подключений будет достаточно большим, поэтому будет иметь смысл выделение под pfsync отдельных сетевых интерфейсов.

Более подробно о CARP я расскажу в ближайшем будущем. Для получения дополнительной информации обратитесь к документации OpenBSD, руководствам man и домашней странице Рьяна Макбрайд http://www.countersiege.com/doc/pfsync-carp/

Тяжелое врямя для спамера

Рассмотрев некоторые основные моменты я рад представить вам нечто действительно полезное: PF, как средство сделать жизнь спамера несколько более тяжелой. Базируясь на недавно узнанном пишем правила: Мы имеем две таблицы, одна из них беред данне из некоторого файла. Трафик от серверов SMTP, находящихся в первой таблице и адреса из другой таблицы переадресовываются к демону, слушающего порт 8025.

Отправная точка, лежащая в основе дизайна spamd - тот факт, что спамеры посылают большое количество сообщений и вероятности, что Вы являетесь первым человеком, принявшим некое сообщение, является невероятно маленькой. Кроме того, спам главным образом посылают через некоторое количество дружественных к спамерам сетей и большое количество зараженных машин. Черные списки зараженных машин и сигнатур сообщений будут пополняться довольно быстро.

Конфигурируется spamd довольно просто. Вы просто редактируете /etc/spamd.conf согласно вашим собственным потребностям. Сам файл некоторым комментарием, на странице руководства man имеется дополнительная информация. Предложенное значение по умолчанию помещает в черный список весьма немного, включая корейские адреса. Я работаю в компании, которая работает с фирмами из Кореи, поэтому из моего файла конфигурации эти адреса удалены. Вы самостоятельно можете указывать, какие черные списки использовать и что для вас будет источником данных.

Поместите строки для старта spamd и укажите параметров запуска, которые Вы хотите, в вашем /etc/rc.conf или /etc/rc.conf.local. После этого, запустите spamd с указанными опциями и завершите конфигурацию, используя spamd-setup. Наконец, вы создаете cron задание, которое обновляет таблицы в разумных интервалах.

Как только таблицы заполнены, Вы можете управлять их содержанием, используя pfctl, точно так же как любые другие таблицы.

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

Как практически применяктся spamd? Мы начали использовать spamd в начале декабря 2004 года, после того, как уже некоторое время эксплуатировали spamassassin и clamav в связке с exim. Наш exim был настроен таким образом, что тегирование и доставка осуществляется при установленном spamassassin весе сообщения в интервале от 5 до 9.99 и отбрасывании при весе большем 10. Но в связи с ростом обьема спама, проходить его стало значительно больше.

При введении в строй spamd общее количество обрабатываемых spamassassin сообщений резко уменьшилось. Количество пропущенного спама сейчас составляет примерно пять сообщений в день.

Типичный лог выглядит так: В первой строке говорится, что машина соединяется, как четвертое активное подключение из четырех помещенных в черный список. Этот специфический адрес был помещен в черный список spamhaus. Следующие две строки показывают, что двум машинам, отказано в доставке после 1 минуты, 42 секунд и 6 минут, 43 секунд, соответственно. В предпоследней строке показано, как машины из черного списка все еще пытаются доставить почту.

По предварительному заключению, spamd блокирует некоторое количество спама. Но, к сожалению, есть и ложные срабатывания. Все они были связаны с использованием списка spews2 (spews level 2), в связи с чем его использование пришлось прекратить.

Теперь кульминационный момент моего опыта работы со spamd. Моя лучшая запись в логе выглядит так: Речь здесь идет об отправителе в wholesalebandwidth.com. Эта машина сделала 13 попыток доставки почты в период с 9-ого декабря до 12-ого декабря 2004. Последняя попытка продолжалась 32 минуты, 44 секунды.

Это меньше, чем 47 минут у Дэниела Хартмеира, но я доволен и этим результатом.

Подводя итог можно сказать, что использование черных списков совместно с spamd является мощным средством борьбы со спамом. Потребление ресурсов spamd - минимально. С другой стороны, надежность spamd равна надежности самого слабого элемента, что означает необходимость поддержания актуальности списков и контроль журнальных файлов.

Ссылки

OpenBSDs web http://www.openbsd.org/
OpenBSDs FAQ, http://www.openbsd.org/faq/index.html
PF User Guide http://www.openbsd.org/faq/pf/index.html
Daniel Hartmeier's PF pages, http://www.benzedrine.cx/pf.html
Daniel Hartmeier: Design and Performance of the OpenBSD Stateful Packet Filter (pf), http://www.benzedrine.cx/pf-paper.html (presented at Usenix 2002)
Nate Underwood: HOWTO: Transparent Packet Filtering with OpenBSD, http://ezine.daemonnews.org/200207/transpfobsd.html
Randal L. Schwartz: Monitoring Net Traffic with OpenBSD's Packet Filter, http://www.samag.com/documents/s=9053/sam0403j/0403j.htm
Unix.se: Brandvдgg med OpenBSD, http://unix.se/Brandv%E4gg_med_OpenBSD
Randal L. Schwartz: Blog for Thu, Jan 29, 2004, http://use.perl.org/~merlyn/journal/17094
RFC 1631, "The IP Network Address Translator (NAT)", May 1994 http://www.ietf.org/rfc/rfc1631.txt?number=1631
RFC 1918, "Address Allocation for Private Internets", February 1996 http://www.ietf.org/rfc/rfc1918.txt?number=1918

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1, wmd772 (?), 01:42, 05/12/2006 [ответить]  
  • +/
    Я конечно дико извиняюсь, но ваши описания не очень свежи. Конкретно:
    Ftp через NAT: ftp-proxy
    не в /inetd.conf 127.0.0.1:8021 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -n
    а в /etc/rc.conf.local ftp-proxy_flags=""
    содержание pf правил тоже не верно, для версии 3.9.
    Правильный вариант описан http://www.openbsd.org/faq/pf/ftp.html#client.
    Я не в кой мере не критикую, команда OpenBSD очень много всего и часто меняет. Просто обращаюсь к людям, которые могут воспользоваться вашей статьей:
    в статье используйте только схему
    проверяйте по man и http://www.openbsd.org/faq/index.html каждую строчку автора
    вы сможете таким образом найти многие отличия версий и избежать вопроса "А почему собственно не работает?"
    на ответ "Я не спикаю по инглишь."
    скажу "спикать придется и скажите спасибо, что первыми языки программирования начали делать англоязычные люди, а не японцы"
    добавлю, что бы меня за эти строчки не пинали в живот и лицо: я не спец по obsd, и это было мое IMHO.
    ЗЫ:
    в man страницах тоже есть некоторые недочеты, например pppoe(4) для версии 3.9 - пароль и логин должны быть заключены в "", это предостережение для тех кто все понимает буквально, как я :)
     
  • 2, MonoS (?), 16:39, 11/02/2007 [ответить]  
  • +/
    Товарищи, использующие, PF - отзовитесь - помогите разобраться с ALTQ Ну реальн... большой текст свёрнут, показать
     
  • 3, Константин (??), 22:51, 06/02/2010 [ответить]  
  • +/
    я не вижу у тя тут вообще шейпа никакого
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру