Выражаю благодарность компании Bi.Zone и Код Безопасности за достаточно смелую публикацию результатов тестирования. Поскольку я фанат NGFW и занимаюсь защитой сетей с 1998 года, то мне было интересно узнать подробности.
PS: Ко мне обратились коллеги из Кода Безопасности. Оказалось, что схема стенда в отчете - верна только для тестов с 5 по 10. Тесты с 1 по 3 проводились на том же стенде, где включен один межсетевой экран. По 4 тесту сейчас без схемы непонятно что там было с чем соединено и как физически и логически тестировался LAG.
Аппаратная часть
Коллеги создали мощный стенд:
- кластер из двух L3 коммутаторов Eltex MES5500-32 версия ПО — 6.6.2.9;
- кластер из двух сетевых балансировщиков DS Integrity-100G (каждый разделен логически пополам);
- кластер из 16 устройств межсетевого экранирования IPC-R3000 версия ПО — 4.1.9
- и система управления с той же версией.
Получилось всего 21 устройство.
Схему стенда показывали сотрудники Бизон на презентации в студии
В качестве генератора трафика были выбраны генераторы трафика Ixia Cloud Storm и Novus 100G с генератором XGS2-HSL2 с карточками L4 и L7. Напомню, что IXIA использует FPGA для ускорения работы.
Устройство IXIA.
Функционал межсетевого экрана
Само межсетевое экранирование производилось по IP портам, то есть функционал блокирования приложений движком DPI не тестировался.
Я, конечно, хотел уже дальше не читать отчет... И я думаю вы тоже.. но природная любознательность заставила... Причина проста: большинство приложений сегодня работает по 443 порту и вам обязательно нужна контентная фильтрация, потому что по портам вы либо просто запрещаете этот порт, либо просто разрешаете. И это уже не работает. Чтобы не повторяться: прошу прочитать про это статью "Межсетевой экран нового поколения - это маркетинг", где приведены какие это 173 приложения работают на 443 порту из реальной сети. То же самое с 80 портом.
Число правил для теста выбрано 1000, что подходит для небольших заказчиков.
Но поскольку производительность ожидалась 400 Гбит/с, то 1000 правил я бы поменял на 10000. Самое большое количество правил, что я видел в своей жизни - 120000. А сколько вы видели? )
Предлагаю сделать такой же тест на 10000 и 100000 правил.
Предлагаю сделать такой же тест на 10000 и 100000 правил.
Тесты
В ходе проверок было проведено 10 различных тестов.Основные тесты это:
1. Максимальное число успешно открытых новых TCP соединений в секунду в режиме L4;
2. Максимальное число одновременных TCP соединений в памяти в режиме L4;
3. Максимальная пропускная способность в режиме L7 (DPI) без маршрутизации, с маршрутизацией, с NAT и без NAT, с IPS и без IPS;
4. Проверка потерь сессий при выходе из строя устройства;
5. Максимальная пропускная способность в режиме L4 на UDP;
И еще пять, что описано на 11 странице отчета.
Результат 26 Гбит/с в режиме DPI и SNAT на 1 межсетевом экране
Поскольку было 73000 транзакций в секунду, то это в среднем 35Кб на транзакцию.
Сам поток трафика состоял из различных приложений, вот их список и процент разбивки в самом потоке.
19.21% 115348 байт транзакции TLS 1.2, без расширования
15.37% 26184 байт транзакции Google Search GET Home Page - я так понимаю это тоже TLS
14.09% 6267 байт транзакции Yahoo Search GET Home Page - я так понимаю это тоже TLS
12.81% 12450 байт транзакции TLS 1.2, без расшифрования
2.56% 217403 байт транзакции GMAIL и это тоже TLS
В итоге 64% трафика был зашифрованный поток данных в TLS, в котором чаще всего нечего проверять фильтру контента, кроме TLS Handshake где можно глянуть версии TLS, SNI и URL категории. Это все не проверялось. По распределению TLS 1.2 и TLS 1.3 в интернет лучше посмотреть на сайте ssllabs.com/ssl-pulse/ на момент прочтения статьи.
Скриншот из интерфейса IXIA, где показаны настройки тестового трафика.
Результат 4 Гбит/с IPS на 1 устройстве
На мой взгляд, тестировать производительность IPS просто подачей трафика - некорректно. Нужно еще проверять, что на этом максимальном потоке трафика IPS вообще как-то работает - то есть блокирует атаки. А то, что у нас есть устройство, которое просто быстро пропускает трафик - и что? )
В других тестах мы выявляли, что при подаче трафика IPS перестает блокировать атаки. И поэтому я бы добавил еще в тест страйки IXIA. И именно так - только вместе с атаками мы понимаем максимальную производительность IPS.
Скриншот IXIA где показано сколько атак заблокировано и сколько пропущено.
Павел Луговов на конференции SSTA в Бизон отлично рассказал как правильно тестировать атаки и вирусы в трафике. Также Владислав Закревский на той же конференции показывал как падает производительность Suricata при подаче трафика.
Четыре неожиданных результата
1. Выяснилось, что сам генератор IXIA максимально может выжать 200 Гбит/с в режиме L7. Поэтому пришлось выключать генерацию трафика приложений и переходить на режим L3 без проверки, что сессии были реально уставлены.Если кто-то из производителей говорит, что у него больше 200 Гбит/с NGFW, то спросите их чем они трафик приложений генерировали. ;-) Вдруг yandex-tank.
Что, в общем, совпадает с datasheet этого вендора.
2. Выяснилось, что пакетный брокер тоже пропускает не бесконечно много трафика: он достиг производительность 400 Гбит/с для двунаправленного трафика. Поэтому если вы тестируете такой трафик, то вам нужно ЧЕТЫРЕ пакетных брокера.
3. Одна система управления не справляется с журналированием такого объема трафика: 400 Гбит/с.
4. Уперлись в ограничения BGP в коммутаторе Eltex. Ну и какие-то проблемы с ICMP (подробнее описывает 32 страница отчета).
4. Уперлись в ограничения BGP в коммутаторе Eltex. Ну и какие-то проблемы с ICMP (подробнее описывает 32 страница отчета).
Вывод
Ставить 16 межсетевых экранов и балансировать их - непростое решение для технических специалистов. Как написано в отчете Bi.Zone, отлаживать проблемы было почти невозможно - не проходил ICMP длиной 64 байта через стенд, не было возможности запустить сниффер трафика на Eltex. В эксплуатацию я бы такое не принял.
Тестирование на UDP трафике - это самое странное, что можно делать при выборе межсетевого экрана, ведь в реальной сети такого трафика нет. Тестировать то, чего не бывает? Чтобы что? ) Я догадываюсь, что для того, чтобы впечатлить непрофессионалов. Это все равно что, тестировать производительность поликлиники, где люди входят и сразу выходят. Очень быстрая поликлиника. Скоро видимо у нас и такие будут. А полечиться? Впрочем, я уже писал про это.
Поэтому если вам где-то пишут производительность на UDP 1500 байт (или в PPS или FPS) - шлите их лесом. Так делают Check Point и Fortinet? Вот их и шлите. Это делают их люди из маркетинга. И скажите этим людям то, что написано ниже:
Самое важное в NGFW - это
Threat Protection или Threat Prevention Troughput.
Это тот самый параметр производительности, который нужен заказчику.
Рынок РФ должен целиться в создание высокоростных устройств: которые в одном устройстве дают нужную производительность.
В итоге, я бы лучше купил PA-3440 две штуки и поставил в кластер HA, чем всю эту огромную конструкцию из 21 устройств. Во первых займет всего 2 юнита, во-вторых производительность даже больше в тесте trhoughput и new sessions, в третьих и питания нужно меньше. И самое главное - там будет настоящий HA где будут синхронизироваться состояния сессий. А в данном решении такого не было.
Посмотрите, число одновременных сессий у Palo Alto 3 000 000, но как мы знаем это в режиме L7, когда запоминается состояние приложений L7. Число одновременных сессий в режиме L4 и L7 отличается минимум в 10 раз, потому что в режиме L7 на состояние сессий нужен буфер большего обмена при той же памяти устройства. Поэтому 10 0000 000 сессий в тесте выше в режиме L4 будет падать до 1 миллиона сессий в режиме L7.
PS: Одна важная вещь
Когда вы смотрите datasheet или когда вы смотрите тесты независимой лаборатории, то учитывайте, что все строки - это РАЗНЫЕ тесты. Не существует такого устройства, которое одновременно дает 10 миллионов TCP сессий, одновременно при этом 150000 новых сессий и одновременно при этом 28 Гбит/с. Это все результаты трех РАЗНЫХ тестов на РАЗНОМ трафике, пусть для одного и того же устройства. Подавался разный трафик и тестировалось РАЗНОЕ. В реальной жизни эти числа достигнуты НЕ БУДУТ все одновременно.
Например, тут - три разных теста.
Для погружения в тестирование NGFW рекомендую серию из трех видеороликов
Как проходит тестирование
Как смотрят параметры CC, CPS, Throughput разные поставщики
Разбираемся с размером транзакций через тесты NSS Labs