Skip to content

Методология · Устройства безопасности

RFC 9411: тест firewall со всеми включенными функциями

RFC 9411 заменил RFC 3511 в 2023 году. Он тестирует firewall так, как вы его эксплуатируете: inline, с включенными TLS-инспекцией и IPS, на реальном HTTP- и HTTPS-трафике, с бюджетом ошибок 1 транзакция на 100 000. На этой странице: как мы проводим тест в CloudLAB и что вы получаете в отчете.

  • 9 бенчмарков: 5 по HTTP, 4 по HTTPS с рекомендованными наборами шифров
  • Фаза sustain 300 с на каждый прогон, KPI снимаются не реже чем раз в 2 с
  • Результат засчитывается, только если сбойных транзакций и неожиданных RST меньше 0,001 %
Получить тест-план для NGFW К 9 тестам
OFFERED LOAD TRAFFIC LOAD PROFILE · RFC 9411 §4.3.4 TARGET OBJECTIVE 10% · QUALIFICATION KPIs MEASURED HERE SAMPLE INTERVAL UNDER 2 s INIT ≥ 5 s RAMP UP SUSTAIN ≥ 300 s RAMP DOWN COLLECT В отчет попадает только фаза sustain

Каждый прогон RFC 9411 идет по этому профилю. Измерения только в фазе sustain: минимум 300 с, все KPI записываются там и нигде больше.

Какой RFC

Метод один: RFC 9411. RFC 3511 остался в истории.

RFC 3511 датирован 2003 годом и мерил firewall как пакетный фильтр: IP throughput, скорость соединений, набор правил. В 2023 году RFC 9411 сделал его устаревшим. Все на этой странице про RFC 9411; 3511 всплывает, только когда его все еще цитирует тендер.

Inspected throughput

KPI считает биты, которые были проверены, разрешены и доставлены, пока DUT инспектирует трафик. По умолчанию на уровне L2; если меряете на L3, отчет обязан это указать: цифры не сравнимы.

Одна конфигурация на все 9 тестов

Конфигурация DUT фиксируется до первого теста и не меняется до последнего. Каждая выключенная рекомендованная функция попадает в отчет вместе с причиной и влиянием на производительность.

Худший случай намеренно

Полный TLS handshake на каждом соединении, session resumption выключен, PSH на всем трафике. Метод ищет нижнюю границу устройства: цифру, которую ваши пользователи получат в плохой день.

Скачать бесплатно

Шаблон тест-плана RFC 9411

План, который мы заполняем перед каждым тестом межсетевого экрана и NGFW, в PDF: класс устройства и список правил, функции защиты, которые нужно включить, 9 тестов с размерами объектов и наборами шифров, критерии валидации и лист результатов

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

PDF на английском. Нужна только почта.

Тестовый стенд

Две половины генератора трафика и одна коробка между ними

Вариант 1 из RFC: эмулированные клиенты с одной стороны, эмулированные серверы с другой, DUT inline. Никаких внешних коммутаторов и маршрутизаторов, если к этому не вынуждает число портов: они добавляют свою задержку и уменьшают ARP-таблицу, с которой должен справляться DUT.

TEST EQUIPMENT · CLIENTS EMULATED ROUTER (OPTIONAL) EMULATED BROWSERS HTTP/1.1 · HTTP/2 · HTTP/3 over QUIC TLS 1.2 / 1.3, full handshake, no resumption MSS 1460 · window 65535 · cwnd ≤ 10 MSS Source ports 1024–65535, PSH on 1,400–1,700 CLIENT IPs PER 10 Gbit/s GET · TLS DUT / SUT INLINE · FAIL-OPEN OFF · FLOW LOGGING ON One configuration for all 9 tests ACL set sized by class XS / S / M / L NGFW · NGIPS · PHYSICAL OR VNF TLS INSPECTION IDS/IPS ANTI-VIRUS ANTI-SPYWARE GEO ANTI-BOTNET ANTI-EVASION APP-ID LOGGING 200 OK TEST EQUIPMENT · SERVERS EMULATED ROUTER (OPTIONAL) EMULATED SERVER POOL HTTP on :80, HTTPS on :443, HTTP/3 on UDP TLS 1.2 or newer, 16 KB records No session tickets, no session cache One IP per FQDN per test port IPv4 / IPv6 SPLIT MIRRORS THE CLIENTS REFERENCE PRE-TEST FIRST тот же стенд, вместо DUT патч-корд или режим fast-forward · потери, задержка и запас генератора записываются до подключения DUT

Эмулированные клиенты

MSS 1460 (IPv4) и 1440 (IPv6), окно 65 535 байт, начальное окно перегрузки до 10 MSS, 3 повтора, порты источника 1024–65535. Число клиентов задает цель: около 1 400–1 700 IP на 10 Gbit/s для периметра предприятия, 50 000–100 000 для абонентского профиля.

DUT / SUT

Inline, fail-open выключен, рекомендованные функции включены, логирование потоков включено, геофильтрация там, где коробка ее умеет. Набор ACL задается классом: от 5 правил по приложениям и 50 блокировок по IP и портам на XS до 50 и 500 на L. Сначала блокирующие правила, разрешающие в конце, и ни одно из них не задевает тестовый трафик.

Эмулированные серверы

HTTP/1.1 и HTTP/2 на портах 80 и 443, HTTP/3 по UDP. TLS 1.2 или новее, лимит записи 16 KB, без session tickets и session cache, один IP на FQDN сервера на тестовый порт. Соотношение IPv4 и IPv6 повторяет клиентскую сторону.

До подключения DUT: reference pre-test

Прогоняем HTTP-профиль с самым маленьким объектом через патч-корд (или DUT в режиме fast-forward), записываем потери и задержку самого стенда и убеждаемся, что генератор перекрывает заявленную производительность DUT с запасом. Если стенд не бьет даташит, результат DUT ничего не значит. За виртуальными стендами дополнительно следим: шумные соседи, миграции VM и тепловой троттлинг в течение 300 с.

Конфигурация DUT/SUT

Что должно быть включено до первого пакета

Раздел 4.2 RFC. Список ниже для NGFW; у NGIPS он короче (без антивируса и ACL), но с DPI и anti-malware. Движки на машинном обучении и поведенческом анализе выключаются: метод не умеет их воспроизводить.

Рекомендовано: включено на каждом тесте

  • TLS Inspection
  • IDS / IPS
  • Anti-Virus
  • Anti-Spyware
  • Anti-Botnet
  • Anti-Evasion
  • Application Identification

Выключить что-то из этого можно, если внедрению это не нужно. Тогда отчет указывает, что именно, почему, и что с включенной функцией результат был бы ниже. Application identification должен быть настроен на распознавание приложений из профиля трафика.

Опционально: по внедрению

  • Web Filtering
  • Data Loss Protection
  • DDoS Protection
  • Certificate Validation

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

Список доступа по классу устройства (Table 4 RFC)

Класс определяется по throughput из даташита вендора. Правила идут в этом порядке, конкретные запреты сверху, и ни одно не должно совпасть с тестовым трафиком.

Правило XS
≤ 1 Gbit/s		 S
1–5 Gbit/s		 M
5–10 Gbit/s		 L
> 10 Gbit/s
Блокировка по приложению (приложения, которых нет в профиле трафика)5102050
Блокировка по IP источника и порту назначения (порты, не используемые в тесте)2550100250
Блокировка по подсети источника и назначения (подсети, не используемые в тесте)2550100250
Разрешение по приложению (половина приложений из профиля)10101010
Разрешение по клиентской подсети и порту, затем по клиентской подсетиминимум 1 правило на клиентскую подсеть, в обоих типах правил

Классы: XS до 1 Gbit/s, S от 1 до 5 Gbit/s, M от 5 до 10 Gbit/s, L выше 10 Gbit/s (Appendix B). Ваше число правил может быть больше; RFC задает минимум. Если коробка построена без ACL (большинство NGIPS), тестируем без них и пишем об этом в отчете.

Раздел 7 RFC

9 тестов, у каждого своя цель и свои ворота

5 идут по открытому HTTP, 4 повторяют схему по HTTPS с рекомендованными наборами шифров. Каждый тест начинается с 10 % цели, затем идет на цели, затем итерациями ищет максимальную нагрузку, которая еще проходит критерии валидации.

  1. 7.1Профиль приложений

    Throughput на профиле прикладного трафика

    Inspected throughput и транзакции в секунду на реалистичном профиле: например, NetSecOPEN enterprise perimeter или снимок вашего периметра. Самое близкое к рабочему дню, что можно уместить в одну цифру.

    Цель: line rate портов DUT или ваша цифра по внедрению · TTLB отчитывается с размерами объектов профиля
  2. 7.2HTTP

    TCP-соединений в секунду

    Один GET на соединение, сразу FIN. Показывает, как быстро таблица сессий, поиск по политике и конвейер логирования принимают новые потоки. Маленькие объекты нагружают control path, на 64 KB в картину входит throughput.

    Объекты: 1, 2, 4, 16 и 64 KB, один размер на итерацию · цель: CPS из даташита или ваш
  3. 7.3HTTP

    HTTP throughput

    Устойчивый inspected throughput при разных размерах объекта. Маленькие объекты показывают цену движков инспекции на запрос; 256 KB показывает, что тянет data path, когда движкам почти нечего делать.

    Объекты: 1, 16, 64, 256 KB плюс смешанный набор от 0,2 KB · throughput и транзакции/с на каждый размер
  4. 7.4HTTP

    Задержка HTTP-транзакции

    Time to first byte и time to last byte, пока коробка работает на половине того, что нашли тесты 7.2 и 7.3. Задержка на 50 % нагрузки: цифра, которую чувствуют пользователи; задержка в простое: цифра из даташита.

    TTFB и TTLB min / avg / max · 1 и 10 транзакций на соединение · объекты 1, 16 и 64 KB
  5. 7.5HTTP

    Емкость одновременных TCP-соединений

    Сколько сессий DUT держит открытыми одновременно, ничего не сбрасывая и не обрывая. Ramp-up идет с темпом CPS из 7.2, чтобы в предел уперлось именно количество сессий.

    Время ramp-up = целевое число соединений ÷ максимальный CPS · sustain проверяет, что число держится в пределах 10 %
  6. 7.6HTTPS · с TLS-инспекцией

    TCP- или QUIC-соединений в секунду, HTTPS

    Тест 7.2 с полным TLS handshake на каждом соединении и DUT, расшифровывающим посередине. Прогоняется по каждому набору шифров и длине ключа; RSA 4096 с P-384 бьет по proxy-инспекции больнее всего.

    Объекты: 1, 2, 4, 16 и 64 KB · скорость TLS handshake измеряется на объекте 1 KB
  7. 7.7HTTPS · с TLS-инспекцией

    HTTPS throughput

    Тест 7.3 поверх TLS. Именно эту цифру кладут рядом с даташитом: расшифровать, проверить, зашифровать обратно на объектах 64 KB с включенными IPS и application identification.

    Итерации покрывают ECDHE с AES-128-GCM и AES-256-GCM, RSA 2048 и 4096, P-256 и P-384
  8. 7.8HTTPS · с TLS-инспекцией

    Задержка HTTPS-транзакции

    TTFB и TTLB, пока TLS-прокси делает свою работу на 50 % нагрузки. Сильнее всего сдвинется TTFB: handshake теперь происходит дважды, до DUT и после него.

    Те же сценарии, что в 7.4 · min / avg / max на каждый размер объекта и набор шифров
  9. 7.9HTTPS · с TLS-инспекцией

    Емкость одновременных TCP- или QUIC-соединений, HTTPS

    Открытые TLS-сессии, удерживаемые одновременно. С TLS 1.3 DUT работает как middlebox, хранящий сертификаты и ключи, так что в лимит упираются и таблица сессий, и ключевой материал.

    Ramp-up с темпом HTTPS CPS из 7.6 · отклонение меньше 10 % в течение sustain

Процедура

Каждый тест ищет потолок, и на каждом шаге стоят ворота

RFC не дает отчитаться цифрой, по дороге к которой что-то сломалось. 4 хода, строго в этом порядке, для каждого из 9 тестов и каждого размера объекта.

  1. 00

    Reference pre-test

    Стенд без DUT. Записываем потери, задержку и запас генератора. Повторяем, если в стенде что-то меняется по ходу проекта.

  2. 01

    Квалификация на 10 %

    Начальная цель: 10 % от целевой. Все KPI должны пройти критерии на этой легкой нагрузке, иначе тест останавливается здесь и мы идем разбираться с конфигурацией.

  3. 02

    Прогон на цели

    Полный профиль нагрузки на целевом значении: цифра из даташита, line rate или ваше требование. Прошли в рамках критериев? Это и есть результат.

  4. 03

    Итерация к максимуму

    Не дотянули до цели или нарушили критерий? Шаг вниз и повтор, пока не найдется максимальная нагрузка, которая проходит. Финальная итерация идет полные 300 с sustain.

Ворота валидации, под контролем всю фазу sustain

  • 0,001 %

    Максимальная доля сбойных транзакций: все, что не 200 OK, от всех попыток. 1 на 100 000.

  • 0,001 %

    Максимальная доля соединений, оборванных неожиданным RST от DUT. Firewall, который сбрасывает сессии под нагрузкой, прогон не проходит.

  • 5 %

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

  • 10 %

    Максимальное отклонение числа одновременных соединений в установившемся режиме. Подтверждает, что DUT открывает и закрывает сессии в одном темпе.

Профиль нагрузки за каждым прогоном

  • Init, от 5 сARP/ND и обучение MAC. Клиенты молчат, серверы готовы. Без измерений.
  • Ramp upОт 0 до целевого значения, достаточно медленно, чтобы генератор не превысил собственные лимиты DUT по CPS и throughput. Без измерений.
  • Sustain, от 300 сПостоянная нагрузка, постоянное число клиентов. Единственная фаза, которая измеряется: все KPI пишутся непрерывно, интервал выборки меньше 2 с.
  • Ramp down и collectionТрафик обратно к 0, затем генератор сводит счетчики и статистику в данные отчета. Без измерений.

Результат работы

Что ложится вам на стол

Раздел 6 RFC описывает отчет. Наш следует ему и добавляет сырой материал, чтобы аудитор, инженер вендора или ваша команда перепроверили каждую цифру, не звоня нам.

Бенчмарки по каждому тесту

  • Inspected throughput в Gbit/s с 2 знаками, в скобках kbit/s
  • TCP- или QUIC-соединений в секунду, на каждый размер объекта
  • Прикладных транзакций в секунду (только 200 OK)
  • Скорость TLS handshake по наборам шифров и длинам ключей
  • Удерживаемые одновременные TCP- или QUIC-соединения
  • TTFB и TTLB: минимум, среднее, максимум, на каждый размер объекта

Контекст, который делает цифры сравнимыми

  • Вендор, модель, прошивка, скорости портов DUT; для VNF: ядра, RAM, DPDK или SR-IOV, pinning, NUMA, гипервизор
  • Каждая включенная функция и причина для каждой выключенной рекомендованной
  • Модель генератора, версия ПО, параметры TCP и TLS, наборы шифров
  • Профиль трафика, соотношение IPv4 и IPv6, диапазоны адресов клиентов и серверов, метод перебора
  • Результаты reference pre-test: потери и задержка самого стенда
  • Время и дата каждого прогона, по фазам
RFC 9411 · TEST REPORT SUSTAIN 300 s · IPv4 100% 7.1Throughput, app mix 7.2TCP CPS, 1 KB object 7.4TTLB, 64 KB object 7.6HTTPS CPS, ECDHE-RSA 2048 7.7HTTPS throughput, 64 KB 7.9HTTPS concurrent capacity 6.20 Gbit/s 48,000 /s 41 ms avg 9,800 /s 5.40 Gbit/s 1.8 M transactions 5,900 /s · TTLB with mix object sizes failed 0.0003% · RST 0.0001% · rate dev 1.2% TTFB 9 / 12 / 31 ms · 10 transactions per connection TLS handshakes 9,800 /s · full handshake, no resumption AES-128-GCM · P-256 · inspection on RST 0.004% at 2.0 M: criterion b failed, 1.8 M reported ATTACHED DUT CONFIG EXPORT FEATURES + REASONS PRE-TEST RESULTS RAW COUNTERS · PCAP Значения иллюстративные. В вашем отчете ваши цифры, по каждому размеру объекта и набору шифров.

От нас, сверх RFC

  • Сырые счетчики и pcap с каждой итерации, чтобы цифры можно было вывести заново
  • Экспорт конфигурации DUT в том виде, в каком тестировали, с набором ACL
  • Рекомендация на 1 страницу: какая коробка, на какой нагрузке, с чем включенным

Из практики

40 Gbit/s в даташите. Каким методом их получили?

Заголовочная цифра большинства NGFW берется из прогона в духе RFC 3511: большие IP-пакеты, горстка сессий, инспекция выключена. Прогоните ту же коробку по RFC 9411 с включенными TLS-инспекцией, IPS и application identification, объектами HTTPS 64 KB и полным handshake на каждое соединение, и inspected throughput окажется на 6 Gbit/s. Коробка намерила 40 одной линейкой и 6 другой.

Купите под 40, и периметр окажется меньше нужного в 6–7 раз. Мы видели, что бывает дальше: первая авария, и инженер тихо выключает инспекцию, чтобы она прошла. Заказ подписан, защита наполовину исчезла, и нигде это не записано.

Тестируйте той линейкой, с которой будете жить

SAME BOX · TWO RULERS RFC 3511 · IP THROUGHPUT 1518-byte packets, a handful of sessions, inspection off 40 Gbit/s RFC 9411 · INSPECTED THROUGHPUT HTTPS 64 KB, full handshake, TLS inspection + IPS + App-ID on 6 Gbit/s SIZING GAP 6.7× Купили под 40, работаете на 6: периметр мал еще до первого пользователя

Как мы это делаем

RFC 9411 как услуга: в CloudLAB или у вас

Вы приносите DUT или шорт-лист; мы приносим генератор, метод и отчет. Объем согласуем до первого пакета: какие из 9 тестов, какие размеры объектов, какой класс устройства, соотношение IPv4 и IPv6, ваш профиль трафика или NetSecOPEN.

Load & Performance Testing

9 бенчмарков на коммерческом генераторе под ваш стенд, от 1G до 100G. Физическая коробка, скоммутированная в Армении, или ваш виртуальный NGFW на наших хостах, счетчики в реальном времени в браузере.

Запросить тест-план

Security & Resilience Testing

Appendix A перед разделом 7: 500 и больше CVE с CVSS от 7 до 10, в открытом виде и внутри TLS, с evasion-техниками, на фоне рабочей нагрузки. Что заблокировано, что прошло и что сам DUT об этом отчитал.

Обсудить набор CVE

Test Plan & Methodology Design

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

Заказать тест-план

Hosted DUT Testing & Remote Lab Access

Пришлите коробку или загрузите VM, смотрите прогон из браузера, оставьте себе тестовые наборы. Или забронируйте время в CloudLAB с уже настроенным методом RFC 9411: прогон ведут наши инженеры, ваша команда смотрит и задает условия.

Войти в CloudLAB
  • Независимость: мы продаем тест, вендор продает коробку
  • Один метод и один стенд для каждого кандидата из шорт-листа
  • Сырые результаты и тестовые наборы остаются у вас

По теме

FAQ

Вопросы, которые задают до первого прогона

В тендере все еще написано RFC 3511. Сможете протестировать по нему?

Да. RFC 3511 устарел, но тендерная документация есть тендерная документация. Прогоняем набор 3511 для бумаг и набор 9411 для решения, а отчет объясняет, почему цифры расходятся.

Наш NGFW виртуальный. Метод меняется?

Тесты те же; отчет длиннее. CPU и RAM хоста, закрепленные ядра, NUMA-узел, DPDK или SR-IOV, версия гипервизора: все это идет в отчет, потому что результат vNGFW без них не воспроизвести. Хост во время sustain тоже под наблюдением: шумные соседи.

Обязательно включать TLS-инспекцию?

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

А если генератор медленнее DUT?

Тогда теста нет. Reference pre-test существует ровно для этого: стенд обязан превосходить заявленную производительность DUT до его подключения. Мы подбираем генератор и число портов под эту планку, а результат pre-test входит в отчет.

Можно принести свой профиль трафика?

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

Test. Compare. Decide.

Пришлите модель или шорт-лист и класс, под который считаете сайзинг. В ответ получите тест-план RFC 9411: тесты, размеры объектов, наборы шифров, лабораторные дни и цена. Дальше коробка едет на стенд, а даташит в ящик стола.

Запросить тест-план Войти в CloudLAB

Пришлите шорт-лист

Методика есть. Осталось получить цифры.

Назовите модели и ключевые показатели. Инженер ответит в течение рабочего дня черновиком плана тестов и оценкой.

Удобнее в чате? Написать инженеру в WhatsApp

Мы используем присланное только чтобы вам ответить. См. политику конфиденциальности.