antiCisco blogs » Blog Archive » Zone Based Firewall

antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 19 Апрель , 2012

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:

  1. Определить зоны. Это делается с помощью команды zone security <ZONE_NAME>. Для каждой зоны можно задать описание (description).
  2. Определить зоновые пары. Это делается с помощью команды zone-pair security <ZONEPAIR_NAME> source <ZONE_SOURCE> destination <ZONE_DESTINATION>
  3. Определить карты классов (class-map), которые описывают трафик, к которому применяются политики фаирволла. В ZFW используется новый тип классовых карт classmap type inspect, который описывает область инспекции трафика.
  4. Определить карты политик (policy-map). В ZFW введен новый тип таких карт policymap type inspect. Вы применяете ранее определенные классовые карты к картам политик и назначаете действия, который должен сделать маршрутизатор с определенным выше трафиком (например пропустить или дропнуть).
  5. (Опционально) определить расширенные параметры политики: например ограничение количества TCP/UDP сессий. Более подробно различные сценарии мы с вами рассмотрим в отдельных статьях.
  6. Применить карты политик к зоновой паре. Делается это командой servicepolicy type inspect <POLICY NAME> в режиме конфигурирования зоновой пары, которую мы определили на шаге 2 данного алгоритма.
  7. Завести интерфейсы в зоны. Это последний шаг, который делается в режиме конфигурирования интерфейса командой zonemember security <ZONE NAME>

Определение классов трафика

Классовые карты инспекции могут быть двух типов: match-all и match-any, точно также, как и обычные карты в MQC. В первом случае, все условия match, которые заданы внутри карты, должны быть выполнены; во втором случае должно совпасть хотя бы одно условие.

Для выделения трафика по направлению вы можете использовать команду match accessgroup 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”, то необходимо убедиться, что обратный трафик также разрешен. Помимо выше сказанного, каждая карта политик имеет скрытый класс classdefault, для которого сконфигурировано действие “drop” (аналогично строке deny any any в любом списке доступа).

Изменение портов для инспектирования протоколов

Как было замечено раньше, ZFW поддерживает тот же набор протоколов, что и CBAC. Вы можете посмотреть стандартные порты того или иного протокола на котором он может инспектироваться командой show ip portmap. Если вам нужно изменить стандартный порт инспекции, используйте команду ip portmap <protocol>. Если вам нужно изменить стандартный порт только для определенных адресов (скажем для некоторых WEB-серверов), используйте команду ip portmap <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
 

Метки: , ,
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы

 

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

Вы должны войти чтобы прокомментировать.