Измерение производительности NGFW

Основная задача любого производителя – создать продукт, удовлетворяющий требованиям потенциального потребителя, для того, чтобы этот продукт ему продать. А чтобы заинтересовать потребителя и помочь с выбором нужного продукта, производители рассказывают о его характеристиках. Это касается любой сферы, от продуктов питания до высокотехнологичных продуктов типа электроники или автомобилей.

Сегодня мы расскажем про тот тип продукта, в котором разбираемся лучше всего — про межсетевые экраны следующего поколения (NGFW).

Скрытый текст

Хотя и про автомобили тоже немного будет!

Как потенциальные потребители оценивают NGFW? Один из основных параметров –производительность. Этот параметр указывают все производители на своих сайтах и в маркетинговых листовках. Казалось бы, все просто, потребителю надо оценить свои задачи и выбрать продукт с подходящими для них параметрами производительности и необходимой функциональностью, купить и радоваться. Но все не так просто, объясним почему.

Как сравнить производительность NGFW по их описанию на сайте?

НИКАК!

На этом можно было бы закончить статью, но давайте обсудим.

Дело в том, что каждый производитель использует свою методику измерения производительности. И явно об этом пишет. Например:

Методики производителей покрывают сценарии, наиболее приближенные к реальным условиям использования, но это мнение производителя. Каждый вендор тестирует свой шлюз безопасности на той смеси трафика, которую он для себя признает эталонной или подходящей для тестирования. В методику включен определенный производителем набор сервисов и указываются параметры их работы.

Как правило, вендор в своих документах явно пишет, что в ваших условиях результаты будут другие, так как при любом изменении условий – тип трафика, включенные функции, настройки, количество правил и т д. – результат неизбежно меняется. Этот момент явно проговаривается.

А можно повторить самостоятельно результат производителя?

Да, можно. Если в точности следовать методике производителя: создать идентичный стенд для испытаний, использовать идентичное оборудование, использовать те же версии ПО, вплоть до совпадения билда сборки, повторить настройки. Тогда с небольшой погрешностью можно будет получить тот результат, который опубликовал производитель. Это вариант для тех, кто хочет проверять вендора. Только зачем вам такие тесты, если у вас будут совсем другие условия и решать нужно свою задачу?

Почему важна методика

Скрытый текст

Лирическое отступление, а потом снова про NGFW

Давайте сравним одни «железки» с другими. Тоже технологичными. Рассмотрим важность методики измерения на примере автомобильной отрасли.

Есть два параметра, которые почти всех интересуют при выборе автомобиля, за исключением цены, конечно. Это максимальная скорость и расход топлива (энергии).

Ни для кого не секрет, что для выявления максимальной скорости автомобиля производители идут на ухищрения используют особую методику, которая допускает, а иногда и требует максимально облегчить автомобиль (минимум топлива), отключить дополнительные системы, потребляющие энергию (кондиционер), проводить испытания в идеальных погодных условиях (отсутствия дождя, ветра, и т.д.), автомобиль должен двигаться прямолинейно без ускорений и торможений в наиболее экономном режиме.

Это лишь портрет методики, но ее цель и задача понятна? Видите в этом проблему? Где методика и где реальные условия эксплуатации?

Вернемся к нашим NGFW.

Показать то, что скрыто

Еще в начале 2010-х на сайтах производителей публиковали показатели производительности, не раскрывая детали того, как и при каких условиях получен результат тестирования.

Но постепенно рынок и требования стали меняться, сейчас вендоры опубликуют показатели производительности с обязательными дополнительными разъяснениями. Как правило, сейчас пишут что-то типа:

«Performance will vary depending on features activated, and network traffic protocol mix, and packet size characteristics. Performance is subject to change with new software releases. Consult your Cisco representative for detailed sizing guidance»

У каждого производителя своя методика и результаты одного производителя нельзя сравнивать с результатами другого до тех пор, пока вы не убедитесь в сопоставимости методик и результатов.

Само собой, такое разнообразие результатов и методик их получения привело к тому, что возникла необходимость создания универсальных и/или независимых методик. Поговорим о них.

Универсальные и независимые методики

Запрос на независимое и публичное тестирование был принят и воплощен в жизнь компанией NSS Labs — независимой организацией из США, с 1991 года занимающейся исследованиями и тестированием решений в области безопасности.  Большинство мировых производителей, являющихся лидерами в этой области, передавали свои продукты на исследование в NSS Labs, где проводилось тестирование по собственной единой методике, что позволило считать сравнимыми те результаты, которые NSS Labs публиковала в своих отчетах.

Одной из первых распространенных методик, изначально предназначавшейся для измерения производительности маршрутизаторов, но успешно примененной для тестирования шлюзов безопасности, стала RFC-2544.

Внимательный читатель уже обратил внимание на упоминание этого документа в методике CheckPoint на картинке выше. Не просто так CheckPoint относят данный документ к лабораторной методике или еще называют ее «идеальными условиями». Методика подразумевает измерение скорости для объекта тестирования при наличии всего одного правила, которое пропускает весь трафик.

В определенный момент времени мировое сообщество призналось себе, что стандарт RFC-2544 морально устарел и отрасли требуется новая методика, в результате чего появился документ RFC-9411. Он разработан для тестирования шлюзов безопасности, а не маршрутизаторов, и описывает множество тонких моментов, которые важно учитывать при тестировании данного типа продуктов.

Какие методики использует ИнфоТеКС при проведении тестирования NGFW и почему

В своих тестах берем за основу методики:

• RFC-2544;

• RFC-9411;

• методики NSSLabs для NGFW.

Почему мы используем методики NSS Labs? Потому что мы можем их воспроизвести и сравнить результаты! Мы используем инструменты для проведения тестов той же фирмы Ixia, что использовала NSS Labs, и мы можем сравнить наши результаты с результатами NSS Labs для других производителей.

Помимо основных целей и задач наших испытаний – выявлять возможности нашего продукта и контролировать его качество и стабильность работы, мы понимаем возможности нашего продукта в сравнении с конкурентами и определяем, к чему надо стремиться, чтобы сделать его лучше.

Профиль трафика — важная часть методики

Принято считать, что самая низкая производительность демонстрируется шлюзами безопасности при обработке трафика минимального размера IP-пакета. Вот что демонстрируют тесты NSS Labs:

Как мы видим, максимальная производительность достигается для IP-пакета размером 1500 байт, минимальная —  для пакетов размером 64 байта. И это независимо от производителя и аппаратной архитектуры продукта.

Однако, благодаря NSS Labs мы получили результаты и других тестов (см. ниже). NSS Labs провели тесты, выявляющую пропускную способность шлюзов безопасности для случаев, когда идет обработка одного типового вида пользовательского трафика.  И выяснилось, что для протокола SMB пропускная способность шлюза еще ниже, чем в случае с UDP размером 64 байта.

У CheckPoint разница составляет порядка двух раз в пользу пакета размером 64 байта, а у Palo Alto почти 17 раз.

Делаем выводы: производительность шлюза безопасности кардинально зависит от того, какой тип трафика и какой сетевой протокол обрабатывается шлюзом безопасности.

IMIX, EMIX и Заказчик-MIX

Как мы выяснили в предыдущем разделе, от типа протокола и трафика зависит поведение – производительность шлюза безопасности. Но тесты, которые были проведены NSS Labs, показывают результаты лишь для одного типа трафика и просто сведены на одном графике для удобства восприятия.

В реальных же сетях мы имеем дело с множеством разнородного трафика. Мы имеем так называемые «мультисервисные сети», то есть сети в которых одновременно работает множество сервисов. И у каждого заказчика свой собственный набор сервисов в сети.

Одним из первых производителей, задумавшимся над задачей выявления пропускной способности в мультисервисных сетях, был Juniper, который в своих публикациях (https://www.juniper.net/ru/ru/products/security/srx-series/srx4200-services-gateway-enterprise-firewall.html ) стал указывать производительность для IMIX (Internet MIX) трафика.

IMIX – это такой усредненный трафик в магистральных сетях, для его подсчета сообщество проанализировало весь трафик Интернет (когда-то на момент разработки IMIX) и выявило долю пакета типового размера в общем объеме. Получилось примерно так: в одной порции трафика есть 1 пакет размером 1500 байт (8.3%), 7 пакетов размером 40 байт (58,3%) и 4 пакета размером 576 байт (33,3%). Все пакеты включают размер заголовка. Вероятно, это было началом, но не итоговым результатом в борьбе потребителей за публикацию сопоставимой информации о производительности.

Да, IMIX-трафик, как и в случае с появлением показателей расхода топлива автомобилей в городском и загородном циклах, изменил цифры в разделе «производительность» на сайтах вендоров, покупатели стали задумываться, как такие результаты интерпретировать и применять к своим задачам.

Это привело к появлению нового термина Enterpise MIX (EMIX) – смесь трафика корпоративных заказчиков. Но тут возникла новая проблема, у каждой компании он оказался во-первым своим и уникальным, а во-вторых, закрытым (не публичным) и никто не хотел им делиться. И тут на сцену снова выходит NSS Labs со своей публичной методикой.

NSS Labs использует такую смесь трафика (см. ниже):

То есть универсальная методика есть, можно тестировать и сравнивать полученные результаты. Но и тут оказалось не все так просто, как хотелось бы. Как говорилось выше, у каждого заказчика свой профиль трафика, свои условия, все это в итоге влияет на показатели пропускной способности шлюза безопасности.

Теперь самое интересное. Приведу пример из нашей практики.

Потенциальный заказчик проводит тестирование шлюзов безопасности. В рамках тестирования были запланировано проведение в том числе и нагрузочного тестирования. Для проведения тестов использовалось оборудование Ixia, была разработана методика тестирования и использовался профиль трафика заказчика.

По условиям испытания необходимо было предоставить шлюз безопасности с пропускной способностью 1 Гбит/сек. Мы в свою очередь передали шлюз, который, согласно нашим измерениям, демонстрирует пропускную способность до 250 Мбит/сек. Потенциальный заказчик выразил недоумение по этому поводу, но допустил нас до испытаний. В процессе испытаний наш шлюз безопасности продемонстрировал пропускную способность 920 Мбит/сек.

На вопрос заказчика, почему мы в официальных документах публикуем показатель 250 Мбит/сек, а устройство при этом демонстрирует существенно лучшие показатели, мы ответили, что все дело в методике, а точнее в использованном на испытаниях профиле трафика, который на 90% состоит из http/https-трафика, что является легкой задачей для шлюзов безопасности. Мы используем свою методику и свой профиль трафика, так как считаем их универсальными, то есть подходящими большинству покупателей. Умудренные опытом читатели могут развить дискуссию на тот счет, говоря о том, что http/https трафик «разный», нужно смотреть размер транзакции, требуется ли так называемый SSL decrypt и т д. Но, собственно, все эти нюансы и есть методика тестирования.

Все понятно, спасибо. Но нам-то что делать?!

Эксперты сходятся во мнении, что лучший способ выбрать подходящий именно вам шлюз безопасности – это проведение тестирования на вашем трафике в ваших условиях.

А если это невозможно? Тогда вам нужно разобраться, как производитель получил тот или иной результат, то есть ознакомиться с методикой тестирования. И примерять эту самую методику на реальные условия вашей сети.

Советы бывалых

Наши рекомендации, на что стоит обратить внимание:

Количество правил

Когда публикуют данные о производительности, редко кто указывает, сколько правил фильтрации было активно в момент тестирования. Например, CheckPoint в своей методике SPU (SecurityPowerUnit) заявляет 100 правил фильтрации.

Достаточно ли этого? Казалось бы, да, ведь если тестирование проводится согласно RFC-2544, то правило фильтрации в тесте одно – всем всё разрешено. А тут в 100 раз больше.

Но! RFC-9411 предполагает использование 562 правил фильтрации/доступа. В 5 раз больше! Может быть этого достаточно для проведения тестирования?

Правильный ответ отсутствует. У нас есть заказчик, у которого на старте проекта было 5 тысяч правил фильтрации/доступа, а через год их стало 10 461.

Что же делать заказчику? Важно ли количество правил при тестировании и потом в работе? Как показывает опыт, количество правил – важный параметр и он серьезно влияет на производительность шлюза безопасности.

Если производитель сообщает, что тестирование проводится по методике RFC-2544, то Вы понимаете, что это одно правило. Скорее всего, вам этого недостаточно. Если RFC-9411, то правил существенно больше – 562. Вероятно, этого достаточно, во всяком случае так учат нас все практики ИБ, говорящие, что необходимо оптимизировать политику ИБ.

Но если Вы понимаете, что у Вас свой случай, то нужно обсуждать его с производителем.

Профиль трафика

Вернемся еще раз к профилю трафика. Мы упоминали, что один и тот же шлюз безопасности может демонстрировать различную производительность в зависимости от типа трафика. А когда будет смесь трафиков, то результат можно выяснить только испытаниями.

В тестах NSS Labs есть результаты производительности шлюзов в зависимости от типа трафика. Из них видно, что при обработке FTP шлюзы демонстрируют высокую производительность, а при обработке SMB-трафика показывает результат в 10 раз ниже. И видно, что такое поведение характерно для шлюзов всех производителей.

Далее обращаем внимание на смесь EMIX от NSS Labs и видим, что в этой смеси всего 5% FTP и нет вообще SMB. А у нас есть заказчик, у которого почти 50% трафика составляет SMB. Очевидно, что шлюз безопасности в случае этого заказчика будет показывать низкие показатели производительности, но виной тому не производитель шлюза, не методика, а сам SMB трафик.

Лучшее из решений – создать свой профиль трафика и попросить производителя провести с ним тестирование. Если это невозможно, то постараться понять какой профиль трафика у производителя используется для его тестов, как он соотносится с вашим и пробовать аппроксимировать эти данные. Та еще задача…

Журналирование

При анализе данных о производительности никто не задается вопросом, а включено ли журналирование. А как показывает практика, задача журналирования всего происходящего в шлюзе безопасности является достаточно ресурсоемкой. В методике RFC-2544 это учтено, в RFC-9411 тоже. Правда первая методика не определяет действие, а значит журналирование при испытаниях можно и не включать, вторая же требует включения журналирования, но не описывает уровень детализации. Поэтому если вендор декларирует, что тесты проводятся по RFC-9411, то журналирование включено, однако уровень детализации при этом неизвестен. А если по RFC-2544 – то журналирование точно выключено. Если используется собственная методика – детали нужно выяснять у производителя. При этом не стоит забывать, что требования заказчика обычно включают в себя журналирование всего!

Выводы

Если к концу статьи вы еще не сделали выводы сами, то подсказываем:

1. Все производители честны со своими заказчиками.

2. Опубликованные производителем параметры получились при использовании собственных методик тестирования продукта

3. Все производители подробно описывают свою методику, поищите или запросите документ.

4. Вам это все равно не поможет, потому что продукт в ваших условиях будет показывать совсем другие цифры, и это нормально.

5. Прежде чем покупать продукт, обратитесь к интегратору или к вендору, чтобы они провели тестирование в условиях, максимально приближенных к вашим реальным.