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),
которая позволяет более гибко, чем в предыдущих версиях межсетевого экрана, настраивать правила
фильтрации трафика.

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

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

маршрутизатора:

По умолчанию, трафик разрешен между интерфейсами одной зоны безопасности и запрещен между
разными зонами. Трафик между интерфейсом, который относится к какой-либо зоне, и интерфейсом,
который не относится ни к одной зоне, запрещен. В дополнение ко всему, вы не можете применять
классические правила межсетевого экранирования (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

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

В левой стороне от роутера 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

Видим, что мы без проблем создаём TCP соединения через маршрутизатор R2, но трафик ICMP не
проходит. Команда show policy-map type inspect zone-pair показывает статистику работы ZBF в
реальном времени.
Так же можно посмотреть текущие сессии установленные через маршрутизатор. Например в
приведенном выше выводе видим установленное 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

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

Здесь мы видим как работал наш ограничитель для 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) под который попало данное
соединение.

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

Настройка Zone Based Firewall

Потребовалось настроить доступ в интернет через маршрутизатор Cisco 2901.

Было арендовано несколько IP адресов. В локальной сети были организованы отдельные

VLAN сети для серверной подсети, пользовательской сети и так далее.

Для настройки межсетевого экрана на маршрутизаторе было решено применить Zone Based
Firewall.

Пример настройки на основе доступа из LAN в Internet

На маршрутизаторе использовалось два интерфейса:

interface GigabitEthernet0/1 используется для доступа в интернет и подключён напрямую к

оборудованию провайдера.
interface GigabitEthernet0/0 был поделён на под-интерфейсы и для LAN сети был создан
interface GigabitEthernet0/0.129.

Настройка ZBF.

Создаём зоны безопасности.

Определим две зоны безопасности.

1. zone security LAN

2. zone security INTERNET

Определение интерфейсов в необходимые зоны.

Интерфейсу GigabitEthernet0/1 указана зона безопасности INTERNET

1. zone-member security INTERNET

Интерфейсу GigabitEthernet0/0.129 указана зона безопасности LAN

1. zone-member security LAN

Создаём пары зон взаимодействия

Зона для пропуска трафика из LAN в INTERNET

1. zone-pair security LAN_to_INTERNET source LAN destination INTERNET

Зона пропуск трафика из INTERNET в LAN

1. zone-pair security INTERNET-to-LAN source INTERNET destination LAN

Определяем класс трафика разрешённого для прохода межу зонами

Таких классов можно создавать несколько и применять к разным политикам, назначенные на разные
зоны безопасности.

1. class-map type inspect match-any LAN_to_INTERNET

2. match protocol http
3. match protocol https
4. match protocol dns
5. match protocol ftp
6. match protocol imap
7. match protocol imap3
8. match protocol imaps
9. match protocol ntp
10. match protocol pop3
11. match protocol pop3s
12. match protocol smtp
13. match protocol ssh
14. match protocol icmp

Для доступа из интернета в локальную сеть будем использовать Access List

1. ip access-list extended INTERNET_INCOMING

2. permit tcp any host 192.168.131.139 eq 443
3. permit tcp any host 192.168.131.140 eq smtp
4. permit tcp any host 192.168.131.138 eq 3389
5. permit tcp any host 192.168.131.138 eq 443
6. permit tcp any host 192.168.131.145 eq 443

Применим созданный Access List к классу трафика

1. class-map type inspect match-all INTERNET_to_LAN

2. match access-group name INTERNET_INCOMING

Определяем политики доступа

Политика доступа из LAN в INTERNET

1. policy-map type inspect LAN_to_INTERNET

2. class type inspect LAN_to_INTERNET
3. inspect
4. class class-default
5. drop
Политика доступа из INTERNET в LAN

1. policy-map type inspect INTERNET_to_LAN

2. class type inspect INTERNET_to_LAN
3. inspect
4. class class-default
5. drop

Применяем политики к парам зон

Пара LAN в INTERNET

1. zone-pair security LAN_to_INTERNET source LAN destination INTERNET

2. service-policy type inspect LAN_to_INTERNET

Пара INTERNET в LAN

1. zone-pair security INTERNET_to_LAN source INTERNET destination LAN

2. service-policy type inspect INTERNET_to_LAN

Дополнительные команды

Создание своих портов

Если вам необходимо открыть свой порт, который не прописан по умолчанию в IOS, то вы
его можете создать сами. Для этого вводим:

1. ip port-map ИМЯ_ПОРТА port tcp или udp НОМЕР_ПОРТА

Данный порт добавляем в нужный class-map.

Брандмауэр на Cisco IOS используя zone-based firewall

Cisco IOS это довольно многофункциональна платформа, а не только ОС для роутера, на ней можно
развернуть и IP-телефонию и полноценный Firewall. Первое я уже где-то описывал, а со вторым не
сталкивался, но этот момент не заставил себя ждать. Итак, есть такая интересная незатронутая тема,
как Zone-based firewall (ZBF).

В основе всей этой концепции лежит разбиение сети на отдельные участки или зоны. Самый яркий
пример, это когда у нас в сети есть обычные пользователи, есть общедоступные сервера и, разумеется,
выход в интернет. Само собою понятно, что извне не должно быть доступа к хостам пользователей, но
должен быть доступ к серверам ну и имеется еще ряд нюансов. Это все можно сделать с помощью
списков доступа (ACL), но как-то это все будет слишком уж коряво выглядеть и так же работать.

Таким образом, чтобы реализовать ZBF, надо первым делом разделить сеть на зоны, в нашем случае
это:
- внутренняя, где расположены пользователи (inside)

- внешняя, непосредственно Интернет (outside)

- демилитаризованная зона, где расположены наши сервера (dmz)
Это общие стандартные названия, называть зоны можно как угодно и создавать их сколько угодно.

После создания зон нам необходимо будет привязать к ним определенные интерфейсы на роутере.
Теперь правилами доступа мы будем рулить между зонами, а не между интерфейсами. При этом
необходимо указать и настроить политики доступа из одной зоны в другую. На роутере можно будет
использовать инспекцию трафика, так что инициировать соединение можно будет с одной зоны (если
инициирование разрешено из этой зоны) и нельзя будет с другой. В нашем случае, пользователи могут
инициировать соединение с серверами в dmz и другими серверами в Интернете. Сервера из dmz, в
свою очередь не могут инициировать соединение в хостами во внутренней сети, так же как и сервера в
Интернете. Если же необходимо разрешить определенный трафик из dmz, то необходимо указать
отдельные разрешающие правила. Точно так же можно указать отдельные правила для соединения
извне с серверами в зоне dmz. Например, разрешить только HTTP соединения и т.д. Необходимо
учитывать, что эти правила работают только в одну сторону и только между двумя зонами. В любом
случае, можно разрешить трафик и с другой стороны.

По умолчанию, между интерфейсами в одной зоне разрешен весь трафик, между интерфейсами в
разных зонах – трафик запрещен. Трафик, который генерируется маршрутизатором, или предназначен
ему, по-умолчанию разрешен.

Перейдем к определению терминов

- class-map определяет, какой именно трафик будет инспектироваться (проходить между зонами, также
проходить будут ответы на этот трафик). Фильтроваться трафик может по критериям c 4 по 7 уровней
модели OSI (т.е. начиная от IP-адреса и заканчивая трафиком определенного приложения).
Определяется трафик списками доступа, значением CoS, типом протокола и еще рядом других
параметров. Критериев может присутствовать одновременно несколько. При этом можно указать,
должен ли трафик попадать под все эти критерии (match-all) или под любой из них (match-any). Таким
образом, основная задача class-map это отфильтровать необходимый тип трафика.
- policy-map определяет действие, которое будет произведено с отфильтрованным с помощью class-
map трафиком. Действия могут быть следующие: инспектировать (разрешать, при этом
контролировать поток), разрешать, запрещать, записывать в лог.
В одном policy-map может быть указано несколько class-map и к каждой из них может применяться
отдельное действие. Если class map-ов указано несколько то сравнение будет проходить от первого до
последнего правила последовательно до первого совпадения. Если трафик не попадает ни под одно
правило, то он запрещается.
- service policies через него мы привязываем policy-map к определенной паре зон в одном направлении.

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

Теперь перейдем к самому интересному, к настройке. Посмотрим еще раз на рисунок, эта топология
будет взята за основу построения нашего файрвола. В левой стороне находится внутренняя сеть, в
нижней части показаны два сервера (ubuntu – web-сервер, debian – другой сервер, предназначение
которого нам неизвестно), в правой части выход в Интернет. Я пропущу настройки интерфейсов на
маршрутизаторе и прочие мелочи, это уже никому не интересно, адресами интерфейсов будут первые
доступные адреса в указанных подсетях.
Итак, с зонами мы определились. Теперь попробуем настроить трафик между зонами inside и outside
Тут все более-менее просто и понятно, создаем список доступа ACL

ZBF-Router(config)#access-list 20 permit 10.0.0.0 0.0.0.255

ZBF-Router(config)#

Теперь создадим class-map, где определим трафик как попадающий под наш список доступа. Как видно
именно тут ключевым словом match-any указывается необходимо ли попадание под все критерии
описанные в class-map (match-all) или под любой из них.

ZBF-Router(config)#class-map type inspect match-any From_Inside

ZBF-Router(config-cmap)#?
Class-map configuration commands:
description Class-Map description
exit Exit from class-map configuration mode
match classification criteria
no Negate or set default values of a command
rename Rename this class-map
ZBF-Router(config-cmap)#match ?
access-group Access group
 class-map Class map
protocol PAM Protocol
ZBF-Router(config-cmap)#match access-group 20
ZBF-Router(config-cmap)#

Теперь создадим policy-map и определим в нем необходимое действие с трафиком (inspect) а также
укажем использование class-map для фильтрования. У меня они оба называются From_Inside, но эти
имена могут отличаться, даже лучше, когда они отличаются.

ZBF-Router(config)#policy-map type ?
access-control access-control specific policy-map
control Configure a control policy policy-map
inspect Configure CBAC Policy Map
logging Control-plane packet logging
port-filter Control-plane tcp/udp port filtering
queue-threshold Control-plane protocol queue limiting
ZBF-Router(config)#policy-map type inspect ?
WORD policy-map name
http Configure CBAC policy-map for HTTP protocol
im Configure CBAC policy-map for IM protocol
imap Configure CBAC policy-map for IMAP protocol
p2p Configure CBAC policy-map for P2P protocols
pop3 Configure CBAC policy-map for POP3 protocol
smtp Configure CBAC policy-map for SMTP protocol
sunrpc Configure CBAC policy-map for RPC protocol
ZBF-Router(config)#policy-map type inspect From_Inside
ZBF-Router(config-pmap)#class type inspect From_Inside
ZBF-Router(config-pmap-c)#?
Policy-map class configuration commands:
drop Drop the packet
exit Exit from class action configuration mode
inspect Context-based Access Control Engine
no Negate or set default values of a command
pass Pass the packet
police Police
service-policy Deep Packet Inspection Engine
 urlfilter URL Filtering Engine

ZBF-Router(config-pmap-c)#inspect ?
ZBF-Router(config-pmap-c)#inspect
%No specific protocol configured in class From_Inside for inspection. All
protocols will be inspected
ZBF-Router(config-pmap-c)#
ZBF-Router(config-pmap-c)#exit
ZBF-Router(config-pmap)#exit
ZBF-Router(config)#

На этом этапе создаем зоны, если они еще не созданы.

ZBF-Router(config)#zone security inside

ZBF-Router(config-sec-zone)#exit
ZBF-Router(config)#zone security outside
ZBF-Router(config-sec-zone)#exit
ZBF-Router(config)#

Теперь разрешаем трафик между двумя зонами, который определен в service-policy From_Inside.

ZBF-Router(config)# zone-pair security in-to-out source inside

destination outside
ZBF-Router(config-sec-zone-pair)#service-policy type inspect ?
WORD policy-map name
ZBF-Router(config-sec-zone-pair)#service-policy type inspect From_Inside
ZBF-Router(config-sec-zone-pair)#exit
ZBF-Router(config)#

Дело за малым, привязываем интерфейсы к зонам.

ZBF-Router(config)#int fa2/0
ZBF-Router(config-if)#zone-member security inside
ZBF-Router(config-if)#exit
ZBF-Router(config)#int fa0/0
ZBF-Router(config-if)#zone-member security outside
ZBF-Router(config-if)#exit
ZBF-Router(config)#

Доступа к серверам в dmz из сети пользователей не будет на данном этапе потому что не указана
политика доступа между зонами. Давайте разрешим доступ к серверам в dmz по следующим
критериям:

- доступ из пользовательской сети (и только от этих адресов) по протоколам ssh, telnet и http.

- доступ из внешней сети всем только по протоколу http

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

ZBF-Router(config)#zone security dmz

ZBF-Router(config-sec-zone)#exit
ZBF-Router(config)#int fastEthernet 0/1
ZBF-Router(config-if)#zone-member security dmz
ZBF-Router(config-if)#

Создаем Class-Map для пары inside-dmz (укажем их тут несколько для разнообразия)

ZBF-Router(config)#class-map type inspect match-all Ins-dmz-ssh-map

ZBF-Router(config-cmap)#match access-group 20
ZBF-Router(config-cmap)#match protocol ssh
ZBF-Router(config-cmap)#exit
ZBF-Router(config)#class-map type inspect match-all Ins-dmz-map
ZBF-Router(config-cmap)#match access-group 20
ZBF-Router(config-cmap)#match protocol http
ZBF-Router(config-cmap)#exit
ZBF-Router(config)#class-map type inspect match-all Ins-dmz-telnet-map
ZBF-Router(config-cmap)#match access-group 20
ZBF-Router(config-cmap)#match protocol telnet
ZBF-Router(config-cmap)#exit
ZBF-Router(config)#

Создаем policy-map, где указываем все три созданные нами Class-Map

ZBF-Router(config)#policy-map type inspect Inside-dmz
ZBF-Router(config-pmap)#class type inspect Ins-dmz-ssh-map
ZBF-Router(config-pmap-c)#inspect
ZBF-Router(config-pmap-c)#exit
ZBF-Router(config-pmap)#class type inspect Ins-dmz-map
ZBF-Router(config-pmap-c)#inspect
ZBF-Router(config-pmap-c)#exit
ZBF-Router(config-pmap)#class type inspect Ins-dmz-telnet-map
ZBF-Router(config-pmap-c)#inspect
ZBF-Router(config-pmap-c)#exit
ZBF-Router(config-pmap)#

Создаем пару между зонами

ZBF-Router(config)#zone-pair security ins-to-dmz source inside

destination dmz
ZBF-Router(config-sec-zone-pair)#service-policy type inspect Inside-dmz
ZBF-Router(config-sec-zone-pair)#exit
ZBF-Router(config)#

Что ж, доступ есть из внутренней сети есть. А теперь интересный момент, мы не разрешили
протокол ICMP, поэтому доступ к серверу через браузер и через ssh c telnet-ом будет, а пинг
проходить не будет. Такие дела.
Повторим еще раз пройденный материал, разрешим извне доступ к серверам по протоколу http.

ZBF-Router(config)#class-map type inspect match-any Out-dmz-map

ZBF-Router(config-cmap)#match protocol http
ZBF-Router(config-cmap)#exit
ZBF-Router(config)#

ZBF-Router(config)#policy-map type inspect Out-dmz-pol

ZBF-Router(config-pmap)#class type inspect Out-dmz-map
ZBF-Router(config-pmap-c)#inspect
ZBF-Router(config-pmap-c)#exit
ZBF-Router(config-pmap)#

ZBF-Router(config)#zone-pair sec out-dmz source outside destination dmz

ZBF-Router(config-sec-zone-pair)#service-policy type inspect Out-dmz-pol
ZBF-Router(config-sec-zone-pair)#

Тут такая же история, есть доступ через браузер, но нет доступа через другие протоколы, в том
числе ICMP.
Замечу, что сервера при этом не могут вообще никуда инициировать соединения кроме как между
собой. При этом они могут отвечать на соединения извне. Спокойно можно из внутренней сети зайти
по ssh для администрирования сервера.

На последок добавлю что, zone based firewall совсем не мешает использовать NAT. В нашем случае
пользователи из внутренней сети выходят в Интернет именно используя NAT. Конфигурация довольно
нехитрая и выглядит таким образом:

ZBF-Router(config)# ip nat inside source list 10 interface

FastEthernet0/0 overload
ZBF-Router(config)#access-list 10 permit 10.0.0.0 0.0.0.255
ZBF-Router(config)#int fa2/0
ZBF-Router(config-if)#ip nat inside
ZBF-Router(config-if)#int fa0/0
ZBF-Router(config-if)#ip nat outside
ZBF-Router(config-if)#

Защита от Ddos с использованием механизма Zone-

Based Policy Firewall cisco
Zone-Based Policy Firewall
Zone-Based Policy Firewall — механизм Cisco, заключающийся в настройке правил
межсетевого экрана на маршрутизаторе.
В его основе лежит распределение интерфейсов маршрутизатора по зонам безопасности.
После этого все правила настраиваются для взаимодействий между зонами.
Оборудование
В данном пример используется маршрутизатор cisco ASR1004 (RP2) processor with
4338924K/6147K bytes of memory
Операционная система Cisco IOS Software, IOS-XE Software 12.2(33)XNE2, RELEASE
SOFTWARE (fc1)
Основные понятия

 правила настраиваются между зонами

 зона может состоять из одного или нескольких интерфейсов
 между зонами по умолчанию политика – запрещено все
 политика применяется к парам зон с указанием направления

Порядок настройки ZBFW

1. Определяем зоны
2. Определяем пары зон
3. Настраиваем class-map, где указываем трафик, к которому будет применяться
политика
 4. Настраиваем политику policy-map, в которой определяем действия с трафиком,
определенным в class-map
5. Применяем политику на пары зон
6. Назначаем зоны на интерфейсы

Рассмотрим, как можно использовать данный механизм для защиты от Ddos атак.
В данном примере у нас есть 2 интерфейса, которые смотрят внутрь сети,
и 2 интерфейса, которые смотрят на аплинки.
Назовем зону, которую вешаем на внешние интерфейсы PUBLIC
Назовем зону, которую вешаем на внутренние интерфейсы PRIVAT
(только не забываем, что на интерфейсы мы вешаем их в последнюю очередь)
1. Определяем зоны
Заходим в режим конфигурации на cisco и создаем зоны

conf t
(config)# zone security PRIVAT
(config)# zone security PUBLIC

2. Определяем пары зон

Инспектировать трафик будем в двух направлениях, хотя можно ограничиться только
направлением извне.
Создаем 2 пары зон PRI-TO-PUB и PUB-TO-PRI

conf t
(config)# zone-pair security PRI-TO-PUB source PRIVAT destination PUBLIC
(config)# zone-pair security PUB-TO-PRI source PUBLIC destination PRIVAT

3. Настраиваем class-map
В моем примере я отдельно инспектирую трафик udp и tcp (что тоже необязательно).
Я буду использовать правило match-all (логическое И), поэтому для каждого ip адреса,
который мы хотим инспектировать (защищать от Ddos),
создается свой access-list и всего class-map будет 4 штуки для udp и tcp, для
каждого направления.
Адреса внутри моей сети внешние.
Пусть адрес, который я хочу защитить внутри моей сети будет 8.8.8.8
Создаем 2 access-list (2 направления)

conf t
(config)# access-list 104 permit ip host 8.8.8.8 any
(config)# access-list 105 permit ip any host 8.8.8.8

Создаем class-map (всего 4 штуки)

conf t
(config)# class-map type inspect match-all INSPECT_8.8.8.8_tcp_PRI
(config-cmap)# match access-group 104
(config-cmap)# match protocol tcp
(config)# class-map type inspect match-all INSPECT_8.8.8.8_udp_PRI
(config-cmap)# match access-group 104
(config-cmap)# match protocol udp
(config)# class-map type inspect match-all INSPECT_8.8.8.8_tcp_PUB
(config-cmap)# match access-group 105
(config-cmap)# match protocol tcp
(config)# class-map type inspect match-all INSPECT_8.8.8.8_udp_PUB
(config-cmap)# match access-group 105
(config-cmap)# match protocol udp

По правилом логического И, под каждый класс будет попадать только трафик с

указанным ip и протоколом (оба условия должны совпадать).
Итак. мы определили, что защищать, теперь определим как защищать

4.Настраиваем политику policy-map

У нас будет 2 политики для 2-ух пар зон.
В них мы перечисляем наши class-map, с указанием
действия inspect (инспектировать).
И последним описываем действие для class class-default. Оно
будет pass (пропускать все остальное).
Это крайне важно, поскольку по умолчанию правило drop (отбрасывать весь остальной
трафик).

(config)# policy-map type inspect INSPECT_PRI

(config-pmap)# class-map type inspect INSPECT_8.8.8.8_tcp_PRI
(config-pmap-c)# inspect
(config-pmap)# class-map type inspect INSPECT_8.8.8.8_udp_PRI
(config-pmap-c)# inspect
(config-pmap)# class class-default
(config-pmap-c)# pass
(config)# policy-map type inspect INSPECT_PUB
(config-pmap)# class-map type inspect INSPECT_8.8.8.8_tcp_PUB
(config-pmap-c)# inspect
(config-pmap)# class-map type inspect INSPECT_8.8.8.8_udp_PUB
(config-pmap-c)# inspect
(config-pmap)# class class-default
(config-pmap-c)# pass

5. Применяем политики на пары зон

(config)# zone-pair security PRI-TO-PUB source PRIVAT destination PUBLIC

(config-sec-zone-pair)# service-policy type inspect INSPECT_PRI
(config)# zone-pair security PUB-TO-PRI source PUBLIC destination PRIVAT
(config-sec-zone-pair)# service-policy type inspect INSPECT_PUB

6. Назначаем зоны на интерфейсы

(config)# interface TenGigabitEthernet0/0/0.1

(config-subif)# zone-member security PUBLIC
(config)# interface TenGigabitEthernet0/0/0.2
(config-subif)# zone-member security PUBLIC
(config)#interface TenGigabitEthernet0/1/0
(config-subif)# zone-member security PRIVAT
(config)# interface TenGigabitEthernet0/2/0
(config-subif)# zone-member security PRIVAT

В результате данные политики пропускают весь трафик в обе стороны,

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

#show zone security

zone self
Description: System defined zone

zone PRIVAT
Member Interfaces:
TenGigabitEthernet0/1/0
TenGigabitEthernet0/2/0

zone PUBLIC
Member Interfaces:
TenGigabitEthernet0/0/0.1
TenGigabitEthernet0/0/0.2
#sh zone-pair security
Zone-pair name PRI-TO-PUB
Source-Zone PRIVAT Destination-Zone PUBLIC
service-policy INSPECT_PRI
Zone-pair name PUB-TO-PRI
Source-Zone PUBLIC Destination-Zone PRIVAT
service-policy INSPECT_PUB
#sh class-map type inspect
Class Map type inspect match-all INSPECT_8.8.8.8_tcp_PRI (id 1)

Match access-group 104

Match protocol tcp

Class Map type inspect match-all INSPECT_8.8.8.8_udp_PRI (id 2)

Match access-group 104

Match protocol udp

Class Map type inspect match-all INSPECT_8.8.8.8_tcp_PUB (id 3)

Match access-group 105

Match protocol tcp

Class Map type inspect match-all INSPECT_8.8.8.8_udp_PUB (id 4)

Match access-group 105

Match protocol udp
#sh policy-map type inspect
Policy Map type inspect INSPECT_PRI
Class INSPECT_8.8.8.8_tcp_PRI
inspect
Class INSPECT_8.8.8.8_udp_PRI
inspect
Class class-default
Pass

Policy Map type inspect INSPECT_PUB

Class INSPECT_8.8.8.8_tcp_PUB
inspect
Class INSPECT_8.8.8.8_udp_PUB
inspect
Class class-default
Pass
#sh policy-map type inspect zone-pair
Zone-pair: PRI-TO-PUB
Service-policy inspect : INSPECT_PRI
Class-map: INSPECT_8.8.8.8_tcp_PRI (match-all)
Match: access-group 104
Match: protocol tcp
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:1483]

Session creations since subsystem startup or last reset 0

Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [2:5:0]
Last session created 00:10:27
Last statistic reset 3d
Last session creation rate 0
Last half-open session total 0

Class-map: INSPECT_8.8.8.8_udp_PRI (match-all)

Match: access-group 104
Match: protocol udp
Inspect
Packet inspection statistics [process switch:fast switch]
udp packets: [0:2153]

Session creations since subsystem startup or last reset 0

Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:6:0]
Last session created 00:01:27
Last statistic reset 3d
Last session creation rate 0
Last half-open session total 0
Class-map: class-default (match-any)
Match: any
 Pass
1038592 packets, 59367005 bytes

Zone-pair: PUB-TO-PRI
Service-policy inspect : INSPECT_PUB
Class-map: INSPECT_8.8.8.8_tcp_PUB (match-all)
Match: access-group 105
Match: protocol tcp
Inspect
Packet inspection statistics [process switch:fast switch]
tcp packets: [0:5463]

Session creations since subsystem startup or last reset 0

Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [32:45:0]
Last session created 00:56:27
Last statistic reset 3d
Last session creation rate 0
Last half-open session total 0

Class-map: INSPECT_8.8.8.8_udp_PUB (match-all)

Match: access-group 105
Match: protocol udp
Inspect
Packet inspection statistics [process switch:fast switch]
udp packets: [0:12153]

Session creations since subsystem startup or last reset 0

Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [31:76:0]
Last session created 00:43:17
Last statistic reset 3d
Last session creation rate 0
Last half-open session total 0

Class-map: class-default (match-any)

Match: any
Pass
 20338592 packets, 59567017 bytes
#sh policy-map type inspect zone-pair sessions