Тестирование NGFW: fast path, поддельный AppMix и ловушки PCAP-реплея

Это вторая часть из шести о том, как оценивать продукты сетевой безопасности. Часть 1 разобрала структурный разрыв в даташитах, общий для всей отрасли.

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

Fast path: функция, которая становится ловушкой в тесте

В большинстве корпоративных NGFW есть свои ASIC или выделенные процессоры безопасности. Эти чипы уводят часть трафика на аппаратный fast path в обход программного стека. Это законная и полезная архитектурная особенность. В правильных условиях она дает реальный прирост производительности с настоящей инспекцией.

Вся соль в словах «в правильных условиях».

Fast path работает лучше всего, когда трафик однородный, предсказуемый и простой: долгие сессии с крупными payload, ровный темп новых соединений, открытые или легко классифицируемые протоколы. В таких условиях ASIC берет основную работу, программный стек почти простаивает, throughput приближается к теоретическому пределу железа.

Реальный корпоративный трафик устроен иначе: короткие сессии, много мелких объектов, TLS 1.3 с шифрованным SNI и ESNI, нестандартные порты, проприетарные протоколы приложений, всплески установки новых соединений. На таком трафике покрытие fast path резко падает, и основную нагрузку несет программный стек.

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

Вендорские тестовые режимы: оптимизация, о которой не объявляют

Кроме честного поведения fast path есть более намеренная категория оптимизаций.

Вендоры знают, какими генераторами трафика обычно тестируют продукты безопасности. Знают профили, паттерны, типовые PCAP-файлы для оценок. Некоторые платформы реализуют оптимизации, которые срабатывают именно на этих известных профилях: кеширование результата DPI для сессий, побайтово совпадающих с уже виденными; сокращенный разбор для точных паттернов payload из распространенных тестовых наборов; правила fast path, привязанные к особенностям конкретных генераторов.

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

Вывод простой: устройство, которое хорошо отработало на знакомом инструменте, может не показать того же результата на методике, к которой его не готовили. Увидеть это можно только независимым тестом инструментом, который вендор не может изучить заранее.

Проблема AppMix: заданное вами распределение – не то, что прошло через устройство

Это самая тонкая техническая проблема в тестировании 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. Вы меряете их разными линейками и не знаете об этом.

PCAP-реплей: инструмент, который сообщает вендору, что придет

TRex и многие тестовые инструменты из Китая используют режим PCAP-реплея – воспроизводят заранее записанный трафик. Каждая сессия на L7 побайтово совпадает с любой другой сессией того же типа. Те же заголовки. Те же payload. Те же номера последовательностей, тот же SNI, те же паттерны URI – повторяются бесконечно.

Вендор, который тестирует ваш продукт, знает, какими инструментами пользуются покупатели. Знает PCAP-файлы. Знает паттерны payload. Оптимизировать под них ничего не стоит.

Что конкретно работает против детерминированного PCAP-реплея:

• Кеширование результата DPI. Если у двух TCP-сессий одинаковый payload, вторую классифицируют мгновенно из кеша вместо полного DPI. На реплее throughput резко выше, на реальных разнообразных сессиях выигрыша почти ноль.
• Правила fast path под известные паттерны. Сессию, совпавшую с известным точным паттерном из тестового PCAP, отправляют на fast path после минимальной инспекции. К сессиям с меняющимся payload это не применимо.
• Сокращенный разбор. Некоторые движки DPI используют сокращения для паттернов payload, которые часто встречаются в тестовом трафике. На новых данных приложений эти сокращения не работают.

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

Как выглядит хороший тест NGFW

Разница между хорошим и плохим тестом сводится к трем управляемым переменным.

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

Контроль AppMix по замкнутому циклу. Генератор измеряет реальный микс приложений на DUT и возвращает это в планирование сессий. Если измеренный микс уходит от целевого, веса подстраиваются на ходу. Без этого вы отчитываетесь о заданном миксе, а не об измеренном, и это разные числа.

Эффективность защиты под нагрузкой. Атаки подаются внутри фонового потока трафика, на реалистичном уровне нагрузки – не отдельно, с устройством на холостом ходу. Устройство, которое блокирует 99% атак при 5% загрузки и 70% при 80% загрузки, дает совсем другой уровень защиты, чем говорит заголовочная цифра детекта.

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

Дальше в серии – Пост 3: WAF, IPS и DLP. Почему тестировать инспекцию контента труднее, чем кажется, и как покрытие обхода отделяет продукты, которые вас защищают, от продуктов, которые защищают вас в демо.

TEST4NET LLC – независимая лаборатория тестирования сетей и безопасности, без коммерческих связей с вендорами безопасности. Напишите нам, чтобы обсудить оценку вашего NGFW.