Тестируем шлюз безопасности UserGate на железе зарубежного NGFW
Я работаю в центре киберзащиты DataLine и в числе прочего занимаюсь межсетевыми экранами нового поколения (NGFW): тестирую новые решения, внедряю, настраиваю, слежу за работоспособностью.
В прошлый раз коллеги уже рассказывали про аналог западных NGFW на случай санкций и показывали схемы подключения виртуального шлюза безопасности в облаке. Но что если компания имеет на балансе аппаратный межсетевой экран и хочет продолжать использовать именно его, а не облачное решение? Например, если нужна частная инсталляция, а покупать новый аппаратный шлюз пока нет возможности.
С этой мыслью мы запустили тесты производительности отечественного UTM UserGate в интересном контексте: мы подняли версию UserGate на программно-аппаратном комплексе от зарубежного вендора NGFW. В статье поделюсь сценариями тестирования и покажу результаты на популярном устройстве розового цвета. При желании такие же тесты можно прогнать на любом другом оборудовании.
Характеристики оборудования
Мы взяли старое оборудование, на котором не было действующей лицензии. Часто такие устройства у компаний просто лежат без дела из-за нерентабельной схемы возобновления техподдержки. Например, политика лицензирования некоторых вендоров требует оплаты пропущенных лет техподдержки, даже если все предыдущие годы межсетевой экран не использовался.
Сдуем пыль с нашего NGFW и посмотрим, что умеет такое оборудование без вендорского софта.
Архитектура процессора: 2x CPU, 16x physical cores, 32x virtual cores (total).
Оперативная память: 16 Gb.
Диски: 2×1 TB HDD.
Сетевая карта: 2×10 Gbps. Есть 3 слота расширения для сетевых карт.
Во время теста мы накатим на него софт от UserGate, посмотрим, что происходит с производительностью устройства и пропускной способностью сети, и сделаем вывод о жизнеспособности такой схемы.
Подготовительная работа и схема подключения
В самом начале сотрудничества мы запросили у коллег из UserGate ТТХ под виртуальные решения. Но показатели характеристик вендора посчитаны под виртуализацию на процессорах с частотой в 2GHz. В наших облаках виртуализация построена на процессорах с частотой 3.1GHz. В итоге нам удалось получить более высокие показатели на своих тестах.
Затем получили у вендора специальный загрузчик для установки ОС на «неродное» оборудование. Далее взяли образ UserGate и установили его по официальной инструкции.
Смонтировали такую цепочку: 2 виртуальные машины, а между ними наш старый NGFW с UserGate 6.1.5.11134R на борту.
Схема стенда:
Характеристики виртуальных машин:
ВМ: IB-TEST-01.
ЦП: 4 vCPU.
ОЗУ: 8GB.
Диск: 50GB SSD.
Сеть: 10Gbps.
Зона: Trusted.
Назначение: iperf server.
ВМ: IB-TEST-02.
ЦП: 4 vCPU.
ОЗУ: 8GB.
Диск: 50GB SSD.
Сеть: 10Gbps.
Зона: Untrusted.
Назначение: iperf client.
Для генерации трафика на ВМ использовался iperf 3.7. Во время каждого теста мы отправляли максимальный трафик в многопоточном режиме с одной ВМ на другую в течение двух минут. В каждом новом тесте последовательно подключали дополнительные модули UserGate и фиксировали нагрузку на процессор и память NGFW при разных конфигурациях виртуального решения. Получилось 5 этапов тестирования.
Как тестировали
Подключили правила межсетевого экранирования. Начнем тесты только с межсетевого экрана (МЭ). Включим следующие правила:
Результат. Сначала смотрим скорость потока:
Теперь глянем на график производительности UserGate: нагрузка на CPU минимальна, ~3%.
Добавили IPS (систему обнаружения вторжений, СОВ). Усложним задачу для UserGate. Создадим пару профилей IPS: для Windows-систем и для Unix-систем, — и назначим их в разные правила СОВ.
В первом профиле отфильтруем по уровню критичности (средний, высокий, очень высокий) и укажем ОС семейства Windows.
Во втором профиле сделаем аналогично, но для Linux ОС.
Создадим под каждый профиль отдельное правило СОВ.
Принудительно применяем правила МЭ и снова запускаем iperf.
Результат. Первые 15–20 секунд скорость не превышает 7,5–8 Гбит/с, а загрузка ЦП UserGate подскакивает до 21%. Далее все разгоняется, а процессор по загрузке опускается до 8%.
Вот что показывает iperf:
Включили фильтрацию контента. Здесь подключили все правила по умолчанию: списки блокировки, списки фишинговых сайтов, реестры запрещенных сайтов, фильтрацию по морфологии.
Применим принудительно правила МЭ и снова повторим тест с iperf.
Результат:
Добавили правила веб-безопасности. Теперь задействуем стандартное правило безопасного поиска.
Результат: ЦПУ до 19% в пике.
Подключили инспекцию SSL. Тоже ориентируемся на правила по умолчанию:
Производительность:
Результат. При 120 потоках трафика:
При 128 потоках трафика:
На всех тестах загрузка процессора не превышала 21%. Главное — не упереться в полосу пропускания сетевой карты. При желании можно добавить еще пару сетевых карт к этой модели и ускорить трафик.
Какие трудности возникли
Не завелась LCD-панель. Обычно на ней отображается статус инициализации, но мы не увидели ничего полезного:
Съехала нумерация интерфейсов. Допустим, у нас есть 8 портов у сетевой карты с заданной нумерацией от 1 до 8. Когда мы установили UserGate, он сам присвоил порядковые номера для портов по возрастанию MAC-адресов. Соответственно, номера на железке и в интерфейсе UserGate не совпали.
UserGate не смог определить дисковый контроллер, который позволяет настраивать массив RAID. Из-за этого операционная система UserGate установилась только на один диск массива из двух.
Это самое неприятное открытие: если один диск выйдет из строя, второй не сможет обеспечить нам отказоустойчивость. Информацию сразу же передали вендору, надеемся, скоро удастся это исправить.
В целом же такое решение с UserGate на неродном ПАКе нисколько не уступает по производительности виртуальному UserGate. Будем рады обсудить результаты ваших экспериментов по этому сценарию.
