Нагрузочное тестирование NDR: как проверить реальную производительность

Наша группа продуктовых исследований регулярно тестирует классические средства сетевой защиты информации — NGFW, IPS. Для этого существуют давно отработанные практики. Например, практически все методики проверки NGFW в зарубежных и отечественных компаниях опираются на стандарты RFC 9411 и RFC 2544 от Internet Engineering Task Force.

К сожалению, с NDR всё иначе: открытых стандартов нагрузочного тестирования для этого класса СЗИ, кажется, просто не существует, а готовые сценарии от NGFW для них не совсем подходят. Поэтому мы разработали собственную методику и делимся ею с ИБ-сообществом.

В этой статье мы не сравниваем конкретные NDR между собой и не доказываем, что один продукт «быстрее» другого. Цель другая: показать воспроизводимый подход к нагрузочному тестированию NDR. Материал пригодится инженерам ИБ, архитекторам SOC, специалистам по тестированию СЗИ, пресейлам и техлидам — всем, кому нужно получить реальные цифры устойчивости NDR под нагрузками, а не «маркетинговую» пропускную способность.

Разберем, чем такое тестирование отличается от классических испытаний NGFW и IPS, как собрать стенд, какие метрики снимать на стороне самого NDR и почему недостаточно статистики генератора трафика. Покажем, как формулировать критерии прохождения теста и как отделять ограничения продукта от ограничений стенда. В конце покажем практический пример того, как методика помогает найти узкое место в производительности NDR. 

Почему NDR не тестируют как NGFW

NDR (Network Detection and Response) — отдельный класс средств обнаружения вторжений и реагирования на ИБ-события, который получает данные от инфраструктуры через сетевые брокеры и прочие устройства, имеющие возможность зеркалирования. 

Если NGFW и IPS устанавливаются в разрыв — весь трафик проходит через них, и пропускная способность измеряется при прохождении сквозь устройство, то NDR не маршрутизирует трафик, а проводит его анализ и отдает выявленные события на внешние системы мониторинга (SOC, EDR и другие). Следовательно, для тестирования NDR нужен отдельный стенд и свои методы съема метрик.

В NDR можно разделить технологии доставки и обработки трафика на два уровня: как трафик попадает в NDR и то, как он обрабатывается внутри системы. Поэтому в методике мы отдельно фиксируем способ доставки трафика в NDR и отдельно механизм его обработки внутри продукта.

На уровне доставки NDR получает копию трафика от маршрутизаторов, коммутаторов, сетевых брокеров или других устройств, поддерживающих зеркалирование через технологии SPAN/TAP, ERSPAN или потоковую телеметрию вроде NetFlow. SPAN и TAP копируют трафик с физического или логического сегмента сети. ERSPAN решает ту же задачу, но доставляет зеркалированный трафик через GRE-туннель. В то же время NetFlow вместо полной копии пакетов передает агрегированную информацию о сетевых потоках. 

На уровне приема и обработки пакетов NDR также может использовать разные механизмы. В нашем случае это libpcap, где захват трафика идет через сетевой стек ОС, и DPDK, где пакеты принимаются в обход ядра для снижения накладных расходов. 

В этой статье будем рассматривать методику на примере тестирования Гарда NDR в режиме Standalone, однако наша методика подходит для любых подобных систем.

Архитектура тестового стенда

В качестве генератора трафика мы используем open-source инструмент Cisco TRex в связке с InfluxDB и Grafana для хранения и представления необходимых метрик для нагрузочного тестирования.

TRex настроен на генерацию в режиме loopback: трафик подается в замкнутом контуре, с одного интерфейса сетевой карты на другой. В разрыв этого подключения установлен TAP, который зеркалирует TX- и RX-трафик на NDR.

Впрочем, вместо TAP можно использовать L3-коммутатор или маршрутизатор. В такой конфигурации нагрузочный трафик с генератора отправляется на коммутатор, как на DUT, а тот, в свою очередь, будет выполнять функции маршрутизации (обратно на генератор) и зеркалирования трафика (на NDR). Также для генерации вредоносного трафика был подключен еще один канал связи, об этом чуть позже.

Проблема сбора метрик с NDR

Так как NDR агрегирует и анализирует смешанный трафик, в качестве тестовой нагрузки хорошо подходит EMIX-профиль корпоративного трафика с таким распределением: 

TRex собирает статистику по отправленному и полученному трафику и по дропам, но это показатели сетевой карты генератора. Если смотреть только на TRex, легко принять ограничение NDR за проблему сети или, наоборот, не заметить потери внутри самого устройства. Так что те же значения необходимо снимать на стороне самого NDR.

В Гарда NDR реализована следующая логика обработки данных: сначала трафик поступает на физические интерфейсы сетевой карты (NIC), затем передается для последующего анализа на логические интерфейсы — кольцевые буферы, далее распределяется на анализ между модулями безопасности. Весь обработанный объем трафика фиксируется во внутреннем лог-файле на всех этапах.

Чтобы снимать эти данные автоматически, мы написали программу-расширение для Cisco TRex. Она подключается к Гарда NDR по SSH, парсит внутренний лог-файл и складывает эти значения вместе с метриками TRex в базу данных InfluxDB, откуда их забирает Grafana.

Методика тестирования

Когда стенд собран, а сбор метрик настроен, можно переходить к самой методике. Ее задача — найти последнюю устойчивую точку, в которой NDR принимает трафик, не превышает заданные пороги по ресурсам, не теряет пакеты сверх допустимого уровня и продолжает выполнять функции безопасности. Просто загрузить СЗИ до отказа недостаточно. 

Алгоритм тестирования устроен как последовательный поиск максимальной устойчивой нагрузки.

Сначала выбираем стартовую точку для поиска предполагаемой скорость обработки трафика. Если уже известна заявленная или ранее измеренная скорость в нужном режиме, начинаем с параметров, близких к этим значениям. Если данных нет, берем консервативную стартовую нагрузку и постепенно ее повышаем (примерно на 1–5%), пока рост генерируемого трафика не начнет снижать производительность (потери пакетов, байтов, нарушение работы сервисов и т. п.) NDR.

Когда значение предполагаемой скорости обработки трафика найдено — переходим к определению реальной скорости. Для этого уменьшаем полученное значение предполагаемой скорости на 1–5% на каждом шаге до тех пор, пока в течение всего теста NDR не будет удовлетворять всем критериям успешного прохождения теста (о них чуть позже). Если хотя бы один критерий не выполнен, запуск считается проваленным, а предполагаемая пропускная способность следующего теста снова уменьшается.

Процесс тестирования состоит из трех этапов:

1. Калибровка генератора трафика

Вначале проверяем, какую нагрузку выдерживают сам TRex и сетевые интерфейсы генератора трафика. Это нужно, чтобы не принять ограничение генератора за ограничение NDR.

2. Калибровка испытательного стенда 

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

3. Тест производительности NDR в рабочем режиме

Нагрузочное тестирование должно проводиться как с каждым модулем безопасности по отдельности, так и в их комбинации. Для этого включаем функции безопасности и журналирование. Отдельные запуски проводим для нешифрованного, шифрованного и смешанного трафика, каждый профиль прогоняем с тремя наборами IDS-политик: 25, 50 и 100. У Гарда NDR всего около 330 политик, и для вариативности мы задали такое разделение. В результате фиксируем максимальную устойчивую нагрузку для каждой комбинации режима, профиля трафика и набора политик.

Регламент проведения нагрузочного тестирования:

• один запуск длится 360 секунд (6 минут) и делится на две фазы: первые ~60 секунд генератор достигает максимального значения пропускной способности путем постепенного повышения нагрузки до целевого значения, следующие 300 секунд идет подача легитимного трафика по пороговому значению;

• перед каждым запуском лог-файлы тестируемого устройства очищаются, если предусмотрена данная функция (если имеется функция ротации логов, то очистка логов не требуется);

• после каждого теста устройство перезагружается и 2–3 минуты выдерживается период восстановления, следующий тест в это время не запускается.

Критерии успешного прохождения теста

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

Мы использовали опыт международных и отечественных компаний по нагрузочному тестированию, адаптировали методики RFC 9411, RFC 2544 и выделили основные критерии прохождения тестов, в соответствии с особенностями NDR.

1. Загрузка ЦП не более 80%, причем и на NDR, и на генераторе трафика;

2. Использование RAM и swap-памяти не более 80%, также на обеих машинах;

3. Потери пакетов и трафика в байтах на физических и логических интерфейсах — не более 0,001% по данным внутреннего лог-файла; 

4. В системных журналах нет сообщений о потерях трафика и других ошибок обработки;

5. IDS успешно обнаруживает выбранный вредоносный дамп.

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

Проведение нагрузочного тестирования

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

Статистика генератора показывала больше, чем регистрировал у себя NDR. При этом ни дропов трафика, ни падения ключевых сервисов не было. До NDR не дошло чуть меньше половины отправленного трафика. Почему так вышло и где проблема?

По аналогии с расширением для парсинга системного файла мы написали еще одно, для сбора метрик записи на дисковые массивы Гарда NDR. Расширенная статистика сняла подозрения с генератора и маршрутизации: узким местом оказалась дисковая подсистема сервера.

На графике ниже видно: в начале теста оба интерфейса принимают трафик примерно на одном уровне. Но на 12:59:00 график dev_1 (TX) резко падает, а dev_2 (RX) продолжает принимать стабильно. Система не успевает обрабатывать трафик на dev_1: буферы приема заполнены, и ядро начинает сбрасывать входящие пакеты на этом интерфейсе. 

Одновременно со снижением объема трафика падает скорость записи на SSD. На диск sdb пишутся данные для анализа модулями безопасности, поэтому мы обратили внимание на дисковую подсистему стенда.

Мы использовали SSD со скоростью чтения 550 МБ/с и записи 530 МБ/с, интерфейс — SATA 6 Гбит/с. Под обработку трафика собрали два таких диска в RAID 0, чтобы поднять скорость: теоретически это дает до 1060 МБ/с на запись. Параметры массива выставили по рекомендациям из руководства по установке Гарда NDR — они приведены выше, в описании стенда. 

При таком запасе в начале теста запись на sdb идет всего около 70 МБ/с, а в 12:59:00 падает практически до нуля. Дисковая система уперлась в предел по операциям ввода-вывода и пропускной способности: очередь запросов на запись переполнилась, и диск перестал справляться.

Следующий график подтверждает, что sdb не тянет нагрузку. В 12:59:00 задержка записи падает почти до минимума. 

Вот почему: когда диск перегружен, каждая операция записи встает в длинную очередь, а пропускная способность близка к нулю. В метрику задержки (Latency) попадают только те запросы, которые система реально приняла в обработку: несколько успевших обрабатываются быстро, а остальные сотни ждут на более высоком уровне, в ядре ОС, и в Latency не учитываются.

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

Для решения возникших ограничений пришлось прибегнуть к полной реорганизации дискового массива NDR. Так как в нашем сервере есть дополнительная плата расширений для установки ОС на быстрые NVMe диски, то было принято решение задействовать все имеющиеся слоты для накопителей памяти. Заполняем слоты, пересобираем RAID’ы и заново выполняем процесс установки.

Таким образом мы получили следующую сборку:

• RAID 1, System: 2 × NVMe M.2, 480 Гб, чтение/запись 5000/700 МБ/с;

• RAID 0, Meta: 2 × SSD SATA Read Intensive, 480 Гб, чтение/запись 560/540 МБ/с;

• RAID 0, Flow: 8 × SSD SATA Read Intensive, 960 Гб, чтение/запись 550/530 МБ/с.

Так как состав стенда претерпел изменения, то все этапы тестирования необходимо провести заново, фиксируя значения метрик уже для новой системы.

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

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

Таким образом, мы смогли найти максимальное значение пропускной способности Гарда NDR, при котором выполняются все требования, предъявляемые к успешно пройденному тесту для каждой из девяти комбинаций: три профиля трафика (нешифрованный, шифрованный, смешанный) на трех наборах IDS-политик (25/50/100).

Тестирование функций безопасности NDR под нагрузкой 

Определив, какой объем легитимного трафика устойчиво обрабатывает NDR, раз в 10 секунд по требованию RFC 9411 мы подаем вредоносные дампы на фоне легитимной нагрузки: сначала при 50% легитимной нагрузки от найденного максимума, затем при 90%. Так мы проверяем, сохраняет ли NDR способность обнаруживать атаки не только в лабораторных условиях, но и под высокой фоновой нагрузкой. Важно, что в ходе теста отправляется 1 атака раз в 10 секунд, после завершения теста выдерживается 5 минут для восстановления NDR и обработки обнаруженных атак. Именно для этого этапа тестирования в стенде предусмотрен отдельный интерфейс.

Найденная максимальная нагрузка, при которой NDR справляется с обработкой трафика, созданного генератором, еще не означает, что при этой же нагрузке NDR будет успешно обнаруживать весь вредоносный трафик. Необходимо проверить, что обработка большого объема трафика не влияет на эффективность обнаружения атак в общем потоке. Другими словами, у злоумышленников не должно быть возможности проэксплуатировать уязвимости в системе путем DoS перегрузки канала мусорным трафиком, отправить вредонос в систему и «уйти незамеченными». NDR должен точно детектировать паттерны атак даже в пределах своей пиковой производительности.

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

В ходе тестирования Гарда NDR на эффективность выявления признаков компьютерных атак под нагрузкой мы использовали атаки, классифицированные по техникам MITRE ATT&CK, которые вы можете найти в нашем репозитории.

Набор pcap включает целую россыпь техник атак:

• взаимодействие с IP-адресами, хостами и URL из репутационных списков;

• взлом учетных записей по протоколам HTTP, HTTPS, FTP, RDP, SSH, SMB, SQL, LDAP;

• туннелирование через ICMP, DNS и SSH;

• коммуникация с C&C-сервером Cobalt Strike по HTTPS;

• атаки на доменную инфраструктуру;

• сетевые трояны;

• reverse shell;

• повышение привилегий;

• подделка контроллера домена;

• выполнение системных бинарных файлов (LOLBins);

• внедрение вредоносных макросов в шаблоны MS Office;

• фишинговые атаки;

• передача учетных данных в открытом виде;

• руткиты.

Для работы с дампами вредоносного трафика мы написали удобный инструмент, который помогает быстро изменять параметры уже записанных дампов и «проигрывать» их через отдельный интерфейс. О нем мы рассказывали в статье «Attack Replay: новый инструмент для воспроизведения и модификации трафика при тестировании СЗИ».

Что проверить перед проведением экспериментов

Если вы хотите провести такие тесты у себя, мы рекомендуем заранее проверить и проконтролировать несколько вещей:

• Определите уровень необходимой нагрузки. Исходя из этого подберите сетевые карты и железо под генератор трафика. Программно-аппаратные характеристики генератора трафика должны превышать характеристики NDR;

• Промежуточное устройство L3-коммутатор/маршрутизатор/tap также должно справляться с выбранной нагрузкой, чтобы не стать «бутылочным горлышком»;

• Сбор метрик необходимо осуществлять непосредственно с тестируемого NDR. Заранее определите принцип сбора метрик;

• Выберите профиль трафика, характерный для вашей сети.

• Очищайте журналы логов и перезагружайте NDR между проведением тестов и выдерживайте период восстановления перед началом запуска теста 2–3 минуты.

Выводы

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

При проведении нагрузочного тестирования продукта мы получили важное понимание того, что для выявления узкого места производительности недостаточно опираться на метрики генератора трафика, важно контролировать как программные, так и аппаратные характеристики на стороне тестируемого СЗИ. Для осуществления контроля дополнительных метрик программно-аппаратных характеристик можно использовать внешние самописные инструменты (программы), которые будут работать в интеграции с генератором трафика, но при этом не будут оказывать влияние на производительность тестируемого СЗИ. Способ сбора метрик может быть разнообразным, от локального мониторинга характеристик СЗИ через CLI или веб-интерфейс, до сбора метрик в БД по SSH с помощью агента.

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

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

Мы делимся с сообществом полной версией методологии, а также всеми описанными скриптами по сбору метрик и расширенным дашбордом для Cisco TRex в нашем репозитории.

PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес‑ориентированной защиты от специалистов Бастиона