The OpenNET Project / Index page

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

IPF Howto (ipf howto bsd firewall ipfilter)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >> 
Ключевые слова: ipf, howto, bsd, firewall, ipfilter,  (найти похожие документы)

From: Михаил Сгибнев <mixa(@).dreamcatcher.ru>
Date: 2006-09-12 12:05:36
Subject: IPF Howto
Перевод: Сгибнев михаил

Оглавление:
  1. Введение
  2. Оговорка
  3. Авторское право
  4. Где получить
  5. Начальное использование систем фильтрации
  6. Файл конфигурации: порядок следования директив
  7. Основы обработки правил
  8. Управление обработкой правил
  9. Основы фильтрации по IP адресу
  10. Управление интерфейсами
  11. Совместное использование IP адреса и интерфейса
  12. Двунаправленная фильтрация. Ключевое слово "out"
  13. Регистрация событий. Ключевое слово "log"
  14. Полная двунаправленная фильтрация на интерфейсе
  15. Управление протоколами. Ключевое слово "proto"
  16. Фильтрация ICMP с помощью ключевого слова "icmp-type". Обьединение наборов правил.
  17. TCP и UDP порты; ключевое слово "port"
  18. Введение в расширенную фильтрацию
  19. Необузданная паранойя; или политика запрета по умолчанию
  20. Неявное разрешение. Правило "keep state"
  21. Stateful UDP
  22. Stateful ICMP
  23. Обнаружение FIN-сканирования. Ключевое слово "flags" и "keep frags"
  24. Ответ на блокированный пакет
  25. Представление о методах регистрации
  26. Объединение всего этого
  27. Увеличение производительности с помощью групп правил
  28. Ключевое слово "Fastroute"
  29. NAT и прокси
  30. Отображение нескольких IP адресов в один
  31. Отображение нескольких IP адресов в пул адресов
  32. Отображение один к одному
  33. Правила NAT
  34. Spoofing Services
  35. Поддержка прозрачных прокси. Польза перенаправления
  36. Фильтрация перенаправления
  37. Волшебство, скрытое в NAT. Прокси-серверы приложений
  38. Еще немного волшебства; использование NAT для балансировки нагрузки
  39. Загрузка и управление правилами фильтрации. Утилита ipf
  40. Загрузка и управление правилами NAT. Утилита ipnat
  41. Мониторинг и отладка
  42. Утилита ipfstat
  43. Утилита ipmon
  44. Keep State With Servers and Flags
  45. Копирование с FTP
  46. Работа FTP сервера
  47. Работа FTP клиента
  48. Различные переменные ядра
  49. Наслаждайтесь с ipf!
  50. Фильтрация на своей машине
  51. Какой фаерволл? Прозрачная фильтрация
  52. Использование прозрачной фильтрации для обнаружения ошибок проектирования сети
  53. Drop-Safe Logging с использованием методов dup-to и to.
  54. Метод dup-to
  55. Метод to
  56. Фильтрация поддельных сетей, вершина технологии anti-spoofing
Резюме: Этот документ предназначен для того, чтобы познакомить пользователя с пакетным фильтром IP Filter и дать некоторые основные принципы построения качественных систем сетевой защиты.

Введение

IP Filter - это маленький по размеру, но не по возможностям пакетный фильтр. Он делает почти все, что и другие свободно распространяемые системы сетевой защиты (ipfwadm, ipchains, ipfw), обладает дополнительными возможностями и хорошей переносимостью. Этот документ предназначен для того, чтобы придать некоторую связность разрозненным сведениям, имеющимся по ipfilter. В дальнейшем, этот документ будет также служить документацией для синтаксически совместимых пакетных фильтров (особенно pf), с указанием важных различий. Этот документ предназначен для описания синтаксиса и языка правил и не является платформозависимым. Было бы полезно, если читатель имел знакомство с пакетными фильтрами, однако, слишком большое знание может превратить чтение этого документа в обычную трату времени. Для большего понимания систем сетевой защиты, авторы рекомендуют Building Internet Firewalls, Chapman & Zwicky, O'Reilly and Associates; и TCP/IP Illustrated, Volume 1, Stevens, Addison-Wesley.

Оговорка

Авторы этого документа и переводчик не ответственны за любые убытки, которые были понесены вследствие предпринятых действий, основанных на прочтении этого документа. Этот документ предназначен как введение в формирование системы сетевой защиты, основанной на ipfilter. Если Вы не чувствуете себя готовым взвалить на себя такую ответственность, наймите профессионала, который сделает все за вас.

Авторское право

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

Все переводы, производные работы, или работы, включающие любые HOWTO должны быть охвачены этим объявлением об авторском праве. То есть Вы не можете сделать работу, основанную на HOWTO и наложить дополнительные ограничения на ее распространение. Исключения к этим правилам можно предоставить при некоторых условиях; пожалуйста войдите в контакт с координатором HOWTO.

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

Где получить

Официальная страница IPF: http://coombs.anu.edu.au/~avalon/ip-filter.html

Распространяемый по лицензии BSD пакетный фильтр pf: http://www.benzedrine.cx/pf.html

Наиболее современная версия этого документа может быть найдена здесь: http://www.obfuscation.org/ipf/

Начальное использование систем фильтрации

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

Файл конфигурации: порядок следования директив

IPF (IP Filter) имеет файл конфигурации. Он традиционен для Unix: одно правило в строке, знак # считается комментарием и символы справа от него до конца строки игнорируются, правило и комментарий могут находиться в одной строке, лишние пробелы и пустые строки игнорируются и поощряются для сохранения читабельности.

Основы обработки правил

Правила обрабатываются сверху вниз, каждое, одно за другим. Это весьма просто и означает что, если Ваш файл конфигурации состоит из строк: Они будут просмотрены в таком порядке: В этом случае к входящему пакету сперва применяется правило: И если IPF сочтет нужным перейти на следущую строку, применяется правило: В этом месте Вы возможножно зададите себе вопрос: "будет ли IPF переходить ко второму правилу?" Если Вы знакомы с ipfwadm или ipfw, то такой вопрос, скорее всего и не возникнет. Но вскоре Вы будете несказанно удивлены, обнаружив, что все пакеты, которые должны быть заблокированными, успешно проходят. Большинство пакетных фильтров прекращают сравнивать пакет с набором правил в момент первого соответствия. IPF - не один из них.

В отличие от других пакетных фильтров, IPF только устанавливает флаг, соответствующий действию над пакетом. Если проход правил не будет прерван, то будут пройдены все правила и основываясь на последнем соответствии будет принято решение о том, пропустить или отбросить пакет. Сцена: работающий IP filter, ресурсы CPU, буфер для контрольных точек, куда заносится: Пакет входит в интерфейс и работа закипела. Рассматривается пакет и берется первое правило: "Пока я думаю, что я блокирую этот пакет " говорит IPF. Рассматривается второе правило: "Пока я думаю, что я передам этот пакет " говорит IPF. Будем смотреть третье правило. А третьего правила нет, поэтому будем действовать в соответствии с последней инструкцией, следовательно, пакет будет пропущен. Самое время указать, что даже если бы набор правил был таким: То пакет по прежнему бы проходил. Нет никакого накопительного эффекта. Последнее правило всегда имеет приоритет.

Управление обработкой правил

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

Вот немного измененный набор правил: В этом случае IPF смотрит на первое правило: Сравнения пакета и правил закончены. Пакет немедленно блокирован. Нет никаких примечаний и никаких записей в файлах регистрации. Так что там со следующим правилом? Это правило не будет рассматриваться, с тем же успехом его могло вообще не быть в файле конфигурации. Наличие таких ключевых слов как all и quick позволит нам с уверенностью утверждать, что никакие другие нижеследующие правила рассматриваться не будут.

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

Основы фильтрации по IP адресу

IPF должен сравнивать пакеты по многим критериям. Наиболее часто вспоминаемым из них является IP адрес. Есть некоторые блоки адресного пространства, из которых мы никогда не должны получать трафик. Один такой блок - диапазон частных сетей 192.168.0.0/16 (/16 - CIDR представление сетевой маски, Вы можете быть знакомы с десятичным форматом 255.255.0.0. , таки IPF понимает оба). Если Вы хотите блокировать трафик из сети 192.168.0.0/16, есть способ сделать это: Теперь мы имеем не такой категоричный набор правил, но он выполняет уже какую-то полезную работу. Давайте представим, что к нам приходит пакет от 1.2.3.4. Применяем первое правило: Пакет - от 1.2.3.4, не 192.168.*. *, так что соответствия нет. Применяем второе правило: Пакет от 1.2.3.4 - определенно часть all, поэтому пакет невозбранно отправляется в пункт назначения.

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

Сейчас Вы можете сформировать довольно обширный список адресов, которые будут пропускаться или блокироваться. Так как мы уже установили блокировку одного диапазона частных сетей, то давайте позаботимся и об остальных: Первые три диапазона сетей принадлежат частному адресному пространству. См. rfc1918 http://www.faqs.org/rfcs/rfc1918.html и http://www.ietf.org/internet-drafts/draft-manning-dsua-06.txt.

Управление интерфейсами

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

Каждый пакет, который Вы получаете, приходит с сетевого интерфейса, каждый пакет, который Вы отправляете, уходит с сетевого интерфейса. Скажем, Ваша машина имеет 3 интерфейса: lo0 (loopback), xl0 (3com ethernet), и tun0 (туннель FreeBSD's для работы с PPP), но Вы не хотите получать пакеты, приходящие на tun0? В этом случае ключевое слово on будет означать входящие данные. Если пакет входит на tun0, первое правило блокирует его. Если пакет входит на lo0 или на xl0, первое правило не будет соответствовать, второе правило будет, пакет будет пропущен.

Совместное использование IP адреса и интерфейса

Весьма странное состояние дел, когда у нас есть интерфейс, но данные с него заблокированы. Чем больше критериев используется для построения системы сетевой защиты, тем она становится надежней (или дырявей). Возможно Вы хотите получать данные от tun0, но запретить сеть 192.168.0.0/16? Это - начало мощной системы сетевой защиты. Сравните это с нашим предыдущим правилом: В этом случае, весь трафик от 192.168.0.0/16 независимо от интерфейса был бы блокирован. В новом варианте предусматривается блокировка этой сети, только в том случае, если пакет пришел с интерфейса tun0 . Если бы пакет прибыл в интерфейс xl0 от 192.168.0.0/16, то он был бы пропущен.

Сейчас Вы можете сформировать довольно обширный список адресов, подлежащих блокировке или пропускаемых. Давайте озаботимся о блокировке частного диапазона сетей с интерфейса tun0: Вы уже видели первые три блока, но остальные нам еще не встречались. Четвертый - в значительной степени потраченная впустую сеть класса A, используемая для кольцевого интерфейса. Много программного обеспечения используют для работы 127.0.0.1, поэтому блокировка этого адреса из внешнего источника - хорошая идея. Пятый, 0.0.0.0/8, никогда не должен присутствовать в internet. Большинство стеков IP обрабатывает "0.0.0.0/32" как заданный по умолчанию шлюз, и остальная часть сетей 0.*.*.* обрабатывается так, как этого пожелали разработчики программного обеспечения. Вы должны обработать 0.0.0.0/8 точно так же как и 127.0.0.0/8. 169.254.0.0/16 был назначен IANA для использования при автоматической конфигурации, когда IP адрес не может быть получен через DHCP или ему подобный протокол. Microsoft Windows будет использовать адреса из этого диапазона, если включена опция получения IP адреса от DHCP сервера и этот сервер недоступен. 192.0.2.0/24 был также зарезервирован для использования в качестве примеров авторами технической документации. Мы намеренно не используем этот диапазон, поскольку это вызвало бы замешательство при использовании его в дальнейших примерах, поэтому мы будем использовать в качестве примера сеть 20.20.20.0/24. 204.152.64.0/23 - блок, зарезервированный Sun Microsystems для частных кластерных решений. Наконец, 224.0.0.0/3 охватывает "Класс D и E", используемые главным образом для группового трафика. хотя определение "Класса E" может быть найдено в rfc1166.

Довольно много программного обеспечения, производящего аутентификацию на базе IP адреса пакета. Если у Вас имеется внутренняя сеть 20.20.20.0/24, то Вы знаете, что трафик находится только в локальной сети и если пакет с таким адресом приходит с PPP, то вполне разумным будет отбросить этот пакет. Нельзя позволить ему пройти к пункту назначения. Вы можете легко достичь поставленной цели с текущими знаниями о IPF. Новый набо правиk будет выглядеть так:

Двунаправленная фильтрация. Ключевое слово "out"

До сего момента мы пропускали или блокировали приходящий трафик. Для ясности уточним - приходящий трафик - весь трафик, который входит в систему сетевой защиты с любого интерфейса. Исходящий трафик - весь трафик, который покидает машину с любого интерфейса (сгенерированный локально или транзитный). Мы можем предположить, что правило pass out all может пропускать и не желательный трафик. Точно также, как Вы можете пропускать или блокировать входящий на интерфейс трафик, Вы можете пропускать или блокировать исходящий трафик.

Вооруженные этим знанием, найдем ему применение. Одно из возможных применений - препятствовать spoofed пакетам выходить из вашей собственной сети. Вместо того, чтобы передавать любой трафик на маршрутизатор, ограничим разрешенный трафик пакетами, исходящими из сети 20.20.20.0/24. Сделать это можно примерно так (можно, конечно, использовать DIPFILTER_DEFAULT_BLOCK при компилировании ipfilter на вашей системе): Если пакет исходит из сети 20.20.20.1/32, то он будет пропущен в соответствии с первым правилом. Если пакет исходит с адреса 1.2.3.4/32, то он блокируется вторым правилом.

Также Вы можете применять подобные правила к немаршрутизируемым адресам. Если некоторая машина пробует переслать пакет через IPF с адресом назначения 192.168.0.0/16, почему мы должны его пропускать? Вы можете даже сэкономить полосу пропускания за счет отсутствия паразитного трафика. С одной стороны, эти правила не улучшают Вашу защиту, они улучшают защиту других сетей, но это хороший поступок, который стоит сделать. С другой стороны ваша сеть не сможет использоваться взломщиками для атаки на другую сеть и никто не сможет послать spoofed пакеты из Вашей сети.

Вы, вероятно, найдете много способов применить блокировку исходящих пакетов.

Регистрация событий. Ключевое слово "log"

До этого момента все блокированные и переданные пакеты были тихо блокированы и тихо переданы. Обычно Вы хотите знать, атакуют ли Вас, а не задаетесь вопросом, окупает ли себя система сетевой защиты. В то время как я не хотел бы регистрировать каждый переданный пакет, и в некоторых случаях каждый блокированный пакет, я буду хотеть знать о блокированных пакетах из сети 20.20.20.0/24. Чтобы сделать это, мы добавляем ключевое слово "log": Пока, наша система сетевой защиты довольно хороша при блокировании подозрительных пакетов, приходящих извне, но поле для работы еще есть. С одной стороны, мы принимаем пакеты, у которых в качастве адреса назначения указано что угодно. Единственное, в чем мы должны удостовериться, что блокируются пакеты с адресами назначения 20.20.20.0/32 и 20.20.20.255/32, иначе наша сеть становится доступна для smurf атаки. Эти две строки препятствовали бы нашей гипотетической сети быть используемой в качестве ретранслятора smurf. Теперь наш список правил выглядел бы следующим образом:

Полная двунаправленная фильтрация на интерфейсе

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

Начнем мы с интерфейса lo0. Так как множество программ на локальной машине работают с этим интерфейсом, то и правила будут соответствующими: Затем следует интерфейс xl0. Позже мы начнем помещать ограничения на интерфейс xl0, но пока мы будем действовать, как будто в нашей локальной сети мы доверяем всем и поэтому правила будут такие же, как и для lo0: Наконец, имеется интерфейс tun0. У нас имеется уже довольно существенное количество правил фильтрации, защита сети 20.20.20.0/24 от спуфинга или быть используемым для спуфинга. Будущие примеры также будут работать только с одним интерфейсом, что необходимо для краткости изложния, но при написанни Вашего собственного набора правил не забывайте добавлять правила для каждого направления и каждого интерфейса.

Управление протоколами. Ключевое слово "proto"

Атаки типа Denial of Service (Отказ в обслуживании) являются столь же распространенными, как и переполнение буфера. Множество таких атак полагаются на сбои в стеке TCP/IP операционной системы. Часто DoS атаки принимают форму ICMP пакетов. Почему бы не блокировать их полностью? Теперь любой ICMP трафик, приходящий на tun0 будет зарегистрирован и отброшен.

Фильтрация ICMP с помощью ключевого слова "icmp-type". Обьединение наборов правил.

Конечно, блокировать весь трафик ICMP - не самый лучший вариант. Почему? Да ведь если Вы хотите использовать утилиты ping и traceroute, Вы должны разрешить ICMP пакеты типов 0 и 11. Если Вы взвесили защиту и удобство, то IPF позволяет Вам сделать это: Помните, что порядок следования правил очень важен, особенно при использовании ключевого слова quick, поэтому разрешающие правила должны стоять перед запрещающими: Добавление этих 3 правил к anti-spoofing правилам имеет один тонкий момент. Одна ошибка могла бы состоять в том, чтобы поместить новые правила ICMP вначале: Проблема с этим состоит в том, что ICMP пакеты типа 0 от сети 192.168.0.0/16 обойдут первое правило и никогда не будут блокироваться четвертым правилом. Таким же образом, так как мы передаем ICMP ECHO_REPLY (тип 0) к сети 20.20.20.0/24 используя quick, то мы только что открыли лазейку для проведения smurf атак. Ой. Чтобы избежать этого, мы разместим правила ICMP после правил anti-spoofing: Поскольку мы блокируем spoofed трафик прежде, чем будут обработаны правила ICMP, spoofed пакет никогда не до них не дойдет. Очень важно сохранить такие ситуации в памяти при объединении правил.

TCP и UDP порты; ключевое слово "port"

Теперь, когда мы запустили блокировку пакетов, основанные на типе протокола, мы можем запустить блокировку пакетов, основанную на определенных аспектах каждого протокола. Наиболее часто используемый из этих аспектов - номер порта. Иметь такие сервисы, как rsh, rlogin, и telnet довольно удобно, но они довольно уязвимы для спуфинга и снифинга. Единственным приемлемым будет блокировка этих портов для доступа извне и разрешение доступа к этим портам изнутри. Это просто сделать, потому что rlogin, rsh, и telnet используют определенные порты TCP (513, 514, и 23 соответственно). Правила, блокирующие данные порты, довольно просты: Удостоверьтесь, что все три правила находятся перед правилом pass in all и закрывают доступ снаружи (для краткости пропустим спуфинг). Возможно Вы захотите блокировать такие порты, как 514/udp (syslog), 111/tcp & 111/udp (portmap), 515/tcp (lpd), 2049/tcp and 2049/udp (NFS), 6000/tcp (X11) и т.д. и т.п. Вы можете просмотреть список открытых портов, используя утилиту используя netstat -a (или, если установлена, lsof -i).

Блокирование UDP вместо TCP только требует замены proto tcp на proto udp. Правило для syslog выглядит так: IPF имеет также сокращенную запись при одновременном блокировании proto tcp и proto udp, таком, как NFS или portmap. Правило для portmap будет выглядеть так:

Введение в расширенную фильтрацию

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

Необузданная паранойя; или политика запрета по умолчанию

Есть большая проблема с блокированием сервисов по номерам портов: иногда номера портов изменяются. Программы базирующиеся на RPC - ужасны, lockd, statd и даже nfsd могут слушать порты, отличные от 2049. Довольно тяжело проводить все время корректировку правил. А что если вы пропустите какую-либо службу? Итак, давайте начнем с чистого листа. Наш набор правил теперь будет выглядеть так: Трафик не проходит. Никакой. Никуда. Гарантия абсолютной безопасности. Не очень полезно, но очень безопасно. Самая примечательная вещь состоит в том, что не потребуется слишком много усилий, для того чтобы сделать этот набор правил приносящим пользу. Пусть, на этой машине запущен web-сервер и ничего более, мы даже не используем DNS. Как следствие, мы хотим принимать соединения к 80/tcp. Мы разрешим это вторым правилом и Вы уже знаете как: Теперь этот маршрутизатор передаст на порт 80 трафик для 20.20.20.1, и будет блокировать все остальное, включая ответы от порта 80 нашего web-сервера. Необходимо разрешить ответы: Для основного использования систем защиты сетей сделано все необходимое. Однако, есть более простой путь; мы будем использовать stateful правила.

Неявное разрешение. Правило "keep state"

Задачей любой системы сетевой защиты является предотвращение лишнего трафика из точки В точку А. Мы в настоящее время имеем правила, говорящие:т "если пакет идет к порту 23, то все хорошо" и "если у пакета установлен флаг FIN, то все хорошо". Наша система сетевой защиты ничего не знает о начале, середине, или конце любого TCP/UDP/ICMP сеанса. Просто у нас имеются неопределенные правила, которые являются применимыми ко всем пакетами. Ним остается только надеяться, что пакет с установленным флагом FIN не является FIN-сканированием, выясняющем имеющиеся у нас сервисы. Мы надеемся, что пакет, направленный к 23 порту - не атака на наш telnet-сервис. Возможное решение данной проблемы состоит в том, чтобы идентифицировать и пропускать пакеты индивидуальных TCP/UDP/ICMP сеансов и отличать их от сканирования портов и DoS атак. Это называется keeping state.

Мы хотим иметь одновременно и удобство и защиту. Этого хотят все, поэтому у Cisco есть критерий "established", для того, чтобы пропускать пакеты уже установленного tcp сеанса. Ipfw имеет опцию established. Ipfwadm имеет опции setup/established. все имеют эту особенность, но имя опции может вводить в заблуждение. Мы могли бы предположить, что данные пакетные фильтры действительно следят за установленными сессиями, но это не так. Они анализируют раздел флагов TCP пакета и не работают с UDP/ICMP, поскольку у этих пакетов таких флагов нет. Любой, кто может модифицировать флаги пакета, может обойти эту систему сетевой защиты.

В отличие от других систем сетевой защиты, IPF действительно способен следить за установленным соединением и работает с протоколами TCP, UDP и ICMP. Ключевое слово в наборе правил, служащее для реализации данной возможности называется keep state.

Вплоть до сего момента, мы считали, что пакет проверяется набором правил на входе и проверяется на выходе. Фактически же, входящий пакет проверяется сперва табицей состояний, и только тогда, может быть он будет проверен набором правил. Таблица состояний - это список TCP/UDP/ICMP сессий, установленных после прохода всего набора правил системы сетевой защиты. Думаете. что это дыра в защите? Держитесь крепче, это лучшее, что могло случиться с вашим фаерволлом!

Все TCP/IP сеансы имеют начало, середину, и конец (даже если все это в одном пакете). Не может быть конца без середины, и не может быть середины без начала. Это означает, что все, что Вы действительно должны фильтровать - начало TCP/UDP/ICMP сеанса. Если начало сеанса позволяется вашими правилами системы сетевой защиты, то следовательно будут пропущены пакеты середены и конца сеанса (это делается во избежание переполнения стека IP маршрутизатора). Keeping state позволяет игнорировать середину и конец сессии и сосредоточиться на блокировани/пропуске новых сеансов. Если блокирован пакет начала сеанса, то отбрасываются и все остальные. Вот пример, как можно получить доступ к ssh серверу: Первая вещь, на которую Вы можете обратить внимание, это то, что нет условия "pass out". Фактически, правилом на выход является только "block out". Несмотря на это, набор правил является законченным и полным, это связано с использованием ключевого слова keep state. Как только первый SYN пакет поступает в адрес ssh сервера, создается запись в таблице состояний и все остальные пакеты ssh сеанса проходят без вмешательства системы сетевой защиты. Вот другой пример: В этом случае на сервере не запущены никакие сервисы. И вообще, это - не сервер, это - клиент. И этот клиент не хочет иметь непрошенных пакетов вообще на своих интерфейсах никогда ни за что! Однако, клиент хочет иметь полный доступ к internet и получать ответные пакеты, что вполне объяснимо. Этот простой набор правил создает записи в таблице состояний для каждой новой исходящей TCP сессии. Как только такая запись будет создана, паеты, принадлежащие сеансу смогут ходить, не подвергаясь проверке набором правил системы сетевой защиты. Как мы упоминали ранее, это работает для UDP и ICMP: Мы сделали это! Теперь у нас есть сохранение состояний сеансов TCP, UDP, ICMP. Теперь мы можем делать исходящие соединения, как будто вообще нет никакой системы сетевой защиты и в то же время, ни один злоумышленник не может соединиться с нами. Это очень удобно, потому что нет никакой необходимости выяснять, какие порты у нас открыты и мы можем предоставить доступ только к тем портам, к которым мы хотим.

Сохранение состояний - довольно хитрая штука. Могут происходить странные и таинственные вещи. Рассмотрим следующий пример: На первый взгляд, все хорошо. Мы позволяем входящие сеансы на порт 23 и исходящие куда угодно. Естественно пакеты, идущие к порту 23 будут иметь ответные пакеты и набор правил установлен таким образом, что pass out будет делать записи в таблице состояний и все будет работать замечательно. Но есть одна маленькая мелочь.

Вся проблема состоит в том, 60 секунд запись будет удалена из таблицы состояния по таймауту в случае простоя (в отличии от положенных 5 дней). Это происходит потому, что Обработчик состояний никогда не видел оригинал SYN пакета, поступившего на порт 23, а видел только пакет SYN ACK. IPF очень хорош в отслеживании сеансов от начала до конца, но не с середины сеанса. Перепишите это правило следующим образом: Ключевое слово keep state в первом правиле сделает необходимую запись в таблице состояний и все будет работать как ожидалось. Просмотреть текущие записи в таблице состояний Вы можете командой ipfstat -s.

Stateful UDP

UDP является протоколом без установления соединения, поэтому реализовать контроль за состоянием довольно сложно. Тем не менее, ipf делает это более-менее хорошо. Когда машина А посылает UDP пакет машине B с исходным портом X, и портом назначения Y, ipf разрешит ответ от машины B на машину А с исходным портом Y и портом назначения X. Эта запись будет действовать 60 секунд.

Вот пример использования утилиты nslookup для определения IP адреса узла www.3com.com: Будет сгенерирован пакет DNS: Пакет от 20.20.20.1, порт 2111, предназначен для 198.41.0.5, порт 53. На 60 секунд создано правило. Если пакет возвращается с 198.41.0.5 порт 53 для 20.20.20.1 порт 2111 в пределах этого периода времени, пакет будет пропущен. Чуть позже Вы можете увидеть: Ответный пает соответствует записи в таблице состояний и будет пропущен. После получения этого пакета запись будет удалена из таблицы и никакие другие паеты пропущены не будут, даже если у них будет прежний источник.

Stateful ICMP

IPFilter обрабатывает состояния ICMP таким же способом, как TCP и UDP, используя keep state. Есть два общих типа ICMP сообщений; запросы и ответы. Когда Вы записываете правило типа: для разрешения исходящих echo-запросов (ктилита ping), то резкльтатом будет icmp пакет типа 0, которому будет разрешено пройти. Для такой записи в теблице состояний таймаут установлен в 60 секунд. Таким образом Вы сохраняете состояние сеанса на любом исходящем icmp пакете с помощью правила типа proto icmp [...] keep state.

Однако, большинство ICMP сообщений - сообщения об ошибке, связанные с работой UDP (и иногда TCP), и в версиях IPFilter начиная с 3.4.x все ICMP сообщения об ошибках (такие как icmp-type 3 - порт недоступен, или icmp-type 11 - превышено время ожидания), пропускаются, в том случае, если IPF может найти запись в таблице состояния о сессии, которая могла повлечь появление такого сообщения. Например, в старых версиях IPFilter для работы traceroute Вам необходимо было использовать конструкцию: А сейчас сделать это можно используя только таблицу состояния UDP: Для обеспечения защиты Вашей сети от посторонних ICMP сообщений, проверяется также не только адреса источника и назначения (и порты, когда это возможно), но и его содержимое.

Обнаружение FIN-сканирования. Ключевое слово "flags" и "keep frags"

Давайте вернемся к четырем правилам из предыдущего раздела: Эти правила не совсем хороши тем, что могут позволить пройти на 23 порт не только пакетам SYN, но и любым старым пакетам. Изменить эту ситуацию мы можем следующим способом: Теперь пропущен будет только пакет TCP на 23 порт IP адреса 20.20.20.1/32 с установленным флагом SYN и по нему откроется запись в таблице состояний. Флаг SYN в пакете (при отсутствии других флагов) однозначно показывает нам начало сессии, и это то самое, к чему мы так стремились. Есть как минимум два преимущества: ни один пакет больше не привнесет беспорядок в таблицу состояний и ничто лишнее не сможет пройти. Также, будет терпеть неудачу FIN и XMAS сканирование, так как устанавливают в паете и другие флаги кроме SYN. Для примера, кроме флага S можно использовать флаги: S/SA - пакеты у которых наличествует один или несколько флагов URG, PSH, FIN или RST, S/AUPRFS соответствует только установленному SYN из шести возможных и т.д. Вам решать, какие флаги использовать при составлении правил. Для фрагментированных пакетов у IPF имеется ключевое слово keep frags. При установке этого ключевого слова IPF выявит и будет следить за фрагментированными пакетами, пропуская фрагменты. Итак, давайте перепишем правила так, чтобы регистрировать поддельные пакеты и пропускать фрагменты. Это работает, потому что для каждого пакета, который необходимо пропустить имеется запись в таблице сосояний. Единственный тип сканирования, котрый будет возможен - это непосредственно SYN сканирование. Если это Вас действительно беспокоит, то включите и регистрацию SYN пакетов.

Ответ на блокированный пакет

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

Когда на Unix-системе на запрашиваемом порту не запущена служба, то это дается понять пославшему запрос, возвращая пакет определенного типа. В TCP это делается с помощью пакета RST. При блокировании TCP пакета, IPF может позвратить отправителю пакет RST, используя ключевое слово return-rst. И поэтому вместо: Мы можем теперь записать: Мы нуждаемся в двух правилах block, так как return-rst работает только с TCP, а нам необходимо блокировать еще UDP, ICMP и все остальное. После того, как это сделано, удаленная стороно получит "connection refused" вместо "connection timed out". Также возможно послать сообщение об ошибке в случае получения UDP пакета. В случае правила: мы можем переписать его таким образом, используя ключевое слово return-icmp: Согласно TCP/IP Illustrated, корректным ICMP ответом в случае отсутствии сервиса на запрашиваемом порту будет port-unreachable. Вы можете возвращать любой тип ICMP пакета, но port-unreachable будет, наверное, лучшим выбором. Он используется по умолчанию для return-icmp.

Однако, Вы можете обратить внимание, что адресом источника пакета port-unreachable будет Ваша система сетевой защиты, а не первоначальный адресат пакета. Это было исправлено в версиях ipfilter начиная с 3.3 введением нового ключевого слова return-icmp-as-dest. Новый формат: В дополнение хотелось бы сказать: используйте данную функцию, когда Вы разбираетесь в ситуации. Для примера, если бы вы послали return-icmp на широковещательный адрес, то дело окончится флудом и сеть быстро потеряет работоспособность. Особенно это критично, если в сети действуют DHCP/BOOTP сервера.

Представление о методах регистрации

Важно обратить внимание, что присутствие ключевого слова log только гарантирует, что пакет будет доступен на устройстве регистрации ipfilter /dev/ipl. Чтобы фактически видеть эту информацию, необходимо использовать утилиту ipmon (или любую другую, читающую из /dev/ipl). Типичное использование log - совместно с ipmon -s, с дальнейшей регистрацией в syslog. Начиная с версии ipfilter 3.3 возможно управление syslog с использованием ключевых слов log level: Вы можете казать, какая информация будет регистрироваться, например Вам не интересно, кто ломился на telnet порт 500 раз подрят, а Вам интересно, кто пробовал сделать это один раз. Вы можете использовать ключевое слово log first для регистрации первого пакета.

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

Объединение всего этого

Теперь у нас есть довольно сильная система сетевой защиты, но можно сделать ее еще крепче. Удаленная нами часть правил anti-spoofing все же весьма полезна. Вернем ее:

Увеличение производительности с помощью групп правил

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

xl0 подсоединен к внешней сети 20.20.20.0/26
xl1 подсоединен к "DMZ" 20.20.20.64/26
xl2 подсоединен к нашей локальной сети 20.20.20.128/25

Мы опишем набор правил полностью за один раз, так как считаем, что Вы уже способны их прочесть самостоятельно: Даже в этом примере видно, что набор правил становится неуправляемым и тяжелым для восприятия. У нас добавились дополнительные правиля лоя ДМЗ, мы добавили дополнительные правила проверки пакетов, проходящих между xl0 и xl2. Если добавить эти правила как они есть и у Вас слабый процессор на мощном канале, то каждый, из находящихся в сети xl2 людей, будет Вами недоволен. Для ускорения работы можно использовать группы правил. Группы правил позволяют создавать список не линейного, а древовидного вида. Используя этот метод можно получить результат, когда пакет, не имеющий отношения, допустим, к интерфейсу xl1, никогда не будет проверяться этими правилами. Вот небольшой пример для начала: В этом упрощенном примере мы можем увидеть всю мощ группировки правил: если пакет не предназначен для xl1, то head в правиле group 10 не будет соответствовать и поэтому проверка правил будет продолжена. Если пакет действительно предназначен для xl1, то ключевое слово quick позволит нам перейти к проверке правил группы 10, а именно проверке SYN для 80/tcp. Перепишем наши правила соответствующим образом: Теперь Вы можете увидеть группы правил в действии: для пакетов к компьютерам, находящихся в сети xl2 мы можем не применять правила из group 10.

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

Ключевое слово "Fastroute"

Мы пропускаем одни пакеты, отфильтровываем другие, в общем, ведем себя как самый обычный маршрутизатор. Соответственно изменяя TTL пакета. Но мы можем скрыть наше присутствие от приложений подобных unix traceroute, которые использует UDP пакеты с разным TTL для определения расстояния до хостов. Если мы хотим, чтобы утилита traceroute работала, но не хотим чтобы TTL паета было изменено нашей системой сетевой защиты, то можно использовать следующую команду: Присутствие ключевого слова fastroute укажет ipfilter не передавать пакет в Unix IP стек, что позволит не изменять TTL пакета. Пакет будет сразу передан на интерфейс. Ipfilter будет использовать таблицу маршрутизации системы, но для выяснения нужного интерфейса воспользуется собственным механизмом маршрутизации.

Мы использовали block quick по определенным причинам: в случае использования просто pass и включенном IP Forwarding мы могли бы получить два маршрута и результатом был бы kernel panic.

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

NAT и прокси

Вне корпоративной среды наиболее симпатичным применением системы сетевой защиты является подключение нескольких компьютеров через один общий интерфейс. Часто это случается даже без согласия провайдера. Для знакомых с Linux этот процесс называется IP Masquerading, но остальная мировая общественность использует понятие Network Address Translation или NAT. Если быть точным, то IPFilter обеспечивает то, что называют NPAT (Network and Port Address Translation). Это значит, что мы можем произвольно изменять и адреса и поры, NAT позволяет работать только с адресами.

Отображение нескольких IP адресов в один

Основное использование NAT (или Linux's IP Masquerading) достигается одной строкой: Очень просто. Всякий раз, когда с интерфейса tun0 пытается уйти пакет с IP адресом источника из диапазона 192.168.1.0/24, то он он будет переписан таким образом, что источником пакета станет адрес 20.20.20.1/32, после чего пакет уйдет получателю. Система также сохранит список таких изменений для последующего обратного преобразования (в данном примере рассматривается типичная частная сеть 192.168.1.0/24 без возможности маршрутизации в Inernet. Пакеты от этой сети должны фильтроваться от внешнего мира, как это мы рассматривали выше).

У только что написанного нами правила есть один недостаток. В достаточно большом количестве случаев мы можем не знать IP адрес, назначенный нам провайдером (особенно при использовании интерфейсов tun0 или ppp0). К счастью, NAT способен понимать адрес 0/32, которым мы заменяем неизвестный нам IP адрес интерфейса: Теперь мы можем спокойно загрузить наши правила ipnat и соединиться с внешним миром без необходимости редактирования правил. ПОсле повторного соединения необходимо выполнить команду ipf -y для обновления адреса.

Некоторые могут задаться вопросом, что происходит в это время с исходным портом? В текущем правиле порт источника останется неизменным. Могут быть случаи, когда такое поведение нежелательно, например имеется еще одна система сетевой защиты, или несколько машин пытаются использовать один порт, вызывая коллизии и пакет будет передан неоттранслированным. Здесь нам поможет ключевое слово portmap: Теперь наше правило производит транслирование, используя в качестве исходных портов (которые могут быть tcp, udp, или tcp/udp) диапазон с 20000 по 30000.

Дополнительно мы можем сделать нашу жизнь еще проще, используя ключевое слово auto, для того, чтобы ipnat самостоятельно определял диапазон портов, доступных для использования и размещал их пропорционально доступному адресному пространству: Имейте в виду, что portmap будет работать только для тех протоколов, которые Вы указали (tcp, udp, или tcp/udp) и не будет работать для других, таких как ICMP или IPSec ESP/AH. Для этого Вы должны иметь дополнительную инструкцию map, которая будет применима ко всем остальным протоколам.

Отображение нескольких IP адресов в пул адресов

Другой традиционный пример использования NAT - это отображение большого количества IP адресов в маленький статически выделенный диапазон. Этого довольно просто достичь зная ключевые слова map и portmap. Также, могут быть случаи, когда приложение требует, чтобы соединения происходили с постоянного IP адреса. Мы можем решить эту проблему, указывая NAT статически отображать сессии с машины в пул адресов с использованием ключевого слова map-block следующим образом: Как и с map, map-block имеет собственную версию portmap. Это достигается использованием ключевого слова auto: Ключевое слово ports используется, если Вы хотите определить определенный порт для каждого IP адреса.

Отображение один к одному

Иногда бывает полезным иметь за системой сетевой защиты машину, адрес которой будет один к одному заменен. Сделать это позволяет ключевое слово bimap. Bimap имеет дополнительные средства защиты для сохранения состояния соединения, тогда как ключевое слово map предназначено для того, чтобы оттранслировать пакет переписав адрес и исходный порт и продолжать спокойно жить. Результатом этого правила будет отображение адреса 192.168.1.1/32 в адрес 20.20.20.1/32.

Правила NAT

Часто возникает необходимость применять NAT только к некоторым сетям. Реализовать это можно следующим способом: В данном примере при обращении к сети 5.0.0.0/20 адреса сети 192.168.1.0/24 не будут проходить через NAT. Мы можем сделать нечто подобное:

Служба спуфинга

Служба спуфинга? Зачем это может быть нужно? Да масса просто примеров из жизни! Давайте представим, что у нас есть web-сервер с IP адресом 20.20.20.5, и в последнее время нас все больше стала беспокоить его защита. Мы более не желаем запускать сервис на 80 порту, так как это требует выполнения некоторых действий с правами поьзователя root. Но как мы сможем запустить на непривилигерованном 8000 порту "xz.com"? Как люди найдут наш сервер? Для решения этой проблемы мы можем использовать средства перенаправления NAT, перебрасывая все запросы для 20.20.20.5:80 на 20.20.20.5:8000. Будем использовать ключевое слово rdr: Здесь также мы можем указать тип протокола UDP/TCP (по умолчанию считается TCP). Например, если на нашей системе сетевой защиты у нас имеется honeypot, имитирующий троян Back Orifice для Windows, мы могли бы сделать так: Также мы можем изменить поведение rdr основаваясь на источнике и адресе назначения: Очень важное замечание: Вы не сможете легко использовать rdr как "reflector". Это правило не будет работать в ситуации, где .5 и .6 находятся в одной сети. Да. Есть способ сделать это. Но будет значительно проще распилить слона лобзиком на куски. Крутые перцы, которым это действительно надо, могут организовать нечто вроде прозрачного перенаправления в TIS plug-gw на 127.0.0.1. Функция rdr применима к пакетам, которые входят в систему сетевой защиты на указанный интерфейс. Когда приходит пакет, соответствующй правилу rdr, перезаписывается адрес назначения и помещается в ipf для фильтрации, в случае успешного прохождения правил фильтрации пакет передается в систему маршрутизации unix. В случае переотражения ("reflector") пакет остается на том же самом интерфейсе, что запутывает систему. "reflector" - не работает. Всегда помните, что пакет, подвергшийся rdr и исходный пакет должны быть с разных интерфейсов. (Включая и 127.0.0.1).

Поддержка прозрачных прокси. Польза перенаправления

Так как Вы устанавливаете систему сетевой защиты, Возможно Вы решите использовать прокси сервер, для перенаправления на него трафика с целью уменьшить количество правил фильтрации и в случае проблем с работой NAT. Это достигается использованием перенаправления: Эта инструкция указывает любому пакету, входящему на интерфейс xl0 из любого адреса (0.0.0.0/0) на ftp порт, перенаправляться на прокси-сервер, выполняющийся на системе с NAT на порту 21.

В этом специфическом примере FTP проксирования, могут возникать проблемы при использовании веб-раузеров или других систем с возможностью автоматической регистрации, которые не знают о требованиях связи с прокси-сервером. Имеется патчи для TIS Firewall Toolkit' sftp-gw, для совместимости с NAT и возможности определения, куда направить пакет. Очень много приложений способно работать в среде прозрачного проксирования. Например Squid.

Использование rdr и прозрачного проксирования, является очень полезным, когда Вам необходимо авторизовывать пользователей через прокси.

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

Довольно много пользователей захотят обьединить и фильтрацию и переадресацию с целью обеспечить связь с миром только известным хостам своей сети. Например, предоставим доступ к нашему web-серверу 20.20.20.5 (адрес которого на самом деле 192.168.0.5), другу с IP адресом 172.16.8.2. В ipnat.rules запишем: И в ipf.rules: На первый взгляд это может выглядеть немного странно, но стоит помнить, что сперва выполняется NAT, адрес и порт назначения пакета перезаписываются прежде, чем будут обработаны кодом фильтра.

Волшебство, скрытое в NAT. Прокси-серверы приложений

С тех пор, как в ipnat появилась возможность перезаписывать пакеты, он стал достаточно удобен для встраивания некоторых прокси-серверов для устранения некоторых проблем приложений и систем сетвой защиты. Яркий пример - FTP. Мы можем заставить нашу систему сетевой защиты обратить внимание на проходящие пакеты, для того, чтобы установить активную FTP сессию и открыть некоторые временные правила, похожие на keep state, для пересылки данных по протоколу FTP. Помните: всегда размещайте правила proxy rule перед любыми правилами portmap, иначе происходит изменение пакета до того, как прокси-сервер получает возможность обработать пакет.

Там также существуют прокси-серверы для "rcmd" (такие команды как rlogin и т.д.) и "raudio" для Real Audio PNM. Аналогично, оба из этих правил должны быть помещены перед любыми правилами portmap при использовании NAT.

Еще немного волшебства; использование NAT для балансировки нагрузки

Мы можем использовать ipnat для реализации некоторых функций дорогих систем балансировки нагрузки и перенаправлять пакеты на множественные адреса назначения. Это достигается использованием ключевого слова round-robin:

Загрузка и управление правилами фильтрации. Утилита ipf

Правила фильтрации загружаются с помощью утилиты ipf. Имя файла может быть любым, но исторически так повелось, что правила сохраняют в файл /etc/ipf.rules, /usr/local/etc/ipf.rules, or /etc/opt/ipf/ipf.rules.

IP Filter имеет два набора праил - active set и inactive set. По умолчанию, все операции выполняются на активном наборе. Управлять неактивным набором ВЫ можете с помощью опции -I ipf. Перелючать наборы можно используя опцию -s. Это может быть полезным при тестировании нового набора правил без исправления старого набора.

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

В заключение, самый простой способ загрузить набор правил ipf -Fa -f /etc/ipf.rules. Для более полной спавки по командам смотри справочное руководство man ipf(1).

Загрузка и управление правилами NAT. Утилита ipnat

Правила NAT загружаются с использованием утилиты ipnat. Имя файла может быть любым, но исторически так повелось, что правила сохраняют в файл /etc/ipnat.rules, /usr/local/etc/ipnat.rules, or /etc/opt/ipf/ipnat.rules.

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

Правила NAT и правила отображения могут быть проверены с помощью опции -l

Самый простой способ загрузить правила NAT ipnat -CF -f /etc/ipnat.rules.

Мониторинг и отладка

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

Утилита ipfstat

В самом простом случае ipfstat отображает отображает таблицу интересных данных о том, как работает Ваша система сетевой защиты, сколько пакетов передано и блокировано и т.д. и т.п. ipfstat также может показать Вам текущий список правил. Используйте флаги -i или -o для отображения правил in или out соответственно. Добавление опции -h позволит увидеть более подробную информацию с указанием "hit count" для каждого правила: Здесь мы можем увидеть, что существуют какие-то проблемы, так как слишком много блокированных пакетов, несмотря на наличие таких правил pass out. В это м примере придется разбираться с правилами... ipfstat не может сказать Вам, правильно или нет Вы написали набор правил, это придется выяснять Вам самостоятельно. Для отладки Вы можете использовать также опцию -n, которая пронумерует список. И в заключение полезной информации, выдаваемой утилитой ipfstat, является опция -s, дамп таблицы состояний: Здесь мы видим, что имеется одна запись для TCP сессии. Вывод может меняться от версии к версии, но основная информация сохранится. Мы видим, что имеется полностью установленное соединение, обозначенное номером 4/4. Другие соединения незавершены еще и будут зарегистрированы позже. Мы увидим, что TTL сессии равно 240 часов, что нелепо долго, но являестя значением по умолчанию для сессии TCP. Счетсик уменьшается каждую секудну, когда соединение не используется и снова выставляется в 864000 при использовании, что гарантирует сохранение сессии при работе. Мы можем также видеть, что мы передали 196 пакетов, примерно по 17 Кб каждый, также мы можем увидеть порты источника и назначения.

Утилита ipmon

ipfstat великолепно подходит для текущего отображения того, что происходит в системе сетевой защиты, но часто оказывается удобным иметь регистрационный файл для наблюдения за событиями. ipmon - этот инструмент. ipmon способен отслеживать файлы регистрации пакетов (правила с ключевым словом log) правил nat, основных правил или любой их комбинации. Эта утилита способна работать как приложение переднего плана или демон, регистрирующий события через syslog или файл. Если мы бы хотели наблюдать таблицу состояний в динамике, то ipmon -o S осуществило бы нашу мечту. Здесь мы видим dns запросы, использования утилиты ping и недолгую ssh сессию.

ipmon также способен показать зарегистрированные пакеты. Например, при использовании keep state, Вы будете часто сталкиваться с пакетами типа: Что это означает? Первое поле - это время регистрации. Второе поле тоже довольно очевидно и указывает на интерфейс. Третье поле @0:2 указывает на правило, при котором произошло событие. Помните ipfstat -in? Если Вы хотите узнать про это правило больше, то ищите правило 2 в группе 0. "b" говорит о том, что пакет был заблокирован. Пятые и шестые поля довольно очевидны. Седьмое и восьмое поле указывают на протокол пакета и размер пакета. "-A" указывает на флаг пакета (в данном случае это был ACK). Вследствии природы Internet, в сети возможны потери пакетов. Иногда может оказаться так, что вы получите две копии пакета и таблица состояний посчитает, что это открытие новой сессии. В конечном счете этот пакет столкнется с реальным правилом и могут возникнуть проблемы. Вы будете часто видеть, что последний пакет закрываемого сеанса уже зарегистрирован, потому что код keep state уже оборвал соединение до того, как пришло подтверждение о конце сеанса к вашей системе сетевой защиты. Не волнуйтесь, это нормально. Для технического представления механизма проверки IP Filter читайте Real Stateful TCP Packet Filtering in IP Filter, by Guido van Rooij. Она может быть найдена по адресу http://www.iae.nl/users/guido/papers/tcp_filtering.ps.gz. Другой пример: Это ICMP пакет router discovery.

Наконец, ipmon позволяет посмотреть в действии таблицу NAT.

Keep State With Servers and Flags

Keep State - хорошая вещь, но весьма просто делать ошибку в направлении, куда выполнять keep state. И вообще Вы хотите иметь ключевое слово keep state в первом правиле обрабатывающем соединение. Одна общая ошибка, которую совершают при комбинации флагов и отслеживании состояний это: Это, конечно, позволяит подключению быть созданным на сервер telnet с адресом 20.20.20.20 и ответные пакеты также будут ходить. Если Вы пробуете использовать это правило, Вы увидите, что это действительно работает - на мгновение. Так как мы фильтруем флажг SYN, для таблицы состояний соединение не будет установлено, а заданное по умолчанию время жизни неполного состояния - 60 секунд.

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

Копирование с FTP

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

В пределах протокола FTP есть два режима передачи файлов - активный и пассивный. Активное соединение - сервер соединяется с открытым портом на клиенте, чтобы отправить данные. Наоборот, пассивное соединение - то, где клиент подключается к серверу, чтобы получить данные.

Работа FTP сервера

При работе FTP-сервера настройка обработки активных подключений довольно проста. В тоже самое время, обработка пассивных подключений - большая проблема. Сначала мы рассмотрим активный метод передачи, после обратимся к пассивному. Вообще, активные FTP-сессии обрабатываются точно также, как и входящие HTTP или SMTP запросы, Вы открываете ftp порт и создаете правило keep state: Эти правила позволяют соединяться с Вашим FTP-сервером 20.20.20.20 в активном режиме.

Рассмотрим пассивный режим передачи. Одно то, что у web-браузеров это отновной метод работы, делает данный режим популярным. Проблема с пассивным режимом состоит в том, что для каждого пассивного подключения, сервер начинает слушать на новом порту (обычно более чем 1023). Это по существу походит на создание нового сервиса на сервере. Принимая во внимание то, что наша система сетевой защиты построена на политике запрета по умолчанию, мы понимаем, что новое соединение с этим неизвестным портом будет блокировано, таким образом пассивный режим передачи перестает работать. Но не впадайте в отчаяние! Надежда остается.

Первой мыслью было бы открыть все порты более чем 1023. На самом деле, это будет работать. Это несколько неудовлетворительно, поскольку, открывая порты, мы можем потенциально нажить себе проблему. В то время как диапазон 1-1023 четко расписан, в диапазоне больше 1023 работает множество программ, таких как nfsd и X.

Хорошие новости состоят в том, что для Вашего FTP-сервера можно указать диапазон портов, используемых для обслуживания пассивного режима. Это означает, что вместо того, чтобы открывать все порты более чем 1023, Вы можете распределить порты 15001-19999 как ftp порты открыть только этот диапазон на вашей системе сетевой защиты. В wu-ftpd это делается опцией passive ports в ftpaccess. Пожалуйста, читайте man на ftpaccess для получения более детальной информации для wu-ftpd. На стороне ipfilter необходимо выполнить следущее: Если это решение не удовлетворило Вас, Вы всегда можете добавить поддержку IPF в Ваш FTP-сервер, или поддержку FTP-сервера в IPF.

Работа FTP клиента

В то время как поддержка FTP-сервера в IPF все еще не совершенна, то клиенты поддерживаются довольно хорошо с версии 3.3.3. Как и серверами, есть два режима работы: пассивный и активный.

Самый простой тип клиентской передачи с точки зрения системы сетевой защиты - пассивная передача. Эти соединения будут обрабатываться теми правилами keep state, которые Вы используете для исходящих tcp соединений. Если Вы этого еще не сделали, рассмотрите такую запись: Активный режим работы немного неприятнее, но тоже вполне решим. Активные передачи заставляют сервер создать второе подключение с клиентом для того, чтобы передать данные уже через него. В случае наличия системы сетевой защиты обычно это становится проблемой. Чтобы решить эту проблему ipfilter включает ipnat прокси-сервер, который временно открывает дыру в системе сетевой защиты только для FTP-сервера. Даже если Вы не используете ipnat для NAT, использование прокси-сервера будет эффективным решением. Следующие правила - тот минимум, который необходимо добавить к правилам ipnat: Дополнительную информацию по внутренним прокси-серверам поищите в разделе выше. Вообще-то ftp-сервер - это дыра в защите. Читайте http://www.false.net/ipfilter/2001_11/0273.html.

Различные переменные ядра

Есть некоторые полезные переменные ядра, которые должны быть установлены для функционирования ipf или для улучшения эффективности системы сетевой защиты. Основной является IP Forwarding, без нее возможности ipf будут весьма скромны, поскольку стек IP не будет маршрутизировать пакеты. Дополнительно, FreeBSD имеет еще несколько интересных переменных sysctl.

Наслаждайтесь с ipf!

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

Фильтрация на своей машине

Давным давно, в далеком университете Wietse Venema писал tcp-wrapper, которыми пытался поднять уровень безопасности сетевых сервисов во всем мире. Это хорошо. Но недостаточно. Они защищали только известные сервисы, хотя сервисы могут быть запущены через inetd, скомпилированы с libwrap и соответствующими обработчиками прерываний, что сделает сервис незащищенным. Это открывает гигантскую дыру в Вашем компьютере. Для примера, мой лэптоп часто подключается к сети с сомнительных в плане безопасности мест. Поэтому мой набор правил выглядит следующим образом: Это работает уже довольно долгое время и я не имею никаких проблем с загрузкой CPU обработкой правил ipf. Конечно, можно еще сократить эти правила, используя NAT ftp proxy, можно добавить правила против спуфинга. Но даже с тем, что есть, мой компьютер значительно более защищен, чем любая другая среднестатистическая машина в локальной сети. Это хорошая вещь, когда на машине работает много пользователей и Вы хотите, чтобы они не запускали собственные сетевые сервисы. Конечно, хакер с правами root отредактирует правила ipf и так или иначе запустит службу, но честный человек будет убережен от соблазна. Использование правил фильтрации на своей машине в дополнение к системе сетевой защиты на маршрутизаторе может решить много проблем, даже такие политические кошмары как: "Почему у меня не работает ICQ!?", "Почему я не могу запустить web-сервер на своей рабочей станции??? ЭТО МОЯ РАБОЧАЯ СТАНЦИЯ!!!" и т.д.

Какой фаерволл? Прозрачная фильтрация

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

Многие сетевые администраторы знакомы с обычным ethernet мостом. Это - устройство, которое соединяет два сегмента Ethernet в один. Мосты обычно используются для соединения разных зданий, увеличения длины сети или изменения скорости. Хабы и свичи - общий вид моста, иногда встречаются двухпортовые репитеры. Последние версии Linux, OpenBSD, NetBSD, и FreeBSD включают код, чтобы преобразовать PC за 1000$ в мост за 10$! Общая тенденция работы мостов заключается в обьединении двух машин, при этом машины о существовании моста не подозревают. Рассмотрим ipfilter и OpenBSD.

В модели ISO мосты работают на Layer2. IP работает на Layer3. IP Filter прежде всего работает с Layer3, но может работать и с Layer2 на уровне интерфесйса. Смешивая IP filter с OpenBSD, мы можем получить систему сетевой защиты невидимую и недостижимую. Система не нуждается ни в каком IP адресе, становится даже ненужным mac адрес. Единственный признак наличия такой защиты - несколько увеличенное время прохождения пакета, чем в обычной сети cat5.

Установка такого набора правил на удивление проста. В OpenBSD первое устройство называется bridge0. Также мы имеем две Ethernet карты xl0 и xl1. Для превращения этой машины в мост требуется следущее: С этого момента весь трафик с xl0 будет пересылаться на xl1 и наоборот. Обратите внимание, что интерфейсам не были назначены IP адреса.

Наборы правил ведут себя по прежнему. Хоть у нас есть интерфейс bridge0, мы его трогать не будем, а используем специфический интерфейс, зависящий от сетевой карты и типа кабеля. Рассмотрим следующую сеть: То есть мы имеем маршрутизатор 20.20.20.1 связанный с сетью 20.20.20.0/24. Пакеты от сети 20.20.20.0/24 уходят на 20.20.20.1 дабы уйти во внешний мир и наоборот. Теперь мы добавляем мост Ipf: Также мы имеем следующий набор правил: С этими правилами сети функционально идентичны. Теперь изменим набор правил: Однако, 20.20.20.1 и 20.20.20.0/24 по прежнему думают, что сеть идентична и только в случае если с 20.20.20.1 выполнить команду ping к 20.20.20.2, ответ получен не будет. 20.20.20.2 даже не получит icmp пакета.

Блокирование icmp бессмысленно, особено, если Вы системный администратор и используете команды ping, traceroute или меняете MTU пакетов. Давайте возмем пример из жизни и используем главную особенность ipf - таблицу состояния: В этой ситуации сеть 20.20.20.0/24 (возможно, более точно ее можно назвать сетью xl1) может обращаться к внешнему миру, но внешний мир в эту сеть - не может и не пожет выяснить почему. Маршрутизатор доступен, хосты работают, но проникнуть в сеть невозможно. Даже если бы сам маршрутизатор был скомпрометирован, система сетевой защиты все еще активна и успешна.

Пока мы осуществляли фильтрацию только по интерфейсу и по протоколу. Даже при всем при том, что мы работаем на layer2, мы можем выделить IP адрес. Обычно мы имеем несколько запущеных служб, поэтому наши правила теперь выглядят так: Теперь мы имеем сеть, где 20.20.20.2 - DNS, 20.20.20.3 - mail-сервер, 20.20.20.7 - web-сервер.

Bridged IP Filter все еще не сделан.

Сперва отметим, что все наши правила используют направление in, а не комбинацию in и out. Это потому, что направление out теперь несовместимо с бриджингом в OpenBSD. Первоначально это было сделано с целью предотвратить падение производительности при использовании множественных интерфейсов. С тех пор так и идет. Если Вы хотите иметь эту возможность - ковыряйте код OpenBSD.

Во вторых, использование возможностей NAT теперь становится нецелесообразным, если не опасным. Первая проблема - мост был бы обнаружен. Вторая - у него нет IP адреса и посему неизвесно будет, как реализовать NAT, что может привести к kernel panic. Конечно, можно назначить IP адрес исходящему интерфейсу, но тогда зачем мы делали мост?

Использование прозрачной фильтрации для обнаружения ошибок проектирования сети

Многие организации начали использовать IP до того, как подумали, что система сетевой защиты или подсети будут хорошей идеей. Теперь они имеют сеть класса С или больше, где находятся их серверы, рабочие станции, другие роутеры, кофеварки. Ужас! Переименовывать сети, доверительные отношения, фильтры трудоемко и дорого. Расходов аппаратных средств и человекочасов требуется так много, что про проблему проще забыть, чем решить. Типичная проблемная сеть выглядит таким образом: Только это раз в 20 больше, разнородней и незадокументированней. В идеальном варианте все серверы находятся в одной сети, рабочие машины в другой и активное сетевое оборудование в третьей. Тогда маршрутизатор фильтровал бы пакеты между подсетями, давая рабочим станциям ограниченный доступ к серверам, никого не пуская к свичам и только машина администратора имела бы полный доступ ко всем устройствам. Я никогда не видел сети класса С разделенной таким образом. IP Filter нам поможет.

Для начала, мы разделим маршрутизатор, рабочие станции и сервер. Для того, чтобы сделать это, нам необходимо 2 концентратора (которые, скорее всего, уже есть), машина с IPF и 3 сетевые карты Ethernet. Мы поместим все сервера в один концентратор, а рабочие станции в другой. В обычной ситуации мы бы соединили концентраторы между собой, а затем в маршрутизатор. Но сейчас мы сделаем по другому: маршрутизатор подключаем в интерфейс xl0, серверы в xl1 и рабочие станции в xl2. Теперь наша сеть выглядит примерно так: Теперь у нас есть фильтрующий мост и ни на одной машине не были изменены настройки. Далее, мы пишем набор правил: Еще раз отметим - трафик, идущий с маршрутизатора, ограничен DNS, SMTP, HTTP. В настоящее время, серверы и рабочие станции могут обмениваться трафиком свободно. Возможно Вас это не устроит. Вы хотите вообще запретить доступ рабочим станциям к серверам? Тогда возьмите набор правил для xl2: И замените его на: Возможно, Вы захотите, чтобы пользователи могли только принимать/отправлять почту по протоколу IMAP? Теперь ваши рабочие станции и серверы защищены от внешнего мира, и серверы защищены от ваших рабочих станций.

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

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

Drop-Safe Logging с использованием методов dup-to и to.

До сих пор мы использовали фильтр для блокировки пакетов. Вместо блокировки давайте пересылать их другой системе, которая может сделать кое-что полезное с этой информацией без регистрации, которую мы можем исполнить с помощью ipmon. Наша машина с установленной на ней системой сетевой защиты может иметь столько интерфейсов, сколько в нее можно пихнуть, не важно, роутер это или фильтрующий мост. Мы можем использовать эту информацию для создания "drop-safe" для пакетов. Хорошим примером использования этого является сеть обнаружения вторжения. Было бы желательно скрыть присутствие наших систем обнаружения вторжения от нашей реальной сети.

Прежде чем начать, сделаем маленькое замечание. Если мы собираемся иметь дело только с блокированными пакетами, то мы можем использовать ключевые слова to или fastroute. Если мы хотим работать с пропускаемыми пакетами, то необходимо делать копию пакета для нашего журнала используя ключевое слово dup-to.

Метод dup-to

Если, например, мы хотели послать копию всего выходящего из интерфейса xl3 на нашу drop-safe сеть ed0, то мы бы использовали такое правило: Возможно, существует потребность послать пакеты на определенный IP адрес нашей сети, чтобы только делать копию пакета там и надеяться на лучшее. Но помните, что этот метод изменяет адрес назначения скопированного пакета, а потому достоверность файла регистрации может бытьнарушена. По этой причине мы рекомендуем использовать для регистрации только известный адрес (например, не используйте 192.168.254.2 для регистрации пакетов одновременно с web и smtp серверов, иначе разбирать что-куда будет проблематично).

Эта методика может использоваться весьма эффективно, если Вы обрабатываете IP адреса для Вашей drop-safe сети подобно тому, как обрабатывается Multicast Group в Internet (например: "192.168.254.2" канал для вашей системы анализа трафика http, " 23.23.23.23" канал для сеансов telnet, и так далее.) По идее, нам даже не нужно устанавливать адрес или псевдоним на нашей системе анализа. Обычно, наша ipfilter машина нуждалась бы в ARP для определения нового адреса назначения (конечно, используя стиль dup-to ed0:192.168.254.2), но мы можем избежать этого, используя статическую запись arp для этого "channel" (канала) на нашей ipfilter машине.

Вообще-то, dup-to ed0 - это все, что требуется для отправки пакета в нашу drop-safe сеть для регистрации и экспертизы.

Метод to

Метод dup-to действительно имеет некоторые недостатки. Так как необходимо сделать копию пакета и произвольно изменить его для его нового адресата, это требует времени, чтобы завершить всю работу и необходимо быть готовым иметь дело со следующим пакетом, входящим в ipfilter.

Если мы не заботимся о прохождении пакета его адресатом, и мы собирались блокировать его, то можно воспользоваться ключевым словом to, чтобы двинуть этот пакет пакет мимо нормальной таблицы маршрутизации и запихнуть на интерфейс, отличный от первоначального интерфейса назначения. Мы используем block quick для to, чтобы осуществить маршрутизацию между интерфейсами, так как подобно fastroute, to генерирует два пути пакета через ipfilter, когда используется pass, что может вызвать kernel panic.

Фильтрация поддельных сетей, вершина технологии anti-spoofing

Мы потратили много времени на поиск адресов, зарезервированных IANA по различным причинам и в настоящее время не используемым. Так как они в настоящее время не используются, нет никакой причины получать от них пакеты, верно?

Так без дальнейшей суматохи, законченный список поддельных сетей: Если Вы собираетесь использовать их, мы предполагаем, что Вы знакомымы с whois.arin.net и время от времени туда смотрите, поскольку IANA не собирается уведомлять Вас, когда они распределят одну из них новой корпорации или кому-то еще. Вы были предупреждены. 












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







 Добавить комментарий




















Имя:


E-Mail:


Заголовок:


Текст:




































Партнёры:




PostgresPro





Inferno Solutions




Hosting by Hoster.ru




Хостинг:















Закладки на сайте

Проследить за страницей


Created 1996-2024 by Maxim Chirkov

Добавить, Поддержать, Вебмастеру