IPF Howto
Перевод: Сгибнев Михаил
Источник: http://dreamcatcher.ru/2009/11/27/ipf-howto/
Оглавление:
1. Введение
2. Оговорка
3. Авторское право
4. Где получить
5. Начальное использование систем фильтрации
6. Файл конфигурации: порядок следования директив
7. Основы обработки правил
8. Управление обработкой правил
9. Основы фильтрации по IP адресу
10. Управление интерфейсами
11. Совместное использование IP адреса и интерфейса
12. Двунаправленная фильтрация. Ключевое слово «out»
13. Регистрация событий. Ключевое слово «log»
14. Полная двунаправленная фильтрация на интерфейсе
15. Управление протоколами. Ключевое слово «proto»
16. Фильтрация ICMP с помощью ключевого слова «icmp-type». Обьединение наборов правил.
17. TCP и UDP порты; ключевое слово «port»
18. Введение в расширенную фильтрацию
19. Необузданная паранойя; или политика запрета по умолчанию
20. Неявное разрешение. Правило «keep state»
21. Stateful UDP
22. Stateful ICMP
23. Обнаружение FIN-сканирования. Ключевое слово «flags» и «keep frags»
24. Ответ на блокированный пакет
25. Представление о методах регистрации
26. Объединение всего этого
27. Увеличение производительности с помощью групп правил
28. Ключевое слово «Fastroute»
29. NAT и прокси
30. Отображение нескольких IP адресов в один
31. Отображение нескольких IP адресов в пул адресов
32. Отображение один к одному
33. Правила NAT
34. Spoofing Services
35. Поддержка прозрачных прокси. Польза перенаправления
36. Фильтрация перенаправления
37. Волшебство, скрытое в NAT. Прокси-серверы приложений
38. Еще немного волшебства; использование NAT для балансировки нагрузки
39. Загрузка и управление правилами фильтрации. Утилита ipf
40. Загрузка и управление правилами NAT. Утилита ipnat
41. Мониторинг и отладка
42. Утилита ipfstat
43. Утилита pmon
44. Keep State With Servers and Flags
45. Копирование с FTP
46. Работа FTP сервера
47. Работа FTP клиента
48. Различные переменные ядра
49. Наслаждайтесь с ipf!
50. Фильтрация на своей машине
51. Какой фаерволл? Прозрачная фильтрация
52. Использование прозрачной фильтрации для обнаружения ошибок проектирования сети
53. Drop-Safe Logging с использованием методов dup-to и to.
54. Метод dup-to
55. Метод to
56. Фильтрация поддельных сетей, вершина технологии anti-spoofing
IP Filter Based Firewalls HOWTO
Brendan Conoboy
Erik Fichtner
Wed Dec 11 12:42:58 EST 2002
Резюме:
Этот документ предназначен для того, чтобы познакомить пользователя с пакетнымфильтром IP Filter и дать некоторые основные принципы построения качественных систем сетевой защиты.
1. Введение
IP Filter — это маленький по размеру, но не по возможностям пакетный фильтр. Он делает почти все, что и другие свободно распространяемые системы сетевой защиты (ipfwadm, ipchains, ipfw), обладает дополнительными возможностями и хорошей переносимостью. Этот документ предназначен для того, чтобы придать некоторую связность разрозненным сведениям, имеющимся по ipfilter. В дальнейшем, этот документ будет также служить документацией для синтаксически совместимых пакетных фильтров (особенно pf), с указанием важных различий. Этот документ предназначен для описания синтаксиса и языка правил и не является платформозависимым. Было бы полезно, если читатель уже имел знакомство с пакетными фильтрами, однако, слишком большое знание может превратить чтение этого документа в обычную трату времени. Для большего понимания систем сетевой защиты, авторы рекомендуют Building Internet Firewalls, Chapman & Zwicky, O’Reilly and Associates; и TCP/IP Illustrated, Volume 1, Stevens, Addison-Wesley.
2. Оговорка
Авторы этого документа и переводчик не ответственны за любые убытки, которые были понесены вследствие предпринятых действий, основанных на прочтении этого документа. Этот документ предназначен как введение в формирование системы сетевой защиты, основанной на ipfilter. Если Вы не чувствуете себя готовым взвалить на себя такую ответственность, наймите профессионала, который сделает все за вас.
3. Авторское право
Если не заявлено иное, то HOWTO документы находятся под защитой авторских прав и принадлежат их авторам. HOWTO может быть приведен полностью или частично, на электронных и бумажных носителях с сохранением авторства. Коммерческое распространение позволяется и поощряется; однако, авторы хотели бы быть уведомленными относительно таких распространений.
Все переводы, производные работы, или работы, включающие любые HOWTO должны быть охвачены этим объявлением об авторском праве. То есть Вы не можете сделать работу, основанную на HOWTO и наложить дополнительные ограничения на ее распространение. Исключения к этим правилам можно предоставить при некоторых условиях; пожалуйста войдите в контакт с координатором HOWTO.
Короче говоря, мы желаем распространить эту информацию всеми возможными способами. Однако, мы действительно желаем сохранить авторское право на этот HOWTO, и хотели бы быть уведомленными относительно любых планов распространения HOWTO.
4. Где получить
Официальная страница IPF: http://coombs.anu.edu.au/~avalon/ip-filter.html
Распространяемый по лицензии BSD пакетный фильтр pf: http://www.benzedrine.cx/pf.html
Наиболее современная версия этого документа может быть найдена здесь: http://www.obfuscation.org/ipf/
5. Начальное использование систем фильтрации
Этот раздел предназначен для ознакомления Вас с синтаксисом ipfilter и общей теорией системы сетевой защиты.Функции, обсуждаемые здесь, вы можете найти в любом хорошем пакетном фильтре. Этот раздел даст Вам возможность более легко понять и освоить раздел расширенных возможностей.
Необходимо подчеркнуть, что прочтения только этого раздела недостаточно для построения хорошей системы сетевой защиты и изучения раздела расширенных возможностей действительно необходимо.
6. Файл конфигурации: порядок следования директив
IPF (IP Filter) имеет файл конфигурации. Он традиционен для Unix: одно правило в строке, знак # считается комментарием и символы справа от него до конца строки игнорируются, правило и комментарий могут находиться в одной строке, лишние пробелы и пустые строки игнорируются и поощряются для сохранения читабельности.
7. Основы обработки правил
Правила обрабатываются сверху вниз, каждое, одно за другим. Это весьма просто и означает что, если Ваш файл конфигурации состоит из строк:
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
То пакет по прежнему бы проходил. Нет никакого накопительного эффекта. Последнее правило всегда имеет приоритет.
8. Управление обработкой правил
Если у Вас есть опыт работы с другими пакетными фильтрами, то Вы можете найти такой порядок весьма запутывающим и размышлять о портируемости списка правил и скорости обработки правил. Представьте себе, что у Вас есть 100 правил и большинство пакетов соответствовало бы первым 10. Было бы ужасно, если бы каждый пакет, имеющий окончательное соответствие, проходил бы все 100 правил. К счастью есть простое ключевое слово, которое может быть добавлено к любому правилу, для принятия именно этого решения при соответствии. Это слово quick.
Вот немного измененный набор правил:
block in quick all
pass in all
В этом случае IPF смотрит на первое правило:
block in quick all
Сравнения пакета и правил закончены. Пакетнемедленно блокирован. Нет никаких примечаний и никаких записей в файлах регистрации. Так что там со следующим правилом?
pass in all
Это правило не будет рассматриваться, с тем же успехом его могло вообще не быть в файле конфигурации. Наличие таких ключевых слов как all и quick позволит нам с уверенностью утверждать, что никакие другие нижеследующие правила рассматриваться не будут.
Положение, когда зря пропадает половина файла конфигурации едва ли можно назвать удачным. С другой стороны, IPF должен сдесь блокировать все пакеты и справляется с этой работой хорошо. Тем не менее, IPF должен также позволить проходить некоторым пакетам, так что необходимо сделать некоторые изменения в наборе правил.
9. Основы фильтрации по 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.
10. Управление интерфейсами
Довольно распространенной ситуацией является, когда сеть компании содержит адреса из частной сети, перед тем, как выйти в Интернет. Фактически, это основная причина рассмотрения систем сетевой защиты. Машина соединяющая внешнюю и внутреннюю сети называется маршрутизатором.
Отличить его от обычного компьютера довольно просто — он имеет больше чем один сетевой интерфейс.
Каждый пакет, который Вы получаете, приходит с сетевого интерфейса, каждый пакет, который Вы отправляете, уходит с сетевого интерфейса. Скажем, Ваша машина имеет 3 интерфейса: lo0 (loopback), xl0 (3com ethernet), и tun0 (туннель FreeBSD’s для работы с PPP), но Вы не хотите получать пакеты, приходящие на tun0?
block in quick on tun0 all
pass in all
В этом случае ключевое слово on будет означать входящие данные. Если пакет входит на tun0, первое правило блокирует его. Если пакет входит на lo0 или на xl0, первое правило не будет соответствовать, второе правило будет, пакет будет пропущен.
11. Совместное использование 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
12. Двунаправленная фильтрация. Ключевое слово «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 пакеты из Вашей сети.
Вы, вероятно, найдете много способов применить блокировку исходящих пакетов.
13. Регистрация событий. Ключевое слово «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
14. Полная двунаправленная фильтрация на интерфейсе
Пока мы только представили фрагменты законченного набора правил. Когда Вы пишете набор правил в реальных условиях, Вы должны установить правила для каждого интерфейса и каждого направления. По умолчанию, 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 от спуфинга или быть используемым для спуфинга. Будущие примеры также будут работать только с одним интерфейсом, что необходимо для краткости изложния, но при написанни Вашего собственного набора правил не забывайте добавлять правила для каждого направления и каждого интерфейса.
15. Управление протоколами. Ключевое слово «proto»
Атаки типа Denial of Service (Отказ в обслуживании) являются столь же распространенными, как и переполнение буфера. Множество таких атак полагаются на сбои в стеке TCP/IP операционной системы. Часто DoS атаки принимают форму ICMP пакетов. Почему бы не блокировать их полностью?
block in log quick on tun0 proto icmp from any to any
Теперь любой ICMP трафик, приходящий на tun0 будет зарегистрирован и отброшен.
16. Фильтрация 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 пакет никогда не до них не дойдет. Очень важно сохранить такие ситуации в памяти при объединении правил.
17. 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
18. Введение в расширенную фильтрацию
Этот раздел является продолжением предидущего, начального раздела. Ниже рассматриваются расширенные методы построения сетевой защиты и возможности, присущие только ipfilter. После освоения этого раздела Вы будете способны разработать очень сильную систему сетевой защиты.
19. Необузданная паранойя; или политика запрета по умолчанию
Есть большая проблема с блокированием сервисов по номерам портов: иногда номера портов изменяются. Программы базирующиеся на 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 правила.
20. Неявное разрешение. Правило «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.
21. 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
Ответный пает соответствует записи в таблице состояний и будет пропущен. После получения этого пакета запись будет удалена из таблицы и никакие другие паеты пропущены не будут, даже если у них будет прежний источник.
22. 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 сообщений, проверяется также не только адреса источника и назначения (и порты, когда это возможно), но и его содержимое.
23. Обнаружение 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 пакетов.
24. Ответ на блокированный пакет
Итак, до сего момента все получаемые пакеты пропускались или нет, регистрировались или нет, но не предпринимальось никаких действий, по извещению отправителя пакета. Иногда это может быть нежелательным, поскольку мы явно даем понять, что присуствует система защиты. Лучшим вариантом будет показать, что пакетный фильтр не установлен и нет никаких сервисов, к которым можно было бы получить доступ.
Когда на 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 сервера.
25. Представление о методах регистрации
Важно обратить внимание, что присутствие ключевого слова 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. Вы должны с осторожностью использовать эту опцию, так как есть опасность разрастания журнальных файлов, но польза этой функции при отладке сетевых приложений несомненна.
26. Объединение всего этого
Теперь у нас есть довольно сильная система сетевой защиты, но можно сделать ее еще крепче. Удаленная нами часть правил 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
27. Увеличение производительности с помощью групп правил
Давайте снова расширим наш набор правил, создавая намного более сложную и приближенную к реальному миру конфигурацию. В этом примере мы собираемся изменить число интерфейсов и их адреса. Предположим, что у нас имеется три интерфейса 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.
В зависимости от ситуации, может быть благоразумно группировать Ваши правила в соответствии с типом протокола, по сетевым блокам, интерфейсам и т.д.
28. Ключевое слово «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 и не стоит думать, что применение этого ключевого слова позволит увеличить скорость работы сетевой подсистемы. Эту возможность стоит применять в тех случаях, когда надо применить хитрость.
29. NAT и прокси
Вне корпоративной среды наиболее симпатичным применением системы сетевой защиты является подключение нескольких компьютеров через один общий интерфейс. Часто это случается даже без согласия провайдера. Для знакомых с Linux этот процесс называется IP Masquerading, но остальная мировая общественность использует понятие Network Address Translation или NAT. Если быть точным, то IPFilter обеспечивает то, что называют NPAT (Network and Port Address Translation). Это значит, что мы можем произвольно изменять и адреса и поры, NAT позволяет работать только с адресами.
30. Отображение нескольких 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
31. Отображение нескольких 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 адреса.
32. Отображение один к одному
Иногда бывает полезным иметь за системой сетевой защиты машину, адрес которой будет один к одному заменен. Сделать это позволяет ключевое слово 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.
33. Правила 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
34. Служба спуфинга
Служба спуфинга? Зачем это может быть нужно? Да масса просто примеров из жизни! Давайте представим, что у нас есть 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).
35. Поддержка прозрачных прокси. Польза перенаправления
Так как Вы устанавливаете систему сетевой защиты, Возможно Вы решите использовать прокси сервер, для перенаправления на него трафика с целью уменьшить количество правил фильтрации и в случае проблем с работой 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 и прозрачного проксирования, является очень полезным, когда Вам необходимо авторизовывать пользователей через прокси.
36. Фильтрация перенаправления
Довольно много пользователей захотят обьединить и фильтрацию и переадресацию с целью обеспечить связь с миром только известным хостам своей сети. Например, предоставим доступ к нашему 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, адрес и порт назначения пакета перезаписываются прежде, чем будут обработаны кодом фильтра.
37. Волшебство, скрытое в NAT. Прокси-серверы приложений
С тех пор, как в ipnat появилась возможность перезаписывать пакеты, он стал д