Привет, Хабр! Я Ильдар Ишкинин, ведущий инженер Центра компетенций 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.


Таблица 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).

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


Таблица 5 - Сценарий запуска (Тест 1)
Таблица 6 - Результат (Тест 1)
Заявлено производителем |
Результат в лаборатории INSI |
157 000 CPS |
159 900 CPS |
Во время тестов был зафиксирован успешный результат при 159 900 CPS, деградация была зафиксирована при подаче более 160 000 CPS. Результаты соответствуют заявленному значению производителя в 157 000 CPS.
Показатели оборудования:


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

Тест 2. Определение максимального количества новых подключений в секунду (CPS, 10k правил)
Цель: определение максимального количества новый TCP-сессий в секунду, обрабатываемых тестируемым устройством при большом количестве правил МЭ (10000 правил).
Данный тест аналогичен Тесту 1, за исключением количества используемых правил. В данном тесте использовались 10000 сгенерированных правил и последнее правило (10001) из предыдущего теста, по которому проходит весь трафик (Рисунок 9).

Таблица 7 - Сценарий запуска (Тест 2)
Таблица 8 - Результат (Тест 2)
Заявлено производителем |
Результат в лаборатории INSI |
- |
92 000 CPS |
Показатели оборудования:



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

Таблица 9 – Сценарий запуска (Тест 3)
Таблица 10 – Результат (Тест 3)
Заявлено производителем |
Результат в лаборатории INSI |
10 000 000 СС |
10 000 000 СС |
Во время тестов был зафиксирован успешный результат при 10 000 000 CC, получить более высокие результаты нет возможности в виду программного ограничения на открытие новых подключений. Результаты соответствуют заявленному значению производителя в 10 000 000 конкурентных сессий.
Показатели оборудования:





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

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

Таблица 11 – Сценарий запуска (Тест 4)
Таблица 12 – Результат (Тест 4)
Заявлено производителем |
Результат в лаборатории INSI |
5,6 Гб/с |
5,9 Гб/с |
Показатели оборудования:



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

Таблица 13 – Сценарий запуска (Тест 5)
Таблица 14 – Результат (Тест 5)
Заявлено производителем |
Результат в лаборатории INSI |
- |
5,5 Гб/с |
Показатели оборудования:



Тест 6. Определение производительности тестируемого устройства на профиле трафика EMIX (10k rule, МЭ, IPS, DPI, Log)
Цель: определение производительности обор��дования с включенными модулями МЭ, IPS, DPI, Log на профиле трафика EMIX. Состав профиля EMIX приведен в таблице (Таблица 4).
В данном тесте к текущей политике МЭ добавили 10000 сгенерированных правил, предоставленных вендором (Рисунок 28). Трафик проходит по последнему правилу.

Таблица 15 – Сценарий запуска (Тест 6)
Таблица 16 – Результат (Тест 6)
Заявлено производителем |
Результат в лаборатории INSI |
- |
2,8 Гб/с |
Показатели оборудования:



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


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

Таблица 17 – Сценарий запуска (Тест 7)
Параметр |
Значение |
Профиль IPS |
Создан профиль «Test_IPS_Profile», включающий все доступные сигнатуры. Все сигнатуры переопределены в «Блокировать» |
Версия базы сигнатур |
4.1.9-456 |
Продолжительность теста |
~20 минут |
Количество правил МЭ |
1 |
Логирование |
Включено |
Активные модули |
МЭ, IPS, Log |
В результате теста модулем IPS заблокировано 39 из 60 атак. Для сравнения также провели тестирование на стенде одного из наиболее распространенных на отечественном рынке NGFW зарубежного производства. Результат – заблокировано 49 из 60 атак.
Показатели оборудования:


Тест 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 попыток скачать вредоносный файл.
Показатели оборудования:


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



Что мы увидели
Результаты подтвердили заявленные показатели производительности «Континента 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 и давать компаниям достоверные сведения для выбора оборудования. Это помогает строить инфраструктуру, где безопасность подтверждена фактами, а не только заявлена в спецификациях.