«ОБНАРУЖЕНИЕ КОМПЬЮТЕРНЫХ АТАК НА ОСНОВЕ АНАЛИЗА ПОВЕДЕНИЯ СЕТЕВЫХ ОБЪЕКТОВ Специальность 05.13.11 – математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей ДИССЕРТАЦИЯ на соискание ...»

Эта особенность означает, что траектория поведения РИС может иметь сложную структуру: некоторые действия объектов РИС могут создавать экземпляры объектов так, что все последующие действия объектов будут порождать изменения состояний только в этих порождённых экземплярах объектов. Соответственно, существует множество действий, которые ведут к уничтожению экземпляров объектов. Как правило, к порождающим действиям относятся запросы на обслуживание к объекту, а к уничтожающим действиям – любые действия, вызывающие прекращение обслуживания объекта объектом. Кроме того, множеств объектов в РИС могут меняться с течением времени, что требует расширения множества событий автомата событиями таймера.

траекторий, а «клиентский» объект всегда имеет лишь одну наблюдаемую траекторию.

Для каждой РИС можно описать два типа автоматов: автоматы первого рода описывают атаки, а автоматы второго рода описывают нормальное поведение наблюдаемого объекта.

Для описания двух типов автоматов предложен язык описания сценариев атак, который имеет следующие особенности:

• переходы между состояниями типизированы;

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

• consuming (поглощающий) – не создается новой копии автомата (все переходы выполняются в текущем);

• nonconsuming (непоглощающий) – создается новая копия автомата, переход • unwinding (свёртка) – удаляются все автоматы, порождённые данным автоматом с помощью переходов типа nonconsuming.

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

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

Формально автомат для каждого класса атак Аi представляет собой структуру следующего вида:

S – множество состояний;

PS – множество предикатов состояний;

T – множество переходов;

PT – множество предикатов переходов;

s0 – начальное состояние;

I – множество экземпляров автомата;

g – глобальное окружение;

q – глобальная очередь таймера.

Множество экземпляров I = {i}, i = + непустая последовательность срезов.

Каждый срез : N K L Q E характеризует текущее состояние автомата и содержит имя текущего состояния (элемент пространства имен состояний), локальное окружение, локальную очередь таймера и локальную очередь событий (строка входного алфавита).

Переход выполняется в том случае, если предикаты перехода и целевого состояния принимают значение true одновременно.

* Объявление имени сценария. В скобках указаны типы анализируемых событий события только таких типов отправляются системой прогона автоматов на * вход данному сценарию.

scenario MyScenario ( NetTCPEvent tcpEv, TimerEvent ) { timer t; // объявление локального таймера u_int_16 srcPort; // переменная для хранения номера порта * Объявление начального состояния, в данном случае оно пустое.

initial state state0 {} * Объявление рабочего состояния.

state state1 { ids_time tm; // переменная для инициализации таймера SetTimer ( t, tm ); // устанавливаем таймер на значение переменной * Переход из начального состояния в state1 по событию прихода TCP-пакета * на порт 21.

nonconsuming transition state0->state event NetTCPEvent ( tcpEv.tcpDestPort == 21 ) { // условие перехода DebugPrint ( «Соединение на порт FTP\n» );

srcPort = tcpEv.tcpSrcPort; // сохранение номера порта источника * Переход-свёртка из состояния state1 в начальное состояние по событию * повторного прихода TCP-пакета на порт 21 в течение 2 секунл.

unwinding transition state1->state event NetTCPEvent ( tcpEv.tcpDestPort == 21 && DebugPrint ( «Повторная попытка соединения в течение 2 сек.\n» );

DebugPrint ( «В течение 2 сек. Нет данных.\n» );

Данный пример описывает автомат, обнаруживающий сетевое соединение на стандартный порт FTP. Ниже приведён фрагмент автомата второго рода, описывающего нормальное поведение сервера FTP proftpd (полностью данный автомат описан в разделе 5.2):

* Сценарий нормального поведения сервера ProFTPd версии 1.2.7+ * Входные события – пакеты TCP, события таймера, события системных * вызовов fork(), vfork(), exec().

scenario proftpd ( NetTCPEvent te, TimerEvent, NetLinkEvent nl ) ids_time tm; // переменная для инициализации таймера TCPState ts; // переменная для хранения состояния соединения initial state statepre {} // начальное состояние state state0 {} // первое рабочее состояние state login {} // состояние после получения команды login state welcome {} // состояние после успешной отправки ответа state waitPASS {} // состояние ожидания ввода пароля state sendPASS {} // состояние после ввода пароля state sendUSER {} // состояние после получения команды USER state sendSITEHELP {}//состояние после получения команды SITEHELP state wait221 {} // состояние после отправки кода state wait214SITE {} // состояние после отправки кода state wait150 {} // состояние после отправки кода state sendPORT {} // состояние после получения команды PORT state sendPASV {} // состояние после получения команды PASV consuming transition welcome->wait221//переход по получению команды QUIT event NetTCPEvent ( te.CheckState(ts) == -1 && bs(te.tcpPayload, “QUIT”)) tm.sec = TIMEOUT;

SetTimer ( t1, tm );

d(“welcome->wait221”, te, 0);

unwinding transition welcome->state0 // переход по получению ответа event NetTCPEvent ( te.CheckState(ts) == 1 && bs(te.tcpPayload, “421”) ) d(“unw welcome->state0”, te, 0);

Автомат построен по описанию протокола FTP в стандарте RFC 959 и его реализации в сервере proftpd. Для каждого состояния сервера FTP выделено отдельное состояние автомата второго рода. Переходы между состояниями соответствуют переходам сервера FTP в соответствии со спецификацией протокола. При этом в каждом состоянии обнаруживаются нелегальные переходы, которые вызывают порождение нового процесса и исполнение в нём произвольного кода (fork() и exec()).

Это позволяет обнаруживать любые атаки класса «remote root» для сервера proftpd, включая ранее неизвестные.

3.5. Алгоритмы обнаружения атак Алгоритм обнаружения атак сводится к формированию последовательности наблюдаемых состояний РИС и поиску в этой последовательности траекторий атак и отклонений от нормального поведения:

1. Для каждого защищаемого объекта r формируем множество автоматов первого рода K r = {K ri } (каждый автомат в этом множестве моделирует атаку некоторого класса i) и автомат второго рода N r.

2. Пусть от наблюдателя поступил некоторый символ a.

a. Определяем, к какому множеству действий принадлежит данный b. Определяем подмножество автоматов, которые могут принять данный c. Подаём символ а на вход каждому автомату из выбранного 3. Для каждого автомата из выбранного подмножества вычисляем предикаты перехода из текущего состояния по символу a и предикат «истина» и предикат перехода «истина», и тип перехода consuming, выполняем переход. Если переход имеет тип nonconsuming, порождаем новый экземпляр автомата и выполняем переход в новом экземпляре. При этом старый экземпляр автомата остаётся в предыдущем состоянии. Если тип перехода unwinding, то выполняется переход в итоговое состояние и уничтожаются все экземпляры автомата, порождённые в этом состоянии ранее.

4. Если итоговое состояние автомата является конечным, выполняем действия, определенные для конечного состояния (формируем сообщение об атаке), и уничтожаем данный экземпляр автомата, если он не единственный, иначе возвращаем его в начальное состояние.

Атака на защищаемый объект r будет обнаружена при одновременном выполнении следующих условий:

1. Траектория атаки принадлежит одному из классов, распознаваемых множеством автоматов первого рода K r = {K ri }, либо не принадлежит нормальному поведению объектов данного типа Bh(type(r)) – это является требованием корректности построения автомата второго рода N r ;

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

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

В следующем разделе приведено описание экспериментальной системы обнаружения атак, реализующей предложенный метод обнаружения для сетей TCP/IP/Ethernet и операционных систем семейства Linux с ядром версии 2.6.х и Windows 2000/XP.

- 40 ЭКСПЕРИМЕНТАЛЬНАЯ СИСТЕМА ОБНАРУЖЕНИЯ АТАК

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

Напомним требования к «идеальной» СОА, изложенные в разделе 2:

• покрывает все классы атак (система полна);

• позволяет анализировать поведение защищаемой РИС на всех уровнях:

сетевом, узловом и уровне отдельных приложений;

• адаптивна к неизвестным атакам (использует адаптивный метод • масштабируется для РИС различных классов: от небольших локальных сетей класса «домашний офис» до крупных многосегментных и коммутированных корпоративных сетей, обеспечивая возможность централизованного управления всеми компонентами СОА;

• имеет встроенные механизмы реагирования на атаки;

• является защищённой от атак на компоненты СОА, в том числе перехвата управления или атаки «отказ в обслуживании».

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

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

4.1. Архитектура и алгоритмы работы системы обнаружения атак На Рис. 5. представлена схема системы обнаружения атак с управляющими связями и связями по передаче сообщений.

В состав СОА входят следующие модули:

сенсор Назначение и состав компонентов СОА:

Сетевой сенсор Сетевой сенсор предназначен для анализа поведения сетевых объектов на основе данных сетевого трафика и сообщений от узловых сенсоров.

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

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

Подсистема реагирования также состоит из наблюдателя, который получает сообщения об атаках и формирует трассу событий, ядра анализа (СПВП + автоматы) и служебной подсистемы. Автоматы реагирования формируют политику реагирования: в конечном состоянии каждого автомата выполняется заданная процедура реагирования.

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

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

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

Узловой сенсор состоит из наблюдателя, который формирует трассу событий, ядра анализа, которое получает поток событий от наблюдателя, и служебной подсистемы, которая отвечает за управление и взаимодействие между компонентами СОА.

На выход узловой сенсор выдаёт сообщения об обнаруженных аномалиях или злоупотреблениях в формате IDMEF. Сообщения пересылаются сетевому сенсору, имеющему соединение с узловым сенсором.

База данных База данных (БД) СОА представляет собой распределенное хранилище описаний нормального и аномального поведения объектов РИС, сообщений об атаках и журнала компонентов СОА. Данное хранилище используется сетевыми и узловыми сенсорами для централизованной загрузки автоматов в СПВП и хранения сообщений об атаках.

База данных построена на основе открытой СУБД PostgreSQL.

Консоль управления Консоль управления представляет собой графическое приложение управления СОА, в задачи которого входит:

• отображение физической и логической структуры СОА и защищаемой РИС;

• управление и настройка компонентов СОА;

• оповещение оператора о событиях безопасности в режиме рального времени (визуальные и звуковые эффекты);

• корреляция сообщений об атаках;

• централизованное реагирование;

• визуализация сообщений об атаках и журнала компонентов.

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

• агент для ОС Windows со встроенными возможностями пакетного фильтра и блокирования процессов на узле.

4.1.1. Структура и алгоритмы работы сетевого сенсора В состав сетевого сенсора СОА входят следующие программные модули:

модуль анализа сетевых данных;

лексический и синтаксический анализатор языка описания сценариев;

система поддержки выполнения программ (СПВП);

набор сценариев (автоматы первого и второго рода);

модуль внешнего управления.

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

Рис. 6. Структура сетевого сенсора и связи с другими компонентами.

Модуль сбора сетевых данных Модуль сбора сетевой информации осуществляет захват всех входящих и исходящих пакетов с сетевого интерфейса на уровне IP стека TCP/IP. Реализация модуля под ОС Linux выполняет функции захвата через механизм сокетов типа AF_PACKET.

Перед началом работы интерфейс (сетевой адаптер Ethernet) переводится в режим “promiscuous mode”, позволяющий просматривать все пакеты, видимые в данном сегменте сети, независимо от их получателя и отправителя.

Из всей реализации сетевого сенсора СОА текст программы для инициализации сетевого интерфейса наименее переносим. Однако, для ОС Linux платформеннозависимая часть программы незначительна. Примерный код инициализации сетевого интерфейса следующий:

int sock = socket ( AF_PACKET, SOCK_RAW, htons(ETH_P_ALL) );

struct ifreq ifr;

memset ( &ifr, 0, sizeof(ifr) );

strncpy ( ifr.ifr_name, ifName, sizeof(ifr.ifr_name) );

if ( ioctl ( sock, SIOCGIFINDEX, &ifr ) < 0 ) { memset ( &saddr, 0, sizeof(saddr) );

saddr.sll_family = AF_PACKET;

saddr.sll_protocol = htons(ETH_P_ALL);

saddr.sll_ifindex = ifr.ifr_ifindex;

memset ( &mreq, 0, sizeof(mreq) );

mreq.mr_ifindex = ifr.ifr_ifindex;

mreq.mr_type = PACKET_MR_PROMISC;

if ( setsockopt ( sock, SOL_PACKET, PACKET_ADD_MEMBERSHIP, &mreq, sizeof(mreq) ) < В целях повышения надежности системы сбора сетевой информации, то есть для избежания возможной потери пакетов при интенсивной загрузке процессора, применяется буферизация пакетов. После получения пакет либо передается модулю анализа сетевой информации, либо, если модуль анализа не готов принять пакет, буферизуется для дальнейшего анализа.

При передаче полученного пакета модулю анализа пакет анализируется на предмет соответствия его структуры пакетам известных протоколов стека TCP/IP;

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

Модуль анализа сетевых данных Модуль получает пакеты от модуля сбора сетевых данных и анализирует их с помощью сценариев, написанных на языке описания сценариев. Каждый сетевой пакет преобразуется в структуру типа NetEvent и передается соответствующему сценарию, либо множеству сценариев. Для выполнения сценариев используется система поддержки выполнения программ. Заключение об обнаружении атаки дается в результате выполнения сценария. В этом случае он вызывает функцию Alert(), которая реализована в библиотеке сетевого сенсора.

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

• IPMatch(event.src_ip,CONST1,CONST2) • event.src_ip==CONST • event.src_port == CONST • IPMatch(event.dst_ip,CONST1,CONST2) • event.dst_ip==CONST • event.dst_port==CONST, то происходит предварительное отсечение сценариев, заведомо не действующих для данного события. Отсечение происходит с помощью двух хэш-таблиц для пары (src_ip,src_port) и пары (dst_ip,dst_port)..

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

Каждый сценарий из набора сценариев представляет собой реализацию автомата первого или второго рода в соотвествии с моделью. Подробная спецификация языка изложена в приложении 1. Здесь же приведём краткое описание сценария и переходов для понимания алгоритмов работы сенсоров СОА.

Определение сценария:

'scenario' '(' ')' '{' Список аргументов в неявном виде задает класс событий, обрабатываемых сценарием. Типы структур, передаваемые в сценарий, сигнализируют о поддерживаемых сценарием событиях. Все аргументы, соответственно, должны быть структурами, унаследованными от структуры Event.

В теле сценария могут быть определены (как и в структуре) переменные и методы.

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

Декларация состояния:

['initial'] 'state' '{' Имя состояния является идентификатором, уникальным в пределах состояния.

Логическое выражение определяет условие перехода в состояние (исключение:

начальное состояние в момент создания копии сценария - в этом случае логическое выражение не вычисляется). Оператор выполняется при переходе в состояние.

Ключевое слово initial говорит о том, что состояние является начальным для сценария. В случае если ни для одного состояния не применено ключевое слово initial, начальным состоянием является первое состояние сценария.

Сценарий должен содержать хотя бы одно состояние.

Декларация перехода:

'transition' [] '(' '->' ')' [‘consuming’|’nonconsuming’|’unwinding’] ‘{‘ Если предикат имеет значение «ложь» или не определён, дальнейших проверок не происходит. Осуществляется проверка предиката состояния. Если он истинен, выполняется оператор, осуществляется переход и выполняется оператор, определенный в теле состояния.

Различаются следующие типы переходов:

• consuming – не создается новой копии контекста выполнения (все выполняется в текущей копии);

• nonconsuming – создается новая копия контекста выполнения, переход осуществляется в ней;

• unwinding – удаляются все контексты выполнения, порожденные данным контекстом выполнения с помощью переходов типа nonconsuming.

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

Промежуточное представление программного модуля представляет собой набор следующих данных:

• список импортируемых функций; т.е. функций, внешних по отношению к данному программному модулю (ПМ). Для каждой функции указывается ее имя;

• список экспортируемых функций и методов; т.е. функций, определяемых внутри ПМ как доступных на вызов из других ПМ (глобальных функций). Формируется таблица имен функций;

• список сценариев, содержащихся в данном ПМ. Для каждого сценария дается список его состояний, список переходов, код для каждой из функций перехода, тип перехода;

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

Имена идентификаторов в таком дереве отсутствуют (исключение:

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

СПВП Система поддержки выполнения программ обеспечивает подготовку набора сценариев к выполнению, а также взаимодействие сценариев между собой и с внешней средой. Она организована в виде библиотеки языка C++ и обеспечивает:

• компиляцию из временного представления в машинный код (для архитектуры • сопоставление импортируемых и экспортируемых функций в нескольких ПМ;

• добавление внешних функций, написанных на C++ и доступных по вызову из • поддержку размещения в памяти контекста выполнения сценария;

• поддержку размещения в памяти контекста выполнения ПМ (глобальных переменных, определенных в ПМ);

• поддержку встроенных функций языка;

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

Сценарии или экспортируемые функции ПМ вызываются как обычные функции C++ (т.к. они откомпилированы в машинный код).

Внешние функции, написанные на языке программирования C++, также вызываются из сценариев способом, неотличимым от вызова из программы на C++. Их представления сценариев.

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

СПВП оперирует таблицей символов: итеративно наращиваемой в процессе обработки программных модулей ассоциативной таблицей - привязывающей имя объекта к его описанию или физическому адресу в памяти.

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

Программный интерфейс СПВП предоставляет возможность ее обновления.

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

Этап 1 - подготовка: установление внешних связей с другими модулями.

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

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

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

Этап 2 – примитивизация операций.

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

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

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

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

Этап 3 – выработка псевдокода.

Третий этап является основным в процессе подготовки программы к выполнению. Во время него синтаксическое дерево преобразуется в последовательность низкоуровневых команд с ветвлением на уровне if/goto.

Этап преобразует сложные структурные операторы if, for, while в форму, близкую к машинному коду. Логические выражения с детерминированным порядком вычисления (т.е. содержащие операции && или ||) также подлежат преобразованию в форму if/goto.

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

ассоциируются с соответствующими им низкоуровневыми командами; эта информация сохраняется в отдельной таблице.

Этап 4 – оптимизация псевдокода.

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

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

Этап 5 – компиляция в машинный код.

Псевдокод преобразуется в машинный код в два прохода.

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

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

В зависимости от операционной системы используются различные схемы аллокации временных регистров (т.к. различные операционные системы имеют различные соглашения о вызовах системных функций).

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

Этап 6 – обновление таблицы символов.

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

В дальнейшем, другие модули могут использовать экспортируемые имена как внешние функции (методы, сценарии и т.п.).

Этап 7 – обновление конечного автомата быстрого поиска подстрок и шаблонов.

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

Строки и шаблоны для поиска берутся из выходных данных синтаксического анализатора языка. Для того, чтобы строка попала в таблицу для поиска, она должна присутствовать в вызове функций FastFind/FastMatch и быть константой.

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

Этап 8 – создание неявных конструкторов для структур.

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

Этап 9 – оптимизация конечного автомата поиска подстрок и шаблонов.

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

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

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

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

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

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

В состав узлового сенсора СОА входят следующие программные модули:

система поддержки выполнения программ (СПВП);

набор сценариев (автоматы первого и второго рода);

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

Рис. 7. Структура узлового сенсора и связи с другими компонентами.

Провайдеры узловых событий В состав узлового сенсора экспериментальной СОА входят следующие провайдеры событий:

• подсистема сбора сетевых данных;

• драйвер узловых событий;

• драйвер событий аппаратуры.

Подсистема сбора сетевых данных организована для ОС Linux аналогично подсистеме сетевого сенсора. Для ОС Windows используется драйвер перехвата сетевых данных.

Драйвер узловых событий позволяет отслеживать следующие классы событий:

1. Файловая система (создание, открытие, закрытие, изменение файлов и т.д.);

2. Процессы (запуск и завершение процессов);

3. Реестр (только для ОС Windows: создание, удаление и изменение ключей 4. Сокеты (создание сокетов, прослушивание, чтение и отправка данных через 5. Стандартные журналы (только для ОС Windows: события системы и Модуль анализа событий и прочие модули узлового сенсора реализованы аналогично сетевому сенсору.

4.1.3. Структура и алгоритмы работы подсистемы реагирования Подсистема реагирования является иерархической и состоит из компонентов трёх типов: узловых менеджеров, центральных менеджеров и агентов. Узловой менеджер является подсистемой реагирования сетевого сенсора. Центральный менеджер реагирования является подсистемой реагирования консоли управления.

выполняет функции управления и настройки данного средства.

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

• система анализа событий;

• модуль внешнего управления.

Структура менеджера реагирования представлена на рис. 8.

Рис. 8. Структура менеджера реагирования Провайдер событий От сетевых сенсоров менеджер получает сообщения в формате IDMEF. По полученному сообщению провайдер событий формирует событие и передаёт его системе анализа событий для анализа и формирования реакции.

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

Пример сценария реагирования:

scenario HIGHSeverityResponse ( NetworkAlertEvent netEv) initial state state0{} consuming transition state0->state + Iptoa(netEv.sourceAddress) + “ –reject-type icmp-host-unreachable”);

high (высший по стандарту IDMEF) формируется блокирующее правило для межсетевого экрана IPTables и отправляется соответствующему агенту реагирования.

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

4.1.4. Структура и алгоритмы работы консоли управления В данном разделе приведено описание графической консоли управления экспериментальной СОА. Консоль управления является инструментом администратора системы обнаружения атак.

Консоль управления решает следующие задачи:

• отображение физической и логической структуры СОА и защищаемой РИС;

• управление и настройка компонентов СОА;

• оповещение оператора о событиях безопасности в режиме реального времени (визуальные и звуковые эффекты);

• корреляция сообщений об атаках;

• централизованное реагирование;

• визуализация сообщений об атаках и журнала компонентов.

Графический интерфейс консоли управления состоит из нескольких окон.

Большинство функций консоли управления доступны через следующие окна:

• окно настройки и управления компонентом СОА;

• окно настройки консоли управления.

При запуске консоли управления запускается основное окно. Основное окно всегда содержит меню, панель инструментов и строку состояния.

В зависимости от режимов работы и настроек в основном окне дополнительно могут быть:

• дерево доступных компонентов СОА;

• индикатор текущего объекта сети;

• индикатор текущего компонента СОА;

• текстовые консоли управления.

Основными компонентами главного окна можно назвать редактор схем и текстовую консоль управления.

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

Графическое представление структуры СОА Графическое представление структуры СОА – схема, на которой изображены объекты сети и СОА и связи между ними. Есть два режима графического представления: режим физических соединений и режим логических соединений.

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

С объектами сети типа «узел» могут быть связаны компоненты системы обнаружения атак. У каждого компонента сети есть «уточняющий тип». Пример уточняющего типа объекта сети: «Рабочее место администратора».

У объекта сети есть два изображения: краткое и полное. Краткое изображение служит для графического обозначения класса объекта в дереве компонентов и индикаторе объекта сети и состоит из маленькой иконки. Полное изображение представляет собой изображение объекта на схеме сети и состоит из большой иконки и дополнительных деталей. Дополнительные детали – это подписи и индикаторы.

Подписи отображают значения параметров объекта и его компонентов.

объекта сети. Индикаторы используются для визуализации работы СОА. Каждому компоненту может соответствовать несколько индикаторов. Индикаторы отображают состояние компонента. Индикатор изображается как «светодиод».

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

В режиме логических связей графическое представление содержит граф логических связей компонентов СОА. По аналогии с объектом в режиме физических соединений, в режиме логических соединений компонент СОА является базовым элементом графического представления.

У компонента СОА есть тип. Возможные типы компонентов:

• Менеджер реагирования;

Компонент изображается иконкой, возможно окруженной подписями со значениями параметров.

Сеть изображается практически так же, как в режиме физических соединений.

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

Рис. 10 Режим логических соединений Графическое представление РИС можно редактировать и просматривать при помощи редактора схем. Самая простая функция редактора схем – поставить на схему новый объект сети. Другая функция – соединить два объекта ребром. Соединить две вершины можно с помощью правой кнопки мыши.

Редактор схем используется для настройки и управления компонентами СОА.

Если в контекстном меню выбрать пункт «Компонент...», то появится окно настройки и управления компонентом СОА. Из этого окна, нажимая на соответствующие кнопки, можно запускать и останавливать компонент, можно менять его настройки и режимы работы.

Другим средством управления СОА является текстовая консоль. Текстовая консоль позволяет в командном режиме настраивать и управлять компонентами системы.

Текстовая консоль может быть подключена к какому-либо компоненту системы.

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

Рис. 11. Текстовая консоль.

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

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

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

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

администратор увидит окно с сообщением, подтверждающим создание файла.

Рис. 12. Окно журнала консоли управления.

Язык текстовой консоли В текстовой консоли языка управления используется алгоритмический язык Ruby. Текстовая консоль представляет собой интерпретатор этого языка. Для удобства работы администратора, все команды управления реализованы как функции языка Ruby, что упрощает синтаксис команд.

4.1.5. Организация иерархического хранилища данных База данных экспериментальной СОА представляет собой двухзвенную иерархическую структуру. Каждый узел БД может быть либо листовым, либо корневым, при этом допускается только один корневой узел. Выполняется следующее свойство: все записи листовых узлов БД содержатся в корневом узле во все моменты времени, задаваемые при настройке БД. Таким образом, иерархия узлов хранилища обеспечивает двукратную избыточность информации для всех вершин, кроме корневой вершины.

БД хранит два типа записей: сценарии описания атак для сенсоров и сообщения от компонентов системы.

Записи сценариев имеют следующие поля:

• name – имя (например, название файла сценария);

• IP – ip адрес узла, сенсор которого работает с данным сценарием;

• data – двоичный код сценария, готовый к загрузке в сенсор.

Ключом записи является пара (name, IP).

Записи сообщений от компонентов имеют следующие поля:

• time – время наступления события;

• IP – ip адрес, от которого пришло событие;

• event_type - тип наступившего события (сообщение об атаке, либо сообщение о работе компонента);

• severity – важность события;

• xml – описание события в xml-формате.

Ключом записи является тройка (time, component_id, IP).

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

• вставить сценарий (name, IP, data);

• удалить все сценарии с данным именем name;

• удалить все сценарии для данного узла IP;

• удалить конкретный сценарий (name, IP);

• получить все сценарии с данным именем name;

• получить все сценарии для данного узла IP;

• получить конкретный сценарий (name, IP).

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

• вставить сообщение (time, component_id, IP, event_type, severity, xml);

• удалить все сообщения от данного компонента component_id;

• удалить все сообщения с данного узла IP;

• удалить все сообщения, наступившие до time;

• получить все сообщения от данного компонента component_id;

• получить все сообщения с данного узла IP;

• получить все сообщения, наступившие до time;

• получить все сообщения, наступившие в период (time1, time2).

В качестве СУБД используется PostgreSQL версии 7.4 и выше.

4.2. Выводы по архитектуре На основе приведенного описания архитектуры и алгоритмов работы экспериментальной СОА можно провести её сравнение с рассмотренными в обзоре открытыми СОА по заданным критериям.

Экспериментальная СОА, как системы Prelude и NetSTAT, является гибридной, т.е. способна обнаруживать атаки на уровне системы, сети и приложений.

СОА обнаруживает атаки следующих классов: (L,R,A,D), где:

• L={li le} (внутренние и внешние атаки);

• R={rl rn} {ru rs rp} (атаки на локальные или сетевые пользовательские ресурсы, системные ресурсы и ресурсы защиты);

• A={as au ar ad} (сбор информации о системе, попытки получения прав пользователя, попытки получения прав администратора и нарушение работоспособности ресурса);

• D={dn au } (нераспределенные и распределенные).

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

По данному критерию экспериментальная СОА наблюдает за поведением сетевых объектов на всех уровнях: сетевом, системном и прикладном - что являлось одной из целей разработки данной системы.

Экспериментальная СОА использует гибридный метод обнаружения атак, основанный на использовании метода анализа переходов состояний как для обнаружения реализаций атак, так и для обнаружения аномалий поведения объектов РИС. Данный метод обладает свойством адаптивности, что позволяет использовать систему для обнаружения модифицированных и неизвестных атак на защищаемые объекты РИС. При этом вычислительная сложность метода находится в линейной зависимости от длины трассы анализируемых событий: состояний объектов РИС и их действий. В ней так же сохраняются свойства верифицируемости и устойчивости, присущие сигнатурным методам. Таким образом, достигнута одна из основных целей данной работы, которая и заключалась в создании адаптивного метода обнаружения атак с вычислительной сложностью, сравнимой со сложностью сигнатурных методов.

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

Разработанная СОА является линейно масштабируемой: добавление нового анализируемого узла или канала передачи данных требует включения в конфигурацию системы одного соответствующего компонента – сетевого или узлового сенсора.

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

Экспериментальная СОА является открытой системой, имеет открытый интерфейс расширения набора сценариев и API системы прогона, который позволяет добавлять новые типы событий стандартным образом. Обмен сообщениями происходит по стандарту IDMEF (Intrusion Detection Message Exchange Format), что позволяет встраивать компоненты системы или систему целиком в сторонние системы защиты, а также интегрировать модули сторонних разработчиков, поддерживающие данный формат.

По данному критерию экспериментальная СОА соответствует возможностям системы Prelude.

В состав экспериментальной СОА входит распределенная система реагирования с возможностью задания политики реагирования в виде набора сценариев. Открытый интерфейс агентов реагирования, набор реализованных агентов реагирования для распространённых межсетевых экранов. Кроме того, модули реагирования системы имеют встроенную систему прогона сценариев и позволяют анализировать сообщения об атаках в качестве обычных событий сценариев СОА, что, в свою очередь, позволяет выполнять в данных модулях дополнительный сложный анализ событий. Например, устанавливать взаимосвязь между событиями и атаками на разных уровнях: сетевом, узловом и уровне приложений. Такой возможностью не обладает ни одна из систем, рассмотренных в разделе 2.

Экспериментальная СОА использует шифрованные каналы передачи данных и управления на основе модифицированного протокола SSHv2, интегрированного с инфраструктурой публичных ключей (PKI) по стандарту X.509.

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

5. ИССЛЕДОВАНИЕ ЭФФЕКТИВНОСТИ ЭКСПЕРИМЕНТАЛЬНОЙ СОА

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

Так как цель тестирования – проверка эффективности обнаружения атак с помощью гибридного метода анализа переходов состояний, то для тестирования выбран ограниченный набор атакуемых ресурсов и реализаций атак. В качестве атакуемых ресурсов были использованы несколько версий сервера FTP ProFTPd, вебсервер Apache и сервер SSH openssh.

Автомат описания нормального поведения был построен для семейства FTPсерверов ProFTPd. Описание данного автомата приведено ниже в описании тестовых сценариев обнаружения. Для остальных ресурсов были построены описания атак для конкретных реализаций атак из тестового набора. Их описание также см. ниже.

5.1. Набор тестовых примеров В набор тестовых примеров включены реализации атак из открытых источников, которые были выбраны из набора примерно в 30 различных реализаций по принципу работоспособности «из коробки» - данные атаки успешно выполнялись для целевого сервиса без дополнительной настройки или доработки. Для реализации атаки класса «сканирование» был использован распространённый сканер безопасности nmap. Ниже приведен список использованных в испытаниях реализаций атак:

1. Атака на уязвимость переполнения буфера в FTP-сервере ProFTPd версий proftpd 1.2.7 и 1.2.8 с двумя разными наборами вредоносных команд (shellcode):

proftp_put_down.c, proftp_put_down2.c;

2. Атака на уязвимость переполнения буфера в FTP-сервере ProFTPd версий proftpd 1.2.0pre3, propro, babcia;

3. Атака на web-сервер Apache версий 1.3.x, использующая уязвимость в обработке кодированных цепочками (chunk-encoded) HTTP-запросов;

4. Атака blackjack.c, позволяющая получить привилегированный доступ (remote root) через SSH-сервер ОС RedHat Linux 8.0 с настройками по-умолчанию;

5. Атака на Microsoft Windows DCOM, позволяющая получить удалённый cmdсеанс с правами администратора на ОС Windows XP без SP2;

6. Атака Apache squ1rt на web-сервер Apache версий 2.0.х, использующая утечку памяти для переполнения памяти сервера и реализации атаки «отказ в обслуживании»;

7. Сканирование привилегированных портов с помощью утилиты nmap.

5.2. Тестовые сценарии обнаружения В данном разделе описан набор тестовых сценариев для исследования эффективности экспериментальной СОА. Наибольший интерес представляет сценарий, реализующий автомат второго рода для FTP-сервера ProFTPd, т.к. он является примером использования предложенного метода для обнаружения неизвестных атак.

соответствии с RFC 959 и множества системных вызовов ядра ОС Linux версии 2.4. Из множества всех системных вызовов в целях оптимизации рассматриваются лишь четыре, которые могут быть потенциально опасны в контексте выполнения proftpd:

fork(), vfork(), execve() и socketcall().

На основе анализа исходных текстов и трасс системных вызовов сервера proftpd был сделан вывод, что данные системные вызовы в нём используются в следующих ситуациях:

• после создания управляющего канала используется fork, создаётся поток для • после выполнения пользователем команды PASV для передачи данных в пассивном режиме сервер создаёт слушающий сокет, используя системный вызов socketcall с параметром SYS_LISTEN;

• также есть 6 команд (STOR, STOU, RETR, LIST, NLST, APPE), после которых, согласно протоколу, устанавливается канал данных. При этом используются системные вызовы socketcall с параметром SYS_CONNECT.

На основе спецификации протокола FTP и полученной информации о реализации строится сценарий нормального поведения сервера proftpd.

Напомним, что автомат второго рода представляет собой структуру следующего вида:

S – множество состояний;

PS – множество предикатов состояний;

T – функция переходов;

PT – множество предикатов переходов;

s0 – начальное состояние;

I – множество экземпляров автомата;

g – глобальное окружение;

q – глобальная очередь таймера.

I, g и q отражают контекст выполнения сценария в заданном окружении в каждый момент времени.

Для нашей модели сервера proftpd множество состояний S = {statepre, state0, login, welcome, waitPASS, sendPASS, sendUSER, sendSITEHELP, wait221, wait214SITE, wait150, sendPORT, sendPASV, waitans, waitanslog}, начальное состояние s0=statepre.

Входной алфавит – множество команд FTP, ответы сервера FTP, состояния TCPсоединения и перечисленный выше набор системных вызовов: {"CWD", "EPRT", "XRMD", "APPE", "XCWD", "EPSV", "MKD", "REST", "CDUP", "ALLO", "XMKD", "TYPE", "ABOR", "XCUP", "RNFR", "PWD", "STRU", "SMNT", "RNTO", "XPWD", "MODE", "DELE", "SIZE", "RETR", "PORT", "MDTM", "STOR", "PASV", "RMD", "STOU", "LIST", "SITE", "NOOP", "SYST", "OPTS", "SIZE", "MDTM", "SYST", "PWD", "TYPE", "CDUP", "FEAT", "OPTS", "CWD", "REST", "MODE", "PASS", "USER", "MKD", "RMD", TCP_CONNECT, TCP_RST, TCP_FIN, TCP_ESTABLISHED, SYS_FORK, SYS_CONNECT, SYS_LISTEN, SYS_EXEC, SYS_VFORK}.

На рис. 13 схематически представлена статическая диаграмма состояний данного сценария.

ALERT ALERT

ALERT ALERT ALERT

Рис. 13. Диаграмма состояний автомата второго рода для ProFTPd.

Сценарий нормального поведения ProFTPd в ходе испытаний функционировал в составе сетевого сенсора экспериментальной СОА, установленного на один узел с Кроме данного сценария были построены сценарии, реализующие автоматы первого рода для каждой из используемых атак. Данные сценарии функционировали в составе сетевых и узловых сенсоров на всех узлах испытательного стенда.

В следующем разделе приведено описание стенда и схема размещения компонентов экспериментальной СОА на его узлах.

5.3. Состав и структура инструментального стенда Операционная система: Debian GNULinux 3.1 Sarge и Stackware Linux.

attacker Рис. 14. Структура инструментального стенда.

Размещение компонентов экспериментальной СОА на узлах стенда:

• узел console: консоль управления СОА и база данных;

• узел sensor1: сетевой сенсор и база данных;

• узел sensor2: сетевой сенсор и база данных;

• узел www: сетевой сенсор и база данных;

• узел ftp: сетевой сенсор и база данных;

Подсистема реагирования на сетевых сенсорах и консоли управления настроена на автоматическую блокировку IP-адреса нарушителя на 10 минут.

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

5.3.1. Сетевая инфраструктура При построении стенда использован коммутатор Cisco Catalyst 2950.

Пропускная способность каждого канала составляет 100Мбит/с.

5.3.2. Серверные узлы Для имитации служебной части защищаемой сети использованы серверы HTTP (www) и FTP (ftp), подключенные к коммутатору с помощью 100-мегабитного сетевого интерфейса.

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

Использованы следующие прикладные сервисы:

• HTTP: Apache 2.0.x, Apache 1.2.x;

5.3.3. Рабочие станции Для имитации рабочих станций защищаемой части стенда использованы узлы с уязвимыми версиями ОС Windows 2000/XP. Использованы следующие уязвимые сервисы:

• Встроенный сервис Windows RPC.

5.3.4. Атакующие узлы Атакующие узлы attacker1 и attacker2 функционируют под управлением ОС Debian Linux. Каждый атакующий узел подключен к сети с помощью 100Мбитного сетевого интерфейса. На атакующих узлах используется одинаковый набор тестовых примеров.

5.4. Порядок испытаний Испытания проводились в два этапа:

1. Имитация нормального сетевого взаимодействия между узлами attacker1,2 и сетевыми сервисами на защищаемых узлах www, ftp, win1,2. Имитация выполняется с помощью следующих стандартных - rdesktop для Windows-машин (с включённой службой удаленного доступа);

2. Проведение атак на фоне имитации нормального сетевого взаимодействия с узлов attacker1,2 на узлы www, ftp, win1,2.

На первом этапе проводилась передача файлов со случайными бинарными данными с узлов www, ftp на узлы attacker1,2 по соответствующим протоколам в цикле.

Было использовано 10 файлов со случайными данными суммарным объёмом 10Гб.

Данный этап предназначен для оценки уровня ложных срабатываний экспериментальной СОА.

На втором этапе атаки проводились на фоне тех же примеров нормального поведения. Атаки проводились с паузой между последовательными тестами в 10 минут (время, необходимое на разблокирование узла на межсетевом экране).

В ходе проведения атак замерялись (вычислялись) следующие параметры:

Результаты испытаний приведены в следующем разделе.

5.5. Результаты испытаний После проведения двух этапов испытаний получены следующие результаты (таблица 4):

Таблица 4. Результаты испытаний экспериментальной СОА.

Число сообщений об атаках во всех тестах превышает число проведённых атак, что в общем случае понижает информативность СОА для оператора, хотя и не влияет на эффективность обнаружения атак. В данном случае повышенное количество сообщений об атаках объясняется избыточностью схемы размещения компонентов СОА: узлы sensor1 и sensor2 являлись «транзитными» для всего сетевого трафика между атакующими узлами и защищаемыми узлами сети.

Доля ложных срабатываний для обнаружения сканирования ресурсов составила 2% - из-за недостаточно точно определенного порога срабатывания сценария обнаружения сканирования. В реальных сетях с открытыми в Интернет сервисами уровень ложных срабатываний в 2% является неприемлемо высоким, поэтом для таких сетей необходима настройка порога срабатывания сценария. Ложные срабатывания наблюдались для сессий нормального трафика, что в условиях реальной РИС недопустимо, если все сообщения об атаках вызывают автоматическую блокировку узла-нарушителя. Таким образом, настройка политики реагирования для защищаемой сети является существенной задачей, но подробное рассмотрение данной проблемы выходит за рамки данной работы.

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

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

В описанных тестах загрузка центрального процессора на сетевых сенсорах, на которые приходилась максимальная вычислительная нагрузка по анализу сетевого трафика, не превышала 30%. При этом пиковая пропускная способность составляла 12Мб/сек при получении файлов по протоколу HTTP. Следует отметить, что вычислительная сложность анализатора с увеличением числа сценариев растёт пропорционально и, при большом числе сценариев, время на обработку сетевого трафика может превысить возможности вычислителя. Данная проблема может быть решена разными способами: распараллеливание, построение обобщённого сценария и его минимизация, либо простое уменьшение количества сценариев за счёт выбора только тех, которые анализируют поведение реально существующих объектов сети.

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

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

6. ЗАКЛЮЧЕНИЕ Основные результаты работы заключаются в следующем:

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

Предложен гибридный метод обнаружения атак на основе метода анализа систем переходов, позволяющий обнаруживать неизвестные атаки как отклонения наблюдаемого поведения сетевых объектов от нормального;

На основе предложенных методов реализована система обнаружения атак для ОС Linux и Windows 2000/XP. Данная экспериментальня система показала высокую эффективность обнаружения на испытательном стенде.

Экспериментально показана адаптивность системы к неизвестным атакам.

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

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

1. Ahmed Awad E. Ahmed, Issa Traore, “Anomaly Intrusion Detection based on Biometrics.” // Proceedings of the 2005 IEEE, Workshop on Information Assurance, United States Military Academy, West Point, NY June 2. Abraham A. and Thomas J., Distributed Intrusion Detection Systems: A Computational Intelligence Approach. // Applications of Information Systems to Homeland Security and Defense, Abbass H.A. and Essam D. (Eds.), Idea Group Inc. Publishers, USA, 3. D Anderson, T Frivold, and A Valdes, “Next-generation intrusion-detection +ert system (NIDES)”. // Technical Report SRI-CSL-95-07, Computer Science Laboratory, SRI International, Menlo Park, CA 94025-3493, USA, 4. Debra Anderson, Teresa F. Lunt, Harold Javitz, Ann Tamaru, and Alfonso Valdes, “Detecting unusual program behavior using the statistical component of the next generation intrusion detection system (NIDES)”. // Technical Report SRI-CSL-95-06, Computer Science Laboratory, SRI International, 5. J.P. Anderson, “Computer Security Threat Monitoring and Surveillance.” // J.P. Anderson Co, Fort Washington, PA, April 6. Amoroso, Edward, G., Intrusion Detection // 1st ed., Intrusion.Net Books, Sparta, New Jersey, USA, 7. Stefan Axelsson, “Research in Intrusion-Detection Systems: A Survey” // Department of Computer Engineering, Chalmers University of Technology, Goteborg, Sweden, 8. Stefan Axelsson, “Intrusion detection systems: A survey and taxonomy.” // Technical Report 99-15, Chalmers Univ., March 9. Bace R. An Introduction to Intrusion Detection Assessment for System and Network Security Management. // 10. Jai Balasubramaniyan, Jose Omar Garcia-Fernandez, E. H. Spafford, Diego Zamboni, “An Architecture for Intrusion Detection using Autonomous Agents”. // Department of Computer Sciences, Purdue University; Coast TR 11. A. Baur & W. Weiss, “Audit Analysis Tool for Systems with High Demands Regarding Security and Access Control.” // Research Report, ZFE F2 SOF 42, Siemens Nixdorf Software, Mnchen, November 12. M. Blanc, L. Oudot, and V. Glaume, "Global Intrusion Detection: Prelude Hybrid IDS." // Technical Report, 13. Damiano Bolzoni, Sandro Etalle, “APHRODITE: an Anomaly-based Architecture for False Positive Reduction” // University of Twente, The Netherlands, Arxiv preprint cs.CR/0604026, 14. Damiano Bolzoni, Emmanuele Zambon, Sandro Etalle, Pieter Hartel, “Poseidon: A 2-tier anomaly-based intrusion detection system.” // Technical report, Centre for Telematics and Information Technology, Univ. of Twente, The Netherlands. November 15. J.M. Bradshaw, An introduction to software agents // J.M. Bradshaw (Ed.), Software Agents, AAA1 Press/MIT Press, Cambridge, MA, 1997, pp. 3- 16. Kalle Burbeck, “Adaptive Real-time Anomaly Detection for Safeguarding Critical Networks.” // Department of Computer and Information Science, Linkpings universitet, Linkping, Sweden, Linkping, 17. Gabriela F. Cretu, Janak J. Parekh, Ke Wang, Salvatore J. Stolfo, “Intrusion and Anomaly Detection Model Exchange for Mobile Ad-Hoc Networks.” // 18. Herve Debar, Marc Dacier, and Andreas Wespi, “Towards a Taxonomy of Intrusion Detection Systems.” // Computer Networks, vol. 31, pp. 805-822, 19. Christian Charras, Thierry Lecroq, Exact String Matching Algorithms, [http://www-igm.univ-mlv.fr/~lecroq/string/index.html], 20. S. Stani ford Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K Levitt, C. Wee, R. Yip, and D. Zerkle, “GrIDS—A graph based intrusion detection system for large networks.” // In Proceedings of the 19th National Information Systems Security Conference, 21. S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K. Levitt, J. Rowe, S. Staniford-Chen, R. Yip, D. Zerkle, The design of GrIDS: a graph-based intrusion detection system. // Technical Report CSE-99-2, Department of Computer Science, University of California at Davis, Davis, CA, January 22. Chung, M., Puketza, N., Olsson, R.A., & Mukherjee, B. (1995) Simulating Concurrent Intrusions for Testing Intrusion Detection Systems:

Parallelizing. // NISSC. pp. 173-183.

23. M. Crosbie, E. Spafford, Defending a computer system using autonomous agents. // Technical Report 95-022, COAST Laboratory, Department of Computer Sciences, Purdue University, West Lafayette, IN 47907-1398, 24. M. Crosbie, E. Spafford, Defending a computer system using autonomous agents. // Proceedings of the 18th National Information Systems Security Conference, October 1995.

25. M. Crosbie, G. Spafford, Active defense of a computer system using autonomous agents. // Technical Report 95-008, COAST Group, Department of Computer Sciences, Purdue University, West Lafayette, IN 47907-1398, February 1995.

26. Mark Crosbie, Bryn Dole, Todd Ellis, Ivan Krsul, and Eugene Spafford, “IDIOT— Users Guide.” // The COAST Project, Dept. of Computer Science, Purdue University, West Lafayette, IN, USA, 4 September 27. W Cui, R. Katz, and W. Tan. “BINDER: An Extrusion- Based Break-In Detector for Personal Computers.” // Proc. USENIX Annual Technical Conference, 28. Dasgupta D., Gonzalez F., K. Yallapu, Gomez, J., Yarramsettii, R., Dunlap, G. and Greveas, M., “CIDS: An Agent-based Intrusion Detection System.” // CS Technical Report No. CS-02-001., Feb, 29. Vaibhav Gowadia, Csilla Farkas, Marco Valtorta, “PAID: A Probabilistic Agent-Based Intrusion Detection system.” // Computers & Security, 30. Herve Debar, Monique Becker, and Didier Siboni, “A neural network component for an intrusion detection system.” // Proceedings of the IEEE Computer Sociecty Symposium on Research in Security and Privacy, pages 240–250, Oakland, CA, USA, May 31. Denault, M., Gritzalis, D., Karagiannis, D., and Spirakis, P. (1994). Intrusion Detection: Approach and Performance Issues of the SECURENET System. // Computers and Security Vol. 13, No. 6, pp. 495-507.

32. Denning, Dorothy. An Intrusion-Detection Model. // IEEE Transactions on Software Engineering, Vol. SE-13, No. 2., Proceedings of the 13th National Computer Security Conference, pages 99– 108, Washington DC, USA, October 34. S.T. Eckmann, G. Vigna, and R. A. Kemmerer. “STATL: An Attack Language for State-based Intrusion Detection”. // Dept. of Computer Science, University of California, Santa Barbara, 2000.

35. W.M. Farmer, J.D. Guttman, V. Swarup, Security for mobile agents: issues and requirements. // Proceedings of the 19th National Information Sytems Security Conference, vol. 2, National Institute of Standards and Technology, October 1996.

36. Debora Frincke, Don Tobin, Jesse McConell, A framework for cooperative intrusion detection. // Dept. of Computer Science, University of Idaho, 37. Ian Goldberg, David Wagner, Randi Thomans, and Eric Brewer, “A secure environment for untrusted helper applications (confining the wily hacker).” // Proceedings of the Sixth USENIX UNIX Security Symposium, San Jose, California, USA, July 38. R. Gopalakrishna, E. H. Spafford, and J. Vitek, “Efficient Intrusion Detection Automaton Inlining.” // Proc. IEEE Symp. on Security & Privacy, Oakland, 39. Vladimir I. Gorodetski, Igor V. Kotenko. “Attacks Against Computer Network: Formal Grammar-Based Framework and Simulation Tool”. // St.

Petersburg Institute for Informatics and Automation, RAID 2002: 219- 40. Noria Foukia, “IDReAM: Intrusion Detection and Response executed with Agent Mobility Architecture and Implementation.” // Proceedings of the fourth international joint conference on Autonomous agents and multiagent systems, the Netherlands, 41. Jani Habra, Baudouin Le Charlier, Abdelaziz Mounji, and Isabelle Mathieu, “ASAX: Software architecture and rule-based language for universal audit trail analysis.” // In Yves Deswarte et al., editors, Computer Security – Proceedings of ESORICS 92, volume 648 of LNCS, pages 435–450, Toulouse, France, 23–25 November 42. J. Habra, B. Le Charlier, A. Mounji & I. Mathieu, “Preliminary Report on Advanced Security Audit Trail Analysis on UniX” // Research Report 1/92, Institut d’Informatique, University of Namur, January 1992.

43. N. Habra, B. Le Charlier, A. Mounji, Advanced Security Audit Trail Analysis on uniX. Implementation Design of the NADF Evaluator. // Research Report, Computer Science Institute, University of Namur, Belgium, March 1993.

44. Hatch, Brian, LIDS overview, 2001, [http://www.lids.org/] 45. R. Heady, G. Luger, A. Maccabe, M. Servilla, The architecture of a network level intrusion detection system. // Technical Report, University of New Mexico, Department of Computer Science, August 1990.

46. Todd Heberlein, Gihan Dias, Karl Levitt, Biswanath Mukherjee, Jeff Wood, and David Wolber, “A network security monitor”. // Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 296–304. IEEE, IEEE Comput. Soc. Press, Los Alamitos, CA, USA, 47. Helman, P., Liepins, G., and Richards, W. Foundations of Intrusion Detection.

// Proceedings of the Fifth Computer Security Foundations Workshop pp.

114-120. 48. Y. Ho, Partial order state transition analysis for an intrusion detection system. // Master’s thesis, University of Idaho, 1997.

DuBois, and Josehpine Ford. NADIR: An automated system for detecting network intrusion and misuse. // Computers & Security, 12(3):235–248, 50. S.A. Hofmeyr, An immunological model of distributed detection and its application to computer security. // Ph.D. thesis, University of New Mexico, 51. Koral Ilgun, “USTAT: A real-time intrusion detection system for UNIX”. // In Proceedings of the 1993 IEEE Symposium on Security and Privacy, pages 16–28, Oakland, California, 24–26 May 1993, 52. Koral Ilgun, Richard A Kemmerer, and Phillip A Porras, “State transition analysis: A rule-based intrusion detection approach”. // IEEE Transactions on Software Engineering, 21(3):181–199, March 53. Kathleen A Jackson, David H DuBois, and Cathy A Stallings, “An +ert system application for network intrusion detection.” // Proceedings of the 14th National Computer Security Conference, pages 215–225,Washington, D.C., 1–4 October 54. Rasool Jalili, Fatemeh Imani-Mehr, Morteza Amini, Hamid Reza Shahriari, “Detection of Distributed Denial of Service Attacks Using Statistical PreProcessor and Unsupervised Neural Networks.” // Lecture notes in computer science, 55. Y. Frank Jou, Fengmin Gong, Chandru Sargor, Shyhtsun FelixWu, and CleavelandW Rance, “Architecture design of a scalable intrusion detection system for the emerging network infrastructure.” // Technical Report CDRL A005, Dept. of Computer Science, North Carolina State University, Releigh, N.C, USA, April 56. Minna Kangasluoma, Policy Specification Languages, Department of Computer Science, Helsinki University of Technology, 1999, [http://www.nixu.fi/~minna/draft2.html] 57. Calvin Ko, “Execution Monitoring of Security-critical Programs in a Distributed System: A Specification-based Approach.” // PhD thesis, Department of Computer Science, University of California at Davis, USA, 58. Calvin Ko, George Fink, and Karl Levitt, “Automated detection of vulnerabilities in privileged programs by execution monitoring.” // Proceedings of the 10th Annual Computer Security Applications Conference, volume xiii, pages 134–144. IEEE, IEEE Computer Society Press, Los Alamitos, CA, USA, 59. Christopher Kruegel, Giovanni Vigna, William Robertson, “A multi-model approach to the detection of web-based attacks.” // Computer Networks 48, 717–738, 60. Sandeep Kumar and Eugene H. Spafford, “A pattern matching model for misuse intrusion detection.” // Proceedings of the 17th National Computer Security Conference, pages 11–21, Baltimore MD, USA, 61. Sandeep Kumar and Eugene H. Spafford, “An application of pattern matching in intrusion detection.” // Technical Report CSD-TR-94-013, The COAST Project, Dept. of Computer Sciences, Purdue University, West Lafayette, IN, 62. Sandeep Kumar and Eugene H. Spafford, “A software architecture to support misuse intrusion detection.” // Technical report, The COAST Project, Dept. of Comp. Sciences, Purdue Univ.,West Lafayette, IN, 47907–1398, USA, PhD thesis, Purdue University, West Lafayette, Indiana, August 1995.

64. Hkan Kvarnstrm, “A survey of commercial tools for intrusion detection”. // Technical Report 99-8, Department of Computer Engineering, Chalmers University of Technology, Gteborg, Sweden, 65. Tao Li, Xiaojie Liu, and Hongbin Li “A New Model for Dynamic Intrusion Detection.” // lecture notes in computer science, 66. Lionel Litty, “Hypervisor-based Intrusion Detection.” // Graduate Department of Computer Science, University of Toronto, 67. W Lu, I Traore, “A new unsupervised anomaly detection framework for detecting network attacks in real-time.” // Department of Electrical and Computer Engineering, University of Victoria, Lecture notes in computer science, 68. Lunt, T.F. Real-Time Intrusion Detection. // Computer Security Journal Vol.

VI, Number 1. pp. 9-14., 69. T.F. Lunt, “Automated Audit Trail Analysis and Intrusion Detection: A Survey.” // Proceedings of the 11th National Security Conference, Baltimore, MD, October 1988.

70. Teresa F. Lunt, Ann Tamaru, Fred Gilham, R. Jagannathan, Caveh Jalali, and Peter G. Neuman, “A real-time intrusion-detection +ert system (IDES).” // Technical Report Project 6784, CSL, SRI International, Computer Science Laboratory, SRI Intl. 333 Ravenswood Ave., Menlo Park, CA 94925-3493, USA, February 71. Bharath Madhusudan, John W. Lockwood, “A HARDWAREACCELERATED SYSTEM FOR REAL-TIME WORM DETECTION.” // Micro, IEEE, 72. Masayoshi Mizutani, Shin Shirahata, Masaki Minami, Jun Murai, “The Design and Implementation of Session Based NIDS.” // IEICO. pages 551-562, Mar 73. A. Mounji, Languages and Tools for Rule-Based Distributed Intrusion Detection. // PhD Thesis, Computer Science Institute, University of Namur, Belgium, Sept 1997.

74. A. Mounji, B. Le Charlier, D. Zampuniris, N. Habra, Preliminary Report on Distributed ASAX. // Research Report, Computer Science Institute, University of Namur, Belgium, May 75. Mukherjee, B., Heberlein, L.T., Levitt, K.N. (May/June, 1994). Network Intrusion Detection. // IEEE Network. pp. 28-42.

76. Srinivas Mukkamala, Andrew H. Sung, Ajith Abraham, “Intrusion detection using an ensemble of intelligent paradigms.” // Journal of Network and Computer Applications, 77. Daniel C. Nash, An Intrusion Detection System for Battery Exhaustion Attacks on Mobile Computers. // Blacksburg, Virginia, 78. Daniel C. Nash, Thomas L. Martin, Dong S. Ha, and Michael S. Hsiao, “Towards an Intrusion Detection System for Battery Exhaustion Attacks on Mobile Computing Devices.” // Proceedings of the Third IEEE International Conference on Pervasive Computing and Communications Workshops, 79. Ozturk Ahmet, OSSEC-HIDS Capabilities, Architecture and plans. // Presentation at the 5th Linux and Free Software Festival, Ankara, Turkey, 80. Vern Paxon, “Bro: A system for detecting network intruders in real-time.” // In Proceedings of the 7th USENIX Security Symposium, San Antonio, TX, USA, January Computer Networks, 31(23-24), pp. 2435-2463, 14 Dec. 82. Phillip A Porras and Alfonso Valdes, “Live traffic analysis of TCP/IP gateways.” // Proceedings of the 1998 ISOC Symposium on Network and Distributed Systems Security, San Diego, California, 11–13 March 83. Philip A Porras and Peter G Neumann, “EMERALD: Event monitoring enabling responses to anomalous live disturbances.” // Proceedings of the 20th National Information Systems Security Conference, pages 353–365, Baltimore, Maryland, USA, 7–10 October 84. Porras, P. A., Ilgun, K., and Kemmerer, R. A. (1995). State transition analysis:

A rule-based intrusion detection approach. // IEEE Transactions on Software Engineering,SE-21: 181–199.

85. T.H. Ptacek, T.N. Newsham, Insertion, evasion, and denial of service: eluding network intrusion detection. // Technical Report, Secure Networks, January 86. Puketza, N., Chung, M., Olsson, R.A. & Mukherjee, B. (September/October, 1997). A Software Platform for Testing Intrusion Detection Systems. // IEEE Software, Vol. 14, No. 87. Guangzhi Qu, Salim Hariri, Mazin Yousif “Multivariate Statistical Analysis for Network Attacks Detection.” // Computer Systems and Applications, 88. Marcus J. Ranum, Experiences Benchmarking Intrusion Detection Systems, [http://www.snort.org/docs/Benchmarking-IDS-NFR.pdf] 89. Roesch, Martin, Snort Users Manual, Snort Release: 2.4, 2007, [http://www.snort.org/] 90. Sebring, M., Shellhouse, E., Hanna, M. & Whitehurst, R. Expert Systems in Intrusion Detection: A Case Study. // Proceedings of the 11th National Computer Security Conference, 91. Mohammed Shahidul Alam “APHIDS++: Evolution of A Programmable Hybrid Intrusion Detection System.” // The University Of British Columbia, Vancouver, Canada, 92. S.R. Snapp, J. Brentano, G.V. Dias, T.L. Goan, L.T. Heberlein, C. Lin Ho, K.N. Levitt, B. Mukherjee, S.E. Smaha, T. Grance, D.M. Teal, D. Mansur, DIDS (distributed intrusion detection system) ± motivation, architecture, and an early prototype. // Proceedings of the 14th National Computer Security Conference, Washington, DC, October 1991.

93. Sheyner, Oleg “Scenario Graphs and Attack Graphs.” // PhD thesis, SCS, Carnegie Mellon University, 2004.

94. S. Smaha, “Haystack: an intrusion detection system” // 4th Aerospace Computer Security Applications Conf., pp. 37–44. October 95. Eugene H. Spafford, Diego Zamboni, Intrusion detection using autonomous agents. // Computer Networks, 34(4):547-570, October 2000.

96. Steven R Snapp, Stephen E Smaha, Daniel M Teal, and Tim Grance, “DIDS (Distributed Intrusion Detection System) Motivation, Architecture, and An Early Prototype.” // Proceedings of the Summer USENIX Conference, pages 227–233, San Antonio, Texas, 8–12 June 97. Eugene H. Spafford, Diego Zamboni, Intrusion detection using autonomous agents. // Computer Networks, 34(4):547-570, October 2000.

98. Mukkamala Srinivas, Sung Andrew H, Abraham Ajith, Ramos Vitorino.

“Intrusion detection systems using adaptive regression splines.” // Seruca I, Filipe J, Hammoudi S, Cordeiro J, editors. Sixth international conference on enterprise information systems. ICEIS’04, Portugal, vol. 3. Chandrasekhar, “A System for Power-aware Agent-based Intrusion Detection (SPAID) in Wireless Ad Hoc Network.” // Lecture notes in computer science, 100. Staniford-Chen, S. Using Thumbprints to Trace Intruders. // UC Davis, 101. S. Staniford-Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K. Levitt, C. Wee, R. Yip, D. Zerkle, GrIDS: a graph based intrusion detection system for large networks. // Proceedings of the 19th National Information Systems Security Conference, vol. 1, National Institute of Standards and Technology, October 1996.

102. Teng, H. S., Chen, K., and Lu, S. C. Adaptive real-time anomaly detection using inductively generated sequential patterns. // Proceedings of the IEEE Symposium on Research in Computer Security and Privacy, 278–284, 103. “Trusted Computer System Evaluation Criteria”, The Orange Book, Department of Defense, NCSC, National Computer Security Centre, DoD 5200.28-STD, December 1985.

104. G. Vigna, R. Kemmerer, "NetSTAT: A Network-based Intrusion Detection Approach." // Proceedings of the 14th Annual Computer Security Application Conference, Scottsdale, Arizona, December 1998.

105. G. Vigna, R.A. Kemmerer, "NetSTAT: A Network-based Intrusion Detection System." // Journal of Computer Security, 7(1), IOS Press, 1999.

106. R.A. Whitehurst, “Expert Systems in Intrusion Detection: A Case Study.” // Computer Science Laboratory, SRI International, Menlo Park, CA, November 107. Yoann Vandoorselaere, Laurent Oudot, “Prelude, an Hybrid Open Source Intrusion Detection System”, [http://www.prelude-ids.org/] 108. M.P.Zielinski, “Applying Mobile Agents in an Immune-system-based intrusion detection system.” // University of South Africa, 109. ГОСТ Р 50922-96: Защита информации. Основные термины и определения. // Госстандарт России, Москва, 1996г.

110. Гамаюнов Д. Ю., Смелянский Р. Л., Модель поведения сетевых объектов «Программирование», 2007, №4.

111. Р.Л. Смелянский, Д. Ю. Гамаюнов. “Современные некоммерческие средства обнаружения атак”. // Факультет Вычислительной Математики и Кибернетики, МГУ им. М. В. Ломоносова, Москва, 2002 г.

112. Р.Л. Смелянский, А.И. Качалин. “Применения нейросетей для обнаружения аномального поведения объектов в компьютерных сетях”. // Факультет Вычислительной Математики и Кибернетики, МГУ им. М. В. Ломоносова, Москва, 2004.

113. Тараканов А.О. Математические модели обработки информации на основе результатов самосборки. // Диссертация д.ф.-м.н., С.-П., 1999.

- 74 ПРИЛОЖЕНИЕ: ЯЗЫК ОПИСАНИЯ ПОВЕДЕНИЯ СЕТЕВЫХ

ОБЪЕКТОВ

7.1. Язык описания поведения объектов РИС Язык описания поведения (ЯОП) синтаксически похож на язык STATL, основой которого, в свою очередь, является язык программирования C++. По сравнению с языком STATL, данный язык расширяется за счет логических предикатов состояний и переходов.

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

Из препроцессора языка "C" взяты следующие конструкции.

Директивы включения файлов:

#include "filename" #include Директивы семантически не отличаются. Файл с именем filename включается в текущий компилируемый исходный файл.

Директива создания символических констант:

#define A B Далее по тексту идентификатор A является синонимом строки B.

Директивы компиляции по условию:

#ifdef A/#else/#endif #ifndef A/#else/#endif Условием включения фрагмента файла в компилируемый исходный файл является наличие или отсутствие определения идентификатора A директивой #define.

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

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

7.3.1. Комментарии Комментарии выделяют либо парой '/*'..'*/' (вложенные комментарии не допускаются), либо парой '//'... Разрешено вложение двух вышеозначенных типов комментариев друг в друга, т.е. конструкции типа:

// комментарий /* комментарий 2 */ /* комментарий // комментарий 2 */ 7.3.2. Константы Целочисленные константы не могут занимать более четырех байт в двоичном представлении. Представление идентично принятому в языке "C".

Десятичная форма: возможно задание знака '+' или '-' (можно опустить), далее число. Число не может начинаться с нуля, иначе оно трактуется как восьмеричное.

шестнадцатеричных цифр (из набора 0-9,a-f,A-F).

Восьмеричная форма: символ '0', далее число в восьмеричном представлении.

Примеры:

Таблица. 5. Примеры целочисленных констант языка.

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

Кодирование специальных символов:

\n,\r,\t - символы перевода строки (код 10), возврата каретки (код 13), табуляции (код 9);

\ - код символа в восьмеричном виде. В частности, \0 нулевой символ;

\x - код символа в шестнадцатеричном виде;

\ - символ, расположенный после слеша (символа \). В частности, полезны комбинации \',\",\\.

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

Примеры:

Таблица 6. Примеры строковых констант.

7.3.2.4. Булевы константы Тип данных bool определяет только два значения: true и false.

7.3.3. Символы операций Символы операций представлены в таблице 7 в порядке убывания приоритета.

Операции, не разделенные линией, имеют одинаковый приоритет. Ассоциативность определяет трактовку выражений вида “a op b op c”. Если в третьей колонке указано «слева направо», такие выражения следует вычислять как “(a op b) op c”. «Справа налево» изменяет порядок вычисления на “a op (b op c)”.