Фильтрация по группам интерфейсов

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

взаимодействия с соседними сетями прилагаемыми к основному шлюзу.

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

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

принадлежат к одной из групп по умолчанию. Для примера, все IEEE 802.11 беспроводные

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

# ifconfig sis2 group untrusted

Эквивалентно под OpenBSD могло бы в hostname.sis2 файле или ifconfig_sis2= строке в

rc.conf файле на FreeBSD 7.0 или более поздних версиях.

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

pass in on untrusted to any port $webports pass out on egress to any port $webports

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

Заметьте,  что  фильтрация  на  группах  интерфейсов  позволяет  писать  по  существу аппаратно-независимые наборы правил. Пока  ваш  hostname.if  файлы  или  ifconfig_if= вставлены строки с интерфейсами в правильные  группы, набор правил для постоянной фильтрации на группах интерфейсов  будут полностью переносимыми между машинами, которые могут или не могут иметь одинаковые аппаратные конфигурации. На системах где функция группа интерфейсов недоступна, вы можете быть в состоянии достичь некоторых

из тех же эффектов через создание использования макросов, вот так:

untrusted = "{ ath0 ath1 wi0 ep0 }" egress = "sk0"

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

К счастью, PF предлагает еще один механизм для классификации и фильтрации в виде

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

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

адресом  источника  равным  точке  доступа  $ext_if.  При  таком  сценарии,   полезным

дополнением к набру правил шлюза с несколькими из этих точек доступа  может быть следующее (при условии, конечно, что определения макросов  wifi_allowed и wifi_ports соответствуют требованиям сайта)

wifi = "{ 10.0.0.115, 10.0.0.125, 10.0.0.135, 10.0.0.145 }"

pass in on $int_if from $wifi to $wifi_allowed port $wifi_ports tag wifigood pass out on $ext_if tagged wifigood

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

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

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий