TLS расшифрован, Layer 7 вскрыт — но фаервол молчит. Почему?

Эпоха простых киберугроз давно миновала. Сегодняшние атаки в сфере информационной безопасности (ИБ) представляют собой многогранные и постоянно развивающиеся вызовы, требующие от специалистов по защите глубокого понимания и передовых инструментов. Проектирование и выбор эффективных защитных решений становится все более сложной задачей. В ответ на эту потребность классические межсетевые экраны (firewalls) и системы предотвращения вторжений (IPS) трансформировались в свои «следующие поколения» – NGFW (Next-Generation Firewall) и NGIPS (Next-Generation Intrusion Prevention System). Эти инновационные системы не ограничиваются базовой фильтрацией пакетов; они анализируют данные до седьмого уровня OSI, осуществляют расшифровку трафика, ведут подробные журналы и обладают расширенными возможностями для выявления и блокировки угроз.

Однако высокая функциональная сложность приводит и к более строгим требованиям при тестировании. Классические подходы, описанные когда-то в RFC 3511, уже не отражают всех особенностей, связанных с современными Layer 7-приложениями, сложным зашифрованным трафиком и динамическими атаками. Поэтому появился новый документ RFC 9411, который официально заменил старый RFC 3511 и описывает свежие методики тестирования NGFW и NGIPS, где делается акцент на актуальных для XXI века задачах: глубокой проверке HTTPS-трафика, анализе надежности инспекции и воспроизводимости тестов.

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

Эволюция требований: от RFC 3511 к RFC 9411

Когда-то брандмауэры проверяли лишь списки доступа (ACL) и могли блокировать трафик по IP-адресам и портам. Тестовые методики того времени, описанные в документах вроде RFC 3511, были относительно просты: нужно было проверить количество одновременно поддерживаемых соединений, базовую пропускную способность на уровне TCP и др. Но по мере роста значимости веб-приложений и с усложнением угроз (включая появление зашифрованного трафика HTTPS, повсеместное внедрение протоколов HTTP/2 и HTTP/3, а также QUIC), возможности классических фаерволов оказались недостаточны.

В новом документе RFC 9411 учтено, что добавилась глубокая проверка содержимого (DPI), появилась критическая необходимость инспекции шифрованного трафика, а также расширились механизмы веб-фильтрации, антивирусной и антиботнет-защиты и т.д. Старый подход, описывающий тестирование преимущественно на уровне пакетной передачи (L3/L4) с синтетическими нагрузками, не всегда раскрывает реальные способности NGFW/NGIPS. Отсюда возникла потребность в создании методик, которые позволяют:

• Работать с реальными сценариями использования (Layer 7).
• Учитывать влияние расшифровки HTTPS-трафика и соответствующих ключей шифрования.
• Точно измерять не только пиковые цифры пропускной способности, но и показатель “Connections per Second”, задержки транзакций и т.д.
• Закладывать в тест реалистичные профили трафика с миксом приложений (HTTP/1.1, HTTP/2, HTTP/3, потоковое видео, VoIP и пр.).
• Обеспечивать воспроизводимость результатов с учётом расширяющихся требований к безопасности.

Таким образом, основные изменения в требованиях объясняются усложнением сетевых сервисов и ростом значимости Layer 7. Стало важно тестировать не просто “скорость фильтрации пакетов”, но и “способность детектировать реальные угрозы, замаскированные в веб-трафике, при высоких объемах сеансов”.

Почему нужен новый подход и что даёт Layer 7?

Многие атаки в современных корпоративных сетях скрываются за SSL/TLS-шифрованием, а приложения всё чаще общаются по API и JSON, передавая критичные данные внутри HTTP/2, HTTP/3 или WebSocket-сессий. Если раньше можно было отфильтровать “опасные” TCP-порты и ощущать спокойствие, сегодня этого явно мало.

Новый подход тестирования учитывает ряд важных нюансов:

1. Широкий спектр протоколов и версий: NGFW теперь должен корректно работать и с классическим HTTP/1.1, и с ускоренным HTTP/2, и со свежеиспечённым HTTP/3 (QUIC). Каждая из реализаций несёт свои особенности: многопоточность, мультиплексирование, возможность 0-RTT и пр.
2. Инспекция шифрованного трафика (TLS Inspection): тесты должны проверять, насколько устройство способно быстро расшифровывать входящие и исходящие HTTPS-соединения, обрабатывать различные наборы шифров, при этом не теряя в пропускной способности и не вызывая массовых задержек (latency).
3. Reassembly и DPI: угроза может быть скрыта внутри многошагового HTTP-запроса или зафрагментирована, поэтому NGFW/NGIPS обязан собирать полный поток, анализировать контент (файлы, скрипты, SQL-инъекции и т.д.) и блокировать потенциальную атаку.
4. Актуальность Layer 7: многие политики безопасности завязаны на конкретных веб-приложениях и сервисах: Facebook, YouTube, почтовые сервисы, проприетарные API. Отсюда возникает потребность тестировать “фильтрацию по приложению”, анализируемую на уровне 7.

Как следствие, новый подход подразумевает расширенный набор KPI (ключевых показателей), который включает не только измерения Throughput (пропускная способность) и CPS (Connections Per Second), но и детальные метрики по времени ответа (Time to First Byte, Time to Last Byte), латентность HTTPS-транзакций, количество параллельных сессий, и корректность логирования событий (logging & reporting).

Принципы воспроизводимости и реалистичности тестов

Одним из важнейших моментов в RFC 9411 является воспроизводимость. Раньше лабораторные тесты часто критиковали за “тепличные” условия: синтетический нешифрованный трафик, упрощённые ACL и прочие упрощения. Сегодня акцент делается на приближенность к реальным сценариям:

• Изолированная среда: тестирование должно проводиться в замкнутом полигоне (testbed), чтобы внешние факторы, вроде случайного интернет-трафика или загрузки маршрутизаторов, не исказили результаты.
• Реалистичные профили трафика: вместо одного типа HTTP-запроса предлагают замешивать несколько категорий (например, 50% HTTPS, 30% HTTP, 10% QUIC, 10% прочие приложения), а в самих HTTP-транзакциях использовать разные размеры объектов: 1 KB, 16 KB, 64 KB, 256 KB и т.д.
• Различные сессии, IP-диапазоны, порты: клиента можно эмулировать не одним “виртуальным” IP-адресом, а тысячами уникальных, чтобы проверить, не упирается ли устройство в лимиты по таблицам MAC/ARP/ND или по отслеживанию состояний (stateful inspection).
• Актуальные шифры и ключи: в отличие от прошлых лет, когда основным шифром был TLS 1.2 с RSA 1024, сейчас тест нужно проводить с ECDHE и продвинутыми ключами (2048/4096, P-256/P-384), а также с поддержкой TLS 1.3.

Именно подобная “живая” нагрузка демонстрирует, способен ли NGFW/NGIPS справляться с задачами, которые в реальных условиях являются критическими. По итогам становится ясно, как система выдерживает тысячи HTTPS-сессий, не слишком ли она замедляет выдачу контента (TTFB, TTLB) и насколько успешно детектирует угрозы.

Методология тестов и ключевые показатели

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

1. Concurrent Connections (одновременные соединения)

Это число, показывающее, сколько TCP/QUIC-сессий одновременно может обслуживать устройство. Именно при пиковых нагрузках (скажем, при “шторме” запросов к серверу) становится ясно, есть ли риск “упасть” из-за недостатка ресурсов.

2. TCP/QUIC Connections Per Second (скорость установления новых соединений)

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

3. Application Transactions Per Second

Здесь мы переходим на уровень приложения (L7). Количество корректно завершенных транзакций (GET/RESPONSE) является мерилом того, как NGFW/NGIPS обрабатывает реальную логику HTTP, HTTPS или других протоколов. Если устройство “душит” транзакции, то для пользовательского опыта это может стать критичным.

4. Inspected Throughput (проверенная пропускная способность)

Это не просто объём прокачанного трафика, а именно объём проинспектированного на уровне безопасности трафика, прошедшего фильтры и отправленного далее. Показатель измеряется, например, в Гбит/с. Важно не путать его с “сырой” скоростью линка: если брандмауэр не успевает расшифровывать и анализировать весь объём, часть пакетов может теряться или отклоняться.

5. TTFB и TTLB

Time to First Byte (TTFB) — это задержка между отправкой клиентом первого пакета и получением первого байта ответа. А Time to Last Byte (TTLB) — между первым пакетом клиента и полным получением ответа. При наличии глубоких проверок, расшифровки TLS, антиботнет-фильтра и т.п. эти задержки могут ощутимо вырасти.

6. TLS Handshake Rate

Способность обрабатывать зашифрованные соединения (TLS 1.2, TLS 1.3) с определённым ключом шифрования, показывая, сколько успешных рукопожатий устройство может поддержать в секунду. Особенно критично при большом количестве краткоживущих HTTPS-сессий.

Построение тестового стенда и воспроизводимость

Чтобы избежать искажений, важно соблюдать определённые рекомендации, которые упоминаются в RFC 9411:

• Изоляция: минимизировать внешние воздействия — любая коммутаторная или маршрутизирующая инфраструктура, не задействованная в тестах напрямую, должна быть исключена из цепочки или сведена к минимуму.
• Адекватные IP-диапазоны: для тестовых целей используют зарезервированные диапазоны (например, 198.18.0.0/15 для IPv4 и 2001:2::/48 для IPv6), чтобы случайно не смешать “боевой” интернет-трафик и не нарушить работу сетей.
• Одинаковая конфигурация для серии тестов: один и тот же набор ACL, одинаковые включённые модули (IDS/IPS, антиботнет, антивирус и т.д.), чтобы корректно сравнивать результаты.
• Использование реалистичных шаблонов: например, генерировать 6–7 Мбит/с на один IP, тем самым добиваясь тысячи IP-адресов для 10 Гбит/с общего трафика. Или, наоборот, 0.1–0.2 Мбит/с на IP, если нужно протестировать экстремальное число IP-клиентов.

Для надежной воспроизводимости рекомендуется сначала провести референсный тест без DUT/SUT (или с минимальной конфигурацией “fast forward”), чтобы понять, насколько сама тестовая установка способна формировать нужный объём трафика.

Актуальность для архитекторов и формирующих требования

Архитекторы ИБ, отвечающие за выбор NGFW/NGIPS, часто сталкиваются с ситуацией, когда цифры из маркетинговых описаний “до 10 Гбит/с шифрованного трафика” не совпадают с реальностью. Именно поэтому так важно опираться на единый набор методик, где детально прописано, как и что измерять:

1. Ясно формулировать цели (черезput, задержки, сессии, транзакции).
2. Грамотно составлять профиль трафика (проценты HTTP/HTTPS, размер объектов, многопоточность, шифры).
3. Однозначно фиксировать конфигурацию NGFW/NGIPS (какие модули включены, какое логйрование, какие ACL, тип TLS Inspection).
4. Проводить тесты в повторяемых условиях и фиксировать ключевые метрики для сравнения нескольких решений.

Благодаря такому подходу легко оценивать, насколько одно устройство реально «быстрее» или «надёжнее» другого в одинаковых сценариях. Для закупочной комиссии или тендера это позволяет формировать чёткие технические задания, где прописано: “Устройство должно выдерживать N HTTPS-сессий в секунду с полным DPI и антивирусным сканированием, обеспечивая при этом средний TTFB не более M миллисекунд”.

Реалистичность vs. синтетика и проблема ложных тревог

Иногда для упрощения теста весь “плохой” трафик запускают отдельно, а “хороший” — отдельно. Но по рекомендации RFC 9411 лучше смешивать в единый поток, чтобы устройство NGFW/NGIPS распознавало угрозы в “живой среде”. Это помогает выявить ложные срабатывания (false positives), когда устройство начинает блочить безобидные HTTP-запросы, а также проверять, не просаживается ли пропускная способность при включении защитных модулей.

Отдельно стоит упомянуть ложьные пропуски (false negatives), то есть ситуации, когда система пропускает вредоносный трафик. В рамках тестов безопасности важно, чтобы NGFW/NGIPS не пропустил эмулированные уязвимости или не отреагировал на сигнатуру экплойта. Именно поэтому в RFC 9411 предусмотрена методика Security Effectiveness Evaluation, когда в нагруженный фоновый трафик вставляются эмуляции реальных CVE. Для теста могут использоваться последние CVE с рейтингом High (7–10 по CVSS), и смотрится, как устройство отрабатывает блокировку.

Процесс тестирования: ключевые этапы

Если обобщить основные рекомендации RFC 9411, то можно выделить следующие этапы испытаний NGFW/NGIPS:

1. Развертывание и первичная проверка

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

2. Настройка DUT/SUT

• Включение необходимых модулей (IDS/IPS, Anti-Malware, GeoIP-фильтра и др.).
• Установка реалистичных ACL в соответствии с предполагаемым размахом сети (XS, S, M, L — классификация, рекомендованная в RFC 9411).
• Включение TLS Inspection, если требуется инспекция шифрованного трафика.
• Отладка логиирования и политики уведомлений.

3. Формирование реалистичного профиля нагрузки

• Определение процентного соотношения IPv4/IPv6, распределения HTTPS, HTTP, QUIC и т.д.
• Задание размеров объектов, сценариев одновременных подключений, числа GET-запросов на соединение.
• Установка временных параметров (Ramp up, Sustain, Ramp down) и времени сбора статистики.

4. Измерение производительности

• Нахождение максимального Throughput (Inspected) с учётом включенных функций.
• Определение Connections Per Second (CPS/QUIC CPS) при разных размерах объектов.
• Замер задержек TTFB и TTLB на существенной выборке, измерение TLS Handshake Rate.
• Тестирование Concurrent Connections, когда устройство держит тысячи или миллионы параллельных сессий.

5. Проверка эффективности безопасности (Security Effectiveness)

• Одновременная подача фонового “чистого” трафика и вредоносных CVE-примеров.
• Проверка, сколько угроз (включая шифрованные) устройство блокирует, а какие могут прорваться.
• Контроль ложных срабатываний (false positives), когда легитимный трафик блокируется ошибочно.

Выводы и рекомендации

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

Для архитектора ИБ или руководителя проекта такие тесты дают уверенность, что при выборе решения учтены особенности реального сетевого окружения. Вместо безликих заявлений “10 Гбит/с на брошюре” можно увидеть метрики: “8 Гбит/с инспектированного HTTPS”, “40 тыс. одновременных HTTP/2-сессий”, “TTFB в 80 мс при 50% загрузке” и т.д.

Таким образом, новые стандарты и принципы из RFC 9411 становятся основой для объективного сравнения разных NGFW/NGIPS и помогают грамотно формировать требования к закупкам и интеграционным проектам. С ними проще прогнозировать поведение устройства в высоконагруженных средах, где каждый процент потерь трафика или дополнительная задержка могут стоить бизнесу дорого.

Если вы формируете требования к тестированию NGFW или NGIPS, опирайтесь на эти рекомендации, составляйте реалистичный профиль трафика с учётом IPv4/IPv6, HTTPS/QUIC, разных шифров и динамической загрузки. Не забывайте проверять и сами защитные возможности: включите сигнатуры IPS, антивирусные движки, правила DLP и антиботнет, чтобы понять реальную картину. И, конечно, логируйте результаты: детальные отчёты по Connections per Second, TTFB, числу блокированных эксплойтов и уровню ложных тревог куда информативнее, чем одна строка “пропускает 10 Гбит/с”.

Наконец, для повышения достоверности и регулярного обновления можете обратиться к организации NetSecOPEN, которая разрабатывает и поддерживает методы тестирования сетевой безопасности в открытом формате. Или изучите примеры на IETF, где и публикуются соответствующие RFC. Главная идея — не бояться современных сложностей и тестировать NGFW/NGIPS так, как их будут эксплуатировать в реальности.

Полезные ссылки и материалы

• RFC 9411 — Benchmarking Methodology for Network Security Device Performance
• RFC 3511 — Устаревший стандарт, ранее описывавший методику тестирования фаерволов
• NetSecOPEN — стандартизированное тестирование в области сетевой безопасности
• IETF — крупнейшая организация, занимающаяся стандартизацией интернет-протоколов и RFC

Надеемся, что изложенный материал поможет вам при планировании тестов и выборе NGFW/NGIPS для вашей инфраструктуры!