Left, Right, Center Left, Center, Right Center, Left, Right

Академия

Мы -- официальная сетевая академия Cisco (ID: 20027250)

Хочешь сказать спасибо?

Нравится наш проект?

Хотите нас поддержать (сказать "спасибо")?

Можете воспользоваться для этого следующими кошельками webmoney

R432847347204

Z150172555537

Подписка на новости

Вопрос недели

В какое время Вам будет удобно заниматься?



 

Вход в систему







Забыли пароль?
Регистрация

Про виртуальные сети (часть 13). Cisco Zone-Based Forewall (ZFW) в виртуальной сети

Статьи

В прошлой статье из цикла о виртуальных сетях мы рассматривали один из очень надежных и важных механизмов безопасности – файрвол на основе инструмента CBAC (Context-Based Access Control). Фактически данный механизм помогает контролировать какому трафику разрешено проходить из доверенной части сети во внешнюю через файрвол и возвращаться обратно. Таким образом, сеть надежно защищена, потому что сессии могут быть инициированы только из доверенной части сети. На внешний интерейс мы можем повесить самый надежный список доступа (access-list): «access-list 101 deny ip any any». Для задач подключения небольшого офиса к сети Интернет такого функционала хватит. В то же время, если у нас появляется такая часть сети, как DMZ (DeMilitarized Zone), то сложность правил у нас возрастает и нам требуется более гибкий механизм, который будет учитывать аж 6 потоков трафика (inside – outside, outside – inside, inside – dmz, dmz – inside, outside – dmz, dmz – outside). Цель данной статьи познакомить Вас с таким механизмом и дать представление о его настройке в виртуальных сетях. Название его, а точнее аббревиатура, в разных источниках разная: это и Cisco ZBF, и Cisco ZFW. Полное же название его выглядит так: Cisco Zone-Based Firewall.

На самом деле, особой роли не играет, как Вы конкретно введете сокращение данной странице в поисковике. Все равно первая ссылка, которую Вам предложат, будет на официальный гайд Cisco, по настройке Cisco Zone-Based Firewall. Инструмент Cisco ZFW в своем основании имеет очень простую логику: сначала Вы определяете трафик по определенным параметрам (тип протокола, IP-адрес, ToS биты и т.д.), затем Вы определяете, что с этим трафиком делать (пропустить, инспектировать, отбросить). Точно такой же механизм обработки трафика присущ Cisco ASA и называется он там MPF (Modular Policy Framework). Конечно же, как и в большинстве других инструментов у Cisco, действует золотое правило: все, что явно не разрешено, все запрещено. Давайте рассмотрим, что необходимо для того, чтобы настроить Cisco ZFW в виртуальной сети, построенной на виртуальных маршрутизаторах VRF.

Физическая связность устройств для нашего примера выглядит следующим образом:

Логическая топология:

Как и в прошлой статье про CBAC, создание инфраструктуры, а именно самих виртуальных маршрутизаторов VRF, назначение им интерфейсов, IP-адресов и создание статических маршрутизаторов мы опустим. И опять же как в прошлой статье объектом нашего внимание будет виртуальный маршрутизатора VRF C, так как именно на нем мы будем настраивать Cisco Zone-Based Firewall (ZFW). Сразу оговоримся, что для целей нашего примера мы будем рассматривать только одно направление трафика: inside-outside. Для остальных направлений Вы сможете сделать настройку самостоятельно по аналогии.

Руководствуясь логикой, указанной в начале, сначала мы определим интересующий нас трафик. Например, мы хотим пропускать наружу трафик http, https, dns и icmp и создать условия для его возвращения. Определяется нужный трафик инструментом, который называется class-map и выглядит в нашем случае следующим образом:


R2#
!
class-map type inspect match-any in-out
match protocol http
match protocol https
match protocol dns
match protocol icmp
!

Пару слов про синтаксис команды. Тип class-map может быть разный, так как этот инструмент применяется не только для определения трафика для файрвола. Тем не менее, если мы говорим именно про Cisco ZFW, нам необходим тип class-map, который будет инспектировать «type inspect» проходящий трафик (мы ведь хотим разрешить ему возвращаться, верно?) Следующий параметр, это определение исполнения политики: «match-all» или «match-any». Он означает, проверяется ли class-map только до первого совпадения, или все условия должны быть выполнены. «in-out» - это просто название нашей class-map. Отметим еще один интересный момент: class-map поддерживает вложения, то есть class-map может включать в себя другие class-map в качестве правил «match».

Затем мы создаем собственно само правило, которое определяет, что делать с трафиком, выбираемым нам class-map:


R2#
!
policy-map type inspect trust_untrust
class type inspect in-out
inspect
class class-default
!

Аналогично, мы устанавливаем тип «type inspect» для всей политики, что означает, что она относится к политикам, которые проверяют трафик. После строчки «class type …» идет определение действия, которое мы делаем с трафиком. У нас стоит действие «inspect», что означает работу политики точно так же, как CBAC. Еще два действия, которые могут быть – это «allow» и «deny». Они, соответственно, разрешают проходящий трафик или его запрещают. «allow» разрешает трафик в одном направлении и не создает динамическую запись, которая разрешит обратный трафик. Основная задач при настройке файрвола Cisco ZFW заключается именно в настройке нужных class-map и policy-map, так как они и есть сами правила обработки трафика.

Дальше все очень просто: нам необходимо создать зоны (security zones), между которыми будет применяться политика.


R2#
!
zone security trust
zone security untrust
!

Затем мы привязываем интерфейсы к созданным зонам:


R2#
!
interface FastEthernet0/0.5
zone-member security trust
!
interface FastEthernet0/0.6
zone-member security untrust
!

Финальным штрихом будет применение самой политики, так как до сих пор она работала (так как не было определено, в каком направлении она должна работать). Важно отметить, что политики применяются именно между зонами, а не между интерефейсами.


R2#
!
zone-pair security policy_in_out source trust destination untrust
service-policy type inspect trust_untrust
!

Логика также здесь довольна тривиальная. Мы определяем зону, откуда трафик приходит «source trust» («trust» - имя зоны, которые мы задавали чуть ранее), и зону, куда трафик направляется «destination untrust». После этого мы указываем, какой набор правила применять к данному трафика командой «service-policy type inspect trust_untrust».

На этом все, настройка окончена. Сделаем пару простеньких тестов:


R1#ping vrf a 10.0.2.1 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 80 percent (5/5), round-trip min/avg/max = 88/103/112 ms

R1#ping vrf b 10.0.1.1 so lo 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.1
.....
Success rate is 0 percent (0/5)

Работает политика корректно: она пропускает наружу трафик, инициированный в доверенной зоне и ответ на него. В то же время, она не пропускает в доверенную сеть трафик, который инициируется из внешней сети.

Есть, правда, один нюанс, который необходимо учесть при настройке политики для направления outside-inside. В приведенной конфигурации, трафик, который адресован самому маршрутизатору из внешней сети разрешен:


R1#ping vrf b 10.0.0.2 so lo 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/52/60 ms

Соответственно, если мы хотим защитить сам маршрутизатор, нам это необходимо учесть.

Как Вы видите, в нашей настройке нигде название самого виртуального маршрутизатора не упоминалось. Это означает, что Cisco ZFW в виртуальной среде работает точно так же, как и в «реальной», и каких-то дополнительных настроек совершать не надо. Что, согласитесь, упрощает задачу настройки механизма безопасности Cisco ZFW для виртуальных маршрутизаторов.

Полный конфиг маршрутизаторов для данной работы по этой ссылке.

Удачи, друзья!

Пожалуйста, зарегистрируйтесь или войдите в систему для добавления комментариев к этой статье.
Share to Facebook Share to Twitter Share to Linkedin Share to Myspace Share to Google 
.