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

1. Закладки могут внедриться на уровне аппаратного обеспечения и прошивки.

2. ПО может быть компрометировано, например, через Open Source уязвимости.

3. Особо коварные алгоритмические закладки могут навредить сложным алгоритмам (например, шифрования).

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

5. Преступники не поскупятся и реализуют высокозатратные атаки, ведь и экономическая эффективность (или ущерб) атак на объекты КИИ будут велики.

6. Злоумышленник достаточно точно предскажет архитектуру и реализацию нашего типового продукта.

7. Киберпреступник возьмёт измором: постоянно будет проверять и подбирать методы проникновения, ведь решение в неизменном сетевом доступе.

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

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

Архитектура

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

В первом эшелоне может также выполняться дополнительная предобработка трафика. Например, при использовании ПЛИС (программируемой логической интегральной схемы, FPGA, о которой в конце этой статьи мы поговорим подробнее) хорошим решением будет на уровне первого эшелона детектировать и блокировать нежелательный трафик со стороны ПО, в том числе стороннего. Ведь аппаратная база (особенно отечественная) — звено, к которому нарушителю труднее всего получить доступ. Мы знаем состав трафика, поступающего на сетевые интерфейсы, и все изменения, которые вносит в него подсистема обработки, а если вместо маршрутизатора реализовать NGFW по схеме прозрачного L2-моста, поймать паразитный трафик будет совсем нетрудно. Теперь, хоть закладки и не исключены, воспользоваться ими злоумышленник не сможет.

А еще к исполнению на ПЛИС легко адаптировать такие задачи как сигнатурный анализ (поиск), удаление заголовков «магистральных» протоколов и дубликатов пакетов, передаваемых на обработку на второй уровень. Их мы тоже перенесем на первый уровень, чтобы снизить риски использования Open Source и зарубежных платформ.

Функциональные возможности

Итак, на уровне 1 производится предварительная обработка трафика, а на уровне 2 (и выше) — основная. Теперь посмотрим на функциональные модули более детально.

Подсистема контроля (security subsystem)

Эта подсистема на уровне 1 выявляет паразитный трафик, источник которого — ПО на уровне 2. В зону её внимания попадает любой исходящий с рабочих интерфейсов поток данных, ненужный для штатной работы комплекса.

На уровне 1 работа модуля подсистемы (SS‑agent) зависит от модулей анализа и обработки трафика (TLS proxy, DPI, MTP). Они в процессе проксирования и очистки трафика могут вносить штатные модификации — новые сессии, изменения реквизитов трафика, например, контрольных сумм сетевых пакетов. Такие штатные изменения регистрируются, а все остальные будут отнесены к нежелательным и заблокированы.

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

Подсистема глубокого анализа трафика

TLS/SSL

Задача прокси-сервера TLS/SSL («terminator proxy») —расшифровывать и анализировать проксируемый трафик. Сертификат устанавливается на рабочих станциях защищаемой сети. В других продуктах часто используются открытые программные реализации в их базовой функциональности, которая не предполагает обработки трафика второго уровня — QUIC, HTTP-2(3). Чтобы не снижать эффективность контроля, полноценная реализация NGFW должна не только включать в себя обработку этих видов трафика, но и архитектурно быть рассчитанной на расширение этого списка.

Опционально в подсистему анализа трафика можно включить возможности предотвращения работы на отозванных и самоподписанных сертификатах, ненадежных наборах шифров (cipher suite), а также детектирование распространённых видов атак на SSL/TLS.

MITM-прокси для SSL / TLS

Стоит упоминания типовое решение задачи, которая часто возникает при реализации таких продуктов как сетевой экран, DPI или IPS/IDS — анализ зашифрованного трафика SSL/TLS из контролируемой сети заказчика. Это промежуточный прокси-сервера по схеме «внедрённый посредник» (MITM). Расшифровка и проверка трафика происходят на рабочих станциях подконтрольной сети на основе предустановленных сертификатов шифрования. В этой схеме используют только Open Source.

На GitHub наше внимание привлекли два решения такого типа, SSLsplit и построенный на его базе SSLproxy. Интеграция второго продукта проще за счет поддержки TLS 1 и записи реквизитов маршрутизации в первый пакет с данными, что дает возможность ответвления расшифрованного трафика.

DPI (глубокая инспекция пакетов)

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

Речь не только о большем количестве протоколов. Нужно детектировать абсолютно весь «аномальный» трафик: если не удалось выполнить классификацию, если трафик корректно классифицирован на основании статических критериев, но обладает при этом существенными отличиями.

Такие аномалии нужно выделять и классифицировать на опасные и допустимые — удобно применить здесь методы машинного обучения. Вспомним классику — атаку «Christmas tree». Обнаружить ее можно было бы без предварительных настроек подсистемы анализа по единственному критерию: ранее никогда не встречалось таких пакетов с таким набором параметров.

Антивирусная защита

Можно использовать сторонний продукт без изменений, но дополнить возможности обработки трафика. Если предварительную обработку мы выполняем на уровне 1 с применением ПЛИС, то и сигнатурный поиск можно перенести туда же. Нагрузка на ЦП будет меньше, а скорость анализа больше.

На уровне 2 антивирусная защита представлена модулем отведения трафика, где необходим дополнительный сигнатурный анализ, на уровень 1. Сигнатурный анализатор целесообразно выделить в особую подсистему на уровне 1 в реализации на ПЛИС.

Очистка трафика

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

Подсистема предварительной обработки трафика

На уровне 1 мы реализуем

• конвертацию магистральных протоколов передачи данных в трафик IPv4/IPv6, чтобы было проще в дальнейшем обрабатывать;

• проверку контрольных сумм заголовков протоколов, контроль целостности пакетов и блокировки тех, которые могут вызвать программные ошибки на низком сетевом уровне обработки данных;

• дефрагментацию трафика определённых протоколов и передачу на уровень 2 в составе агрегированных пакетов, чтобы сократить ресурсоёмкость;

• предварительную фильтрацию трафика для приоритетной обработки;

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

Как уже упоминалось, этот уровень выполняется на специальном аппаратном обеспечении на базе ПЛИС (FPGA), чтобы снять часть рутинных задач с ЦП. Поговорим о нем поподробнее.

Специальное аппаратное обеспечение

Специальные аппаратные решения (сетевые карты) позволяют эффективно обрабатывать трафик на уровне FPGA. Предустановленные прошивки можно дополнить сторонними прошивками. Это позволит перенести на ПЛИС рутинные процессы, к примеру, сигнатурный поиск, если предварительно загрузить базу искомых сигнатур.

Помимо ресурсов, которые передаются по магистральной сети, нужно проверять те, которые выделяются из терминированных сессий TLS на уровне 2. Как обеспечить доступ к ним на уровне 1? Можно было бы загрузить их на уровень 2 и задерживать трафик до получения результата проверки на уровне 1, но есть способ гораздо лучше. Будем передавать не сами ресурсы, а сеансовые ключи и реквизиты соответствующих сессий, полученные на этапе установки защищённого соединения TLS. Это будет корректнее: в версии HTTP/2 ресурсы могут передаваться без предварительных запросов, поэтому на момент запроса могут быть неизвестны типы передаваемых данных.

Вот как это выглядит на схеме.

Выводы

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

Итак, целесообразно включить в список функциональных возможностей NGFW:

• расширенную подсистему контроля целостности ПО, реализованную на аппаратном уровне;

• расширенную подсистему глубокого анализа трафика и его последующей очистки (в противовес блокировке);

• обработку данных на уровне медиапотоков.