Разработка и анализ эффективности средств отражения распределенных атак (стр. 8 из 13)

Рис. 4.3 Эмпирическое распределение времени возврата ICMP ответа.

На рис. 4.3 изображено эмпирическое распределение времени возврата ICMP ответов. По оси абсцисс отложены временные интервалы, полученные разбиением всего диапазона значений с шагом 10 мс. По оси ординат отложено количество значений, попавших в интервал.

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

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

4.2 Определение вероятности потери пакетов

Для определения вероятности

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

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

Список пингуемых хостов был получен путем обработки html страницы, сгенерированной proxy сервером. Эта страница представляет собой месячный отчет о доступе автора в internet. В связи с этим ответы на ICMP запросы отправленные на некоторые хосты получены не были. Это объясняется тем, что эти хосты могут находится за межсетевым экраном, фильтрующим пакеты протокола ICMP. Поэтому при определении количества потерянных пакетов учитывались только те хосты, от которых приходил хоть один ICMP ответ.

4.3 Определение интенсивности входящего потока требований

В качестве предложений для определения этого параметра можно выделить:

· Анализ логов какого либо сниффера. Например Ethereal, tcpdump, IDS Snort, работающей в режиме сниффера.

· Написание собственного ПО

Соответствующее ПО разработано моим коллегой [22].

В этом разделе приведены возможные подходы к определению фактических значений исходных параметров рассмотренной выше модели для защищаемой системы находящейся в нормальном состоянии (при условии отсутствия атаки). Как отмечалось выше, такими параметрами являются интенсивность потока заявок (TCP пакетов с установленным SYN флагом), вероятность потери пакетов в сети, к которой подключен сервер и среднее время обслуживания заявки (успешного установления TCP соединения). Имея фактические значения этих параметров с помощью соотношений приведенных в разделе 3 можно определить допустимое пороговое значение для количества "просроченных" полуоткрытых соединений, которое будет использовано ниже.

Одним из важных этапов исследований является программная реализация предлагаемой методики противодействия TCP SYN атаке, особенности которой рассмотрены ниже.

5. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ

Было принято решение реализовать предложенную методику обнаружения TCPSYN атаки в качестве модуля расширения функциональности (plug-in) для системы обнаружения вторжений IDSSnort. В качестве достоинств Snort, которые определили этот выбор можно отметить легко расширяемую архитектуру, открытость исходного кода. Так же стоит упомянуть, что эта система способна работать на большом количестве аппаратных платформ и ОС.

Т.к. в реальности простого обнаружения атаки недостаточно для бесперебойной работы системы, то помимо обнаружения система должна обеспечивать отражение атаки. Поэтому модуль расширения функциональности разрабатывался для модификации системы Snort – IPSSnort_inline. Это система предотвращения вторжений, которая способна модифицировать пакеты в реальном режиме времени, по мере того как они поступают в сеть и/или покидают ее. Такие системы так же называются системами "с активным ответом". Для того, чтобы IPS могла контролировать весь трафик, поступающий и исходящий из сети, она должна располагаться на inline устройстве. Поэтому в предложенной реализации Snort_inline работает на Linux-системе, функционирующей в режиме маршрутизатора.

5.1 Особенности установки Snort

Как было сказано выше, целевая система для разрабатываемого модуля – это Snort_inline. Однако ее установка и настройка занятие, отнимающее много сил и времени. Поэтому на начальных этапах разработка велась на системе Snort, в то время как мой коллега занимался исследованием возможностей snort_inline [22].

Для того чтобы поставить Snort на Linux машину необходимо, предварительно установить некоторые библиотеки:

· libpcap – библиотека работающая на канальном уровне. Используется системой Snort. С помощью нее snort получает доступ ко всем пакетам поступающим на сетевой интерфейс.

· libpcre – библиотека для работы с регулярными выражениями (regularexpressions)

· libipq – используется системой Snort_inline вместо библиотеки libpcap. Это библиотека организации очередей пакетов, которую предоставляет IPtables

Для непосредственной установки системы необходимо ввести стандартные команды:

/configure

make

makeinstall

Стоит отметить, что на этапе разработки следует вызвать скрипт ./configure с опцией –enable-debug.

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

/snort –crules.txt

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

5.2 Внутренняя структура Snort

Система Snort имеет гибкую архитектуру, представленную в виде множества подключаемых модулей. Подключаемые модули бывают трех типов:

- препроцессоры

- модули обнаружения

- модули вывода

5.2.1 Препроцессоры

Препроцессоры Snort бывают двух типов. Первый тип предназначен для обнаружения подозрительной активности, а второй тип предназначен для модификации пакетов протоколов высоких уровней (чем канальный) для последующей их обработки процессором обнаружения. Этот процесс называется нормализацией трафика. Он позволяет обнаруживать атаки, которые манипулируют внешним видом трафика для большей скрытности. Существует много препроцессоров snort, которые можно подключить или отключить, внеся соответствующие изменения в файл конфигурации. Исходные коды препроцессоров находятся в директории ./src/preprocessors. Здесь приведены только некоторые из них:

· portscan (2) – предназначен для обнаружения сканирования портов

· http_inspect – предназначен для контроля http трафика

· stream4 – предназначен для контроля за TCP сессиями

· arpspoof – предназначен для обнаружения атак arp-spoofing

· bo – предназначен для обнаружения активности BackOrifice

· frag2 – предназначен для сборки фрагментированных пакетов

· RPC-decode - декодирование RPC-трафика;

· Telnet_decode - декодирование трафика telnet-сессий;

· ASN1_decode - выявление аномалий в строках формата ASN1;

· и т.д.

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

5.2.2 Модули обнаружения

Модули обнаружения используются непосредственно для анализа обработанного препроцессорами трафика. Если этот модуль определяет, что пакет удовлетворяет указанному правилу, то он генерирует событие, которое дальше передается модулям вывода Snort. Именно в виде модуля обнаружения реализована методика обнаружения TCPSYN атаки, поэтому его структура будет подробно описана ниже.

5.2.3 Модули вывода

Модули вывода используются Snort для записи событий безопасности, ведения логов и т.д. в различные устройства и хранилища данных. Возможно настроить систему на ведение логов в отдельную базу данных, двоичные и текстовые файлы различных форматов. Возможны даже такие экзотические варианты, как уведомления администратора по e-mail или SMS. Исходные коды этих модулей находятся в директории ./src/output-plugins Вот некоторые модули вывода:

· alert_syslog – вывод в формате syslog

· log_tcpdump – вывод в формате tcpdump

· output_database – выводвБД. Возможны mysql, postgresql, oracle, odbc, mssql(толькодля Snort под Windows)

· csv – выводвформате CSV ( coma separated values)

· и т.д.

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

5.3 Разработка модуля обнаружения

В корневой директории Snort есть директория templates, в которой находятся шаблоны модулей вывода и обнаружения. Рассмотрим шаблон модуля обнаружения, представленный двумя файлами:

· sp_template.h – заголовочный файл модуля

· sp_template.c – файл реализации модуля

В заголовочном файле должно присутствовать объявление setup функции, которая отвечает за инициализацию модуля. Для того чтобы Snort знал, что необходимо проинициализировать данный модуль необходимо добавить вызов этой функции в функцию InitPlugIns(), реализация которой находится в файле ./src/plugbase.c. При этом, конечно, надо не забыть указать компилятору с помощью директивы #include в каком именно файле она определена.

Применительно к нашему модулю, который называется tcp_syn_flood необходимо сделать следующее:

1. создать в директории ./src/detection-plugins/ два файла:

· sp_tcp_syn_flood.h

· sp_tcp_syn_flood.с

2. вфайл sp_tcp_syn_flood.h добавитьобъявлениефункцииSetupTcpSynFlood(), авфайл sp_tcp_syn_flood.с ее реализацию:

void SetupTcpSynFlood()

{

/* регистрируеммодуль */

RegisterPlugin("tcp_syn_flood", TcpSynFloodInit);

DEBUG_WRAP(DebugMessage(DEBUG_PLUGIN,"Plugin: TcpSynFlood Setup\n"););