Привет, Хабр! Я Ильдар Ишкинин, ведущий инженер Центра компетенций Innostage. В этой статье хочу поделиться результатами нагрузочного тестирования отечественного NGFW «Континент 4», которое мы провели в нашей лаборатории INSI (Innostage Security Infrastructure).

Зачем мы это делали 

После выхода указа №250 и широкого внедрения отечественных средств защиты мы увидели, что замена NGFW на российские решения — задача далеко не тривиальная. Особенно, когда речь идёт об устройствах нового поколения, которые должны обрабатывать большой поток данных при включении всех модулей безопасности — IPS, DPI, TLS-инспекции и антивируса.

Мы решили проверить, насколько реальные показатели «Континента 4» совпадают с заявленными производителем. Цель была простая: дать объективные данные, на которые можно опираться при выборе оборудования для реальных проектов.

Что такое «Континент 4»

«Континент 4» объединяет все функции современного NGFW: фильтрацию URL, контроль приложений, систему предотвращения вторжений на собственных сигнатурах, расшифровку TLS-трафика для поиска угроз, потоковый антивирус и централизованное управление.

Продукт включён в реестр российского ПО Минцифры (№13885 от 14.06.2022), сертифицирован ФСТЭК России на соответствие 4-му уровню доверия, 4-му классу защиты для многофункциональных межсетевых экранов уровня сети и сопутствующим классам для МЭ типов «А», «Б», «Д», 4-му уровню СОВ и ФСБ России как СКЗИ класса КС2.

Как проходили тесты

Испытания мы проводили в нашей лаборатории INSI (Innostage Security Infrastructure), которая была создана специально для проверки отечественных средств защиты.

Каждый сценарий прогонялся несколько раз, чтобы исключить случайные колебания результатов. Мы использовали разные профили нагрузки, включая EMIX, проверяли устройство с включённым�� и отключёнными модулями, приближая условия к реальной эксплуатации: высокая нагрузка, длительные прогоны и комплексные профили трафика.

Состав стенда и схемы испытаний

Таблица 1 - Конфигурация компонентов стенда

Аппаратная платформа

Компонент

Примечание

1

IPC-R3000

NGFW Континент 4

Версия ПО 4.1.9

2

IPC-R1000

ЦУС Континент 4

Версия ПО 4.1.9, центр управления сетью

3

Qtech 6300 32F

Коммутатор

Коммутация стенда, использование портов 10G

4

Dell R840 PowerEdge

Trex

Средство генерации нагрузки Trex

5

Cisco Extreme

Коммутатор

Коммутация стенда, использование портов 1G

6

Dell R540 PowerEdge

VMware ESXI

Развернут виртуальный Trex для генерации атак

 

Стенд включал тестируемое устройство и двух независимых генераторов нагрузки Trex:

·       Trex1 установлен на аппаратной платформе Dell R840 PE и служит для генерации трафика в тестах на производительность.

·       Trex2 развернут в виде виртуального образа на виртуализации VMware ESXI и служит для генерации атак из PCAP файлов для проверки модуля IPS тестируемого оборудования.

 

Для коммутации стенд�� использованы коммутаторы Qtech 6300 32F и Cisco Extreme 3626GTS.

NGFW Континент 4 был подключён к системе мониторинга Zabbix и передавал данные по протоколу SNMP.

 

Рисунок 1 - Структурная схема тестового стенда
Рисунок 1 - Структурная схема тестового стенда
Рисунок 2 - Логическая схема тестового стенда
Рисунок 2 - Логическая схема тестового стенда

 

Таблица 2 - Настройки сетевых интерфейсов NGFW Континент 4

Устройство

Интерфейс

Адрес/маска

Примечание

NGFW Континент 4 (IPC R3000)

Ge-0-0

10.3.0.84/29

Интерфейс управления

Ge-0-3.21

192.168.21.1/28

Подключение к Trex2

Ge-0-3.22

192.168.22.1/28

Подключение к Trex2

Te-1-2

172.16.60.1/29

Подключение к Trex1

Te-1-3

172.16.61.1/29

Подключение к Trex1

Континент 4 ЦУС (IPC R1000)

Ge-0-0

10.3.0.85/29

Интерфейс управления

 

Таблица 3 – Статические маршруты NGFW Континент 4

Устройство

Сеть назначения

Шлюз

Примечание

NGFW Континент 4 (IPC R3000)

30.0.0.0/8

172.16.60.4

Виртуальный сегмент Trex1

60.0.0.0/8

172.16.61.4

Виртуальный сегмент Trex1

17.0.0.0/8

192.168.21.5

Виртуальный сегмент Trex2

49.0.0.0/8

192.168.22.5

Виртуальный сегмент Trex2

 

Нагрузочное тестирование

 

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

 

Таблица 4 - Состав профиля EMIX

Протокол

Процентное соотношение (%)

HTTPS

15

RSTP

18

HTTP

14

SMB

43

SIP

5

RDP

5

 

Нагрузочное тестирование проводилось путем запуска определенного профиля на генераторе трафика Trex1, в некоторых сценариях одновременно запускался профиль на генераторе трафика Trex2. Скрипты, профили и настройки генераторов, используемые в тестах, взяты из источника https://github.com/OlegKashtanov/ngfw-trex-perf.

Результат теста считался успешным, когда % потерь сессий менее 0.105 (не применимо к тестам IPS). Правила политики МЭ, их количество, команда запуска генератора трафика, активные модули и логирование указаны в каждом тесте в виде таблицы. С участием инженеров вендора для тестов (Тест 2 и Тест 6) подготовлено 10000 правил. Примеры правил приведены на рисунке (Рисунок 3).

Рисунок 3 - Сгенерированные правила
Рисунок 3 - Сгенерированные правила

Тест 1. ��пределение максимального количества новых подключений в секунду (CPS)

Цель: определение максимального количества новых TCP-сессий, обрабатываемых тестируемым устройством.

Для генерации нагрузки использовался профиль max_cps. Данный профиль включает генерацию HTTP запроса и ответа. Размер пакета 1 Кбайт. Вид запроса и ответа приведены на рисунке (Рисунок 4).

Рисунок 4 – Профиль max_cps
Рисунок 4 – Профиль max_cps
Рисунок 5 – Политика МЭ (Тест 1)
Рисунок 5 – Политика МЭ (Тест 1)

Таблица 5 - Сценарий запуска (Тест 1)

Параметр

Значение

Команда запуска

./trex_run.py -f ./trex_profiles/ max_cps_30.py --drp 0.105 --latency_pps 1 -d 300 -t response_size_kb=1 -m 159900

 

Продолжительность теста

5 минут

Количество правил МЭ

1

Логирование

Выключено

Активные модули

МЭ

 

Таблица 6 - Результат (Тест 1)

Заявлено производителем

Результат в лаборатории INSI

157 000 CPS

159 900 CPS

 

Во время тестов был зафиксирован успешный результат при 159 900 CPS, деградация была зафиксирована при подаче более 160 000 CPS. Результаты соответствуют заявленному значению производителя в 157 000 CPS.

Показатели оборудования:

Рисунок 6 – Загрузка CPU NGFW Континент 4 (Тест 1)
Рисунок 6 – Загрузка CPU NGFW Континент 4 (Тест 1)
Рисунок 7 – Нагрузка Trex1 (Тест 1)
Рисунок 7 – Нагрузка Trex1 (Тест 1)

1)  Результат выполнения нагрузочного теста Trex1 приведен на рисунке (Рисунок 8).

Рисунок 8 – Вывод Trex1 (Тест 1)
Рисунок 8 – Вывод Trex1 (Тест 1)

Тест 2. Определение максимального количества новых подключений в секунду (CPS, 10k правил)

Цель: определение максимального количества новый TCP-сессий в секунду, обрабатываемых тестируемым устройством при большом количестве правил МЭ (10000 правил).

Данный тест аналогичен Тесту 1, за исключением количества используемых правил. В данном тесте использовались 10000 сгенерированных правил и последнее правило (10001) из предыдущего теста, по которому проходит весь трафик (Рисунок 9).

Рисунок 9 – Политика МЭ (Тест 2)
Рисунок 9 – Политика МЭ (Тест 2)

Таблица 7 - Сценарий запуска (Тест 2)

Параметр

Значение

Команда запуска

./trex_run.py -f ./trex_profiles/ max_cps_30.py --drp 0.105 --latency_pps 1 -d 300 -t response_size_kb=1 -m 92000

 

Продолжительность теста

5 минут

Количество правил МЭ

10001

Логирование

Выключено

Активные модули

МЭ

 

Таблица 8 - Результат (Тест 2)

Заявлено производителем

Результат в лаборатории INSI

-

92 000 CPS

 

Показатели оборудования:

Рисунок 10 – Загрузка CPU NGFW Континент 4 (Тест 2)
Рисунок 10 – Загрузка CPU NGFW Континент 4 (Тест 2)
Рисунок 11 – Показатели Trex1 (Тест 2)
Рисунок 11 – Показатели Trex1 (Тест 2)
Рисунок 12 – Вывод Trex1 (Тест 2)
Рисунок 12 – Вывод Trex1 (Тест 2)

Тест 3. Определение максимального количества конкурентных TCP сессий (СС)

Цель: определение максимального количества конкурентных TCP-сессий, обрабатываемых тестируемым устройством.

В данном тесте использовался профиль – max_cc, в котором открывается HTTP сессия. Профиль с параметрами, приведенные в таблице (Таблица 9), откроет 10 млн. сессий с шагом 25000 сессий в секунду. HTTP запрос и ответ приведен на рисунке (Рисунок 13).

Рисунок 13 – Профиль max_cc
Рисунок 13 – Профиль max_cc

Таблица 9 – Сценарий запуска (Тест 3)

Параметр

Значение

Команда запуска

./trex_run.py -f trex_profiles/max_cc_30.py --drp 0.105 --latency_pps 1  -t flow_size=25 delay=64 -d 400 -m 25000.0 --cc-dur 1200

Продолжительность теста

20 минут

Количество правил МЭ

1

Логирование

Выключено

Активные модули

МЭ

Таблица 10 – Результат (Тест 3)

Заявлено производителем

Результат в лаборатории INSI

10 000 000 СС

10 000 000 СС

 

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

 

Показатели оборудования:

Рисунок 14 – Загрузка CPU NGFW Континент 4 (Тест 3)
Рисунок 14 – Загрузка CPU NGFW Континент 4 (Тест 3)
Рисунок 15 – Показатели Trex1 (Тест3)
Рисунок 15 – Показатели Trex1 (Тест3)
Рисунок 16 – Количество сессий на NGFW Континент 4
Рисунок 16 – Количество сессий на NGFW Континент 4
Рисунок 17 – Вывод Trex1 (Тест 3)
Рисунок 17 – Вывод Trex1 (Тест 3)
Рисунок 18 – График CC в Zabbix (Тест 3)
Рисунок 18 – График CC в Zabbix (Тест 3)

Тест 4. Определение производительности тестируемого устройства на профиле трафика EMIX (МЭ, IPS, DPI)

Цель: определение производительности оборудования с включенными модулями МЭ, IPS, DPI на профиле EMIX.

Рисунок 19 – Политика МЭ (Тест 4)
Рисунок 19 – Политика МЭ (Тест 4)

Политика СОВ для данного теста приведена на рисунке (Рисунок 20). В данном тесте использовался предустановленный профиль СОВ – «Оптимальный набор», включающий 6800 сигнатур.

Рисунок 20 – Политика СОВ (Тест 4)
Рисунок 20 – Политика СОВ (Тест 4)

Таблица 11 – Сценарий запуска (Тест 4)

Параметр

Значение

Команда запуска

./trex_run.py -f trex_profiles/emix_cor_30.py --drp 0.105 --latency_pps 1 -d 200 -m 350

 

Продолжительность теста

200 секунд

Количество правил МЭ

2

Логирование

Выключено

Активные модули

МЭ, IPS, DPI

 

Таблица 12 – Результат (Тест 4)

Заявлено производителем

Результат в лаборатории INSI

5,6 Гб/с

5,9 Гб/с

 

Показатели оборудования:

Рисунок 21 – Загрузка CPU NGFW Континент 4 (Тест 4)
Рисунок 21 – Загрузка CPU NGFW Континент 4 (Тест 4)
Рисунок 22 – Показатели Trex1 (Тест 4)
Рисунок 22 – Показатели Trex1 (Тест 4)
Рисунок 23 – Вывод Trex1 (Тест 4)
Рисунок 23 – Вывод Trex1 (Тест 4)

Тест 5. Определение производительности тестируемого устройства на профиле трафика EMIX (МЭ, IPS, DPI, Log)

 

Цель: определение производительности оборудования с включенными модулями МЭ, IPS, DPI, Log на профиле трафика EMIX. Состав профиля EMIX приведен в таблице (Таблица 4).

Данный тест отличается от предыдущего (Тест 4) тем, что в политике МЭ было включено логирование для правил.

Рисунок 24 – Политика МЭ (Тест 5)
Рисунок 24 – Политика МЭ (Тест 5)

Таблица 13 – Сценарий запуска (Тест 5)

Параметр

Значение

Команда запуска

./trex_run.py -f trex_profiles/emix_cor_30.py --drp 0.105 --latency_pps 1 -d 200 -m 330

 

Продолжительность теста

200 секунд

Количество правил МЭ

2

Логирование

Включено

Активные модули

МЭ, IPS, DPI, Log

 

Таблица 14 – Результат (Тест 5)

Заявлено производителем

Результат в лаборатории INSI

-

5,5 Гб/с

 

Показатели оборудования:

Рисунок 25 – Загрузка CPU NGFW Континент 4 (Тест 5)
Рисунок 25 – Загрузка CPU NGFW Континент 4 (Тест 5)
Рисунок 26 – Показатели генерации нагрузочного теста Trex1 (Тест 5)
Рисунок 26 – Показатели генерации нагрузочного теста Trex1 (Тест 5)
Рисунок 27 – Вывод Trex1 (Тест 5)
Рисунок 27 – Вывод Trex1 (Тест 5)

Тест 6. Определение производительности тестируемого устройства на профиле трафика EMIX (10k rule, МЭ, IPS, DPI, Log)

 

Цель: определение производительности обор��дования с включенными модулями МЭ, IPS, DPI, Log на профиле трафика EMIX. Состав профиля EMIX приведен в таблице (Таблица 4).

В данном тесте к текущей политике МЭ добавили 10000 сгенерированных правил, предоставленных вендором (Рисунок 28). Трафик проходит по последнему правилу.

Рисунок 28 – Политика МЭ (Тест 6)
Рисунок 28 – Политика МЭ (Тест 6)

Таблица 15 – Сценарий запуска (Тест 6)

Параметр

Значение

Команда запуска

./trex_run.py -f trex_profiles/emix_cor_30.py --drp 0.105 --latency_pps 1 -d 200 -m 165

 

Продолжительность теста

200 секунд

Количество правил МЭ

10002

Логирование

Включено

Активные модули

МЭ, IPS, DPI, Log

 

Таблица 16 – Результат (Тест 6)

Заявлено производителем

Результат в лаборатории INSI

-

2,8 Гб/с

 

Показатели оборудования:

Рисунок 29 – Загрузка CPU NGFW Континент 4 (Тест 6)
Рисунок 29 – Загрузка CPU NGFW Континент 4 (Тест 6)
Рисунок 30 – Показатели Trex1 (Тест 6)
Рисунок 30 – Показатели Trex1 (Тест 6)
Рисунок 31 – Результат выполнения нагрузочного теста Trex1 (Тест 6)
Рисунок 31 – Результат выполнения нагрузочного теста Trex1 (Тест 6)

Тест 7. Оценка эффективности отражения атак тестируемым устройством

 

Цель: оценка эффективности отражения атак тестируемым устройством. В рамках данного теста использовался генератор трафика Trex2, атаки представлены в виде записи сетевого трафика (дампов) в формате PCAP во время применения атак. Использовалось 60 дампов атак.

Рисунок 32 – Политика МЭ (Тест 7)
Рисунок 32 – Политика МЭ (Тест 7)
Рисунок 33 – Правила политики СОВ (Тест 7)
Рисунок 33 – Правила политики СОВ (Тест 7)

На рисунке (Рисунок 34) приведен пример настройки профилей СОВ. Для профиля Test_IPS_Profile установлено действие блокировать для всех сигнатур из актуальной базы СОВ производителя (база решающих правил)

Рисунок 34 – База решающих правил
Рисунок 34 – База решающих правил

Таблица 17 – Сценарий запуска (Тест 7)

Параметр

Значение

Профиль IPS

Создан профиль «Test_IPS_Profile», включающий все доступные сигнатуры. Все сигнатуры переопределены в «Блокировать»

Версия базы сигнатур

4.1.9-456

Продолжительность теста

~20 минут

Количество правил МЭ

1

Логирование

Включено

Активные модули

МЭ, IPS, Log

 

В результате теста модулем IPS заблокировано 39 из 60 атак. Для сравнения также провели тестирование на стенде одного из наиболее распространенных на отечественном рынке NGFW зарубежного производства. Результат – заблокировано 49 из 60 атак.

 

Показатели оборудования:

Рисунок 35 – Журнал мониторинга (Тест 7)
Рисунок 35 – Журнал мониторинга (Тест 7)
Рисунок 36 – Результат выполнения теста Trex2 (Тест 7)
��исунок 36 – Результат выполнения теста Trex2 (Тест 7)

Тест 8. Оценка эффективности отражения атак различного уровня в легитимном HTTPS трафике тестируемым устройством

 

Цель: оценка эффективности отражения атак в легитимном HTTPS трафике тестируемым устройством.

В рамках данного теста использовался генератор трафика Trex1 для генерации легитимной нагрузки HTTPS трафика (1000 сессий в секунду), Trex2 использовался для воспроизведения атаки скачивания тестового вируса eicar из дампа PCAP. Тест длился 100 секунд, за это время Trex2 сгенерировал 108 попыток скачивания eicar.

Таблица 18 – Сценарий запуска (Тест 8)

Параметр

Значение

Профиль IPS

Создан профиль, включающий все доступные сигнатуры. Все сигнатуры переопределены в «Блокировать»

Команда запуска Trex 1

./trex_run.py -f /trex_profiles/https_packet_only_30.py –drp 0.105 –latency_pps 1 -d 100 -m 1000

Продолжительность теста

100 секунд

Количество правил МЭ

1 (аналогично Тест 7)

Логирование

Включено

Активные модули

МЭ, IPS, Log

 

В результате теста модулем IPS под нагрузкой заблокировано 108 из 108 попыток скачать вредоносный файл.

Показатели оборудования:

Рисунок 37 – Показатели генерации нагрузки Trex1 (Тест 8)
Рисунок 37 – Показатели генерации нагрузки Trex1 (Тест 8)
Рисунок 38 – Результат выполнения нагрузочного теста Trex1 (Тест 8)
Рисунок 38 – Результат выполнения нагрузочного теста Trex1 (Тест 8)

1) Вывод результата теста Trex2 приведен на рисунке.

Рисунок 39 – Вывод результата теста Trex2 (Тест 8)
Рисунок 39 – Вывод результата теста Trex2 (Тест 8)
Рисунок 40 – Журнал мониторинга (Тест 8)
Рисунок 40 – Журнал мониторинга (Тест 8)

 

Рисунок 41 – Детальная информация о событии (Тест 8)
Рисунок 41 – Детальная информация о событии (Тест 8)

Что мы увидели

                 

Результаты подтвердили заявленные показатели производительности «Континента 4». При использовании профиля EMIX с включённым IPS устройство показало заявленную производительность, а в некоторых сценариях даже превысило заявленные значения.

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

Таблица 19 – Результаты тестирования

Наименование теста

Активные модули

Кол-во правил

Логирование

Результат производителя

Результат в лаборатории INSI

1

2

3

4

5

6

Определение максимального значения CPS

МЭ

1

-

157 000 CPS

159 900 CPS

Определение максимального значения CPS

МЭ

10 001

-

-

92 000 CPS

Определение максимального значения CC

МЭ

1

-

10 000 000 CC

10 000 000 CC

Определение значения для EMIX трафика

МЭ, IPS, DPI

2

-

5,6 Гбит,с

5,9 Гбит,с

Определение значения для EMIX трафика

МЭ, IPS, DPI, Log

2

включено

-

5,5 Гбит,с

Определение значения для EMIX трафика

МЭ, IPS, DPI, Log

10 002

включено

-

2,8 Гбит,с

Отражение атак

МЭ, IPS, Log

1

включено

-

39/60 атак заблокировано

Отражение атак (eicar) в легитимном HTTPS трафике

МЭ, IPS, Log

1

включено

-

108/108 заблокировано

Выводы

Такие тесты показывают, что рынок отечественных средств защиты становится более зрелым. Заказчики всё чаще требуют объективные, проверенные данные о продуктивности решений — и мы считаем это правильным подходом.

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

Комментарии (0)