IOS Zone-Based Firewall (ZBF)
Firewall средствами Cisco IOS, поддерживается на маршрутизаторах серии ISR с лицензией Security.
Предшественником ZBF был CBAC (Context-Based Access Control).
Интерфейсы маршрутизатора делятся на зоны (Zones). Зона (Zone) — логическая область с точки зрения маршрутизатора, в которой все устройства имеют общий уровень доверия и подчиняются одним правилам.
Зоны создаются администратором, после чего интерфейсы маршрутизатора помещаются в зоны. Один или несколько интерфейсов маршрутизатора могут находится в одной зоне. Каждый отдельный интерфейс может находится только в одной зоне.
Прохождение трафика с одной зоны в другую определяется созданными политиками.
Default Zone (Self-zone) — особый тип зоны маршрутизатора (есть по умолчанию), в которой находится только сам маршрутизатор (его Control Plane). Трафик, направленный на любой IP адрес самого маршрутизатора, либо сгенерированный с него, входит или соответственно покидает Self-zone.
Для Self-zone поддерживается инспекция (Inspect) только следующих протоколов: TCP, UDP, ICMP, H.323.
Правила поведения между зонами по умолчанию:
1) Трафик, входящий в (или покидающий) Self-zone разрешен!
2) Трафик, проходящий между интерфейсами, находящимися в одной зоне разрешен!
3) Трафик, проходящий между интерфейсами, не принадлежащими каким-либо зонам, разрешен!
4) Трафик, проходящий между интерфейсами разных зон запрещен!
5) Трафик, проходящий между интерфейсами, только один из которых является членом какой-либо зоны запрещен!
Для того, чтобы разрешить прохождение трафика между интерфейсами, находящимися в разных зонах, необходимо создать разрешающую политику (Service Policy) для каждой пары зон — т.н. Zone-pair.
Политика, применяемая на Zone-pair, имеет однонаправленное действие (unidirectional policy) — т.е. политика из зоны «inside» в «outside» это не тоже самое что из «outside» в «inside» и наоборот.
Если для Zone-pair выполняется Stateful Inspection на маршрутизаторе (задается в политике), то при прохождении трафика из одной зоны в другую (например из «A» в «B»), он проходит через Inspection Engine, записываясь в Database маршрутизатора. Это позволяет свободно пропускать ответный трафик назад в зону «A» даже если если не было создано пары зон и соответствующей политики, разрешающей прохождение трафика в обратном направлении (из зоны «B» в «А»).
Для применения политик используется т.н. язык С3PL (Cisco Common Classification Policy Language), который в многом похож на MQC (Modular QoS Command-Line).
Составляющие компоненты C3PL:
1) Class-map — используется для описания/выделения трафика. Трафик может выделяться с использование ключевого слова match protocol (поддерживаются различные протоколы L3-L7), ссылаясь на Access-list — match access-group, или указывать на другой Class-map — match class-map.
Class-map может состоять из нескольких match правил (match1, match2,…,matchN) и поэтому делится на 2 типа:
— match-all — все правила должны выполняться
— match-any — любое из правил должно выполняться (проверяются в порядке следования!)
Общий вид конфигурации:
2) Policy-map — действие, которое должно быть применено к трафику, определенному в Class-map. Правила Policy-map состоят из одного или нескольких Class-map, к которым применяются действия:
- inspect — Разрешить трафик и производить его инспекцию (Stateful Inspection)
- pass — Только разрешить трафик, не инспектировать
- drop — Запретить трафик
Для действий "drop" и "pass" доступно ключевое слово "log", для логирования событий при попадании трафика на конкретное правило в Policy-map.
Policy-map правила просматриваются в порядке очередности сверху вниз, так же как это происходит в ACL.
В конце каждого Policy-map по умолчанию добавляется Class-map "class-default" c действием "drop" (только после применения Policy-map к Service-policy).
Общий вид конфигурации:
Если Class-map составлен только на основе ACL, а в Policy-map используется инспекция трафика (Inspect), то попадать под инспекцию будет весь трафик(TCP, UDP, ICMP), проходящий ACL.
3) Service-policy — Применение политики. Service-policy ссылается на Policy-map и применяется на Zone-pair. Для каждого Zone-pair может быть применена только одна Service-policy.
Общий вид конфигурации:
Рассмотрим следующую схему:
Имеется маршрутизатор R1, на котором настраивается ZBF. Определяем зоны:
INSIDE - внутренняя доверенная сеть.
OUTSIDE - Подключение к интернет провайдеру.
DMZ - расположение серверов и публичного WEB-ресурса компании.
self - сам маршрутизатор R1, если трафик предназначается ему, либо генерируется маршрутизатором (имеется по умолчанию).
Имеется удаленный филиал (маршрутизатор R2), связь с которым осуществляется через шифрованный IPsec туннель (VTI).
Создаем Security Zones:
Внимание! После этого весь трафик, проходящий между интерфейсами, находящимися в разных Security Zone, будет запрещен!
1) Из зоны INSIDE в зону OUTSIDE:
Разрешаем пользователям внутренней сети использовать протоколы HTTP, HTTPS, DNS, ICMP. Создаем Class-map для выделения интересующих протоколов:
Для того, чтобы явно обозначить кому разрешен доступ из внутренней подсети, создадим access-list, в котором выделим всю подсеть 192.168.1.0/24:
В данном случае мы с помощью Class-map выделяем трафик (далее его будем разрешать и инспектировать), идущий только из сети 192.168.1.0/24 по любым из протоколов: HTTP (80); HTTPS (443); DNS(53); ICMP
Определяем Policy-map, т.е. те действия, которые мы будем совершать над трафиком, определенным в Class-map выше:
Создаем Zone-pair "in_to_out", т.е. определяем пару зон между которыми будет применяться политика Policy-map:
2) Из зоны INSIDE в зону DMZ:
Разрешаем весь TCP, UDP, ICMP трафик и ответный трафик из DMZ (inspect):
Разрешаем протоколы HTTP и HTTPS для прохождения - публичные Web ресурсы компании:
Разрешим доступ к маршрутизатору R1 по протоколам TCP, UDP, ICMP только с ПК администратора (PC1) и маршрутизатора филиала (R2), остальным пользователям внутренней сети разрешим только ICMP трафик до R1:
Создаем ACL и Class-map для ICMP:
Из Интернета разрешим только SSH для удаленного администрирования, а т.к. предполагается наличие IPsec туннеля, то нужно так же разрешить ISAKMP (UDP port 500) и ESP:
"show zone security" - посмотреть информацию о настроенных зонах и интерфейсах, на которые эти зоны назначены:
"show zone-pair security" - посмотреть информацию о настроенных парах зон (Zone-pair):
"show policy-map type inspect" - посмотреть настроенные Policy-map:
В каждом Policy-map автоматически создалось правило Class "class-default" с действием "drop"!
"show class-map type inspect" - посмотреть настроенные Class-map:
"show policy-map type inspect zone-pair name sessions" - посмотреть инспекцию трафика:
Маршрутизатор R2 установил TCP соединение с WEB-сервером по HTTP протоколу. Настроен Static NAT 209.165.100.250-192.168.100.100, настройки NAT см. ниже.
Настройка IPsec туннеля в сторону удаленного офиса (в сторону R2):
Приведу настройки только для R1, на R2 они полностью аналогичные!
R1:
Так же проверяем доступ по SSH с маршрутизатора R2 на R1 и доступность удаленной подсети 192.168.2.0/24 c PC1:
Настройка NAT для R1:
Допустим имеется диапазон белых адресов, выделенный провайдером: 209.165.100.248/30
IP адреc 209.165.100.250 зарезервируем за сервером 192.168.100.100, находящимся в DMZ и настроим Static NAT:
v.1.00
Firewall средствами Cisco IOS, поддерживается на маршрутизаторах серии ISR с лицензией Security.
Предшественником ZBF был CBAC (Context-Based Access Control).
Интерфейсы маршрутизатора делятся на зоны (Zones). Зона (Zone) — логическая область с точки зрения маршрутизатора, в которой все устройства имеют общий уровень доверия и подчиняются одним правилам.
Зоны создаются администратором, после чего интерфейсы маршрутизатора помещаются в зоны. Один или несколько интерфейсов маршрутизатора могут находится в одной зоне. Каждый отдельный интерфейс может находится только в одной зоне.
Прохождение трафика с одной зоны в другую определяется созданными политиками.
Default Zone (Self-zone) — особый тип зоны маршрутизатора (есть по умолчанию), в которой находится только сам маршрутизатор (его Control Plane). Трафик, направленный на любой IP адрес самого маршрутизатора, либо сгенерированный с него, входит или соответственно покидает Self-zone.
Для Self-zone поддерживается инспекция (Inspect) только следующих протоколов: TCP, UDP, ICMP, H.323.
Правила поведения между зонами по умолчанию:
1) Трафик, входящий в (или покидающий) Self-zone разрешен!
2) Трафик, проходящий между интерфейсами, находящимися в одной зоне разрешен!
3) Трафик, проходящий между интерфейсами, не принадлежащими каким-либо зонам, разрешен!
4) Трафик, проходящий между интерфейсами разных зон запрещен!
5) Трафик, проходящий между интерфейсами, только один из которых является членом какой-либо зоны запрещен!
Для того, чтобы разрешить прохождение трафика между интерфейсами, находящимися в разных зонах, необходимо создать разрешающую политику (Service Policy) для каждой пары зон — т.н. Zone-pair.
Политика, применяемая на Zone-pair, имеет однонаправленное действие (unidirectional policy) — т.е. политика из зоны «inside» в «outside» это не тоже самое что из «outside» в «inside» и наоборот.
Если для Zone-pair выполняется Stateful Inspection на маршрутизаторе (задается в политике), то при прохождении трафика из одной зоны в другую (например из «A» в «B»), он проходит через Inspection Engine, записываясь в Database маршрутизатора. Это позволяет свободно пропускать ответный трафик назад в зону «A» даже если если не было создано пары зон и соответствующей политики, разрешающей прохождение трафика в обратном направлении (из зоны «B» в «А»).
Для применения политик используется т.н. язык С3PL (Cisco Common Classification Policy Language), который в многом похож на MQC (Modular QoS Command-Line).
Составляющие компоненты C3PL:
1) Class-map — используется для описания/выделения трафика. Трафик может выделяться с использование ключевого слова match protocol (поддерживаются различные протоколы L3-L7), ссылаясь на Access-list — match access-group, или указывать на другой Class-map — match class-map.
Class-map может состоять из нескольких match правил (match1, match2,…,matchN) и поэтому делится на 2 типа:
— match-all — все правила должны выполняться
— match-any — любое из правил должно выполняться (проверяются в порядке следования!)
Общий вид конфигурации:
class-map type inspect protocol-name {match-any | match-all} class-map-nameprotocol-name — (опция) служит для более глубокой инспекции отдельно взятых протоколов уровня приложения (HTTP, ICQ, IMAP, SIP, SMTP, и др.)
2) Policy-map — действие, которое должно быть применено к трафику, определенному в Class-map. Правила Policy-map состоят из одного или нескольких Class-map, к которым применяются действия:
- inspect — Разрешить трафик и производить его инспекцию (Stateful Inspection)
- pass — Только разрешить трафик, не инспектировать
- drop — Запретить трафик
Для действий "drop" и "pass" доступно ключевое слово "log", для логирования событий при попадании трафика на конкретное правило в Policy-map.
Policy-map правила просматриваются в порядке очередности сверху вниз, так же как это происходит в ACL.
В конце каждого Policy-map по умолчанию добавляется Class-map "class-default" c действием "drop" (только после применения Policy-map к Service-policy).
Общий вид конфигурации:
policy-map type inspect policy-map-namePolicy-map позволяет так же ограничить скорость трафика (bytes/second), проходящего между зонами — опция Police rate — применяется к конкретному Class-map
(config-pmap-c)#police rate <8000-2000000000> burst <1000-512000000>Police rate нельзя применить на Zone-pair, содержащую Self-zone. (На самом деле можно, но после того, как уже применена Service-policy). Для защиты Control-plane маршрутизатора правильнее использовать CoPP и CPPr.
Если Class-map составлен только на основе ACL, а в Policy-map используется инспекция трафика (Inspect), то попадать под инспекцию будет весь трафик(TCP, UDP, ICMP), проходящий ACL.
3) Service-policy — Применение политики. Service-policy ссылается на Policy-map и применяется на Zone-pair. Для каждого Zone-pair может быть применена только одна Service-policy.
Общий вид конфигурации:
service-policy type inspect policy-map-nameПример настройки IOS ZBF:
Рассмотрим следующую схему:
Имеется маршрутизатор R1, на котором настраивается ZBF. Определяем зоны:
INSIDE - внутренняя доверенная сеть.
OUTSIDE - Подключение к интернет провайдеру.
DMZ - расположение серверов и публичного WEB-ресурса компании.
self - сам маршрутизатор R1, если трафик предназначается ему, либо генерируется маршрутизатором (имеется по умолчанию).
Имеется удаленный филиал (маршрутизатор R2), связь с которым осуществляется через шифрованный IPsec туннель (VTI).
Создаем Security Zones:
R1(config)#zone security INSIDEНазначаем Security Zones на интерфейсы:
R1(config-sec-zone)#description Trusted_network
!
R1(config)#zone security OUTSIDE
R1(config-sec-zone)#description Internet
!
R1(config)#zone security DMZ
R1(config-sec-zone)#description Servers
Внимание! После этого весь трафик, проходящий между интерфейсами, находящимися в разных Security Zone, будет запрещен!
R1(config)#interface f1/0Создаем политики, разрешающие прохождение трафика между зонами:
R1(config-if)#zone-member security INSIDE
!
R1(config)#interface f1/1
R1(config-if)#zone-member security OUTSIDE
!
R1(config)#interface g0/0
R1(config-if)#zone-member security DMZ
1) Из зоны INSIDE в зону OUTSIDE:
Разрешаем пользователям внутренней сети использовать протоколы HTTP, HTTPS, DNS, ICMP. Создаем Class-map для выделения интересующих протоколов:
R1(config)#class-map type inspect match-any in_to_out_protocols"match-any" - использовать любой из этих протоколов
R1(config-cmap)#match protocol http
R1(config-cmap)#match protocol https
R1(config-cmap)#match protocol dns
R1(config-cmap)#match protocol icmp
Для того, чтобы явно обозначить кому разрешен доступ из внутренней подсети, создадим access-list, в котором выделим всю подсеть 192.168.1.0/24:
R1(config)#ip access-list extended INTERNET_ACLСоздаем отдельный Class-map, в котором указываем уже созданный Class-map и access-list:
R1(config-ext-nacl)#permit ip 192.168.1.0 0.0.0.255 any
R1(config)#class-map type inspect match-all in_to_out"match-all" - т.е. должны выполняться все условия одновременно
R1(config-cmap)#match class-map in_to_out_protocols
R1(config-cmap)#match access-group name INTERNET_ACL
В данном случае мы с помощью Class-map выделяем трафик (далее его будем разрешать и инспектировать), идущий только из сети 192.168.1.0/24 по любым из протоколов: HTTP (80); HTTPS (443); DNS(53); ICMP
Определяем Policy-map, т.е. те действия, которые мы будем совершать над трафиком, определенным в Class-map выше:
R1(config)#policy-map type inspect in_to_out"inspect" - разрешаем прохождение трафика и записываем информацию в Stateful database маршрутизатора, что автоматически разрешает ответный трафик без применения дополнительных политик из зоны OUTSIDE в зону INSIDE
R1(config-pmap)#class in_to_out
R1(config-pmap-c)#inspect
Создаем Zone-pair "in_to_out", т.е. определяем пару зон между которыми будет применяться политика Policy-map:
R1(config)#zone-pair security in_to_out source INSIDE destination OUTSIDEТрафик, проходящий из зоны INSIDE в зону OUTSIDE будет инспектироваться согласно Policy-map "in_to_out"
R1(config-sec-zone-pair)#service-policy type inspect in_to_out
2) Из зоны INSIDE в зону DMZ:
Разрешаем весь TCP, UDP, ICMP трафик и ответный трафик из DMZ (inspect):
R1(config)#class-map type inspect match-any in_to_dmz3) Из зоны OUTSIDE в зону DMZ:
R1(config-cmap)#match protocol tcp
R1(config-cmap)#match protocol udp
R1(config-cmap)#match protocol icmp
!
R1(config)#policy-map type inspect in_to_dmz
R1(config-pmap)#class in_to_dmz
R1(config-pmap-c)#inspect
!
R1(config)#zone-pair security in_to_dmz source INSIDE destination DMZ
R1(config-sec-zone-pair)#service-policy type inspect in_to_dmz
Разрешаем протоколы HTTP и HTTPS для прохождения - публичные Web ресурсы компании:
R1(config)#class-map type inspect match-any out_to_dmz4) Из зоны INSIDE в зону self:
R1(config-cmap)#match protocol http
R1(config-cmap)#match protocol https
!
R1(config)#policy-map type inspect out_to_dmz
R1(config-pmap)#class out_to_dmz
R1(config-pmap-c)#inspect
!
R1(config)#zone-pair security out_to_dmz source OUTSIDE destination DMZ
R1(config-sec-zone-pair)#service-policy type inspect out_to_dmz
Разрешим доступ к маршрутизатору R1 по протоколам TCP, UDP, ICMP только с ПК администратора (PC1) и маршрутизатора филиала (R2), остальным пользователям внутренней сети разрешим только ICMP трафик до R1:
Создаем ACL и Class-map для ICMP:
R1(config)#ip access-list extended ICMPСоздаем ACL и Class-map для ПК администратора (192.168.1.10) и маршрутизатора R2 (для туннельного адреса 10.0.0.2)
R1(config-ext-nacl)#permit icmp any any
!
R1(config)#class-map type inspect in_to_self_icmp
R1(config-cmap)#match access-group name ICMP
R1(config)#ip access-list standard ADMINПрименяем два Class-map к Policy-map "in_to_self", просматриваться они будут в порядке назначения, т.е. сначала "in_to_self_admin", а затем "class in_to_self_icmp". Если совпадения не будет, то сработает Class-map по умолчанию - class default, и трафик будет отброшен (по умолчанию drop).
R1(config-std-nacl)#permit 10.0.0.2
R1(config-std-nacl)#permit 192.168.1.10
!
R1(config)#class-map type inspect match-any in_to_self_protocols
R1(config-cmap)#match protocol tcp
R1(config-cmap)#match protocol udp
R1(config-cmap)#match protocol icmp
!
R1(config)#class-map type inspect match-all in_to_self_admin
R1(config-cmap)#match class-map in_to_self_protocols
R1(config-cmap)#match access-group name ADMIN
R1(config)#policy-map type inspect in_to_selfПрименяем политику между зонами INSIDE и self:
R1(config-pmap)#class in_to_self_admin
R1(config-pmap-c)#pass
R1(config-pmap-c)#exit
R1(config-pmap)#class in_to_self_icmp
R1(config-pmap-c)#pass
R1(config-pmap-c)#exit
R1(config-pmap)#exit
R1(config)#zone-pair security in_to_self source INSIDE destination self5) Из зоны OUTSIDE в зону self:
R1(config-sec-zone-pair)#service-policy type inspect in_to_self
Из Интернета разрешим только SSH для удаленного администрирования, а т.к. предполагается наличие IPsec туннеля, то нужно так же разрешить ISAKMP (UDP port 500) и ESP:
R1(config)#ip access-list extended from_internetПроверки:
R1(config-ext-nacl)#permit tcp any any eq 22
R1(config-ext-nacl)#permit udp any any eq isakmp
R1(config-ext-nacl)#permit esp any any
!
!для большей безопасности такой ACL стоит настраивать только с конкретных диапазонов адресов
!
R1(config)#class-map type inspect out_to_self
R1(config-cmap)#match access-group name from_internet
!
R1(config)#policy-map type inspect out_to_self
R1(config-pmap)#class out_to_self
R1(config-pmap-c)#pass
!
R1(config)#zone-pair security out_to_self source OUTSIDE destination self
R1(config-sec-zone-pair)#service-policy type inspect out_to_self
"show zone security" - посмотреть информацию о настроенных зонах и интерфейсах, на которые эти зоны назначены:
"show zone-pair security" - посмотреть информацию о настроенных парах зон (Zone-pair):
"show policy-map type inspect" - посмотреть настроенные Policy-map:
В каждом Policy-map автоматически создалось правило Class "class-default" с действием "drop"!
"show class-map type inspect" - посмотреть настроенные Class-map:
"show policy-map type inspect zone-pair name sessions" - посмотреть инспекцию трафика:
Маршрутизатор R2 установил TCP соединение с WEB-сервером по HTTP протоколу. Настроен Static NAT 209.165.100.250-192.168.100.100, настройки NAT см. ниже.
Настройка IPsec туннеля в сторону удаленного офиса (в сторону R2):
Приведу настройки только для R1, на R2 они полностью аналогичные!
!IKE Phase 1Настройка протокола динамической маршрутизации OSPF с маршрутизатором филиала R2:
!
R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encryption aes
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 2
R1(config-isakmp)#hash sha
!
!Настройка общего ключа аутентификации (PSK)
!
R1(config)#crypto isakmp key cisco123 address 209.165.200.253
!
!IKE Phase 2
!
R1(config)#crypto ipsec transform-set R1_set esp-aes esp-sha-hmac
R1(cfg-crypto-trans)#mode tunnel
!
!Создаем IPsec Profile
!
R1(config)#crypto ipsec profile R1
R1(ipsec-profile)#set transform-set R1_set
!
!Настраиваем туннельный интерфейс - VTI и размещаем его в INSIDE зоне
!
R1(config)#interface tunnel 0
R1(config-if)#ip address 10.0.0.1 255.255.255.252
R1(config-if)#tunnel source 209.165.100.253
R1(config-if)#tunnel mode ipsec ipv4
R1(config-if)#tunnel destination 209.165.200.253
R1(config-if)#tunnel protection ipsec profile R1
R1(config-if)#zone-member security INSIDE
R1:
R1(config)#router ospf 1R2:
R1(config-router)#router-id 1.1.1.1
R1(config-router)#network 10.0.0.1 0.0.0.0 area 0
R1(config-router)#network 192.168.1.254 0.0.0.0 area 0
R1(config-router)#network 192.168.100.254 0.0.0.0 area 0
R1(config-router)#passive-interface default
R1(config-router)#no passive-interface tunnel 0
R2(config)#router ospf 1Проверяем работу OSPF через туннель:
R2(config-router)#router-id 2.2.2.2
R2(config-router)#network 10.0.0.2 0.0.0.0 area 0
R2(config-router)#network 192.168.2.254 0.0.0.0 area 0
R2(config-router)#passive-interface default
R2(config-router)#no passive-interface tunnel 0
Так же проверяем доступ по SSH с маршрутизатора R2 на R1 и доступность удаленной подсети 192.168.2.0/24 c PC1:
Настройка NAT для R1:
Допустим имеется диапазон белых адресов, выделенный провайдером: 209.165.100.248/30
IP адреc 209.165.100.250 зарезервируем за сервером 192.168.100.100, находящимся в DMZ и настроим Static NAT:
R1(config)#ip nat inside source static 192.168.100.100 209.165.100.250Для хостов из внутренней подсети 192.168.1.0/24 настроим NAT Overload (PAT) с использованием адреса интерфейса F1/1 маршрутизатора R1:
R1(config)#ip nat inside source list NAT interface FastEthernet1/1 overloadПрименим NAT на интерфейсы:
R1(config)#ip access-list standard NAT
R1(config-std-nacl)#permit 192.168.1.0 0.0.0.255
R1(config)#interface g0/0--------
R1(config-if)#ip nat inside
!
R1(config)#interface f1/0
R1(config-if)#ip nat inside
!
R1(config-if)#interface f1/1
R1(config-if)#ip nat outside
v.1.00
Комментариев нет:
Отправить комментарий