Специальные настройки для хостинга

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

Уравнение (2.3) определяет два пути для повышения устойчивости к атакам ботнетов [31]. Первый путь состоит в повышении количества одновременно обрабатываемых запросов. Это достигается путем распараллеливания обработки запросов, когда высокопроизводительный сервер распределяет запросы по нескольким синхронизированным базам, часто разнесенным по географическому признаку. Есть даже специальные хостинги с применением технологии Content Delivery Network [32].

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

Проведение этих двух мероприятий позволяет без особых затрат увеличить количество обрабатываемых запросов с 40 до 10 000 в секунду (параметр из уравнения (1)). Дальнейшее повышение требует применения специальных технологий.

Есть еще один резерв повышения производительности. Как известно, разные страницы информационного ресурса по-разному востребованы пользователями. Обычно, популярность (количество запросов) описывается распределением Зипфа. Это ранговое распределение, в котором документы располагаются в порядке убывания популярности, следуя зависимости (2.1)

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

Выводы

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

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

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

Литература

[1] Singh S., Gyanchandani M. Analysis of Botnet behavior using Queuing theory //International Journal of Computer Science & Communication. – 2010.
– ISSN: 0973-7391. – Т. 1. – №. 2. – С. 239-241.

[2] Stanton J. M., Stam K. R., Mastrangelo P., Jolton, J. Analysis of end user security behaviors //Computers & Security. – 2005. – ISSN: 0167-4048. – DOI: 10.1016/j.cose.2004.07.001. – Т. 24. – №. 2. – С. 124-133.

[3] Hochheiser, H. Shneiderman, B. Understanding patterns of user visits to web sites: interactive starfield visualizations of WWW log data //Proceedings of the ASIST Annual Meeting – 1999. – ISSN 0044-7870.

[4] Mirkovic J., Reiher P. A taxonomy of DDoS attack and DDoS defense mechanisms //ACM SIGCOMM Computer Communication Review. – 2004. – ISSN: 0146-4833. – DOI: 10.1145/997150.997156. – Т. 34. – №. 2. – С. 39-53.

[5] Douligeris C., Mitrokotsa A. DDoS attacks and defense mechanisms: classification and state-of-the-art //Computer Networks. – 2004. – ISSN: 1389-1286. – DOI: 10.1016/j.comnet.2003.10.003. – Т. 44. – №. 5. – С. 643-666.

[6] Jiang J., Papavassiliou S. Detecting network attacks in the internet via statistical network traffic normality prediction //Journal of Network and Systems Management. – 2004. – Т. 12. – №. 1. – С. 51-72.

[7] Feinstein L. et al. Statistical approaches to DDoS attack detection and response //DARPA Information Survivability Conference and Exposition, 2003. Proceedings. – IEEE, 2003. – Т. 1. – С. 303-314.

[8] Bhuyan M. H., Bhattacharyya D. K., Kalita J. K. Information metrics for low-rate DDoS attack detection: A comparative evaluation //Contemporary Computing (IC3), 2014 Seventh International Conference on. – IEEE, 2014. – С. 80-84.

[9] Sun C., Liu B., Shi L. Efficient and low-cost hardware defense against DNS amplification attacks //IEEE GLOBECOM 2008-2008 IEEE Global Telecommunications Conference. – IEEE, 2008. – С. 1-5.

[10] Tan Z. et al. A system for denial-of-service attack detection based on multivariate correlation analysis //IEEE transactions on parallel and distributed systems. – 2014. – Т. 25. – №. 2. – С. 447-456.

[11] Li B., Springer J., Bebis G., Hadi Gunes M. A survey of network flow applications //Journal of Network and Computer Applications. – 2013. – ISSN: 1084-8045. – DOI: 10.1016/j.jnca.2012.12.020. – Т. 36. – №. 2. – С. 567-581.

[12] Proto A., Alexandre L. A., Batista M. L., Oliveira I. L., Cansian,A. M. Statistical model applied to netflow for network intrusion detection //Transactions on computational science XI. – Springer Berlin Heidelberg, 2010. – ISBN: 978-3-642-17696-8. – ISSN: 0302-9743. – DOI: 10.1007/978-3-642-17697-5_9. – С. 179-191.

[13] Sawaya Y., Kubota A., Miyake Y. Detection of attackers in services using anomalous host behavior based on traffic flow statistics //Applications and the Internet (SAINT), 2011 IEEE/IPSJ 11th International Symposium on. – IEEE, 2011. – ISBN: 978-1-4577-0531-1. – DOI: 10.1109/SAINT.2011.68. – С. 353-359.

[14] Siaterlis C., Maglaris V. Detecting incoming and outgoing DDoS attacks at the edge using a single set of network characteristics //10th IEEE Symposium on Computers and Communications (ISCC'05). – IEEE, 2005. – С. 469-475.

[15] Sukhov A. M., Sidelnikov D. I., Platonov A. P., Strizhov M. V., Galtsev A. A. Active flows in diagnostic of troubleshooting on backbone links //Journal of High Speed Networks. – 2011. – ISSN: 0926-6801. – DOI: 10.3233/JHS-2011-0447. – Т. 18. – №. 1. – С. 69-81.

[16] Zipf G. K. Relative frequency as a determinant of phonetic change //Harvard Studies in Classical Philology. – 1929. – С. 1-95.

[17] Крашаков С. А., Теслюк А. Б., Щур Л. Н. Об универсальности рангового распределения популярности веб-серверов //Вестник РФФИ. – 2004. – ISSN: 1605-8070.– С. 46-66.

[18] Geva M., Herzberg A., Gev Y. Bandwidth Distributed Denial of Service: Attacks and Defenses //IEEE Security & Privacy. – 2014. – Т. 12. – №. 1. – С. 54-61.

[19] Glassman S. A caching relay for the World Wide Web //Computer Networks and ISDN Systems. – 1994. – v. 27. – n. 2. – p. 165-173.

[20] Dorogovtsev S. N., Mendes J. F. F. Evolution of networks: From biological nets to the Internet and WWW. – Oxford University Press, 2013.

[21] W.Lee and S. J. Stolfo. Data mining approaches for intrusion detection, Proceedings of the 7th USENIX Security Symposium

[22] X. Ye, Countering ddos and xdos attacks against web services, in IEEE/IFIP International Conference on Embedded and Ubiquitous Computing, vol. 1, 2008, pp. 346–352

[23] D. Menasce, V. Almeida, Capacity planning for Web performance: Metrics, models, and methods, Prentice Hall, NJ, 1998 (ISBN 0136938221 )

[24] A. Greenhalgh, F. Huici, M. Hoerdt, P. Papadimitriou, M. Handley, and L. Mathy. Flow Processing and The Rise of Commodity Network Hardware. SIGCOMM CCR, Apr. 2009

[25] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing. RFC 2827, May 2000

[26] K.J. Houle, G.M. Weaver, Trends in denial of service attack technology, CERT, October 2001

[27] G. Gu, R. Perdisci, Junjie Zhang, and W. Lee. BotMiner: Clustering analysis of network traffic for protocol- and structure-independent botnet detection. In Proceedings of the 17th USENIX Security Symposium (Security’08), San Jose, CA, July 2008

[28] A. Karasaridis, B. Rexroad, and D. Hoeflin. Wide-scale botnet detection and characterization. In USENIX Workshop on Hot Topics in Understanding Botnets (HotBots'07), 2007

[29] Y. Wang, H. Yang, X. Wang, and R. Zhang, Distributed intrusion detection system based on data fusion method, Intelligent control and automation, WCICA 2004

[30] KANDULA, S., SENGUPTA, S., GREENBERG, A., PATEL, P., AND CHAIKEN, R. The Nature of Data Center Traffic: Measurements & Analysis. In Proceedings ACM IMC 2009

[31] R. Sommer and V. Paxson. Outside the Closed World: On Using Machine Learning For Network Intrusion Detection. In Proceedings of the IEEE Symposium on Security and Privacy, 2010

[32] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and F.Jahanian, “Internet Traffic and Content Consolidation,” 77th Internet Engineering Task Force, 2010

3. ИЗУЧЕНИЕ ПОЛЬЗОВАТЕЛЬСКОЙ АУДИТОРИИ ДЛЯ ЗАДАЧ СЕТЕВОЙ БЕЗОПАСНОСТИ

Постановка задачи

В этой главе пойдёт речь о методах противодействия DDoS атакам [1,2] (Distributed Denial of Service, распределённая атака типа «отказ в обслуживании») – это такой тип атак, при котором некоторое множество компьютеров в сети Интернет, называемых «зомби», «ботами» или бот сетью (ботнет), по команде злоумышленника начинают отправлять запросы на сервис жертвы. Такие сети имитируют действия обычных пользователей [3], поэтому их крайне сложно выявить и заблокировать. Когда число запросов превышает возможности серверов жертвы, новые запросы от настоящих пользователей перестают обслуживаться и становится недоступным. При этом жертва несёт финансовые убытки.

Задачи обеспечения надёжности и безопасности Интернет сервисов требуют изучения поведения пользователей [4,5] на конкретном ресурсе. Все пользователи Интернет сервиса могут быть разделены на две категории: пользовательское ядро и новички. К пользовательскому ядру следует отнести тех посетителей, которые регулярно обращаются к исследуемому ресурсу [6]. Причем перерывы по времени между обращениями от одного пользователя могут достигать нескольких недель. Первой задачей данного исследования является определение периода времени, за которое анализ статистики посещений позволит выявить пользовательское ядро, вторая задача состоит в том, чтобы оценить предельную долю адресов из пользовательского ядра в общей базе IP адресов.

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

При отражении DDoS атаки можно использовать разные стратегии обороны. Например, искать классификационные признаки IP адресов, с которых происходит атака, и по ним ограничивать доступ к ресурсу [8]. Однако в начале атаки всегда требуется время на распознание особенностей атаки, формулировку квалификационных признаков для нежелательных запросов и идентификацию атакующих IP адресов. Длительность этих операций может достигать нескольких часов, в течение которых сервис может быть недоступен. В это время можно обрабатывать запросы только постоянной аудитории, то есть пользовательского ядра. Знание статистических особенностей поведения новых пользователей облегчит поиск типов атакующих запросов и формирование списков блокировки доступа атакующих IP адресов.

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

3.2.Обзор предшествующих работ

Множество работ посвящено обнаружению несанкционированных вторжений при помощи анализа данных протокола NetFlow. Достаточно полный обзор можно найти в статье [9]. Среди методов обнаружения вторжений можно отметить статистический подход [10,11], когда анализ информации о потоках с помощью простейших законов теории вероятности позволяет выявить источники атак. Статистический подход отличается простотой, даёт надежные результаты, но область применения ограничена хорошо изученными типами атак.

Неизвестные методы вторжений требуют для обнаружения более сложных подходов, таких как различные схемы машинного обучения [12]. Для обнаружения новых угроз используются нейронные сети [13], генетические алгоритмы [14], опорные векторные машины [15] и т.д.

Наш подход [16] имеет отличительные особенности. Во-первых, обнаружение атаки базируется на отклонениях от распределения Зипфа [17]. Для этого анализируется информация об активных или завершённых потоках за некоторый промежуток времени. Минимальное время сбора статистики NetFlow может варьироваться от одной до пяти минут. При нормальном функционировании сети ранжированный список количества потоков, генерируемых уникальным IP адресом, представляет типичное распределение Зипфа [18].

Атакующие адреса могут быть идентифицированы по превышению установленного порогового значения для числа активных или завершённых потоков [16]. Во время атак число потоков возрастает многократно.

Однако этот метод не будет работать для атаки типа «UDP flood», при которой не меняются порты источника и назначения пакетов [19]. В этом случае число потоков с одного атакующего IP адреса будет небольшим, в то же время скорость потока может достигать десятков Мбит/с. Поэтому необходим дополнительный критерий для обнаружения атаки указанного типа.

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

3.3.Выявление пользовательского ядра Интернет сервиса

Для выявления пользовательского ядра Интернет сервиса можно использовать любые журналы доступа, в которые вносятся IP адреса посетителей, либо данные NetFlow. В рассматриваемом в данной работе случае атака проводится на веб сервер популярного Интернет портала, поэтому в качестве источника IP адресов используются файлы журналоввеб сервера Nginx, работающего в операционной системе Debian GNU/Linux. IP адреса посетителей заносятся в базу данных и в дальнейшем считаются принадлежащими пользовательскому ядру. После формирования ядра, пользователи, IP адреса которых не внесены в базу данных, считаются новыми.

На Рис. 3.1 изображён график измерения доли новых IP адресов в ежесуточной аудитории. Под долей понимается отношение количества IP адресов новых посетителей к их общему числу за каждые сутки.

Рисунок 3.1 - График зависимости доли новых IP адресов за сутки от времени, прошедшего с начала измерений

Из графика видно, что через четыре-шесть недель с начала сбора статистики процент новых IP адресов, с которых происходят посещения сайта, стабилизируется в интервале от 30 до 40%.

Для того чтобы понять структуру аудитории необходимо построить ранжированные списки пользовательских IP адресов [18]. В качестве величины для упорядочивания следует выбрать частоту посещений с каждого адреса, а пользовательские IP адреса расположить в порядке убывания данной частоты. В качестве ранга будет использован порядковый номер IP адреса в убывающем списке, тогда функция и будет искомым ранговым распределением.

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

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

Журналы доступа веб сервера Nginx позволяют получить зипфоподобное (Zipf like) распределение, изображенное на Рис. 3.2. Здесь – это количество запросов с одного IP адреса, а n ранг этого запроса, т.е. порядковые номера IP адресов в списке по убыванию количества запросов.

Рисунок 3.2 - Распределение Зипфа для посещений, зафиксированных в журнале доступа

Условно график можно разделить на две части. Вначале идёт пологая часть, а затем резкий спад количества посещений с одного IP адреса. В исследуемом случае спад начинается с 55 запросов на IP адрес в сутки. Анализ содержимого запросов позволяет сделать вывод о том, что с IP адресов в пологой части делаются запросы ко всем документам с загружаемой HTML страницы, то есть закачиваются картинки, скрипты, стили и другие, подключаемые на странице, файлы. В части спада запрашиваются только HTML страницы, которые генерируются каждый раз заново, что говорит о том, что остальные файлы уже были сохранены в кэше браузера пользователя, а значит, он ранее уже посещал данный сайт. Стоит отметить, что пользователи, запросившие от 1 до 3 файлов, как правило, вообще не заходили на сайт, а загрузили картинку с сайта через поисковую систему или обновили RSS ленту.

Версию кэширования подтверждает и аналогичное ранговое распределение, построенное с учётом запросов только HTML файлов и другого содержимого, которое не остаётся в кэше браузера пользователя (см. Рис. 3.3).

Рисунок 3.3 - Распределение Зипфа для запросов к обновляемым данным

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

Статистика NetFlow для новых IP адресов за сутки даёт похожий результат, изображенный на Рис. 3.4.

Рис. 4. Суточная статистика посещений для новых адресов по данным NetFlow.

На Рис. 3.5 изображена суточная статистика посещений по данным NetFlow для всех адресов, включая новые и встречавшиеся ранее. Этот график наиболее близок к прямой.

Рисунок 3.5 – Полная суточная статистика посещений по данным NetFlow

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

Рисунок 3.6 – Ранговое распределение посещений сайта за пять месяцев

Ранжированный список показывает, что большинство пользователей посещали сайт только в течение одних суток. Однократные посещения зафиксированы с более чем 590 тысяч адресов из 775 тысяч, что составляет 76.2% от общего количества адресов. Назовем IP адреса, с которых посещения фиксировались только в течение одних суток, случайными IP адресами. Сравнивая данные из списка случайных IP адресов со списком новых IP адресов за сутки, получается, что доля случайных IP адресов среди новых IP адресов составляет 91±5%. Этот факт объясняет большой процент новых IP адресов в суточной аудитории. Предсказать IP адреса таких посетителей невозможно.

3.4.Формирование списка постоянных посетителей

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

Он будет не полон, так как часть IP адресов выбирается из блоков динамических адресов Интернет провайдеров. Для пополнения списка IP адресов был разработан специальный скрипт, в основе которого лежит нижеследующий алгоритм. В качестве исходных данных берётся список IP адресов, с которых производились запросы к сайту за время стабилизации количества новых IP адресов (четыре-шесть недель в исследуемом случае). Адреса разбиваются на группы по сетевой маске /24. Если группа заполнена адресами на 30%, то блок IP адресов по маске /24 заносится целиком в список IP адресов пользовательского ядра. Если группа заполнена меньше, чем на 30%, то она разбивается на две равные части по сетевой маске /25. Аналогичная операция по проверке заполнения и расширению ядра выполняется для полученных частей. Если какой-то из блоков адресов заполнен меньше порогового значения в 30%, то операция повторяется до сетевой маски /29 включительно.

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

Применение разработанного скрипта дополнения базы данных позволило увеличить число входящих в неё адресов с 273030 до 393273, то есть на 44%. На Рис. 3.7 изображён график зависимости процента новых IP адресов за сутки от времени, пошедшего с начала измерений, с учетом дополнения базы данных. После расширения ядра доля новых адресов находится в интервале от 25 до 35%.

Рисунок 3.7 – Доля новых адресов с учетом расширения базы

При определении момента начала атаки, необходимо иметь в виду, что общее количество запросов различается как по дням недели, так и по времени суток, но эти показатели цикличны. Например, на Рис. 3.8 видно, что количество запросов с 2 до 5 часов ночи более чем в 5 раз ниже, чем количество запросов с 10 часов утра до 16 часов дня. Количество запросов в выходные дни в 2-3 раза ниже, чем в будни.

Рисунок 3.8 – Количество запросов по дням недели и часам

На Рис. 3.9 изображён типичный суточный график изменения числа завершённых потоков за рабочий день. Сбор данных о потоках происходит каждые пять минут. В случае начала реальной атаки число активных потоков возрастёт, как минимум, на порядок.

Рисунок 3.9 – Суточный график изменения количества завершившихся потоков

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

,

где – среднее количество уникальных IP адресов за сутки. Время также следует исчислять в сутках. Для времени t, равного 6 часам (0.25 суток) и следует, что всего 8% от среднесуточной аудитории будет отказано в обслуживании.

3.5.Защитная инфраструктура и её испытания

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

Рисунок 3.10 – Сетевая инфраструктура для проведения исследований.

Эта инфраструктура включает следующие элементы:

– NetFlow установлен на граничном маршрутизаторе Cisco ASR 1001;

– специальный скрипт на базе NetFlow, который выделяет адреса, генерирующие число потоков выше порогового значения и заносящее их в стоп лист для последующей блокировки;

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

– дополнительный маршрутизатор Cisco 2811 перед атакуемым сервером, на котором устанавливались стоп листы;

– коммутатор 3Com 4500 используется для дублирования сетевого трафика с порта, идущего к веб серверу, на сервер, с установленным сетевым сниффером tcpdump [20], который сохраняет весь трафик в файл для последующего анализа;

– специально сформированный список постоянных посетителей, который активируется в момент начала атаки для ограничения посетителей атакуемого сайта.

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

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

Атака на количество запросов к веб серверу выполнялась с помощью Apache HTTP server benchmarking tool [21], Low Orbit Ion Cannon [22], BoNeSi [23]. UDP flood атака с помощью Low Orbit Ion Cannon и BoNeSi. В дополнение проводилось испытание скорости фильтрации IP адресов на Cisco 2811. Ни одна из атак не вывела из строя оборудование, а веб сервер отвечал на запросы пользователей. Стоит отметить, что испытания проводились на введённой в коммерческую эксплуатацию системе, не являющейся лабораторным стендом. По этой причине невозможно полноценно провести эмуляцию большого ботнета с реальным участием всего нескольких атакующих компьютеров.

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

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

Рисунок 3.11 – График загрузки внешнего канала во время DDoS атаки

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

Выход из строя каналов связи произошёл из-за переполнения входящим UDP трафиком (DDoS атака типа «UDP flood»). Причем количество серверов, генерирующих этот трафик, было сравнительно небольшим, их насчитывалось не более 200. Приблизительно половина этих серверов, практически не меняла порты источника и назначения, другая половина делала это регулярно.

При атаке применялись UDP пакеты двух типов. Первый тип это UDP пакеты минимальной длины (см. Рис. 3.12). Эти пакеты содержат один символ, который повторяется во всех пакетах. Второй тип представляет собой UDP пакеты максимальной длины. Эти пакеты заполнены случайными данными (см. Рис. 3.13). Все пакеты помечены, как фрагменты для их последующего объединения сервером в один большой пакет (см. Рис. 3.14).

Рисунок 3.12 – UDP пакеты минимальной длины

Рисунок 3.13 – UDP пакеты со случайным заполнением данными

Рисунок 3.14 – Фрагментированные UDP пакеты

Небольшое количество атакующих серверов компенсировалось суммарной скоростью UDP потоков, генерируемых атакующим каждым адресом. С ряда адресов эта скорость достигала 60 Мбит/с и могла бы быть увеличена, если бы не ограничения, наложенные нашим провайдером на внешний канал. Поверка месторасположения атакующих серверов показала, что большинство их расположено в США, хотя переписка с руководством ботнета происходила на русском. По заверениям руководства ботнета его мощность в атаке на нас была использована только на 2%. При этом пострадал только наш веб хостинг с его внешними каналами шириной порядка 1 Гбит/с. Каналы нашего внешнего провайдера суммарной мощностью не меньше 100 Гбит/с не пострадали.

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

TCP запросы (DDoS атака типа «TCP flood») тоже участвовали в DDoS атаке. Число атакующих серверов было порядка 1500. При атаке применялись TCP запросы двух типов. Первый тип – это запросы файлов с веб сервера, имитирующие действия пользователей. Второй тип представлен множеством SYN/ACK пакетов минимального размера – по всей видимости, это «TCP SYN flood» DDoS атака. Но существенного ущерба эти атаки не нанесли ввиду переполнения канала и активации алгоритмов ограничения запросов с одного IP адреса на веб сервере.

Анализ атаки на уровне потоков показал, что начало атаки сопровождалось резким ростом числа активных потоков во внешнем канале веб хостинга. Число завершенных потоков, как упоминалось выше, возросло более чем на два порядка. Этот рост был сразу зафиксирован мониторинговой системой. Отдельные атакующие IP адреса легко определяются по количеству генерируемых потоков, как активных, так и завершенных. На Рис. 3.15 приведен ранжированный список адресов по количеству сгенерированных потоков. Верхний график описывает момент атаки, на нижнем графике приведено типичное распределение при отсутствии атаки.

Рисунок 3.15 – Сравнение числа потоков во время атаки и в обычном состоянии

Сравнение графиков с Рис. 3.15 позволяет сформулировать критерий для определения принадлежности IP адреса к ботнету. Все адреса, расположенные выше, чем самый популярный сервер в обычном состоянии сети и не принадлежащие к пользовательскому ядру, должны быть отнесены к ботнету [16]. Для полного выявления атакующих адресов необходимо построить ранжированные распределения для входящего UDP, ICMP и TCP трафика, генерируемого с единичного IP адреса в момент атаки. Обычное состояние сети используется для определения порога отсечения, как это было сделано в работе [16]. Порог отсечения должен быть определен для каждого сервиса и типа трафика заранее, причем раз в полгода эти значения необходимо пересчитывать.

Применение двух независимых критериев по числу потоков и объему входящего трафика (UDP, ICMP или TCP) позволяет оперативно (в течение 5 минут) составить список атакующих адресов для блокировки на фильтрующем оборудовании.

3.6.Выводы

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

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

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

Устойчивая работа сетевой инфраструктуры серверной невозможна без наличия, как минимум, двух внешних Интернет каналов связи по 10 Гбит/с. Каналы порядка нескольких Гбит/с не могут обеспечить отказоустойчивость при DDoS атаке.

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

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

Наибольшую опасность представляет атака UDP flood, нацеленная на переполнение каналов доступа. Поскольку DDoS атака чаще всего ведётся на один или несколько адресов, то полное ограничение UDP трафика у провайдера верхнего уровня на атакуемые адреса поможет избежать переполнения каналов связи. Требуется рассмотрение вопроса об ограничении скорости UDP потоков с одиночного IP адреса. Второй тип атакующих IP адресов, ведущих атаку с помощью TCP запросов, легко идентифицируется с помощью критерия по числу потоков. Одновременное применение указанных методов даёт возможность выявить IP адреса атакующих серверов (ботов) в течение 30 минут.

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

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

Литература

[1] Mirkovic J., Reiher P. A taxonomy of DDoS attack and DDoS defense mechanisms //ACM SIGCOMM Computer Communication Review. – 2004. – ISSN: 0146-4833. – DOI: 10.1145/997150.997156. – Т. 34. – №. 2. – С. 39-53.

[2] Douligeris C., Mitrokotsa A. DDoS attacks and defense mechanisms: classification and state-of-the-art //Computer Networks. – 2004. – ISSN: 1389-1286. – DOI: 10.1016/j.comnet.2003.10.003. – Т. 44. – №. 5. – С. 643-666.

[3] Singh S., Gyanchandani M. Analysis of Botnet behavior using Queuing theory //International Journal of Computer Science & Communication. – 2010.
– ISSN: 0973-7391. – Т. 1. – №. 2. – С. 239-241.

[4] Stanton J. M., Stam K. R., Mastrangelo P., Jolton, J. Analysis of end user security behaviors //Computers & Security. – 2005. – ISSN: 0167-4048. – DOI: 10.1016/j.cose.2004.07.001. – Т. 24. – №. 2. – С. 124-133.

[5] Hochheiser, H. Shneiderman, B. Understanding patterns of user visits to web sites: interactive starfield visualizations of WWW log data //Proceedings of the ASIST Annual Meeting – 1999. – ISSN 0044-7870.

[6] Chen J., Nairn R., Nelson L., Bernstein M., Chi E. Short and tweet: experiments on recommending content from information streams //Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. – ACM, 2010. – ISBN: 978-1-60558-929-9. – DOI:10.1145/1753326.1753503. – С. 1185-1194.

[7] Lehmann J., Lalmas M., Yom-Tov E., Dupret G. Models of user engagement //User Modeling, Adaptation, and Personalization. – Springer Berlin Heidelberg, 2012. – ISSN: 0302-9743. – ISBN: 978-3-642-31453-7. – DOI: 10.1007/978-3-642-31454-4_14. – С. 164-175.

[8] Ma J., Saul L. K., Savage, S. Voelker G. M. Beyond blacklists: learning to detect malicious web sites from suspicious URLs //Proceedings of the 15th ACM SIGKDD international conference on Knowledge discovery and data mining. – ACM, 2009. – ISBN: 978-1-60558-495-9. – DOI: 10.1145/1557019.1557153. – С. 1245-1254.

[9] Li B., Springer J., Bebis G., Hadi Gunes M. A survey of network flow applications //Journal of Network and Computer Applications. – 2013. – ISSN: 1084-8045. – DOI: 10.1016/j.jnca.2012.12.020. – Т. 36. – №. 2. – С. 567-581.

[10] Proto A., Alexandre L. A., Batista M. L., Oliveira I. L., Cansian,A. M. Statistical model applied to netflow for network intrusion detection //Transactions on computational science XI. – Springer Berlin Heidelberg, 2010. – ISBN: 978-3-642-17696-8. – ISSN: 0302-9743. – DOI: 10.1007/978-3-642-17697-5_9. – С. 179-191.

[11] Sawaya Y., Kubota A., Miyake Y. Detection of attackers in services using anomalous host behavior based on traffic flow statistics //Applications and the Internet (SAINT), 2011 IEEE/IPSJ 11th International Symposium on. – IEEE, 2011. – ISBN: 978-1-4577-0531-1. – DOI: 10.1109/SAINT.2011.68. – С. 353-359.

[12] Sommer R., Paxson V. Outside the closed world: On using machine learning for network intrusion detection //Security and Privacy (SP), 2010 IEEE Symposium on. – IEEE, 2010. – ISSN: 1081-6011. – ISBN: 978-1-4244-6894-2.
– DOI: 10.1109/SP.2010.25. – С. 305-316.

[13] Corchado E., Herrero Á. Neural visualization of network traffic data for intrusion detection //Applied Soft Computing. – 2011. – ISSN: 1568-4946. – DOI: 10.1016/j.asoc.2010.07.002. – Т. 11. – №. 2. – С. 2042-2056.

[14] Martinez L. P., Espitia H. E. Proposal and adjustment of a Colombian migration model for the Pacific region //Instrumentation and Measurement, Sensor Network and Automation (IMSNA), 2013 2nd International Symposium on. – IEEE, 2013. – DOI: 10.1109/IMSNA.2013.6742812. – С. 37-41.

[15] Zhao G., Ji C., Xu C. Survey of Techniques for Internet Traffic Identification [J] //Journal of Chinese Computer Systems. – 2010. – ISSN: 1000-1220. – Т. 8. – С. 010.

[16] Sukhov A. M., Sidelnikov D. I., Platonov A. P., Strizhov M. V., Galtsev A. A. Active flows in diagnostic of troubleshooting on backbone links //Journal of High Speed Networks. – 2011. – ISSN: 0926-6801. – DOI: 10.3233/JHS-2011-0447. – Т. 18. – №. 1. – С. 69-81.

[17] Zipf G. K. Relative frequency as a determinant of phonetic change //Harvard Studies in Classical Philology. – 1929. – С. 1-95.

[18] Крашаков С. А., Теслюк А. Б., Щур Л. Н. Об универсальности рангового распределения популярности веб-серверов //Вестник РФФИ. – 2004. – ISSN: 1605-8070.– С. 46-66.

[19] Chen Y., Hwang K., Ku W. S. Collaborative detection of DDoS attacks over multiple network domains //Parallel and Distributed Systems, IEEE Transactions on. – 2007. – ISSN: 1045-9219. – DOI: 10.1109/TPDS.2007.1111. – Т. 18. – №. 12. – С. 1649-1662.

[20] Luis M. G. TCPDUMP/LIBPCAP public repository //Online document, www.tcpdump.org. – 2009.

[21] ab – Apache HTTP server benchmarking tool – Apache HTTP Server Version 2.2 //The Apache Software Foundation. http://httpd.apache.org/docs/2.2/programs/ab.html

[22] LOIC | Free Security & Utilities software downloads at SourceForge.net //Dice Holdings, Inc. http://sourceforge.net/projects/loic/

[23] bonesi - BoNeSi - the DDoS Botnet Simulator //Google Project Hostingрон. https://code.google.com/p/bonesi/

4. ПРАКТИКА ВНЕДРЕНИЯ МЕТОДОВ ОБНАРУЖЕНИЯ DDoS атак

4.1.Введение в систему журналирования ОС Linux

Все примеры и описания в данной главе выполнены с использованием Debian GNU/Linux версии 7.6.0. В данной работе приведён обзор файлов журналов операционной системы Linux.

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

В операционной системе Linux для этих целей ведутся файлы журналов. Они, как правило, расположены в директории /var/log и её поддиректориях, а сами файлы имеют расширение *.log – поэтому их часто называют лог-файлами или логами. Список основных файлов журналов и их предназначение представлен в таблице 4.1.

Таблица 4.1 – Основные файлы журналов Debian GNU/Linux и их предназначение.

Доступ к этим файлам, как правило, осуществляется любым удобным текстовым редактором.