Для упрощения реализации интерфейса был использован следующий подход:
- библиотека, реализующая доступ к хранилищу, состоит из реализации функций, требуемых для работы компонентов;
- для конкретной СУБД создаются хранимые процедуры, осуществляющие непосредственно добавление и получение данных из хранилища;
- в каждой функции библиотеки выполняется вызов хранимых процедур используемой СУБД.
Функции библиотеки можно разделить на следующие группы в зависимости от их применения:
1) Функции регистрации данных о хостах сети и функционирующих компонентах (датчиках, модулях анализа, межсетевых экранах).
2) Функции формирования данных для сохранения сетевых данных события (сетевого контекста).
3) Функции формирования данных для сохранения хостовых данных события (хостового контекста).
4) Функции формирования сообщения.
5) Функции сохранения сообщения.
6) Функции получения данных о событии.
При подключении нового компонента необходимо добавить данные о нем в таблицу БД: IDS_Module. Категория компонента сохраняется добавлением идентификатора компонента в одну из таблиц: Analyzer, Sensor или Firewall. Тип компонента сохраняется в таблицу IDS_Module_Type, зависимости между компонентами различных типов добавляются в таблицу Modules_Type_Using. Расположение компонента сохраняется в следующих таблицах Node, Node_name, Node_Address, Address. Параметры функций регистрации компонентов различных типов определяются данными, требуемыми для заполнения указанных таблиц. В основную таблицу заносятся название, тип компонента, модель, версия и производитель и некоторые дополнительные данные о компоненте.
Для заполнения таблиц c расположением компонента нужны название и/или адрес станции, на которой будет выполняться компонент, а также указание типа имени и/или адреса, с помощью которых процессор запуска определяет, как их интерпретировать; указанные данные заносятся в таблицы Node_Address_Category, Node_Name_Category.
Для регистрации нового компонента необходимо сначала инициализировать структуру описания компонента требуемыми значениями. Полями данной структуры являются название, тип, модель, версия, класс, производитель компонента, данные о местоположении компонента. Кроме того, существует поле, указывающее тип модуля (датчик, модуль анализа, межсетевой экран). Структура содержит также ссылку на структуру с данными, специфичными для данного типа компонента.
На рис. 3 показана связь между полями структуры компонента и таблицы базы данных хранилища.
Рисунок 3 Связь полей структуры модуля module_t и таблиц БД
Далее для регистрации нового модуля используется одна из функций, в зависимости от типа модуля, register_sensor, register_analyzer или register_firewall. Каждая из функций принимает в качестве параметра указатель на инициализированную структуру модуля module_t.
После добавления нового модуля в хранилище процессор запуска получает идентификатор добавленного модуля. Получить идентификатор модуля можно также с помощью функции get_module_id. На рис.4 приведена взаимосвязь между входными параметрами функции и таблицами БД.
Рисунок 4 Получение идентификатора модуля
Библиотека также предоставляет функцию для добавления информации о защищаемых хостах, описания новых защищаемых сервисов и используемых протоколов, а также управления защищаемыми сервисами для станции, которые используются компонентами управления СОВ (менеджерами). Описание указанных функций приведено в Приложении 3.
При сохранении сообщения от компонента данные добавляются в таблицы Message, Heartbeat или Alert. Оценка меры влияния данного события и степень уверенности в правильном определении сохраняются в таблице Assessment. Для сообщений об атаках дополнительно заполняются таблицы Alert_Source, Alert_Target, где указываются данные о предполагаемом источнике и целевой станции. Если вывод о некотором событии сделан модулем на основе других сообщений хранилища, связь между ними указывается в таблице Reaction.
Модуль также должен сохранить данные о классификации события, оценку опасности события для целевой системы, ссылки на дополнительные источники информации о событии. Если вывод о возможной или осуществленной атаке сделан на основе базы данных сигнатур, в хранилище добавляется название и класс сигнатуры. В связи с этим модуль должен инициализировать структуру описания события следующими данными: идентификатором сигнатуры (в случае, если сигнатура уже есть в базе, в структуре события будет указан идентификатор уже существующей сигнатуры), названием и классом сигнатуры, массивом ссылок на внешние источники информации о событии.
Кроме того, для событий от сетевых и хостовых датчиков о возможных или осуществленных атаках, в хранилище должна быть добавлены данные, на основе которых был сделан подобный вывод.
Если сообщение сгенерировано после получения сетевого пакета (модуль является сетевым датчиком), в хранилище дополнительно сохраняются параметры пакета. При этом необходимо добавить информацию в таблицу iphdr, одну из таблиц tcphdr, udphdr, icmphdr для сохранения данных заголовков сетевого и транспортных протоколов, а также таблицу data, где сохраняются данные прикладного уровня (вся эта информация составляет сетевой контекст события).
Соответственно, функции инициализации структур сетевого контекста для события принимают на вход данные заголовков сетевых пакетов, которые собираются библиотекой в отдельные структуры. Поля структур заголовков пакетов однозначно соответствуют форматам пакетов, определенных в соответствующих RFC, поэтому могут быть правильно интерпретированы и заполнены любым модулем.
На рис.5 приведена взаимосвязь параметров функций инициализации, полей структур и таблиц базы данных, в которые впоследствии сохраняются сетевые данные.
Рисунок 5 Взаимосвязь параметров функций инициализации, структур и таблиц БД для сетевых данных
Структура network_context_t (рис. 6) инициализируется с помощью функции init_network_context, на вход которой подаются указатели на уже инициализированные структуры сетевых данных или пустые указатели (NULL), которые интерпретируются библиотекой как отсутствие информации данного типа.
Рисунок 6 Структура network_context_t
В случае, когда модуль расположен непосредственно на защищаемой станции (хостовой датчик) и располагает дополнительными данными об учетных записях пользователей, процессах, файлах, функциях на источнике и/или целевом объекте, связанных с событием (хостовой контекст события), при добавлении сообщения в хранилище дополнительно заполняются таблицы User, File, Process, Function, которые, в свою очередь, имеют зависимые таблицы (см. раздел Host sensor data на схеме БД хранилища).
Функции инициализации структур хостовых данных принимают требуемую информацию и объединяют ее в соответствующие структуры: user_t, file_t, process_t и function_t.
На рис.7 приведена взаимосвязь параметров функций инициализации, полей структур и таблиц базы данных, в которые впоследствии сохраняются хостовые данные.
Рисунок 7 Взаимосвязь параметров функций инициализации, структур и таблиц БД для хостовых данных
Структуры source_context_t и target_context_t (рис.8) инициализируются с помощью функций библиотеки указателями на уже инициализированные структуры хостовых данных или пустые указатели (NULL), которые интерпретируются библиотекой как отсутствие информации данного типа.
Рисунок 8 Структуры target_context_t и source_context_t
Далее модуль инициализирует структуру события alert_t указателями на уже сформированные структуры и дополнительными данными о событии (идентификатор компонента, время обнаружения, оценка опасности события и мера уверенности в правильном определении). Компоненты структуры alert_t приведены на рис.9.
Рисунок 9 Структура alert_t
После чего событие сохраняется в базу данных с помощью функции save_alert, принимающей указатель на структуру. На рис.10 схематично показано, как информация полей структуры alert_t распределяется по таблицам базы данных при сохранении события.
Рисунок 10 Сохранение данных структуры alert_t в таблицы БД хранилища
Таким образом, существует практически однозначное соответствие между параметрами функций API хранилища и полями таблиц БД, что и определяет универсальность интерфейса доступа к базе данных хранилища, обоснование архитектуры которой приведено выше.
Получение информации о добавленных событиях необходимо главным образом зависимым компоентам. Соответственно, библиотека должна предоставлять функции для получения данных из хранилища по идентификатору созданного сообщения. Идентификатор последнего добавленного в хранилище сообщения является открытым полем класса-оболочки потока зависимого модуля, значение идентификатора указывается модулем в качестве параметра процедуры Notify зависимого модуля, генерирующим сообщение, который получает указатель на объект зависимого модуля от процессора управления компонентами (при вызове Notify для всех зависимых модулей). Поэтому идентификатор сообщения будет известен зависимому модулю.
В данной реализации выделение памяти и собственно получение данных разнесены в отдельные функции. Для получения данных о событии модуль должен сначала выделить память под необходимые структуры. Если полями структуры являются указатели на структуры, необходимо выделить память и под них. Для этого модуль может использовать функции библиотеки, которые выделяют память под структуру и ее поля, если это необходимо, и заполняет структуру значениями по умолчанию. К каждой функции выделения памяти существует обратная функция освобождения выделенной памяти. Для удобства в библиотеке выделены функции инициализации структур определенными модулем значениями и значениями по умолчанию. После выделения памяти модуль может запросить требуемые данные о произошедшем событии по идентификатору события из базы с помощью функций библиотеки. Первым параметром каждой функции является идентификатор сообщения, хранящегося в базе, данные о котором требуется получить, вторым параметром является указатель на структуру, в которую необходимо сохранить полученные из хранилища данные. На рисунках ниже схематично показано, из каких таблиц БД различные функции библиотеки получают информацию.
Рисунок 11 Получение данных о сообщении
Рисунок 12 Получение хостовых данных события
Рисунок 13 Получение сетевого контекста события
4.3 Процессор запуска и управления компонентами
Процессор запуска и управления компонентами при старте сканирует директорию с подключаемыми модулями и регистрирует их, сохраняя информацию, необходимую для управления модулями. Для регистрации модулей используются функции, предоставляемые библиотекой.
После обработки всех модулей процессор управления строит для каждого из них списки модулей, зависимых от него. Далее процессор запускает модули на выполнение. Каждый модуль исполняется в отдельном потоке. При этом потоки модулей с типом запуска ON_DEPENDENCE блокируются до получения процессором оповещения о наступлении события от тех модулей, результаты работы которых используются первыми. Для создания потоков и организации синхронизации между ними процессор запуска использует классы-оболочки потоков запуска модулей на основе библиотеки pthreads, реализующей стандарт POSIX для работы с потоками. Существует три основных класса SCSModuleThreadOnce (используется для модулей, запускаемых один раз), SCSModuleThreadTimeout (используется для модулей, запускаемых периодически по таймауту), SCSModuleThreadByReq (используется для модулей, запускаемых по запросу), которые отличаются реализацией функций запуска и остановки потоков модулей. Для модулей, запускаемых по запросу, дополнительно реализована функция оповещения о новом сообщении c идентификатором добавленного сообщения в качестве параметра. Управление компонентами (запуск, остановка) осуществляется при помощи мьютексов и условных переменных (conditions), предоставляемых библиотекой pthreads. Для вызова зависимых компонентами при добавлении нового сообщения в базу также используются условные переменные библиотеки pthreads.
Каждый компонент должен экспортировать блок описания, где указаны тип компонентая, тип вызова (ONCE - один раз, TIMEOUT - раз в таймаут, ON_DEPENDENCE - зависимый от другого комопнента), таймаут запуска (только для запуска по таймауту), название компонента, производитель, версия и модель, дополнительное описание и класс модуля, а также тип модуля, результаты работы которого использует данный модуль. Таким образом, модуль предоставляет процессору запуска структуру своего описания следующего вида:
struct _SCS_MODULE_DESCRIPTION_BLOCK {
const char* type; // тип компонента
const char* description; // описание типа компонента
//тип вызова компонента (перечисление): ONCE, TIMEOUT, //ON_DEPENDENCE, NEVER
SCS_MODULE_CALLTYPE calltype; int timeout; // таймаут запуска модуля
const char* name; // имя компонента
const char* manufacturer; // производитель
const char* model; // модель компонента
const char* version; // версия компонента
const char* module_class; // класс компонента
};
Кроме того, в каждом подключаемом компоненте должны быть реализованы интерфейсные функции: функция инициализации компонента – Initialize, функция запуска – Run и функция остановки выполнения – Terminate, в которой выполняются действия, необходимые комопненту для корректного завершения работы, например, освобождение выделенной в процессе работы памяти.
Список комопнентов, от которых зависит запуск данного компонента хранится в массиве char* Uses[], который инициализируется им самостоятельно.
4.4 Подключаемые компоненты
Подключаемые компоненты позволяют легко расширять возможности системы по обнаружению атак на защищаемые станции за счет создания различных датчиков и модулей анализа и осуществления взаимодействия между ними. Кроме того, допустимо создание и использование модулей уведомления для вывода результатов других модулей, модулей вывода пользовательского интерфейса и др. Можно привести следующие примеры подключаемых комопнентов:
· сетевой датчик событий
· хостовой датчик событий
· генератор вторичных атрибутов и/или корреляций событий
· датчик значений параметров защищаемой системы
· модуль анализа в режиме реального времени
· модуль пост-обработки (вне режима реального времена)
· хостовой модуль блокировки нарушителя
· сетевой модуль блокировки нарушителя (межсетевой экран)
· модуль уведомления администратора
· модуль хранения входных данных и результатов обработки
· модуль, реализующий пользовательский интерфейс вывода результатов работы.
Пример реализации подключаемого модуля приведен в главе 4.
4.5 Выводы
В данной главе описана реализация ядра универсальной архитектуры СПВ. Ядро включает хранилище данных на базе СУБД MySQL. Данная СУБД была выбрана потому, что она является свободно распространяемой. Выбор СУБД не принципиален при реализации ядра. К хранилищу данных предоставляется интерфейс доступа в виде библиотеки, написанной на языке C как наиболее распространенном универсальном языке программирования, в главе описана реализация этого интерфейса. В рамках реализации ядра создан процессор запуска и управления компонентами, предоставляющий базовые механизмы СПВ.
5 Пример реализации подключаемого модуля
Рассмотрим демонстрационный пример работы системы. В рамках данной работы в качестве хранилища была использована база данных под управлением СУБД MySQL. Была портирована сетевая система обнаружения вторжений Snort как пример подключаемого модуля в рамках СПВ на базе разработанной универсальной архитектуры. Для запуска Snort в качестве компонента системы был реализован требуемый для подключения интерфейс (блок описания модуля, функции инициализации, запуска, остановки и оповещения).
5.1 Описание реализации
СОВ Snort позволяет создавать модули (плагины) для вывода предупреждений в требуемом формате. Для взаимодействия с хранилищем через интерфейс был создан модуль вывода, выполняющий конвертирование данных Snort в определенный библиотекой формат и сохранение информации о предупреждении в хранилище посредством функций библиотеки.
Для демонстрации механизма взаимодействия между модулями был также реализован подключаемый модуль, выполняющий вывод сообщения о добавленном предупреждении в системный журнал ОС Windows каждый раз при генерации Snort сообщения об атаке. В модуле также реализованы все функции, необходимые для подключения. В блоке описания указан тип запуска ON_DEPENDENCE (по запросу), а в массиве модулей Uses, от которых зависит данный модуль, - тип модулей «snort». Модуль «узнает» о новом сообщении, сгенерированном snort, c помощью условных переменных библиотеки pthreads.
Описанная в данном разделе конфигурация системы (рис. 14) полностью соответствует архитектуре СПВ, приведенной на рис.2.
Рисунок 14 Схема работы демонстрационного примера
Рассмотрим подробнее последовательность действий, выполняемых сетевым модулем Snort для сохранения сообщения. Snort делает вывод о возможной атаке на основе совпадения определенных параметров сетевого пакета с сигнатурой из базы сигнатур датчика. Для внесения информации о предупреждении в хранилище необходимо конвертировать данные модуля в формат, определенный хранилищем. Сначала модуль должен выделить память под требуемые структуры, определенные интерфейсом доступа к хранилищу (библиотекой), и инициализировать их. Инициализация всех структур происходит посредством вызова соответствующих функций библиотеки. Далее определяется идентификатор и класс сигнатуры из базы датчика, на основе совпадения с которой было сделано предположение об атаке. Структура для описания события инициализируется соответствующими значениями. Затем на основе определенным образом разобранных параметров пакета начинается инициализация сетевого контекста. Сначала заполняется структура параметров заголовка IP. Далее определяется тип заголовка транспортного уровня, и инициализируется соответствующая структура. Данные протоколов прикладного уровня сохраняются в виде массива байтов.
После обработки данных сетевой датчик создает структуру события и инициализирует ее, передавая указатели на заполненные структуры, определяющие заголовки пакета, данные о сигнатуре и др. Затем вызывается функция сохранения события в хранилище. Библиотека формирует последовательность вызова хранимых процедур базы с параметрами, определенными на основе информации из переданного модулем указателя на структуру события и выполняет сохранение.
В данной главе рассмотрен демонстрационный пример функционирования системы предотвращения вторжений на базе универсальной архитектуры с использованием двух подключаемых модулей: сетевого датчика Snort и зависящего от него модуля вывода в системный журнал Windows.
5.2 Выводы
Портирование существующей системы в качестве подключаемого компонента СПВ на базе универсальной архитектуры выполняется относительно просто, не требует больших временных затрат и ухищрений, синхронизация работы компонентов между собой выполняется ядром архитектуры. Таким образом, включение дополнительных компонентов и расширение функциональности существующей системы выполняется достаточно эффективно.
6 Заключение
В данной работе получены следующие результаты.
1. Разработана универсальная архитектура предотвращения вторжений. Выделено ядро этой архитектуры, реализующее базовые механизмы, необходимые для создания любой СПВ.
2. Реализовано ядро универсальной архитектуры СПВ, включающее хранилище данных на базе СУБД MySQL, к которому предоставляется интерфейс доступа на языке C.
3. Реализован демонстрационный пример работы системы на базе разработанной универсальной архитектуры СПВ, показана эффективность и невысокая трудоемкость разработки и портирования систем в СПВ с данной архитектурой.
Наиболее перспективными направлениями исследований являются создание хранилища данных ядра архитектуры для других СУБД, реализация интерфейса доступа к ним, разработка (и портирование) других компонентов СПВ на базе данной архитектуры с реализацией различных типов их взаимодействия, а также портирование ядра архитектуры под Linux.
Приложение 1. Основные классы модели IDMEF
Класс | Вложенные элементы класса | Описание | Обязательный |
IDMEF-Message | Сообщение IDMEF | ||
Alert | Сообщение об атаке от службы анализа | Корневой элемент | |
Analyzer | Модуль анализа | Да | |
CreateTime | Время создания сообщения | Да | |
Classification | Объект классификации события | Да | |
DetectTime | Время обнаружения события | Да | |
Source | Предполагаемый источник атаки | Да | |
Target | Предполагаемая цель атаки | Да | |
Assessment | Оценка события модулем анализа | Нет | |
Messageid | Уникальный идентификатор сообщения | Нет | |
Analyzer | Класс определяет компонент СОВ, обрабатывающий информацию, собранную датчиками, или интегрированный компонент сбора и анализа, т. е. отправителя IDMEF сообщения. | Да | |
analyzerid | Уникальный идентификатор модуля анализа. | Да | |
name | Название модуля. | Нет | |
manufacturer | Производитель модуля | Нет | |
version | Версия компонента | Нет | |
ostype | Названия операционных систем, для которых предназначен модуль | Нет | |
Node | Информация о станции, на которой располагается модуль анализа (IP-адрес, имя и т. п.) | Да | |
Classification | Элемент, содержащий информацию, позволяющую определить, что произошло | Да | |
Text | Строка о данном событии, определяемая производителем | Нет | |
Reference | Информация о сообщении, ссылки на базы уязвимостей и т. п. | Нет | |
Source | Элемент, содержащий информацию о возможном источнике события | Да | |
ident | Уникальный идентификатор источника | Нет | |
interface | Сетевой интерфейс модуля анализа | Нет | |
Node | Информация о станции, которая могла быть источником события (ip-адрес, имя и т. п.) | Нет | |
User | Информация о пользователе, осуществляющем воздействие | Нет | |
Process | Информация о процессе, осуществляющем воздействие | Нет | |
Service | Информация о сервисе, осуществляющем воздействие | Нет | |
Target | Элемент, содержащий данные о цели атаки | Да | |
ident | Уникальный идентификатор целевого объекта | Нет | |
Interface | Сетевой интерфейс модуля анализа | Нет | |
Node | Информация о целевом объекте события | Нет | |
User | Информация о пользователе системы, на которого направлено воздействие | Нет | |
Process | Информация о процессе, на который направлено воздействие | Нет | |
Service | Информация о сервисе, на который направлено данное событие | Нет | |
Assessment | Оценка события модулем анализа | Нет | |
Impact | Оценка модулем анализа степени воздействия на целевой объект | Да | |
Action | Действия, предпринятые в ответ на событие | Нет | |
Confidence | Степень уверенности в правильном определении события | Нет | |
CreateTime | Дата и время создания сообщения модулем анализа | Да | |
DetectTime | Дата и время определения события | Да | |
Impact | Оценка степени воздействия на целевой объект | Нет | |
Severity | Мера воздействия на объект атаки. | Нет | |
completion | Результат попытки нарушения безопасности. | Нет | |
type | Элемент, определяющий цель атаки. | Нет | |
Action | Элемент, определяет действия, предпринятые при обнаружении атаки | Нет | |
Category | Действие, предпринятое при обнаружении атаки. | Нет | |
Confidence | Степень уверенности модуля анализа в определении атаки. | Нет | |
Rating | Значение меры уверенности в определении атаки. | Нет | |
Reference | Дополнительная информация о событии | Нет | |
Origin | Источник информации о событии. | Да | |
name | Название события из одной из ссылок, указанных в поле reference. | Да | |
Node | Данные о станции. | Нет | |
name | Имя узла (если не задан адрес). | Да, если не задан адрес. | |
Address | Элемент Address, определяющий адрес узла. | Да, если не задано имя. | |
Address | Класс, представляющий сетевой адрес узла. | ||
Category | Категория (тип) адреса. | Нет | |
Address | Адрес, формат которого определяется значением параметра category | Да | |
vlan-num | Номер VLAN, к которой принадлежит адрес | Нет | |
vlan-name | Имя VLAN, к которой принадлежит адрес | Нет | |
Service | Сервис | Нет | |
ident | Уникальный идентификатор сервиса | Нет | |
ip_version | Используемая версия протокола IP | Нет | |
name | Имя сервиса | Нет | |
Port | Используемый порт | Нет | |
User | Данные о пользователе | Нет | |
ident | Уникальный идентификатор пользователя | Да | |
category | Категория пользовтаеля | Нет | |
Process | |||
name | Имя исполняемой программы | Да | |
pid | Идентификатор процесса | Нет | |
path | Полный путь к выполняющейся программе | Нет | |
arg | Командные аргументы запуска программы | Нет | |
env | Строка переменных окружения для программы | Нет | |
UserId | Дополнительные данные о пользователе | Нет | |
name | Имя пользователя или группы | Да | |
number | Номер пользователя или группы | Да | |
ident | Уникальный идентификатор пользователя | Нет | |
type | Элемент перечисления | Нет | |
tty | Имя терминала пользователя | Нет | |
File | Информация о файле | Нет | |
name | Имя файла | Да | |
path | Полный путь к файлу | Да | |
create-time | Время создания файла | Нет | |
modify-time | Время последней модификации | Нет | |
access-time | Время последнего открытия файла | Нет | |
data-size | Размер данных файла в байтах | Нет | |
disk-size | Размер файла на диске в байтах | Нет | |
FileAccess | Права доступа к файлу | Нет | |
Linkage | Другие ссылки на созданный файл | Нет | |
Inode | Inode файла | Нет | |
Checksum | Контрольная сумма | Нет | |
Category | Категория, указывает, когда получена вся информация о файле (до или после события, которое определено в данном сообщении) | Да | |
fstype | Файловая система | Нет | |
Inode | Информация об i-node (для Unix ФС) | нет | |
change-time | Время последнего изменения inode файла | Нет | |
Number | Номер inode | Да | |
major-device | Номер major-device | Нет | |
minor-device | Номер minor-device | Нет | |
c-major-device | Номер с-major-device | Нет | |
c-minor-device | Номер с-minor-device | Нет | |
FileAccess | Информация о правах доступа к файлу определенного пользователя | Нет | |
UserId | Информация о пользователе или группе, к которым относятся права на файл | Да | |
Permission | Права пользователя или группы на файл | Да | |
Linkage | name | Название ссылки (не включая путь) | Да |
path | Путь к ссылке | Да | |
File | Объект File, на который указывает сслыка | Да | |
category | Тип ссылки | Да | |
Checksum | Данные о контрольной сумме | Нет | |
value | Значение контрольной суммы | Да | |
key | Значение ключа для контрольной суммы, если требуется | Нет | |
algorithm | Используемый для подсчета контрольной суммы алгоритм | Да | |
AdditionalData | Класс дополнительных данных, для дополнения существующих классов; в качестве одного из атрибута. | Нет | |
type | Тип данных, которые содержит элемент класса. | Да | |
meaning | Определяет значение данных. | Нет |
Приложение 2 Описание таблиц базы данных хранилища.
Самоописывающие данные. Таблицы
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 |
