CC BY
23
УДК 004.41/.42
ИЗУЧЕНИЕ ПОЛЬЗОВАТЕЛЬСКОЙ АУДИТОРИИ ДЛЯ ЗАДАЧ
СЕТЕВОЙ БЕЗОПАСНОСТИ*
STUDYING USER BEHAVIOUR FOR ENSURING NETWORK SECURITY
© Баскаков Александр Викторович
Alexander V. Baskakov
начальник отдела управления корпоративной сетью. Самарский государственный аэрокосмический университет имени академика С.П. Королева
Head of the department of corporate network management, Samara State Aerospace University
e-mail: [email protected]
© Сагатов Евгений Собирович
Evgeniy S. Sagatov
кандидат технических наук, ассистент кафедры суперкомпьютеров и общей информатики. Самарский государственный аэрокосмический университет имени академика С.П. Королева
Cand.Sc.(Engineering), researcher at the department of supercomputers and general informatics, Samara State Aerospace University
e-mail: [email protected]
© Сухов Андрей Михайлович
Andrey M. Suhov
доктор технических наук, профессор кафедры суперкомпьютеров и общей информатики. Самарский государственный аэрокосмический университет имени академика С.П. Королева, член ACM, IEEE
PhD. (Engineering), professor at the department of supercomputers and general informatics, member of ACM, IEEE, Samara State Aerospace University
e-mail: [email protected]
Статья посвящена изучению аудитории интернет-сервисов с целью формирования пользовательского ядра в виде списка 1Р-адресов, для которых можно разрешить доступ в начале сетевой атаки. Предложены методы определения постоянной аудитории сайта и выявления 1Р-адресов, с которых ведется атака для последующего блокирования доступа. Проведены эксперименты в условиях реальной сетевой атаки на популярный интернет-портал. Для выделения 1Р-адресов источников атаки показана эффективность одновременного применения двух критериев: превышения порогового уровня для предельной скорости
The paper studies the audience of Internet services in order to create user profiles as a list of IP-addresses that can be allowed access at the beginning of a network attack. The authors suggest methods for determining regular users of sites and identifying IP-addresses from which attacks are carried out in order to subsequently block their access. The paper presents results of an experiment in a real network attack on a popular internet portal. To isolate the IP-addresses of sources of attack it is recommended to simultaneously apply two criteria: excess of the threshold for a top speed of UDPflows and the number of flows generated from the tested IP-address.
* Работа выполнена при поддержке Министерства образования и науки РФ и гранта РФФИ № 13-07-00381а.
Keywords: network security, DDoS-attack, overflow of communication channel, custom kernel, IP-address black list, traffic analysis.
Метод противодействия DDoS-атакам [i; 2] (Distributed Denial of Service - распределенная атака типа «отказ в обслуживании») - это такой тип атак, при котором некоторое множество компьютеров в сети Интернет, называемых «зомби», «ботами» или «бот-сетью» (бот-нет), по команде злоумышленника начинают отправлять запросы на сервис жертвы. Такие сети имитируют действия обычных пользователей [3, с. 239-241], поэтому их крайне сложно выявить и заблокировать. Когда число запросов превышает возможности серверов жертвы, новые запросы от настоящих пользователей перестают обслуживаться и сервис становится недоступным. При этом жертва несет финансовые убытки.
Задачи обеспечения надежности и безопасности интернет-сервисов требуют изучения поведения пользователей [4; 5] на конкретном ресурсе. Все пользователи интернет-сервиса могут быть разделены на две категории: пользовательское ядро и новички. К пользовательскому ядру следует отнести тех посетителей, которые регулярно обращаются к исследуемому ресурсу [6, с. 1185-1194]. Перерывы по времени между обращениями от одного пользователя могут достигать нескольких недель. Первой задачей данного исследования является определение периода времени, за которое анализ статистики посещений позволит выявить пользовательское ядро, вторая задача состоит в том, чтобы оценить предельную долю адресов из пользовательского ядра в общей базе IP-адресов.
Дополнительной задачей является определение особенностей поведения новых (посетивших ресурс впервые) пользователей и процента запросов, принадлежащих им. К особенностям поведения можно отнести количество и долю запросов при пользовании сервисом, включая ранжированный список для всех новых пользователей, период времени непрерывного пользования сервисом и т.д. [7, с. 164-175]. Прежде всего, следует сравнить поведение новых и старых пользователей и найти корреляцию между частотой посещений и количеством запросов к сервису.
При отражении DDoS-атаки можно использовать разные стратегии обороны. Например, искать классификационные признаки IP-адресов, с которых происходит атака, и по ним ограничивать доступ к ресурсу [8, с. 1245-
1254]. Однако в начале атаки всегда требуется время на распознание особенностей атаки, на формулировку квалификационных признаков для нежелательных запросов и идентификацию атакующих 1Р-адресов. Длительность этих операций может достигать нескольких часов, в течение которых сервис может быть недоступен. В это время можно обрабатывать запросы только постоянной аудитории, т.е. пользовательского ядра. Знание статистических особенностей поведения новых пользователей облегчит поиск типов атакующих запросов и формирование списков блокировки доступа атакующих 1Р-адресов.
Эксперименты по ББоБ-атаке на сервис можно провести с помощью эмуляции в лабораторных условиях. При этом ценность полученных результатов значительно меньше, чем при ББоБ-атаке на введенный в эксплуатацию коммерческий сервис, так как эмулятор не может полностью воспроизвести реальную компьютерную сеть. Кроме того, для полноценного понимания принципов и методов ББоБ-атаки необходим опыт работы с ней. Поэтому авторы анонимно договорились о проведении реальной ББоБ-атаки на специально подготовленный веб-сервис. В процессе атаки был записан сетевой трафик, собрана статистика NetFlow и сделаны выводы об эффективности способов обнаружения и методов противодействия.
Обзор предшествующих работ
Множество работ посвящено обнаружению несанкционированных вторжений при помощи анализа данных протокола NetFlow. Достаточно полный обзор можно найти в статье [9, с. 567-581]. Среди методов обнаружения вторжений можно отметить статистический подход [10; 11], когда анализ информации о потоках с помощью простейших законов теории вероятности позволяет выявить источники атак. Статистический подход отличается простотой, дает надежные результаты, но область применения ограничена хорошо изученными типами атак.
Неизвестные методы вторжений требуют для обнаружения более сложных подходов, таких как различные схемы машинного обучения [12, с. 305-316]. Для обнаружения новых угроз используются нейронные сети [13, с. 2042-2056], генетические алгоритмы [14,
с. 37-41], опорные векторные машины [15, с. 10] и т.д.
Наш подход [16, с. 69-81] имеет отличительные особенности. Во-первых, обнаружение атаки базируется на отклонениях от распределения Зипфа [17, с. 1-95]. Для этого анализируется информация об активных или завершенных потоках за некоторый промежуток времени. Минимальное время сбора статистики NetFlow может варьироваться от одной до пяти минут. При нормальном функционировании сети ранжированный список количества потоков, генерируемых уникальным IP-адресом, представляет типичное распределение Зипфа [18, с. 46-66].
Атакующие адреса могут быть идентифицированы по превышению установленного порогового значения для числа активных или завершенных потоков [16]. Во время атак число потоков возрастает многократно.
Однако этот метод не будет работать для атаки типа «UDP flood», при которой не меняются порты источника и назначения пакетов [19, с. 1649-1662]. В этом случае число потоков с одного атакующего IP-адреса будет небольшим, в то же время скорость потока может достигать десятков Мбит/с. Поэтому необходим дополнительный критерий для обнаружения атаки указанного типа.
Второе отличие предлагаемого подхода состоит в том, чтобы выделить пользовательское ядро. При атаке можно блокировать неограниченное число обнаруженных атакующих адресов, а все адреса вне пользовательского ядра.
Въявление пользовательского ядра интернет-сервиса
Для выявления пользовательского ядра интернет-сервиса можно использовать любые журналы доступа, в которые вносятся IP-адреса посетителей, либо данные NetFlow. В рассматриваемом в данной статье случае атака проводится на веб-сервер популярного интернет-портала, поэтому в качестве источника IP-адресов используются файлы журналов веб-сервера Nginx, работающего в операционной системе Debian GNU/Linux. IP-адреса посетителей заносятся в базу данных и в дальнейшем считаются принадлежащими пользовательскому ядру. После формирования ядра пользователи, IP-адреса которых не внесены в базу данных, считаются новыми.
На рис. 1 изображен график измерения доли новых IP-адресов п в ежесуточной аудитории. Под долей п понимается отношение количества IP-адресов новых посетителей к их общему числу за каждые сутки.
Из графика видно, что через четыре-шесть недель с начала сбора статистики процент новых IP-адресов, с которых происходят посещения сайта, стабилизируется в интервале от 30 до 40%.
Для того чтобы понять структуру аудитории, необходимо построить ранжированные списки пользовательских IP-адресов [18]. В качестве величины для упорядочивания следует выбрать частоту посещений R с каждого адреса, а пользовательские IP-адреса расположить в порядке убывания данной частоты. В каче-
%
Рис. 1. График зависимости доли новых 1Р-адресов за сутки от времени, прошедшего
с начала измерений
стве ранга n будет использован порядковый номер IP-адреса в убывающем списке, тогда функция R(n) и будет искомым ранговым распределением.
Для того чтобы понять природу поведения посетителей с новых адресов, необходимо построить два ранговых распределения. Первое распределение должно содержать анализ суточной выборки IP-адресов. Вторая выборка должна анализировать данные за более длительный срок, не менее четырех месяцев.
Для построения суточного ранжированного списка можно выбрать различные исходные статистические данные, например журналы веб-сервера или данные NetFlow.
Журналы доступа веб-сервера Nginx позволяют получить зипфоподобное (Zipf like) распределение, изображенное на рис. 2. Здесь R(n) - это количество запросов с одного IP-адреса, а n - ранг этого запроса, т.е. порядковые номера IP-адресов в списке по убыванию количества запросов.
Условно график можно разделить на две части. Вначале идет пологая часть, а затем резкий спад количества посещений с одного IP-адреса. В исследуемом случае спад начинается с 55 запросов на IP-адрес в сутки. Анализ содержимого запросов позволяет сделать вывод о том, что с IP-адресов в пологой части делаются запросы ко всем документам с загружаемой HTML- страницы, т.е. закачиваются картинки, скрипты, стили и другие подключаемые на странице файлы. В части спада запра-
шиваются только HTML-страницы, которые генерируются каждый раз заново, что говорит о том, что остальные файлы уже были сохранены в кэше браузера пользователя, а значит, он ранее уже посещал данный сайт. Стоит отметить, что пользователи, запросившие от 1 до 3 файлов, как правило, вообще не заходили на сайт, а загрузили картинку с сайта через поисковую систему или обновили RSS-ленту.
Версию кэширования подтверждает и аналогичное ранговое распределение, построенное с учетом запросов только HTML-файлов и другого содержимого, которое не остается в кэше браузера пользователя (рис. 3).
Такое поведение свидетельствует о том, что пользователи из второй части графика с рис. 2 ранее уже посещали сайт, но имели другой IP-адрес. Как правило, такие пользователи подключаются к сети Интернет через сеть своего провайдера, который выдает ему IP-адрес из своего блока динамических адресов. Указанные блоки адресов также должны быть занесены в пользовательское ядро, так как, вероятно, пользователь сайта получит тот или иной адрес из этого блока в будущем.
Статистика NetFlow для новых IP-адресов за сутки дает похожий результат, изображенный на рис. 4.
На рис. 5 изображена суточная статистика посещений для всех адресов (по данным Net-Flow), включая новые и встречавшиеся ранее адреса.
Рис. 3. Распределение Зипфа для запросов к обновляемым данным
Рис. 4. Суточная статистика посещений для новых адресов
Для того чтобы понять происхождение новых 1Р-адресов и то, почему их доля не уменьшается со временем, была собрана и проанализирована статистика посещений за пять месяцев. В качестве величины для упорядочива-
ния данных было выбрано количество суток, в течение которых с исследуемого 1Р-адреса поступали запросы к исследуемому сервису. Итоговый ранжированный график изображен на рис. 6.
Рис. 5. Полная суточная статистика посещений
Рис. 6. Ранговое распределение посещений сайта за пять месяцев
Ранжированный список показывает, что большинство пользователей посещали сайт только в течение одних суток. Однократные посещения зафиксированы с более чем 590 тысяч адресов из 775 тысяч, что составляет 76,2% от общего количества адресов. Назовем IP-адреса, с которых посещения фиксировались только в течение одних суток, случайны-
ми IP-адресами. Сравнивая данные из списка случайных IP-адресов со списком новых IP-адресов за сутки, получается, что доля случайных IP-адресов среди новых IP-адресов составляет 91±5%. Этот факт объясняет большой процент новых IP-адресов в суточной аудитории. Предсказать IP-адреса таких посетителей невозможно.
Формирование списка постоянных посетителей
Исследование аудитории пользователей сервиса, проведенное выше, позволяет сформировать список постоянных посетителей. За основу можно взять аудиторию за какой-то значительный промежуток времени (от двух недель, а лучше месяц). Прежде всего, из такого списка следует удалить все случайные адреса, т.е. адреса, которые посещали сайт только в течение одних суток.
Он будет не полон, так как часть IP-адресов выбирается из блоков динамических адресов интернет-провайдеров. Для пополнения списка IP-адресов был разработан специальный скрипт, в основе которого лежит нижеследующий алгоритм. В качестве исходных данных берется список IP-адресов, с которых производились запросы к сайту за время стабилизации количества новых IP-адресов (четыре-шесть недель в исследуемом случае). Адреса разбиваются на группы по сетевой маске /24. Если группа заполнена адресами на 30%, то блок IP-адресов по маске /24 заносится целиком в список IP-адресов пользовательского ядра. Если группа заполнена меньше, чем на 30%, то она разбивается на две равные части по сетевой маске /25. Аналогичная операция по проверке заполнения и по расширению ядра выполняется для полученных частей. Если какой-то из блоков адресов заполнен меньше порогового значения в 30%, то опера-
%
20,0
10,0
ia.ii. 13 2а.п.13 os.i2.i3 1a.12.13 23.12.13 07.01.14 17.01.14 27.01.14 0e.02.14 Рис. 7. Доля новых адресов с учетом расширения базы
ция повторяется до сетевой маски /29 включительно.
Следует отметить, что разработанный скрипт по расширению пользовательской базы необходимо запускать до описанного в предыдущем разделе скрипта по удалению случайных посетителей. Адреса посетителей из подсетей, принадлежащих пользовательскому ядру, не считаются случайными и не удаляются при чистке.
Применение разработанного скрипта дополнения базы данных позволило увеличить число входящих в нее адресов с 273030 до 393273, т.е. на 44%. На рис. 7 изображен график зависимости процента новых IP-адресов за сутки п от времени, пошедшего с начала измерений, с учетом дополнения базы данных. После расширения ядра доля новых адресов находится в интервале от 25 до 35%.
При определении момента начала атаки необходимо иметь в виду, что общее количество запросов различается как по дням недели, так и по времени суток, но эти показатели ци-кличны. Например, на рис. 8 видно, что количество запросов с 2 до 5 часов ночи более чем в 5 раз ниже, чем количество запросов с 10 часов утра до 16 часов дня. Количество запросов в выходные дни в 2-3 раза ниже, чем в будни.
На рис. 9 изображен типичный суточный график изменения числа завершенных потоков за рабочий день. Сбор данных о потоках происходит каждые пять минут. В случае на-
Рис. 8. Количество запросов по дням недели и часам
Рис. д. Суточный график изменения количества завершившихся потоков
чала реальной атаки число активных потоков возрастет, как минимум, на порядок.
В заключение этого раздела необходимо установить, какой части пользователей будет отказано в обслуживании при установке фильтра, позволяющего обслуживать запросы только с 1Р-адресов, входящих в пользовательское
ядро. Из графика на рис. 7 видно, что доля новых 1Р-адресов стремится к пределу, который можно обозначить как п. Тогда за время £, потраченное на обнаружение и блокировку атаки, защищаемый сервис не сможет обслужить следующее количество запросов:
где S - среднее количество уникальных IP-адресов за сутки. Время t также следует исчислять в сутках. Для времени t, равного 6 часам (0,25 суток) и п=32% , следует, что всего 8% от среднесуточной аудитории будет отказано в обслуживании.
Защитная инфраструктура и ее испытания
Для проведения тестовых испытаний и проверки защиты в условиях реальной DDoS-атаки была создана сетевая инфраструктура на базе веб-хостинга, на который был перемещен популярный интернет-портал. Принципиальная схема сетевой инфраструктуры приведена на рис. 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 и Bo-NeSi. В дополнение проводилось испытание скорости фильтрации IP-адресов на Cisco 2811. Ни одна из атак не вывела из строя оборудование, а веб-сервер отвечал на запросы пользователей. Стоит отметить, что испытания проводились на введенной в коммерческую эксплуатацию системе, не являющейся лабораторным стендом. По этой причине невозможно полноценно провести эмуляцию большого ботнета с реальным участием всего нескольких атакующих компьютеров.
Лабораторные испытания не могут заменить опыт, полученный при реальной атаке, поэтому авторы анонимно обратились с просьбой о проведении комбинированной DDoS-атаки на описанный выше веб-сервер. Статистика использования данного сервера собира-
Рис. 10. Сетевая инфраструктура для проведения исследований
лась в течение пяти месяцев и была приведена в предыдущем разделе статьи.
Реальный опыт отражения DDoS-атаки кардинально поменял мнение авторов о типе и особенностях проведения атаки. Перед атакой планировалось осуществлять дистанционно мониторинг состояния оборудования, но первые минуты DDoS-атаки показали, что делать это через атакуемый канал связи невозможно. Начало DDoS-атаки сопровождалось резким ростом (более чем в сто раз) числа активных потоков, что было своевременно зафиксировано скриптами наблюдения. Затем в первые минуты DDoS-атаки произошло переполнение внешних каналов связи и веб-сервер стал недоступен из внешней сети. Все остальные службы и сервера также стали недоступны, удаленное управление было утеряно, несмотря на три внешних канала связи. Поэтому пришлось брать управление из внутренней сети. Переполнение одного из внешних каналов демонстрирует график, изображенный на рис. 11.
Сплошная линия показывает предельно допустимую нагрузку на канал от сервис-провайдера. В течение всей атаки она была значительно превышена.
Выход из строя каналов связи произошел из-за переполнения входящим UDP-трафиком (DDoS-атака типа UDP flood). При этом количество серверов, генерирующих этот трафик, было сравнительно небольшим, их насчитывалось не более 200. Приблизительно половина этих серверов практически не меняла порты источника и назначения, другая половина делала это регулярно.
При атаке применялись UDP-пакеты двух типов. Первый тип - это UDP-пакеты минимальной длины (рис. 12). Эти пакеты содержат один символ, который повторяется во всех пакетах. Второй тип представляет собой UDP-
пакеты максимальной длины. Эти пакеты заполнены случайными данными (рис. 13). Все пакеты помечены сервером в один большой пакет, как фрагменты для их последующего объединения (рис. 14).
Небольшое количество атакующих серверов компенсировалось суммарной скоростью UDP-потоков, генерируемых атакующим каждым адресом. С ряда адресов эта скорость достигала 60 Мбит/с и могла бы быть увеличена, если бы не ограничения, наложенные нашим провайдером на внешний канал. Поверка месторасположения атакующих серверов показала, что большинство их расположено в США, хотя переписка с руководством ботнета происходила на русском. По заверениям руководства ботнета его мощность в атаке на нас была использована только на 2%. При этом пострадал только наш веб-хостинг с его внешними каналами шириной порядка 1 Гбит/с. Каналы нашего внешнего провайдера суммарной мощностью не меньше 100 Гбит/с не пострадали.
К сожалению, наш хостинг не имел соглашения об ограничении входящего трафика с провайдерами, простейший запрет UDP-трафика на атакуемый сервер сразу бы помог решить большинство проблем.
TCP-запросы (DDoS-атака типа TCP flood) тоже участвовали в DDoS-атаке. Число атакующих серверов было порядка 1500. При атаке применялись TCP-запросы двух типов. Первый тип - это запросы файлов с веб-сервера, имитирующие действия пользователей. Второй тип представлен множеством SYN/ACK пакетов минимального размера - по всей видимости, это «TCP SYN flood» DDoS-атака. Но существенного ущерба эти атаки не нанесли ввиду переполнения канала и активации алгоритмов ограничения запросов с одного IP-адреса на веб-сервере.
Рис. 11. График загрузки внешнего канала во время DDoS-атаки
Tine Scurce Deütinaticn Prctcccl Length Info
0 000000 193.200.ЗБ.21 91 222 129 218 UDP 60 Source port 53186 Desti nati on port 29578
0 000004 123. 231. 6.14 91 222 129 218 UDP 60 source port 33509 Desti nati on port 21545
0 000014 123. 237. 252.198 91 222 129 218 UDP 60 Source port 4 3149 Desti nati on port 64098
0 ooooib 86.34.167.242 91 222 129 218 UDP 60 Source port 50633 Desti nati on port 34012
0 000027 195.138.198.208 91 222 129 218 UDP 60 Source port 50832 Desti nati on port 10760
0 000031 190.151. 39. 254 91 222 129 218 UDP 60 Source port 28755 Desti nati on port 52633
0 000041 184.22.62.140 91 222 129 218 UDP 60 Source port 47576 Desti nati on port 5tX
0 000044 86.34.167.242 91 222 129 218 UDP 60 Source port 50633 Desti nati on port 34012
0 000054 195. 138.198. 2:08 91 222 129 218 UDP 60 source port 50832 Desti nati on port 10760
0 000058 190.151. 39. 254 91 222 129 218 UDP 60 Source port 28755 Desti nati on port 52633
0 000067 202. 129. 38. 5 91 222 129 218 UDP 60 source port 46313 Desti nati on port 52478
0 000071 86.34.167.242 91 222 129 218 UDP 60 Source port 50633 Desti nati on port 34012
0 000081 195. 138.198. 2:08 91 222 129 218 UDP 60 source port 50832 Desti nati on port 10760
0 000085 83.172. 21. 22 91 222 129 218 UDP 60 source port 45002 Desti nati on port openvn
0 000095 202.129. 38. 5 91 222 129 218 UDP 60 source port 46313 Desti nati on port 52478
0 000099 86.34.167.242 91 222 129 218 UDP 60 source port 50633 Desti nati on port 34012
0 000108 195. 138.198. 2:08 91 222 129 218 UDP 60 source port 50832 Desti nati on port 10760
0 000111 83.172. 21. 22 91 222 129 218 UDP 60 source port 45002 Desti nati on port openvn
0 000121 202. 129. 38. 5 91 222 129 218 UDP 60 source port 46313 Desti nati on port 52478
0 000125 86.34.167.242 91 222 129 218 UDP 60 source port 50633 Desti nati on port 34012
0 000134 195. 138.198. 2:08 91 222 129 218 UDP 60 source port 50832 Desti nati on port 10760
0 000138 203. 140. 65. 78 91 222 129 218 UDP 60 source port 64852 Desti nati on port 59538
0 00014 8 188.163. 245. 82 91 222 129 218 UDP 60 source port 50917 Desti nati on port 29088
0 000152 89.175.183.208 91 222 129 218 UDP 60 source port 53611 Desti nati on port 8778
0 000162 193.200.173.110 91 222 129 218 UDP 60 source port 56732 Desti nati on port 59330
0 000166 203. 140. 65. 78 91 222 129 218 UDP 60 source port 64652 Desti nati on port 59538
0 000175 122.103. 236. 2:04 91 222 129 218 UDP 60 Source port 4 5982 Desti nati on port 8110
0 000179 89.175.183.208 91 222 129 218 UDP 60 source port 53611 Desti nati on port 8778
0 000188 62. 75.161.46 91 222 129 218 UDP 60 Source port 35388 Desti nati on port 11265
Рис. 12. UDP-пакеты минимальной длины
Ш Fraire 2975: 754 bytes on wire (6032 bits), 754 bytes captured £6032 bits)
Ш Ethernet II, src: lbm_f0:2a:aS (00:21:5e:f0:2a:a8), Dst: cisco_43:3d:p0 (00:1b:54:43:3d:pO) В internet Protocol Version 4, Ere: 119.6.254.144 (119.6.254.144), Dst: 91.222.129.218 (91.222.129.218) version: 4
Header length: 20 bytes
Ei Differentiated services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) Total Length: 740 Identification: 0x570b (22283) Ei Fl ags : 0x00
Fragment offset: 7400 Time to live: 108 Protocol : и DP (17) Ei Header checksum: 0x9ell [correct] Source: 119.6.254.144 (119.6.2 54.144) Destination: 91.222.129.218 (91.222.129.218) [source GeolP: unknown] [Destination GeolP: unknown]
El [6 IPv4 Fragments (8120 bytes): #2970(1480), #2971(1480), #2972(1480), #2973(1480), #2974(1480), #2975(720)] В User Datagram Protocol, Src Port: 1028 (1028), Dst Port: 5842 (5842) source port: 1028 (1028) Destination port: 5842 £5842) Length: 8120 Ei checksum: 0x8790 [validation disabled] В Data (8112 bytes)
Data: Ib075550055b9018ecep2d6675a27f8cl058fpb030430163... [Length: 8112]
0000 00 lb 54 43 3d eü 00 21 be to 2a ам 08 00 4b 00 TC = _ _ i A *. . . E.
0010 02 e4 57 0b 03 9d 6c 11 9e 11 77 06 fp 90 5b dp w 1
0020 81 da 09 62 59 73 03 OS ее d6 21 2a 4e 36 te cb .bYS.. L ^N6..
0030 t6 bO fb ds 2e a7 c7 09 c2 82 d7 a4 80 73 28 67 ...s(g
0040 Г4 lid 9a 8e p4 rd 64 9e P9 70 1 7 34 71 a? dt pf . d. 5.4!. . .
0050 dd ah 1 d 96 1 0 73 00 do 5b d4 8a 97 h3 rr eb ab s. . L
0060 b5 b2 9d ea 2e 68 36 5c ea 6c ее 35 dc 72 3b e5 h6\ . 5.r; .
0070 7e 4b dh td f 7 14 54 68 31 За 6r 1 8 db no 63 03 . vh 1 1. . . C.
0080 5b bd 5? b3 r5 05 39 Op 8b 76 1 p p7 98 06 db d4 L- R. . 9.
0090 e7 04 9a 07 3b fo bd 3? 49 9p 3b b3 98 bp h7 7b . . ? T ;....+
OOaO do af 82 4c b6 40 2b bl e7 ef 6p 55 d5 pb 20 68 @+. nu.. h
ооьо 59 f 3 7d da a7 le ce 03 7c 82 97 C9 7f dl 4a 7e Y. i. ....J~
OOcO 32 69 80 98 8t 66 52 83 12 a0 7d 3d 2d 51 cc 83 21 tR. ]=Q..
nnHn ГГ- 11 TT TR ЗП Л1 Ли #n ->rJ НД HCl D ....."1С
Рис. 13. UDP-пакеты со случайным заполнением данными
Анализ атаки на уровне потоков показал, что начало атаки сопровождалось резким ростом числа активных потоков во внешнем канале веб-хостинга. Число завершенных потоков, как упоминалось выше, возросло более чем на два порядка. Этот рост был сразу за-
фиксирован мониторинговой системой. Отдельные атакующие 1Р-адреса легко определяются по количеству генерируемых потоков, как активных, так и завершенных. На рис. 15 приведен ранжированный список адресов по количеству сгенерированных потоков. Верх-
1273. 652670 163 2 3.92.193 91 222 129 218 IPv4 1514 Fragmented IP protocol (prOtO=UDP 17 off=0, ID-695C) [Reassembled in £2987]
1273. 652793 163 2 3.92.193 91 222 129 218 IPv4 1514 Fragmented IP protocol (prOtO=UDP 17 off-1480, ID=695c) [Reassembled i n £2987]
1273. 652915 163 2 3.92.193 91 222 129 218 IPv4 1514 Fragmented IP protocol (prOtO=UDP 17 off-2 960, ID-6950 [Reassembl ed i n £2987]
1273. 653040 163 2 3.92.193 91 222 129 218 IPv4 1514 Fragmented IP protocol (prOtO=UDP 17 off-4440, ID=695c) [Reassembl ed i n £2987]
1273. 653162 163 2 3.92.193 91 222 129 218 IPv4 1514 Fragmented IP protocol (prOtO=UDP 17 off.5920, ID-6950 [Reassembl ed i n £2987]
1273. 653224 163 2 3.92.193 91 ¿¿1 129 218 U DP 834 source port 56081 Destination port e3consultants
1273. 666005 14 0 113.224. 73 91 222 129 218 IPv4 1514 Fragmented IP protocol CprOtO-UDP 17 off=0, ID =d62S) [Reassembled in £2993]
1273. 666129 14 0 113.224.73 91 222 129 218 IPv4 1514 Fragmented IP protocol CprOtO-UDP 17 off-1480, ID-d628) [Reassembl ed i n £2993]
1273. 6662 50 14 0 113.224. 73 91 222 129 218 IPv4 1514 Fragmented IP protocol CprOtO-UDP 17 off-2 960, ID—d628) [Reassembled i n £2993]
1273. 666374 14 0 113.224.73 91 222 129 218 IPv4 1514 Fragmented IP protocol CprOtO-UDP 17 off-4440, ID—d628) [Reassembl ed i n £2993]
1273. 666497 14 0 113.224. 73 91 222 129 218 IPv4 1514 Fragmented IP protocol CprOtO-UDP 17 off.5920, ID—d628) [Reassembled i n £2993]
1273.666557 140.113.224. 73 91 222 129 218 UDP S34 Source port: treehopper Desti nati on port: rapidbase
1273. 668760 140.12S.93.240 91 222 129 218 IPv4 1514 Fragmented IP protocol Cproto-UDP 17 off=0, ID =77f0) [Reassembled in £2999]
1273. 668885 140.12S.93.240 91 222 129 218 IPv4 1514 Fragmented IP protocol Cproto-UDP 17 off-1480, ID=77f0) [Reassembled in £2999]
1273. 669006 140.12S.93.240 91 222 129 218 IPv4 1514 Fragmented IP protocol Cproto-UDP 17 off-2 960, ID-77f03 [Reassembled in £2999]
1273. 669129 140.12S.93.240 91 222 129 218 IPv4 1514 Fragmented IP protocol Cproto-UDP 17 off=4440, ID=77fO) [Reassembled in £2999]
1273. 669253 140.12S.93.240 91 222 129 218 IPv4 1514 Fragmented IP protocol Cproto-UDP 17 off-5920, ID=77fO) [Reassembled in £2999]
1273.669313 140.12S.93.240 91 ¿¿1 12!9 218 UDP 834 Source port : wssauthsvc Destinati on port: codasrv
Рис. 14. Фрагментированные UDP-пакеты
ний график описывает момент атаки, на нижнем графике приведено типичное распределение при отсутствии атаки.
Сравнение графиков на рис. 15 позволяет сформулировать критерий для определения принадлежности 1Р-адреса к ботнету. Все адреса, расположенные выше, чем самый популярный сервер в обычном состоянии сети и не принадлежащие к пользовательскому ядру, должны быть отнесены к ботнету [16]. Для полного выявления атакующих адресов необходимо построить ранжированные распределения для входящего ИБР-, 1СМР- и ТСР-трафика, генерируемого с единичного 1Р-адреса в момент атаки. Обычное состояние сети используется для определения порога отсечения, как это было сделано в работе [16, с. 69-81]. Порог отсечения должен быть определен для каждого сервиса и типа трафика заранее, причем раз в полгода эти значения необходимо пересчитывать.
Применение двух независимых критериев по числу потоков и объему входящего трафика (UDP, ICMP или TCP) позволяет оперативно (в течение 5 минут) составить список атакующих адресов для блокировки на фильтрующем оборудовании.
Основные выводы
Для организации защиты от несанкционированного воздействия на сервисы компьютерных сетей было проведено исследование пользовательской аудитории крупного интернет-портала. Изучались вопросы выделения постоянной аудитории, или пользовательского ядра, и расширения этой базы для учета блоков динамических адресов провайдеров.
В работе предлагаются методы составления разрешительного списка, который содержит IP-адреса пользовательского ядра и запретительного, который включает в себя атакующие IP-адреса в момент DDoS-атаки.
Для проверки алгоритмов составления запретительного списка была проведена тестовая атака с использованием реального ботнета, что позволило сделать следующие выводы.
Устойчивая работа сетевой инфраструктуры серверной невозможна без наличия, как минимум, двух внешних интернет-каналов связи по 10 Гбит/с. Каналы порядка нескольких Гбит/с не могут обеспечить отказоустойчивость при DDoS-атаке.
Список блокированных IP-адресов должен устанавливаться у провайдеров верхнего уровня. Для этого должно быть заключено соглашение с каждым из провайдеров, а процесс передачи стоп-листа должен быть автоматизирован и осуществляться без вмешательства администраторов.
Идеально, чтобы стоп-лист транслировался к провайдерам второго уровня, т.е. к провайдерам провайдеров. Такая защита позволит избежать трудностей защиты от подавляющего большинства существующих ботнетов. По нашим наблюдениям, перенос защиты на третий уровень провайдеров позволит полностью блокировать атаки.
Наибольшую опасность представляет атака UDP flood, нацеленная на переполнение каналов доступа. Поскольку DDoS-атака чаще всего ведется на один или несколько адресов, то полное ограничение UDP-трафика у провай-
дера верхнего уровня на атакуемые адреса поможет избежать переполнения каналов связи. Требуется рассмотрение вопроса об ограничении скорости ЦБР-потоков с одиночного 1Р-адреса. Второй тип атакующих 1Р-адресов, ведущих атаку с помощью ТСР-запросов, легко идентифицируется с помощью критерия по числу потоков. Одновременное применение указанных методов дает возможность выявить 1Р-адреса атакующих серверов (ботов) в течение 30 минут.
Основным организационным мероприятием по отражению атаки является налаживание взаимодействия с провайдерами. С ними необходимо иметь соглашение об оперативной передаче листов доступа. Это может быть разрешительный список, он большого размера и должен загружаться заранее.
После начала атаки формируется стоп-лист, который также может быть двух типов. Первый тип ограничивает ЦБР-пакеты на атакуемые адреса. Это позволяет избежать переполнения канала. Второй список действует с начала атаки и разрешает доступ к сайту только постоянной аудитории сайта, сформированной заранее. После установления списка атакующих адресов необходимо заменить разрешающий список на запрещающий. Для его формирования достаточно 30 минут при наличии заранее установленной защитной инфраструктуры.
Библиографический список (References)
1. Mirkovic J., Reiher P. A taxonomy of DDoS attack and DDoS defense mechanisms // ACM SIGCOMM Computer Communication Review. 2004. DOI: 10.1145/997150.997156. T. 34. №. 2.
2. Douligeris C., Mitrokotsa A. DDoS attacks and defense mechanisms: classification and state-of-the-art // Computer Networks. 2004. DOI: 10.1016/j.comnet.2003.10.003. T. 44. №. 5.
3. Singh S., Gyanchandani M. Analysis of Botnet behavior using Queuing theory // International Journal of Computer Science & Communication. 2010. T. 1. №. 2.
4. Stanton J.M., Stam K.R., Mastrangelo P., Jolton J. Analysis of end user security behaviors // Computers & Security. 2005. DOI: 10.1016/j.cose.2004.07.001. T. 24. №. 2.
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.
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. DOI:10.1145/1753326.1753503-
1. Mirkovic J., Reiher P. A taxonomy of DDoS attack and DDoS defense mechanisms // ACM SIGCOMM Computer Communication Review. 2004. DOI: 10.1145 / 997150.997156. T. 34. №. 2.
2. Douligeris C., Mitrokotsa A. (2003) DDoS attacks and defense mechanisms: classification and state-of-the-art // Computer Networks. 2004. DOI: 10.1016 / j.comnet. 10.003. T. 44. № 5.
3. Singh S., Gyanchandani M. (2010) Analysis of Botnet behavior using Queuing theory // International Journal of Computer Science & Communication. T. 1. №. 2.
4. Stanton JM, Stam KR, Mastrangelo P., Jolton J. Analysis of end user security behaviors // Computers & Security. 2005. DOI: 10.1016 / j.cose.2004.07.001. T. 24. № 2.
5. Hochheiser H. Shneiderman B. (1999) Under-standing patterns of user visits to web sites: interactive starfield visualizations of WWW log data // Proceedings of the ASIST Annual Meeting.
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. DOI: 10.1145 / 1753326.1753503.
7. Lehmann J., Lalmas M., Yom-Tov E., Dupret G. Models of user engagement // User Modeling, Adaptation, and Personalization. Springer Berlin Heidelberg, 2012.
8. Ma J., Saul L. K., Savage, S. Voel-ker 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.
9. Li B., Springer J., Bebis G., Hadi Gunes M. A survey of network flow applications //Journal of Network and Computer Applications. 2013. Т. 36. №. 2.
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.
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. DOI: 10.1109/SAINT. 2011.68.
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.
13. Corchado E., Herrero A. Neural visualization of network traffic data for intrusion detection // Applied Soft Computing. 2011. Т. 11. № 2.
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 (IM-SNA), 2013 2nd International Symposium on. -IEEE, 2013. DOI: 10.1109/IMSNA.2013.6742812.
15. Zhao G., Ji C., Xu C. Survey of Techniques for Internet Traffic Identification [J] // Journal of Chinese Computer Systems. 2010. Т. 8.
16. Sukhov A.M., Sidelnikov D.I., Pla-tonov A.P., Strizhov M.V., Galtsev A.A. Active flows in diagnostic of troubleshooting on backbone links // Journal of High Speed Networks. 2011. Т. 18. №. 1.
17. Zipf G.K. Relative frequency as a determinant of phonetic change // Harvard Studies in Classical Philology. 1929.
18. Крашаков С.А., Теслюк А.Б., Щур Л.Н. Об универсальности рангового распределения популярности веб-серверов // Вестник РФФИ. 2004.
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. Т. 18. № 12.
7. Lehmann J., Lalmas M., Yom-Tov E., Dupret G. (2012) Models of user engagement // User Modeling, Adaptation, and Personalization. Springer Berlin Heidelberg.
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.
9. Li B., Springer J., Bebis G., Hadi Gunes M. (2013) A survey of network flow applications // Journal of Network and Computer Applications. T. 36. № 2.
10. Proto A., Alexandre L.A, Batista M.L, Oliveira I.L, Cansian A.M. (2010) Statistical model applied to netflow for network intrusion detection // Transactions on computational science XI. Springer Berlin Heidelberg,
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. DOI: 10.1109 / SAINT.2011.68.
12. Sommer R., Paxson V. (2010) Outside the closed world: On using machine learning for network intrusion detection // Security and Privacy (SP), 2010 IEEE Symposium on. IEEE,
13. Corchado E., Herrero A. (2011) Neural visualization of network traffic data for intrusion detection // Applied Soft Computing. T. 11. № 2.
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.
15. Zhao G., Ji C., Xu C. (2010) Survey of Techniques for Internet Traffic Identification [J] // Journal of Chinese Computer Systems. T. 8.
16. Sukhov A.M., Sidelnikov D.I., Platonov A.P., Strizhov M.V., Galtsev A.A. (2011) Active flows in diagnostic oftroubleshooting on backbone links // Journal of High Speed Networks. T. 18. № 1.
17. Zipf G.K. (1929) Relative frequency as a determinant of phonetic change // Harvard Studies in Classical Philology. In 1929.
18. Krashakov S.A., Teslyuk A.B., Schur L.N. (2004) Ob universal'nosti rangovogo raspredeleniya populyarnosti veb-serverov [On the universality of rank distributions of Web servers popularity] // Vestnik RFFI.
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. T. 18. № 12.
20. Luis M.G. TCPDUMP/LIBPCAP public repository // Online document. URL: www.tcp-dump.org. 2009.
21. ab - Apache HTTP server benchmarking tool - Apache HTTP Server Version 2.2 // The Apache Software Foundation. URL: http://httpd. apache.org/docs/2.2/programs/ab.html
22. LOIC | Free Security & Utilities software downloads at SourceForge.net // Dice Holdings, Inc. URL: http://sourceforge.net/projects/loic/
23. bonesi - BoNeSi - the DDoS Botnet Simulator // Google Project HostingpoH. https://code. google.com/p/bonesi/
20. Luis M.G. TCPDUMP / LIBPCAP public repository // Online document. URL: www. tcpdump.org. 2009.
21. ab - Apache HTTP server benchmarking tool - Apache HTTP Server Version 2.2 // The Apache Software Foundation. URL: http://httpd. apache.org/docs/2.2/programs/ab.html
22. LOIC | Free Security & Utilities software downloads at SourceForge.net // Dice Holdings, Inc. URL: http://sourceforge.net/projects/loic/
23. bonesi - BoNeSi - the DDoS Botnet Simulator // Google Project Hostingron. https:// code.google.com/p/bonesi/
УДК 657.0/.5
ОЦЕНКА КАЧЕСТВА УЧЕТНОЙ ИНФОРМАЦИИ КАК ФАКТОР ОБЕСПЕЧЕНИЯ БЕЗОПАСНОЙ ИНВЕСТИЦИОННОЙ ДЕЯТЕЛЬНОСТИ
QUALITY ASSESSMENT OF ACCOUNTING INFORMATION AS A FACTOR FOR ENSURING SAFE INVESTMENT
© Исяняев Ринат Минерович
Rinat M. Isyanyaev
аспирант кафедры анализа хозяйственной деятельности и аудита, Саратовский социально-экономический институт (филиал) ФГБОУ ВПО «РЭУ им. Г.В. Плеханова»
postgraduate student of the department of business analysis and auditing, Saratov socio-economic institute (branch) of Plekhanov Russian University of Economics
e-mail: [email protected]
В статье рассматриваются подходы к оценке качества учетной информации, способные обеспечить целостность информационной системы при осуществлении инвестиционной деятельности.
Ключевые слова: инвестиционная привлекательность, МСФО, аудит, коэффициент искажения.
В условиях современной мировой конъюнктуры рынка, подверженной спекулятивным факторам, для инвесторов остро встает вопрос информационной безопасности данных. Вкладывая свои ресурсы в предприятие, инвесторы хотят обладать достаточным уровнем уверенности в качестве получаемой информации, на базе которой будет принято управленческое решение.
В настоящее время инвесторы при оценке инвестиционной привлекательности принимают решение на базе:
- оценки геополитических рисков;
The paper discusses various approaches to assessing the quality of accounting information that can ensure the integrity of information systems in conducting investment activities.
Keywords: investment attractiveness, IFRS, auditing, distortion factor.
- общеэкономического анализа;
- отраслевого анализа;
- микроэкономического (локального) анализа;
- маркетингового анализа;
- финансового анализа;
- количественного анализа рисков.
Особое внимание уделяется анализу бухгалтерской (финансовой) отчетности. Финансовый анализ включает в себя:
- анализ платежеспособности и ликвидности;
- анализ финансовой устойчивости;
