Сделать домашней|Добавить в избранное
 

CCIENetLab - Подготовка к экзаменам
CCNA, CCNP и CCIE

 
» » Zone Based Firewall (ZBF) на Cisco маршрутизаторах

Zone Based Firewall (ZBF) на Cisco маршрутизаторах

Автор: Sauron от 21-06-2015, 13:32
Zone Based Firewall (ZFW) – новое направление на маршрутизаторах под управлением операционной системы Cisco IOS для конфигурирования правил доступа между сетями. До появления этой технологии трафик фильтровался с помощью списков доступа ACL и динамической инспекции трафика Context-Based Access Control (CBAC). И ACL и правила CBAC’а применялись непосредственно на физические интерфейсы, что во многих случаях не способствует масштабируемости и гибкости решения. Весь трафик, проходящий через интерфейс, получал ту же самую инспекционную политику. Такая модель конфигурации ограничивает степень детализации политик межсетевого экрана и вызывает путаницу правильного применения политики межсетевого экранирования, особенно в сценариях, когда политика межсетевого экрана должна применяться между несколькими интерфейсами.
Zone Based Firewall меняет конфигурацию межсетевого экрана от старой интерфейсной модели на более гибкую, более понятную модель, на основе зон безопасности.

Зона безопасности состоит из набора различных интерфейсов, которые должны иметь одинаковую политику сетевой безопасности или, иначе говоря, одинаковый уровень доверия. После этого все правила настраиваются для взаимодействий между зонами. Такой подход облегчает настройки правил межсетевого экрана. Кроме того в Zone-Based Policy Firewall используется Cisco Policy Language (CPL), которая позволяет более гибко, чем в предыдущих версиях межсетевого экрана, настраивать правила фильтрации трафика.
Зона устанавливает границы безопасности вашей сети. Зона определяет границу, где трафик является предметом ограничения со стороны политики, как только он уходит в другую область вашей сети.

На рисунке, вы можете увидеть три зоны безопасности, назначенные на различные интерфейсы маршрутизатора:

Zone Based Firewall (ZBF)  на Cisco маршрутизаторах

По умолчанию, трафик разрешен между интерфейсами одной зоны безопасности и запрещен между разными зонами. Трафик между интерфейсом, который относится к какой-либо зоне, и интерфейсом, который не относится ни к одной зоне, запрещен. В дополнение ко всему, вы не можете применять классические правила межсетевого экранирования (CBAC, ACL) к интерфейсу, который принадлежит какой-либо зоне безопасности.
Существует одна зона, которая есть на всех маршрутизаторах и создана по-умолчанию и известна как self-зона. К этой зоне относятся все IP-адреса маршрутизатора. Трафик между self-зоной и любой другой, по-умолчанию, разрешен. Однако, вы можете применить политику между self-зоной и любой другой чтобы контролировать трафик, который генерируется маршрутизатором. Если вы примените политику от любой зоны к self-зоне, то трафик от self-зоны в обратном направлении будет все равно разрешен (пока вы явно это не запретите).

Когда вы хотите применить политики к трафику, который проходит между зонами, необходимо помнить одно важное правило: политики применяются к зоновой паре (zone pair). При этом, пара зон {A,B} это не тоже самое, что {B,A}. Первая зона в паре называется зоной-источником (source zone), вторая зоной назначения (destination zone). Когда вы применяете политику межсетевого экранирования к зоновой паре, она применяется к трафику который «бежит» от зоны-источника к зоне назначения.

Правила для применения ZBF

Сетевые интерфейсы маршрутизатора которые принадлежат зонам являются объектами ряда правил, которые регулируют поведение интерфейса, при движении трафика между этими интерфейсами:
  • Прежде чем интерфейсы могут быть назначены зоне безопасности, последняя должна быть сконфигурирована.
  • Любой интерфейс может быть назначен только одной зоны безопасности.
  • Любой зона может принадлежать один или несколько интерфейсов
  • В пределах зоны по умолчанию разрешен весь трафик
  • Между зонами по умолчанию политика – deny any any
  • Трафик предназначенный маршрутизатору или сгенерированный им разрешен по умолчанию
  • Трафик не может протекать между интерфейсом, который принадлежит зоне и любым интерфейсом, который не принадлежит никакой зоне. Иначе говоря, если один из интерфейсов принадлежит к какой-либо зоне, другой нет - трафик запрещен
  • Интерфейсы, которые не были назначены в зоны функционируют как классические порты маршрутизатора и, могут все еще использовать CBAC.


Порядок настройки ZBF
  1. Создать зоны
  2. Создать пары зон
  3. Определить классы (class-map) трафика, к которому применяются политики межсетевого экранирования
  4. Определить политику межсетевого экранирования, которая указывает какие действия будут применяться к трафику
  5. Применить политику межсетевого экранирования к зоновой паре
  6. Добавить интерфейсы в зону


Создание зон и пар зон

Зоны создаются с помощью команды zone security
zone security IN
zone security OUT
zone security DMZ


Зонные пары создаются с помощью команды

zone-pair security NAME source FROM-ZONE destination TO-ZONE

Пример:
zone-pair security IN_OUT source IN destination OUT
zone-pair security OUT_IN source OUT destination IN
zone-pair security OUT_DMZ source OUT destination DMZ


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

Class-map определяют трафик который выбирает межсетевой экран для применения политики безопасности. Трафик может быть отсортирован по следующим критериям, которые могут быть указаны в команде match:
  • access-group - стандартный, расширенный или именованный ACL который может фильтровать трафик на основании IP адреса-порта источника и приемника. Это единственный способ выделить трафик от конкретного источника к конкретному получателю.
  • Protocol - это протоколы уровня 4 (TCP, UDP, ICMP), а также прикладные сервисы, такие как HTTP, SMTP, DNS, и т.д. Может быть указан любой известный или определяемый пользователем сервис.
  • Class-map - подчиненный класс, который предоставляет дополнительные критерии соответствия может быть вложен в другой класс
  • Not - определяет, что любой трафик, который не соответствует указанному сервису или протоколу или листу доступа будет выбран в данном class-map.

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

Например, рассмотрим следующую класс-карту
class-map type inspect match-any my-test-cmap
 match protocol http
 match protocol tcp

HTTP-трафик должен встретить сперва match protocol http, чтобы быть уверенным, что трафик обрабатывается HTTP инспекцией. Если же строчки в класс-карте поменять местами, то HTTP трафик попадет под match protocol tcp и такой трафик будет классифицирован как TCP трафик и будет инспектироваться в соответствие с возможностями инспекционного TCP движка.

Список поддерживаемых протоколов такой же как у технологии CBAC. Однако, в противовес классическим классовым картам, когда вы вводите команду match protocol, вы не включаете процесс NBAR – скорее протокол для инспекции будет выбран когда карта политики будет применена к зонной паре

Примеры class-map:
class-map type inspect match-any OUT_protocols
 match protocol http
 match protocol ssh
 match protocol telnet
!
class-map type inspect match-all IN_to_DMZ_SSH
 match access-group name IN_TO_DMZ
 match protocol ssh
!
class-map type inspect OSPF
 match access-group name OSPF
!
class-map type inspect match-all IN_OUT
 match class-map OUT_protocols
 match access-group name IN_to_remote_OUT
!


Определение политик межсетевого экранирования

Команда policy-map определяет действие, которое будет произведено с отфильтрованным с помощью команды class-map трафиком. Существует три основных действия, которые применимы к классифицированному трафику:
  • Drop - Трафик обрабатываемый этим действием слепо отбрасывается и никакого уведомления на удаленных хост не высылается. В противоположность классическим листам доступа (ACL), когда высылается ICMP Host Unreachable. В настоящий момент нет возможности менять поведение действия Drop.
    Помимо выше сказанного, каждая карта политик имеет скрытый класс class-default, для которого сконфигурировано действие “drop” (аналогично строке deny any any в любом списке доступа).
  • Pass – Пропускает трафик не включая инспекцию протокола. Это действие позволяет маршрутизатору пересылать трафик из одной зоны в другую, при этом он не е отслеживает состояние соединений или сессий. Это действие разрешает прохождение трафика только в одном направлении. Чтобы обратный трафик пройти в обратном направлении, должна быть соответствующая политика для него. Это действие полезно для таких протоколов, как IPSec ESP, IPSec AH, ISAKMP и других по своей сути безопасных протоколов с предсказуемым поведением.
  • Inspect - Включает динамическую инспекцию для трафика, который проходит от зоны источника к зоне приемника и автоматически разрешает обратный трафик даже для сложны протоколов, таких как H323. Например, если трафик из зоны Private в зону Internet, маршрутизатор поддерживает информацию о соединениях или сеансах для TCP и UDP трафика. Поэтому маршрутизатор разрешает обратный трафик из зоны Internet в зону Private в качестве ответов на запросы соединений из Private в Internet.


Примеры policy-map
policy-map type inspect IN_OUT_policy
 class type inspect IN_OUT
  inspect
!
policy-map type inspect OUT_to_DMZ_policy
 class OUT_to_DMZ
  inspect
!
policy-map type inspect IN_to_SELF_policy
 class OSPF
  pass
 class IN_to_SELF
  inspect
 class class-default
  drop log
!


ZBF предлагает опцию логирования для трафика, который отбрасывается или инспектируется.

ZBF не поддерживает редактирование своих структур на лету, таких как policy-map, class-map и parameter-map. Для того, чтобы внести изменения в класс определяющий трафик или действие для классифицированного трафика необходимо скопировать существующую ZBF-структуру команда в текстовый редактор, полностью удалить конфигурацию ZBF с маршрутизатора, сделать необходимые изменения в скопированной конфигурации и повторно залить на маршрутизатор.

Применение политик межсетевого экранирования

Применение созданной политики межсетевого экранирования осуществляется командой service policy. Через нее мы привязываем policy-map к определенной паре зон в одном направлении.

Для двух зон можно применить только одну service policy в одном направлении и, соответственно, одну в обратном направлении. Если действие с трафиком определено как inspect, то запросы будут контролироваться таким образом, что в обратную сторону будут разрешены ответы на эти запросы. Если действие определено как пропускать трафик, то контролироваться ничего не будет и ответы на этот трафик проходить не будут (если это не разрешено политикой между зонами в обратную сторону).

Примеры:

zone-pair security IN_OUT source IN destination OUT
 service-policy type inspect IN_OUT_policy
!
zone-pair security IN_DMZ source IN destination DMZ
 service-policy type inspect IN_to_DMZ_policy


Политика Self-зоны маршрутизатора

Политики, которые могут быть применены относительно self-зоны маршрутизатора имеют некоторые ограничения.
Во-первых, динамическая инспекция для трафика, который сгенерирован самим маршрутизатором, ограничена протоколами TCP, UDP, ICMP и H323. Инспекция протоколов на уровне приложений (HTTP, TELNET и пр.) не поддерживается.

Во-вторых, ограничение по количеству сессий и по полосе также не может быть сконфигурировано. Если вы используете, например, протоколы маршрутизации OSPF, EIGRP, то они должны быть явно разрешены – т.к. инспекция этих протоколов не поддерживается.

Добавление интерфейсов в зону межсетевого экранирования

Интерфейсы добавляются в зону командой zone-member security в настройках интерфейса маршрутизатора.
Пример:
interface Ethernet0/0
  zone-member security PRIVATE


Пример конфигурации ZBF

Теперь перейдем к самому интересному, к настройке. Рассмотрим следующую топологию.

Zone Based Firewall (ZBF)  на Cisco маршрутизаторах

В левой стороне от роутера R2 находится внутренняя сеть с HTTP сервером, в правой части выход в Интернет. В этой простой конфигурации мы будем использовать только две зоны. Одну для нашей внутренней сети (PRIVATE), а другую для внешней (PUBLIC). Мы создадим класс для всего TCP и UDP трафика, который будем использовать в политике для инспектирования.

Конфигурация R2:
hostname R2
!
! Создаем класс трафика описывающий весь TCP и UDP
class-map type inspect match-any TCP_UDP
 match protocol tcp
 match protocol udp
!
! Создаем инспекционную политику и указываем, что для созданного ранее класса
! будем выполнять инспекцию.  Весь остальной трафик по умолчанию отбрасывается
policy-map type inspect PRIVATE_PUBLIC_POLICY
 class type inspect TCP_UDP
  inspect 
 class class-default
  drop
!
! Создаем две зоны
zone security PRIVATE
zone security PUBLIC
!
! Создаем зонную пару и применяем инспекционную политику
zone-pair security PRIVATE_PUBLIC source PRIVATE destination PUBLIC
 service-policy type inspect PRIVATE_PUBLIC_POLICY
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface Ethernet0/0
 ip address 24.234.12.2 255.255.255.0
 zone-member security PRIVATE
!
interface Ethernet0/1
 ip address 24.234.23.2 255.255.255.0
 zone-member security PRIVATE
!
interface Serial1/0.1 point-to-point
 ip address 24.234.245.2 255.255.255.0
 zone-member security PUBLIC
 frame-relay interface-dlci 205   
!


Интерфейсы Ethernet0/0 и Ethernet0/1 поместим в зону PRIVATE, а интерфейс Serial1/0.1 в зону PUBLIC. Между зонами PRIVATE и PUBCLIC осуществляется инспекция всего TCP и UDP трафика. Инспекция ICMP трафика не осуществляется. Конфигурация динамической маршрутизации опущена, равно как и конфигурация остальных маршрутизаторов, так как для данного примера она не существенна.

Проверим работу ZBF на R2 и выполним telnet и ping на маршрутизатор R5 с маршрутизатора R1

Zone Based Firewall (ZBF)  на Cisco маршрутизаторах

Видим, что мы без проблем создаём TCP соединения через маршрутизатор R2, но трафик ICMP не проходит. Команда show policy-map type inspect zone-pair показывает статистику работы ZBF в реальном времени.

Zone Based Firewall (ZBF)  на Cisco маршрутизаторах

Так же можно посмотреть текущие сессии установленные через маршрутизатор. Например в приведенном выше выводе видим установленное TCP TELNET соединение с R1 в строну R5. Так как ICMP трафик у нас не классифицируется , он попадает по умолчанию попадает в class class-default и отбрасывается.
Выполним для ICMP Трафика инспектирование, но ограничим его движение между зонами PRIVATE и PUBLIC со скоростью 8K.
!
class-map type inspect match-all ICMP_CLASS
 match protocol icmp
policy-map type inspect PRIVATE_PUBLIC_POLICY
class type inspect ICMP_CLASS
  inspect 
  police rate 8000 burst 2000
!

Попробуем выполнить команду ping на роутере R1 в строну R5

Zone Based Firewall (ZBF)  на Cisco маршрутизаторах

Мы видим, что при отсылке 100 пакетов, 9 из них были отпрошены на R2 – это пакеты которые что не влезли в указанную полосу. Выполним еще раз команду show policy-map type inspect zone-pair PRIVATE_PUBLIC sessions на R2:

Zone Based Firewall (ZBF)  на Cisco маршрутизаторах

Здесь мы видим как работал наш ограничитель для ICMP трафика. В поле conformed указано что 192 пакета попали в 8Kbit-полосу. Но мы посылали 100 пакетов , а откуда взялась цифра 192?

Все просто. Мы посылали 100 ICMP Echo Request пакетов в строну R5, на каждый ICMP Request, маршрутизатор R5 отвечал ICMP Echo Reply. Если бы ICMP трафик не был ограничен 8Kbit полосой, то R2 посчитал бы 200 пакетов, которые прошли через него – 100 ICMP запросов и 100 ICMP ответов. Но так как есть ограничения для этого трафика, то 9 пакетов были убиты - exceeded 9, и до R2 дошли только 91 запрос, что дало 91 ответ. Итого 182. Но перед тем как делать 100-пакетный тест, мы сделали стандартный 5-пакетный ICMP тест, который полностью попал в полосу.

Мы можем включить журналирование, чтобы видеть создание и завершение сессии для трафика, проходящего через маршрутизатор. Это делается с помощью команды parameter-map

Непосредственно в parameter-map указываются параметры которые влияют на поведение ZBF, такое как защита от DoS атак, таймеры для TCP и UDP сессий, логирование и т.д. Далее указнные параметры применяются в политиках для L3/L4 и L7 – классов трафика. Ниже приведем простой пример включение логирования сессий.

parameter-map type inspect ZONE_PARAMETERS
 audit-trail on
policy-map type inspect PRIVATE_PUBLIC_POLICY
 class type inspect TCP_UDP
  inspect ZONE_PARAMETERS
!

В данном примере, поведение инспектирования TCP и UDP трафика было изменено применением параметра, такого как логирование (audit-trail on). Теперь когда создаются и завершаются сесии, R2 будет логировать эти события и выдавать сообщения:

Jun 21 09:47:48.052: %FW-6-SESS_AUDIT_TRAIL_START: (target:class)-(PRIVATE_PUBLIC:TCP_UDP):Start tcp session: initiator (24.234.12.1:54529) -- responder (5.5.5.5:23)
Jun 21 09:47:57.170: %FW-6-SESS_AUDIT_TRAIL: (target:class)-(PRIVATE_PUBLIC:TCP_UDP):Stop tcp session: initiator (24.234.12.1:54529) sent 49 bytes -- responder (5.5.5.5:23) sent 98 bytes

В первом сообщении указывается что произошло создание TCP сессии от R1 в строну R5 на порт 23. При этом указывается зонная пара PRIVATE_PUBLIC и класс трафика (TCP_UDP) под который попало данное соединение.

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

Комментарии:

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

CCIENetLab (C)