Дипломная работа: Разработка и анализ эффективности средств отражения распределенных атак

typedef struct _TimeCheckerTreeNodeData

{

ubi_trNode Node;

// Номер acknowledgement последовательности (для Syn+Ack и Ack пакетов)

u_int32_t SeqAckNumber;

}

TChTreeNodeData;

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

Как видно из приведенного фрагмента кода в структуре объявлены два поля:

·  Node – узел бинарного дерева. Это поле должно идти первым в объявлении структуры. Это обусловлено оптимизацией во внутренней реализацией бинарных деревьев Snort

·  SeqAckNumber – значение последовательности Acknowledgement в SYN+ACK пакетах исходящих от защищаемого сервера.

При получении данным модулем SYN+ACK пакета исходящего от защищаемого сервера в дерево, имеющее нулевое смещение в массиве помещается соответствующий элемент. Этот элемент соответствует полуоткрытому на сервере соединению.

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

Размерность массива деревьев определяется при инициализации модуля в функции InitTcpConnEstTimeChecker как:

int rootNodesCount = ceil(serverTimeout / _checkPeriod);

При такой организации внутренних структур данных "возраст" полуоткрытых соединений, которым соответствуют узлы в i-м дереве массива определяется как (_checkPeriod * i) . Узлы самого правого в массиве дерева, которые при сдвиге удаляются соответствуют полуоткрытым на защищаемом сервере соединениям для которых истек таймаут отведенный на установку соединений и они закрываются автоматически.

При получении модулем ACK пакета, предназначенного серверу, производится поиск узла дерева, соответствующего полуоткрытому соединению. Поиск производится по ключу (Acknowledge number ACK пакета – 1). После того как узел найден, он удаляется из дерева, что соответствует закрытию полуоткрытого соединения на сервере.

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

// the index of the first node with overdued connections

checker->firstOverduedNodeIndex = checker->overdueTime / checker->checkPeriod;

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

Описанный выше модуль в программной реализации представлен в виде следующей структуры и функций работы с ним:

typedef struct _TcpConnEstTimeChecker

{

/*** Опции правила ***/

// time in seconds after which the half-open connection is overdue

int overdueTime;

// period in seconds to check the number of overdue half-open connections

int checkPeriod;

// the max allowed number of half-open connections

int overdueUpperBound;

// the diviation of overdueUpperBound

int overdueUpperBoundDiviation;

/*** Внутренние данные ***/

// the number of root nodes in the array

int rootNodesCount;

// the array of root nodes

ubi_btRoot* rootNodes;

// the index of the first node, which contains overdued connections

int firstOverduedNodeIndex;

// time when the last shift was made

time_t lastShiftTime;

// Indicates if Syn Flood atack presents

int atackState;

}

TcpConnEstTimeChecker;

/***Интерфейс***/

void InitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker, int _overdueTime,

int _checkPeriod, int _overdueUpperBound, int _overdueUpperBoundDiviation,

int _serverTimeout);

void DeInitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker);

int TcpConnEstTimeChecker_ProcessPacket(TcpConnEstTimeChecker* checker, Packet* p, int packetType);

int ShiftRootNodes(TcpConnEstTimeChecker* checker, int GenerationCount);

5.3.2 Структура модуля TcpSynFloodPreventionModule

Как упоминалось в разделе 2, на данный момент общедоступные методы противодействия TCP SYN атаке не отличаются эффективностью и обоснованностью выбора значений конкретных параметров при настройке системы. Т.к. на данный момент авторами не разработана модель, позволяющая построить математически обоснованную методику противодействия атаке, то было принято решение реализовать эту функциональность без соответствующей базы. При этом одним из требований к разработке является возможность работы с модулем посредством определенного интерфейса, не зависящего от конкретной реализации. Такое требование в дальнейшем позволит легко подключать различные (более эффективные) реализации. В объектно-ориентированных языках такой подход обычно реализуется соответствующими механизмами (наследование, интерфейсы и т.д.), однако язык С, на котором написан сам Snort таких возможностей не предоставляет. Поэтому приведение к единому интерфейсу реализовано по аналогии с бинарными деревьями Snort, в виде макроопределений, которые используются для работы с модулем. Такой подход затрудняет разработку и отладку приложения, но приводит к большему быстродействию конечного продукта.

Для реализации этого интерфейса модули предотвращения должны реализовывать три функции:

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

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

·  Функция обработки пакета. В конкретной реализации эта функция при условии отсутствия TCP SYN атаки занимается ведением положительной статистики. В условиях присутствия атаки обновление статистики приостанавливается, а данная функция принимает решение о том пропускать ли этот пакет дальше или нет.

В текущей реализации статистика "положительных клиентов" ведется по учету количества успешно установленных TCP соединений с конкретного IP адреса, от которого пакеты приходят с определенным значением TTL. Учет значения TTL затрудняет возможному злоумышленнику имитацию "положительного" клиента. Например, злоумышленник знает, что у администратора системы определенный IP. В этом случае для введения системы предотвращения атаки в заблуждения он может генерировать множество TCP SYN пакетов, указывая в качестве адреса отправителя известный ему IP адрес. Если же система так же учитывает значение TTL, то злоумышленнику для успешной имитации так же необходимо знать количество маршрутизаторов находящихся между защищаемым сервером и машиной администратора.

Реализация этого модуля так же основана на использовании бинарных деревьев Snort. Внутренняя структура данных модуля имеет вид:

интернет атака программный snort

typedef struct _TcpSynFloodPreventionModule

{

// корень дерева со статистикой

ubi_btRootPtr rootStat;

long totalPacketsCount;

} TcpSynFloodPreventionModule;

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

Следующая структура представляет собой данные, которые хранятся в узлах дерева:

typedef struct _TcpSynFloodPreventionStatTreeNodeData

{

// узел дерева

ubi_trNode Node;

// Поля идентифицирующие клиента

u_int8_t ttl;

struct in_addr ipSrc;

// Количество пакетов удовлетворяющих условию. TTL=ttl and IPSrc=ipSrc

long counter;

} TcpSynFloodPreventionStatTreeNodeData;

Эта структура содержит следующие поля:

·  Node – структура представляющая узел бинарного дерева Snort. Это поле должно быть первым в объявлении, т.к. это обусловлено оптимизацией во внутренней реализации деревьев.

·  ttl – значение TTL для узла

·  ipSrc – значение IP адреса клиента

·  counter – количество обработанных ACK пакетов, пришедших о клиента с IP адресом ipSrc и значением TTL=ttl.

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

currNodeData->counter > (module->totalPacketsCount / ubi_trCount(module->rootStat));

5.3.3 Взаимодействие TcpConnEstTimeChecker и TcpSynFloodPreventionModule в реализации tcp_syn_flood

Для дальнейшего описания реализации следует привести структуру, в которой хранится внутреннее состояние tcp_syn_flood:

typedef struct _TcpSynFloodData

{

// текущий режим работы

int workingMode;

// IP адрес защищаемого сервера

struct in_addr serverIP;

// указатель на модуль TcpConnEstTimeChecker

TcpConnEstTimeChecker* timeChecker;

// указатель на модуль TcpSynFloodPreventionModulePtr

TcpSynFloodPreventionModulePtr preventionModule;

} TcpSynFloodData;

Как видно из объявления кроме знакомых нам TcpConnEstTimeChecker и TcpSynFloodPreventionModulePtr здесь присутствует переменная workingMode, которая хранит текущее состояние. Она может принимать следующие значения, определенные в файле sp_tcp_syn_flood.h:

/*** Режимы работы модуля ***/

#define TCP_SYN_FLOOD_DETECTION1

#define TCP_SYN_FLOOD_PREVENTION2

Очевидно, что работа каждого из модулей начинается с инициализации, которая происходит при инициализации tcp_syn_flood. Как было показано выше, за инициализацию модуля отвечает функция TcpSynFloodInit. Внутри нее происходит вызов функции TcpSynFloodRuleParseFunction, которая производит анализ параметров, указанных в правиле. Считается, что во время запуска Snort TCP SYN атака отсутствует и переменной workingMode присваивается значение TCP_SYN_FLOOD_DETECTION.

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

/*** Поддерживаемые типы пакетов ***/

#define PACKET_TYPE_UNSUPPORTED 0

#define PACKET_TYPE_SYN_ACK 1

#define PACKET_TYPE_ACK 2

#define PACKET_TYPE_RST_FROM_SERVER 3

#define PACKET_TYPE_RST_FROM_CLIENT 4

#define PACKET_TYPE_SYN 5

Как видно из приведенного выше фрагмента на внутреннее состояние модуля влияют пришедшие от клиента пакеты с установленными комбинациями флагов SYN, ACK и RST, а от защищаемого сервера – SYN+ACK и RST. Различия между RST пакетами введены для того, чтобы корректно уменьшать количество полуоткрытых соединений. Следующий фрагмент кода демонстрирует это:

switch(packetType){

case PACKET_TYPE_ACK:

findNodeData->SeqAckNumber = p->tcph->th_ack-1;

break;

case PACKET_TYPE_RST_FROM_SERVER:

findNodeData->SeqAckNumber = p->tcph->th_ack-1;

break;

case PACKET_TYPE_SYN_ACK:

findNodeData->SeqAckNumber = p->tcph->th_seq-1;

break;

}

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

/*** Состояния атаки ***/

#define SYN_ATACK_IS_NOT_PRESENT 1

#define SYN_ATACK_IS_PRESENT 2

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

if(checkerResult == SYN_ATACK_IS_PRESENT){

// Если атака только началась

if(tcpSynFloodData->workingMode == TCP_SYN_FLOOD_DETECTION){

// Генерируем сообщение 'Atack Started'

GenerateSnortEvent(NULL, GENERATOR_TCP_SYN_FLOOD, 0,0,0,3,SYNFLOOD_STARTED);

//изменяем режим

tcpSynFloodData->workingMode = TCP_SYN_FLOOD_PREVENTION;

}

}

else{

// Если атака только закончилась

if(tcpSynFloodData->workingMode == TCP_SYN_FLOOD_PREVENTION){

// генерируем сообщение "ATACK FINISHED"

GenerateSnortEvent(NULL, GENERATOR_TCP_SYN_FLOOD, 0,0,0,3,SYNFLOOD_FINISHED);

//изменяем режим

tcpSynFloodData->workingMode = TCP_SYN_FLOOD_DETECTION;

}

}

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

if(preventionResult == PREVENTION_PACKET_IS_BAD){

if(InlineMode()){

InlineDrop();

}

}

Как видно из приведенного фрагмента в случае "плохого" пакета осуществляется проверка того, в каком режиме работает Snort. Если в режиме inline, то доступен метод InlineDrop, который говорит Snort о том, что этот пакет пропускать нельзя. В качестве дальнейшего развития этого модуля возможна реализация активного ответа для Snort работающего в режиме простого обнаружения. В качестве такого активного ответа может быть рассылка серверу и клиенту RST пакетов для закрытия этого соединения.

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

#tcp_syn_flood:

# [0] - ip_server

# [1] - server_timeout_sec

# [2] - max_overdue_count

# [3] - max_overdue_count_diviation

# [4] - overdue_time_sec

# [5] - check_period_sec

pass tcp any any <> any any (tcp_syn_flood:172.20.24.20, 60, 10, 2, 5, 1;)

Конкретное значение параметра max_overdue_count можно определить с помощью соотношения (3.14) . Для этого сначала с помощью специальных утилит [22] необходимо найти значения интенсивности входящего потока и вероятности потери пакетов в сети.

Рассмотрим пример, когда интенсивность обращений к серверу λ равна 1000 заявок в секунду, вероятность потери пакетов в сети Pпп 0.01, значение 1/μ (отведенный на сервере таймаут ) примем равным 60 секундам, и количество попыток повторной передачи SYN+ACK пакетов  равным 2.

Подставив такие значения в соотношение (3.14) получим:

Т.е. значение параметра max_overdue_count в правиле Snort следует принять равным 24.

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

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

ВЫВОДЫ

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

В настоящее время существуют различные механизмы обнаружения и противодействия TCP SYN атаке. Наиболее эффективным из них является метод SYN Cookies, однако он, как и все другие, имеет недостатки, такие как необходимость внесения соответствующих изменений в реализацию стека протоколов TCP/IP на защищаемом сервере, недостаточная эффективность обнаружения атаки из-за отсутствия методики выбора конкретных значений для параметров защиты. В связи с этим, проблема TCP SYN атак требует новых эффективных решений.

В результате проделанной работы была разработана методика обнаружения TCP SYN атаки, позволяющая обнаруживать атаку на ранних стадиях. В основе предложенной методики лежит математическая модель, описывающая обслуживание сервером потока заявок на установление TCP соединения. С помощью математического аппарата теории систем массового обслуживания находятся допустимые интервалы значений для количества полуоткрытых TCP соединений на сервере, работающем в нормальном режиме (при условии отсутствия атаки). В соответствии с этим методом, решение о начале атаки принимается в том случае, когда реальное количество полуоткрытых на сервере соединений выходит за пределы допустимого интервала. Для определения границ этого интервала необходимо получить значения таких параметров как: интенсивность входного потока заявок, время, в течение которого с заданной вероятностью заявка будет обслужена (время прихода ACK пакета), вероятность потери IP пакетов при передаче по сети, количество попыток повторного отправления сервером SYN + ACK пакетов, таймаут отведенный на сервере на установку TCP соединения и вероятность верного обнаружения атаки. Часть параметров можно определить, используя предложенные методики сбора данных, часть определяется настройками стека протоколов TCP/IP на защищаемом сервере.

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

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

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

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

Разработанное решение направлено на защиту критических ресурсов корпоративной сети, таких как сервера прикладных сервисов (Web, электронная почта, службы аутентификации и т.д) от TCP SYN атак.

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

ПЕРЕЧЕНЬ ССЫЛОК

1.  Постанова Кабінету Міністрів України від 28.10.2004 р. №1452 "Про затвердження Порядку застосування електронного цифрового підпису органами державної влади, органами місцевого самоврядування, підприємствами, установами та організаціями державної форми власності"

2.  Закон України "Про електронні документи та електронний документообіг" від 22.05.2003 р.

Страницы: 1, 2, 3, 4, 5, 6