«Традиционные ACL — это набор инструкций, а не настоящая политика. ZPF — это сдвиг парадигмы: вы сначала объявляете границы доверия (зоны), а затем декларативно описываете, что между ними разрешено. Это не про фильтрацию, а про архитектуру безопасности.»

ZPF Design: проектирование межзонного политического межсетевого экрана

Zone-based Policy Firewall (ZPF) — это модель настройки межсетевого экрана, при которой политики безопасности привязываются не к сетевым интерфейсам или адресам, а к логическим зонам. Интерфейсы маршрутизатора назначаются этим зонам, а правила (разрешить, запретить, инспектировать) определяются для пар «исходная зона — зона назначения».

Ключевое отличие от классического подхода с ACL на интерфейсах — в уровне абстракции. Вы работаете не с правилами «разрешить хост A в сеть B», а с концепцией: «трафик из зоны «Серверы» в зону «Интернет» должен проходить stateful-инспекцию». Это делает конфигурацию более интуитивной, централизованной и менее подверженной ошибкам при изменении топологии.

Эта модель особенно актуальна в контексте требований регуляторов, таких как ФСТЭК и 152-ФЗ, где одним из базовых принципов является зонирование информационных систем и контроль информационных потоков между зонами. ZPF предоставляет готовый инструментарий для технической реализации этих требований на оборудовании Cisco IOS.

Как работает ZPF: от интерфейсов к политикам

В основе ZPF лежит несколько строгих правил, определяющих судьбу трафика в зависимости от принадлежности интерфейсов к зонам.

1. Трафик внутри одной зоны проходит свободно. Если оба интерфейса принадлежат одной зоне (например, «Внутренняя_сеть»), межзональная политика не применяется.

2. Трафик из зоны в не-зону (или наоборот) блокируется по умолчанию. Если один интерфейс в зоне, а другой — нет, трафик между ними будет отброшен. Это фундаментальный принцип «всё, что не разрешено явно, запрещено».

3. Трафик между разными зонами контролируется политикой. Только если для пары зон определена политика (zone-pair с привязанным service-policy), трафик будет обработан согласно ей: инспектирован, пропущен (pass) или отброшен (drop).

Ключевые компоненты и этапы проектирования

1. Определение зон

Первый и самый важный шаг — сегментировать сеть на зоны безопасности. Зона — это группа интерфейсов с одинаковым уровнем доверия. Типичные примеры:

• INSIDE (Внутренняя сеть) — наиболее доверенная зона с пользовательскими рабочими станциями.
• DMZ — зона для публично доступных серверов (веб, почта).
• OUTSIDE (Интернет) — наименее доверенная зона.
• SERVERS — выделенная зона для внутренних серверов БД, систем управления.

В российской практике это напрямую коррелирует с выделением сегментов информационной системы (ИС) согласно ее модели угроз.

2. Установление политик между зонами

Для каждой пары зон, между которыми требуется обмен трафиком, определяется политика. Политика всегда однонаправленная: из зоны-источника в зону-назначения.

• Из INSIDE в OUTSIDE: разрешить и инспектировать HTTP, HTTPS, DNS.
• Из OUTSIDE в DMZ: разрешить и инспектировать HTTP(S) на адрес веб-сервера.
• Из DMZ в INSIDE: запретить всё, кроме исключительных служебных протоколов на конкретные адреса (например, SQL-запросы от веб-сервера к серверу БД).

3. Физическое проектирование и зона Self

Отдельного внимания заслуживает системная зона Self. Это абстрактная зона, представляющая сам маршрутизатор. Политики с участием Self контролируют трафик, предназначенный для устройства или исходящий от него:

• Управление (SSH, SNMP, NetFlow) из зоны INSIDE в зону Self.
• Исходящие запросы DNS или NTP от Self к OUTSIDE.
• Обмен маршрутной информацией (OSPF, BGP) между маршрутизаторами.

Без явной политики для Self такой служебный трафик будет заблокирован, что может привести к потере управления или сбою в работе сети.

Три действия политики: Inspect, Drop, Pass

Внутри политики для классифицированного трафика можно задать одно из трёх действий:

Действие	Аналог в ACL	Поведение	Когда использовать
Inspect (Cisco IOS Stateful Packet Inspection)	Permit с stateful-проверкой	Разрешает инициирующий трафик, динамически открывает обратные порты для ответов, отслеживает состояние сессии (TCP, UDP).	Для большинства пользовательских протоколов (HTTP, Email, VoIP). Основное действие для безопасного доступа.
Pass	Stateless Permit	Статически разрешает трафик в одном направлении. Не отслеживает состояние. Для ответного трафика нужна отдельная политика.	Для протоколов с предсказуемым поведением, где stateful-инспекция избыточна или проблематична (например, протоколы шифрования типа IPsec ESP, протоколы multicast).
Drop	Deny	Молча отбрасывает пакет (без отправки ICMP unreachable).	Явный запрет. Действие по умолчанию для всего трафика, не подпадающего под правила класса class-default.

Практика: последовательность конфигурации ZPF

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

Шаг 1: Создание зон (zone security)

R1(config)# zone security INSIDE
R1(config)# zone security OUTSIDE

Шаг 2: Классификация трафика (class-map type inspect)

Создаём класс, например, для веб-трафика.

R1(config)# class-map type inspect match-any WEB-CLASS
R1(config-cmap)# match protocol http
R1(config-cmap)# match protocol https
R1(config-cmap)# match protocol dns

Шаг 3: Определение действия (policy-map type inspect)

Создаём политику и назначаем ей действие для созданного класса.

R1(config)# policy-map type inspect INSIDE_to_OUTSIDE_POLICY
R1(config-pmap)# class type inspect WEB-CLASS
R1(config-pmap-c)# inspect

Класс class-default с действием drop добавляется в политику автоматически.

Шаг 4: Связывание зон и политики (zone-pair security)

Создаём одностороннюю пару зон и применяем к ней политику.

R1(config)# zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE
R1(config-sec-zone-pair)# service-policy type inspect INSIDE_to_OUTSIDE_POLICY

Шаг 5: Назначение интерфейсов зонам (zone-member security)

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

R1(config)# interface GigabitEthernet0/0
R1(config-if)# zone-member security INSIDE
R1(config-if)# interface GigabitEthernet0/1
R1(config-if)# zone-member security OUTSIDE

Верификация и диагностика

Помимо просмотра running-config, используйте специализированные команды:

• show zone-pair security — показывает созданные пары зон и привязанные политики.
• show policy-map type inspect zone-pair sessions — ключевая команда. Отображает активные сессии, проходящие через межсетевой экран, их состояние, объём переданных данных, а также статистику по срабатыванию правил (сколько пакетов обработано или отброшено классом class-default).
• show zone security — отображает все зоны и интерфейсы, в них входящие.

Особенности и ограничения для проектирования

• Интерфейс может принадлежать только одной зоне. Для создания объединения зон (например, для общего ресурса) нужно создавать новую зону и продумывать политики заново.
• ZPF и классический межсетевой экран (CBAC/Classic Firewall) не могут работать на одном интерфейсе одновременно. Перед назначением интерфейса зоне команды ip inspect должны быть удалены.
• Политика по умолчанию — запрет всего. Это соответствует принципам безопасной настройки. Разрешаются только явно описанные в политиках потоки.
• Трафик управления маршрутизатором защищён только через зону Self. Если не настроить политики для Self, доступ к самому устройству может быть неконтролируемым.

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