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

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

СОДЕРЖАНИЕ
СОКРАЩЕНИЯ И УСЛОВНЫЕ ОБОЗНАЧЕНИЯ
ВВЕДЕНИЕ
1. ОПИСАНИЕ ИС
1.1 Описание ИС
1.2 Модель нарушителя
1.3 Модель угроз
1.3.1. Классификация угроз в соответствии с IT-Baseline Protection Manual
1.3.1.1 Угрозы, связанные с форс-мажорными обстоятельствами1.3.1.2 Угрозы, связанные снедостатками организации и управления
1.3.1.3 Угрозы, связанные с человеческим фактором
1.3.1.4 Угрозы, связанные с техническими неисправностями
1.3.1.5 Угрозы, связанные со спланированными действияминарушителей
1.3.2 Классификация угроз по нарушаемым базовым услугам ИС
1.3.2.1 Угрозы нарушения конфиденциальности информации
1.3.2.2 Угрозы нарушения целостности информации
1.3.2.3 Угрозы нарушения аутентичности
1.3.2.4 Угрозы нарушения наблюдаемости
1.3.2.5 Угрозы нарушения доступности ресурсов
1.4 Особенности реализации DoS/DDosатак. TCP SYN атака
1.5 Постановка задач по защите отугроз
2. ИЗВЕСТНЫЕ МЕТОДЫ ПРОТИВОДЕЙСТВИЯTCP SYN АТАКЕ
2.1 TCP SYN cookies
2.2 TCP RST cookies
2.3 Floodgate
2.4 Предмаршрутизационная фильтрация
2.5 Random/Old Drop
2.6 Syn-Proxy
2.7 Stack tweaking
2.8 BlackListing
3. МАТЕМАТИЧЕСКАЯ МОДЕЛЬ TCP SYN АТАКИ
3.1 Краткие сведения из теориисистем массового обслуживания
3.2 Поток требования СМО
3.3. Сервер TCP соединения как СМО
3.4 СМО с бесконечным количествомобслуживающих приборов
3.5 Модель, учитывающая потерюпакетов в сети
4. МЕТОДИКИ СБОРА ДАННЫХ
4.1 Определение времени прохожденияIP пакета по сети Internet
4.2 Определение вероятности потерипакетов в сети
4.3 Определение интенсивностивходящего потока требований
5. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ
5.1 Особенности установки Snort
5.2 Внутренняя структура Snort
5.2.1 Препроцессоры
5.2.2 Модули обнаружения
5.2.3 Модули вывода
5.3 Разработка модуля обнаружения
5.3.1 Структура модуля TcpConnEstTimeChecker
5.3.2 Структура модуля TcpSynFloodPreventionModule
5.3.3 Взаимодействие TcpConnEstTimeChecker и TcpSynFloodPreventionModule вреализации tcp_syn_flood
ВЫВОДЫ
ПЕРЕЧЕНЬ ССЫЛОК
ПРИЛОЖЕНИЯ

СОКРАЩЕНИЯ И УСЛОВНЫЕ ОБОЗНАЧЕНИЯ
БД – базы данных
ДСТСЗИ СБУ – Департамент специальныхтелекоммуникационных систем и защиты информации Службы Безопасности Украины (Державна служба спеціального зв'язку та захисту інформації України)ИС – информационная система
ИТС –информационно-телекомуникационная система
КЗИ – комплексная защитаинформации
КС – компьютерная система
ОС – операционная система
ОЗУ – оперативноезапоминающее устройство
ПО – программноеобеспечение
СВ – случайная величина
СМО – система массовогообслуживания
ACK – Acknowledgement Flag
ARP – AddressResolution Protocol
ASN.1 –Abstract Syntax Notation One
BO — BackOrifice
CSV – ComaSeparated Values
DDoS –Distributed Denial of Service
DNS – DomainName Service
DoS – Denialof Service
DSL – DigitalSubscriber Line
FIN – FinalizationFlag
ICMP –Internet Control Message Protocol
IDS — Intrusion Detection System
IPS –Intrusion Prevention System
IP — InternetProtocol
HTTP – HyperText Transfer Protocol
MSS – MaximumSegment Size
OSI – OpenSystem Interconnection
PSH – PushFlag
RPC – RemoteProcedure Call
RST – ResetFlag
SMS – SimpleMessage Service
SYN –Synchronize Flag
TCP –Transmission Control Protocol
TTL – Time toLive
UDP – UserData Protocol
URG – UrgentFlag
WWW – WorldWide Web

ВВЕДЕНИЕ
В настоящее время,трудно себе представить успешную компанию, не использующую для организацииделопроизводства достижения науки и техники в сфере информационных технологий.Также интеграции современных технологий способствует развитие в Украинесоответствующей нормативной базы. Одним из перспективных направлений являетсяразвитие электронного документооборота, инфраструктуры открытых ключей,использование средств современной криптографии органами государственной власти,органами местного самоуправления, предприятиями, учреждениями, организациями ит.д. [1,2]. Одним из основных преимуществ использования таких технологийявляется значительное повышение эффективности делопроизводства за счетускорения поиска необходимой информации, увеличения скорости обменаинформацией, уменьшение процента утерянной информации и т.д. Такие средствакриптографии как электронная цифровая подпись способны обеспечить обеспечениетаких базовых услуг информационных систем как конфиденциальность, целостностьинформации и т.д [3]. Однако использование этих средствне дает гарантии обеспечения такой важной услуги, как доступность ресурсов [3].Для того чтобы инфраструктура открытых ключей могла полноценно функционировать,необходимо, чтобы пользователи системы всегда могли иметь доступ к центрамсертификации различных уровней.
К сожалению, впоследнее время все большее распространение получил целый класс атак (DoS/DDoS), направленных на отказ в обслуживании. Успешнаяреализация таких атак позволяет блокировать доступ пользователей информационныхсистем к ресурсам различных серверов, что может вывести из рабочего состояниявсю систему.
Одним из способовреализации атаки типа отказа в обслуживании является загрузка всех ресурсовсервера обработкой огромного количества ложных запросов. В большинстве случаев,для организации таких атак используются компьютеры «мирных»пользователей без их ведома и согласия. Это осуществляется путем установки нанедостаточно защищенные машины вредоносного программного обеспечения, такогокак «троянские кони», «черви», компьютерные вирусы и т.д.После того, как злоумышленник смог инфицировать достаточно большое количествоузлов сети, реализация распределенной атаки сводится к тому, чтобы отправитьодновременно всем зараженным машинам команду, активирующую вредоносное ПО,превращая тем самым «мирные» компьютеры в источник распределеннойатаки.
В настоящее время,организация атак типа отказа в обслуживании является довольно прибыльнымзанятием. Существуют два способа получить финансовое вознаграждение. В первомслучае за организацию атак платят нечистоплотные конкуренты, целью которыхявляется нанесение удара по репутации других компаний и организаций. А в другомслучае хакеры занимаются вымогательством – выбирают жертву, атакуют ее итребуют выкуп за прекращение атаки.
Для эффективногопротиводействия DDoS атакамсуществуют несколько серьезных препятствий. В частности, многие из них нетребуют установления сеанса связи с источником атаки, что значительнозатрудняет поиск злоумышленника. Но даже в случае поимки хакера, он может неполучить заслуженного наказания в виду несовершенства законодательства вразличных странах [4].
На данный момент в миресуществуют решения, снижающие негативное воздействие DDoS атак (может отфильтровываться до 99% вредоносноготрафика [5]), но такие средства обладают несколькими недостатками, которыеограничивают возможности их использования. Во-первых, использующиеся алгоритмыявляются коммерческой тайной разработчиков, что не дает возможностисоответствующим организациям сертифицировать эти продукты. Вторым недостаткомявляется высокая цена, недоступная для многих компаний и организаций. Например,услуги компаний AT&T и MCI в этой области стоят около 12 тысяч долларов вмесяц[5].
Из всего вышесказанноговидно, что проблема обнаружения и противодействия DDoS атакам является актуальной и требует недорогих иэффективных решений. В магистерской работе предлагается методика раннегообнаружения одной из самых распространенных DDoS атак – TCP SYNатаки. В основе этой методики лежит математическая модель, описывающаявзаимодействие сервера с клиентами. Разработанная модель учитываетиндивидуальные значения различных параметров, характеризующих работу сети исервера, что повышает эффективность обнаружения атаки. В работе так жепредлагается программная реализация разработанной методики, представленная ввиде модуля расширения функциональности для системы предотвращения вторжений Snort_inline. Такое решение ориентировано назащиту критичных ресурсов корпоративной сети от указанной выше атаки.

1. ОПИСАНИЕ ИС1.1 Описание ИС
Как известно, XXI век принято считать веком высокихтехнологий. Трудно себе представить современное общество, в котором неиспользовались бы последние достижения стремительно развивающейся науки итехники. Одним из направлений развития современной науки являютсяинформационные технологии, с каждым днем открывающие перед человечеством всеновые и новые возможности. Одним из замечательных продуктов этих технологийявляются информационные системы (ИС), повсеместно внедряемые во всяческие сферычеловеческой деятельности.
Далее под информационнойсистемой будем понимать объединенную совокупность аппаратных,программно-аппаратных и программных средств, осуществляющих создание, хранение,обработку и уничтожение разнообразной информации, а так же обмен ею путемвзаимодействия между собой [6].
Наиболееизвестным примером информационной системы является глобальная сеть Internet. Она охватывает своей паутиной практически всюповерхность земного шара, открывая для человечества колоссальные возможности.Фактически Internet состоит из множества локальных и глобальных сетей,принадлежащих различным компаниям и предприятиям, связанных между собойразличными линиями связи. Internet можно представить себе в виде мозаикисложенной из небольших сетей разной величины, которые активно взаимодействуютодна с другой, пересылая различную информацию [7].
При низкой стоимостиуслуг (часто это только фиксированная ежемесячная плата за используемые линииили телефон) пользователи могут получить доступ к коммерческим и некоммерческиминформационным службам практически всех мировых стран. В архивах свободногодоступа сети Internet можно найти информацию практическипо всем сферам человеческой деятельности, начиная с новых научных открытий допрогноза погоды на ближайший месяц.
Internet предоставляет уникальные возможностидешевой и надежной связи по всему миру. Это оказывается очень удобным для фирмимеющих свои филиалы по всему миру, транснациональных корпораций и структуруправления. Обычно, использование инфраструктуры Internet для международной связи обходитсязначительно дешевле прямой компьютерной связи через спутниковый канал или черезтелефон.
Электронная почта – однаиз самых распространенных услуг сети Internet. Посылка письма по электронной почте обходится значительнодешевле посылки обычного письма. Кроме того, сообщение, посланное поэлектронной почте, дойдет до адресата за короткий промежуток времени (отнескольких десятков секунд), в то время как обычное письмо может добираться доадресата несколько дней и недель.
Еще одной распространеннойуслугой Internet является World Wide Web (WWW) — система для работы с гипертекстом.Потенциально она является наиболее мощным средством поиска. Гипертекстсоединяет различные документы на основе заранее заданного набора слов.Например, когда в тексте встречается новое слово или понятие, система,работающая с гипертекстом, дает возможность перейти к другому документу, вкотором это слово или понятие рассматривается более подробно. WWW часто используется в качестведружественного интерфейса к базам данных [6].
С каждым днем растетзависимость успешной работы компаний от использования современныхинформационных технологий, которые предоставляют грандиозные возможности. Нарис. 1.1 приведен пример типичной корпоративной сети компании, имеющейразветвленную структуру географически удаленных друг от друга филиалов, [8].

/>
Рис.1.1 Пример ИС
Такая ИС позволяет,например, проводить конференции с участием сотрудников, работающих в разныхгородах и странах, с такой же легкостью как если бы они находились в одномпомещении. В таких системах обрабатывается информация различного характера исодержания. Это может быть жизненно важная для компании информация, например окоммерческой деятельности, результаты научных исследований, на которые былозатрачено много ресурсов и времени и т.д. Очевидно, что, например, ознакомлениес такими сведениями конкурентов, может привести к непоправимым последствиям,вплоть до банкротства. В связи с этим к информационной системе должнывыдвигаться требования по обеспечению некоторых базовых услуг. Такие услугибудут рассмотрены ниже. Здесь стоит отметить, что причинами нарушения базовыхуслуг могут быть как обстоятельства случайного характера, так и специальноспланированные действия нарушителей.
Эти обстоятельства могутиметь как случайный характер, так и являться следствием спланированных действийнарушителей. Классификация возможных нарушителей в ИС приведена в пункте 1.2.

1.2 Модельнарушителя
Всоответствии с [3], нарушитель – это пользователь, который осуществляетнесанкционированный доступ к информации. Здесь стоит отметить, что поднесанкционированным доступом к информации может быть как ознакомление с нейтаки и ее редактирование и удаление. В контексте данной работы это определениеможет быть расширено с учетом того, что злоумышленник может не бытьпользователем атакуемой системы. В соответствии с нормативными документами,действующими в Украине, определены четыре уровня возможностей нарушителя в ИСсистеме [9]:
1. Нулевой уровень – случайное неспециальное ознакомление с содержаниеминформации.
2. Первый уровень – нарушитель, имеющий ограниченные средства исамостоятельно создающий средства и методы атак на средства КЗИ и ИТС, сприменением широко распространенного ПО и вычислительной техники.
3. Второй уровень – нарушитель корпоративного типа. Имеет возможностьсоздания специальных технических средств, стоимость которых соотносится свозможными финансовыми убытками при потере, искажении и уничтожении защищаемой информации.Для проведения вычислений могут использоваться локальные вычислительные сети.
4. Третий уровень – нарушитель имеет научно-технический ресурс,приравниваемый к научно-техническому ресурсу экономически развитогогосударства.
Методика,предлагаемая в данной магистерской работе, ориентирована на защиту отзлоумышленников нулевого, первого и второго уровней.
В связи стем, что злоумышленники третьего уровня обладают практически неограниченнымивозможностями, защита от реализуемых ими угроз выходит за рамки данной работы.
В пункте1.3 приведена модель возможных в рассматриваемой ИС угроз.
1.3 Модельугроз
Всоответствии с [3], угроза – это любые обстоятельства или события, которыемогут быть причиной нарушения политики безопасности и (или) нанесения ущерба.Ущерб может заключаться в нарушении свойств информации путем ее разрушения,искажения или несанкционированного ознакомления, либо в разрушении, искаженииили несанкционированном использовании ресурсов системы. Источниками угроз могутбыть различные объекты и явления, что значительно затрудняет их учет припостроении комплексной системы защиты информации. В связи с этим в мировойпрактике принято строить модель угроз, в которой приводится классификациявозможных угроз, их описание и средства возможной реализации.
1.3.1Классификация угроз в соответствии с IT-Baseline Protection Manual
Одним излучших документов в этой области классификации угроз является [10]. В этомстандарте приводится перечень возможных угроз, а так же рекомендуютсяорганизационные и технические меры для защиты от них. В приведенной в [10]классификации все угрозы разделены на 5 основных групп:
1.  Угрозы,связанные с форс-мажорными обстоятельствами
2.  Угрозы,связанные с недостатками организации и управления
3.  Угрозы,связанные с человеческим фактором
4.  Угрозы,связанные с техническими неисправностями.
5.  Угрозы,связанные со спланированными действиями злоумышленников.
Каждая изэтих групп содержит большой перечень угроз, подробное рассмотрение которыхвыходит за пределы этой работы, поэтому ниже приведены только некоторыепримеры, дающие представление о разнообразности угроз.
1.3.1.1Угрозы, связанные с форс-мажорными обстоятельствами
Рассматриваемыев этой группе угрозы характеризуются тем, что их источники трудно заранеепредсказать и их проявление носит случайных характер. Одной из таких угрозявляются проблемы с персоналом. Ущерб в этом случае проявляется в том, чтоболезнь, смерть или забастовки персонала могут привести к прерыванию выполнениякритичных задач, или выходу из строя критичных ресурсов. Источниками целогоряда угроз являются ЧП как природного (молнии, пожары, наводнения, дожди,магнитные бури) так и техногенного (возгорание кабелей, аварии, нарушениесистем тепло-, водо-, и электроснабжения) характера. Стоит отметить, что такогорода угрозы могут наносить как непосредственный, так и косвенный ущерб.Например, во время пожара оборудование может подвергаться деструктивномувоздействию не только от контакта с открытым огнем, но и под действием газовыхсмесей, образующихся при горении.
Так же кугрозам этой группы относятся недопустимые температуры и влажность, пыль игрязь, который могут привести к выходу из строя некоторых ресурсовинформационной системы.
Для систем,подсистемы которых тесно связаны между собой, серьезными угрозами являются отказыи сбои в системе. Отказ в работе одного из компонентов может повлечь за собойсбой работы всего механизма. Примером такой угрозы может быть резкий скачокнапряжения в электросети, результатом которого может быть выход из строй блокапитания одного из критичных ресурсов системы. В результате этот ресурс можетстать недоступным для всей системы на длительное время. Еще одним примеромявляются распределенных ИТ систем, в которых время является критичным ресурсом.В этом случае сбои в работе WAN могут привести к сбоямработы всей системы или ее компонентов.
1.3.1.2 Угрозы,связанные с недостатками организации и управления
Угрозы этойгруппы характеризуются тем, что их источником являются недоработкиорганизационного характера. К таким угрозам относятся отсутствие илинесовершенство регламентирующих правил и документов, недостаточное ознакомлениес ними персонала, низкокачественный мониторинг и аудит мер ИТ безопасности.Например, если в политике безопасности не запрещено использование неучтенныхносителей данных, или служащий не ознакомлен с этим положением, то значительноповышается вероятность попадания в корпоративную сеть вредоносного ПО (ad-ware – вирусов, троянских коней ит.д.), принесенного сотрудником из дома на flash диске.Еще одним примером этого вида угроз является недостаточное финансирование, либонеэффективное использование ресурсов. Например, необходимость использованиястарых версий ОС (таких как Windows 95) приводит кневозможности аудита действий пользователей.
Так же кугрозам этой группы относятся ошибки в проектировании системы. Например,неправильный расчет пропускной способности канала связи приведет либо кнеобоснованным затратам на услуги связи, либо к замедлению работы другихкомпонентов. Стоит упомянуть угрозы связанные с тестированием. К ним относятсянекачественное тестирование и тестирование с использованием реальных данных. Впервом случае в эксплуатацию может поступить нестабильная и (или) неправильноработающая система, а во втором может иметь место нарушение конфиденциальностиданных.
Другимипримерами таких угроз являются неавторизированный доступ в помещение,использование ресурсов, использование полномочий и т.д.

1.3.1.3Угрозы, связанные с человеческим фактором
Источникамиугроз этой группы являются некорректные действия пользователей системы.Вследствие таких действий возможна потеря конфиденциальности или целостностиданных. Например, если пользователь распечатал информацию на принтере и забылзабрать распечатку, то ее содержание может стать доступно не имеющим на этоправ пользователям. Потеря целостности возможна в случае неправильной настройкиправ доступа к файлам. Еще одним примером угрозы этой группы является неполноеследование мерам безопасности. Например, хранение носителей информации взакрытом ящике стола еще не гарантирует достаточной защиты от неавторизованногодоступа. Если ключ от ящика находится в офисе в общедоступном месте – напримерна столе. Неаккуратные действия пользователей и не целевое использованиесистемы могут привести к потере данных, порче оборудования и т.д.
Большаячасть угроз этой группы связана с некорректным администрированием и настройкойсистемы. Например, неправильное соединение кабелей, настройка сетевых устройствможет привести к тому, что данные будут дополнительно передаваться другимадресатам. В случае неправильной настройки прикладных сервисов? таких как Web, SMTP, POP3,RAS и т.д. так же возможно нарушение конфиденциальностии целостности информации.
1.3.1.4Угрозы, связанные с техническими неисправностями.
Источникамиугроз этой группы являются различного рода технические неисправности. Это могутбыть сбои в сетях электро-, тепло-, водоснабжения, в противопожарных системах исистемах кондиционирования и вентиляции, в сетях связи и т.д. В результатереализации таких угроз может выйти из строя оборудование, что в свою очередьможет привести к остановке функционирования всей системы, или ее отдельныхкомпонентов. Так же примерами такого рода угроз могут быть неисправностиоборудования, носителей информации, ошибки при передаче данных.
Так же кэтой группе относятся ошибки и уязвимости ПО. Например, в некоторых широкораспространенных приложениях есть функциональность позволяющая применятькриптопреобразования к документам и т.д. Однако эта функциональность реализуетнестойкие алгоритмы, защиту которых можно легко обойти с помощью легкодоступныхв Интернете утилит. Так же широко известной разновидностью уязвимостей ПОявляется переполнение буфера. Эти уязвимости используют тот факт, чторазработчики довольно часто не ограничивают размер вводимых пользователямиданных. Это может привести к тому, что введенные пользователем данные могутбыть интерпретированы как исполняемый код.
Еще однаинтересная угроза связана с настройками CD привода. Вслучае, когда включена опция автоматического определения диска, автоматическивыполняется файл AUTORUN.INF,содержание которого заранее неизвестно.
1.3.1.5Угрозы, связанные со спланированными действиями злоумышленников
Эта группасодержит наибольшее количество угроз. В ней представлены угрозы, которые могутбыть реализованы как при непосредственном физическом воздействии (кражи, актывандализма и т.д.) так и удаленно.
Одним изпримеров таких угроз является действие так называемого adwareПО, к которому относятся компьютерные вирусы, черви, троянские кони, макровирусы, rootkit’ы и т.д.
Так жесуществуют угрозы, связанные с анализом сетевого трафика с помощью специальныхпрограмм (sniffers). При реализации этих угроззлоумышленник может получить несанкционированный доступ к конфиденциальнойинформации: e-mail, паролям(которые во многих протоколах передаются по сети в открытом виде). Так же спомощью сетевого трафика злоумышленник может получить представление овнутренней структуре сети (используемые IP адреса, топологиюи т.д.), ПО используемое на машинах в сети и т.д. Если злоумышленникконтролирует сетевое устройство (маршрутизатор, мост и т.д.) через котороепроходит трафик, то кроме нарушения конфиденциальности информации можетприсутствовать нарушение ее целостности.
Стоит упомянутьугрозы связанные со спуфингом (spoofing). Примерамитаких угроз являются ARP и DNS spoofing. Реализация этих угрозпозволяет изменить маршрутизацию пакетов в локальных (ARP,DNS) и глобальных (DNS) сетях,в результате чего злоумышленник получает возможность контролировать трафикатакуемых систем. Так же существует угроза Web spoofing. Она заключается в том, чтозлоумышленник может имитировать какой либо Web сайтпутем регистрации доменного имени со схожим названием, при этом многиепользователи об этом даже не будут догадываться. Например, у компании «Рогаи Копыта Ukraine» есть webсайт www.rogakopita.ua. Если пользователи не знают точного доменного имени? томногие из них начнут поиск с www.rogakopita.com,по которому злоумышленники могут разместить похожий сайт.
1.3.2Классификация угроз по нарушаемым базовым услугам ИС
Как упоминалось ранее, кИС должны выдвигаться требования по обеспечению базовых услуг. Такими базовымиуслугами являются [3]:
· обеспечение конфиденциальностиинформации. Конфиденциальность – это свойство информации, заключающееся в том,что она не может быть получена неавторизованным пользователем и (или) процессом[3].
· обеспечение целостностиинформации. Целостность – это свойство информации, заключающееся в том, что онане может быть модифицирована неавторизованным пользователем и (или) процессом[3].
· обеспечение доступностиресурсов. Доступность – это свойство ресурса системы, заключающееся в том, чтопользователь и (или) процесс, который владеет соответствующими полномочиями,может использовать ресурс в соответствии с правилами, установленными политикойбезопасности, не ожидая дольше заданного (маленького) промежутка времени, т.е.когда они находятся в виде нужном пользователю, в месте нужном пользователю и внужное пользователю время [3]
· обеспечение аутентичности.Обеспечивается с помощью аутентификации. Аутентификация – это процедурапроверки соответствия предъявленного идентификатора объекта КС на предметпринадлежности его этому объекту [3].
· обеспечение наблюдаемости.Наблюдаемость – это свойство КС, которое позволяет фиксировать деятельностьпользователей и процессов, использование пассивных объектов, а так жеоднозначно устанавливать идентификаторы причастных к конкретным событиямпользователей и процессов с целью предотвращения нарушения политикибезопасности и (или) обеспечения ответственности за конкретные действия [3].
Так жеугрозы могут быть классифицированы по принципу, к нарушению какой из базовыхуслуг ИС они приводят. Здесь можно выделить угрозы нарушающиеконфиденциальность, целостность и доступность информации и ресурсов, а так жеаутентичности и наблюдаемости.
1.3.2.1Угрозы нарушения конфиденциальности информации
Эта угрозызаключается том, что информация становится известной тем сторонаминформационного взаимодействия, у которых нет прав на ознакомление с этойинформацией. Примерами реализации такой угрозы могут быть:
· Перехват и анализ сетевого трафика с помощью специализированногоПО. Такое ПО называется снифферами.
· Криптоанализ зашифрованных данных
· Несанкционированный доступ к данным, находящимся в различныхзапоминающих устройствах (на жестком диске, в ОЗУ, flashи т.д).
1.3.2.2Угрозы нарушения целостности информации
Угрозынарушения целостности информации включают в себя несанкционированное изменениеили удаление данных, обрабатываемых в информационной системе. Примерами реализациитакой угрозы могут быть:
· Модификация трафика, проходящего через хост атакующего, либо спомощью специализированного ПО (троянские кони, rootkit)
· Модификация файлов других пользователей, хранящихся наразделяемом дисковом пространстве
1.3.2.3 Угрозынарушения аутентичности
Угрозынарушения аутентичности заключаются в том, что в результате проведениянекоторых действий пользователь и (или) процесс выдает себя за другогопользователя и имеет возможность воспользоваться чужими правами и привелегиями.Примерами реализации такой угрозы являются:
· Навязывание ложных сетевых адресов (ARP-spoofing) и доменных имен (DNS-spoofing), соответственно, может осуществляться на сетевом итранспортном уровнях модели OSI.
· Классическая атака типа человек посередине (Man in the middle).Заключается в том, что злоумышленник незаметно внедряется в канал связи междудвумя абонентами и получает полный контроль над информацией (модификация,удаления, создание дезинформации), которой обмениваются участвующие стороны.При этом он остается абсолютно невидимым для абонентов.
1.3.2.4Угрозы нарушения наблюдаемости
Угрозынарушения наблюдаемости заключаются в том, что в результате некоторых действийзлоумышленника становится невозможным фиксирование деятельности пользователей ипроцессов, использования пассивных объектов, а так же однозначно устанавливатьидентификаторы причастных к конкретным событиям пользователей и процессов.Примерами реализации таких атак может быть:
· Очистка журналов аудита
· Отключение системы аудита
· Переполнение журнала аудита, в результате чего, записи онекоторых событиях пропадают
· Заражение системы rootkit’ом
1.3.2.5Угрозы нарушения доступности ресурсов
Угрозынарушения доступности ресурсов заключаются в проведении некоторых действий, врезультате которых блокируется доступ к некоторому ресурсу информационнойсистемы со стороны легальных пользователей. Примерами реализации таких угрозмогут быть:
· загрузка ресурсов сервера фиктивными запросами злоумышленника, врезультате чего запросы от легальных пользователей не могут быть обработаны.
· обрыв канала связи, между взаимодействующими сторонами
Атаки,реализующие такие угрозы, называются DoS (Denial of Service) атаками. Целью даннойработы является разработка методики обнаружения и противодействия TCP SYN атаке– одной из самых распространенных атак этого класса. В связи с этим нижерассматриваются особенности реализации атак типа отказа в обслуживании и, вчастности, TCP SYN атаки.
1.4Особенности реализации DoS/DDosатак. TCP SYNатака
DoS/DDoS-атаки направлены на нарушение базовой услугидоступности. Основная цель DoS/DDoS-атак вывести атакуемый объект израбочего состояния и сделать его ресурсы недоступными для легальныхпользователей. Атаку, направленную на отказ в обслуживании, можно провестидвумя способами: используя уязвимости в программном обеспечении атакуемойсистемы и при помощи отсылки большого количества определенно составленныхсетевых пакетов (flood).
Первый способ сложнее итребует более высокой квалификации атакующего. Второй способ основан наприменении «грубой силы». Идея заключается в том, чтобы загрузитьвычислительные ресурсы сервера обработкой огромного количества посланныхзлоумышленником пакетов. Такая загрузка сервера в лучшем случае может привестик тому, что сервер будет неспособен принять на обработку запросы от легальныхпользователей, а в худшем случае может привести к зависанию и отключениюсервера.
Здесь стоит отметить, чтоможно выделить два типа атак, направленных на загрузку ресурсов системы: впервом случае загружаются вычислительные ресурсы сервера, а в другом –пропускная способность канала связи. Разрабатываемая методика ориентирована назащиту от атак первого типа, поэтому дальше будем считать, что пропускнойспособности достаточно, чтобы сервер получил весь адресованный ему трафик.
Для многих DoS/DDoS атак результаты обработки сервером пакетов,отправленных злоумышленником, последнего не интересуют. Это значит, что атакующийможет отправлять поток ложных заявок с ложных IP адресов (это понятие называется spoofing), что препятствует его обнаружению иэффективному противодействию такого рода атакам.
Для проведения успешной DoS-атаки необходима довольно высокаяпропускная способность канала. Поэтому атака на отказ в обслуживании вбольшинстве случаев проводится сразу с нескольких машин. Атака, в проведениикоторой участвует большое количество машин, получила название DDoS. Стоит отметить, что дляраспределенной атаки могут использоваться инфицированные специальным ПО машиныне принадлежащие атакующему. Такие зараженные машины называются «зомби».Одним из способов получения «зомби» является массовое внедрение «трояна»на компьютеры мирных пользователей. Получив определенную извне команду такой «троян»превращает «мирный» компьютер с доступом в Internet в источник ложных запросов,направленных на перегрузку ресурсов сервера.
Наиболеераспространенными DoS атаками являются:
· TCP SYN Flood или просто TCP SYN
· TCPflood
· Pingof Death
· ICMPflood
· UDPflood
Рассмотрим подробнее TCP SYN (tcp syn flood) атаку, которая направлена наприкладные сервисы, использующие протокол транспортного уровня TCP. Этот протокол получил широкоераспространение в информационных системах за счет того, что он гарантирует 100%доставку всех передаваемых данных. Взаимодействующие узлы сети, использующие вкачестве транспорта этот протокол, устанавливают между собой TCP соединения, в рамках которых ведетсяконтроль над тем, что получатель получит все посланные отправителем пакеты. Этодостигается за счет того, что получатель извещает отправителя о том, какиепакеты он получил. Если до получателя дошли не все предназначенные ему пакеты,то отправитель повторно их отправит. Как видно достоинством этого протоколаявляется возможность установления соединения. Для хранения информации о текущемсостоянии соединения в частности используется поле битовых флагов в пакетах,используемых протоколом. Под это поле отведено 8 бит, однако 2 из них являютсязарезервированными и в настоящее время используются только 6 флагов: URG (флаг срочности), ACK (флаг подтверждения), PSH (флаг push функции), RST (флаг сброса), SYN(флаг синхронизации) и FIN(флаг окончания). К сожалению, установленный стандартом [11] механизмустановления соединения не является совершенным, и рассматриваемая атака, какраз использует его недостатки.
Основная цель этой TCP SYN атаки – превысить ограничение на количество TCP соединений, которые находятся всостоянии установки. Рассмотрим процедуру установки TCP соединения. Сначала клиент, инициализирующийсоединение отправляет серверу TCP-SYN запрос. Получив такой запрос, сервервыделяет память для параметров соединения в специально предназначенном дляэтого буфере. Затем отправляет клиенту TCP пакет с флагами SYN+ACK.Получив пакет SYN+ACK, клиент должен отправить серверу пакет с подтверждением,т.е. пакет с установленным флагом ACK. Когда сервер получит и обработает этот пакет, соединение являетсяустановленным. Описанная выше
процедура изображена нарис. 1.1
/>
Рис. 1.1 Установка TCP соединения
TCP SYN атака производится следующим образом: злоумышленникгенерирует большое количество пакетов с установленными SYN флагами протокола TCP. Получая пакеты, атакуемая машина выделяет память дляхранения параметров соединения и отправляет ответ – пакет с флагами SYN + ACK и ожидает пакета с флагом ACK. Очевидно, что ожидаемый ответ она не получит, ипамять будет освобождена только после истечения установленного таймаута. Черезнекоторое время буфер, выделенный для хранения параметров TCP, соединений будет полностью занят, врезультате чего, система не сможет устанавливать новые соединения. После этогокаждый дополнительный запрос еще сильнее увеличивает нагрузку. Такие атаки ненуждаются в обратной связи с атакующим, и поэтому злоумышленник можетгенерировать пакет с произвольными IP адресами отправителя.
Отсутствие обратной связи с атакующим делаетобнаружение и отражение TCP-SYN атаки довольно сложной задачей.
1.5Постановка задач по защите от угроз
В настоящее время воткрытой литературе не известны эффективные методы обнаружения TCP SYN атак. В современных ОС присутствуют механизмы защитыатакуемого сервера, например SYN cookies.Операционная система автоматически включает защиту, когда обнаруживаетпревышение значений некоторых параметров. Например, ОС Windows 2000 следит за значениями трех параметров: TcpMaxHalfOpen, TcpMaxHalfOpenRetried, TcpMaxPortsExhausted [12].Пороговые значения для этих параметров имеют значения по умолчанию и могутменяться администратором. Если исходные значения не подходят для конкретногосервера, то перед администратором стоит непростая задача эффективно настроитьзащиту. Кроме того, этот метод требует внесения соответствующих изменений вреализацию стека TCP/IP, которые некоторые специалисты вобласти сетевых технологий считают «серьезным нарушением» протокола TCP[13].
Другим недостаткомсредств обнаружения TCP атакиинтегрированных в ОС является то, что при перегрузке (имеется в виду нехваткаресурсов процессора и памяти) или зависании самой системы средствапротиводействия так же становятся неработоспособными.
Целью магистерской работыявляется создание математически обоснованной методики обнаружения TCP SYN атаки. Для этого необходимо построить математическуюмодель, описывающую взаимодействие TCP сервера с клиентами. Исходными параметрами для такой модели должны бытьхарактеристики сервера и канала связи, а выходным параметром должно бытьутверждение о наличии или отсутствии TCP-SYN атаки.
Для возможностииспользования предлагаемой методики на практике для защиты критичных ресурсовкорпоративной сети необходимы так же средства, позволяющие определитьфактические значения входных параметров модели для конкретного сервера и сети,к которой он подключен.

2. ИЗВЕСТНЫЕ МЕТОДЫПРОТИВОДЕЙСТВИЯ TCP SYN АТАКЕ
В этом разделерассматриваются существующие методы обнаружения и противодействия TCP SYN атаке, описываются их достоинства и недостатки.
2.1 TCP SYN Cookies
Этот метод защиты отрассматриваемой атаки был предложен в 1996 году, в скором времени после первых TCP SYN атак [13], вызвавших большой резонанс. В основе этогометода лежит изменение идентификатора последовательности TCP TCP (TCP sequencenumber). Значение этого параметраопределяется следующим образом [13]:
· 5 старших битов:значение t mod 32, где t – 32-разрядный счетчик временных интервалов, значение которогоувеличивается на 1 каждые 64 секунды;
· следующие 3 бита:кодированное значение MSS,выбранное сервером в ответ на MSSклиента;
· младшие 24 бита:выбранная сервером на основе IP-адресови номеров портов отправителя и получателя, а также величины t значение секретной функции.
Такой алгоритм выбораначального порядкового номера соответствует основным требованиям протокола TCP, в соответствии с которыми номерадолжны увеличиваться достаточно медленно и начальные порядковые номера длясерверов растут несколько быстрее, нежели порядковые номера для клиентов.
Серверы, использующиефункции SYN cookie, не отвергают соединения при заполнении очереди SYN. Взамен они передают инициаторусоединения пакет SYN+ACK, в точности соответствующий пакету,который был бы передан при большем размере очереди SYN (исключения: сервер должен отвергать (reject) опции TCP такие, как большое окно, и должен использовать 1/8значения MSS, которое он может кодировать). Приполучении пакета ACK, серверубеждается в работе секретной функции для последнего (recent) значения t и перестраивает запись очереди SYN в соответствии со значением MSS.
Стоит отметить, что этотметод реализован в ОС семейства Linuxи FreeBSD. К достоинствам этого метода можноотнести его достаточную эффективность. Недостатком метода являетсянеобходимость модификации реализации стека TCP/IP,которая, по мнению некоторых специалистов в области сетевых технологий [13],противоречит спецификации протокола TCP.
2.2 TCP RST Cookies
Этот метод заключается втом, что клиенту, приславшему запрос на соединение, отправляется SYN+ACK пакет, с неверными параметрами. В соответствии соспецификацией протокола TCP[10] клиент должен прислать RSTпакет. Если такой пакет приходит к серверу, то сервер добавляет клиента всписок «благополучных» клиентов. Достоинством этого метода являетсяпроверка клиента, при этом к недостаткам можно отнести несовершенство механизматакой проверки. Во-первых, эта проверка требует дополнительного времени наотправку некорректного SYN + ACK и получение RST пакетов. В открытой литературе недостаточноинформации об этом методе, что затрудняет анализ его достоинств и недостатков.В частности, возникает вопрос, по какому критерию сервер идентифицируетклиентов. Если это только IPадрес, то злоумышленник может при организации атаки устанавливать в качествеадреса отправителя адрес уже проверенного сервером клиента [14].

2.3 Floodgate
Метод заключается в том,что в условиях атаки сервер обрабатывает не все SYN пакеты, а только их часть. Обычно эта частьвыбирается случайным образом. Достоинством этого метода является простотареализации, однако это выливается в его же основной недостаток – низкуюэффективность, т.к. заявки легальных пользователей будут отфильтровыватьсясистемой наравне с вредоносным трафиком [15].
2.4 Предмаршрутизационнаяфильтрация
Этот метод заключается втом, что каждый маршрутизатор в сети контролирует IP адреса отправителей в маршрутизируемом им трафике, выявляетпакеты с ложными адресами и уничтожает их. Главным достоинством этого методаявляется то, что он полностью исключает возможность атаки с подложных адресов,что является главным препятствием для ее эффективного обнаружения иблокирования. Недостатком метода является его дороговизна, обусловленнаянеобходимостью замены огромного числа действующих в настоящее время в сети Internet маршрутизаторов [14].
2.5 Random/Old Drop
Метод основан на том, чтонекоторые из полуоткрытых соединений закрываются сервером. При этом в случае Random модификации закрываются случайновыбранные соединения, а в случае Old –те полуоткрытые соединения, которые существуют дольше остальных. Достоинствомтакого метода является простота реализации, а главным недостатком – низкаяэффективность фильтрации трафика, при которой с высокой вероятностью будутзакрыты соединения с легальными клиентами [14].
2.6. SYN-Proxy
Этот метод требуетдополнительный прокси-сервер, назначением которого является обработка SYN пакетов. Он служит посредником междуклиентом и сервером. Если прокси-серверу удалось установить соединение склиентом, то клиент допускается к ресурсам главного сервера. Достоинствомданного метода является то, что ресурсы основного сервера используются сбольшей эффективностью, а недостатки заключаются в незащищенностипрокси-сервера от атаки и сложность реализации [14].
2.7 Stack Tweaking
Заключается в измененияхнастройки параметров протокола TCP насервере. Как правило, этими параметрами являются: таймаут перед закрытиемполуоткрытого соединения, максимально возможное количество полуоткрытыхсоединений и время ожидания ответного ACK-пакета. Достоинством метода является возможность повышения эффективностиработы сервера за счет учета параметров сервера и сети. Недостатки заключаютсяв том, что это метод не работает против интенсивной атаки и требует высокойквалификации администратора [12].
2.8 Blacklisting
Заключается в том, чтосервер не обслуживает заявки, поступающие от клиентов, внесенных в «черныйсписок» [15]. Этот метод малоэффективен в видутого, что обычно атаки производятся с подставных адресов. Этот метод был быэффективен при использовании совместно с методом предмаршрутизационнойфильтрации, рассмотренном в пункте 2.4.
Таким образом, внастоящее время существуют различные механизмы обнаружения и противодействия TCP SYN атаке. Наиболее эффективным из них является метод SYN Cookies, однако он, как и все другие, имеет недостатки, такиекак необходимость внесения соответствующих изменений в реализацию стекапротоколов TCP/IP на защищаемом сервере, недостаточная эффективностьобнаружения атаки из-за отсутствия методики выбора конкретных значений дляпараметров защиты. В связи с этим, проблема TCP SYN атак требует новых эффективных решений, и тематикаданной работы является чрезвычайно актуальной.

3. МАТЕМАТИЧЕСКАЯ МОДЕЛЬ TCP-SYN АТАКИ
Целью магистерской работыявляется создание методики обнаружения TCP SYN атаки, в основе которой находится математическаямодель, учитывающая особенности среды, для которой разрабатывается методика. Всвязи с этим на начальном этапе исследований стал вопрос о том, какойматематический аппарат целесообразно использовать для построения наиболееэффективной модели. После анализа существующих направлений современной наукибыло принято решение использовать теорию систем массового обслуживания,специфика которой идеально подходит для решения поставленной задачи. Нижеприведено описание некоторых понятий, используемых в работе. Подробнее с этимразделом теории вероятностей можно ознакомиться здесь [16].
3.1 Краткие сведения из теории системмассового обслуживания
Под системой массовогообслуживания [16] обычно понимается совокупность обслуживающих приборов иобслуживаемых требований (заявок) из некоторого входящего потока требований.
Число приборов в системемассового обслуживания может быть любым. Основной характеристикой прибораявляется время обслуживания одного требования этим прибором. Этот показательхарактеризует не качество обслуживания, а пропускную способность прибора. Времяобслуживания обычно непостоянно. Оно зависит от различных факторов. Поэтому вобщем случае эта величина является случайной [16]. При этом в теории массовогообслуживания считают, что продолжительность обслуживания различных требованийодним прибором есть независимые случайные величины с одним и тем же закономраспределения. Наиболее часто предполагают, что это закон являетсяпоказательным. Его применяют в тех случаях, когда время обслуживанияподавляющего большинства требований мало и только для сравнительно небольшойчасти требований оно велико. При показательном распределении времениобслуживания требований теоретические рассуждения существенно упрощаются, амногие окончательные результаты оказываются справедливыми и для произвольногозакона распределения, но с тем же средним временем обслуживания [16].
Так же в теории массовогообслуживания принято считать, что входящий поток требований распределен попуассоновскому закону распределения. По определению пуассоновский поток долженудовлетворять трем следующим требованиям: стационарности, отсутствияпоследствия и ординарности.
Поток называетсястационарным, если вероятность поступления k требований в течение промежутка времени t не зависит от момента начала этогопромежутка.
Под отсутствиемпоследствия понимается то, что вероятность поступлений k требований в систему после произвольного момента времени t0не зависит от того, когда и сколько поступилотребований до этого момента времени. Из этого следует взаимная независимостьпоступления того или иного числа требований на обслуживание в непересекающиесяпромежутки времени.
Свойство ординарностиозначает, что вероятность поступления более одного требования за малыйпромежуток времени dT есть величинаболее высокого порядка малости, чем dT. Оно выражает практическую невозможность одновременного поступления двухили более требований.
Стоит отметить, чтомногие реальные потоки являются приближенно пуассоновскими.
Пуассоновский потокполностью определяется одним параметром – интенсивностью потока λ… На практике величину λ находят статистически. При этомодновременно, например, при помощи критерия согласия />, проверяют, действительноли рассматриваемый поток требований с заданной вероятностью можно считатьпуассоновским.
Математический аппараттеории массового обслуживания позволяет определить основные параметры системы:среднее число занятых приборов, вероятность отказа в обслуживании требования,среднюю длину очереди, среднее время простоя требования в очереди и т.д.
Для нас наибольшийинтерес будет представлять среднее число занятых приборов [16]:
/>(3.1)
Где n – количество приборов в системе,
/>,
/> - интенсивность потокатребований,
/> - математическое ожиданиевремени обслуживания одного требования.
/> - вероятность нахождения всистеме ровно k требований
/>(3.2)
Приведенные соотношения позволяютопределить среднее количество заявок, находящихся в системе массовогообслуживания, что будет использовано ниже при построении методики обнаружениярассматриваемой атаки.

3.2 Поток требований СМО
Будем рассматриватьмножество TCP SYN пакетов, поступающих к серверу, в качестве входящегопотока заявок. Покажем, что в определённых условиях этот поток можно считатьпуассоновским.
Интенсивность этогопотока может зависеть от времени, если рассматривать его в течение достаточнобольших промежутков времени. Например, в течение суток в дневное время егоинтенсивность может быть больше, чем ночью. Тем не менее, при уменьшениипродолжительности рассматриваемого промежутка интенсивность поступающих TCP SYN заявок стабилизируется и может рассматриваться какнекоторая постоянная величина. Для различных сетей продолжительность такого промежуткаможет быть разной (как правило, от нескольких минут до нескольких часов) иможет быть установлена экспериментально.
В этом случае вероятностьпоступления k требований в интервале времени (0, t) равна вероятности поступления k требований в любом другом интервалетой же длительности (a, a + t) в пределах заданного промежутка. Таким образом,рассматриваемый поток обладает свойством стационарности.
Далее будем считать, чтопользователи обращаются к ресурсам сервера независимо друг от друга. Если при одномобращении пользователя к серверу устанавливается одно TCP соединение, то поток требований обладает свойствомотсутствия последствия (в соответствии с определением этого свойства [16]). Однаконекоторые приложения прикладного уровня взаимодействуют друг с другомпосредством параллельно установленных TCP соединений. Покажем, что и в этом случае входящий поток обладаетуказанным свойством.
Рассмотрим влияниепроцесса обращения браузера к web-страницена поток TCP SYN пакетов, поступающих к серверу. Как правило,большинство возвращаемых сервером страниц содержат гиперссылки на другиересурсы, такие как изображения, элементы ActiveX, flash-анимациии другие элементы, выводимые на htmlстранице в окне браузера. В соответствии со спецификацией протокола HTTP [17], для получения каждого изресурсов браузер должен сделать отдельный запрос к web серверу, и, следовательно, установить TCP-соединение. Если web-страница содержит i элементов, требующих немедленнойзагрузки, то при выполнении Nобращений количество TCPсоединений будет равно (i+1)N. В этом случае можно рассматривать вкачестве одного требования отправление (i+1) SYNпакетов. Очевидно, что каждое обращение к web-странице можно рассматривать как одну заявку, иинтенсивность потока таких требований будет в (i+1)раз меньше. В предлагаемой далее модели возможно введение дополнительногокоэффициента для учёта объёдинения таких взаимосвязанных SYN пакетов в одну заявку. Объединенные заявкиявляются независимыми, т.к. пользователи обращаются к ресурсам сервера независимодруг от друга. Из этого следует, что входящий поток требований обладаетсвойством отсутствия последствия.
Покажем, что потоктребований является ординарным. Рассмотрим сервер с одним сетевым интерфейсом.По такому подключению одновременно не могут прийти сразу несколько IP пакетов, т.к. в блоке данныхпротоколов канального уровня (Ethernet, DSL-соединение, модемное подключение идр.) может быть максимум один IPпакет [18]. Соответственно, существует некоторый малый промежуток времени, втечение которого может поступить не более одной заявки. Следовательно, длясервера с одним сетевым интерфейсом входной поток TCP SYN пакетов является ординарным.
Таким образом, потокзаявок, содержащих TCP SYN пакеты, поступающие на сервер содним сетевым интерфейсом, обладает свойствами стационарности, ординарности иотсутствия последствия, и в соответствии с определением, такой поток являетсяпуассоновским.

3.3 Сервер TCP соединения как СМО
Как было показано вп.3.2, поток поступающих на сервер TCP SYN пакетов взаданных условиях является пуассоновским. Это значит, что его можнорассматривать как поток требований, поступающих в СМО. Однако для построениямодели удобнее в качестве множества заявок рассматривать эквивалентный емупоток. В нормальном режиме работы в ответ на каждый полученный TCP SYN пакет сервер должен отправить TCP SYN+ACKпакет[10]. Из того, что существуетвзаимнооднозначное соответствие между входящими и исходящими пакетами следуетэквивалентность потоков. Далее в качестве требований СМО будем рассматриватьотправляемые сервером SYN+ACK пакеты. Множеством обслуживающихприборов будем считать ресурсы сервера, предназначенные для хранения параметровTCP соединений. В такой интерпретацииобслуживание требования – это резервирование соответствующих ресурсов либо доуспешного установления TCPсоединения (получения ACKпакета, который должен быть получен в соответствии с [10]), либо до истечения отведенного на сервере таймаута.
Для такой моделипризнаком TCP SYN атаки является резкое увеличение количества заявок вСМО. Находясь под воздействием атаки, сервер выделяет соответствующие ресурсы,которые остаются занятыми в течение отведенного таймаута. Для современныхоперационных систем и сетевых технологий времени таймаута (от десятков секунддо нескольких минут [12]) достаточно чтобы занять вседоступные ресурсы сервера, предназначенные для хранения параметров TCP соединений. Для рассматриваемой намимодели это означает резкое увеличение занятых обслуживающих приборов.
Рассмотрим более детальноресурсы сервера, выступающие в качестве обслуживающих приборов. Параметры TCP соединений хранятся всоответствующем буфере [18], который можно представить в видемассива размерности L, элементыкоторого хранят параметры TCPсоединений. Их можно разделить на три типа: содержащие параметры установленныхсоединений, полуоткрытых соединений и свободные. Пусть B – количество открытых в данный момент TCP соединений. Тогда n = L — B –количество элементов второго и третьего типов, совокупность которых мы будемрассматривать в качестве множества обслуживающих приборов СМО. При этом занятыеобслуживанием требований приборы – это элементы второго типа. На рис. 3.1изображен описанный массив, а на рис. 3.2 показано представление ресурсовсервера в качестве множества обслуживающих приборов.
/>
Рис. 3.2 Сервер TCPсоединения как СМО
Взависимости от соотношения интенсивности входящего потока требований /> и размерности массива L можно рассматривать два типа СМО. Если интенсивностьвходящего потока заявок значительно меньше возможностей сервера, чтосправедливо для большинства современных систем, то целесообразно рассматриватьСМО с бесконечным числом обслуживающих приборов. В противном случае можнорассматривать СМО с отказами. Ввиду того, что на практике в нормальном режимеработы возможности сервера со значительным запасом покрывают входящие требования,то рассмотрение системы с отказами является неактуальным. В дальнейшем будемрассматривать систему первого типа.
3.4 СМО сбесконечным количеством обслуживающих приборовКак уже было показано, для описания модели взаимодействия клиентов исервера TCP соединения в нормальном режиме работыцелесообразно рассматривать СМО с бесконечным числом обслуживающих приборов.Обозначим отношение интенсивности входящего потока требований /> к среднему времениобслуживания заявки /> коэффициентом/>. Т.к. поток требованийявляется пуассоновским, то вероятность того, что в системе находится ровно k требований, определяется как
/>(3.3)
Подставив это значение всоотношение (3.2), описывающее среднее число приборов, занятых обслуживанием(общее число полуоткрытых соединений) получим:
/>(3.4)
Соответственно,
/>(3.5)

Из соотношений (3.4) и(3.5) для СМО с бесконечным числом обслуживающих приборов имеем [16]:
/>(3.6)
Предложенная модель описывает работусервера в нормальном режиме и позволяет учитывать такие параметры, какинтенсивность обращений к серверу и среднее время обслуживания заявки. Однакотакая СМО недостаточно полно описывает работу сервера, т.к. не учитываетвозможность потери пакетов при передаче в современных сетях.
Для усовершенствования предложенноймодели целесообразно разделить рассматриваемую СМО на две системы,обслуживающие заявки на нормальное установление соединения (когда все пакетыдоставлены) и полуоткрытые соединения, удаляемые по таймауту. Для разделенияисходного потока требований на множества заявок для каждой из систем необходимоввести критерий, позволяющий определить принадлежность заявок к вышеописаннымтипам. Для этого в дальнейшем будет использован тот факт, что в большинствеслучаев время прохождения IPпакета между произвольными хостами в Internet не превосходит некоторого порогового значения [19]. Определение этого порогарассмотрено в п.4.1.3.5 Модель, учитывающая потерю пакетов в сети
Как было отмечено выше, предложенная ранее модель требует усреднениясреднего времени обслуживания по всем требованиям, что не в полной мереучитывает особенности процесса установления TCP соединений.Для устранения этого недостатка разделим описанную в п.3.3 СМО на две системы:СМО1 и СМО2. Будем считать, что первая система описывает обслуживание заявок,для которых полуоткрытые соединения будут успешно установлены после получениясервером ACK пакетов, а вторая – требования, длякоторых соединения не будут установлены и после истечения отведенного таймаутабудут удалены.
Как будет показано в п.4.1, в большинстве случаев время обмена паройпакетов между произвольными хостами не превосходит порог />.При условии того, что на клиенте корректно реализован протокол TCP,появление полуоткрытых соединений, которые не установленных в течениепромежутка времени длительностью /> объясняетсяпотерей либо SYN+ACK, либо ACK пакета. Поэтому к требованиямвторого типа будем относить заявки, для которых TCP соединениенаходится в полуоткрытом состоянии дольше чем />. Обозначим через s и l – количества соединений первогои второго типов соответственно. Такое представление сервера изображено нарис.3.4
/>   Рис 3.4. Сервер TCP соединения, как СМО
Определим соотношения, описывающие состояние такой системы. Аналогично(3.6) определим среднее количество полуоткрытых соединений:
/> . (3.7)
Как следует изсоотношения (3.7), среднее число полуоткрытых соединений является случайнойвеличиной, равной сумме двух случайных величин, имеющих пуассоновский законраспределения. Первая из них описывает среднее количество полуоткрытыхсоединений, которые не представляют собой угрозу с точки зрения TCP SYN атаки. Вторая составляющая представляет собойполуоткрытые соединения, которые не будут установлены и через заданныйпромежуток времени (определяемый таймаутом) будут удалены, до этого занимаяресурсы сервера. Как отмечалось выше, увеличение количества таких соединенийявляется признаком TCP SYN атаки. Поэтому в основу методикицелесообразно положить СМО, учитывающую только требования второго типа.
Далее будем рассматриватьв качестве заявки не все SYN+ACK пакеты, для которых сервер ожидаетответный ACK пакет, а только те, для которыхвремя ожидания превышает пороговое значение />, описанное в п.3.5.Очевидно, что при нормальной работе (отсутствии TCP SYN атаки) для каждой такой заявки был потерян либо SYN+ACK, либо ACKпакет. Интенсивность поступления таких заявок определяется следующимсоотношением:
/>(3.8)
где:
/> – интенсивностьпоступающих на вход сетевой карты сервера TCP SYN пакетов
/> – вероятность появления полуоткрытогосоединения, которое не будет установлено
Параметр /> зависит от качества работысети, которое характеризуется вероятностью потери пакета в сети (/>). Методика определенияфактического значения этой вероятности описана в [20]. Найдем зависимость /> от />. Пусть событие A заключается в том, что был потерян SYN+ACK пакет, а событие B представляет собой потерю ACK пакета. Вероятность события A равна вероятности потери пакета в сети:

/>(3.9)
Т.к. событие B может наступить только тогда, когда не наступило событие A (ACK пакет можетбыть отправлен только после получения SYN+ACK пакета[10]), то его вероятностьравна:
/>(3.10)
Рассмотрим событие C, заключающееся в появлениеполуоткрытого соединения второго типа. Оно равно сумме событий A и B. Отсюда с учетом (3.9) и (3.10) получим:
/> (3.11)
Из соотношений (3.8) и(3.11) найдем интенсивность потока требований второго типа:
/>(3.12)
В современных ОС такихкак Windows и Linux, ядро отсылает несколько копий SYN+ACK пакетов до тех пор, пока не будет получен ACK
пакет. Обозначимколичество таких копий параметром />.Тогда интересующее нас событие заключается в том, что ни для одной из копий SYN + ACK пакета не дойдет ответный ACK пакет, и соотношение (3.12) принимает следующий вид:
/>(3.13)

Т.к. интенсивность потокатребований второго типа пропорциональна интенсивности первоначального потока,то он так же является пуассоновским.
Среднее число такихзаявок, находящихся на обслуживании в СМО, определяется вторым слагаемымформулы(3.7):
/>(3.14)
где: />– таймаут отведенный насервере на установление TCPсоединения
/> – вероятностьпотери пакета в сети
/> – количество копий SYN + ACK пакетов отправляемых ОС
Как было показано в п.3.4, СВ характеризующая среднее количество занятыхприборов в СМО рассматриваемого нами типа пуассоновский закон распределения. Внашем случае параметр этого распределения равен l.Известно, что для пуассоновского распределения математическое ожидание идисперсия равны параметру распределения [21] и в нашем случае так же равны l.
На рисунках 3.4 и 3.5 приведены графики плотности распределения и законараспределения случайной величины, распределенной по пуассоновскому закону, спараметром />.
/>

Для определения наличия или отсутствия TCP SYN атаки нам понадобится значениефункции распределения, которое, как известно, определяется следующим образом:
/>(3.15)
При использовании данной модели, признаком TCP SYN атаки является превышениезначения функции распределения от текущего количества полуоткрытых соединенийнекоторого порогового значения Fпор (рис.3.5), которое будет соответствовать вероятности верного обнаружения TCP SYN атаки(вероятности ошибки первого рода).
Достоинствами предлагаемой методики являются возможность своевременного(раннего) обнаружения атаки, ее способность адаптироваться к реальнымпараметрам сети. При значительном увеличении интенсивности обращений к серверусо стороны легальных пользователей количество потерянных пакетов увеличитсяпропорционально вероятности потери пакета в сети. Т.к. для современных сетейэта величина имеет небольшое значение, то эффективность обнаружения снизитсянезначительно. Недостатком является то, что неисправности сетевогооборудования, в результате которых увеличивается вероятность потери пакета всети, будут интерпретированы как TCP SYN атака.
Для того, чтобы иметь возможность эффективно обнаруживать атаку напрактике, необходимы средства, позволяющие определять значения исходныхпараметров модели для конкретного сервера и сети, к которой он подключен.Возможные методики сбора таких данных предлагаются ниже.

4. МЕТОДИКИ СБОРА ДАННЫХ
Для эффективного использования предложенной выше методики на практикенеобходимо иметь возможность определить фактические значения исходныхпараметров модели для системы находящейся в нормальном состоянии (при условии отсутствияатаки). Как было показано выше, такими параметрами являются: интенсивностьпотока заявок (TCP пакетов с установленным SYN флагом), вероятность потери пакетов в сети, к которойподключен сервер и среднее время обслуживания заявки (успешного установления TCP соединения). В этом разделе приведены возможные подходы крешению этой задачи. Более подробно этот материал изложен в [22].
4.1 Определение временипрохождения IP пакета по сети Internet
Значение пороговогозначения /> временипрохождения пакетов между двумя хостами в сети работающей в нормальном режимеможно определить двумя способами. Первый способ – это, накопив довольно большуюстатистику, найти максимальное значение. Более сложный подход основан напроверке гипотезы о законе распределения СВ, описывающей время прохожденияпакетов.
В обоих случаях намнеобходима большая статистика времени прохождения пакетов, наиболее полнопредставляющая генеральную совокупность. Для ее получения была использованаутилита ping.
Известно, что эта утилитапредназначена для проверки качества соединения с удаленным компьютером. Утилитаping работает поверх протокола ICMP (Internet Control Message Protocol). Для проверки соединения судаленным хостом утилита pingпосылает ему ICMP-request, в ответ на который, удаленный хост должен ответитьсообщением ICMP-reply.
Утилита ping позволяет получить статистику длязаданного хоста. Среди прочих данных этой статистики можно определить времяпрохождения каждой пары пакетов с сообщениями ICMP-requestи ICMP-reply между двумя хостами. Именно этот параметр нас иинтересует – время за которое два удаленных хоста обмениваются парой пакетов (внашем случае это TCP SYN+ACK и TCP ACK пакеты).
Для накопления ping статистики были использованыразличные удаленные хосты, физически расположенные в разных странах и на разныхконтинентах. Исходя из этого, можно утверждать, что полученные результатыдостаточно обобщены.
Полученные результатыприведены нарисунках 4.1 – 4.3.
/>
Рис. 4.1. Время возврата пакетов ICMP-reply
На рис. 4.1 и 4.2 приведена упорядоченная повозрастанию статистика времени возврата ICMP-reply. На рис. 4.2 статистика приведенабез учета трех пакетов, время возврата которых в 40 раз превышает времявозврата большинства пакетов. Рис. 4.2 приведен здесь дляпредставления результатов в более крупном масштабе.

/>
Рис. 4.2. Время возврата пакетов ICMP-reply
/>
Рис. 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. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ
Было принято решениереализовать предложенную методику обнаружения TCP SYN атаки в качестве модуля расширения функциональности (plug-in) для системы обнаружения вторжений IDS Snort. В качестве достоинств Snort, которые определили этот выбор можно отметить легко расширяемуюархитектуру, открытость исходного кода. Так же стоит упомянуть, что эта системаспособна работать на большом количестве аппаратных платформ и ОС.
Т.к. в реальности простого обнаружения атакинедостаточно для бесперебойной работы системы, то помимо обнаружения системадолжна обеспечивать отражение атаки. Поэтому модуль расширения функциональностиразрабатывался для модификации системы Snort – IPS Snort_inline. Это система предотвращения вторжений, котораяспособна модифицировать пакеты в реальном режиме времени, по мере того как онипоступают в сеть и/или покидают ее. Такие системы так же называются системами «сактивным ответом». Для того, чтобы IPS моглаконтролировать весь трафик, поступающий и исходящий из сети, она должнарасполагаться на inline устройстве. Поэтому в предложенной реализации Snort_inline работает на Linux-системе,функционирующей в режиме маршрутизатора.
5.1 Особенности установки Snort
Как было сказано выше, целевая система дляразрабатываемого модуля – это Snort_inline. Однако ее установка и настройка занятие,отнимающее много сил и времени. Поэтому на начальных этапах разработка веласьна системе Snort, в то время как мой коллега занимался исследованиемвозможностей snort_inline [22].
Для того чтобы поставить Snort на Linux машину необходимо, предварительно установить некоторые библиотеки:
· libpcap – библиотека работающая на канальном уровне.Используется системой Snort. С помощью нее snortполучает доступ ко всем пакетам поступающим на сетевой интерфейс.
· libpcre – библиотека для работы с регулярными выражениями (regular expressions)
· libipq – используется системой Snort_inline вместо библиотеки libpcap. Это библиотека организации очередей пакетов,которую предоставляет IPtables
Для непосредственной установки системы необходимоввести стандартные команды:
/configure
make
make install
Стоит отметить, что на этапе разработки следуетвызвать скрипт ./configure с опцией –enable-debug.
Настройка системы Snort (как ибольшинства других) дело тонкое, занимающее много времени. Поэтому на начальныхэтапах разработки было принято решение отлаживать модуль расширенияфункциональности на системе работающей со значениями практически всехпараметров установленными по умолчанию. Единственным переопределяемымпараметром был путь к файлу с правилами. Для того чтобы, запустить snort в таком режиме, надо выполнить следующую команду:
/snort –c rules.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»););
}

Здесь вызывается функция RegisterPlugin,предоставляемая snort, которая говорит snort о том,что если в правиле встречаются опции, относящиеся к модулю tcp_syn_flood, то необходимо вызвать функцию TcpSynFloodInit,находящуюся в файле sp_tcp_syn_floodы.с. Реализация функции инициализации будет описананиже.
3. добавить вызов функции SetupTcpSynFlood() в plugbase.c:
· В секции /* custom detection plugin */ добавить
#include«detection-plugins/sp_tcp_syn_flood.h»
· В теле функции InitPlugIns()добавить вызов функции SetupTcpSynFlood();
4. добавить элементPLUGIN_TCP_SYN_FLOOD к перечислению (enum) доступных модулей Snort
Для того чтобы наш модуль был успешно интегрирован вsnort осталось реализовать функцию TcpSynFloodInit(). Это статическая функция, в которой необходимовыделить память для используемых модулем структур данных, проинициализироватьэти структуры данными, указанными в правиле. Здесь стоит отметить, что длякаждого правила, в котором заданы параметры для модуля tcp_syn_flood будет вызвана эта функция.
Здесь так же стоит отметить, что модуль tcp_syn_flood должен генерировать события Snort связанные с началом иокончанием атаки. Для этого его надо зарегистрировать в качестве генераторасобытий Snort. Сделать это проще простого. Надо добавитьсоответствующие объявления в файл ./src/generatos.h:
#define GENERATOR_TCP_SYN_FLOOD 224
#define SYNFLOOD_STARTED "(tcp synflood: PREVED)"
#define SYNFLOOD_FINISHED "(tcp synflood: PAKA)"

В первой строчке мы регистрируем модуль в качествегенератора событий, а дальше идет объявление сообщений, которые могутзаписываться в логи. Как уже было сказано, нам необходимо генерировать двасобытия.
Перед тем как продолжить описание реализации модуляна языке C, следует описать внутреннее устройство модуля ииспользуемых в нем структур данных. Модуль tcp_syn_flood предназначен для обнаружения и возможного отражения TCP SYN атаки. Обе эти функциональности представленыотдельными подмодулями: TcpConnEstTimeChecker и TcpSynFloodPreventionModule.Первый из них предназначен именно для обнаружения атаки с помощью описаннойразделе 3 методики. Он является решающей системой, которая генерирует события snort говорящие о том, что TCP атака началась или закончилась. Второй подмодульпредназначен для накопления «положительной» статистики работызащищаемого сервера при условии атаки. Под положительно статистикой здесьпонимается учет количества успешно установленных TCPсоединений сервера с клиентами. Дифференциация клиентов производится попризнаку их IP адресов и значения поля TTLв приходящих от них пакетах. Если атаканачинается, то накопление статистики приостанавливается, а на основании уженакопленных данных модуль принимает решения от каких клиентов пропускать SYNпакеты к серверу, а от каких нет.
5.3.1 Структура модуля TcpConnEstTimeChecker
Полное название этого модуля Tcp Connection Estimate Time Checker. Онпредназначен для определения количества «просроченных» tcpсоединений и сравнения их количества с допустимым порогом.
Стоит напомнить, что в соответствии с изложенной вразделе 3 методикой необходимо вести учет количества полуоткрытых TCPсоединений, которые находятся в этом состоянии дольше определенного промежуткавремени. Значения указанных параметров этот модуль берет из правила Snort:
· server_timeout_sec – таймаут отведенный на сервере для установки TCPсоединений. Значение этого параметра задается в секундах
· max_overdue_count – максимально допустимое количество полуоткрытых насервере соединений
· max_overdue_count_diviation – разброс максимально допустимого количестваполуоткрытых на сервере соединений. Это значит, что модуль будет генерировать событие«TCP SYN атаканачалась» после того, как на сервере будет (max_overdue_count + max_overdue_count_diviation) полуоткрытых соединений и, соответственно «TCP SYN атака закончилась», когда количество такихсоединений станет меньше чем (max_overdue_count -max_overdue_count_diviation)
· overdue_time_sec – время после которого полуоткрытое соединениесчитается «просроченным». Значение этого параметра задается всекундах
· check_period_sec – период с которым модуль должен проверять текущееколичество полуоткрытых соединений. Как будет показано дальше, операцияпроверки количества просроченных соединений требует больше вычислительныхресурсов, чем просто обработка пакетов. Если этому параметру установитьдовольно большое значение, то атака будет обнаружена позже, а если маленькоезначение, то больше ресурсов системы будет расходоваться на более частыепроверки.
Для того чтобы минимизировать затраты памяти иувеличить быстродействие было принято решение не хранить время прихода пакетовв явном виде. Для определения «возраста» полуоткрытых соединенийиспользуется довольно хитрая структура данных: массив бинарных деревьев. Такоймассив показан на рис.5.1.

/>
Рисунок 5.1 Массив бинарных деревьев, используемыйTcpConnEstTimeChecker.
В узлах каждого из деревьев хранится информация оботдельном полуоткрытом TCP соединении. Эта информация представлена следующейструктурой:
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 withoverdued connections
checker->firstOverduedNodeIndex =checker->overdueTime / checker->checkPeriod;
Так же стоит отметить, что модуле реализованаобработка RST пакетов приходящих как от защищаемого сервера, таки от клиента.
Описанный выше модуль в программной реализациипредставлен в виде следующей структуры и функций работы с ним:
typedef struct _TcpConnEstTimeChecker
{
/*** Опции правила ***/
// time in seconds after which thehalf-open connection is overdue
int overdueTime;
// period in seconds to check the numberof overdue half-open connections
int checkPeriod;
// the max allowed number of half-openconnections
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, whichcontains overdued connections
int firstOverduedNodeIndex;
// time when the last shift was made
time_t lastShiftTime;
// Indicates if Syn Flood atack presents
int atackState;
}
TcpConnEstTimeChecker;
/***Интерфейс***/
voidInitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker, int _overdueTime,
int _checkPeriod, int _overdueUpperBound,int _overdueUpperBoundDiviation,
int _serverTimeout);
voidDeInitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker);
intTcpConnEstTimeChecker_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. В этом случае для введения системы предотвращенияатаки в заблуждения он может генерировать множество TCPSYN пакетов, указывая в качестве адреса отправителяизвестный ему 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
TcpSynFloodPreventionModulePtrpreventionModule;
} 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 TCPSYN атака отсутствует и переменной 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_SYN5
Как видно из приведенного выше фрагмента навнутреннее состояние модуля влияют пришедшие от клиента пакеты с установленнымикомбинациями флагов 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 р.
3. НД ТЗІ1.1-003-99. ТЕРМІНОЛОГІЯ В ГАЛУЗІ ЗАХИСТУ ІНФОРМАЦІЇ В КОМП’ЮТЕРНИХ СИСТЕМАХВІД НЕСАНКЦІОНОВАНОГО ДОСТУПУ
4. http://bezpeka.com
5. http://www.virulist.com
6. http://www.void.ru
7. http://www.webinform.ru
8. http://bugtraq.ru
9. Приказ ДСТСЗИ СБУ30.04.2004 N 31
10. BSI.ITBaseline Protection Manual. Standard Security Measures. Version: October 2000
11. RFC793TransmissionControl Protocol
12. http://www.securityfocus.com/infocus/1729
13. http://www.protocols.ru
14. http://www.preferredtechnology.com
15. http://www.iss.net
16. Г.И. Ивченко.Теория массового обслуживания, М: Высшая Школа, 1982.
17. RFC2616. Hypertext Transfer Protocol – HTTP/1.1.
18. Д. Камер.Сети TCP/IP том 1, изд. дом «Вильямс»М-Санкт-Петербург-Киев 2003
19. http://www.internettrafficreport.com/main.htm
20. http://securitylab.ru
21. Г.Корн, Т.КорнСправочник по математике для научных работников и инженеров М: «НАУКА»,1968.
22. Д.Л. Ясницкий. «Разработка методики раннегообнаружения и отражения распределённых атактипа „отказ в обслуживании“». Магистерская аттестационная работа. Харьков: ХНУРЭ,2006
23. Джей Бил и др. Snort 2.1. Обнаружение вторжений. 2-е изд.Пер. с англ. — М.: ООО «Бином-Пресс», 2006;
24. МедведовскийИ.Д., Семьянов П.В., Платонов В.В. Атака через Internet.
25. http://www.securityfocus.com
26. Д.Л. Ясницкий,В.Д. Литовский, Р.В. Олейников. Методика раннего обнаружения TCP SYN атаки. Прикладная радиоэлектроника. Т.5, Харьков:ХНУРЭ, 2006.
27. Snort-2.4.3source code.
28. http://kiev-security.org.ua
29. http://www.sophist.demon.co.uk/ping
30. http://www.citforum.ru
31. www.computer.org/
32. http://wiki.hping.org/172
33. http://www.snort.org
34. http://www.bsi.de/
35. http://www.linuxsecurity.com

Приложение А
Исходный код модулярасширение функциональности для IPS Snort_inline
// Файл tcp_syn_flood.h
#ifndef__SP_TCP_SYN_FLOOD_H__
#define__SP_TCP_SYN_FLOOD_H__
//TcpSynFloodDefinitions
#defineTcpSynFloodPreventionModulePtr void*
/*** Plugingworking modes ***/
#defineTCP_SYN_FLOOD_DETECTION1
#defineTCP_SYN_FLOOD_PREVENTION2
/***TcpSynFlood atack states ***/
#defineSYN_ATACK_IS_NOT_PRESENT 1
#defineSYN_ATACK_IS_PRESENT 2
/*** Supportedpacket types ***/
#definePACKET_TYPE_UNSUPPORTED 0
#definePACKET_TYPE_SYN_ACK 1
#definePACKET_TYPE_ACK 2
#definePACKET_TYPE_RST_FROM_SERVER 3
#definePACKET_TYPE_RST_FROM_CLIENT 4
#definePACKET_TYPE_SYN 5
/***Prevention module checking packet results ***/
#definePREVENTION_PACKET_IS_OK 1
#definePREVENTION_PACKET_IS_BAD 2
voidSetupTcpSynFlood();
#endif /*__SP_TCP_SYN_FLOOD_H__ */
// Файл tcp_syn_flood.с
#include
#include
#include
#include«rules.h»
#include«decode.h»
#include«plugbase.h»
#include«parser.h»
#include«debug.h»
#include«util.h»
#include«plugin_enum.h»
#include«generators.h»
#include«event_wrapper.h»
#ifdefHAVE_STRINGS_H
#include«mstring.h»
#endif
#include«sp_tcp_syn_flood.h»
#include«tcp_conn_est_time_checker.h»
#include«tcp_syn_flood_prevention_stat.h»
/*
* setup anydata structs here
*/
typedef struct_TcpSynFloodData
{
// the currentmode of the plugin
intworkingMode;
// the IPaddress of the server being protected
struct in_addrserverIP;
// tcpconnection estimate time checker
TcpConnEstTimeChecker*timeChecker;
// preventionmodule
TcpSynFloodPreventionModulePtrpreventionModule;
}TcpSynFloodData;
/* functionprototypes go here */
static voidTcpSynFloodInit(char *, OptTreeNode *, int);
static voidTcpSynFloodRuleParseFunction(char *, OptTreeNode *);
static intTcpSynFloodCheckFunction(Packet *, struct _OptTreeNode *, OptFpList *);
/* internalfunctions prototypes */
intParseIntElement(char* token, char *name);
voidSetupTcpSynFlood()
{
/* map thekeyword to an initialization/processing function */
RegisterPlugin(«tcp_syn_flood»,TcpSynFloodInit);
DEBUG_WRAP(DebugMessage(DEBUG_PLUGIN,«Plugin:TcpSynFlood Setup\n»););
}
static voidTcpSynFloodInit(char *data, OptTreeNode *otn, int protocol)
{
// multipledeclaration check
if(otn->ds_list[PLUGIN_TCP_SYN_FLOOD])
{
FatalError("%s(%d):Multiple tcpsynflood options in rule\n", file_name,
file_line);
}
// allocatethe data structure and attach it to the
// rule's datastruct list
TcpSynFloodData*tcpSynFloodData = (TcpSynFloodData*)SnortAlloc(sizeof(TcpSynFloodData));tcpSynFloodData->workingMode = TCP_SYN_FLOOD_DETECTION;
tcpSynFloodData->preventionModule= TcpSynFloodPreventionCreateModule();
otn->ds_list[PLUGIN_TCP_SYN_FLOOD]= tcpSynFloodData;
TcpSynFloodRuleParseFunction(data,otn);
// finally,attach the option's detection function to the rule's
// detectfunction pointer list
AddOptFuncToList(TcpSynFloodCheckFunction,otn);
}
/** ExpectedRule Structure
#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
*/
static voidTcpSynFloodRuleParseFunction(
char *data,
OptTreeNode*otn)
{
intserver_timeout_sec = 0;
intmax_overdue_count = 0;
intmax_overdue_count_diviation = 0;
intoverdue_time_sec = 0;
intcheck_period_sec = 0;
TcpSynFloodData*tcpSynFloodData;
tcpSynFloodData= otn->ds_list[PLUGIN_TCP_SYN_FLOOD];
while(isspace((int)*data))
data++;
int numTokens;
const intTokensCount = 6;
char **tokens= mSplit(data, ",", TokensCount, &numTokens, 0);
printf(«numtokens%d\n», numTokens );
if(numTokens!= TokensCount)
{
FatalError(«inTcpSynFlood rule: invalid number of init parameters\n»);
}
if(inet_aton(tokens[0],&tcpSynFloodData->serverIP) == 0)
{
FatalError(«inTcpSynFlood rule: %s is invalid ip address\n», tokens[0]);
}
server_timeout_sec= ParseIntElement(tokens[1], «server timeout»);
max_overdue_count= ParseIntElement(tokens[2], «overdue count»);
max_overdue_count_diviation= ParseIntElement(tokens[3], «overdue count diviation»);
overdue_time_sec= ParseIntElement(tokens[4], «overdue time (in seconds)»);
check_period_sec= ParseIntElement(tokens[5], «check period (in seconds)»);
// initchecker
TcpConnEstTimeChecker*checker = (TcpConnEstTimeChecker*)SnortAlloc(sizeof(TcpConnEstTimeChecker));
InitTcpConnEstTimeChecker(checker,
overdue_time_sec,// overdueTime
check_period_sec,// int _checkPeriod
max_overdue_count,// overdueUpperBound
max_overdue_count_diviation,// overdueUpperBoundDiviation
server_timeout_sec//serverTimeout
);
tcpSynFloodData->timeChecker= checker;
printf(«TcpSynFloodmodule initialized with the following parameters:\n»);
printf("\tservertimeout %d\n", server_timeout_sec);
printf("\tmaxoverdue count %d\n", max_overdue_count);
printf("\tmaxoverdue count diviation %d\n", max_overdue_count_diviation);
printf("\toverduetime %d\n", overdue_time_sec);
printf("\theckperiod %d\n", check_period_sec);
// free tokensmemory
mSplitFree(&tokens,numTokens);
}
static intTcpSynFloodCheckFunction(
Packet *p,
struct_OptTreeNode *otn,
OptFpList*fp_list)
{
// Get RuleData
TcpSynFloodData*tcpSynFloodData;
tcpSynFloodData= otn->ds_list[PLUGIN_TCP_SYN_FLOOD];
int packetType= GetPacketType(tcpSynFloodData->timeChecker, p,tcpSynFloodData->serverIP);
if(packetType!= PACKET_TYPE_UNSUPPORTED)
{
// process ACKpackets with prevention module
if(packetType== PACKET_TYPE_ACK)
{
printf(«ProcessingACK\n»);
// check ifatack is absent
int changeStat= (tcpSynFloodData->workingMode == TCP_SYN_FLOOD_DETECTION)?CHANGE_STAT_YES: CHANGE_STAT_NO;
if(changeStat== CHANGE_STAT_YES)
{
// updatestatistics for «good» client
TcpSynFloodPreventionProcessPacket(tcpSynFloodData->preventionModule,p, changeStat);
}
} // processSYN packet with prevetntion module
elseif(packetType == PACKET_TYPE_SYN)
{
printf(«processingSYN\n»);
// check ifatack is present
if(tcpSynFloodData->workingMode== TCP_SYN_FLOOD_PREVENTION)
{
printf(«processingSYN while attack is present\n»);
// get packetstatus
intpacketStatus =TcpSynFloodPreventionProcessPacket(tcpSynFloodData->preventionModule, p,CHANGE_STAT_NO);
if(packetStatus== PREVENTION_PACKET_IS_BAD)
{
printf(«Processingbas SYN\n»);
if(InlineMode())
{
InlineDrop();
}
// else {} //Another type of ActiveReply should be implemented
// For examplesending RST packets to server and client
return 0;
}
}
}
// processpacket with time checker
intcheckerResult =TcpConnEstTimeChecker_ProcessPacket(tcpSynFloodData->timeChecker, p,packetType);
if(checkerResult== SYN_ATACK_IS_PRESENT)
{
// Check ifatack has been started now
if(tcpSynFloodData->workingMode== TCP_SYN_FLOOD_DETECTION)
{
// Generatelog message 'Atack Started'
GenerateSnortEvent(NULL,GENERATOR_TCP_SYN_FLOOD, 0,0,0,3,SYNFLOOD_STARTED);
//change mode
tcpSynFloodData->workingMode= TCP_SYN_FLOOD_PREVENTION;
}
}
else
{
// Check ifatack has been finished now
if(tcpSynFloodData->workingMode== TCP_SYN_FLOOD_PREVENTION)
{
// Generateevent log «ATACK FINISHED»
GenerateSnortEvent(NULL,GENERATOR_TCP_SYN_FLOOD, 0,0,0,3,SYNFLOOD_FINISHED);
//change mode
tcpSynFloodData->workingMode= TCP_SYN_FLOOD_DETECTION;
}
}
}// PACKET ISSUPPORTED
returnfp_list->next->OptTestFunc(p, otn, fp_list->next);
}
intParseIntElement(char* token, char *name)
{
char * tail;
int value =(int) strtol(token, &tail, 10);
if(*tail)
{
FatalError(«inTcpSynFlood rule: %s is invalid %s.\n», token, name);
}
return value;
}
inline intGetPacketType(TcpConnEstTimeChecker* checker, Packet* p, struct in_addripServer)
{
// check IPaddress
struct in_addripSrc = p->iph->ip_src;
struct in_addripDst = p->iph->ip_dst;
u_int8_t flags= p->tcph->th_flags;
if((ipDst.s_addr== ipServer.s_addr) && ((flags ^ R_SYN) == 0))
{
returnPACKET_TYPE_SYN;
}
if((ipSrc.s_addr== ipServer.s_addr) && ((flags ^ R_SYN ^ R_ACK) == 0))
{
returnPACKET_TYPE_SYN_ACK;
}
elseif((ipDst.s_addr == ipServer.s_addr) && ((flags ^ R_ACK) == 0))
{
returnPACKET_TYPE_ACK;
}
elseif((ipSrc.s_addr == ipServer.s_addr) && ((flags ^ R_RST) == 0))
{
returnPACKET_TYPE_RST_FROM_SERVER;
}
elseif((ipDst.s_addr == ipServer.s_addr) && ((flags ^ R_RST) == 0))
{
returnPACKET_TYPE_RST_FROM_CLIENT;
}
returnPACKET_TYPE_UNSUPPORTED;
}
// файл tcp_conn_est_time_checker.h
#ifndef__TCP_CONN_EST_TIME_CHECKER_H__
#define__TCP_CONN_EST_TIME_CHECKER_H__
#include
#include
#include«config.h»
#include«decode.h»
#include«ubi_SplayTree.h»
typedef struct_TcpConnEstTimeChecker
{
/*** RuleOptions ***/
// time inseconds after which the half-open connection is overdue
longoverdueTime;
// period inseconds to check the number of overdue half-open connections
longcheckPeriod;
// the maxallowed number of half-open connections
intoverdueUpperBound;
// thediviation of overdueUpperBound
intoverdueUpperBoundDiviation;
/*** InternalData ***/
// the numberof root nodes in the array
introotNodesCount;
// the arrayof root nodes
ubi_btRoot*rootNodes;
// the indexof the first node, which contains overdued connections
intfirstOverduedNodeIndex;
// time whenthe last shift was made
struct timevallastShiftTime;
// Indicatesif Syn Flood atack presents
intatackState;
}
TcpConnEstTimeChecker;
/*** Inerface***/
voidInitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker, long _overdueTime,
long_checkPeriod, int _overdueUpperBound,
int_overdueUpperBoundDiviation, long _serverTimeout);
voidDeInitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker);
intTcpConnEstTimeChecker_ProcessPacket(TcpConnEstTimeChecker* checker, Packet* p,int packetType);
intShiftRootNodes(TcpConnEstTimeChecker* checker, int GenerationCount);
#endif /*__SP_TCP_SYN_FLOOD_H__ */
// файл tcp_conn_est_time_checker.c
#ifndef__TCP_CONN_EST_TIME_CHECKER_H__
#include«tcp_conn_est_time_checker.h»
#endif
#include«sp_tcp_syn_flood.h»
#include
#include
#include
#include«rules.h»
#include«util.h»
/*********States of Timechecker Tree Node Data ********/
#defineNODE_STATE_SYN_RECEIVED 1
#defineNODE_STATE_SYN_ACK_RECEIVED 2
typedef struct_TimeCheckerTreeNodeData
{
ubi_trNodeNode;
// state ofthe node
int NodeState;
// Sequencenumber for client SYN packet
u_int32_tClientNumber;
// Sequencenumber for server SYN+ACK packet
u_int32_tServerNumber;
}
TChTreeNodeData;
/***TChTreeNodeData manipulation functions ***/
static intTChTreeNodeDataCompareFunc(ubi_trItemPtr ItemPtr, ubi_trNodePtr NodePtr);
static voidTChTreeNodeDataDeleteNode(ubi_btNodePtr NodePtr);
/***TcpConnEstTimeChecker manipulation functions ***/
voidInitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker, long _overdueTime,
long _checkPeriod,int _overdueUpperBound,
int_overdueUpperBoundDiviation, long _serverTimeout)
{
CheckInitParams(_overdueTime,_checkPeriod, _overdueUpperBound, _overdueUpperBoundDiviation,_serverTimeout);
checker->overdueTime= _overdueTime;
checker->checkPeriod= _checkPeriod;
checker->overdueUpperBound= _overdueUpperBound;
checker->overdueUpperBoundDiviation= _overdueUpperBoundDiviation;
// GetrootNodes count
doubleserverTimeout = _serverTimeout;
introotNodesCount = ceil(serverTimeout / _checkPeriod);
checker->rootNodesCount= rootNodesCount;
printf(«NODESCOUNT %d\n», rootNodesCount);
// init thearray of root nodes
checker->rootNodes= (ubi_btRoot*)SnortAlloc(sizeof(ubi_btRoot) * rootNodesCount);
// the indexof the first node with overdued connections
checker->firstOverduedNodeIndex= checker->overdueTime / checker->checkPeriod;
int i;
for(i = 0; i
{
ubi_trInitTree(checker->rootNodes+ i,/* ptr to the tree head */
TChTreeNodeDataCompareFunc,/* comparison function */
ubi_trDUPKEY);
//0); /* donot allow nither OVERWRITE nor DUPLICATES */
}
// get currenttime
structtimezone tz;
gettimeofday(&checker->lastShiftTime,&tz);
//time(&checker->lastShiftTime);
checker->atackState= SYN_ATACK_IS_NOT_PRESENT;
}
voidDeInitTcpConnEstTimeChecker(TcpConnEstTimeChecker* checker)
{
introotNodesCount = checker->rootNodesCount;
// deletetrees
int i;
for(i = 0; i
{
ubi_trKillTree(checker->rootNodes+ i, TChTreeNodeDataDeleteNode);
}
// deletearray
free(checker->rootNodes);
checker->rootNodes= NULL;
}
longGetTimeDifference(struct timeval* time1, struct timeval* time2)
{
long secDiff=time1->tv_sec — time2->tv_sec;
longmicSecDiff = time1->tv_usec — time2->tv_usec;
returnlabs(secDiff)*1000000 + labs(micSecDiff);
}
intTcpConnEstTimeChecker_ProcessPacket(TcpConnEstTimeChecker* checker, Packet* p,int packetType)
{
int i;
/*
// get currenttime
time_tcurTime;
time(&curTime);
//check thetime
int diff =difftime(curTime, checker->lastShiftTime);
*/
struct timevalcurrTime;
structtimezone zone;
gettimeofday(&currTime,&zone);
long diff =GetTimeDifference(&currTime, &checker->lastShiftTime);
if(diff >=checker->checkPeriod)
{
// shift trees
printf(«shiftingtrees\n»);
intgenerationsCount = ((float)diff) / checker->checkPeriod;
ShiftRootNodes(checker,generationsCount);
}
// is used asitem to search
TChTreeNodeData*findNodeData = NULL;
// flag whichindicates if the node is inserted successfully
ubi_trBoolinsertResult;
// if Syn addnode to the tree
if(packetType== PACKET_TYPE_SYN)
{
printf(«processingSYN packet in time checker \n»);
TChTreeNodeData*newNodeData = (TChTreeNodeData*)SnortAlloc(sizeof(TChTreeNodeData));
ubi_trNodePtrnodePtr = &newNodeData->Node;
ubi_btInitNode(nodePtr);
// savesequence number and set NODE_STATE_SYN_RECEIVED
newNodeData->ClientNumber= p->tcph->th_seq;
newNodeData->NodeState= NODE_STATE_SYN_RECEIVED;
// trying toinsert the node to the 0-th tree
insertResult =
ubi_trInsert(checker->rootNodes,nodePtr, (ubi_trItemPtr)newNodeData, NULL);
if(insertResult!= ubi_trTRUE)
{
printf(«failedto add SYN to the tree\n»);
// there isalready the node with the same key in the tree
free(newNodeData);
}
}
// if Syn +Ack
elseif(packetType == PACKET_TYPE_SYN_ACK)
{
printf(«processingSYN + ACK in time checker\n» );
// find thenode that is corresponded to received SYN
findNodeData =(TChTreeNodeData*)SnortAlloc(sizeof(TChTreeNodeData));
findNodeData->NodeState= NODE_STATE_SYN_RECEIVED;
findNodeData->ClientNumber= p->tcph->th_ack — 1;
// run overall trees and try to find the node
for(i = 0; irootNodesCount; i++)
{
TChTreeNodeData*foundNodeData = (TChTreeNodeData*)ubi_trFind(checker->rootNodes + i,findNodeData);
if(foundNodeData!= NULL)
{
// remove nodefrom tree
ubi_trRemove(checker->rootNodes+ i, foundNodeData);
// setAcknowledgement number and update node state to NODE_STATE_SYN_ACK_RECEIVED
foundNodeData->NodeState= NODE_STATE_SYN_ACK_RECEIVED;
foundNodeData->ServerNumber= p->tcph->th_seq;
// insert nodeagain in the tree
insertResult =
ubi_trInsert(checker->rootNodes+ i, foundNodeData, (ubi_trItemPtr)foundNodeData, NULL);
if(insertResult!= ubi_trTRUE)
{
// there isalready the node with the same key in the tree
free(foundNodeData);
}
break;
}
}
free(findNodeData);
}
// if Ack orResets
else if((packetType == PACKET_TYPE_ACK) ||
(packetType ==PACKET_TYPE_RST_FROM_SERVER) ||
(packetType ==PACKET_TYPE_SYN_ACK))
{
TChTreeNodeData*findNodeData = (TChTreeNodeData*)SnortAlloc(sizeof(TChTreeNodeData));
switch(packetType)
{
casePACKET_TYPE_ACK:
printf(«processingACK packet\n»);
findNodeData->NodeState= NODE_STATE_SYN_ACK_RECEIVED;
findNodeData->ClientNumber= p->tcph->th_seq — 1;
findNodeData->ServerNumber= p->tcph->th_ack — 1;
break;
/*
casePACKET_TYPE_RST_FROM_SERVER:
printf(«processingRST from server\n»);
findNodeData->SeqAckNumber= p->tcph->th_ack-1;
break;
casePACKET_TYPE_SYN_ACK:
printf(«processingRST from client\n»);
findNodeData->SeqAckNumber= p->tcph->th_seq-1;
break;
*/
}
// run overall trees and try to Find and Delete node with the given key
for(i = 0; irootNodesCount; i++)
{
ubi_trNodePtrnodePtr = ubi_trFind(checker->rootNodes + i, findNodeData);
if(nodePtr !=NULL)
{
// delete
ubi_trRemove(checker->rootNodes+ i, nodePtr);
free((TChTreeNodeData*)nodePtr);
break;
}
}
free(findNodeData);
}
// checkoverdue connections count
printf(«chekcing\n»);
returnCheckOverdueConnectionsCount(checker);
}
intShiftRootNodes(TcpConnEstTimeChecker* checker, int generationCount)
{
int i;
if(generationCount> checker->rootNodesCount)
{
generationCount= checker->rootNodesCount;
}
// free oldtrees
for( i =(checker->rootNodesCount — generationCount); i rootNodesCount; i++ )
{
ubi_trKillTree(checker->rootNodes+ i, TChTreeNodeDataDeleteNode);
}
// shift
memmove(checker->rootNodes+ generationCount,
checker->rootNodes,(checker->rootNodesCount — generationCount) * sizeof(ubi_btRoot));
// init newtrees
for(i = 0; i
{
ubi_trInitTree(&checker->rootNodes[i],/*ptr to the tree head */
TChTreeNodeDataCompareFunc,/* comparison function */
ubi_trDUPKEY);/* allow duplicates */
}
structtimezone zone;
gettimeofday(&checker->lastShiftTime,&zone);
return 0;
}
intCheckOverdueConnectionsCount(TcpConnEstTimeChecker* checker)
{
int resCount =0;
int i;
for(i =checker->firstOverduedNodeIndex; i rootNodesCount; i++ )
{
resCount +=ubi_trCount(checker->rootNodes + i);
}
intcurrentlyAllowedBound;
if(checker->atackState== SYN_ATACK_IS_PRESENT)
{
// subtractdiviation from the bound
currentlyAllowedBound= checker->overdueUpperBound — checker->overdueUpperBoundDiviation;
}
else
{
// adddiviation to the bound
currentlyAllowedBound= checker->overdueUpperBound + checker->overdueUpperBoundDiviation;
}
// savecurrent atack state
checker->atackState= (resCount > currentlyAllowedBound )? SYN_ATACK_IS_PRESENT:SYN_ATACK_IS_NOT_PRESENT;
printf(«checkoverdued: %d — %d\n», currentlyAllowedBound, resCount);
returnchecker->atackState;
}
voidCheckInitParams(int _overdueTime,int _checkPeriod,
int_overdueUpperBound, int _overdueUpperBoundDiviation,
int_serverTimeout)
{
if(_overdueTime
{
FatalError(«TcpConnectionEstimateTimeChecker::_overdueTime must be > 0\n»);
}
if(_checkPeriod
{
FatalError(«TcpConnectionEstimateTimeChecker::_checkPeriod must be > 0\n»);
}
if(_overdueUpperBound
{
FatalError(«TcpConnectionEstimateTimeChecker::_overdueUpperBound must be > 0\n»);
}
if(_overdueUpperBoundDiviation
{
FatalError(«TcpConnectionEstimateTimeChecker::_overdueUpperBoundDiviation must be > 0\n»);
}
if((_overdueUpperBound- _overdueUpperBoundDiviation)
{
FatalError(«TcpConnectionEstimateTimeChecker::(_overdueUpperBound — _overdueUpperBoundDiviation) must be > 0\n»);
}
if((_overdueUpperBound+ _overdueUpperBoundDiviation) > _serverTimeout)
{
FatalError(«TcpConnectionEstimateTimeChecker::(_overdueUpperBound + _overdueUpperBoundDiviation) must be
}
if(_serverTimeout
{
FatalError(«TcpConnectionEstimateTimeChecker::_serverTimeout must be > 0\n»);
}
if(_overdueTime> _serverTimeout)
{
FatalError(«TcpConnectionEstimateTimeChecker::overdue time can't be greater than server timeout\n»);
}
if(_serverTimeout
{
FatalError(«TcpConnectionEstimateTimeChecker::_serverTimeout must be greater than _checkPeriod\n»);
}
}
/* Returns -1if A
Returns 1 if A> B
Returns 0 if A= B
At firstClient number is checked.
Than ifneccessary Server nubmer is checked
*/
static intTChTreeNodeDataCompareFunc(ubi_trItemPtr ItemPtr, ubi_trNodePtr NodePtr)
{
TChTreeNodeData*A = (TChTreeNodeData *) ItemPtr;
TChTreeNodeData*B = (TChTreeNodeData *) NodePtr;
if(A->ClientNumberClientNumber)return -1;
if(A->ClientNumber== B->ClientNumber)return 0;
else // checkcurr node state
if(B->NodeState== NODE_STATE_SYN_ACK_RECEIVED)
{
if(A->ServerNumberServerNumber) return -1;
if(A->ServerNumber== B->ServerNumber) return 0;
else return 1;
}
else // stateis NODE_STATE_SYN_RECEIVED
{
return 1;
}
}
static voidTChTreeNodeDataDeleteNode(ubi_btNodePtr NodePtr)
{
free(NodePtr);
}
// файл tcp_syn_flood_prevention_stat.h
#ifndef_TCP_SYN_FLOOD_PREVENTION_STAT_H_
#define_TCP_SYN_FLOOD_PREVENTION_STAT_H_
//#include«config.h»
#include«decode.h»
#include«sp_tcp_syn_flood.h»
#include«ubi_SplayTree.h»
#defineCHANGE_STAT_YES 1
#define CHANGE_STAT_NO2
typedef struct_TcpSynFloodPreventionModule
{
// the root ofthe statistics tree
ubi_btRootPtrrootStat;
longtotalPacketsCount;
}TcpSynFloodPreventionModule;
// Creates andinitializes the prevention module
void*TcpSynFloodPreventionStatCreateModule();
voidTcpSynFloodPreventionStatDeinitModule(TcpSynFloodPreventionModule*preventionModule);
intTcpSynFloodPreventionStatProcessPacket(TcpSynFloodPreventionModule*preventionModule, Packet* packet, int changeStat);
// Unified TcpSyn Flood prevention interface
#defineTcpSynFloodPreventionProcessPacket( module, p, changeStat )TcpSynFloodPreventionStatProcessPacket( (TcpSynFloodPreventionModule*) (module),(Packet*) (p), (int) (changeStat) )
#defineTcpSynFloodPreventionCreateModule TcpSynFloodPreventionStatCreateModule
#defineTcpSynFloodPreventionDeinitModule( module )TcpSynFloodPreventionStatDeinitModule( (TcpSynFloodPreventionModule*) (module))
#endif
// файл tcp_syn_flood_prevention_stat.c
#ifndef_TCP_SYN_FLOOD_PREVENTION_STAT_H_
#include«tcp_syn_flood_prevention_stat.h»
#endif
typedef struct_TcpSynFloodPreventionStatTreeNodeData
{
// the node inwhich data is stored
ubi_trNodeNode;
// Fields toidentify from what client the packet has came
u_int8_t ttl;
struct in_addripSrc;
// the numberof packets with TTL=ttl and IPSrc=ipSrc that've been processed
long counter;
}TcpSynFloodPreventionStatTreeNodeData;
/***TcpSynFloodPreventionStatTreeNodeData manipulation functions ***/
static intTcpSynFloodPreventionStatTreeNodeDataCompareFunc(ubi_trItemPtr ItemPtr,ubi_trNodePtr NodePtr);
static voidTcpSynFloodPreventionStatTreeNodeDataDeleteNode(ubi_btNodePtr NodePtr);
void*TcpSynFloodPreventionStatCreateModule()
{
TcpSynFloodPreventionModule*newModule = (TcpSynFloodPreventionModule*)SnortAlloc(sizeof(TcpSynFloodPreventionModule));
newModule->totalPacketsCount= 0l;
int* a =(int*)SnortAlloc(10);
newModule->rootStat= (ubi_btRootPtr)SnortAlloc(sizeof(ubi_btRoot));
ubi_trInitTree(newModule->rootStat,/*ptr to the tree head */
TcpSynFloodPreventionStatTreeNodeDataCompareFunc,/* comparison function */
0); /* do notallow nither OVERWRITE nor DUPLICATES */
returnnewModule;
}
voidTcpSynFloodPreventionStatDeinitModule(TcpSynFloodPreventionModule*preventionModule)
{
// kill tree
ubi_trKillTree(preventionModule->rootStat,TcpSynFloodPreventionStatTreeNodeDataDeleteNode);
free(preventionModule->rootStat);
free(preventionModule);
}
intTcpSynFloodPreventionStatProcessPacket(TcpSynFloodPreventionModule* module,Packet* packet, int changeStat)
{
// try to find
TcpSynFloodPreventionStatTreeNodeData*findNodeData =(TcpSynFloodPreventionStatTreeNodeData*)SnortAlloc(sizeof(TcpSynFloodPreventionStatTreeNodeData));
findNodeData->ipSrc= packet->iph->ip_src;
findNodeData->ttl= packet->iph->ip_ttl;
TcpSynFloodPreventionStatTreeNodeData*currNodeData = (TcpSynFloodPreventionStatTreeNodeData*)ubi_trFind(module->rootStat, findNodeData);
// updatestatistics
if(changeStat== CHANGE_STAT_YES)
{
if(currNodeData== NULL)
{
// add newnode to the tree
TcpSynFloodPreventionStatTreeNodeData*newNodeData =(TcpSynFloodPreventionStatTreeNodeData*)SnortAlloc(sizeof(TcpSynFloodPreventionStatTreeNodeData));
newNodeData->ipSrc= findNodeData->ipSrc;
newNodeData->ttl= findNodeData->ttl;
ubi_trNodePtrnewNodePtr = &newNodeData->Node;
ubi_trInsert(module->rootStat,newNodePtr, (ubi_trItemPtr)newNodeData, NULL);
currNodeData =newNodeData;
}
module->totalPacketsCount++;
currNodeData->counter++;
printf(«statsis updated %d \n», currNodeData->counter);
}
free(findNodeData);
// Make thedecision if the packet is bad
if(currNodeData== NULL) return PREVENTION_PACKET_IS_BAD;
double avg =0;
doublenodesCount = ubi_trCount(module->rootStat);
if(nodesCount!= 0)
{
avg =module->totalPacketsCount / nodesCount;
}
if(currNodeData->counter>= avg)
{
printf(«packetis OK\n»);
returnPREVENTION_PACKET_IS_OK;
}
else
{
printf(«packetis BAD\n»);
returnPREVENTION_PACKET_IS_BAD;
}
}
/* Returns -1if A
Returns 1 if A> B
Returns 0 if A= B */
static intTcpSynFloodPreventionStatTreeNodeDataCompareFunc(ubi_trItemPtr ItemPtr,ubi_trNodePtr NodePtr)
{
TcpSynFloodPreventionStatTreeNodeData*A = (TcpSynFloodPreventionStatTreeNodeData *) ItemPtr;
TcpSynFloodPreventionStatTreeNodeData*B = (TcpSynFloodPreventionStatTreeNodeData *) NodePtr;
if((A->ipSrc.s_addr== B->ipSrc.s_addr) && (A->ttl == B->ttl))
return 0;
else
{
if(A->ipSrc.s_addripSrc.s_addr)
return -1;
elseif(A->ipSrc.s_addr > B->ipSrc.s_addr)
return 1;
else
return(A->ttl ttl )? -1: 1;
}
}
static voidTcpSynFloodPreventionStatTreeNodeDataDeleteNode(ubi_btNodePtr NodePtr){
free(NodePtr);
}

Приложение Б
Исходный кодвспомогательной утилиты
Утилита предназначена для:
·  Извлечения из html страницы списка пингуемых хостов
·  Извлечение из логов пингованиявремени отклика
·  Анализ распределения полученныхизвлеченных значений времени
namespacepings{
class Class1{
public staticvoid ExtractUrls(string FileName){
StreamReadersr = new StreamReader(FileName);
StreamWritersw = new StreamWriter(«run_pings.cmd»);
string content= sr.ReadToEnd();
string pattern= @«href=.*»"";
System.Text.RegularExpressions.MatchCollectionmatches = Regex.Matches(content, pattern );
foreach(Matchmatch in matches){
string val =match.Value;
if(val.IndexOf(«viacom.local»)> -1) continue;
val =val.Replace(«href=», "");
val =val.Replace(«http://», "");
val =val.Replace(@"""", "");
val =val.Replace("/", "");
sw.WriteLine(«ping» + Regex.Split(val, ":")[0]);
}
sr.Close();
sw.Close();
}
public staticvoid ExtractPingTime(string FileName){
StreamReadersr = new StreamReader(FileName);
StreamWritersw = new StreamWriter(«extracted_time.txt»);
string str;
int count = 0;
while((str =sr.ReadLine()) != null){
if(str !=string.Empty){
string []tokens = str.Split();
foreach(stringtoken in tokens){
if(token.IndexOf(«time=»)> -1){
count ++;
sw.WriteLine(token.Replace(«time=»,"").Replace(«ms», ""));
}
}
}
}
sr.Close();
sw.Close();
}
public staticvoid Usage(){
Console.WriteLine(«pings »);
Console.WriteLine("option={url, time}");
}
[STAThread]
static voidMain(string[] args){
if(args.Length== 2){
switch(args[0]){
case«url»:
ExtractUrls(args[1]);
break;
case«time»:
ExtractPingTime(args[1]);
break;
}
}
else{
Usage();
}
}
}
}