Zone-based firewall

Брандмауэр зональной политики (англ. 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].

Эта процедура может использоваться для настройки ZFW. Последовательность действий не важна, но все же некоторые действия должны быть выполнены по порядку. Например, прежде чем присваивать интерфейсы зонам, зоны нужно определить и настроить. Так же не получится применить к паре зон ненастроенную карту политик. ^[4]

1. Определить зоны (zone).
2. Присвоить интерфейсы зонам. ^[3]
3. Определить пары зон (zone-pair).
4. Определить карты классов (class-map), описывающие трафик, к которому будет применена политика при пересечении пары зон.
5. Определить карты политик (policy-map), где указано, какое действие нужно применять в отношении трафика карт классов.
6. Применить карты политик к парам зон.

Карты классов определяют трафик для применения политики. Сортировка трафика происходит с помощью команды match в карте классов (class-map) ^[4]

• Access-group — список контроля доступа может фильтровать трафик на основе IP-адреса источника и получателя, а также порта источника и получателя. ^[5]
• Protocol — протоколы транспортного уровня (TCP, UDP и ICMP) и службы приложения (например, DNS, HTTP и др.). ^[5]
• Class-map — подчиненная карта классов, представляющая дополнительные критерии соответствия, которые вложены в другую карту классов. ^[5]
• Not — критерий not указывает на то, что будет использоваться любой трафик, группа, протокол или карта классов.

Для определения порядка применения критериев соответствия в картах классов применяются операторы 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]

• Отбросить — это действие, применяемое ко всему трафику по умолчанию. Трафик отбрасывается ZFW'ом «бесшумно», то есть узел, от которого поступил трафик, не получает уведомления об отбрасывании. Такое поведение отличается от поведения, при использовании ACL, когда брандмауэр отправляет узлу, отправившему трафик, ICMP сообщение, что «узел недоступен». Однако, если требуется уведомление, при настройке можно указать параметр журнала, который позволит уведомить системный журнал о том, что трафик был отброшен брандмауэром. ^[8][9]
• Пропустить — трафик, переходящий из одной зоны в другую, пропускается. Если, например, трафик пропускается из первой зоны во вторую, то из второй зоны трафик не будет пропущен в первую, то есть действие «пропустить» работает только в одном направлении. Для разрешения перехода трафика из второй зоны в первую нужно провести соответствующую настройку. «Пропускание» будет полезно при использовании протоколов IPSec разных стандартов из-за предсказуемости их поведения. ^[8][9]
• Проверка — трафик проверяется на основании состояния. Например, если трафик идет из первой зоны во вторую, то брандмауэр сохраняет данные о подключении и о сеансе для трафика, использующего протоколы TCP или UDP. Значит брандмауэр автоматически разрешает и обратный трафик из второй зоны в первую, в ответ, например, на какие-нибудь запросы из первой зоны. Кроме того, можно настроить проверку приложения и управление протоколами службы передачи данных приложения, если передается что-то важное или уязвимое. Так же есть возможность сохранять время начала подключения, сеанса, окончания сеанса, продолжительность подключения, объем переданных данных, адреса отправителя и получателя. ^[8][9]

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

• HTTP
• SMTP
• POP3
• IMAP

и другими. ^[18][17]

Например, проверка 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]

• Alexandre Matos da Silva Pires de Moraes. Cisco Firewalls. — Cisco Press, 2011. — 912 с.
• Zone-Based Policy Firewall Design and Application Guide : Technical Support & Documentation - Cisco Systems. — 2010.
• Michel Ndabarasa. GNS3 and Cisco Zone-Based Policy Firewall – Part I.