Zone Based Firewall (здесь и далее ZFW) – новое направление на маршрутизаторах под управлением операционной системы Cisco IOS для конфигурирования правил доступа между сетями. До появления этой технологии трафик фильтровался с помощью списков доступа ACL и динамической инспекции трафика (CBAC). И ACL и правила CBAC’а применялись непосредственно на физические интерфейсы, что во многих случаях не способствует масштабируемости и гибкости решения.
В ZFW появляется новое ключевое понятия – зона, которая состоит из набора различных интерфейсов, которые должны иметь одинаковую политику сетевой безопасности (или, иначе говоря, одинаковый уровень доверия). На рисунке, вы можете увидеть три зоны безопасности, назначенные на различные интерфейсы маршрутизатора:
Разрешения для прохождения того или иного трафика делаются между зонами, не между интерфейсами. По умолчанию, трафик разрешен между интерфейсами одной зоны безопасности и запрещен между разными зонами. Трафик между интерфейсом, который относится к какой-либо зоне, и интерфейсом, который не относится ни к одной зоне, запрещен. В дополнение ко всему, вы не можете применять классические правила фаирволла (CBAC, ACL) к интерфейсу, который принадлежит какой-либо зоне безопасности.
Существует одна зона, которая есть на всех маршрутизаторах и создана по-умолчанию и известна как self-зона. К этой зоне относятся все IP-адреса маршрутизатора. Трафик между self-зоной и любой другой по-умолчанию разрешен. Однако, вы можете применить политику между self-зоной и любой другой чтобы контролировать трафик, который генерируется маршрутизатором. Если вы примените политику от любой зоны к self-зоне, то трафик от self-зоны в обратном направлении будет все равно разрешен (пока вы явно это не запретите).
Когда вы хотите применить политики к трафику, который проходит между зонами, необходимо помнить одно важное правило: политики применяются к зоновой паре (zone pair). При этом, пара зон {A,B} это не тоже самое, что {B,A}. Первая зона в паре называется зоной-источником (source zone), вторая зоной назначения (destination zone). Когда вы применяете политику фаирволла к зоновой паре, она применяется к трафику который «бежит» от зоны-источника к зоне назначения.
Для применения политик ограничения/разрешения трафика, ZFW использует новый язык конфигурации, называемый Cisco Policy Language (CPL). Синтаксис CPL был полностью позаимствован от широко-известного MQC (Modular QoS CLI). Ниже представлен краткий обзор шагов конфигурации ZFW:
- Определить зоны. Это делается с помощью команды zone security <ZONE_NAME>. Для каждой зоны можно задать описание (description).
- Определить зоновые пары. Это делается с помощью команды zone-pair security <ZONEPAIR_NAME> source <ZONE_SOURCE> destination <ZONE_DESTINATION>
- Определить карты классов (class-map), которые описывают трафик, к которому применяются политики фаирволла. В ZFW используется новый тип классовых карт class—map type inspect, который описывает область инспекции трафика.
- Определить карты политик (policy-map). В ZFW введен новый тип таких карт policy—map type inspect. Вы применяете ранее определенные классовые карты к картам политик и назначаете действия, который должен сделать маршрутизатор с определенным выше трафиком (например пропустить или дропнуть).
- (Опционально) определить расширенные параметры политики: например ограничение количества TCP/UDP сессий. Более подробно различные сценарии мы с вами рассмотрим в отдельных статьях.
- Применить карты политик к зоновой паре. Делается это командой service—policy type inspect <POLICY NAME> в режиме конфигурирования зоновой пары, которую мы определили на шаге 2 данного алгоритма.
- Завести интерфейсы в зоны. Это последний шаг, который делается в режиме конфигурирования интерфейса командой zone—member security <ZONE NAME>
Определение классов трафика
Классовые карты инспекции могут быть двух типов: match-all и match-any, точно также, как и обычные карты в MQC. В первом случае, все условия match, которые заданы внутри карты, должны быть выполнены; во втором случае должно совпасть хотя бы одно условие.
Для выделения трафика по направлению вы можете использовать команду match access—group name <ACL NAME> (это единственный способ выделить трафик от конкретного источника к конкретному получателю).
В дополнение к спискам доступа, вы можете выделять протоколы, которые поддерживаются модулем инспекции маршрутизатора (inspection engine). Список поддерживаемых протоколов такой же как у технологии CBAC. Однако, в противовес классическим классовым картам, когда вы вводите команду match protocol (для просмотра всех протоколов, которые поддерживаются для команды match, можно использовать команду show ip port-map), вы не включаете процесс NBAR’а – скорее протокол для инспекции будет выбран когда карта политики будет применена к зоновой паре. Довольно часто комбинируют «отлов» трафика по спискам доступа и протоколам, например:
class-map type inspect match-all CLASS_HTTP-INSIDE match access-group ACL_INSIDE match protocol httpвыше приведенная конструкция отловит HTTP-трафик от пользователей, который находятся в INSIDE-сети (согласно списку доступа).
Кроме того, вы можете использовать вложенные классовые карты – это может быть полезно, когда необходимо применить комплексную логику И/ИЛИ. Например: вы хотите выбрать набор протоколов (HTTP, DNS, ICMP) для определенной группы пользователей. Итоговый результат будет выглядеть следующим образом:
ip access-list extended ACL_INSIDE permit ip 10.1.1.0 0.0.0.255 any class-map type inspect match-any CLASS_IN-OUT-PROTOCOLS match protocol http match protocol dns match protocol icmp class-map type inspect match-all CLASS_IN-OUT match access-group name ACL_INSIDE match class-map CLASS_IN-OUT-PROTOCOLSПрименение политик
Существует три основных действия, которые применимы для инспектирующих карт политик: “inspect”, “drop” и “pass”. Первое действие (inspect) аналогично правилу CBAC-инспекции. Оно включает динамическую инспекцию для трафика, который бежит от зоны источника к зоне назначения и автоматически разрешает обратный трафик даже для сложны протоколов, таких как H323. Действие “drop” просто отбрасывает трафик, а “pass” пропускает не включая инспекцию протокола (аналогично строчке “permit” в списке доступа). Пример команды:
policy-map type inspect POLICY_IN-OUT class type inspect CLASS_IN-OUT inspectПрим.: если вы используете “inspect” в карте политик, то классовые карты должны содержать хотя бы одно “match protocol” условие для определения того, какой протокол необходимо инспектировать. В противном случае будут инспектироваться все поддерживаемые протоколы. Если вы используете действие типа “pass”, то необходимо убедиться, что обратный трафик также разрешен. Помимо выше сказанного, каждая карта политик имеет скрытый класс class—default, для которого сконфигурировано действие “drop” (аналогично строке deny any any в любом списке доступа).
Изменение портов для инспектирования протоколов
Как было замечено раньше, ZFW поддерживает тот же набор протоколов, что и CBAC. Вы можете посмотреть стандартные порты того или иного протокола на котором он может инспектироваться командой show ip port—map. Если вам нужно изменить стандартный порт инспекции, используйте команду ip port—map <protocol>. Если вам нужно изменить стандартный порт только для определенных адресов (скажем для некоторых WEB-серверов), используйте команду ip port—map <protocol> port <port> list <ACL>. Например:
access-list 1 permit ip 10.1.1.0 0.0.0.255 ip port-map http tcp 8080 list 1выше приведенные команды добавят инспектирование протокола HTTP по порту 8080 для адресов из диапазона 10.1.1.0/24.
Self-зона маршрутизатора
Политики, которые могут быть применены относительно self-зоны маршрутизатора имеют некоторые ограничения. Во-первых, динамическая инспекция для трафика, который сгенерирован самим маршрутизатором, ограничена протоколами TCP, UDP, ICMP и H323. Инспекция протоколов на уровне приложений (HTTP, TELNET и пр.) не поддерживается. Во-вторых, ограничение по количеству сессий и по полосе также не может быть сконфигурировано.
Рассмотрим пример: нам требуется разрешить только SSH-трафик на машрутизатор. Сделать это можно следующим образом:
ip access-list extended ACL_SSH-SELF permit tcp any any eq 22 class-map type inspect CLASS_OUT-SELF match access-group name ACL_SSH-SELF policy-map type inspect POLICY_OUT-SELF class type inspect CLASS_OUT-SELF pass zone-pair security ZONEP_OUT-SELF source OUTSIDE destination self service-policy type inspect POLICY_OUT-SELFПрим.: после примененной выше конфигурации, весь трафик кроме SSH будет отброшен. Если вы используете, например, протоколы маршрутизации OSPF, EIGRP, то они должны быть явно разрешены – т.к. инспекция этих протоколов не поддерживается.
ip access-list ACL_ROUTING permit ospf any any permit eigrp any any class-map type inspect CLASS_ROUTING match access-group name ACL_ROUTING policy-map type inspect POLICY_OUT-SELF class type inspect CLASS_ROUTING pass
Метки: firewall, ZBFW, ZFW
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы
» Оставить комментарий
Вы должны войти чтобы прокомментировать.