Автоматическое построение профилей нормального поведения веб-приложений

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИМ. М.В. ЛОМОНОСОВА ФАКУЛЬТЕТ ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И КИБЕРНЕТИКИ КАФЕДРА АВТОМАТИЗАЦИИ СИСТЕМ ВЫЧИСЛИТЕЛЬНЫХ КОМПЛЕКСОВ Дипломная работа

Автоматическое построение профилей нормального поведения веб-приложений Студента группы 522 факультета ВМиК Гамбарова Эльдара Рафаиловича Научные руководители:

д. ф. — м. н. профессор Смелянский Р. Л., Петухов А.А.

МОСКВА, 2007

Аннотация

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

• 1. Введение
• 2. Постановка задачи
• 3. Определения и основные понятия
• 4 Метод обнаружения уязвимостей веб-приложений
• 4.1 Применение метода
• 4.2 Описание метода
• 4.3 Использование значений операций для более точного обнаружения отклонений в поведении
• 4.4 Отклонения в поведении с точки зрения метода
• 4.5 Сравнение наборов HTTP-параметров
• 5. Выбор методов обнаружения аномалий
• 5.1 Метод Хотеллинга (тест Хотеллинга)
• 5.2 Метод EWMA (Exponentially Weighted Moving Average)
• 5.3 Метод цепей Маркова
• 5.4 Нейросетевой метод
• 5.5 Сравнительный анализ методов обнаружения аномалий и обоснование выбора метода
• 6. Модуль обнаружения уязвимостей
• 6.1 Требования к модулю
• 6.2 Структура профиля нормального поведения
• 6.2.1 Секция мета-информации
• 6.2.2 Секция HTTP-параметров
• 6.2.3 Секция информации об операциях над объектами окружения
• 6.2.4 Пример записи профиля нормального поведения
• 6.3 Программная архитектура модуля
• 6.4 Описание подсистем модуля
• 6.4.1 Консоль управления
• 6.4.2 Подсистема предварительной обработки трассы
• 6.4.3 Подсистема построения профиля нормального поведения
• 6.4.4 Подсистема обнаружения аномалий
• 7. Результаты
• 8. Заключение
• 9. Литература

1. Введение

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

Проблема безопасности данных в информационной системе возникла с появлением самих систем. По мере внедрения компьютерных систем управления в важных для общества областях деятельности проблема приобретает всё большую значимость. Рост доступности пользовательских сервисов информационных систем через Интернет и локальные сети порождает новые проблемы, связанные с обеспечением безопасности (т.е., доступности, целостности и конфиденциальности [15]) данных от вторжений извне.

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

Предоставление удалённого доступа к информации, заказу и оплате услуг и ряду других сервисов в подавляющем большинстве случаев происходит через веб-приложения. Под веб-приложением понимается приложение, работающее в составе веб-сервера. Веб-приложение взаимодействует с пользователями через веб-интерфейс, представляющий собой совокупность интерактивных веб-страниц, доступ к которым осуществляется через веб-браузер пользователя. Доля уязвимостей веб-приложений в общем количестве фиксируемых уязвимостей значительна (около 69% в период с января по июнь 2006;го года) [16], а большое количество доступных удалённо веб-серверов и работающих на них веб-приложений создаёт благодатную почву для злоумышленников [1, 2, 3].

Программное обеспечение, использующееся в инфраструктуре веб-приложения (веб-сервер, СУБД и т. п.), обычно создаётся компетентными в вопросах безопасности специалистами и является хорошо защищённым. Но веб-приложения в ряде случаев разрабатывается специалистами, не владеющими аналогичными навыками или плохо понимающими значимость защищённости системы. Результатом разработки становится слабо защищённое веб-приложение, доступное каждому пользователю сети Интернет. Уязвимость в таком приложении может привести к краже или порче данных, содержащихся в других объектах инфраструктуры, например, базе данных. И противостоять этому не может даже то, что сама СУБД спроектирована правильно и устойчива к действиям злоумышленников.

Под поведением далее будет пониматься взаимодействие веб-приложения с объектами окружения (ресурсы операционной системы, СУБД, почтовые сервисы) в ответ на HTTP-запросы от клиента.

Слабая защищённость и широкая распространённость веб-приложений делает их привлекательными целями для взломщиков. Существующие системы обеспечения безопасности часто неэффективны при защите приложений данного класса. Можно перечислить следующие основные виды систем, используемых для обеспечения безопасности веб-приложения [3, 12, 14, 17]:

Модули обеспечения безопасности, встроенные в приложение

" Стратегия песочницы" (sandboxing)

Системы обнаружения уязвимостей

Межсетевые экраны уровня приложения

Системы предотвращения атак

Системы обнаружения атак

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

Суть «стратегии песочницы» (sandboxing) заключается в создании контролируемой среды исполнения веб-приложения, изолированной от системы, в котором она работает. Это позволяет минимизировать потери в случае, если уязвимость приложения будет использована злоумышленником, но не позволяет обнаружить и локализовать сами уязвимости.

Системы обнаружения уязвимостей анализируют веб-приложения, используя метод белого или чёрного ящика [12, 13, 14, 19]. Система, использующая метод белого ящика, анализирует исходные коды и/или файлы конфигурации веб-приложения. Система выявляет участки кода, потенциально содержащие уязвимость или небезопасные параметры конфигурации. Система, использующая метод чёрного ящика, осуществляет поиск уязвимостей «извне», посылая приложению HTTP-запросы и анализируя ответы. При этом встают задачи выявления структуры веб-приложения, определения типа сервера и построения тестового набора HTTP-запросов и последующего анализа HTTP-ответов. Однако анализа исходного кода приложения может быть недостаточно для выявления всех уязвимостей, так как код может не содержать уязвимых с точки зрения языка конструкций и при этом быть уязвимым в целом из-за ошибок при проектировании. Кроме того, для той технологии, при помощи которой создано данное веб-приложение, может не оказаться систем поиска уязвимостей, использующих метод белого ящика. Анализ безопасности методом чёрного ящика также не может выявить все возможные уязвимости, так как нет гарантии, что множество тестовых запросов содержит все необходимые для этого варианты.

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

Системы предотвращения атак не распространены широко. Для их корректной настройки и работы требуется глубокое понимание особенностей функционирования как веб-приложения, так и самой системы предотвращения атак. Неверное конфигурирование может привести к большому количеству ложных срабатываний системы и, как следствие, недоступности сервиса для пользователей, что крайне нежелательно для многих сервисов [3, 19].

Системы обнаружения атак (СОА) используют методы, которые принято относить к двум основным категориям: методы обнаружения злоупотреблений (сигнатурные методы) и методы обнаружения аномалий.

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

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

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

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

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

Другим подходом является выявление аномалий в обращениях веб-приложений к объектам окружения (операционная система, СУБД и т. п.). Например, для веб-приложения строятся профили, содержащие типичную синтаксическую структуру запросов к БД, и последующие запросы проверяются на соответствие профилям. Решения такого рода хороши тем, что в определённом смысле они анализируют поведение самого приложения. Но такие методы фокусируются на взаимодействии приложения с конкретными видами объектов окружения (например, СУБД) и не учитывают взаимодействие с другими объектами, а уязвимость в веб-приложении, обычно обращающемуся к одному ресурсу, может привести к несанкционированному доступу именно к другим ресурсам. Например, если некоторый модуль веб-приложения в процессе работы производит только системные вызовы операционной системы для работы с файлами, но при этом содержит уязвимость, позволяющую злоумышленнику запускать произвольный код, то результатом может стать модификация таблицы базы данных, содержащей пароли пользователей, с целью получения доступа — то есть обращение к другому ресурсу и порча информации. Комплексное решение, анализирующее обращения веб-приложения к разным объектам окружения является достаточно сложной технической задачей, так как встаёт вопрос о получении необходимой для анализа информации об обращениях, что, например, может потребовать модификацию программных компонент объектов.

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

Метод был реализован в виде модуля к СОА «Мониторинг-РВС». Как было отмечено, анализ обращений к различным объектам окружения является сложной технической задачей, а для успешной реализации СОА должна предоставлять необходимый инструментарий. Развитая инфраструктура СОА «Мониторинг-РВС» позволяет решать поставленную задачу.

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

Для этого необходимо рассмотреть существующие методы автоматического построения профилей нормального поведения, определить критерии сравнения методов и выбрать оптимальный для дальнейшей реализации. Модуль осуществляет обнаружение уязвимостей путём выявления обращений к тем ресурсам, которые не указаны в профиле нормального поведения, в ответ на HTTP-запросы. Однако аномалии в поведении могут быть связаны и с характером обращения к разрешённому профилем ресурсу, например, уязвимость может позволить злоумышленнику выбрать не одну строку из БД, а все. В основе метода автоматического построения профиля нормального поведения лежит некоторая математическая модель, и именно она определяет набор хранимых в профиле данных и анализ на предмет отклонения текущего поведения от описанного в профиле. Таким образом, выбирается оптимальный для данной задачи математический аппарат обнаружения аномалий и формат профилей изменяется таким образом, чтобы он позволял хранить данные, необходимые для анализа. Далее в модуль добавляется функция «обучения», которая позволит автоматически строить профиль нормального поведения и заносить в него данные по окончанию учебного периода.

Результатом работы является модуль обнаружения уязвимостей веб-приложений для СОА «Мониторинг-РВС» на основе контроля поведения с возможностью ручного и автоматического определения профиля нормального поведения.

приложение профиль нормальное поведение

2. Постановка задачи

Провести обзор методов автоматического построения профиля нормального поведения веб-приложения.

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

Реализовать выбранный метод в рамках разрабатываемого модуля.

Провести испытания на действующих веб-приложениях.

3. Определения и основные понятия

В данном разделе определяются основные понятия и термины, используемые в данной работе.

Ключевыми понятиями являются веб-приложение и поведение веб-приложения.

Под веб-приложением понимается приложение, с которым пользователь взаимодействует при помощи браузера. Само приложение при этом работает в составе веб-сервера и осуществляет взаимодействие с пользователем путём получения HTTP-запросов от браузера пользователя (ввод) и генерации веб-страниц (вывод).

Объект окружения — это любая внешняя по отношению к веб-приложению сущность, предоставляющая набор операций, которые могут быть осуществлены веб-приложением над данным объектом окружения. В качестве примеров объектов окружения могут быть приведены ресурсы операционной системы, почтовый сервис, СУБД.

Операция — любое действие, которое может быть осуществлено над объектом окружения веб-приложением. Например, для объекта окружения «СУБД» операциями являются операторы языка SQL, для объекта окружения «почтовый сервис» — функции отправки сообщений.

Значение операции — это отображение результатов операции во множество вещественных чисел. Семантика отображения определяется для каждой конкретной операции. Например, для операций «SELECT» или «INSERT» объекта окружения «СУБД» значением данных операций может являться количество затронутых строк в базе данных; для операций «чтение из файла» или «запись в файл» объекта окружения «ресурсы операционной системы» значением операции может являться количество прочитанных или записанных байт соответственно. Очевидно, не для каждой операции значение операции может быть иметь смысл. Например, для операции «выбор базы данных» объекта окружения «СУБД». В этом случае в качестве значения операции может быть выбрана некоторая константа.

Логическая схема веб-сервера представлена на рисунке 3.1.

Рисунок 3.1 Логическая схема веб-сервера

В схеме, изображённой на рисунке 3.1:

Веб-сервер — приложение, выполняющее функции веб-сервера, например, Apache HTTP Server или Microsoft Internet Information Services (IIS).

Технология поддержки веб-приложения — набор программных компонент, формирующих среду для выполнения веб-приложений, созданных при помощи данной технологии. В качестве примера можно привести такие распространённые технологии, как PHP и ASP.net.

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

В общем случае, взаимодействие пользователя с веб-приложением происходит по следующей схеме [17, 22]:

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

Порождённый HTTP-запрос принимается и обрабатывается веб-сервером. Определяется, какому веб-приложению адресован запрос и какие компоненты отвечают за выполнение веб-приложения. Происходит запуск необходимых компонент и передача данных HTTP-запроса.

В сформированной запущенными компонентами рабочей среде производится запуск веб-приложения.

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

Веб-приложение генерирует вывод, который передаётся компонентами технологии поддержки веб-приложения веб-серверу. Веб-сервер отправляет вывод клиенту в виде HTTP-ответа.

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

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

4 Метод обнаружения уязвимостей веб-приложений

В данном разделе описывается предлагаемый метод обнаружения уязвимостей веб-приложений на основе контроля поведения веб-приложения.

4.1 Применение метода

Как было отмечено во Введении, существующие средства обнаружения уязвимостей используют методы белого и чёрного ящика. В первом случае производится анализ исходных коды и/или файлов конфигурации веб-приложения. Выявляются участки кода, потенциально содержащие уязвимость или небезопасные параметры конфигурации. Во втором случае осуществляется поиск уязвимостей «извне» — веб-приложению отсылаются HTTP-запросы и анализируются ответы. При этом встают задачи выявления структуры веб-приложения, определения типа сервера и построения тестового набора HTTP-запросов и последующего анализа HTTP-ответов. Но данные средства не осуществляют контроль поведения веб-приложения в смысле, определённом в Разделе 3, в то время как необнаруженные уязвимости могут проявиться именно в обращении к объектам окружения. Предлагаемый метод обнаружения уязвимостей предполагает сравнение поступающего HTTP-трафика со внутренней работой веб-приложения. Метод предназначен для обнаружения уязвимостей, приводящих к недопустимым с точки зрения профиля нормального поведения операциям веб-приложения над объектами окружения и/или изменению значений допустимых операций.

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

4.2 Описание метода

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

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

Режим обучения предназначен для автоматического построения профилей нормального поведения веб-приложений. В режиме обучения веб-приложение используется легитимным пользователем строго по назначению. На этапе обучения трасса анализируется, и в результате анализа формируется профиль нормального поведения веб-приложения. В нём фиксируются наборы HTTP-параметров и соответствующие наборы операций. Таким образом, профиль несёт в себе информацию об ожидаемых (или допустимых) операциях в ответ на каждый набор HTTP-параметров. Подробнее алгоритм построения профиля нормального поведения описывается в Подразделе 6.4.3.

Очевидно, для построения максимально подробного и адекватного профиля нормального поведения, функционирование веб-приложения в режиме обучения должно охватывать возможно большее количество вариантов использования. При этом также встаёт традиционная для включающих в себя этап обучения методов обнаружения аномалий проблема «чистоты» учебного периода — необходимо оградить веб-приложение от возможного использования злоумышленниками, так как иначе в профиле нормального поведения в качестве допустимых будут зафиксированы действия, потенциально таковыми не являющиеся [4, 6].

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

4.3 Использование значений операций для более точного обнаружения отклонений в поведении

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

Можно привести следующий пример. Уязвимость в файле modules. php распространённого веб-приложения CMS PHP-Nuke v 7.5 позволяет провести атаку типа класса SQL injection. При атаках этого класса злоумышленник заставляет веб-приложение выдать СУБД изменённый или модифицированный запрос. Атаки класса SQL injection являются как распространёнными, так и особенно опасными в связи с тем, что могут потенциально приводить к потере всех данных в базе данных. Не менее опасными представляются кража или подмена данных в базе данных. Уязвимости, позволяющие проведение атак класса SQL injection, обычно связаны с недостаточной проверкой и очисткой вводимых пользователем данных при динамическом формировании SQL-запроса с использованием этих данных.

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

1-й POST-параметр: name=Your_Account

2-й POST-параметр: op=userinfo

3-й POST-параметр: username=' OR username LIKE `%'; - ;

Результирующий SQL-запрос:

SELECT uname FROM nuke_session WHERE uname='' OR username LIKE `%'; - -'

Таким образом, с точки зрения описанного метода в ходе атаки веб-приложение совершит допустимую операцию «SELECT» над объектом окружения «сервер MySQL». Аномалия будет заключаться в изменении значения операции. При обычном функционировании значение данной операции будет равно 1, в то время как в результате проведения атаки значение операции будет равно количеству строк в таблице nuke_session.

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

1-й POST-параметр: user=Bob

2-й POST-параметр: card_type=' OR user='Alice

Результирующий SQL-запрос:

SELECT card_id FROM creditcards WHERE user='Bob' AND type=`' OR user='Alice'

Таким образом, с точки зрения описанного метода в ходе атаки веб-приложение совершит допустимую операцию «SELECT» над объектом окружения «сервер MySQL». Аномалия будет заключаться в изменении значения операции. При обычном функционировании значение данной операции будет равно количеству кредитных карт пользователя Bob, информация о которых содержится в таблице creditcards, в то время как в результате проведения атаки значение операции будет равно совокупному количеству кредитных карт пользователей Bob и Alice.

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

4.4 Отклонения в поведении с точки зрения метода

Таким образом, с точки зрения описываемого метода, возможны два класса аномалий:

Аномалии, связанные с обнаружением недопустимых операций.

Аномалии, связанные со значениями операций.

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

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

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

4.5 Сравнение наборов HTTP-параметров

Необходимо дополнительно рассмотреть вопрос о сравнении наборов HTTP-параметров.

Параметры могут быть переданы в веб-приложение методами GET и POST [22, 23], определёнными в стандарте протокола HTTP. При использовании метода GET параметры передаются в URL-адресе вида

http://<�адрес приложения>? параметр1=значение1&параметр2=значение2

Так как длина URL ограничена, метод GET применим для передачи данных небольшого объёма. Cогласно стандарту HTTP [23], запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET. В качестве примера можно привести поисковую систему Google.com — она принимает поисковый запрос в URL-строке.

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

Таким образом, методом POST в основном передаются данные большой длины [22], в основном из форм, в то время как данные, переданные методом GET (то есть, URL, содержащий набор параметров), используются в основном для навигации — URL с заданными параметрами может быть передан для перехода на нужную страницу. Разработчиками веб-приложений часто используется комбинированный подход — GET параметры используются для уточнения действия, а POST параметры содержат данные, которые предстоит обработать.

В качестве примера, иллюстрирующего такой подход, можно привести популярные веб-приложения, созданные при помощи технологии PHP — систему управления контентом Drupal (текущая версия — 5.1) и систему управления форумом Invision Power Board (текущая версия — 2.2).

В системе управления контентом Drupal вся работа ведётся через файл index. php, расположенный в папке приложения, в котором, по мере необходимости, подключаются дополнительные модули и библиотеки. Специальный GET-параметр q используется для указания действия или адреса страницы и присутствует в URL-адресе всегда, за исключением случая, когда идёт обращение по базовому адресу веб-приложения. В этом случае параметр q считается неопределённым, что соответствует главной странице сайта под управлением Drupal. К примеру, при заданном значении параметра q=admin/build/modules система выводит список модулей в виде формы с флажками. Можно выбрать модули, которые должны быть подключены и по нажатию кнопки отправки данных система сохранит конфигурацию и проинсталлирует выбранные модули. При этом данные формы будут переданы по URL-адресу, содержащему то же значение параметра q=admin/build/modules, но среди POST-данных будет присутствовать скрытый (типа hidden) параметр формы form_id со значеием «system_modules», что будет являться указанием системе сохранить параметры конфигурации, переданные из формы. Аналогично реализованы остальные функции системы: параметр q используется для указания действия, а POST-данные содержат данные для обработки.

В системе управления форумом Invision Power Board используется схожая схема работы. Все действия осуществляются через файл index. php. Действия и дополнительные данные для обработки указываются как в GET, так и в POST-параметрах. К примеру, GET-параметр showforum=8 в URL-адресе является командой отображения страницы со списком тем форума с соответсвующим идентификатором в базе данных; GET-параметр showtopic=12 — команда отображения страницы со списком сообщений на тему с соответствующим идентификатором в базе данных. При добавлении сообщения данные отсылаются методом POST, в числе которых присутствует скрытый (hidden) параметр act со значением «Post», что и является для системы командой на обработку остальных данных и добавление сообщения.

Таким образом, можно сделать следующий вывод. GET-параметры во многих случаях используются как своеобразные «указатели» действия или для навигации, поэтому разные значения одного и того же GET-параметра могут приводить к логически разным действия веб-приложения (как в случае GET-параметра q системы управления контентом Drupal). POST-параметры содержат данные для обработки и, за исключением служебных, вроде скрытого параметра act системы управления форумом Invision Power Board, рассмотренного выше, как правило не управляют логикой работы веб-приложения — разные значения POST-параметров будут обрабатываться в рамках одной и той же логики. Из этого следует, что GET-параметры логично сравнивать на точное совпадение по значению, а POST-параметры — на совпадение типов. Однако, в ряде случаев для отдельных параметров возможны исключения или особые условия при сравнении. Набор типов и их семантика определяется реализацией; подробнее об используемом наборе типов и задании исключений и особых условий при сравнении рассказывается в Подразделе 6.2.2 и Подразделе 6.4.2.

Таким образом, далее будет считаться, что два набора HTTP-параметров совпадают, если:

количество и набор GET-параметров совпадают, значения соответствующих GET-параметров совпадают;

количество и набор POST-параметров совпадают, типы соответствующих POST-параметров совпадают;

HTTP-параметры, для которых оговорены особые правила сравнения, совпадают согласно правилам сравнения.

5. Выбор методов обнаружения аномалий

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

Рассмотренные методы были выбраны из следующих соображений:

каждый метод является представителем класса методов;

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

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

5.1 Метод Хотеллинга (тест Хотеллинга)

Метод Хотеллинга представляет собой многомерный статистический метод обнаружения аномалий. Пусть X_i = (X_i1, X_i2, …, X_ip) ' — значения p параметров процесса или системы в определённый момент времени i. Предполагается, что при нормальном функционировании процесса анализируемое множество векторов X обладает нормальным распределением с вектором математических ожиданий м и ковариационной матрицей У. Для образца данных размера n вектор математических ожиданий X и ковариационная матрица S обычно рассчитываются следующим образом:

Значение теста Хотеллинга T² для наблюдения X_i рассчитывается следующим образом:

Большое значение T² означает большое отклонение значений наблюдения X_i от математических ожиданий анализируемой совокупности наблюдений.

Обычно неизвестно, каким распределением обладает множество значений каждой такой переменной, а значит, выдвигать предположение о том, что оно является нормальным, нельзя. Однако, если p случайных величин независимы и p достаточно большое (примерно больше 30), то T² имеет распределение близкое к нормальному в соответствии с Центральной Предельной Теоремой вне зависимости от того, какими распределениями обладают множества значений каждой из p рассматриваемых случайных переменных. Используя набор значений T², можно получить значения дисперсии и математического ожидания путём приближения математического ожидания и дисперсии. Предельные значения для обнаружения потери контроля над процессом обычно ставятся равными 3у и определяют диапазон. по выходу значения T² за который подаётся сигнал об аномалии.

Сигнал о потере контроля над процессом на основе теста T² может быть вызван сдвигом математического ожидания, потерей связи между переменными или комбинацией обеих ситуаций. В ситуации «сдвиг математического ожидания» одна или более из p переменных выходят из-под контроля. В ситуации «потеря взаимодействия переменных», взаимодействие между двумя или более из p переменных начинает отличаться от описанного в ковариационной матрице.

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

Процесс автоматического построения профиля нормального поведения для теста Хотеллинга происходит следующим образом. Берётся набор учебных данных, каждый элемент которого представляет собой вектор значений параметров системы в конкретный момент времени. Для каждого параметра рассчитывается математическое ожидание, таким образом формируется вектор математических ожиданий X, который фиксируется в профиле. Далее рассчитывается и фиксируется в профиле ковариационная матрица S. Затем высчитывается математическое ожидание теста Хотеллинга и дисперсия, после чего высчитывается и фиксируется в профиле контрольный диапазон. После фиксации границ контрольного диапазона можно начинать анализ поступающих данных на предмет обнаружения аномалий — то есть выхода значения теста T² за пределы контрольного диапазона.

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

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

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

5.2 Метод EWMA (Exponentially Weighted Moving Average)

В основе метода EWMA лежит экспоненциальное сглаживание первого порядка [20, 21]:

(5.2.1)

где

0<�л?1 — константа сглаживания.

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

z₀ = (5.2.2)

Если раскрыть z_i-1, получается:

Рекурсивно, для z_i-j, j=2, 3, …, t получается:

Вес элемента уменьшается геометрически, с ростом порядкового номера. Сумма весов стремится к 1, так как:

Если, к примеру, л=0.2, то вес, назначенный текущему элементу, равен 0.2, а веса, назначенные предыдущим элементам, равны 0.04, 0.128, 0.1024 и так далее.

Рисунок 5.2.1 Изменение веса образца в ходе работы EWMA

Контрольные пределы для EWMA рассчитываются следующим образом (ВКП — верхний контрольный предел, НКП — нижний контрольный предел):

(5.2.3)

(5.2.4) где

Где у^2 — дисперсия, а м_x - математическое ожидание случайной величины x_i.

В этих формулах L является шириной контрольного диапазона.

На практике часто используемыми значениями константы сглаживания являются л=0.05, л=0.10 и л=0.25. При меньших значениях л на значение статистики z_i влияет большее количество значений x_i, при больших — меньшее, что позволяет параметризовать формулу расчёта z_i (5.2.1) для учёта краткосрочных или долгосрочных тенденций.

В общем случае формирование профиля нормального поведения производится следующим образом.

Получается набор учебных данных. Далее высчитывается математическое ожидание для анализируемой случайной величины, оно принимается в качестве начального значения статистики z_{0 (}согласно формуле (5.2.2)). Затем по формуле (5.2.1) для каждого i-го значения случайной величины из тестового набора рассчитывается значение статистики z_i. После этого высчитывается дисперсия для x_i и контрольные пределы по формулам (5.2.3) и (5.2.4). Полученные данные сохраняются в профиле нормального поведения.

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

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

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

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

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

5.3 Метод цепей Маркова

Определение [26]: Маркова цепь — марковский процесс с дискретным временем, заданный в измеримом пространстве.

Стохастический процесс в дискретные моменты времени показывает, как меняется значение случайной переменной в данные моменты времени. Пусть X_t — некоторая случайная переменная, представляющая состояние системы в момент времени t, где t=0, 1, …Стационарная цепь Маркова — это стохастический процесс с дискретным временем, для которого предполагается следующее:

распределение вероятности нахождения системы в некотором состоянии в момент времени t+1 зависит от состояния в момент времени t и не зависит от состояний, в которых находилась система в моменты времени, предшествующих моменту t;

переход из состояния в момент времени t в состояние момента времени t+1 является мгновенным.

Обозначим через p_ij вероятность того, что система находится в состоянии j в момент времени t+1 и в состоянии i в момент времени t. Если множество возможных состояний системы конечно (1, 2, …, s), то стационарная цепь Маркова может быть определена матрицей вероятностей переходов

и вектором начального распределения вероятностей: Q = (q₁ q_{2 …} q_s), где q_{i -} вероятность нахождения системы в состоянии i в момент времени 0 и .

Вероятность появления последовательности состояний X₁, X₂, …, X_T в моменты времени 1, 2, …, T в контексте цепной модели Маркова рассчитывается следующим образом:

Матрица вероятностей переходов и вектор начального распределения вероятностей могут быть построены путём анализа состояний системы в предыдущие моменты времени. Если имеется набор наблюдений за состояниями системы X₀, X₁, …, X_N-1 в моменты времени 0, 1, …, N-1, то компоненты матрицы вероятностей переходов и вектора начального распределения вероятностей рассчитываются следующим образом:

(5.3.1)

где

N_{ij -} количество наблюдаемых пар состояний X_t и X_t+1, равных i и j соответственно.

N_{j. -} количество наблюдаемых пар состояний X_t и X_t+1, где первое равно i любым из 1, 2, …, s.

N_j — количество состояний X_t, равных i

N — общее количество наблюдений.

Для анализа открывается окно наблюдения размера N — берутся N последних событий до настоящего момента времени t E_{t— (N-1) =t-N+1}, …, E_t.

Каждому событию сопоставляется тип из конечного множества типов событий. Далее анализируется получившаяся последовательность состояний — типов событий X_t-N, …, X_t (X_{i -} тип события E_i).

Вероятность принадлежности данной последовательности состояний нормальному поведению системы определяется по следующей формуле:

(5.3.2)

Последовательность аномальных действий будет иметь меньшую вероятность (меньшую поддержку модели).

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

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

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

В режиме обнаружения аномалий для каждого набора HTTP-параметров открывается окно наблюдения, охватывающее последовательность значений операций, поступающих для данного набора HTTP-параметров. На основе извлечённых из профиля нормального поведения матрицы вероятностей переходов и вектора начального распределения вероятностей по формуле (5.3.2) пересчитывается общая вероятность последовательности значений операций, зафиксированной в текущий момент времени в окне наблюдения. При падении вероятности ниже контрольного предела — фиксируется аномалия и предполагается уязвимость в веб-приложении, которому поступил запрос.

5.4 Нейросетевой метод

Нейросетевой метод обнаружения аномалий рассматривается на примере экспериментальной системы обнаружения аномалий NNID (Neural Network Intrusion Detection).