Я работаю в центре киберзащиты DataLine и в числе прочего занимаюсь межсетевыми экранами нового поколения (NGFW): тестирую новые решения, внедряю, настраиваю, слежу за работоспособностью.
В прошлый раз коллеги уже рассказывали про аналог западных NGFW на случай санкций и показывали схемы подключения виртуального шлюза безопасности в облаке. Но что если компания имеет на балансе аппаратный межсетевой экран и хочет продолжать использовать именно его, а не облачное решение? Например, если нужна частная инсталляция, а покупать новый аппаратный шлюз пока нет возможности.
С этой мыслью мы запустили тесты производительности отечественного UTM UserGate в интересном контексте: мы подняли версию UserGate на программно-аппаратном комплексе от зарубежного вендора NGFW. В статье поделюсь сценариями тестирования и покажу результаты на одном популярном устройстве. При желании такие же тесты можно прогнать на любом другом оборудовании.
![](https://habrastorage.org/getpro/habr/upload_files/775/2e1/971/7752e197106f7f5694d648e7b478ebc9.png)
Характеристики оборудования
Мы взяли старое оборудование, на котором не было действующей лицензии. Бывает, что такие устройства лежат без дела на складе, вот и у нас так и случилось.
Сдуем пыль с нашего NGFW и посмотрим, что умеет такое оборудование без вендорского софта.
Архитектура процессора: 2x CPU, 16x physical cores, 32x virtual cores (total).
Оперативная память: 16 Gb.
Диски: 2х1 TB HDD.
Сетевая карта: 2x10 Gbps. Есть 3 слота расширения для сетевых карт.
Во время теста мы накатим на него софт от UserGate, посмотрим, что происходит с производительностью устройства и пропускной способностью сети, и сделаем вывод о жизнеспособности такой схемы.
Подготовительная работа и схема подключения
В самом начале сотрудничества мы запросили у коллег из UserGate ТТХ под виртуальные решения для тестов. Но показатели характеристик вендора посчитаны под виртуализацию на процессорах с частотой в 2GHz. В наших облаках виртуализация построена на процессорах с частотой 3.1GHz. В итоге нам удалось получить более высокие показатели на своих тестах и заодно обкатать сценарий тестирования UserGate.
Затем получили у вендора специальный загрузчик для установки ОС на “неродное” оборудование. Далее взяли образ 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 этапов тестирования.
Как тестировали
Подключили правила межсетевого экранирования. Начнем тесты только с межсетевого экрана (МЭ). Включим следующие правила:
Результат. Сначала смотрим скорость потока:
Результат с тестом iperf -c 10.1.1.100 -P 70 -t 120. Результат с тестом iperf -c 10.1.1.100 -P 70 -w 32768 -t 120. Теперь глянем на график производительности 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 на неродном ПАКе нисколько не уступает по производительности виртуальному UserGate. Будем рады обсудить результаты ваших экспериментов по этому сценарию.