Привет, Хабр! Делюсь ниже статьей моих коллег в К2 Кибербезопасность системного инженера Захара Пенчева и ведущего эксперта технического блока Влада Мусатова.
Тестирование новых версий продуктов — одна из самых интересных задач для инженера системного интегратора. Ведь это возможность не только познакомиться с новой функциональностью, но и проверить ее на практике, разобраться в особенностях реализации и оценить поведение решения в различных сценариях.
В К2 Кибербезопасность мы регулярно тестируем решения как для развития собственной экспертизы и накопления практического опыта, так и по запросам клиентов и вендоров.
В этот раз в центре нашего внимания оказался Kaspersky NGFW (K-NGFW). В статье расскажем, как проходило тестирование, что удалось проверить и к каким выводам мы пришли.
Мы также сделали видео-распаковку продукта — можно посмотреть ТУТ.
ЧТО ТЕСТИРОВАЛИ?
На функциональное и нагрузочное тестирование к нам поступил K-NGFW версии 1.3 в двух аппаратных исполнениях: KX-100-KB1 и KX-400.
Модель KX-100-KB1 была представлена двумя устройствами, которые мы объединили в кластер для проведения функциональных испытаний. Кроме того, устройства этой модели участвовали и в нагрузочном тестировании.
Модель KX-400 досталась нам в единственном экземпляре и использовалась исключительно для нагрузочных испытаний.
КАК УСТРОЕН ИСПЫТАТЕЛЬНЫЙ СТЕНД
Для проведения испытаний мы собрали стенд (Рис. 1), который разделили на два контура: функционального и нагрузочного тестирования.
Справа на схеме расположен контур функционального тестирования. В его состав вошли два устройства K-NGFW KX-100-KB1, объединенные в кластер, и сервер виртуализации на базе VMware ESXi. На нем мы развернули систему управления K-NGFW и несколько вспомогательных виртуальных машин, необходимых для проведения испытаний.
Слева расположен контур нагрузочного тестирования. Здесь все проще: генератор трафика на базе Cisco TRex и тестируемое устройство K-NGFW. В нагрузочных испытаниях участвовали обе аппаратные модели: KX-100-KB1 и KX-400. Для управления K-NGFW использовалась та же система управления, что и в контуре функционального тестирования.
Подробнее о компонентах стенда, особенностях организации сети и методике проведения испытаний расскажем ниже.
НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ
Схема подключения и методика
Для проведения нагрузочного тестирования K-NGFW использовалась схема подключения «в разрыв» (Inline). Генератор трафика Cisco TRex одновременно имитировал обе стороны сетевого взаимодействия: клиента и сервер. Стенд был организован таким образом, чтобы весь генерируемый трафик проходил через K-NGFW, подвергаясь маршрутизации, фильтрации и инспекции в соответствии с настроенными политиками безопасности.
Для тестирования KX-100-KB1 использовались интерфейсы SFP+ с пропускной способностью до 10 Гбит/с, а для KX-400 — QSFP28 с пропускной способностью до 100 Гбит/с. Управление устройствами осуществлялось через интерфейсы RJ-45 с пропускной способностью до 1 Гбит/с.
Само тестирование проходило в несколько этапов.
На первом этапе методом бинарного поиска определяли максимальную скорость передачи трафика, при которой сохраняется приемлемый уровень потерь пакетов.
В качестве критерия максимальной эксплуатационной производительности K-NGFW в рамках испытаний мы приняли пропускную способность при уровне потерь пакетов не более 0,5% на профиле трафика EMIX.
Почему именно 0,5%? Мы выбрали этот порог как компромисс между максимальной производительностью устройства и допустимыми потерями в условиях стресс-нагрузки. Поскольку значительная часть трафика передается по TCP, отдельные потери могут компенсироваться механизмом повторной передачи сегментов (retransmission). При этом важно учитывать, что потери все равно могут влиять на скорость передачи данных и задержки, поэтому выбранный порог — критерий нашей методики, а не универсальная норма для любой сети передачи данных.
После определения порогового значения проводили несколько десятиминутных тестов с найденной нагрузкой. Это позволяло убедиться в повторяемости результатов и исключить влияние случайных колебаний.
Затем переходили к часовым стресс-тестам. Задача которых заключается в проверке того, насколько стабильно K-NGFW справляется с высокой нагрузкой в течение продолжительного времени и не происходит ли постепенной деградации производительности.
Для каждой комбинации включенных модулей безопасности выполняли несколько повторных тестов, чтобы получить достаточный объем данных и убедиться в устойчивости результатов.
Профили трафика и сценарии тестирования
Нагрузочное тестирование проводили двумя профилями трафика, позволяющими оценить поведение K-NGFW в разных сценариях сетевой нагрузки.
Для первого профиля характерно умеренное количество сетевых сессий, в каждой из которых передается значительный объем данных.
Со вторым профилем ситуация обратная: большое количество сетевых сессий, каждая из которых передает относительно небольшой объем данных.
Первый профиль условно можно назвать оптимальным, а второй — более тяжелым для оборудования. Такое разделение позволяет оценить, как на производительность NGFW влияют не только объем передаваемого трафика, но и количество обрабатываемых сессий.
Если результаты нагрузочного теста на профилях трафика расходятся, то сначала указана цифра для второго профиля, потом для первого.
Испытания проводили в трех режимах с последовательным включением модулей безопасности:
L4 FW + AppControl — межсетевой экран и контроль приложений;
L4 FW + AppControl + IDPS — дополнительно включаем систему обнаружения и предотвращения вторжений;
L4 FW + AppControl + IDPS + AV — к предыдущему набору добавляем потоковый антивирус.
Кроме того, каждый сценарий проверяли при разном количестве правил межсетевого экрана: 1, 500, 1000 и 10 000. Это необходимо, чтобы оценить, насколько размер политики безопасности влияет на производительность NGFW.
Ниже рассмотрим результаты испытаний при 10 000 правил.
Для примера приведем выдержку результатов, снятых с обоих профилей с «10000» ACL для KX-100. Обращаем ваше внимание, что параметр CPS — connections per second — не измерен, такую метрику продукт не предоставляет, а ее снятие с TRex не является корректным.
Результаты KX-100-KB1
Режим работы | Данные вендора | Результаты К2 |
L4 FW + AppControl | 10 Гбит/с | 10 Гбит/с |
L4 FW + AppControl + IDPS | 3 Гбит/с | 1,8–2,75 Гбит/с |
L4 FW + AppControl + IDPS + AV | 2 Гбит/с | 1,36–1,88 Гбит/с |
KX-100-KB1 показал хорошие результаты. В базовом режиме L4 FW + AppControl удалось достичь заявленных 10 Гбит/с.
При включении IDPS и потокового антивируса производительность ожидаемо снижалась. В этих режимах полученные значения оказались ниже ориентиров вендора, особенно при использовании более тяжелых сценариев нагрузки.
Здесь стоит отметить, что мы сознательно не занимались тонкой настройкой модулей безопасности ради достижения максимальной производительности и использовали стандартные настройки движка IDPS, который включает в себя максимальное количество сигнатур, и потоковый антивирус, который не подлежит тонкой настройке у вендора. Нам было интересно посмотреть, как устройство поведет себя в достаточно тяжелых условиях, с несколькими одновременно работающими механизмами защиты.
Результаты KX-400
Режим работы | Данные вендора | Результаты К2 |
L4 FW + AppControl | 40 Гбит/с | 40 Гбит/с |
L4 FW + AppControl + IDPS | 15 Гбит/с | 16 Гбит/с |
L4 FW + AppControl + IDPS + AV | 12 Гбит/с | 11,4 Гбит/с |
А вот результаты KX-400 нас приятно удивили.
В базовом режиме устройство продемонстрировало 40 Гбит/с, полностью достигнув заявленного значения. При включении IDPS мы получили 16 Гбит/с против 15 Гбит/с в данных вендора.
Даже после подключения потокового антивируса производительность оставалась на высоком уровне — 11,4 Гбит/с при ориентире 12 Гбит/с.
В целом KX-400 хорошо справился с нагрузочными испытаниями. Особенно интересными оказались результаты при одновременной работе нескольких модулей безопасности, когда требования к ресурсам устройства существенно возрастают.
ФУНКЦИОНАЛЬНОЕ ТЕСТИРОВАНИЕ
Как уже упоминали, для функционального тестирования мы использовали два устройства K-NGFW, объединенных в отказоустойчивый кластер, и сервер виртуализации на базе VMware ESXi.
Для проверки различных функций K-NGFW на сервере развернули несколько виртуальных машин:
Windows Server 2022 — выполняет роли контроллера домена Active Directory (AD), DNS- и DHCP-серверов;
Windows 10 Pro — имитирует рабочее место пользователя и выступает в роли тестового хоста («жертвы»);
Kali Linux — имитирует средства нарушителя и выступает в роли источника атак;
VyOS — виртуальный маршрутизатор, применяемый для тестирования протоколов динамической маршрутизации (BGP и OSPF);
Zabbix-сервер — отвечает за сбор метрик и мониторинг состояния K-NGFW;
Система управления (СУ) K-NGFW — обеспечивает централизованную настройку и управление межсетевыми экранами.
Чтобы трафик между тестовыми узлами проходил через K-NGFW, виртуальные машины разместили в разных подсетях, организовав маршрутизацию между ними через межсетевой экран. Такая топология позволила проверять механизмы статической и динамической маршрутизации, а также работу VRF и виртуальных контекстов. Кроме того, для системы управления, шлюзов K-NGFW и узла «жертвы» обеспечили доступ в Интернет.
Методология и порядок тестирования
Мы перешли к функциональному тестированию после предварительной настройки K‑NGFW и смежной инфраструктуры стенда.
Следующим шагом стало изучение документации вендора, с целью определения состава проверяемых функций. Нам было важно разобраться не только в возможностях продукта в целом, но и в том, какие функции появились или изменились в версии 1.3.
На основании документации мы составили чек-лист, разделив тест на несколько логических этапов с функциональной группировкой:
Сетевые функции: статическая и динамическая маршрутизация, поддержка VRF и виртуальных контекстов, работа с VLAN, трансляция сетевых адресов (NAT), организация Site-to-Site, а также возможность работы в роли инфраструктурных серверов DNS/DHCP/NTP.
Управление и отказоустойчивость: интеграция со службами каталогов и аутентификации (AD/RADIUS), работа HA-кластера в режимах Active-Active и Active-Passive (AA/AP), управление сетевыми сессиями, просмотр журналов трафика и работа с политиками безопасности.
Функции безопасности: обнаружение и предотвращение вторжений (IDPS), глубокий анализ пакетов (DPI), потоковый антивирус, URL-категоризация, защита DNS-трафика (DNS Security) и инспекция зашифрованного TLS/SSL‑трафика.
Обслуживание и мониторинг: контроль состояния устройств (Health Status), мониторинг по SNMP, централизованное обновление модулей безопасности, шлюзов и системы управления, сброс к заводским настройкам (Factory Reset), а также возможности автоматизации через API.
Отдельно стоит рассказать о нашем подходе к проверке механизмов безопасности. Здесь мы сознательно ограничили сложность тестовых сценариев. Например, для проверки потокового антивируса использовали стандартный тестовый файл EICAR, а для IDPS — сценарии с известными и задокументированными уязвимостями (CVE).
Почему не стали использовать более сложные и нестандартные сценарии атак? Перед нами стояла задача проверить именно работоспособность механизмов защиты: анализирует ли NGFW соответствующий трафик, обнаруживает ли тестовые угрозы и корректно ли применяет настроенные политики блокировки.
Оценка полноты сигнатурных баз, качества обнаружения неизвестных угроз и эффективности защитных механизмов против сложных атак в задачи нашего тестирования не входила. Для таких исследований потребовались бы отдельная методика, более широкий набор сценариев и существенно больший масштаб испытаний.
Сетевые функции
Проверка сетевого стека K-NGFW проводилась, чтобы оценить стабильность функционирования устройств под нагрузкой в условиях, приближенных к реальной корпоративной сети. В ходе испытаний проверили следующие функции:
Статическая и динамическая маршрутизация. Базовые маршруты между сегментами сети настроили статически, а для проверки динамической маршрутизации использовали виртуальный маршрутизатор VyOS. С его помощью проверили работу протоколов OSPF и BGP: установление соседства, обмен маршрутной информацией и реакцию на изменения сетевой топологии. K-NGFW корректно принимал, обрабатывал и пересылал маршрутную информацию, оперативно реагируя на вносимые нами изменения в топологию сети.
Сегментация сети и виртуальные контексты. Для проверки изоляции сетевых сегментов протестировали работу VRF (Virtual Routing and Forwarding). Также проверили возможность разделения устройства на виртуальные контексты (VSS), позволяющие создавать несколько независимых логических межсетевых экранов на базе аппаратного комплекса. Для каждого контекста настроили собственную таблицу маршрутизации, политики безопасности и параметры администрирования.
Канальный уровень. Проверили работу агрегированных интерфейсов с использованием LACP (802.3ad). Объединили несколько физических портов в логический интерфейс, проверили распределение трафика между ними и поведение системы при отключении отдельных физических соединений. При отключении одного из каналов трафик продолжал передаваться через оставшиеся соединения без зафиксированных потерь. Также проверили работу VLAN (802.1Q), настроив тегирование трафика поверх агрегированных интерфейсов.
Трансляция сетевых адресов (NAT). Протестировали основные сценарии трансляции: Source NAT для доступа внутренних узлов во внешние сети, Destination NAT для публикации тестовых ресурсов и Static NAT для статического сопоставления IP-адресов по принципу «один к одному». Все проверенные сценарии отработали корректно.
Построение защищенных каналов (Site-to-Site VPN). Для проверки работы IPsec VPN организовали защищенный туннель между двумя устройствами K‑NGFW. Ради этого пришлось временно разделить отказоустойчивый кластер и перенести один из узлов в другую подсеть. После настройки туннеля проверили прохождение трафика между тестовыми сегментами. Соединение установилось успешно, передача данных через защищенный канал работала стабильно.
Взаимодействие с инфраструктурными сервисами. В тестируемой версии K‑NGFW не поддерживает работу в роли DNS-, DHCP- и NTP-серверов. Поэтому соответствующие задачи на стенде выполнял Windows Server 2022. K-NGFW обеспечивал маршрутизацию и фильтрацию трафика между клиентскими устройствами и инфраструктурными сервисами.
Функции управления и отказоустойчивости
Помимо сетевых возможностей, мы проверили удобство централизованного управления K-NGFW, работу с политиками безопасности и интеграцию с инфраструктурными сервисами.
Здесь нас интересовала не только функциональность, но и практическая сторона эксплуатации: какие операции доступны через графический интерфейс, для чего потребуется CLI и какие дополнительные компоненты необходимо развернуть.
Централизованное администрирование и работа с политиками. Для управления шлюзами мы использовали Kaspersky Security Center (KSC), выступающий в роли СУ. В ходе тестирования убедились, что базовые функции, такие как создание правил фильтрации, настройка профилей безопасности и конфигурация интерфейсов доступны через графический интерфейс СУ. Возможности GUI в системе управления реализованы так, что нет необходимости настраивать что-либо напрямую через CLI самих шлюзов (кроме первоначальной инициализации).
При этом обнаружилось ограничение: ручное переключение активного и резервного узлов HA-кластера в тестируемой версии выполнялось через CLI. Возможности провести эту операцию из GUI СУ не хватает. По информации вендора, ее поддержку планируется добавить в версии 2.0.
Локальный интерфейс управления шлюзами (CLI). Интерфейс командной строки K-NGFW оставил положительное впечатление. Через CLI можно получить подробную информацию о состоянии устройства, проверить конфигурацию, полученную от системы управления, и воспользоваться встроенными инструментами диагностики без необходимости установки сторонних утилит. CLI порадовал развитым встроенный инструментарием для глубокой диагностики и поиска неисправностей оборудования.
Сбор журналов и мониторинг событий ИБ (интеграция с KUMA). Важной особенностью является то, что в качестве системы анализа событий K-NGFW использует выделенный экземпляр Kaspersky Unified Monitoring and Analysis Platform (KUMA).
Такой подход имеет свои преимущества и особенности. Применение KUMA унифицирует экосистему Kaspersky и дает развитые инструменты анализа и корреляции событий. С другой стороны, это высокопроизводительная система анализа событий общего назначения, с потенциально высокими потребностями в вычислительных ресурсах. Мы не ставили перед собой задачу детального анализа этой особенности в рамках теста.
В ходе тестирования мы настроили передачу событий с узлов K-NGFW на коллекторы KUMA. После этого получили возможность централизованно анализировать журналы сетевого трафика и срабатывания механизмов безопасности, включая IDPS, потоковый антивирус и Веб-Контроль.Интеграция со службами каталогов (Active Directory). Для идентификации пользователей и сопоставления их учетных записей с IP-адресами использовали службу Kaspersky UAWS (User Awareness Service). Этот компонент собирает информацию о событиях входа (Logon Events) с контроллеров домена и передает данные на СУ и узлы K-NGFW, обеспечивая прозрачную идентификацию пользователей без необходимости постоянно вводить логин и пароль. Интеграцию по протоколу RADIUS мы не проверяли, поскольку в тестируемой версии продукта соответствующая возможность была недоступна.
Тестирование подсистемы безопасности
В рамках функционального тестирования мы проверили работу основных механизмов защиты K-NGFW: от блокировки сетевого сканирования до инспекции зашифрованного трафика.
1. Защита от сканирования
Для обнаружения и блокировки сетевого сканирования в K-NGFW предусмотрен отдельный механизм защиты, анализирующий входящий трафик из выбранной зоны.
Чтобы проверить его работу, мы запустили с тестового хоста «атакующий» сканирование внутренних систем с помощью утилиты nmap. В ходе испытаний проверяли реакцию NGFW на попытки обнаружения доступных узлов, открытых портов и определения операционных систем.
Модуль защиты отработал успешно: в проверенных сценариях попытки сканирования были обнаружены и заблокированы.
2. Система обнаружения и предотвращения вторжений (IDPS)
Для проверки IDPS был использован тестовый трафик, имитирующий известные сценарии эксплуатации уязвимостей (CVE). Атаки моделировали с виртуальной машины «атакующий», направляя трафик в сторону тестового узла «жертвы». Ряд сценариев не мог быть выполнен на узле «жертвы», но в нашем случае, это не влияет на результаты теста.
В ходе испытаний проверяли срабатывания следующих сигнатур и связанных с ними сценариев:
CVE-2024-38473.HTTP.C&C — возможность обхода аутентификации в Apache HTTP Server из-за ошибки обработки URL в модуле mod_proxy.
CVE-2024-32523.HTTP.C&C — уязвимость включения файлов в плагине Mailster для WordPress. Дополнительно использовались тестовые запросы, связанные с сигнатурой HTTP.Exploit.Carbid.C&C.
CVE-2022-39045.HTTP.C&C — возможность произвольной загрузки файлов через веб-интерфейс устройства Siretta QUARTZ-GOLD. Также проверяли обнаружение активности, соответствующей сигнатурам HackTool.ReconScan.TCP.ServerRequest и HackTool.PathTraversal.HTTP.C&C.
CVE-2022-38577.HTTP.C&C — повышение привилегий пользователя до уровня администратора в системе ProcessMaker.
В ходе испытаний K-NGFW успешно обнаружил и заблокировал все использованные тестовые сценарии.
Таким образом была подтверждена работоспособность IDPS на выбранном наборе известных сигнатур. Напомним, что оценка полноты сигнатурных баз и эффективности обнаружения неизвестных атак в задачи тестирования не входила.
3. Потоковый антивирус
Работоспособность антивирусного модуля мы проверяли классическим методом — попытались загрузить стандартизированный тестовый файл EICAR на узел «жертвы».
При попытке скачивания K-NGFW обнаружил тестовый файл и заблокировал его передачу. Сессия была разорвана, а в браузере пользователя появилась штатная страница с уведомлением о блокировке.
Таким образом, мы убедились, что антивирусный модуль корректно обнаруживает тестовый объект и применяет настроенную политику безопасности.
4. Веб-Контроль (URL-категоризация)
Для проверки Веб-Контроля с тестового хоста «жертвы» выполняли обращения к различным интернет-ресурсам, доступ к которым ограничивался политиками безопасности.
Проверяли работу встроенных категорий сайтов, включая «Социальные сети», «Игры» и «Электронная коммерция», а также возможность создания собственных категорий.
В ходе теста проверили работу модуля веб-контроля в сценарии, когда для сессии не настроена глубокая расшифровка TLS/SSL. В таких сценариях NGFW может определять доменное имя по полю SNI (Server Name Indication), передаваемому в сообщении TLS ClientHello, если оно доступно в открытом виде.
В наших тестах K-NGFW корректно определял домены, сопоставлял их с настроенными категориями и применял соответствующие политики безопасности. При обращении к запрещенным ресурсам доступ блокировался, а в проверенных сценариях пользователь получал страницу-заглушку с уведомлением.
5. Защита DNS-трафика (DNS Security)
Как уже упоминали, функции DNS-сервера на нашем стенде выполнял Windows Server 2022, а K-NGFW обеспечивал обработку транзитного трафика между клиентскими устройствами и сервером.
Для проверки DNS Security мы эмулировали обращения к доменам, относящимся к вредоносным, скомпрометированным и фишинговым ресурсам.
Нам было важно проверить, способен ли NGFW обнаружить и заблокировать потенциально опасный запрос еще на этапе разрешения доменного имени, до установления соединения с целевым IP-адресом.
Механизм защиты анализировал DNS-запросы, сопоставлял запрашиваемые доменные имена (FQDN) с базами угроз и применял настроенные действия. В зависимости от тестового сценария K-NGFW блокировал запрос или подменял DNS-ответ.
По результатам испытаний DNS Security корректно отработал на проверенных категориях доменов.
6. Инспекция зашифрованного TLS/SSL-трафика
Отдельное внимание уделили инспекции зашифрованного трафика. Сегодня значительная часть сетевого взаимодействия осуществляется по HTTPS, поэтому для анализа содержимого таких соединений механизмам безопасности требуется доступ к расшифрованным данным.
Без TLS-инспекции NGFW может анализировать только доступные метаданные соединения, например IP-адреса, параметры TLS и открытое поле SNI, но не содержимое зашифрованного HTTP-трафика.
Для проверки этой функции мы настроили в политиках K-NGFW инспекцию TLS-соединений по принципу Man-in-the-Middle (MitM). При такой схеме NGFW расшифровывает трафик для проверки механизмами безопасности, после чего повторно шифрует его перед отправкой получателю.
Чтобы браузер тестового хоста «жертвы» доверял сертификатам, формируемым при инспекции, мы предварительно добавили соответствующий корневой сертификат, сгенерированный СУ K-NGFW, в хранилище доверенных сертификатов «жертвы».
В проверенных сценариях K-NGFW успешно выполнял расшифровку трафика, передавал его содержимое механизмам безопасности и повторно шифровал перед отправкой адресату.
В ходе испытаний нами подтверждена работоспособность TLS-инспекции на выбранном наборе тестовых соединений, использующими версии TLS от 1.0 до 1.3.
Отказоустойчивость, мониторинг и обслуживание системы
Заключительный этап функционального тестирования мы посвятили проверке отказоустойчивости K-NGFW, мониторингу состояния устройств и процедурам обслуживания. Нам было важно оценить не только работоспособность этих механизмов, но и удобство их использования в повседневной эксплуатации.
В ходе испытаний проверили следующие функции:
Работа отказоустойчивого HA-кластера. Как уже упоминали, для функционального тестирования мы объединили два устройства K-NGFW в кластер. В ходе испытаний проверили синхронизацию конфигурации, маршрутной информации (RIB) и системных параметров между узлами.
Затем смоделировали аварийное отключение активного устройства, имитируя аппаратный сбой, потерю питания, отказ сетевого интерфейса/кабеля. Кластер успешно отработал сценарий Failover: резервный узел принял на себя обработку трафика, обеспечив продолжение сетевого взаимодействия. В наших тестах переключение происходило с минимальными задержками, без разрыва установленных сессий.
При этом выявилась особенность работы кластера: после восстановления основного узла автоматического обратного переключения (Failback) не происходило. Для возвращения ему активной роли требовалось вручную выполнить переключение через CLI, через GUI эта процедура недоступна.
Мониторинг состояния и производительности. Для наблюдения за состоянием K-NGFW мы настроили интеграцию с Zabbix с использованием протокола SNMP. На сервере мониторинга собирали основные показатели работы устройств: загрузку процессора (CPU), использование оперативной памяти (RAM), интенсивность трафика на сетевых интерфейсах и доступность узлов.
Для K-NGFW вендор предоставляет готовый шаблон Zabbix с большим количеством метрик. Это позволило достаточно быстро организовать мониторинг основных параметров системы.
Правда, готовых графиков нам оказалось недостаточно. Но благодаря большому количеству доступных метрик мы без особых сложностей создали собственные графики под задачи нашего тестирования.В результате получили удобный инструмент для наблюдения за состоянием устройств и анализа использования их ресурсов в процессе тестирования.
Обновление компонентов и обслуживание системы. Отдельно проверили механизм обновления баз модулей безопасности K-NGFW. Устройство поддерживает автоматическую проверку и загрузку обновлений для антивируса, IDPS и URL-категоризации через Интернет. При необходимости процедуру обновления можно запустить вручную из интерфейса системы управления.
В ходе тестирования убедились, что обновление баз выполняется корректно и не требует постоянного вмешательства администратора.
Кроме того, проверили процедуру сброса устройства к заводским настройкам (Factory Reset). После ее выполнения локальная конфигурация была очищена, а устройство вернулось в исходное состояние, готовое к повторной инициализации.
Заключение и выводы по результатам тестирования
Мы в К2 Кибербезопасность наблюдаем за развитием Kaspersky NGFW с версии 1.0. За это время нам удалось познакомиться с продуктом на разных этапах его развития, а теперь разобрать вместе с вами результаты функционального и нагрузочного тестирования версии 1.3.
По результатам испытаний мы выделили основные преимущества решения, а также несколько особенностей и ограничений, на которые стоит обратить внимание при эксплуатации.
Ключевые преимущества и положительные впечатления
В целом K-NGFW оставил положительное впечатление. Отметим несколько основных результатов:
Базовый функционал K-NGFW подтвердил свою работоспособность. Мы проверили основные сетевые возможности, механизмы безопасности и функции управления. В рамках проведенных тестов они корректно выполняли поставленные задачи. При этом часть функциональных возможностей имеет ограничения, о которых мы рассказали в соответствующих разделах.
Производительность оказалась на хорошем уровне. В базовом режиме L4 FW + AppControl обе аппаратные платформы достигли заявленных показателей пропускной способности: 10 Гбит/с для KX-100-KB1 и 40 Гбит/с для KX-400. При включении дополнительных механизмов безопасности производительность закономерно снижалась, однако устройства продолжали стабильно обрабатывать трафик в рамках выбранных сценариев нагрузки.
Механизмы безопасности успешно прошли функциональные проверки. IDPS, потоковый антивирус, Веб-Контроль, DNS Security и TLS-инспекция корректно отработали на выбранных тестовых сценариях. Напомним, что перед нами стояла задача проверить работоспособность этих механизмов, а не оценить качество обнаружения всех возможных угроз.
Отказоустойчивый кластер продемонстрировал стабильную и быструю работу. В ходе испытаний мы проверили несколько сценариев отказа активного узла. Кластер корректно выполнял переключение на резервное устройство, обеспечивая продолжение сетевого взаимодействия без разрыва установленных сессий. Критических сбоев в проверенных сценариях мы не обнаружили.
Отдельно хочется отметить удобство управления K-NGFW.
Графический интерфейс системы управления (GUI) оставил хорошее впечатление. На наш взгляд, он демонстрирует отличную эргономику. В GUI нет сложной многоуровневой вложенности, а все необходимые настройки и параметры политик находятся на виду. СУ позволяет создать единую политику правил безопасности и централизованно распространить ее на любые подключенные шлюзы NGFW. Это избавляет от необходимости дублировать сетевые объекты и правила фильтрации для разных площадок.
Интерфейс командной строки (CLI) также оказался удобным инструментом. Он предоставляет подробную информацию о состоянии устройства и его конфигурации, а встроенные средства диагностики позволяют разбираться в возникающих проблемах без необходимости установки дополнительных утилит.
Рекомендации по развитию («точки роста»)
Несмотря на положительные результаты тестирования, мы обнаружили несколько особенностей, которые, на наш взгляд, заслуживают внимания разработчиков.
Документация к API. На момент проведения испытаний нет полноценной документации к API K-NGFW. Это создавало сложности при попытках автоматизировать тестовые сценарии. По информации вендора, публикация соответствующей документации запланирована. Для системных интеграторов и крупных заказчиков развитие возможностей автоматизации особенно актуально. По нашей информации разработчик обещает выложить официальное руководство по API в ближайшем будущем.
Управление HA-кластером через GUI. В тестируемой версии нам не хватило возможности отслеживать и управлять переключением активного и резервного узлов кластера непосредственно через GUI СУ. Эта операция выполнялась через CLI. Указанный функционал находится в роадмапе на версию 2.0.
Нагрузка на интерфейсы при передаче журналов. Одним из интересных наблюдений стало количество трафика, генерируемого системой журналирования. При включении детального логирования событий в начале и конце сессий интенсивность трафика на интерфейсе управления в наших испытаниях достигала 850–900 Мбит/с.
С учетом того, что для управления использовался интерфейс с пропускной способностью 1 Гбит/с, такая нагрузка заслуживает отдельного внимания. При проектировании инфраструктуры с интенсивным журналированием стоит заранее оценивать ожидаемый объем событий и предусматривать достаточную пропускную способность каналов их передачи. В зависимости от масштаба инфраструктуры одним из вариантов может стать выделение отдельного высокоскоростного интерфейса и/или агрегированных интерфейсов для передачи событий в KUMA.
Само по себе большое количество событий не является недостатком продукта, однако, хотелось бы видеть более подробные рекомендации вендора по проектированию инфраструктуры журналирования и оценке необходимой пропускной способности.
Отсутствие Hit Counters в графическом интерфейсе СУ. В тестируемой версии системы управления нам не хватило отображения счетчиков срабатывания правил межсетевого экрана. Такие счетчики позволяют быстро понять, какие правила действительно используются, насколько часто они срабатывают и какие из них остаются невостребованными.
Для крупных инфраструктур с большим количеством политик безопасности это особенно полезный инструмент. Его наличие существенно упростило бы аудит правил, поиск неиспользуемых политик и повседневное администрирование. Вендор заявил, что данный функционал появится в версии 2.0.
Какой вывод можно сделать по результатам тестирования?
Kaspersky NGFW версии 1.3 показал себя как работоспособное решение с хорошей производительностью и широким набором сетевых и защитных функций. В рамках проведенных испытаний мы не столкнулись с критическими проблемами, которые помешали бы выполнению запланированных тестовых сценариев.
При этом у продукта остаются функциональные и эксплуатационные ограничения, которые необходимо учитывать при проектировании инфраструктуры. Часть из них касается удобства администрирования, другие могут потребовать дополнительных решений на этапе внедрения.
В целом K-NGFW оставил у нас положительное впечатление. Всего за год с момента запуска продукт показал очень сильное развитие и демонстрирует отличные результаты. На наш взгляд, продукт заслуживает внимания при выборе межсетевого экрана нового поколения для корпоративной сети. Однако окончательное решение о внедрении стоит принимать с учетом конкретных требований заказчика, предполагаемой нагрузки и результатов пилотного тестирования.
Если вы рассматриваете Kaspersky NGFW для своей инфраструктуры, мы можем помочь провести такое тестирование в условиях реальной сети.
