Исследование российского рынка NGFW показало, что только 16% опрошенных довольны установленными российскими межсетевыми экранами. Наше общение с клиентами это подтверждает. При этом ошибка при выборе межсетевого экрана нового поколения может стать фатальной, так как именно NGFW отвечает за отказоустойчивость бизнеса и его защиту от кибератак.
Я, Юрий Дышлевой, более 10 лет занимаюсь сетевыми технологиями. За это время я успел построить множество сетей федерального масштаба. Большинство этих сетей сейчас активно перестраивают, пытаясь найти аналоги зарубежным продуктам. Вместе с командой разработки PT NGFW мы поставили себе цель — создать межсетевой экран мирового уровня.
Проанализировав потребности клиентов, мы решили рассказать о том, какими сложными могут быть ответы на вроде бы простые вопросы: как правильно выбрать NGFW? Что может послужить стоп-фактором? Кроме того, собрали топ пять ошибок при выборе межсетевого экрана, чтобы вам было проще ориентироваться в будущем, когда вам понадобится идеальный NGFW.
1. Неумение работать с российскими приложениями
Исторически, когда Palo Alto вышел на рынок NGFW, термин «межсетевой экран следующего поколения» подразумевал возможность работы с пользователем и приложением, к которому он пытается получить доступ. Эксплуатируя решения западных производителей NGFW, администраторы привыкли к этому.
Когда NGFW не может решить эту задачу, теряется первоначальная суть продукта этого класса. Субъективно можно выделить две основные причины потери возможности распознавать приложения:
Для западного производителя добавление российских приложений в базы знаний продукта никогда не было в фокусе. А с уходом с российского рынка необходимость пополнения базы специфичной информацией и вовсе исчезла. Это, кстати, отмечают и сами пользователи.
Используемая база данных приложений неактуальна или не отвечает требованиям конкретной компании.
Как итог — вместо NGFW остается FW, то есть обычный межсетевой экран транспортного уровня.
В современном мире задача распознавания приложений существенно усложняется и превращается в задачу со звездочкой, когда необходимо разобрать приложение до атомарного уровня (то есть определить, что конкретно пользователь делает с приложением). Например, сейчас нельзя представить работу маркетолога вне социальных сетей. То есть NGFW, установленный в компании, не должен ограничивать решение рабочих задач маркетинга. Если NGFW способен только разрешить или заблокировать доступ, например, к VK, это не самый продвинутый NGFW. Для гранулярной настройки политики доступа к внешним ресурсам межсетевой экран должен иметь возможность, например, запретить доступ к прослушиванию музыки, но при этом сохранить доступ к VK.
Совет: узнайте, может ли используемый вами или рассматриваемый к покупке NGFW предоставить подобный способ настройки правил.
2. Отсутствие у вендора собственной экспертной группы для создания сигнатур, IoC и базы знаний продукта
Для этого критерия существует достаточно простая аналогия: если для антивируса используется неактуальная база данных угроз, то его эффективность резко снижается. При этом неважно, насколько продвинутые технологии он использует.
Продукт класса NGFW обладает похожим свойством. Любой крупный зарубежный производитель имеет свой центр накопления знаний об актуальных угрозах и их трансформации в код, с которым может работать межсетевой экран следующего поколения (например, Cisco Talos).
В России собственные экспертные центры пока не так распространены. Наличие подобного подразделения показывает степень зрелости игрока на рынке. Например, у нас есть PT Expert Security Center (PT ESC).
Почему это важно? В начале ноября 2023 года был обнародован внушительный список уязвимостей приложения «1С-Битрикс» (ваш межсетевой экран знает о таком приложении?). PT ESC быстро отреагировал на эту публикацию и обновил базу знаний актуальных угроз информационной безопасности для российского ландшафта.
Когда мы показывали работу IPS в NGFW в рамках кибербитвы Standoff 12, мы, конечно же взяли сигнатуры от PT ESC для самых актуальных угроз и подготовили весомую порцию вредоносов на эмуляторе. Настолько весомую, что даже межсетевые экраны из правого верхнего угла Gartner не смогли обнаружить их все. Смело заявляем об этом, потому что проводили соответствующее исследование.
Тестовые угрозы в сценарии, продемонстрированные на Standoff 12 | |
ArcServe Authentication Bypass attempt | CVE-2023-26258 |
Cisco Unauthenticated Heap Buffer Overflow in websUrlParse | CVE-2023-20024 |
PaperCut Possible Auth Bypass | CVE-2023-27350 |
Possible Veeam Backup & Replication Credential leak | CVE-2023-27532 |
Fortinet FortiNAC RCE attempt | CVE-2022-39952 |
VMWare vRealize. remotePakDownloadCommand execution | CVE-2022-31704 |
vBulletin <=5.6.9 pre-auth RCE | CVE-2023-25135 |
TeamCity authentication bypass attempt | CVE-2023-42793 |
Openfire Path Traversal attempt | CVE-2023-32315 |
Citrix ShareFile RCE attempt | CVE-2023-24489 |
Совет: уточните, какими базами знаний обладает используемый у вас или планируемый к приобретению межсетевой экран и как быстро производитель выпускает на них обновления.
3. Отсутствие системы централизованного управления и (или) журналирования
Чем больше бизнес, тем сложнее им управлять. С NGFW точно так же: чем их больше, тем продуманнее и удобнее должна быть система централизованного управления. При этом сам факт наличия такой системы еще не означает, что задача эксплуатации большого количества межсетевых экранов будет решена. Удобство — понятие крайне субъективное.
Каким бы опытным и именитым ни был производитель NGFW, он не может предусмотреть все сценарии администрирования сотен или тысяч устройств в системе управления. Но решение есть — API.
Не все, но многие зарубежные производители стараются поддерживать свой API в открытом и доступном виде без необходимости регистрации и заключения контракта. Производители российских NGFW не всегда так делают. При случае следует задать вопрос: как познакомиться с документаций на API продукта и насколько современный транспорт и полезную нагрузку использует производитель? На наш взгляд, удобным на сегодня является транспорт HTTPS и нагрузка в виде JSON. С этим согласны и мировые лидеры рынка NGFW.
Осталось решить проблему с системой централизованного журналирования. Чаще всего нам задают два вопроса:
Существует ли она вообще?
Можно ли выгружать из нее данные во внешнюю систему?
Первый вопрос довольно неожиданный. Кажется, что если ее нет, то от диалога с производителем такого NGFW стоит отказаться, потому что поиск инцидентов информационной безопасности или поиск ошибок конфигурации в этом случае может превратиться в сущий ад.
Второй вопрос тоже важен, но в 2024 году, на наш взгляд, он должен быть сформулирован несколько иначе: как именно предлагается выгружать журналы во внешнюю систему?
Возможно несколько вариантов:
Syslog,
Телеметрия,
Ручное копирование оператором из одной системы в другую (Шутка. Этот вариант не стоит даже рассматривать 😎).
Первый вариант традиционен и привычен. Но он медленный, а для 2024 года и объема сообщений в современных системах катастрофически медленный. Представьте себе систему управления на 10 000 устройств, которые пытаются отгружать журнал в формате Syslog по каждому правилу. Во-первых, это ресурсозатратно, во-вторых, задача чтения журнала в таком формате может стать весьма сложной.
Совет: спросите у своего поставщика NGFW, готов ли он работать с современными методами передачи журналов в формате телеметрии. Это косвенно даст понять, вкладывался ли производитель в вопросы оптимизации транспорта журналов.
Кроме использования телеметрии как средства журналирования сразу же приходит мысль ее применения для мониторинга состояния самих устройств. Уже десятки лет инженеры сталкиваются с утечками памяти в протоколе SNMP. Можно позавидовать тому, как ловко этот протокол способен укладывать на лопатки control plane даже суперсовременных «железок».
У нас (в команде разработки NGFW) идут активные обсуждения, что нужна еще одна попытка избавиться от этого наследия в пользу более современных способов мониторинга. Если вам интересно, то напишите в комментариях, стоит ли нам выпустить статью о том, как мы при помощи телеметрии формируем графики для анализа поведения устройства во время нагрузочных тестов. Наберем сотню лайков Увидим отклик — обязательно поделимся.
О пользе телеметрии в сети можно найти несколько уникальных историй. Вот одна из них. Подобные статьи, кажется, должны влюбить в телеметрию инженеров, эксплуатирующих сетевое оборудование. Если NGFW способен предложить подобный способ мониторинга, поставьте ему жирный плюс в протоколе тестирования.
4. Нестабильная работа при большом количестве правил политики безопасности
У клиентов сложилось мнение, что на платформе x86 невозможно достичь стабильной и быстрой работы межсетевого экрана без использования специальных аппаратных акселераторов. Действительно, без акселераторов невозможно, но они необязательно должны быть аппаратными.
Если вы посмотрите, что архитектурно представляли из себя западные NGFW 5–10 лет назад и что они представляют сейчас, то заметите тенденцию отказа от специальных интегральных схем. Следует обратить внимание, что это прослеживается не во всех NGFW и не для всех его задач, но некая тенденция все же есть.
Positive Technologies уже более года доказывает (например, в рамках реалити-шоу «NGFW за стеклом»), что, используя программные акселераторы, можно добиться высоких скоростей на x86.
Но одно дело высокие скорости обработки трафика с одним разрешающим правилом, а другое — с нагрузкой под десятками тысяч правил политики безопасности. Последнее как раз обнажает слабые места тех межсетевых экранов, которые базируются только на x86 без применения каких-либо ускорителей.
Для тестирования под подобной нагрузкой собственного межсетевого экрана мы в Positive Technologies используем отдельные тесты. Как обычно, на межсетевой экран подается трафик eMIX. Параллельно с этой нагрузкой работает скрипт, который в заданный интервал времени подает все больше и больше правил: 1000, 5000, 10 000 и так далее. В ноябре 2023 года на Standoff 12 мы дошли до 80 000 правил. Останавливаться не собираемся. В декабре на внутренних тестах уже получили результат в 100 000 правил.
Безусловно, для таких тестов используется автоматизация (еще одно подтверждение необходимости API). Входные данные для правил можно изменить под задачи конкретного теста, а вот формирование самих правил мы стараемся поддерживать псевдослучайным. Вот пример результата работы скрипта для рандомизации источника и назначения для правил (формат YAML):
- action: drop
dst: 193.198.97.204/27
proto: tcp
src: 21.67.77.108/28
zone_in: 0
- action: accept
dst: 34.59.83.156/27
proto: tcp
src: 190.6.16.56/23
- action: drop
dst: 2.130.157.0/20
proto: udp
src_port: 26168
src_port_end: 57847
zone_in: 1Для генерации случайных блоков правил в Python существуют удобные модули. Можно написать свои для решения частных задач и использовать комбинации с готовыми модулями:
…
from misc import IPv4, IPv4Range, L4Port, L4PortRange
import random
…
def get_rand_ip():
a = IPv4Range('1.1.1.1 - 223.255.255.255')
ip = a.random(rmask_le=16)
return str(ip)
def get_rand_port():
ports = L4PortRange('1-65535')
rp = ports.random()
return int (rp)
def get_rand_port_range():
ports = L4PortRange('1-65535')
rp = ports.random_range(32000)
return rp.get_range()
…Совет: уточните у производителя NGFW, при каком количестве действующих правил фильтрации заявлена производительность в техническом описании межсетевого экрана. И обязательно проверьте заявленные характеристики на тестах перед принятием решения о покупке.
Еще одна важная деталь — архитектура программного обеспечения, которое управляет «железом». Стабильная работа под высокой нагрузкой — это не только способность перенаправить сетевой пакет в нужный интерфейс, но и гарантия полной обработки этого пакета всеми модулями безопасности, а также отправка сообщений об этом пакете от системы журналирования в систему мониторинга или SIEM. Кроме того, это возможность для администратора подключиться в любой момент к management plane межсетевого экрана (даже когда data plane полностью нагружен). В PT NGFW мы в первую очередь защищаем администратора от потери управления. Для этого было сделано то, что вы видите на скриншоте.
Это вывод htop с межсетевого экрана на 16 ядер.
Вот такой же вывод c маленькой коробочки на 2 ядра.
Оба скриншота похожи тем, что на них всегда одно ядро занято обработкой задач control plane и management plane. Разработчики PT NGFW заранее подумали об управляемости оборудования и реализовали такой подход, который не встретишь даже в некоторых западных решениях.
5. Довериться даташиту
Последний в топе, но не последний по важности. Если взять даташиты разных производителей, то, на первый взгляд, цифр для прямого сравнения решений между собой предостаточно. Но это так, только если рассматривать цифры с пяти метров — тогда точно не будут заметны все звездочки и надписи мелким шрифтом. К сожалению, при ближайшем рассмотрении ясность не появляется. В чем проблема? Чтобы разобраться, рассмотрим несколько примеров.
Пример № 1. Этот пример взят из многих технических требований, которые разбирает инженер при составлении спецификаций. «Пропускная способность межсетевого экрана» — параметр, который порождает неисчислимое количество вопросов. Приведу еще один вариант формулировки: «Пропускная способность межсетевого экрана в режиме L4-фильтрации». Уже лучше, но все еще остаются десятки вопросов. Перечисление всех не входит в задачи этой статьи, но предлагаем хотя бы несколько:
На каком профиле трафика дана указанная производительность? TCP? UDP? eMIX? В каком сценарии тестирования? На периметре сети? Внутри ЦОД? В ядре корпоративной сети? А может быть, вообще в сегменте АСУ ТП?
Профиль трафика, параметры тестирования, нагрузка и задачи, которые решает межсетевой экран, отличаются не только между организациями (не может же большая нефтяная компания быть похожа на сеть салонов красоты), но и даже внутри одной организации в зависимости от конкретного сегмента сети.
Давайте сравним два профиля трафика из двух разных организаций.
Вот первый (данные немного искажены из соображений конфиденциальности).
App | Bytes, % |
netbackup | 42 |
smb | 11 |
unknown-tcp | 9 |
sql | 7 |
ssl | 7 |
imap | 4 |
oracle | 4 |
web | 2 |
rtp-audio | 0,5 |
unknown-udp | 0,5 |
other | 13 |
А вот второй.
Как видите, статистика отличается значительно. Как этим организациям выбрать NGFW, опираясь на даташит?
Какие функции безопасности были активированы при тесте на максимальную пропускную способность?
Покупая NGFW, вы же наверняка захотите включить функции определения приложений, определения пользователя, IPS и многие другие? Какими будут результаты, когда вы добавите тот набор функций, который нужен именно вам?
А было ли включено журналирование срабатывания правил? Как и для какого количества правил оно было включено?
Это, вероятно, самый неприятный вопрос для производителей NGFW. Когда включается журналирование, нагрузка становится еще специфичнее. В зависимости от архитектуры системы журналов включается в работу не только вычислитель с оперативной памятью, но и дисковая подсистема межсетевого экрана. И тут неожиданно сетевому инженеру или специалисту по информационной безопасности приходится знакомиться с такими метриками, как IOPS, скорость чтения, скорость записи.
Совет: при следующем общении с поставщиком обязательно задайте эти вопросы и оцените, насколько уверенными были ответы на них.
Пример № 2. Совсем уж неочевидный параметр — «Количество соединений в секунду (CPS)». Характеристика очень важная для оценки производительности, но при этом не всегда встречающаяся как в даташитах производителей, так и в технических требованиях заказчиков. Задайте вопрос поставщику, какое количество соединений в секунду способен обеспечить межсетевой экран, который вы рассматриваете.
Расплывчатость ответа и количество уточнений могут вас сильно удивить, и вот почему.
Возьмем даташит Palo Alto и даташит Fortinet. Казалось бы, и там и там есть нужные цифры. Бинго? Нет. Palo Alto приводит свои цифры на трафике HTTP. Это правильно. Fortinet приводит свои цифры для «сырого» TCP. Эта задача намного проще, чем измерения на HTTP. Это неправильно. Для NGFW проще выдать хорошие цифры, заглядывая только в транспортный заголовок и не поднимаясь до уровня приложения. О том, какие функции безопасности были активированы при проведении теста, умалчивают оба. О размере пакета и транзакции в этих тестах оба производителя также умалчивают.
Выбирая подход к проведению тестов и открытости результатов, мы в Positive Technologies решили полностью опереться на RFC 9411. Позволим себе не переводить первоисточник, а вырвем цитату из контекста: «The RECOMMENDED response object sizes are 1, 2, 4, 16, and 64 KB». Появление такого документа, как RFC 9411, в теории должно нормализовать даташиты производителей. Что покажет практика, будет понятно со временем, но PT NGFW в первую очередь тестируется по методологии, описанной в этом стандарте. Что-то придумывается только тогда, когда общепринятой методики для оценки производительности отдельно взятой фичи еще не существует.
Целью этой статьи не был ликбез по выбору NGFW. Особенностей выбора настолько много, что уместить все в одну заметку невозможно. Наша задача как вендора, который ежедневно общается с клиентами и получает фидбэк на имеющиеся на рынке NGFW, — добавить немного скепсиса в процесс принятия финального решения. Один CISO мне как-то сказал: «Я отниму 30% от заявленных цифр в даташите, и это будет примерная производительность решения». А другой CISO похлопал его по плечу и предложил сразу делить пополам.
Мы за честный подход к NGFW, мы стараемся открыто рассказывать о ходе разработки в реалити-шоу «NGFW за стеклом», делимся не только результатами тестов производительности, но и сложностями, с которыми сталкиваемся в процессе.