Лабораторный стенд для NGFW: когда честность важнее высоких цифр

10:20 / 2 мая, 2025

Подробное руководство по конфигурациям, трафику и тестбедам по стандарту RFC 9411.

Как сконструировать лабораторное окружение, которое позволит честно сравнить NGFW/NGIPS разных вендоров, минимизировать «шум» внешних факторов и не сойти с ума в процессе.

1. Зачем нужен правильный стенд — и почему «ласточки» 2010-х уже не летают

Десять лет назад достаточно было скрестить лабораторный генератор трафика вроде IXIA c парой коммутаторов, базовым скриптом для проверки ACL — и получался стандартный «тест производительности». Сейчас всё изменилось: современные NGFW/NGIPS анализируют зашифрованный трафик TLS 1.3, производят глубокий разбор HTTP/3, некоторые даже используют элементы машинного обучения (хотя для бенчмаркинга такие возможности рекомендуется отключать). Прежние методики, описанные в стандарте RFC 3511, просто не учитывают эти аспекты. В 2023 году был принят новый стандарт RFC 9411, который кардинально переопределил подход к тестированию: особый акцент на проверку приложений уровня 7, требования к строгой воспроизводимости результатов и обязательному детальному логированию. Методика, описанная в данной статье, полностью основана на этих новых стандартах.

2. Базовые принципы построения стенда

Перед тем как заворачивать гайки, надо договориться о фундаменте:

Изоляция. Демилитаризованная зона — не фигуральное выражение, а обязательное условие. Лаборатория отделена от продуктивной сети vlan'ами, фаерволами и банальной табличкой «Не трогать!».
Избыточность железа. Каждый элемент (генератор, коммутатор, маршрутизатор) обязан переваривать минимум 120% планируемой пиковой нагрузки. Это гарантирует, что бутылочное горлышко найдётся внутри тестируемого устройства (Device Under Test, DUT), а не рядом.
Детальный паспорт стенда. Версии прошивок, параметры TCP стека, номера патчей ОС — всё это описывается и хранится вместе с отчетом. Иначе никакой повторяемости.

3. Топологии по RFC 9411: Option 1 и Option 2

3.1. Option 1 — минималистичная прямая связка

Это максимально «чистая» топология, когда DUT подключается напрямую к трафик-генератору, минуя любые промежуточные устройства.

Когда использовать:

Если генератор трафика умеет эмулировать внешние IP-устройства (например, запуск клиентов и серверов в разных подсетях);
Когда важна минимизация задержек и джиттера — например, при замерах времени до первого байта (TTFB), времени до последнего байта (TTLB) или тестировании чувствительных к задержкам финансовых, видео и аудио приложений;
При тестировании базовой производительности NGFW/NGIPS без лишнего «шума» от коммутаторов и маршрутизаторов.

Плюсы:

Максимально низкие задержки и джиттер: весь путь прохождения пакетов сводится к маршруту «генератор → DUT → генератор»;
Простота настройки, меньше точек отказа и меньше переменных, влияющих на результат;
Наилучшая воспроизводимость результатов: тест легко повторить при любых условиях и через любое время.

Минусы:

Требуется продвинутый генератор трафика, который умеет не просто отправлять пакеты, а эмулировать функции маршрутизации, трансляцию сетевых адресов (NAT), а также клиентские и серверные устройства, генерировать и передавать сертификаты SSL/TLS;
Не масштабируется без существенного усложнения: если нужно подключить десятки физических портов или тестировать кластерные конфигурации SUT, необходимо переходить на топологию Option 2;
Может не соответствовать реальной инфраструктуре заказчика, где маршрутизаторы, балансировщики нагрузки и зеркалирование трафика являются нормой.

Рекомендация: если используете Option 1 — обязательно задокументируйте L3 топологию в генераторе: IP-диапазоны, маршруты, FQDN, тип NAT, TTL. Это критично для воспроизводимости и для понимания, «как именно шёл трафик» в готовых отчётах.

3.2. Option 2 — с коммутаторами и/или маршрутизаторами

Этот вариант согласно RFC 9411 стоит использовать в следующих ситуациях:

Требуется агрегировать большое количество физических портов — типичный сценарий для высокопроизводительных (high-end) решений типа NGFW уровня дата-центра;
Используемый генератор трафика не поддерживает функции маршрутизации (L3), или у него физически меньше портов, чем у тестируемого DUT.

Плюсы:

Позволяет масштабировать стенд под нагрузки 40G/100G/400G без полной замены генератора;
Более реалистично отражает реальную инфраструктуру заказчика (где почти всегда есть распределённая маршрутизация);
Гибче при построении кластеров DUT с несколькими зонами (DMZ, внешняя, внутренняя, зеркалирование).

Минусы:

Возникает зависимость от таблиц MAC, ARP (Address Resolution Protocol) и ND (Neighbor Discovery) коммутаторов — переполнение этих таблиц может вызывать скрытые задержки в обработке пакетов (известные как latent slow-path в документации производителей);
Значительно сложнее обеспечить полную изоляцию тестового стенда от внешнего трафика — особенно при использовании реальных (а не лабораторных) маршрутизаторов;
Дополнительные промежуточные устройства добавляют больше искажений, что снижает воспроизводимость результатов тестирования.

Рекомендация: если вы всё-таки используете топологию Option 2, необходимо регулярно контролировать состояние таблиц MAC и ARP на всех промежуточных устройствах. Оптимальный вариант — организовать автоматический мониторинг с помощью скриптов через SNMP или Netconf. Без такого контроля высока вероятность столкнуться с ситуацией, когда часть фреймов в коммутаторе начинает обрабатываться медленно (software-based forwarding вместо hardware-based), что делает тест некорректным.

4. Настройка DUT: от «Inline»-режима до логирования

Ниже приведён обязательный чек-лист. Он объёмный, но раз настроив, вы перекладываете ответственность за честность теста c себя на документацию.

4.1. Режим работы и feature-set

Чтобы тест NGFW/NGIPS был не просто «о скорости портов», а отражал реальную эксплуатацию устройства в боевой сети, необходимо активировать все ключевые функции безопасности. При этом важно начать с базовой настройки передачи трафика.

Режим работы

Inline (в разрыв сети) — обязательное требование согласно RFC 9411. Устройство должно физически находиться на пути трафика, а не работать в режиме мониторинга (Monitor) или анализа зеркалированного трафика (Tap);
Fail-Open = отключено — при отказе или перегрузке NGFW должен разрывать соединения (Fail-Close), а не пропускать трафик бесконтрольно (Fail-Open). Это единственный способ достоверно проверить поведение устройства под критической нагрузкой и при сбоях; Только в этом режиме вы знаете, что тестируете все функции безопасности под нагрузкой, а не просто внезапно устройство перешло в режим «выключено все». Оно будет очень быстрым, и бесполезным для безопасности, но значительно более дорогим чем патч-корд, который NGFW в этом режиме заменяет.
При наличии кластеризации или HA-режима (High Availability) — тест проводится на одном активном узле, с настройкой резервирования в режиме Active Passive. Нужно осознавать, что в реальной сети работа механизмов HA является нагрузкой на устройство и если вы это не протестируете, то в реальной эксплуатации столкнетесь с неожиданными проблемами.

Функции, которые нужно включить перед тестом

Для достоверного тестирования нужно активировать не просто «пустой» NGFW, а полный набор функций, используемых в продакшене. RFC 9411 рекомендует следующие модули:

Application Identification: определение приложений на основе поведения (например, Google Meet, WhatsApp, Steam) — без этого невозможно корректно фильтровать Layer 7. Контроль приложений использует технологию DPI (Deep Packet Inspection) - глубокая проверка содержимого пакетов, особенно для протоколов, где передают файлы или где работают туннели (ICMP, DNS, Websocket)
User Identification: определение пользователей. В сети правила на NGFW пишут по имени пользователя и по названию группы пользователей. Эти базы чаще всего берут с подключения к AD и LDAP сервисам. В тестах вы можете подгрузить в DUT список пользователей через API устройства.
TLS расшифрование: расшифровка трафика на основе подмены сертификатов сервера (SSL Proxy). Обязательно протестировать как TLS 1.2, так и TLS 1.3, с разными наборами шифров. Даже если модуль снижает производительность — это нужно измерить. При этом расшифрованный трафик в свою очередь тоже нужно проверить имеющимися модулями защиты: IPS, антивирусом, URL, песочницей.
SSH расшифрование: некоторые туннели работают через SSH и если в устройстве есть такой функционал, то тоже включите его и проверьте проверяет ли устройство атаки через SSH.
IPS: сигнатурный и эвристический анализ трафика. Использовать свежие базы сигнатур атак. Также нужно использовать свежие тестовые эксплойты, встроенные в генератор. Важно активировать максимальное количество сигнатур, соответствующих реальному сценарию защиты. Даже если это отрицательно влияет на производительность — это должно быть частью честного тестирования. Существуют сигнатуры, которые серьезно снижают производительность устройства, и поставщики обычно будет всеми правдами и неправдами просить выключать такие сигнатуры. Будьте готовы. Если вы выключите даже одну сигнатуру, которая серьезно снижает пропускную способность устройства, то это значит она же будет выключена и в реальной сети, и эту атаку ваше устройство блокировать не будет. А если сигнатура не включена, то NGFW пропустит критические важную атаку, и оставит вас в опасности.
Anti-Malware, Anti-Spyware, Anti-Botnet и Threat Intelligence: желательно включить сразу. Эти модули могут анализировать даже трафик внутри зашифрованных TLS потоков и потребляют значительные ресурсы, потому что нужно проверять множеством сигнатур каждый файл, скрипты в HTML и каждое подключение. Обычно в каждом NGFW есть набор готовых баз IP, DNS, URL которые поставщик предлагает использовать для блокировки доступа к C2C и другим известным вредоносным ресурсам. Используйте их.
Anti-Evasion: защита от техник обхода (фрагментация, обфускация, split payloads и пр.) — критична для честной оценки IPS. Существуют типовые методики обхода, которые умеют эмулировать тестовые устройства
Web-Filtering: фильтрация по URL, категориям сайтов, ключевым словам. Даже при «нулевом трафике» модуль должен быть активен и подключён к облачной базе (или офлайн-кэшу).
GeoIP: фильтрация по стране или региону. Такие базы есть сегодня во многих устройствах и вы должны проверить как они работают, потому что сегодня блокировка трафика от конкретных стран – часто используемая функция для защиты электронной почты, веб сайтов и вообще корпоративной сети.
Source NAT: Это серьезная сетевая функция, которая даже в эпоху портовых межсетевых экранов требовала наличия Application Layer Gateways (ALG), потому что требуется менять часть данных L7 при подмене IP адреса на L3 уровне. Особенно это важно для FTP и SIP.
NTP: включите синхронизацию времени в NGFW, потому что это будет влиять и на работу сертификатов и на журналирование.
Журналирование локально на устройстве: все срабатывания правил, все заблокированные соединения, все алерты по сигнатурам, все данные по геофильтрации. Генератор трафика при этом фиксирует latency и throughput по каждому потоку трафика.

Функции, которые можно включить перед тестом

Machine Learning: сегодня многие NGFW позволяют проверять DNS и URL запросы на основе ML, выявлять вредоносный код в файлах моделями ML и так далее. Это необязательная функция и она может повысить качество блокировки атак и снизить число ложных срабатываний. Спросите поставщика NGFW об этом.

Функции, которые лучше ВЫКЛЮЧИТЬ перед тестом

В NGFW в действительности больше функций: SSL VPN, IPSEC VPN, SD-WAN, динамическая маршрутизация OSPF и BGP, Policy Based Forwarding, DHCP. Их сложно протестировать, потому что в реальной сети они точно все будут работать по-разному. Если вы реально хотите протестировать работу 10000 подключений клиентов VPN или BGP с BFD, то при этом начните с обязательных проверок.
Автобновления: все базы сигнатур обычно обновляются из центральной системы управления всеми NGFW и NGFW их периодически скачивает. Да, есть тест на то работает ли NGFW при скачивании обновлений IPS сигнатур. Однако в тестировании это создает стохастически помехи, которые потом непонятно как анализировать. Лучше автообновления выключить.

Проверка эффективности профилей IPS

Помимо включения всех функций, необходимо также проводить проверку эффективности настроенных профилей IPS:

Генерация атак: во время тестирования производительности периодически должны подаваться симулированные атаки для проверки способности IPS обнаруживать и блокировать угрозы под нагрузкой.
Комбинированное тестирование: оптимально проводить одновременное тестирование и производительности, и эффективности обнаружения атак — это позволяет получить реалистичную картину работы устройства.
Документирование ложных срабатываний: учитывать и фиксировать ложные срабатывания (false positives) при обработке легитимного трафика, особенно при высоких нагрузках.

Логирование и аналитика

Без логов тест — это «темная комната».
Логирование должно быть:

Включено в полном объёме локально на устройстве. В больших сетях часто бывает так, что центральная система управления недоступна и журналирование пропадает. Также у вас будут ситуации, когда устройство не работает. И, если в нем нет локальных журналов, то вы просто не сможете провести troubleshooting.

Логирование может быть:

Настроено на внешний коллектор событий. Обычно это собственное устройство поставщика, также вы можете использовать syslog, NetFlow, JSON API, ELK-стек, SIEM или просто на лог-сервер. При этом это дополнительная нагрузка. Многие внешние коллекторы событий не тянут больше 50-60 тысяч журналов в секуну. NGFW создает большой поток событий при большом потоке трафика.

Геофильтрация

Активируется через собственную IP-базу;
Создаётся минимум одно правило: блокировать исходящие соединения в "запрещённые" страны или регионы (например, RU, CN, KP);
Если геофильтрация не поддерживается — это обязательно указывается в отчёте как ограничение функционала DUT/SUT.

Зачем включать всё это?

Потому что именно в таком режиме устройство максимально эффективно работает в продакшене. «Голые» цифры throughput на отключенном DPI и IPS никому не нужны — они не отражают ни задержек, ни потерь, ни поведения на Layer 7. В реальной сети всегда включены политики, и честное тестирование должно это учитывать.

4.2. ACL: сколько правил ставить?

При тестировании NGFW/NGIPS важно задать реалистичное количество и структуру правил доступа (ACL), поскольку именно они напрямую влияют на загрузку процессора, порядок обработки трафика и производительность DPI-модулей. RFC 9411 предлагает стандартные наборы ACL в зависимости от класса устройства.

Стандартная матрица ACL по классам производительности (согласно RFC 9411)

Класс устройства	Пропускная способность	L7 правила (block / allow)	L4/L3 правила (block / allow)
XS (сверхмалые)	≤ 1 Гбит/с	5 / 10	25 / 25
S (малые)	1–5 Гбит/с	10 / 20	50 / 50
M (средние)	5–10 Гбит/с	20 / 40	100 / 100
L (крупные)	10+ Гбит/с	50 / 100	250 / 250

Примечание: Данная классификация и количество правил являются рекомендацией стандарта RFC 9411, а не произвольными значениями.

При этом в реальных сетях число правил может достигать 100 тысяч. Обычно поставщиков тестируют на 1000 правил, а лидеров на 10000 правил. Компании у которых 100 тысяч правил и более часто заказывают собственные тесты.

Логика построения ACL

Порядок правил ACL — это критически важный фактор, напрямую влияющий на производительность. RFC 9411 устанавливает следующую последовательность: сначала всегда размещаются block-правила (запрещающие), и только после них — allow-правила (разрешающие). При этом необходимо соблюдать следующие принципы:

Наиболее конкретные правила ставятся первыми — например, правило блокировки по комбинации "IP-адрес + порт + протокол" должно располагаться выше в списке, чем правило блокировки только по IP-адресу;
Общие и «ловящие всё» правила (например, "deny all" или "allow all") всегда должны находиться в самом низу списка — они не должны перекрывать более специфические правила;
Политики NGFW отличаются по сетевым уровням: правила уровня L7 отвечают за приложения и URL-адреса, L4 — за порты и транспортные протоколы, L3 — за IP-адреса и подсети. В тесте NGFW нужно полностью L7 правила и правила пользователям. В тесте обычных L4 firewall используются правила только по IP адресам и портам. Отличайте эти тесты.

Зачем столько правил?

Во многих реалистичных сценариях NGFW работает в условиях сложной политики доступа: запрет доступа к определённым регионам (геофильтрация), блокировка категорий сайтов, ограничение приложений (P2P, прокси и т.п.). Тестовый стенд должен учитывать это, иначе вы получите «идеальные цифры» в лаборатории, которые рассыплются в прах на реальной сети.

Рекомендации

Имейте отдельный профиль теста с включённой и отключённой инспекцией политик безопасности, чтобы оценить реальную нагрузку при смене политики безопасности;
Не забывайте журналировать каждое срабатывание политики — нагрузка на систему логирования тоже имеет значение.

Итог: правильно подобранный и структурированный ACL не только отражает реальные сценарии эксплуатации, но и позволяет объективно сравнивать производительность устройств в честных и сопоставимых условиях. А значит — вы заранее знаете, как поведёт себя NGFW/NGIPS на проде, и избегаете неприятных сюрпризов.

Сначала блокируем — затем разрешаем; чем выше строчка, тем более конкретное совпадение. Магия порядка спасёт вас от «странных» результатов.

4.3. Логирование

Логирование — это не просто «удобно для отчёта», а необходимый элемент воспроизводимости и валидации теста. Без нормального лога вы не докажете, что устройство действительно увидело, проанализировало и отфильтровало нужный трафик.

Минимальный стандарт: 7-tuple лог

Каждое соединение, проходящее через DUT/SUT, должно быть зафиксировано в логе с указанием:

Source IP — IP-адрес источника;
Destination IP — IP-адрес назначения;
Source Port — порт источника;
Destination Port — целевой порт (например, 443, 53, 80);
Protocol — TCP, UDP, ICMP и т.д.
Приложение – 1C, обновления Касперского, web-browsing и т.д.
Имя пользователя – domain/igor, domain/marketing

Также желательно логировать timestamp, action (allow/block), policy name, app ID и метки GeoIP (если включены).

Что делать, если логирование ограничено

Если устройство по какой-то причине не поддерживает 7-tuple логирование, то его тестировать есть смысл, если вам хочется только одну какую-то функцию в нем проверить, например IPS. Если вы тестируете именно NGFW и там нет такого типа журналов, то это не NGFW. Все NGFW отличаются именно журналами. И если там нет даже такого минимума -– его в тест не берут. Зачем тратить время.

Типы журналов

Рекомендуется использовать следующие типы:

журнал соединений 7-tuple;
журнал IPS;
журнал антивируса;
журнал URL фильтрации;
журнал файлов;
журнал расшифрования TLS в режиме TLS Proxy;
журнал действий администратора;
журнал действий системы.

Обязательные проверки перед запуском теста

Проверить, что все логи от DUT поступают на лог-коллектор локальный или внешний (используйте tcpdump, если сомневаетесь);
Убедиться, что фильтруемые соединения (block по ACL, сигнатуре, гео) действительно отображаются как заблокированные и действительно блокируются;
Сделать «контрольную атаку» во время подачи нагрузки (например, имитацию CVE или запрещённого сайта) — проверить, что атака зафиксирована.

Зачем всё это?

Потому что без лога вы не докажете: прошёл ли трафик, был ли заблокирован, какова была причина, и на каком этапе он отвалился. Особенно это критично для тестов IPS, TLS Inspection и геофильтрации. Лог — это единственный объективный свидетель событий.

5. Генерация трафика

5.1. Эмуляция клиентов

Генератор трафика должен имитировать поведение реальных клиентов, включая браузеры с поддержкой современных протоколов HTTP 1.1, 2 и 3. Основные параметры, которые важно задать:

TCP: MSS 1460 или 1440 байт, окно — 64 КБ, Delayed ACK — не более 200 мс;
QUIC: без 0-RTT, Immediate Close включён, payload — 1252 или 1232 байта, тип потока — client-initiated, двунаправленный;
ALPN: «h2» и «h3», заголовки сжимаются, server_push выключен — чтобы избежать искажений в измерениях.

5.2. Эмуляция серверов

Серверы (или их эмуляция на генераторе) принимают трафик на портах 80 и 443 (TCP) и на одном произвольном UDP-порту — для тестов QUIC и нестандартных приложений.

Каждому FQDN назначается уникальный IP-адрес — это позволяет DUT/SUT распознавать и фильтровать трафик по приложению и хосту;
HTTPS: только TLS 1.2 и выше. TLS Handshake должны быть полными, без TLS reuse или кеша сессий; Переиспользование ключей TLS – облегчает тест.
Шифры для TLS 1.2: рекомендуется использовать ECDHE-ECDSA-AES128-GCM-SHA256 (с ключом P-256) и ECDHE-RSA-AES128-GCM-SHA256 (RSA 2048).

5.3. IPv4/IPv6-адресация

Подбираем пул IP-адресов, исходя из целевой нагрузки. Примерная формула согласно RFC 9411:

Количество IP = целевой throughput (Мбит/с) ÷ средний throughput на один IP

Для кампусных (enterprise) сценариев следует рассчитывать примерно 6 Мбит/с на каждый IP-адрес, а для сценариев тестирования дата-центров — 0.2 Мбит/с на IP. При смешанном тестировании IPv4 и IPv6, необходимо применять эту логику расчёта адресов независимо для каждого стека протоколов.

Важно помнить, что для тестирования следует использовать выделенные IANA тестовые диапазоны IPv4 (198.18.0.0/15) и IPv6 (2001:2::/48), чтобы избежать конфликтов с реальными адресами.

5.4. Пятифазный профиль нагрузки

Чтобы стенд отражал динамику реального трафика, применяется следующая схема загрузки:

Init — инициализация соединений;
Ramp-up — плавное увеличение числа одновременных сессий, чтобы не превысить число новых сессий в секунду;
Sustain — основная нагрузка (не менее 300 секунд);
Ramp-down — постепенное снижение трафика;
Collect — фаза сбора метрик.

Интервалы сэмплирования при этом не должны превышать 2 секунд — иначе пропадут пики latency, а графики сгладятся до неинформативных.

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

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

6. ACL, геофильтрация и другие «тонкие специи»

На первый взгляд, кажется: ну что там эти ACL — список правил и всё. Но именно здесь начинается зона «скрытой производительности», где NGFW может начать тормозить, а логика фильтрации — работать неожиданно.

6.1. Не экономьте на политиках ACL

Если политики NGFW на стенде настраиваются номинально: пару блокирующих правил, пару разрешающих — «для галочки», то это ошибка. Полноценная политика доступа позволяет:

нагрузить движки DPI и URL-фильтрации реальной работой, а не пропуском пустых пакетов;
протестировать таблицы состояний, производительность правил L3/L4/L7 и оптимизацию сопоставлений по порядку;
приблизиться к реальным сценариям эксплуатации, где политика безопасности редко состоит из 5 строчек.

6.2. Порядок имеет значение

Правила ACL должны быть расположены по принципу от самого узкого к самому общему (right-to-left). Это снижает количество обращений к движку DPI и уменьшает общий CPU-hit до 10–15% по сравнению с неструктурированной ACL. Банально? Да. Но именно об этом забывают чаще всего.

6.3. Геофильтрация (GeoIP)

Если вы активируете геофильтрацию (на основе IP2Location, MaxMind или собственной базы), убедитесь в трёх вещах:

Правила действительно применяются к трафику (а не «висят» в интерфейсе);
Срабатывания логируются — иначе вы не узнаете, что фильтрация была;
Вы понимаете цену: в режиме блокировки трафика по странам (например, RU, CN, KP) вы теряете 1–3% от TPS — это нормально и ожидаемо.

Не включать геофильтрацию — значит упустить важную часть проверки NGFW на соответствие современным требованиям по комплаенсу (особенно в финансовых и госсетях).

6.4. Мелочи, которые на самом деле не мелочи

Чем больше «rule hit» на уровне L7 — тем больше задержка TTFB. Даже 1-2 миллисекунды в каждом запросе могут суммироваться в десятки секунд при большом TPS.
Если в DUT реализован механизм оптимизации передачи трафика — отключите его на время теста, иначе результат будет плавающим;
Не забывайте: любые фильтры и списки доступа — это не только безопасность, но и «удар» по задержкам. И чем честнее вы с этим работаете — тем надёжнее будут выводы.

Вывод: журналирование, HA, геофильтрация и число политик в NGFW— это не просто «опции», а ключевые факторы, которые влияют на задержки, эффективность фильтрации и итоговую производительность. Если вы их игнорируете — вы не тестируете NGFW, вы тестируете линейную прокладку кабеля.

7. Как убрать помехи

Чтобы тест NGFW/NGIPS был не только честным, но и повторяемым, нужно исключить влияние лишних факторов — как в железе, так и в виртуализации. Вот два ключевых направления.

7.1. Reference-тест

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

Потери: 0% (допускается не более 0,001%);
RTT: менее 1 мс;
Jitter (p95): менее 50 мкс.

Если базовые цифры плохие — искать баги в NGFW бессмысленно: стенд не готов.

7.2. Виртуальный бестиарий

Если DUT развёрнут в виде виртуального сетевого сервиса (VNF/VM), убедитесь в следующем:

NUMA-pinning: ядра и память закреплены жёстко. Без этого пакеты перескакивают между сокетами и создают задержки;
DPDK или SR-IOV: обязательны для любых VNF с производительностью 10 Гбит/с и выше — прямой доступ к сетевому адаптеру сильно снижает overhead;
Noisy neighbours: если включено автоматическое перемещение VM (vMotion, Live Migration) — тест нельзя считать валидным. Даже кратковременный spike в latency убивает результат.

Не забудьте: иногда проще и честнее взять физический DUT, чем бороться с виртуальными ресурсами виртуалки.

8. KPI, которые действительно важны

RFC 9411 перечисляет с десяток метрик, но в жизни инженеры и заказчики смотрят на конкретный набор показателей, которые действительно позволяют судить о качестве NGFW/NGIPS. Вот шесть самых прицельных.

Inspected Throughput (L2 или L3): сколько данных проходит через устройство с полной инспекцией. Измеряется в Gbit/s, желательно с точностью до ±0,01. Главное — не путать L2 и L3 между собой.
TCP / TLS CPS (Connections Per Second): сколько новых соединений в секунду обрабатывается. На высоком TPS с TLS 1.3 валятся даже мощные устройства — это сложный тест на криптографическую производительность. Некоторые производители могут снизить результат до 1 соединения в секунду.
Concurrent Sessions: максимальное количество одновременных соединений, которые может держать устройство. Важно знать реальную границу таблицы сессий, а не ту, что в паспорте.
Transactions per second (TPS): сколько новых L7-транзакций в секунду проходит через устройство. Это и есть настоящая «деловая» метрика, показывающая, как NGFW справляется с реальными задачами. И в реальной сети именно в этот параметр упирается NGFW. Например, если у вас много коротких DNS запросов, то для NGFW это серьезная нагрузка.
TTFB / TTLB: задержка до первого и последнего байта. Особенно важны при включённой DPI и URL-фильтрации. Для SLA значат больше, чем просто средняя скорость.
TLS Handshake Rate: если включено расшифрование TLS — это метрика номер один. От неё зависит, сколько новых и одновременных HTTPS-сессий выдержит система без потерь.
Эффективность защиты: процент успешно обнаруженных и заблокированных угроз из тестового набора CVE. Измеряется как отношение корректно заблокированных атак к общему количеству симулированных атак. В IXIA этот набор называется Strike.

Пороги допустимых отклонений: ошибки и дропы — не более 0,001%, вариация throughput — до 5%, отклонение по числу сессий — не более 10% от целевого значения.

Баланс производительности и защиты

Важно понимать, что зачастую существует обратная зависимость между производительностью и уровнем защиты. Следует анализировать оба аспекта в комплексе:

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

9. Пошаговый рецепт сборки: чек-лист инженера

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

Выберите топологию:

Вариант 1 — если генератор трафика умеет работать на сетевом уровне (L3);
Вариант 2 — если требуется подключить много портов или использовать внешние коммутаторы.

Проверьте совместимость оборудования: если у тестируемого устройства оптический интерфейс QSFP, а у генератора — SFP28, потребуются переходники или медиаконвертеры.
Соберите «паспорт стенда»: опишите версии операционных систем, прошивок, ключевых настроек, контрольные суммы конфигураций. Это необходимо для воспроизводимости.
Настройте устройство:

режим inline, функция «fail-open» отключена;
включите глубокую проверку пакетов (DPI), обнаружение вторжений (IDS/IPS), антивирусную защиту;
настройте внутренний удостоверяющий центр для расшифровки HTTPS;
загрузите базу гео-IP и добавьте базовые правила: например, «запретить трафик в Россию и Китай по TCP-портам 80 и 443».

Настройте ACL по классу нагрузки: воспользуйтесь таблицей XS / S / M / L из RFC 9411 и примените соответствующее количество правил на уровнях L3, L4 и L7.
Подготовьте профиль трафика:

смешанный поток HTTP/1 и HTTP/2 c TLS 1.3 с объектами от 1 до 256 КБ; Обычно в datasheet используют значение 64Кб;
соотношение IPv4/IPv6 — например, 80/20 или ваше рабочее значение или только IPv4; Обычно в datasheet все используют IPv4;
использование современных шифров, таких как TLS 1.3 с TLS_AES_128_GCM_SHA256.

Прогоните пробный тест: замерьте потери, задержки и стабильность стенда без тестируемого устройства. Сохраняйте данные в Excel, InfluxDB или любой системе мониторинга.
Запустите основной тест: фаза основной нагрузки (Sustain) должна длиться не менее 300 секунд — иначе результаты будут неустойчивыми.
Соберите данные: снимите журналы событий с устройства, сравните их с результатами генератора и убедитесь в совпадении ключевых показателей (пропускная способность, блокировки, срабатывания).
Сделайте себе кофе и подведите итоги: сформулируйте краткий отчёт о тесте до того, как менеджер спросит: «А где цифры?». Лучше быть на шаг впереди.

10. FAQ

Q: Нужно ли включать машинное обучение в NGFW во время теста?

A: RFC 9411 советует выключать, иначе результаты непредсказуемы. Но если задача — «как в живую», включайте и документируйте.

Q: Что делать, если генератор не поддерживает HTTP/3?

A: Либо обновить лицензии, либо ограничиться HTTP/2 и честно сказать об этом в отчёте. Скрывать такие вещи хуже любой низкой цифры.

Q: Почему вы советуете брать Sustain минимум 300 с?

Короткие тесты (60–90 с) не ловят GC/refresh таблиц у NGFW, искажают latency. 5 минут — компромисс между статистикой и временем.

11. Итоги: что делать завтра утром

Начните с простого списка:

проверить, есть ли изолированная площадка и сколько портов нужно;
обновить генератор трафикадо версии с QUIC и HTTP/3;
скачать RFC 9411, поставить закладки на стр. 6–11 и стр. 18 (Load Profile);
вынести в отдельный документ конфигурацию будущего DUT — потом спасибо скажете.

И самое главное — помните: хорошо поставленный эксперимент экономит недели споров «почему у вендора A получилось быстрее, чем у вендора B». Формализуйте каждую мелочь, и ваш стенд станет реальным конкурентным преимуществом.

Приложение: расшифровка терминов, использованных в статье

DUT — Device Under Test: тестируемое устройство. В нашем контексте — NGFW или NGIPS, на которое подаётся нагрузка.
SUT — System Under Test: тестируемая система в целом, включая всё окружение, ПО, виртуальные машины и компоненты вокруг DUT.
NGFW — Next-Generation Firewall: межсетевой экран нового поколения, способный анализировать трафик на уровне приложений (Layer 7), расшифровывать TLS и применять политики безопасности.
NGIPS — Next-Generation Intrusion Prevention System: система предотвращения вторжений, использующая сигнатуры, эвристики и поведенческий анализ для выявления угроз.
ACL или политика безопасности — Access Control List: список правил фильтрации трафика, задающих, какие соединения разрешены или запрещены.
TTFB — Time To First Byte: время от начала запроса до получения первого байта ответа. Важный показатель задержки при DPI и фильтрации.
TTLB — Time To Last Byte: время до получения последнего байта ответа. Часто используется для оценки полной длительности транзакции.
CPS — Connections Per Second: количество новых сетевых соединений в секунду, которое может обрабатывать устройство.
TPS — Transactions Per Second: количество новых соединений приложения в секунду, которое может обрабатывать устройство.
Throughput — пропускная способность: объём данных, который устройство может обрабатывать в секунду, без потерь и задержек.
QUIC — современный транспортный протокол на базе UDP, используемый в HTTP/3, с меньшими задержками по сравнению с TCP.
DPI — Deep Packet Inspection: глубокая проверка содержимого пакетов, в том числе расшифрованного трафика, на наличие угроз или нарушений политик.

Подготовлено с опорой на документ RFC 9411. Все названия продуктов приведены исключительно для примеров; автор не связан с производителями оборудования или ПО.

Авторы - Александр Антипов и Денис Батранков.