Брандмауэр зональной политики (англ. Zone-Based Policy firewall или ZFW) — межсетевой экран, являющийся одним из компонентов программного обеспечения Cisco IOS. ZFW используется для настройки правил доступа между сетями. Предшественником ZFW был классический брандмауэр с контролем состояния (контроль доступа на основе содержимого или CBAC). Впервые zone-based firewall был представлен в Cisco IOS версии 12.4(6)T[1].
В ZFW (Zone-based firewall) вместо старой модели на основе интерфейсов используется модель на основе зон. При использовании ZFW не используются команды проверки с контролем состояния (CBAC). ZFW и CBAC могут использоваться на маршрутизаторе одновременно, но на разных интерфейсах. Зоны устанавливают границы безопасности сети, то есть определяют границу, где трафик, переходящий в другую часть вашей сети, разрешен ограничивающими политиками. В отличие от CBAC, где трафик неявно разрешен, пока не заблокирован явным образом, в ZFW по умолчанию переход трафика из одной зоны в другую запрещен. Брандмауэр решает пропускать или блокировать трафик на основе списка контроля доступа (ACL), то есть, чтобы трафик был разрешен, в списке должна быть соответствующая запись [2]. Так же особенность Cisco IOS в том, что возможности межсетевого экрана доступны прямо из маршрутизатора, а значит не нужно разворачивать специализированные брандмауэры такие, как, например, Cisco ASA или Juniper SRX [3].
CBAC следует применять, когда взаимодействуют два интерфейса. ZFW же следует использовать, когда есть несколько интерфейсов. При использовании CBAC генерируемый роутером трафик не проверяется по умолчанию. Основное неудобство CBAC в том, что нужно иметь политики проверки трафика на каждом интерфейсе, то есть CBAC настраивается для каждого интерфейса вручную. В ZFW достаточно настроить зоны и при необходимости добавлять туда интерфейсы. При наличии большого количества интерфейсов настроить зоны оказывается быстрее, чем настраивать каждый интерфейс [3].
| CBAC | ZFW |
|---|---|
| Настройка на основе интерфейса | Настройка на основе зон |
| Управление входящим и исходящим доступом к интерфейсу | Управление доступом между зонами в двух направлениях |
| Настройка роутеров с более чем двумя интерфейсами может стать достаточно сложной | Простая настройка роутеров с более чем двумя зонами |
| Используются списки доступа с сохранением состояния | Используется основанный на политике классов Cisco Common Classification Policy Language |
| Проверка и контроль на уровне приложения не поддерживается | Поддерживается проверка и контроль на уровне приложения [3] |
Эта процедура может использоваться для настройки ZFW. Последовательность действий не важна, но все же некоторые действия должны быть выполнены по порядку. Например, прежде чем присваивать интерфейсы зонам, зоны нужно определить и настроить. Так же не получится применить к паре зон ненастроенную карту политик. [4]
Карты классов определяют трафик для применения политики. Сортировка трафика происходит с помощью команды match в карте классов (class-map) [4]
Для определения порядка применения критериев соответствия в картах классов применяются операторы match-any или match-all. Если выбрано match-any, то трафик должен удовлетворять только одному из критериев соответствия. Если выбрано match-all, то трафик должен удовлетворять всем критериям карты классов. Сначала должны применяться более конкретные критерии соответствия, затем — более общие. [5][6]
Например,
class-map type inspect match-any [class-map_name] match protocol http match protocol tcp
Здесь трафик будет сравнен с протоколом соответствия http и будет обрабатываться специфическими для службы средствами проверки HTTP. Если же поменять строки местами, то трафик будет обработан средствами проверки tcp, то есть будет классифицироваться просто, как трафик TCP. [6]
ACL могут использоваться для поиска соответствий для применения политики. Если ACL является единственным критерием соответствия карты классов, связанной с картой политик, то маршрутизатор выполнит проверку TCP или UDP для всего трафика, разрешенного списком, не беря в расчет трафик, для которого предусмотрена проверка с учетом приложения. Если доступна проверка с учетом приложения, то трафик разрешается независимо от того, разрешен ли трафик в ACL. [7]
Например ACL 101,
access-list 101 permit ip any any
Здесь трафик примененный к заданной зонной паре разрешен в обоих направлениях. [7]
Карта политик применяет действия к одной или нескольким картам классов, чтобы определить политику, которая будет применена к зонной паре безопасности. При создании карты политик создается класс по умолчанию (class-default). По умолчанию политика класса class-default выполняет действие «отбросить», но его можно заменить на «пропустить». [10]
Настройка карты политик происходит из режима глобальной конфигурации. В картах политик действия связаны с картой классов: [9]
conf t
policy-map type inspect [zone1-zone2-policy-map_name]
class type inspect [class-map_name]
inspect|drop|allow [parameter-map_name]
В parameter-map (или в карте параметров) настраивают проверки, относящиеся к DoS-атакам, таймерам подключения TCP и сеанса UDP и др. Карта параметров так же применяется к картам классов и картам политик прикладного уровня (например, объекты HTTP). [11]
Настройка карты параметров так же происходит из режима глобальной конфигурации: [12]
conf t parameter-map type inspect [zone1-zone2-parameter-map_name]
В карте параметров типа regexp определяется регулярное выражение, которое будет использовано при фильтрации трафика при проверке приложения HTTP: [12]
parameter-map type regex [parameter-map_name]
В карте параметров типа protocol-info определяются названия серверов при обмене мгновенными сообщениями: [12]
parameter-map type protocol-info [parameter-map_name]
Для отбрасываемого трафика доступно логирование. Чтобы включить логирование, следует в карту политик добавить карту параметров с действием отбрасывания. [12]
Начиная с версии 12.1(5)T, в Cisco IOS добавлена возможность ограничения скорости трафика путем ограничения номинальной скорости и размера пакета. А с версии 12.4(9)T в ZFW добавлена функция регулировки трафика, совпадающая с тем, что определено в конкретной карте классов. Здесь предлагается описывать трафик, применять политику ZWF и регулировать полосу пропускания из одной точки конфигурации, вместо конфигурирования каждого интерфейса по отдельности. [13]
При помощи ZFW можно указать полосу пропускания в байтах в секунду или в битах в секунду, однако установить процент пропускания не удастся. Применять регулирование скорости можно как совместно с настройкой каждого интерфейса, так и по отдельности. [13][14]
ZFW, заметив значительные изменения сетевой активности, оповещает инженеров и снижает нежелательную сетевую активность, чтобы снизить ее воздействие на маршрутизатор. Для этого в ZFW встроены счетчики для каждого класса. [15]
Существует возможность ограничить трафик сеанса, можно также ограничить количество сеансов для заданной карты классов, которая, например, пересекает пару зон. Это дополнение к существующей возможности применять защиту от DoS-атак. [16]
Объем данных сеанса указывается в карте параметров. Далее карта параметров присоединяется к действию брандмауэра при настройке карты политик: [17]
parameter-map type inspect [my-parameters] sessions maximum [1-2147483647] policy-map type inspect [private-allowed-policy] class type inspect http-class inspect [my-parameters]
За подробными примерами настройки брандмауэра против DoS-атак следует обратиться к официальной документации. [15]
Приложения прикладного уровня модели OSI могут отправлять и принимать сообщения, связанные как с нежелательными уязвимостями, так и с полезными возможностями, а значит, следует ограничить действия служб приложений, то есть фильтровать сообщения. [18][17]
ZFW позволяет управлять службами следующих приложений:
Например, проверка SMTP ограничивает длину содержимого, чтобы удовлетворять стандартам протокола. [18][17]
Проверка приложения настроена, как набор карт классов и политик, которые потом применяются к существующим картам классов и политик. [18][17]
ZFW может фильтровать URL-адреса, создавая «белые» и «черные» списки. [19]
Настройка происходит в карте параметров с параметром urlfilter: [19]
parameter-map type urlfilter [websense-parmap_name] exclusive-domain deny [domain_name_1] exclusive-domain permit [domain_name_2]
В строке deny определены запрещенные url-адреса, а в строке permit — разрешенные. [19]