IPF Howto — Dreamcatcher.ru

Перевод: Сгибнев Михаил

Оглавление:

IP Filter Based Firewalls HOWTO

Brendan Conoboy Erik Fichtner Wed Dec 11 12:42:58 EST 2002

Резюме:
Этот документ предназначен для того, чтобы познакомить пользователя с пакетнымфильтром 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: одно правило в строке, знак # считается комментарием и символы справа от него до конца строки игнорируются, правило и комментарий могут находиться в одной строке, лишние пробелы и пустые строки игнорируются и поощряются для сохранения читабельности.

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

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



block in all

pass in all

Они будут просмотрены в таком порядке:



block in all

pass in all

В этом случае к входящему пакету сперва применяется правило:



block in all

И если IPF сочтет нужным перейти на следущую строку, применяется правило:



pass in all

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

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



block in all

pass in all

Пакет входит в интерфейс и работа закипела.
Рассматривается пакет и берется первое правило:



block in all

«Пока я думаю, что я блокирую этот пакет » говорит IPF. Рассматривается второе правило:



pass in all

«Пока я думаю, что я передам этот пакет » говорит IPF. Будем смотреть третье правило. А третьего правила нет, поэтому будем действовать в соответствии с последней инструкцией, следовательно, пакет будет пропущен. Самое время указать, что даже если бы набор правил был таким:



block in all

block in all

block in all

block in all

pass in all

То пакет по прежнему бы проходил. Нет никакого накопительного эффекта. Последнее правило всегда имеет приоритет.

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

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

Вот немного измененный набор правил:



block in quick all

pass in all

В этом случае IPF смотрит на первое правило:



block in quick all

Сравнения пакета и правил закончены. Пакетнемедленно блокирован. Нет никаких примечаний и никаких записей в файлах регистрации. Так что там со следующим правилом?



pass in all

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

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

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

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



block in quick from 192.168.0.0/16 to any

pass in all

Теперь мы имеем не такой категоричный набор правил, но он выполняет уже какую-то полезную работу. Давайте представим, что к нам приходит пакет от 1.2.3.4. Применяем первое правило:



block in quick from 192.168.0.0/16 to any

Пакет — от 1.2.3.4, не 192.168.*. *, так что соответствия нет. Применяем второе правило:



pass in all

Пакет от 1.2.3.4 — определенно часть all, поэтому пакет невозбранно отправляется в пункт назначения.

С другой стороны, предположите, что мы имеем пакет, который входит от 192.168.1.2. Применяем первое правило:



block in quick from 192.168.0.0/16 to any

Есть соответствие, пакет отброшен, и это — конец. Первое правило применяться не будет, поскольку соответсвие произошло и имелось ключевое слово quick.

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



block in quick from 192.168.0.0/16 to any

block in quick from 172.16.0.0/12 to any

block in quick from 10.0.0.0/8 to any

pass in all

Первые три диапазона сетей принадлежат частному адресному пространству. См. rfc1918 http://www.faqs.org/rfcs/rfc1918.html и http://www.ietf.org/internet-drafts/draft-manning-dsua-06.txt.

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

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

[ad name=»Google Adsense»]

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

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

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



block in quick on tun0 from 192.168.0.0/16 to any

pass in all

Сравните это с нашим предыдущим правилом:



Compare this to our previous rule:

block in quick from 192.168.0.0/16 to any

pass in all

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



block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

pass in all

Вы уже видели первые три блока, но остальные нам еще не встречались. Четвертый — в значительной степени потраченная впустую сеть класса 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. Новый набо правил будет выглядеть так:



block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

block in quick on tun0 from 20.20.20.0/24 to any

pass in all

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

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

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



pass out quick on tun0 from 20.20.20.0/24 to any

block out quick on tun0 from any to any

Если пакет исходит из сети 20.20.20.1/32, то он будет пропущен в соответствии с первым правилом. Если пакет исходит с адреса 1.2.3.4/32, то он блокируется вторым правилом.

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



block out quick on tun0 from any to 192.168.0.0/16

block out quick on tun0 from any to 172.16.0.0/12

block out quick on tun0 from any to 10.0.0.0/8

block out quick on tun0 from any to 0.0.0.0/8

block out quick on tun0 from any to 127.0.0.0/8

block out quick on tun0 from any to 169.254.0.0/16

block out quick on tun0 from any to 192.0.2.0/24

block out quick on tun0 from any to 204.152.64.0/23

block out quick on tun0 from any to 224.0.0.0/3

block out quick on tun0 from !20.20.20.0/24 to any

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

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

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

До этого момента все блокированные и переданные пакеты были тихо блокированы и тихо переданы. Обычно Вы хотите знать, атакуют ли Вас, а не задаетесь вопросом, окупает ли себя система сетевой защиты. В то время как я не хотел бы регистрировать каждый переданный пакет, и в некоторых случаях каждый блокированный пакет, я буду хотеть знать о блокированных пакетах из сети 20.20.20.0/24. Чтобы сделать это, мы добавляем ключевое слово «log»:



block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

block in log quick on tun0 from 20.20.20.0/24 to any

pass in all

Пока, наша система сетевой защиты довольно хороша при блокировании подозрительных пакетов, приходящих извне, но поле для работы еще есть. С одной стороны, мы принимаем пакеты, у которых в качастве адреса назначения указано что угодно. Единственное, в чем мы должны удостовериться, что блокируются пакеты с адресами назначения 20.20.20.0/32 и 20.20.20.255/32, иначе наша сеть становится доступна для smurf атаки. Эти две строки препятствовали бы нашей гипотетической сети быть используемой в качестве ретранслятора smurf.



block in log quick on tun0 from any to 20.20.20.0/32

block in log quick on tun0 from any to 20.20.20.255/32

Теперь наш список правил выглядел бы следующим образом:



block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

block in log quick on tun0 from 20.20.20.0/24 to any

block in log quick on tun0 from any to 20.20.20.0/32

block in log quick on tun0 from any to 20.20.20.255/32

pass in all

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

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

Начнем мы с интерфейса lo0. Так как множество программ на локальной машине работают с этим интерфейсом, то и правила будут соответствующими:



pass out quick on lo0

pass in quick on lo0

Затем следует интерфейс xl0. Позже мы начнем помещать ограничения на интерфейс xl0, но пока мы будем действовать, как будто в нашей локальной сети мы доверяем всем и поэтому правила будут такие же, как и для lo0:



pass out quick on xl0

pass in quick on xl0

Наконец, имеется интерфейс tun0.



block out quick on tun0 from any to 192.168.0.0/16

block out quick on tun0 from any to 172.16.0.0/12

block out quick on tun0 from any to 127.0.0.0/8

block out quick on tun0 from any to 10.0.0.0/8

block out quick on tun0 from any to 0.0.0.0/8

block out quick on tun0 from any to 169.254.0.0/16

block out quick on tun0 from any to 192.0.2.0/24

block out quick on tun0 from any to 204.152.64.0/23

block out quick on tun0 from any to 224.0.0.0/3

pass out quick on tun0 from 20.20.20.0/24 to any

block out quick on tun0 from any to any

block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

block in log quick on tun0 from 20.20.20.0/24 to any

block in log quick on tun0 from any to 20.20.20.0/32

block in log quick on tun0 from any to 20.20.20.255/32

pass in all

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

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

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



block in log quick on tun0 proto icmp from any to any

Теперь любой ICMP трафик, приходящий на tun0 будет зарегистрирован и отброшен.

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

Конечно, блокировать весь трафик ICMP — не самый лучший вариант. Почему? Да ведь если Вы хотите использовать утилиты ping и traceroute, Вы должны разрешить ICMP пакеты типов 0 и 11. Если Вы взвесили защиту и удобство, то IPF позволяет Вам сделать это:



pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0

pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11

Помните, что порядок следования правил очень важен, особенно при использовании ключевого слова quick, поэтому разрешающие правила должны стоять перед запрещающими:



pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0

pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11

block in log quick on tun0 proto icmp from any to any

Добавление этих 3 правил к anti-spoofing правилам имеет один тонкий момент. Одна ошибка могла бы состоять в том, чтобы поместить новые правила ICMP вначале:



pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0

pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11

block in log quick on tun0 proto icmp from any to any

block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

block in log quick on tun0 from 20.20.20.0/24 to any

block in log quick on tun0 from any to 20.20.20.0/32

block in log quick on tun0 from any to 20.20.20.255/32

pass in all

Проблема с этим состоит в том, что ICMP пакеты типа 0 от сети 192.168.0.0/16 обойдут первое правило и никогда не будут блокироваться четвертым правилом. Таким же образом, так как мы передаем ICMP ECHO_REPLY (тип 0) к сети 20.20.20.0/24 используя quick, то мы только что открыли лазейку для проведения smurf атак. Ой. Чтобы избежать этого, мы разместим правила ICMP после правил anti-spoofing:



block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

block in log quick on tun0 from 20.20.20.0/24 to any

block in log quick on tun0 from any to 20.20.20.0/32

block in log quick on tun0 from any to 20.20.20.255/32

pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0

pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11

block in log quick on tun0 proto icmp from any to any

pass in all

Поскольку мы блокируем spoofed трафик прежде, чем будут обработаны правила ICMP, spoofed пакет никогда не до них не дойдет. Очень важно сохранить такие ситуации в памяти при объединении правил.

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

Теперь, когда мы запустили блокировку пакетов, основанные на типе протокола, мы можем запустить блокировку пакетов, основанную на определенных аспектах каждого протокола. Наиболее часто используемый из этих аспектов — номер порта. Иметь такие сервисы, как rsh, rlogin, и telnet довольно удобно, но они довольно уязвимы для спуфинга и снифинга. Единственным приемлемым будет блокировка этих портов для доступа извне и разрешение доступа к этим портам изнутри. Это просто сделать, потому что rlogin, rsh, и telnet используют определенные порты TCP (513, 514, и 23 соответственно). Правила, блокирующие данные порты, довольно просты:



block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 513

block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 514

block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 23

Удостоверьтесь, что все три правила находятся перед правилом pass in all и закрывают доступ снаружи (для краткости пропустим спуфинг).



pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 0

pass in quick on tun0 proto icmp from any to 20.20.20.0/24 icmp-type 11

block in log quick on tun0 proto icmp from any to any

block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 513

block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 514

block in log quick on tun0 proto tcp from any to 20.20.20.0/24 port = 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 выглядит так:



block in log quick on tun0 proto udp from any to 20.20.20.0/24 port = 514

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



block in log quick on tun0 proto tcp/udp from any to 20.20.20.0/24 port = 111

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

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

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

Есть большая проблема с блокированием сервисов по номерам портов: иногда номера портов изменяются. Программы базирующиеся на RPC — ужасны, lockd, statd и даже nfsd могут слушать порты, отличные от 2049. Довольно тяжело проводить все время корректировку правил. А что если вы пропустите какую-либо службу? Итак, давайте начнем с чистого листа. Наш набор правил теперь будет выглядеть так:



block in all

Трафик не проходит. Никакой. Никуда. Гарантия абсолютной безопасности. Не очень полезно, но очень безопасно. Самая примечательная вещь состоит в том, что не потребуется слишком много усилий, для того чтобы сделать этот набор правил приносящим пользу. Пусть, на этой машине запущен web-сервер и ничего более, мы даже не используем DNS. Как следствие, мы хотим принимать соединения к 80/tcp. Мы разрешим это вторым правилом и Вы уже знаете как:



block in on tun0 all

pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 80

Теперь этот маршрутизатор передаст на порт 80 трафик для 20.20.20.1, и будет блокировать все остальное, включая ответы от порта 80 нашего web-сервера. Необходимо разрешить ответы:



block in on tun0 all

pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 80

pass out quick on tun0 proto tcp from 20.20.20.1/32 port = 80 to any

Для основного использования систем защиты сетей сделано все необходимое. Однако, есть более простой путь; мы будем использовать 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 серверу:



block out quick on tun0 all

pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 22 keep state

Первая вещь, на которую Вы можете обратить внимание, это то, что нет условия «pass out». Фактически, правилом на выход является только «block out». Несмотря на это, набор правил является законченным и полным, это связано с использованием ключевого слова keep state. Как только первый SYN пакет поступает в адрес ssh сервера, создается запись в таблице состояний и все остальные пакеты ssh сеанса проходят без вмешательства системы сетевой защиты. Вот другой пример:



block in quick on tun0 all

pass out quick on tun0 proto tcp from 20.20.20.1/32 to any keep state

В этом случае на сервере не запущены никакие сервисы. И вообще, это — не сервер, это — клиент. И этот клиент не хочет иметь непрошенных пакетов вообще на своих интерфейсах никогда ни за что! Однако, клиент хочет иметь полный доступ к internet и получать ответные пакеты, что вполне объяснимо. Этот простой набор правил создает записи в таблице состояний для каждой новой исходящей TCP сессии. Как только такая запись будет создана, пакеты, принадлежащие сеансу смогут ходить, не подвергаясь проверке набором правил системы сетевой защиты. Как мы упоминали ранее, это работает для UDP и ICMP:



block in quick on tun0 all

pass out quick on tun0 proto tcp from 20.20.20.1/32 to any keep state

pass out quick on tun0 proto udp from 20.20.20.1/32 to any keep state

pass out quick on tun0 proto icmp from 20.20.20.1/32 to any keep state

Мы сделали это! Теперь у нас есть сохранение состояний сеансов TCP, UDP, ICMP. Теперь мы можем делать исходящие соединения, как будто вообще нет никакой системы сетевой защиты и в то же время, ни один злоумышленник не может соединиться с нами. Это очень удобно, потому что нет никакой необходимости выяснять, какие порты у нас открыты и мы можем предоставить доступ только к тем портам, к которым мы хотим.

Сохранение состояний — довольно хитрая штука. Могут происходить странные и таинственные вещи. Рассмотрим следующий пример:



pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23

pass out quick on tun0 proto tcp from any to any keep state

block in quick all

block out quick all

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

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



pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 keep state

pass out quick on tun0 proto tcp from any to any keep state

block in quick all

block out quick all

Ключевое слово keep state в первом правиле сделает необходимую запись в таблице состояний и все будет работать как ожидалось. Просмотреть текущие записи в таблице состояний Вы можете командой ipfstat -s.

Stateful UDP

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

Вот пример использования утилиты nslookup для определения IP адреса узла www.3com.com:



$ nslookup www.3com.com

Будет сгенерирован пакет DNS:



17:54:25.499852 20.20.20.1.2111 > 198.41.0.5.53: 51979+

Пакет от 20.20.20.1, порт 2111, предназначен для 198.41.0.5, порт 53. На 60 секунд создано правило. Если пакет возвращается с 198.41.0.5 порт 53 для 20.20.20.1 порт 2111 в пределах этого периода времени, пакет будет пропущен. Чуть позже Вы можете увидеть:



17:54:25.501209 198.41.0.5.53 > 20.20.20.1.2111: 51979 q: www.3com.com

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

Stateful ICMP

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



pass out on tun0 proto icmp from any to any icmp-type 8 keep state

для разрешения исходящих 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 Вам необходимо было использовать конструкцию:



pass out on tun0 proto udp from any to any port 33434><33690 keep state

pass in on tun0 proto icmp from any to any icmp-type timex

А сейчас сделать это можно используя только таблицу состояния UDP:



pass out on tun0 proto udp from any to any port 33434><33690 keep state

Для обеспечения защиты Вашей сети от посторонних ICMP сообщений, проверяется также не только адреса источника и назначения (и порты, когда это возможно), но и его содержимое.

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

Давайте вернемся к четырем правилам из предыдущего раздела:



pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 keep state

pass out quick on tun0 proto tcp from any to any keep state

block in quick all

block out quick all

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



pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 flags S keep state

pass out quick on tun0 proto tcp from any to any flags S keep state

block in quick all

block out quick all

Теперь пропущен будет только пакет 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 выявит и будет следить за фрагментированными пакетами, пропуская фрагменты. Итак, давайте перепишем правила так, чтобы регистрировать поддельные пакеты и пропускать фрагменты.



pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23 flags S keep state keep frags

pass out quick on tun0 proto tcp from any to any keep state flags S keep frags

block in log quick all

block out log quick all

Это работает, потому что для каждого пакета, который необходимо пропустить имеется запись в таблице сосояний. Единственный тип сканирования, котрый будет возможен — это непосредственно SYN сканирование. Если это Вас действительно беспокоит, то включите и регистрацию SYN пакетов.

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

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

Когда на Unix-системе на запрашиваемом порту не запущена служба, то это дается понять пославшему запрос, возвращая пакет определенного типа. В TCP это делается с помощью пакета RST. При блокировании TCP пакета, IPF может позвратить отправителю пакет RST, используя ключевое слово return-rst. И поэтому вместо:



block in log on tun0 proto tcp from any to 20.20.20.0/24 port = 23

pass in all

Мы можем теперь записать:



block return-rst in log proto tcp from any to 20.20.20.0/24 port = 23

block in log quick on tun0

pass in all

Мы нуждаемся в двух правилах block, так как return-rst работает только с TCP, а нам необходимо блокировать еще UDP, ICMP и все остальное. После того, как это сделано, удаленная стороно получит «connection refused» вместо «connection timed out». Также возможно послать сообщение об ошибке в случае получения UDP пакета. В случае правила:



block in log quick on tun0 proto udp from any to 20.20.20.0/24 port = 111

мы можем переписать его таким образом, используя ключевое слово return-icmp:



block return-icmp(port-unr) in log quick on tun0 proto udp from any to 20.20.20.0/24 port = 111

Согласно TCP/IP Illustrated, корректным ICMP
ответом в случае отсутствии сервиса на запрашиваемом порту будет
port-unreachable. Вы можете возвращать любой тип ICMP пакета, но
port-unreachable будет, наверное, лучшим выбором. Он используется по
умолчанию для return-icmp.

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



block return-icmp-as-dest(port-unr) in log on tun0 proto udp from any to 20.20.20.0/24 port = 111

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

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

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



block in log level auth.info quick on tun0 from 20.20.20.0/24 to any

block in log level auth.alert quick on tun0 proto tcp from any to 20.20.20.0/24 port = 21

Вы можете казать, какая информация будет регистрироваться, например Вам не интересно, кто ломился на telnet порт 500 раз подрят, а Вам интересно, кто пробовал сделать это один раз. Вы можете использовать ключевое слово log first для регистрации первого пакета.

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

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

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



block in on tun0

block in quick on tun0 from 192.168.0.0/16 to any

block in quick on tun0 from 172.16.0.0/12 to any

block in quick on tun0 from 10.0.0.0/8 to any

block in quick on tun0 from 127.0.0.0/8 to any

block in quick on tun0 from 0.0.0.0/8 to any

block in quick on tun0 from 169.254.0.0/16 to any

block in quick on tun0 from 192.0.2.0/24 to any

block in quick on tun0 from 204.152.64.0/23 to any

block in quick on tun0 from 224.0.0.0/3 to any

block in log quick on tun0 from 20.20.20.0/24 to any

block in log quick on tun0 from any to 20.20.20.0/32

block in log quick on tun0 from any to 20.20.20.255/32

pass out quick on tun0 proto tcp/udp from 20.20.20.1/32 to any keep state

pass out quick on tun0 proto icmp from 20.20.20.1/32 to any keep state

pass in quick on tun0 proto tcp from any to 20.20.20.1/32 port = 80 flags S keep state

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

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

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

Мы опишем набор правил полностью за один раз, так как считаем, что Вы уже способны их прочесть самостоятельно:



block in quick on xl0 from 192.168.0.0/16 to any

block in quick on xl0 from 172.16.0.0/12 to any

block in quick on xl0 from 10.0.0.0/8 to any

block in quick on xl0 from 127.0.0.0/8 to any

block in quick on xl0 from 0.0.0.0/8 to any

block in quick on xl0 from 169.254.0.0/16 to any

block in quick on xl0 from 192.0.2.0/24 to any

block in quick on xl0 from 204.152.64.0/23 to any

block in quick on xl0 from 224.0.0.0/3 to any

block in log quick on xl0 from 20.20.20.0/24 to any

block in log quick on xl0 from any to 20.20.20.0/32

block in log quick on xl0 from any to 20.20.20.63/32

block in log quick on xl0 from any to 20.20.20.64/32

block in log quick on xl0 from any to 20.20.20.127/32

block in log quick on xl0 from any to 20.20.20.128/32

block in log quick on xl0 from any to 20.20.20.255/32

pass out on xl0 all

pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 80 flags S keep state

pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 21 flags S keep state

pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 20 flags S keep state

pass out quick on xl1 proto tcp from any to 20.20.20.65/32 port = 53 flags S keep state

pass out quick on xl1 proto udp from any to 20.20.20.65/32 port = 53 keep state

pass out quick on xl1 proto tcp from any to 20.20.20.66/32 port = 53 flags S keep state

pass out quick on xl1 proto udp from any to 20.20.20.66/32 port = 53 keep state

block out on xl1 all

pass in quick on xl1 proto tcp/udp from 20.20.20.64/26 to any keep state

block out on xl2 all

pass in quick on xl2 proto tcp/udp from 20.20.20.128/25 to any keep state

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



block out quick on xl1 all head 10

pass out quick proto tcp from any to 20.20.20.64/26 port = 80 flags S keep state group 10

block out on xl2 all

В этом упрощенном примере мы можем увидеть всю мощь группировки правил: если пакет не предназначен для xl1, то head в правиле group 10 не будет соответствовать и поэтому проверка правил будет продолжена. Если пакет действительно предназначен для xl1, то ключевое слово quick позволит нам перейти к проверке правил группы 10, а именно проверке SYN для 80/tcp. Перепишем наши правила соответствующим образом:



block in quick on xl0 all head 1

block in quick on xl0 from 192.168.0.0/16 to any group 1

block in quick on xl0 from 172.16.0.0/12 to any group 1

block in quick on xl0 from 10.0.0.0/8 to any group 1

block in quick on xl0 from 127.0.0.0/8 to any group 1

block in quick on xl0 from 0.0.0.0/8 to any group 1

block in quick on xl0 from 169.254.0.0/16 to any group 1

block in quick on xl0 from 192.0.2.0/24 to any group 1

block in quick on xl0 from 204.152.64.0/23 to any group 1

block in quick on xl0 from 224.0.0.0/3 to any group 1

block in log quick on xl0 from 20.20.20.0/24 to any group 1

block in log quick on xl0 from any to 20.20.20.0/32 group 1

block in log quick on xl0 from any to 20.20.20.63/32 group 1

block in log quick on xl0 from any to 20.20.20.64/32 group 1

block in log quick on xl0 from any to 20.20.20.127/32 group 1

block in log quick on xl0 from any to 20.20.20.128/32 group 1

block in log quick on xl0 from any to 20.20.20.255/32 group 1

pass in on xl0 all group 1

pass out on xl0 all

block out quick on xl1 all head 10

pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 80 flags S keep state group 10

pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 21 flags S keep state group 10

pass out quick on xl1 proto tcp from any to 20.20.20.64/26 port = 20 flags S keep state group 10

pass out quick on xl1 proto tcp from any to 20.20.20.65/32 port = 53 flags S keep state group 10

pass out quick on xl1 proto udp from any to 20.20.20.65/32 port = 53 keep state group 10

pass out quick on xl1 proto tcp from any to 20.20.20.66/32 port = 53 flags S keep state

pass out quick on xl1 proto udp from any to 20.20.20.66/32 port = 53 keep state group 10

pass in quick on xl1 proto tcp/udp from 20.20.20.64/26 to any keep state

block out on xl2 all

pass in quick on xl2 proto tcp/udp from 20.20.20.128/25 to any keep state

Теперь Вы можете увидеть группы правил в действии: для пакетов к компьютерам, находящихся в сети xl2 мы можем не применять правила из group 10.

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

Ключевое слово «Fastroute»

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



block in quick on xl0 fastroute proto udp from any to any port 33434 >< 33465

Присутствие ключевого слова 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) достигается одной строкой:



map tun0 192.168.1.0/24 -> 20.20.20.1/32

Очень просто. Всякий раз, когда с интерфейса 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 адрес интерфейса:



map tun0 192.168.1.0/24 -> 0/32

Теперь мы можем спокойно загрузить наши правила ipnat и соединиться с внешним миром без необходимости редактирования правил. ПОсле повторного соединения необходимо выполнить команду ipf -y для обновления адреса.

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



map tun0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:30000

Теперь наше правило производит транслирование, используя в качестве исходных портов (которые могут быть tcp, udp, или tcp/udp) диапазон с 20000 по 30000.

Дополнительно мы можем сделать нашу жизнь еще проще, используя ключевое слово auto, для того, чтобы ipnat самостоятельно определял диапазон портов, доступных для использования и размещал их пропорционально доступному адресному пространству:



map tun0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto

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



map tun0 192.168.1.0/24 -> 0/32 portmap tcp/udp 20000:30000

map tun0 192.168.1.0/24 -> 0/32

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

Другой традиционный пример использования NAT — это отображение большого количества IP адресов в маленький статически выделенный диапазон. Этого довольно просто достичь зная ключевые слова map и portmap.



map tun0 192.168.0.0/16 -> 20.20.20.0/24 portmap tcp/udp 20000:60000

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



map-block tun0 192.168.1.0/24 -> 20.20.20.0/24

Как и с map, map-block имеет собственную версию portmap. Это достигается использованием ключевого слова auto:



map-block tun0 192.168.1.0/24 -> 20.20.20.0/24 auto

Ключевое слово ports используется, если Вы хотите определить определенный порт для каждого IP адреса.

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

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



bimap tun0 192.168.1.1/32 -> 20.20.20.1/32

Результатом этого правила будет отображение адреса 192.168.1.1/32 в адрес 20.20.20.1/32.

Правила NAT

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



map tun0 from 192.168.1.0/24 ! to 5.0.0.0/20 -> 20.20.20.1/32

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



map tun0 from 192.168.1.5/32 port = 5555 to 1.2.3.4/32 -> 20.20.20.2/32

map tun0 from 192.168.1.0/24 to 5.0.0.0/20 -> 20.20.20.2/32 portmap auto

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

Служба спуфинга? Зачем это может быть нужно? Да масса просто примеров из жизни! Давайте представим, что у нас есть web-сервер с IP адресом 20.20.20.5, и в последнее время нас все больше стала беспокоить его защита. Мы более не желаем запускать сервис на 80 порту, так как это требует выполнения некоторых действий с правами поьзователя root. Но как мы сможем запустить на непривилигерованном 8000 порту «xz.com»? Как люди найдут наш сервер? Для решения этой проблемы мы можем использовать средства перенаправления NAT, перебрасывая все запросы для 20.20.20.5:80 на 20.20.20.5:8000. Будем использовать ключевое слово rdr:



rdr tun0 20.20.20.5/32 port 80 -> 192.168.0.5 port 8000

Здесь также мы можем указать тип протокола UDP/TCP (по умолчанию считается TCP). Например, если на нашей системе сетевой защиты у нас имеется honeypot, имитирующий троян Back Orifice для Windows, мы могли бы сделать так:



rdr tun0 20.20.20.0/24 port 31337 -> 127.0.0.1 port 31337 udp

Также мы можем изменить поведение rdr основаваясь на источнике и адресе назначения:



rdr tun0 from 10.1.1.1/32 to 20.20.20.5/32 port = 80 -> 192.168.0.5 port 8001

rdr tun0 from 10.1.1.1/32 port = 12345 to 20.20.20.5/32 port = 80 -> 192.168.0.5 port 8002

Очень важное замечание: Вы не сможете легко использовать rdr как «reflector».



rdr tun0 20.20.20.5/32 port 80 -> 20.20.20.6 port 80 tcp

Это правило не будет работать в ситуации, где .5 и .6 находятся в одной сети. Да. Есть способ сделать это. Но будет значительно проще распилить слона лобзиком на куски. Крутые перцы, которым это действительно надо, могут организовать нечто вроде прозрачного перенаправления в TIS plug-gw на 127.0.0.1. Функция rdr применима к пакетам, которые входят в систему сетевой защиты на указанный интерфейс. Когда приходит пакет, соответствующй правилу rdr, перезаписывается адрес назначения и помещается в ipf для фильтрации, в случае успешного прохождения правил фильтрации пакет передается в систему маршрутизации unix. В случае переотражения («reflector») пакет остается на том же самом интерфейсе, что запутывает систему. «reflector» — не работает. Всегда помните, что пакет, подвергшийся rdr и исходный пакет должны быть с разных интерфейсов. (Включая и 127.0.0.1).

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

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



rdr xl0 0.0.0.0/0 port 21 -> 127.0.0.1 port 21

Эта инструкция указывает любому пакету, входящему на интерфейс 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 запишем:



rdr tun0 20.20.20.5/32 port 80 -> 192.168.0.5 port 8000

И в ipf.rules:



pass in on tun0 proto tcp from 172.16.8.2/32 to 192.168.0.5/32 port = 8000 flags S keep state

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

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

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



map tun0 192.168.1.0/24 -> 20.20.20.1/32 proxy port ftp ftp/tcp

Помните: всегда размещайте правила proxy rule перед любыми правилами portmap, иначе происходит изменение пакета до того, как прокси-сервер получает возможность обработать пакет.

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

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

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



rdr tun0 20.20.20.5/32 port 80 -> 192.168.0.5, 192.168.0.6, 192.168.0.7 port 8000

Загрузка и управление правилами фильтрации. Утилита 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

input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0

output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0

input packets logged: blocked 99286 passed 0

output packets logged: blocked 0 passed 0

packets logged: input 0 output 0

log failures: input 3898 output 0

fragment state(in): kept 0 lost 0

fragment state(out): kept 0 lost 0

packet state(in): kept 169364 lost 0

packet state(out): kept 431395 lost 0

ICMP replies: 0 TCP RSTs sent: 0

Result cache hits(in): 1215208 (out): 1098963

IN Pullups succeeded: 2 failed: 0

OUT Pullups succeeded: 0 failed: 0

Fastroute successes: 0 failures: 0

TCP cksum fails(in): 0 (out): 0

Packet log flags set: (0)

none

ipfstat также может показать Вам текущий список правил. Используйте флаги -i или -o для отображения правил in или out соответственно. Добавление опции -h позволит увидеть более подробную информацию с указанием «hit count» для каждого правила:



# ipfstat -ho

2451423 pass out on xl0 from any to any

354727 block out on ppp0 from any to any

430918 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state keep frags

Здесь мы можем увидеть, что существуют какие-то проблемы, так как слишком много блокированных пакетов, несмотря на наличие таких правил pass out. В это м примере придется разбираться с правилами… ipfstat не может сказать Вам, правильно или нет Вы написали набор правил, это придется выяснять Вам самостоятельно. Для отладки Вы можете использовать также опцию -n, которая пронумерует список.



# ipfstat -on

@1 pass out on xl0 from any to any

@2 block out on ppp0 from any to any

@3 pass out quick on ppp0 proto tcp/udp from 20.20.20.0/24 to any keep state keep frags

И в заключение полезной информации, выдаваемой утилитой ipfstat, является опция -s, дамп таблицы состояний:



# ipfstat -s

281458 TCP

319349 UDP

0 ICMP

19780145 hits

5723648 misses

0 maximum

0 no memory

1 active

319349 expired

281419 closed

100.100.100.1 -> 20.20.20.1 ttl 864000 pass 20490 pr 6 state 4/4

pkts 196 bytes 17394 987 -> 22 585538471:2213225493 16592:16500

pass in log quick keep state

pkt_flags & b = 2, pkt_options & ffffffff = 0

pkt_security & ffff = 0, pkt_auth & ffff = 0

Здесь мы видим, что имеется одна запись для TCP сессии. Вывод может меняться от версии к версии, но основная информация сохранится. Мы видим, что имеется полностью установленное соединение, обозначенное номером 4/4. Другие соединения незавершены еще и будут зарегистрированы позже. Мы увидим, что TTL сессии равно 240 часов, что нелепо долго, но являестя значением по умолчанию для сессии TCP. Счетсик уменьшается каждую секудну, когда соединение не используется и снова выставляется в 864000 при использовании, что гарантирует сохранение сессии при работе. Мы можем также видеть, что мы передали 196 пакетов, примерно по 17 Кб каждый, также мы можем увидеть порты источника и назначения.

[ad name=»Google Adsense»]

Утилита ipmon

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



# ipmon -o S

01/08/1999 15:58:57.836053 STATE:NEW 100.100.100.1,53 -> 20.20.20.15,53 PR udp

01/08/1999 15:58:58.030815 STATE:NEW 20.20.20.15,123 -> 128.167.1.69,123 PR udp

01/08/1999 15:59:18.032174 STATE:NEW 20.20.20.15,123 -> 128.173.14.71,123 PR udp

01/08/1999 15:59:24.570107 STATE:EXPIRE 100.100.100.1,53 -> 20.20.20.15,53 PR udp Pkts 4 Bytes 356

01/08/1999 16:03:51.754867 STATE:NEW 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp

01/08/1999 16:04:03.070127 STATE:EXPIRE 20.20.20.13,1019 -> 100.100.100.10,22 PR tcp Pkts 63 Bytes 4604

Здесь мы видим dns запросы, использования утилиты ping и недолгую ssh сессию.

ipmon также способен показать зарегистрированные пакеты. Например, при использовании keep state, Вы будете часто сталкиваться с пакетами типа:



# ipmon -o I

15:57:33.803147 ppp0 @0:2 b 100.100.100.103,443 -> 20.20.20.10,4923 PR tcp len 20 1488 -A

Что это означает? Первое поле — это время регистрации. Второе поле тоже довольно очевидно и указывает на интерфейс. Третье поле @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. Другой пример:



12:46:12.470951 xl0 @0:1 S 20.20.20.254 -> 255.255.255.255 PR icmp len 20 9216 icmp 9/0

Это ICMP пакет router discovery.

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



# ipmon -o N

01/08/1999 05:30:02.466114 @2 NAT:RDR 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816]

01/08/1999 05:30:31.990037 @2 NAT:EXPIRE 20.20.20.253,113 <- -> 20.20.20.253,113 [100.100.100.13,45816] Pkts 10 Bytes 455

Keep State With Servers and Flags

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



block in all

pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S

pass out all keep state

Это, конечно, позволяит подключению быть созданным на сервер telnet с адресом 20.20.20.20 и ответные пакеты также будут ходить. Если Вы пробуете использовать это правило, Вы увидите, что это действительно работает — на мгновение. Так как мы фильтруем флажг SYN, для таблицы состояний соединение не будет установлено, а заданное по умолчанию время жизни неполного состояния — 60 секунд.

Решить эту проблему можно следующими способами:



block in all

pass in quick proto tcp from any to 20.20.20.20/32 port = 23 keep state

block out all

или



block in all

pass in quick proto tcp from any to 20.20.20.20/32 port = 23 flags S keep state

pass out all keep state

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

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

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

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

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

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



pass in quick proto tcp from any to 20.20.20.20/32 port = 21 flags S keep state

pass out proto tcp all keep state

Эти правила позволяют соединяться с Вашим FTP-сервером 20.20.20.20 в активном режиме.

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

Первой мыслью было бы открыть все порты более чем 1023. На самом деле, это будет работать.



pass in quick proto tcp from any to 20.20.20.20/32 port > 1023 flags S keep state

pass out proto tcp all keep state

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

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



pass in quick proto tcp from any to 20.20.20.20/32 port 15000 >< 20000 flags S keep state

pass out proto tcp all keep state

Если это решение не удовлетворило Вас, Вы всегда можете добавить поддержку IPF в Ваш FTP-сервер, или поддержку FTP-сервера в IPF.

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

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

Самый простой тип клиентской передачи с точки зрения системы сетевой защиты — пассивная передача. Эти соединения будут обрабатываться теми правилами keep state, которые Вы используете для исходящих tcp соединений. Если Вы этого еще не сделали, рассмотрите такую запись:



pass out proto tcp all keep state

Активный режим работы немного неприятнее, но тоже вполне решим. Активные передачи заставляют сервер создать второе подключение с клиентом для того, чтобы передать данные уже через него. В случае наличия системы сетевой защиты обычно это становится проблемой. Чтобы решить эту проблему ipfilter включает ipnat прокси-сервер, который временно открывает дыру в системе сетевой защиты только для FTP-сервера. Даже если Вы не используете ipnat для NAT, использование прокси-сервера будет эффективным решением. Следующие правила — тот минимум, который необходимо добавить к правилам ipnat:



map ep0 0/0 -> 0/32 proxy port 21 ftp/tcp

Дополнительную информацию по внутренним прокси-серверам поищите в разделе выше. Вообще-то ftp-сервер — это дыра в защите. Читайте http://www.false.net/ipfilter/2001_11/0273.html.

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

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



openbsd:

net.inet.ip.forwarding=1
freebsd:

net.inet.ip.forwarding=1
netbsd:

net.inet.ip.forwarding=1
solaris:

ndd -set /dev/ip ip_forwarding 1
Ephemeral Port Adjustment:
openbsd:

net.inet.ip.portfirst = 25000
freebsd:

net.inet.ip.portrange.first = 25000 net.inet.ip.portrange.last = 49151
netbsd:

net.inet.ip.anonportmin = 25000 net.inet.ip.anonportmax = 49151
solaris:

ndd -set /dev/tcp tcp_smallest_anon_port 25000

ndd -set /dev/tcp tcp_largest_anon_port 65535
Other Useful Values:
openbsd:

net.inet.ip.sourceroute = 0

net.inet.ip.directed-broadcast = 0
freebsd:

net.inet.ip.sourceroute=0

net.ip.accept_sourceroute=0
netbsd:

net.inet.ip.allowsrcrt=0

net.inet.ip.forwsrcrt=0

net.inet.ip.directed-broadcast=0

net.inet.ip.redirect=0

solaris: ndd -set /dev/ip ip_forward_directed_broadcasts 0 ndd -set /dev/ip ip_forward_src_routed 0 ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Дополнительно, FreeBSD имеет еще несколько интересных переменных sysctl.
net.inet.ipf.fr_flags: 0 net.inet.ipf.fr_pass: 514 net.inet.ipf.fr_active: 0 net.inet.ipf.fr_tcpidletimeout: 864000 net.inet.ipf.fr_tcpclosewait: 60 net.inet.ipf.fr_tcplastack: 20 net.inet.ipf.fr_tcptimeout: 120 net.inet.ipf.fr_tcpclosed: 1 net.inet.ipf.fr_udptimeout: 120 net.inet.ipf.fr_icmptimeout: 120 net.inet.ipf.fr_defnatage: 1200 net.inet.ipf.fr_ipfrttl: 120 net.inet.ipf.ipl_unreach: 13 net.inet.ipf.ipl_inited: 1 net.inet.ipf.fr_authsize: 32 net.inet.ipf.fr_authused: 0 net.inet.ipf.fr_defaultauthage: 600

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

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

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

Давным давно, в далеком университете Wietse Venema писал tcp-wrapper, которыми пытался поднять уровень безопасности сетевых сервисов во всем мире. Это хорошо. Но недостаточно. Они защищали только известные сервисы, хотя сервисы могут быть запущены через inetd, скомпилированы с libwrap и соответствующими обработчиками прерываний, что сделает сервис незащищенным. Это открывает гигантскую дыру в Вашем компьютере. Для примера, мой лэптоп часто подключается к сети с сомнительных в плане безопасности мест. Поэтому мой набор правил выглядит следующим образом:



pass in quick on lo0 all

pass out quick on lo0 all

block in log all

block out all

pass in quick proto tcp from any to any port = 113 flags S keep state

pass in quick proto tcp from any to any port = 22 flags S keep state

pass in quick proto tcp from any port = 20 to any port 39999 >< 45000 flags S keep state

pass out quick proto icmp from any to any keep state

pass out quick proto tcp/udp from any to any keep state keep frags

Это работает уже довольно долгое время и я не имею никаких проблем с загрузкой 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. Для превращения этой машины в мост требуется следущее:

brconfig bridge0 add xl0 add xl1 upifconfig xl0 up

ifconfig xl1 up

С этого момента весь трафик с xl0 будет пересылаться на xl1 и наоборот. Обратите внимание, что интерфейсам не были назначены IP адреса.

Наборы правил ведут себя по прежнему. Хоть у нас есть интерфейс bridge0, мы его трогать не будем, а используем специфический интерфейс, зависящий от сетевой карты и типа кабеля. Рассмотрим следующую сеть:



20.20.20.1 <---------------------------------> 20.20.20.0/24 network hub

То есть мы имеем маршрутизатор 20.20.20.1 связанный с сетью 20.20.20.0/24. Пакеты от сети 20.20.20.0/24 уходят на 20.20.20.1 дабы уйти во внешний мир и наоборот. Теперь мы добавляем мост Ipf:



20.20.20.1 <-------/xl0 IpfBridge xl1/-------> 20.20.20.0/24 network hub

Также мы имеем следующий набор правил:



pass in quick all

pass out quick all

С этими правилами сети функционально идентичны. Теперь изменим набор правил:



block in quick on xl0 proto icmp

pass in quick all

pass out quick all

Однако, 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 — таблицу состояния:



pass in quick on xl1 proto tcp keep state

pass in quick on xl1 proto udp keep state

pass in quick on xl1 proto icmp keep state

block in quick on xl0

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

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



pass in quick on xl1 proto tcp keep state

pass in quick on xl1 proto udp keep state

pass in quick on xl1 proto icmp keep state

block in quick on xl1 # nuh-uh, we're only passing tcp/udp/icmp sir.

pass in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state

pass in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state

pass in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state

pass in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state

block in quick on xl0

Теперь мы имеем сеть, где 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.20.20.1 router 		20.20.20.6 unix server

20.20.20.2 unix server 		20.20.20.7 nt workstation

20.20.20.3 unix server		20.20.20.8 nt server

20.20.20.4 win98 workstation 	20.20.20.9 unix workstation

20.20.20.5 intelligent switch 20.20.20.10 win95 workstation

Только это раз в 20 больше, разнородней и незадокументированней. В идеальном варианте все серверы находятся в одной сети, рабочие машины в другой и активное сетевое оборудование в третьей. Тогда маршрутизатор фильтровал бы пакеты между подсетями, давая рабочим станциям ограниченный доступ к серверам, никого не пуская к свичам и только машина администратора имела бы полный доступ ко всем устройствам. Я никогда не видел сети класса С разделенной таким образом. IP Filter нам поможет.
Для начала, мы разделим маршрутизатор, рабочие станции и сервер. Для того, чтобы сделать это, нам необходимо 2 концентратора (которые, скорее всего, уже есть), машина с IPF и 3 сетевые карты Ethernet. Мы поместим все сервера в один концентратор, а рабочие станции в другой. В обычной ситуации мы бы соединили концентраторы между собой, а затем в маршрутизатор. Но сейчас мы сделаем по другому: маршрутизатор подключаем в интерфейс xl0, серверы в xl1 и рабочие станции в xl2. Теперь наша сеть выглядит примерно так:



| 20.20.20.2 unix server

router (20.20.20.1) ____________| 20.20.20.3 unix server

| / | 20.20.20.6 unix server

| /xl1 | 20.20.20.7 nt server

------------/xl0 IPF Bridge <

 xl2 | 20.20.20.4 win98 workstation

____________| 20.20.20.8 nt workstation

| 20.20.20.9 unix workstation

| 20.20.20.10 win95 workstation

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



pass in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state

pass in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state

pass in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state

pass in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state

block in quick on xl0

pass in quick on xl1 proto tcp keep state

pass in quick on xl1 proto udp keep state

pass in quick on xl1 proto icmp keep state

block in quick on xl1 # nuh-uh, we're only passing tcp/udp/icmp sir.

pass in quick on xl2 proto tcp keep state

pass in quick on xl2 proto udp keep state

pass in quick on xl2 proto icmp keep state

block in quick on xl2 # nuh-uh, we're only passing tcp/udp/icmp sir.

Еще раз отметим — трафик, идущий с маршрутизатора, ограничен DNS, SMTP, HTTP. В настоящее время, серверы и рабочие станции могут обмениваться трафиком свободно. Возможно Вас это не устроит. Вы хотите вообще запретить доступ рабочим станциям к серверам? Тогда возьмите набор правил для xl2:



pass in quick on xl2 proto tcp keep state

pass in quick on xl2 proto udp keep state

pass in quick on xl2 proto icmp keep state

block in quick on xl2 # nuh-uh, we're only passing tcp/udp/icmp sir.

И замените его на:



block in quick on xl2 from any to 20.20.20.0/24

pass in quick on xl2 proto tcp keep state

pass in quick on xl2 proto udp keep state

pass in quick on xl2 proto icmp keep state

Возможно, Вы захотите, чтобы пользователи могли только принимать/отправлять почту по протоколу IMAP?



pass in quick on xl2 proto tcp from any to 20.20.20.3/32 port=25

pass in quick on xl2 proto tcp from any to 20.20.20.3/32 port=143

block in quick on xl2 from any to 20.20.20.0/24

pass in quick on xl2 proto tcp keep state

pass in quick on xl2 proto udp keep state

pass in quick on xl2 proto icmp keep state

block in quick on xl2 # nuh-uh, we're only passing tcp/udp/icmp sir.

Теперь ваши рабочие станции и серверы защищены от внешнего мира, и серверы защищены от ваших рабочих станций.

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



pass in quick on xl2 from any to 20.20.20.0/24

block in quick on xl2

Теперь серверы имеют доступ к внешнему миру, а
рабочие станции нет. Запретим доступ и серверам.



pass in quick on xl1 from any to 20.20.20.0/24

block in quick on xl1

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

Полный набор правил смотрелся бы примерно так:



pass in quick on xl0 proto udp from any to 20.20.20.2/32 port=53 keep state

pass in quick on xl0 proto tcp from any to 20.20.20.2/32 port=53 flags S keep state

pass in quick on xl0 proto tcp from any to 20.20.20.3/32 port=25 flags S keep state

pass in quick on xl0 proto tcp from any to 20.20.20.7/32 port=80 flags S keep state

block in quick on xl0

pass in quick on xl1 from any to 20.20.20.0/24

block in quick on xl1

pass in quick on xl2 from any to 20.20.20.0/24

block in quick on xl2

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

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

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

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

Метод dup-to

Если, например, мы хотели послать копию всего выходящего из интерфейса xl3 на нашу drop-safe сеть ed0, то мы бы использовали такое правило:



pass out on xl3 dup-to ed0 from any to any

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



pass out on xl3 dup-to ed0:192.168.254.2 from any to any

Но помните, что этот метод изменяет адрес назначения скопированного пакета, а потому достоверность файла регистрации может бытьнарушена. По этой причине мы рекомендуем использовать для регистрации только известный адрес (например, не используйте 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 in quick on xl0 to ed0 proto tcp from any to any port < 1024

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

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

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

Так без дальнейшей суматохи, законченный список поддельных сетей:



#

# s/OUTSIDE/outside-interface (eg: fxp0)

# s/MYNET/network-cidr-address (eg: 1.2.3.0/24)

#

block in on OUTSIDE all

block in quick on OUTSIDE from 0.0.0.0/7 to any

block in quick on OUTSIDE from 2.0.0.0/8 to any

block in quick on OUTSIDE from 5.0.0.0/8 to any

block in quick on OUTSIDE from 10.0.0.0/8 to any

block in quick on OUTSIDE from 23.0.0.0/8 to any

block in quick on OUTSIDE from 27.0.0.0/8 to any

block in quick on OUTSIDE from 31.0.0.0/8 to any

block in quick on OUTSIDE from 70.0.0.0/7 to any

block in quick on OUTSIDE from 72.0.0.0/5 to any

block in quick on OUTSIDE from 83.0.0.0/8 to any

block in quick on OUTSIDE from 84.0.0.0/6 to any

block in quick on OUTSIDE from 88.0.0.0/5 to any

block in quick on OUTSIDE from 96.0.0.0/3 to any

block in quick on OUTSIDE from 127.0.0.0/8 to any

block in quick on OUTSIDE from 128.0.0.0/16 to any

block in quick on OUTSIDE from 128.66.0.0/16 to any

block in quick on OUTSIDE from 169.254.0.0/16 to any

block in quick on OUTSIDE from 172.16.0.0/12 to any

block in quick on OUTSIDE from 191.255.0.0/16 to any

block in quick on OUTSIDE from 192.0.0.0/19 to any

block in quick on OUTSIDE from 192.0.48.0/20 to any

block in quick on OUTSIDE from 192.0.64.0/18 to any

block in quick on OUTSIDE from 192.0.128.0/17 to any

block in quick on OUTSIDE from 192.168.0.0/16 to any

block in quick on OUTSIDE from 197.0.0.0/8 to any

block in quick on OUTSIDE from 201.0.0.0/8 to any

block in quick on OUTSIDE from 204.152.64.0/23 to any

block in quick on OUTSIDE from 219.0.0.0/8 to any

block in quick on OUTSIDE from 220.0.0.0/6 to any

block in quick on OUTSIDE from 224.0.0.0/3 to any

block in quick on OUTSIDE from MYNET to any

# Your pass rules come here...

block out on OUTSIDE all

block out quick on OUTSIDE from !MYNET to any

block out quick on OUTSIDE from MYNET to 0.0.0.0/7

block out quick on OUTSIDE from MYNET to 2.0.0.0/8

block out quick on OUTSIDE from MYNET to 5.0.0.0/8

block out quick on OUTSIDE from MYNET to 10.0.0.0/8

block out quick on OUTSIDE from MYNET to 23.0.0.0/8

block out quick on OUTSIDE from MYNET to 27.0.0.0/8

block out quick on OUTSIDE from MYNET to 31.0.0.0/8

block out quick on OUTSIDE from MYNET to 70.0.0.0/7

block out quick on OUTSIDE from MYNET to 72.0.0.0/5

block out quick on OUTSIDE from MYNET to 83.0.0.0/8

block out quick on OUTSIDE from MYNET to 84.0.0.0/6

block out quick on OUTSIDE from MYNET to 88.0.0.0/5

block out quick on OUTSIDE from MYNET to 96.0.0.0/3

block out quick on OUTSIDE from MYNET to 127.0.0.0/8

block out quick on OUTSIDE from MYNET to 128.0.0.0/16

block out quick on OUTSIDE from MYNET to 128.66.0.0/16

block out quick on OUTSIDE from MYNET to 169.254.0.0/16

block out quick on OUTSIDE from MYNET to 172.16.0.0/12

block out quick on OUTSIDE from MYNET to 191.255.0.0/16

block out quick on OUTSIDE from MYNET to 192.0.0.0/19

block out quick on OUTSIDE from MYNET to 192.0.48.0/20

block out quick on OUTSIDE from MYNET to 192.0.64.0/18

block out quick on OUTSIDE from MYNET to 192.0.128.0/17

block out quick on OUTSIDE from MYNET to 192.168.0.0/16

block out quick on OUTSIDE from MYNET to 197.0.0.0/8

block out quick on OUTSIDE from MYNET to 201.0.0.0/8

block out quick on OUTSIDE from MYNET to 204.152.64.0/23

block out quick on OUTSIDE from MYNET to 219.0.0.0/8

block out quick on OUTSIDE from MYNET to 220.0.0.0/6

block out quick on OUTSIDE from MYNET to 224.0.0.0/3

# Your pass rules come here...

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

Уважайте труд автора и переводчика, не ищите дешевой славы — оставляйте ссылки и копирайты при размещении статьи на своем ресурсе!

Реклама на сайте висит не просто так! Спасибо!

[ad name=»Google Adsense»]

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

Рубрики

Страницы

Мета