Как я создал межсетевой экран с помощью свёрточных нейронных сетей для веб-приложений с микросервисной архитектурой

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


Вступление

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

  • Межсетевые экраны прошлого поколения:
    • Подход черного списка требовал ручного составления правил, которые в итоге обходились злоумышленниками. Происходило это из-за того, что для составления правил обнаружения атак использовалась регулярная грамматика (тип 3 по иерархии грамматик Хомского) [1].
    • Подход белого списка не может охватывать все вариации вводимых обычными пользователями данных.
  • Межсетевые экраны нового поколения на основе машинного обучения:
    • Нет необходимости создавать правила детектирования вручную.
    • Сочетание белых и черных списков одновременно.

Поэтому имеет смысл использовать машинное обучение, потому как таким образом возможно совершить переход от регулярных грамматик к контекстно-зависимым (тип 1 по иерархии грамматик Хомского), при этом избегая трудоёмкого процесса составления правил детектирования вручную [1].

Я решил рассмотреть случай (кейс), где взаимодействие с компонентами микросервиса происходит без использования API-шлюза. Этот случай описывается в свободно распространяемой книге от Майкрософт “.NET Microservices Architecture for Containerized .NET Applications” [2]. Такое прямое клиент-серверное взаимодействие годится для небольшого количества компонентов микросервиса. Моя задумка предполагает RESTful взаимодействие.

Способ внедрения межсетевого экрана

Далее я задумался над способом внедрения своего межсетевого экрана. Существует несколько способов:

  1. Облачные решения третьей стороны (Cloudflare, Imperva) могут оказаться ненадежными, так как эта третья сторона будет обладать TLS-сертификатом и секретным ключом. Таким образом, их межсетевой экран будет расшифровывать и зашифровывать трафик, что приводит к риску конфиденциальности и целостности данных, так как в компании может работать внутренний злоумышленник, сливающий данные.
  2. Аппаратный межсетевой экран требует наличие или аренды физического оборудования.
  3. Интеграция в ПО микросервисов.

Я остановился на последнем варианте. Для того чтобы внедрить межсетевой экран, я воспользовался декоратором, шаблоном проектирования, который добавляет дополнительную функциональность (в моем случае это проверка трафика), которая будет выполняться до оконечной функции микросервиса (рисунок 1).

Рисунок 1 - Отношение агрегации между шаблоном проектирования и оконечной функцией микросервиса.
Рисунок 2 - Схема взаимодействия.

Формирование датасетов

Далее я сформировал датасеты, ниже представлен список всех классов, которые может предсказывать модель.

  1. Классические SQL-инъекции (in-band): основанные на ошибке и с использованием union.
  2. Слепые SQL-инъекции (blind): основанные на времени и на основе логического вывода.
  3. Обфусцированные SQL-инъекции (blacklist).
  4. Межсайтовый скриптинг (XSS).
  5. Атака обхода каталога (directory traversal).
  6. Инъекция шаблона на стороне сервера (SSTI).
  7. Безопасный трафик (benign).

В таблице ниже представлено описание датасетов, при этом обучающий датасет был разделен в пропорции 80:20.

Размер выборок – это 64 элемента формального языка, близкого к естественному (NL). Здесь нужно уточнить, что, по сути, из выборки создаётся формальный язык, близкий к естественному, но при этом методы NLP всё еще применимы.

Реализация модели

Последовательная (tf.keras.Sequential) модель реализована при помощи Python 3, Tensorflow 2 и Keras API. Она представлена на рисунке 3. Обучению подлежат только слои, выделенные пунктирной линией.

Рисунок 3 - Стек слоёв модели

Ниже представлено краткое описание:

  1. Слой текстовой векторизации (TextVectorization) нормализует входные данные (декодирует полезную нагрузку, добивает нулями вектора до длины 250) и создает словарь выборки.
  2. Слой вложения слов (Embedding) создаёт плотные вектора и тензор становится трёхмерным.
  3. Слой свёртки (Conv1D) хоть и предназначается для классификации изображений, но я использовал его немного иначе: вместо 4 каналов RGBA, я использовал каналы, полученные от вложения слов, то есть 64 канала. По ним и проходит окно свёртки.
  4. Слой субдискретизации (GlobalMaxPooling1D) уменьшает размерность трехмерного тензора до двумерного, путем поиска максимального элемента во второй оси тензора (в Tensorflow эта ось именуется timesteps [3]).
  5. Полносвязный слой (Dense) умножает входную матрицу на матрицу размером 64x7.
  6. Слой активации производит окончательное предсказание одной из 7 меток класса.

Как говорилось в первом пункте, в данной реализации пришлось создать свой собственный словарь формального языка для создания контекстно-зависимой грамматики, так как готовые подходы, например, word2vec реализуют контекстно-свободную грамматику (контекстно-независимую), а BERT хоть и учитывает контекст, но тяжеловесна и нужна для обработки естественных языков. Более того, я специально вынес слой активации отдельно от полносвязного слоя (Dense). Это нужно по следующим причинам:

  1. График сигмоиды “прижимается” к асимптотам y=1 и y=0 для значений x>2 и x<-2, что позволяет делать четкие предсказания классов. Если бы она была в Dense слое, то нейрон смещения смещал бы функцию активации, а мы этого не хотим.
  2. Вынос функции активации решает и проблему исчезающего градиента: значения производной от сигмоиды находятся ближе к нулю. А по мере обратного распространения ошибки производные умножаются. Умножение малых чисел даёт ещё более малое значение, что останавливает обучение модели.

Оценка точности модели

Далее я оценивал точность разработанной модели. На рисунке 4 представлена матрица ошибок, полученная с помощью mlxtend:

  • По диагонали представлены TP значения.
  • В классе “Инъекция шаблона на стороне сервера” (SSTI) произошла FN ошибка, 10% элементов Инъекции на стороне сервера отнесено в Межсайтовый скриптинг.
  • Целочисленное значение в ячейке – это количество элементов рассматриваемого класса.
  • Сумма всех целочисленных значений ячеек равна 64.
Рисунок 4 - Матрица ошибок

При этом я использую в качестве метрик микро-усреднение и макро-усреднение (таблица представлена ниже).

При этом микро-усреднение описывается следующим образом:

  • Характеристики TP, FP, FN, TN усредняются по количеству классов, а затем они подставляются в итоговую двухклассовую метрику, например полнота или F-мера.

А макро-усреднение описывается вот так:

  • Суммируется метрика каждого класса, например полнота, а затем результат усредняется по количеству классов.

Таким образом, разница лишь в том, что в микро-усреднении класс с маленькой мощностью почти не влияет на результат, так как его вклад в средние характеристик TP, FP, FN, TN будет незначителен, а в макро-усреднении каждый класс вносит равный вклад в итоговую метрику, так как используются величины не чувствительные к соотношению размеров классов. Помимо того, что метрика имеет высокие показатели, можно сделать вывод, что используется хорошее перемешивание, так как микро и макро метрики почти сравнялись.

Апробация модели

А после этого я провел апробацию модели на примере микросервиса, написанного на Flask:

  1. Уязвимое к межсайтовому скриптингу приложение выложено на облачный веб-сервер Heroku.
  2. Фаззинг параметра comment методом POST не увенчался успехом, так как с помощью декоратора подключен мой МЭ.
  3. В итоге фаззер-грубой силы пришел к выводу, что параметр неуязвим (рисунок 5).
Рисунок 5 - Фаззинг грубой силы не увенчался успехом

При этом в логах отображается обнаружение атаки (рисунок 6).

Рисунок 6 - Логирование предотвращения атаки

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

Рисунок 7 – SQLmap посчитал, что параметр password неуязвим из-за подключенного межсетевого экрана

Вывод

Таким образом, мне удалось создать межсетевой экран с использованием свёрточных нейронных сетей для защиты от инъекционных атак, а также доказать применимость NLP методов для формального языка выборки. Более того, использование машинного обучения нивелирует трудоёмкий процесс составления правил детектирования инъекционных атак. В дальнейшем можно добавить защиту от L7 DDoS, добавить поддержку GraphQL и размещать модель машинного обучения в API-шлюзе.

Список использованных источников

  1. Карпов Ю. Г. Основы построения компиляторов //Учебное пособие. Л.: Изд-во ЛПИ. – 1982. – 28 с.
  2. de la Torre C., Wagner B., Rousos M. .NET microservices: Architecture for containerized .NET applications //Microsoft Developer Division. – 2020. – 40 c.
  3. Введение в тензоры // [Руководство Tensorflow, 2020]. – URL: https://www.tensorflow.org/guide/tensor.

Источник: m.vk.com

Комментарии: