Привет, Хабр! Меня зовут Кирилл Прямов, я менеджер по развитию NGFW в UserGate. Не так давно мы анонсировали новый NGFW для крупных компаний и операторов дата-центров, который мы назвали UserGate Data Center Firewall (UserGate DCFW).
Сегодня я хочу рассказать про то, как мы тестировали этот продукт на новой аппаратной платформе F8010, официальные продажи которой начнутся к концу марта 2025. А в следующий раз я расскажу про тестирование нового гибридного устройства G9300 из новой серии G, которую мы выведем на рынок к лету 2025.
Что вообще такое DCFW
UserGate DCFW — это специализированный NGFW, заточенный на работу в дата-центрах и масштабных корпоративных сетях. Одна из его главных отличительных черт по сравнению с классическим UserGate NGFW — применение нашей новой технологии векторного файрвола. Это позволяет UserGate DCFW обрабатывать до 130 тыс. правил межсетевого экрана, что является рекордом для российских разработок класса NGFW (как это выглядит на практике, мы посмотрим далее во время тестов).
Если говорить про «железную» составляющую, то UserGate DCFW может использовать как наши традиционные старшие аппаратные платформы F8000 форм-фактора 2U, которые обычно используются для защиты ЦОД и штаб-квартир, так и платформы нового поколения — E1010, E3010, F8010 и FG. Все перечисленные платформы находятся в 2-х реестрах Минпромторга: ПП 719 (реестр российской продукции) и ПП 878 (реестр российской радиоэлектронной продукции).
На аппаратной платформе UserGate FG стоит остановиться отдельно, так как в ней впервые для российских NGFW используется аппаратный ускоритель на базе FPGA (он же ПЛИС, он же вентильная матрица). Традиционный процессор отвечает за идентификацию потоков и генерацию флоу-правил, а ускоритель реализует функции безопасности. Такой подход обеспечивает высокую производительность и позволяет обходить ограничения, присущие решениям на базе универсальных процессоров, например, невозможность обрабатывать elephant flows (например, сессия для репликации базы данных или большого бэкапа в ЦОД).
В настоящее время на FPGA доступная работа функций FW L3/L4 (150 Гбит/с на UDP 1518 байт и 90 Гбит/с EMIX. Про состав EMIX расскажу чуть позже. К началу апреля платформа FG также начнет официально поддерживать обработку функций IPS. До конца 2025 года мы также надеемся перенести на сопроцессор обработку функций контроля приложений (FW L7), а также планируем в 2 раза ускорить работу FW L3/L4. В более отдаленной перспективе — реализуем на FPGA обработку функций VPN и контентной фильтрации.
Еще одна особенность платформы FG — для нее возможны два варианта внедрения. В первом случае платформа работает автономно (мы назвали его режим standalone). На сегодня доступен кластер Active-Passive, работаем над реализацией кластера Active-Active.
Второй режим является уникальным для российского рынка и предназначен для задач, требующих обработки большого числа транзакций и еще более высоких скоростей. Так как UserGate DCFW поддерживает явное разделение уровня управления (control plane) и уровня обработки данных (data plane), мы можем объединять несколько платформ в гибридное устройство. В данном случае платформа E1010, E3010 или F8010 берет на себя функции control plane, а более производительная FG — функции data plane. Для удобства мы решили выделить такие гибридные устройства в отдельную серию G. Соединение между плоскостью данных и плоскостью управления осуществляется через стандартные 10-гигабитные интерфейсы. При этом для администратора гибридное устройство выглядит и ведет себя как единое целое — веб-интерфейс для двух платформ один.
Сейчас можно объединять в гибридное устройство серии G две платформы, но в перспективе мы хотим объединять 4-5 платформ для получения рекордных для российского рынка скоростей обработки трафика.
Обзор тестового стенда
Для начала хочу сказать большое спасибо своему коллеге Павлу Никулину — главному инженеру службы внедрения UserGate. Именно он проводил тесты, которые я опишу далее.
Сперва в двух словах расскажу, как мы проводим тестирование для заказчиков. Когда к нам обращаются с просьбой провести нагрузочное тестирование, первым делом мы согласуем параметры теста: оборудование, конфигурацию и дополнительные условия (если такие имеются). В этом плане мы опираемся на базовые настройки конфигурации, которые предоставляет заказчик, и на профиль трафика.
Количество соединений в секунду и правил межсетевого экрана, а также набор сетевых протоколов в трафике зависят от профиля заказчика. Например, у банков обычно выше требования к количеству одновременных соединений, новых соединений в секунду и правил межсетевого экрана. В целом выбор тестов зависит только от желания заказчика и возможности их технической реализации: в каждом конкретном случае заказчик знает, что ему необходимо, и тестирует решения в соответствии с требуемыми параметрами.
По нашей статистике, 90% всех тестирований происходят в режиме онлайн, 10% — в офлайн-формате в одном из наших офисов. По времени согласование всех параметров занимает от одного дня до нескольких недель. Само тестирование – обычно 1,5-2 часа. В редких случаях, когда нужно реализовать серьезное ПМИ от крупного заказчика, — до четырех-пяти часов. Бывают случаи, когда заказчики просят проводить тестирование в течение суток, чтобы убедиться в способности NGFW стабильно работать длительное временя.
Теперь про сам тестовый стенд. Мы применяем два генератора трафика: Spirent Cyberflood и Keysight BreakingPoint (бывшая Ixia), которые используют ведущие мировые вендоры сетевого оборудования. Это выгодно отличает нас от многих российских разработчиков NGFW, вынужденных использовать бесплатные генераторы трафика Trex или Яндекс.Танк, имеющие ряд ограничений. Клиентская часть генератора использует свой набор подсетей для генерации трафика и передает его серверной части. Оба компонента имеют интерфейсы, подключенные к коммутатору. Он, в свою очередь, соединен с испытуемым устройством.
Для генератора Spirent Cyberflood мы применяем встроенный профиль EMIX:
А вот пример одного из профилей трафика EMIX в Keysight BreakingPoint. Можно увидеть набор протоколов и веса, при помощи которых мы можем регулировать тестовый трафик. Байты в конце — это полезная нагрузка для каждого протокола в отдельности.
Тесты платформы UserGate F8010
UserGate F8010 — наша новая флагманская платформа в форм-факторе 2U. В ней используются два процессора AMD EPYC с 48 ядрами каждый и 256 ГБ RAM DDR4. Для сравнения, ее предшественница F8000 оперирует двумя Intel Xeon E5-2697V4 по 18 ядер и 128 ГБ RAM DDR4. По умолчанию включена технология виртуального разделения физических ядер процессора на два, то есть используется 192 виртуальных потока.
В стандартной поставке платформы F8010 доступно 8 интерфейсов RJ45 1 GbE и 4 оптических интерфейса SPF+ 10 GbE, а также 6 слотов для дополнительных сетевых карт (NIC), вплоть до QSFP28 на 100 GbE. Проведем четыре теста, используя 131 тыс. правил файрвола (позднее мы решили зарезервировать 1 000 правил под служебные задачи, но тест провели до этого события, поэтому теперь говорим про 130 тысяч правил).
CPS-тест, HTTP, 1 Байт (BreakingPoint)
Этот тест позволяет оценить максимально возможное количество соединений в секунду. Под соединением будем понимать процесс трехэтапного согласования TCP (SYN, SYN-ACK и ACK), за которым следуют запросы HTTP GET и HTTP Response с последующим закрытием TCP-подключения.
Для начала откроем интерфейс BreakingPoint и отредактируем профиль трафика. Для этого нажмем на кнопку MULTI EDIT.
Далее, кликнем на иконку увеличительного стекла, чтобы открыть окно с настройками:
Установим значение параметров Random response max (min) length в 1 байт (как в условиях теста):
Возвращаемся на главный экран и запускам тест кнопкой Save and Run:
Трафик пошел — задача установить, сколько новых подключений за секунду мы «перевариваем» на устройстве. Нас интересует вторая графа — TCP Client Connection Rate. Сейчас она показывает, что почти все соединения (их 78 000) закрываются без запаздывания. На пропускную способность мы не смотрим, в этом тесте она нам не интересна. Главное, чтобы не было большого числа Closed (RST) в окне Cumulative Client TCP Connections, которое отражает накопленные подключения.
Параллельно можем видеть на графике в дашборде UserGate DCFW, как возрастает нагрузка на процессор.
Длительность CPS-теста — 4 минуты, этого достаточно в демонстрационных целях. Для CPS-тестов нет строгих стандартов по времени, их задача — обнаружить возможные утечки памяти. Хотя иногда их проводят дольше — некоторые клиенты заказывают суточные проверки.
Тест успешно завершился: при 131 000 правил у нас получилось 78 000 новых соединений в секунду.
По умолчанию CPS-тест выполняется без логирования. Однако заказчики часто просят писать логи. Такой подход немного снижает производительность, но эффект, как правило, несущественен и зависит от объема трафика и количества событий. Если заглянуть в журнал трафика, то можно увидеть, что у нас были множественные срабатывания по правилу pass_131K.
EMIX-тест (Cyberflood)
Второй нагрузочный тест с использованием разнообразных типов трафика. Используем генератор Cyberflood, который будет самостоятельно их подбирать. Все, что от нас требуется, — указать пропускную способность.
Генерация трафика будет происходить в соответствии с тем самым стандартным профилем EMIX, который я упоминал ранее.
Можно запускать тест — нажимаем кнопку Start.
Система загрузит конфигурацию на блейды тестового стенда, которых у нас двенадцать штук. Потом потребуется минута на «разгон», в это время Cyberflood будет плавно наращивать объем генерации микс-трафика.
На дашборде UserGate DCFW видим, что степень использования CPU снова начала расти.
Во время теста красная полоска в окне Test Criteria Charts обозначает, что некоторые сессии были закрыты с опозданием. Но тест будет провален только в том случае, если количество таких ошибок превысит один процент.
По окончании теста количество «дропов» можно просмотреть для каждого блейда по отдельности в столбце Unsuccessful Transactions. Текущие цифры с ошибками — это уровень погрешности.
HTTP-тест, 524К (BreakingPoint)
В этом тесте вновь перейдем в интерфейс BreakingPoint. Будем использовать 12 блейдов с парой интерфейсов (клиент и сервер).
Перед запуском генерации заглянем в профиль трафика. Значение поля Random response min length в настройках равно 524 288 байт — это объем полезной нагрузки.
Запустим тест — у него также есть разгонная часть длительностью чуть менее двух минут. Сразу после генерация выровняется.
Здесь нас интересует пропускная способность устройства и сколько транзакций оно будет передавать. Так как у нас один протокол, то TCP Client Connection Rate будет равен количеству транзакций.
Через две минуты вышли на стабильный уровень генерации трафика и смотрим на графики в дашборде. Загрузка устройства не превышает 60% — это нормальный рекомендуемый уровень. Нагружать устройство до 90% не имеет смысла, так как это нерабочий режим.
Серый график, обозначенный как vCPU, отражает количество очередей на ядре процессора. Синий график — использование процессора — это усредненная утилизация процессорного времени. Если график vCPU находится выше графика использования процессора, значит, CPU накапливает очередь перед их обработкой.
Генерация прекратилась, можем посмотреть отчет. Для HTTP с полезной нагрузкой в 524К пропускная способность UserGate DCFW на платформе F8010 при включении 131 000 правил межсетевого экрана составила стабильные 60 Гбит/с.
EMIX-тест + СОВ (Cyberflood)
Проведем тест, аналогичный второму, но поменяем профиль, подключив систему обнаружения вторжений. У подавляющего большинства наших заказчиков обрабатываемый трафик меньше или равен 20 Гбит/с — установим параметр объема трафика с учетом производительности тестируемой платформы.
В открывшемся окне устанавливаем стандартный профиль СОВ: Default IDPS profile.
Этот профиль содержит около 4 300 сигнатур 3–5 уровня угроз и подразумевает разрешение всех подключений. Что не критично, поскольку тест будет проводиться в условиях отсутствия атак на систему.
Мы не будем использовать полный профиль, который содержит сигнатуры с высоким уровнем влияния на производительность, поскольку подавляющему большинству заказчиков не нужно защищаться от атак такого рода.
Хотя замечу, что мы проводим тесты с симуляцией атак под нагрузкой с основным профилем по запросу. В основном при помощи Keysight BreakingPoint, который имеет свою большую базу сетевых атак. В редких случаях симуляция проводится путем «проигрывания» PCAP-файлов (c заранее записанными сессиями атак) в Trex или Keysight BreakingPoint.
Запускаем тест и видим, что у нас сильно возросла утилизация процессора, и она выше, чем vCPU. Это означает, что очереди не накапливаются, как на предыдущем тесте.
Можно сказать, что UserGate DCFW без труда обрабатывает трафик на скорости 20 Гбит/с на том же количестве правил (131 000) с системой обнаружения вторжений c 4 300 сигнатурами.
Спасибо за внимание! Я и наша команда тестирования будем рады ответить на ваши вопросы в комментариях. В следующий раз я расскажу про тесты гибридного устройства G9300 с аппаратным ускорением (платформа FG + платформа E3010) на аналогичных тестах.