Многоуровневая защита периметра в NGFW: как DPI, IPS, DNS Security, TLS-инспекция и WAF дополняют друг друга

На упрощённых схемах NGFW часто изображают как последовательный конвейер: межсетевой экран, DPI, IPS, антивирус, WAF. Такая схема удобна для презентации, но создаёт неверное впечатление, будто каждый пакет проходит через все механизмы по очереди, а для усиления защиты достаточно включить больше модулей.

На практике всё зависит от конкретного потока. DNS-запрос, исходящее HTTPS-соединение, другой транзитный трафик и обращение к опубликованному веб-приложению обрабатываются разными механизмами. Поэтому модуль может быть настроен и активен, но не анализировать нужное соединение: профиль IPS не подключён к разрешающему правилу, DNS-запросы уходят через другой резолвер, HTTPS не расшифровывается, а приложение опубликовано через DNAT в обход WAF.

Разберём эту модель на примере Ideco NGFW Novum 22: какой трафик получает каждый механизм, какие данные ему доступны и где чаще всего возникают слепые зоны.

В Ideco NGFW Novum используются классические и высокопроизводительные контексты. Они различаются набором функций и внутренним порядком обработки трафика. В статье рассматриваются функциональные тракты, а не точная последовательность вызова программных компонентов. Подробные схемы приведены в документации для классического и высокопроизводительного контекстов. Доступность функций зависит от типа контекста, лицензии и действующих подписок.

Начинать нужно с потока, а не со списка модулей

Одно действие пользователя может создавать несколько самостоятельных потоков. Например, открытие сайта обычно начинается с DNS-запроса, после которого устанавливается HTTP- или HTTPS-соединение.

Пользователь открывает сайт
├─ DNS-запрос → DNS-служба NGFW → DNS Security
└─ HTTP(S)-соединение → сетевые и веб-механизмы защиты

Эти потоки получают разные наборы проверок:

Это не универсальный порядок вызова. Таблица показывает, какие механизмы в принципе могут участвовать в сценарии. Фактический набор определяется типом соединения, правилами Межсетевого экрана, настройками сервисов и подключёнными профилями безопасности.

У каждого механизма свой объект анализа:

Тракт 1. Произвольное транзитное соединение: Межсетевой экран, Контроль приложений и IPS

Межсетевой экран задаёт границы допустимого

Базовый уровень защиты — stateful firewall. Он определяет, разрешено ли соединение между источником и назначением, и учитывает состояние сессии. Для транзитного трафика используются правила FORWARD. Правила NAT и соединения к самому NGFW находятся за рамками этого сценария.

Разрешающее правило может подключать дополнительные профили безопасности, например Контроль приложений и IPS. В высокопроизводительном контексте к нему также можно привязать профиль TLS/SSL-инспекции.

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

DPI распознаёт, Контроль приложений применяет политику

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

DPI анализирует признаки прикладного протокола и помогает определить, какое приложение использует соединение. Контроль приложений использует результат распознавания в политике: например, разрешает средство удалённого администрирования ИТ-службе и запрещает его остальным пользователям.

Это важно, потому что номер порта больше не определяет сервис. Через TCP 443 могут работать корпоративный SaaS, файлообменник, мессенджер, средство удалённого доступа или инструмент обхода ограничений. Политика, построенная только на адресах и портах, не различает такие сценарии.

IPS проверяет разрешённый трафик на признаки атак

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

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

IPS может выявлять попытки эксплуатации уязвимостей, сканирование, протокольные аномалии, обращения к известной вредоносной инфраструктуре и другие сигнатурно описанные события. Его не следует сводить только к поиску известных CVE: протокольные и обобщённые правила иногда позволяют обнаружить неизвестную атаку по применяемой технике. Но сетевой IPS не гарантирует обнаружение произвольной zero-day-уязвимости и не заменяет EDR или sandbox-анализ неизвестных объектов.

Шифрование определяет глубину анализа

Отсутствие TLS-инспекции не делает Контроль приложений и IPS полностью слепыми. Им остаются доступны параметры соединения, незашифрованные протоколы и часть TLS-метаданных. Но они не могут получить URI, HTTP-заголовки, тело запроса и другое содержимое, защищённое TLS.

В высокопроизводительном контексте профиль TLS/SSL-инспекции можно применить к выбранному TLS-трафику на нужных TCP-портах. После расшифровки содержимое передаётся подключённым L7-профилям: Контролю приложений, IPS, а для веб-трафика — Контент-фильтру.

Поэтому перенос TLS-защищённого сервиса с TCP 443 на нестандартный порт сам по себе не гарантирует обход проверки. Но профиль расшифровки должен охватывать соответствующий трафик, а нужные механизмы должны быть подключены к тому же правилу.

Тракт 2. HTTP(S): TLS-инспекция, Контент-фильтр и веб-антивирус

Для веб-доступа принципиальна разница между двумя уровнями видимости: NGFW видит только TLS-соединение или получает доступ к HTTP-запросу внутри него.

Что доступно без расшифровки

Без вмешательства в TLS-сессию NGFW может использовать доступные метаданные, например SNI и поля сертификата, чтобы применить политику к ресурсу целиком.

Такой режим не позволяет:

• отличить одну страницу сайта от другой;

• проверить полный URL и HTTP-метод;

• анализировать HTTP-заголовки и MIME-тип содержимого;

• проверить передаваемый по HTTPS файл веб-антивирусом.

Фильтрация без расшифровки проще во внедрении и остаётся полезной, если достаточно разрешать или запрещать ресурс целиком. Но по глубине контроля она не равна анализу открытого HTTP-содержимого.

Что даёт TLS-инспекция

При TLS-инспекции NGFW завершает защищённое соединение клиента, в том числе использующее TLS 1.3, устанавливает отдельную TLS-сессию с внешним сервером и выдаёт клиенту динамически сформированный сертификат целевого ресурса, подписанный локальным удостоверяющим центром NGFW.

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

После расшифровки становятся доступны полный URL, метод запроса, заголовки, MIME-тип и передаваемое содержимое. Какие механизмы получат эти данные, зависит от типа контекста, настроенного тракта и подключённых профилей. Это могут быть Контент-фильтр, Контроль приложений, IPS, веб-антивирус и внешние ICAP-сервисы.

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

Почему расшифровку нельзя включать без подготовки

Глобальное включение TLS-инспекции обычно создаёт больше проблем, чем постепенное внедрение. Нужно учитывать:

• приложения с certificate pinning;

• сервисы, которые следует исключить по требованиям безопасности или внутренней политике;

• конфликты с локальными антивирусами, которые также выполняют подмену сертификатов;

• рост вычислительной нагрузки;

• необходимость диагностировать ошибки сертификатов и несовместимые клиенты.

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

Отдельно нужно учитывать QUIC и HTTP/3. Они работают поверх UDP и не проходят обычный HTTPS-тракт на TCP. Если веб-трафик должен контролироваться механизмами, рассчитанными на HTTP поверх TCP, QUIC и HTTP/3 необходимо ограничить предусмотренной политикой. Браузеры с поддержкой отката после этого перейдут на TCP, а отдельные приложения без такого механизма могут перестать работать.

Тракт 3. DNS-запрос: DNS-служба и DNS Security

DNS Security принимает решение до установления соединения. Если пользователь переходит по фишинговой ссылке, вредоносная программа обращается к C2 или пытается разрешить DGA-домен, запрос можно заблокировать ещё до получения IP-адреса. Это снижает нагрузку на последующие уровни защиты и останавливает часть угроз на раннем этапе.

В Ideco NGFW DNS Security проверяет внешние домены с помощью аналитической платформы и репутационных данных. Блокируются:

• фишинговые, вредоносные и недавно зарегистрированные домены;

• инфраструктура ботнетов, C2 и вымогателей;

• DGA-домены и typosquatting;

• обращения к криптомайнингу;

• признаки DNS-туннелирования.

Анализ учитывает не только репутацию, но и аномалии DNS-трафика (структуру субдоменов, частоту запросов, типы записей), что позволяет выявлять новые угрозы.

Связь с аналитической платформой защищена (DNS-over-TLS), а внутренние зоны обрабатываются локально. DNS Security и IPS дополняют друг друга: первый блокирует соединение на этапе резолвинга, второй анализирует уже проходящий трафик.

DNS-запрос должен попасть в NGFW

DNS Security работает, только если запрос проходит через NGFW. Это достигается либо использованием NGFW как DNS-сервера, либо включением перехвата пользовательских DNS-запросов. Так обеспечивается централизованная политика даже при использовании внешних резолверов.

При включении перехвата все пользовательские DNS-запросы принудительно направляются на DNS-службу NGFW, даже если на конечном устройстве настроен другой DNS-сервер. Одновременно блокируется использование DoH, DoT и DoQ между пользователями и NGFW, поэтому зашифрованные альтернативные резолверы нельзя использовать для обхода централизованной DNS-политики.

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

Ограничения:

• соединения по IP обходят DNS;

• возможен обход через встроенные или зашифрованные резолверы, если они не контролируются политиками;

• проверка домена не заменяет анализ последующего трафика.

DNS Security уменьшает поверхность атаки, блокирует часть угроз до установления соединения и даёт администратору единую точку контроля DNS-активности пользователей и устройств, но не превращает последующее соединение в доверенное.

Тракт 4. Публикация приложения: Обратный прокси и WAF

WAF защищает не исходящий веб-доступ пользователей, а входящие HTTP- и HTTPS-запросы к опубликованным приложениям.

В Ideco NGFW профиль WAF создаётся отдельно и применяется в правиле Обратного прокси. Само наличие профиля не меняет обработку трафика. Приложение должно быть опубликовано через Обратный прокси с выбранным WAF-профилем. Обычный DNAT только направляет соединение на внутренний сервер и не включает WAF.

Для профиля предусмотрены два режима:

• только обнаружение — подозрительные запросы журналируются, но не блокируются;

• обнаружение и блокировка — запросы журналируются и блокируются.

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

WAF помогает выявлять типовые инъекции, XSS, обращения к чувствительным файлам, сканирование и протокольные аномалии. Но он не знает бизнес-логику конкретного приложения, не исправляет уязвимый код и не заменяет безопасную разработку. Авторизацию, разграничение прав и защиту бизнес-операций необходимо реализовывать в самом приложении.

Где чаще всего возникают разрывы в защите

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

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

Что на практике означает единая платформа

Объединение механизмов в NGFW не означает, что они используют один движок или обязательно выполняются друг за другом. Межсетевой экран, IPS, Контент-фильтр, DNS Security, антивирус и WAF остаются отдельными компонентами со своими объектами анализа, профилями и журналами.

Практическая ценность единой платформы в другом:

• политики используют общих пользователей, группы и сетевые объекты;

• разные уровни контроля настраиваются в одном интерфейсе;

• события можно сопоставлять внутри продукта или передавать во внешнюю SIEM;

• уменьшается количество отдельных точек включения в сеть и независимых контуров управления.

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

Итог

Многоуровневая защита в NGFW — это не один универсальный конвейер, а сочетание нескольких функциональных трактов.

DNS Security может остановить обращение к опасному домену до установки соединения. Межсетевой экран определяет допустимые направления трафика. Контроль приложений классифицирует прикладные протоколы и сервисы. IPS ищет признаки атак в разрешённых соединениях. TLS-инспекция открывает защищённое содержимое для тех механизмов, которые подключены к соответствующему тракту. Контент-фильтр управляет веб-доступом, веб-антивирус проверяет передаваемые объекты, а WAF отдельно защищает приложения, опубликованные через Обратный прокси.

Поэтому главный вопрос при проверке конфигурации звучит не «Какие модули включены?», а иначе:

По какому тракту проходит конкретный поток, какой механизм его получает и какие данные доступны ему на этом этапе?

Узнать больше про Ideco NGFW Novum и получить доступ к демонстрации