Это вторая часть из шести о том, как оценивать продукты сетевой безопасности. Часть 1 разобрала структурный разрыв в даташитах, общий для всей отрасли.
NGFW — самая закупаемая, самая часто тестируемая и хуже всего оцениваемая категория корпоративной безопасности. Ловушки тестирования тут хорошо известны внутри индустрии и стабильно неизвестны тем, кто принимает решение о закупке.
В большинстве корпоративных NGFW есть свои ASIC или выделенные процессоры безопасности. Эти чипы уводят часть трафика на аппаратный fast path в обход программного стека. Это законная и полезная архитектурная особенность. В правильных условиях она даёт реальный прирост производительности с настоящей инспекцией.
Fast path работает лучше всего, когда трафик однородный, предсказуемый и простой: долгие сессии с крупными payload, ровный темп новых соединений, открытые или легко классифицируемые протоколы. В таких условиях ASIC берёт основную работу, программный стек почти простаивает, throughput приближается к теоретическому пределу железа.
Реальный корпоративный трафик устроен иначе: короткие сессии, много мелких объектов, TLS 1.3 с шифрованным SNI и ESNI, нестандартные порты, проприетарные протоколы приложений, всплески установки новых соединений. На таком трафике покрытие fast path резко падает, и основную нагрузку несёт программный стек.
Плохо спроектированный тест — или тест, спроектированный под удобный результат — гоняет трафик по первому сценарию. Устройство показывает отличные числа. В проде эти числа не живут.
Кроме честного поведения fast path есть более намеренная категория оптимизаций.
Вендоры знают, какими генераторами трафика обычно тестируют продукты безопасности. Знают профили, паттерны, типовые PCAP-файлы для оценок. Некоторые платформы реализуют оптимизации, которые срабатывают именно на этих известных профилях: кеширование результата DPI для сессий, побайтово совпадающих с уже виденными; сокращённый разбор для точных паттернов payload из распространённых тестовых наборов; правила fast path, привязанные к особенностям конкретных генераторов.
Такие оптимизации дают внушительные числа на бенчмарке. На реальном разнообразном трафике пользы от них мало или нет, а иногда они добавляют отличия в поведении, которые вылезают только под реалистичной нагрузкой.
Вывод простой: устройство, которое хорошо отработало на знакомом инструменте, может не показать того же результата на методике, к которой его не готовили. Увидеть это можно только независимым тестом инструментом, который вендор не может изучить заранее.
Это самая тонкая техническая проблема в тестировании NGFW и самая часто упускаемая.
Вы задаёте тест с целевым миксом приложений — скажем, 25% HTTPS, 20% HTTP, 15% DNS, 15% SMTP, 10% видео, 10% БД, 5% кастом — и ждёте, что именно это распределение пойдёт через устройство. Оно не идёт.
Бесплатные и open-source генераторы планируют новые сессии по заданным весам. Они не учитывают, сколько времени каждый тип протокола обрабатывается на DUT. Обработка средствами безопасности по протоколам неравномерна.
Тяжёлые протоколы — TLS со взаимной аутентификацией, SMTP с крупными вложениями, протоколы с долгой классификацией DPI — тратят больше времени на сессию на DUT. Они встают в очередь. Замедляются. Генератор об этом не знает и продолжает запускать новые сессии с заданной частотой. Лёгкие протоколы — обычный HTTP, DNS-запросы, мелкий UDP — обрабатываются быстро и проходят через устройство на полной скорости.
Итог: за время теста реальный микс на DUT смещается в сторону самых лёгких, быстрых протоколов. Устройство будто держит 10 Gbps с полной инспекцией. Оно правда держит 10 Gbps, но 60% из них это обычный HTTP и DNS, потому что заданные вами сессии SMTP и TLS стоят в очередях или отбрасываются.
Число throughput настоящее. Профиль трафика, на котором его сняли, не тот, что вы задумывали.
Почему без контроля AppMix сравнение вендоров бессмысленно. Устройство A обрабатывает тяжёлые протоколы эффективно: TLS и сложный DPI идут с умеренным overhead. В вашем тесте реальный AppMix устройства A близок к заданному. Устройство B отбрасывает тяжёлые сессии быстрее: overhead слишком высок, соединения отваливаются по таймауту. Реальный AppMix устройства B состоит в основном из лёгкого трафика. Устройство B показывает более высокий throughput.
Вы делаете вывод, что устройство B производительнее устройства A. Вы меряете их разными линейками и не знаете об этом.
TRex и многие тестовые инструменты из Китая используют режим PCAP-реплея — воспроизводят заранее записанный трафик. Каждая сессия на L7 побайтово совпадает с любой другой сессией того же типа. Те же заголовки. Те же payload. Те же номера последовательностей, тот же SNI, те же паттерны URI — повторяются бесконечно.
Вендор, который тестирует ваш продукт, знает, какими инструментами пользуются покупатели. Знает PCAP-файлы. Знает паттерны payload. Оптимизировать под них ничего не стоит.
Что конкретно работает против детерминированного PCAP-реплея:
Аргумент за бесплатные инструменты — цена. Честный подсчёт включает: инженерное время на сборку стенда, время на обход ограничений по масштабированию, время на проектирование методики — и стоимость многолетнего решения о закупке по результатам, к которым вендор подготовился. Это не дешёвый тест.
Разница между хорошим и плохим тестом сводится к трём управляемым переменным.
Динамическая генерация трафика. Каждая сессия генерируется на ходу — уникальные заголовки, токены, payload на L7. Две сессии одного типа не должны совпадать побайтово. Это отключает оптимизации на кеше и заставляет устройство классифицировать каждый поток с нуля, как оно будет делать в проде.
Контроль AppMix по замкнутому циклу. Генератор измеряет реальный микс приложений на DUT и возвращает это в планирование сессий. Если измеренный микс уходит от целевого, веса подстраиваются на ходу. Без этого вы отчитываетесь о заданном миксе, а не об измеренном, и это разные числа.
Эффективность защиты под нагрузкой. Атаки подаются внутри фонового потока трафика, на реалистичном уровне нагрузки — не отдельно, с устройством на холостом ходу. Устройство, которое блокирует 99% атак при 5% загрузки и 70% при 80% загрузки, даёт совсем другой уровень защиты, чем говорит заголовочная цифра детекта.
Это не экзотические требования. Это стандартная практика квалификации инфраструктуры у крупных операторов и в финансовых организациях. Всё это достижимо при правильных инструментах и методике.
Дальше в серии — Пост 3: WAF, IPS и DLP. Почему тестировать инспекцию контента труднее, чем кажется, и как покрытие обхода отделяет продукты, которые вас защищают, от продуктов, которые защищают вас в демо.
TEST4NET LLC — независимая лаборатория тестирования сетей и безопасности, без коммерческих связей с вендорами безопасности. Напишите нам, чтобы обсудить оценку вашего NGFW.