Межсетевые экраны в 2024 году

Саммари

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

Введение

Эта статья является моими размышлениями на тему современных межсетевых экранов (далее, МЭ), какой функционал важен и нужен, как его можно проверить и на что можно обратить внимание. Всё что написано ниже, является моим частным мнением и не нацелено на продвижение какого-либо решения.

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

Архитектура

Условно можно разделить все МЭ на два больших вида:

• Программные МЭ

• Аппаратные МЭ

Конечно, и те и те по сути являются одним и тем же программным кодом, работающим на определённой ОС, только в первом случае ОС будет общедоступной, а во втором специализированной и с ограниченным доступом.

Даёт ли какая-то из этих философий определённые преимущества или недостатки зависит напрямую от производителя и его умения.

Программные МЭ без сомнения обладают большей гибкостью и вариативностью использования. Самым главным тут я бы выделил возможность использовать в Cloud.

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

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

Аппаратная начинка

Очень часто вывод о действительной, максимальной, производительности МЭ можно сделать, просто посмотрев на то, какая аппаратная начинка внутри платформы.

Процессор

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

Количество ядер даёт нам потенциальное количество параллельных потоков, которые мы обработаем в единицу времени.

В случае программных МЭ информация о процессоре нам всегда известна, а вот в случае аппаратных МЭ многие производители скрывают эти данные, но при определённом навыке это не является вопросом.

Сетевая карта

Зная спецификацию сетевой карты, мы можем получить максимальный объём трафика, которым мы можем оперировать для данной платформы. Некоторые производители пытаются выдавать эту характеристику за реальную производительность МЭ.

Оперативная память

Оперативная память влияет на МЭ скорее косвенно, поскольку её скорость и объём редко становятся тем самым узким местом, из-за которого может начать проседать производительность. В моей практике требования к большему объёму оперативной памяти для МЭ появлялись при переходе от старой версии ядра ОС к новой.

Жесткие диски

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

Видео карта или ускоритель

Элемент, который как я описывал выше, может радикально поднять скорость нашего МЭ:

• Да, мы получаем ускорение операций определенного вида

• Да, у нас есть большая зависимость и потенциальная проблемность в части драйверов

• Да, это сильно удорожает платформу

Самое важное это найти ограничения для данного элемента платформы и чётко отдавать себе отчёт, где мы получим от него выгоду, а где вся обработка будет происходить по обычному пути.

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

Внешняя обвязка и дополнительные компоненты

Суть этого пункта заключается в том, что некоторые производители предлагают свои решения в виде больших шасси, содержащих несколько одинаковых аппаратных МЭ. До недавнего времени их можно было рассматривать просто как класс high-load. С появлением же возможности собирать в подобную конфигурацию самые обычные платформы МЭ при помощи специализированного аппаратного балансировщика мы вышли из ограничений high-load шасси, что даёт нам очень большую гибкость. Я не включаю сюда решения, которые можно балансировать при помощи обычного балансировщика, поскольку high-load шасси и специализированные балансировщики от производителя МЭ предоставляют не просто распределение трафика между платформами, а вполне определённый перечень функций и технических решений, которые возникают при реализации подобной архитектуры. Что это за решения я не буду описывать, с ними можно ознакомиться при внимательном изучении рекомендаций и ограничений от любого из производителей МЭ предлагающего high-load платформы.

Производительность

Максимальная, базовая производительность

Для оценки производительности часто ориентируются на rfc3511 и rfc2544, я вижу тут примерно следующие параметры:

Максимальная производительность для указанной платформы, может быть измерена для условий:

• Одно правило Any-Any-Accept-Log. Простое изменение вместо Log на None может нам позволить снизить влияние задержек связанных с жёстким диском. При проверках желательно чтобы было значение именно Log, поскольку в при работе будет установлено именно это значение. Никакие дополнительные проверки связанные с deep packet inspection не должны включаться.

• Траффик TCP с максимальным размером пакета

• Траффик TCP с минимальным размером пакета

• Траффик UPD с максимальным размером пакета

• Траффик UDP с минимальным размером пакета

• Траффик MIX со случайным размером пакета

• Максимальное число вновь устанавливаемых соединений

• Максимальное число установленных соединений

Разумеется, в каждом тесте надо смотреть дополнительные метрики такие как latency, frame loss и пр.

Важные нюансы:

• При проверке у нас должен быть двунаправленный трафик, т.е. на одной стороне у нас должен быть сервер, а на другой клиент и обмен должен происходить между ними.

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

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

Суть в том, что может быть ситуация, что скорость от платформы к платформе у производителя будет прирастать как % роста частоты процессора, но, например, никак не будет коррелировать с количеством ядер на данном процессоре, что нам скажет о том, что производитель работает в один поток и балансировать свою обработку не умеет. Искажение нам может добавить аппаратный ускоритель или дополнительные компоненты в виде внешней обвязки.

Максимальная, функциональная производительность

Для оценки производительности того или иного функционала наиболее универсальным критерием будет взять тесты, которые предоставляют системы нагрузочного тестирования, например та же IXIA или Spirent, но если нет возможности их использовать, то можно собрать собственный тестовый полигон на базе open source. Важный момент, что в случае IXIA и Spirent набор тестов описан и общедоступен, а собственная лаборатория потребует, как минимум публикации методики, чтобы её мог повторить кто-то другой.

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

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

Надёжность

Наработка на отказ

Любой производитель железа предоставляет такой параметр как Mean time between failure (MTBF), его можно найти в спецификации на аппаратную платформу и зафиксировать как максимальную величину времени, до которой оборудование в надлежащих условиях должно проработать. Любое отклонение от рабочих режимов будет сокращать время для данного параметра и повышать риск отказа. Разумеется, для оборудования прошедшего все процедуры заводских испытаний эта величина будет существенно отличаться от того, что указано для оборудования, собирающегося без соблюдения данных требований.

Работа в отказоустойчивом кластере

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

Active – Standby

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

• Что именно синхронизируют между собой узлы кластера

• Как происходит переключение между узлами кластера

Кластер распределения нагрузки

Несколько узлов кластера объединяются в группу, один из них выбирается лидером, принимает все соединения и распределяет их между остальными участниками кластера. В данном случае важно помнить, что производительность двух узлов в данном кластере не равна сложению производительности каждого из узлов ввиду того, что все сессии приходят на лидера и только потом перераспределяются внутри. С учётом необходимости синхронизации мы получим график, когда добавление каждого нового участника в данный кластер будет давать всё меньший рост производительности. Начиная с 5-го узла добавление узлов тут теряет смысл, поскольку трафик синхронизации будет снижать общую производительность кластера.

Active – Active

Все узлы кластера обрабатывают трафик. Надо опять помнить о нюансах:

• Узлы кластера должны обмениваться между собой данными о сессиях и состояниях, а значит тут также есть проблема с трафиком синхронизации и количеством узлов в кластере

• Трафик одной сессии должен проходить через один и тот же узел кластера для реализации контроля состояния сессий.

Кластер high-load

Тут мы сильно расширяем производительность и надёжность кластера за счёт вынесения задачи по распределению сессий на внешний балансировщик. Тем самым количество узлов в кластере будет ограничиваться возможностями нашего балансировщика и внутренней шины платформы. При этом нужно учитывать, что мы получаем полноценный Active-Active кластер в контуре одной площадки, но если площадки 2 и они сильно удалены, то вопрос с синхронизацией сессий и асимметричным трафиком для нас будет по прежнему актуальным.

Функциональность

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

Поддержка работы с одним интерфейсом

Не очевидный функционал, который можно считать обязательным требованием если мы говорим о Cloud. Возможность МЭ работать лишь с одним интерфейсом для приёма и передачи трафика, в том числе и для работы с VPN.

IPS

Для оценки работы IPS можно пользоваться тем, что осталось от методик NSS Labs, тем что есть в предустановленных конфигурациях производителей IXIA или Spirent, или взять что-то из свободно распространяемого – тот же pytbull-ng. В любом случае, ответ на вопрос что именно IPS этого производителя в его МЭ лучше или хуже чем у конкурента мы получаем с некоей долей субъективности. Каждый производитель настраивает IPS согласно своему мировоззрению и как оно будет работать в реальности и конкретной сети отдельно взятого клиента, сколько будет ложных сработок или вообще не будет сработок остаётся за скобками и зачастую сложно измеримо в силу зависимости от проведённых настроек, способов обработки реализованных производителем, типов приложений у клиента и степенью балагана в сетевом трафике и инфраструктуре.

VPN

Функциональный элемент, который определяет, можно ли полноценно использовать МЭ на периметре. Помимо просто поддержки работы с VPN я бы дополнительно выделил ещё следующие параметры:

Поддержка стандарта IPSec, что означает возможность построения Site-to-Site VPN с любым другим решением, поддерживающим IPSec, например можно взять за ориентир Cisco.

Совместимость по стандарту ГОСТ, до недавнего времени каждый производитель реализовывал свой ГОСТ, это приводило к тому, что VPN можно было построить только между решениями этого производителя.

Параметры шифрования:

• Поддержка широкого перечня алгоритмов шифрования, AES, DES, (ГОСТ в случае производителей РФ), null и пр.

• Шифрование на основе pre-shared key

• Шифрование на основе внешнего CA

• Шифрование на основе внутреннего CA

Параметры VPN:

• Site-to-Site

• Client-to-Site

• Clientless — SSL VPN

• Route-based VPN

• NAT-T

• Overlapping networks

• Zone based/Domain based VPN

• Выбор main IP/interface

• Поддержка 2-х и более интерфейсов для работы VPN

• Поддержка dynamic IP

• Поддержка L2TP, PPTP

Основное что чаще всего является критерием оценки в реальных условиях, это:

• Производительность для выбранного режима VPN

• Возможность работы с клиентами и партнёрами (количество вариаций и функций поддерживаемых VPN)

• Количество удалённых клиентов, которые могут подключиться к нашему шлюзу через VPN

Routing

Как минимум нужно чтобы поддерживались такие функции как:

• OSPF/BGP/RIP/static routing

• Policy-based routing/Source-based routing

• PPPoE

• PIM/IGMP

Switching

Должно быть наличие:

• L2/L3/Bridge mode

• 802.1q

• 802.3ad

• Monitor mode

• Изменение vlan (re-tagging vlan)

IPv6

По-прежнему преобладает IPv4, но поддержка IPv6 для современного МЭ обязательна. Эта функция чаще всего актуальна для применения в ЦОД или Cloud.

Идентификация

Разграничение доступа на уровне приложений

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

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

Разграничение доступа на уровне пользователей

Межсетевой экран должен уметь интегрироваться с каталогами пользователей такими как LDAP или Radius/Tacacs чтобы видеть какой именно пользователь инициировал соединение. Это позволяет создавать политики на основе принадлежности к группам что является одним из признаков современного МЭ.

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

Разграничение доступа на основе типа устройств

Относительно новый функционал, появившийся с развитием темы IoT. МЭ должен уметь распознавать тип устройства и в зависимости от этого мы можем создавать гранулярный доступ.

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

Раскрытие SSL/TLS

МЭ должен обладать функционалом позволяющим раскрывать SSL/TLS сессии реализуя man-in-the-middle. Тем самым https трафик становится виден, и мы имеем возможность его контролировать и разграничивать.

Функционал должен реализовываться как для входящих, так и для исходящих соединений.

Фильтрация URL

Тут важно количество категорий и их гранулярность. Чаще всего пользователи применяют разделение доступа на основе принадлежности к той или иной группе с добавлением блокировки отдельных разделов.

Поддержка NAT

Базовая функция, которая является обязательной для всех МЭ, при этом можно обратить внимание на ряд возможностей:

• Hide NAT

• Static NAT

• PAT

• Address range NAT

Поддержка управления через API

Современный МЭ без этого функционала невозможно представить. Через API мы должны иметь возможность управлять если не всеми, то максимальным числом функций нашего МЭ.

Особенно актуально данное требование если мы говорим об использовании в Cloud, больших high-load системах или распределённых сетях, где количество устройств 100+.

Интеграция с Sandbox

Важный функционал с учётом необходимости проверки трафика на zero-day. Некоторые решения обладают встроенным функционалом, но он чаще всего довольно ограничен и не может сравниваться с функционалом, который предоставляет платформа, заточенная под данную задачу. Наиболее распространённым является возможность:

• Интеграция с выделенной платформой sandbox

• Интеграция с облачным сервисом sandbox

Встроенный Anti-Virus

Удобный функционал обеспечивающий дополнительный уровень контроля и проверки. Anti-Virus сильно влияет на производительность, и не все пользователи и производители его используют и включают в свои решения, но его наличие существенно повышает защищённость сетей и пользователей.

Обнаружение Bot и C&C

Полезный функционал, который в зависимости от решения может быть представлен несколькими или одной функцией:

• Проверка трафика на наличие признаков bot программ

• Проверка DNS трафика на наличие C&C запросов

• Проверка DNS трафика на наличие dns tunnel

Проверка рабочих станций или удалённых клиентов

У многих компаний в политике безопасности есть требования выполнить проверку подключающейся в сеть рабочей станции, для этого необходим следующий функционал:

• Проверка клиентской рабочей станции перед установлением VPN

• Проверка клиентской рабочей станции перед допуском в какой-либо сегмент

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

Разделение прав по администрированию

Чем более гранулярные правила и параметры можно задавать для управления, тем как правило лучше, в общем виде как минимум нужны:

• Основной администратор с полными правами

• Пользователь с правами на чтение

• Пользователь с правами на изменение политик

Мониторинг состояния

Чем больше возможностей для мониторинга есть, тем лучше будет понимание о том насколько наш МЭ загружен и в чём именно у нас возникла проблема при отказе. Мониторинг должен быть:

• Встроенным

• Поддерживать возможность интеграции с внешними системами через snmp/API/netflow

• Поддерживать обнаружение отказов отдельных элементов платформы

• Поддерживать обнаружение отказов внешних узлов (например, ping доступности внешнего шлюза)

Логирование

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

• Различные уровни логирования на уровне МЭ

• Возможность записи трафика на уровне интерфейса сетевой карты (до старта обработки МЭ)

• Возможность получить debug работы отдельного функционала МЭ

• Возможность экспорта данных во внешнюю систему

• Возможность фильтрации данных, на уровне полей лог файла

• Ведение hitcount для сработавших правил

Поддержка виртуальных контекстов

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

В данном случае необходимо обращать внимание на следующее:

• Сколько виртуальных контекстов входит в базовую конфигурацию и сколько их необходимо

• Какой функционал и какие ограничения есть для виртуальных систем

• Можем ли мы выделить ресурсы платформы на виртуальные системы

Управление

Выделенный управляющий трафик для МЭ

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

Вынесенное управление МЭ

Применительно к управлению МЭ выделяют:

• Управление с отдельной платформы

• Резервирование управления (active-standby)

• Иерархическое управление, когда мы создаём глобальный узел управления на уровне организации и подчинённые на уровне филиалов

• Выделенный лог сервер

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

Compliance

Не обязательный, но часто желательный функционал, который упрощает жизнь для компаний, в которых применяется регулярная сверка с каким-либо стандартом. Тут можно выделить:

• Количество поддерживаемых стандартов

• Возможность создания собственного стандарта

• Автоматизированная проверка настроек МЭ на выполнение требований

Работа с объектами и политиками

МЭ должен подразумевать простоту элементов управления и настройки для персонала, который с ним работает каждый день. Управление и обслуживание МЭ должны быть удобны в работе для выполнения:

• Повседневных задач

• Задач, связанных со сложной архитектурой и необходимостью изменений

• Задач, связанных выявлением неисправностей

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

Непрерывность бизнеса

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

• Совместимы ли версии ПО производителя между собой

• Поддерживает ли производитель миграцию всех настроек с версии на версию

• Поддерживает ли производитель миграцию всех настроек с платформы на платформу

• Если ли возможность проводить автоматический upgrade:

  • В автоматическом режиме

  • Без downtime

  • Без разрыва соединений

• Предусмотрен ли промежуточный режим работы кластера для разных версий на МЭ

• Предусмотрен ли режим работы распределенной системы, когда часть МЭ работают на старой версии ПО, а часть на новой

Поддержка Cloud

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

• Поддержка NSX/NSX-T, ACI, Azure, OpenStack, KVM

• Наличие динамически определяемых объектов Cloud в политике и правилах МЭ

• Поддержка автоматического определения конфигураций и загрузки политик для динамически масштабируемого МЭ

Наличие Copilot

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

Зрелость производителя

Косвенный параметр, но его необходимо учитывать поскольку МЭ — это тот элемент инфраструктуры, на который все и всегда смотрят в первую очередь, в случае каких-либо проблем. На что можно обратить внимание:

• Подробная документация на решение и её объём

• Наличие базы знаний и её объем

• Наличие партнерской сети и её размер

• Наличие требований к квалификации, специализации и регулярная аттестация партнёров

• Количество видов платформ у производителя

• Количество выпущенных версий МЭ

• Частота выхода обновлений для версий ПО

• Частота выхода версий ПО

• Скорость исправлений при обнаружении проблем в ПО (например, как быстро была закрыта уязвимость Log4j)

Вместо заключения

Современный межсетевой экран — это далеко не Stateful Firewall и не NGFW. Он должен содержать широкий перечень функциональных возможностей, отвечающих высоким требованиям со стороны клиентов. Современные тенденции в части Cloud, High-load и ML напрямую затрагивают этот сегмент решений требуя ответа на возникающие потребности.

Какого-то вывода я делать не буду, каждый кто прочёл всё что написано выше может самостоятельно сделать свои собственные выводы.

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