Размещено на http://www.allbest.ru/

Оглавление

• Введение
• Глава 1. Обзор области генерации сетевого трафика
• 1.1 Ostinato
• 1.2 AndroGenerator
• 1.3 MoonGen
• 1.4 OpenAirInterface
• 1.5 Новое направление в существующей области
• Выводы по первой главе
• Глава 2. Описание выбранных методов, моделей, алгоритмов решения задач
• 2.1 Метод генерации запросов
• 2.2 Создание модели поведения пользователя
• 2.2.1 Выбор ссылок
• 2.2.2 Распределение времени ожидания
• 2.2.3 Распределение количества посещённых страниц сайта
• Выводы по второй главе
• Глава 3. Выбор средств реализации программного продукта, проект/прототип программного продукта
• 3.1 Описание модулей
• 3.2 Описание работы журналирования и сбора статистик
• Выводы по третьей главе
• Заключение
• Основные определения, термины и сокращения
• Список использованных источников


Введение

Область генерации синтетического сетевого трафика развивалась вместе с веб и интернет технологиями. Стандартным и общепринятым взглядом на генерацию трафика [12] [15] является вопрос тестирования и развития новый сетевых элементов таких как оборудование, протоколы, приложения относительно их производства и исследования. Это крайне важно - предсказывать поведения компьютерный сетей в реальных условиях. Запуск сетей без соответствующего тестирования с созданием сходных с реальными условиями приводит к повышенному риску при эксплуатации данной новой системы и может быть причиной неожиданного и неприемлемого поведения или неудовлетворительных показателей производительности. Генерация трафика делает возможным тестировать и изучать производительность сетевых систем и без потерь, которые неизбежно происходят при запуске с ошибками в реальных условиях. Генерация трафика помогает исследователям в понимании динамики сетевых соединений и в разработке подходящих модификаций и улучшений в существующих протоколах и оборудовании.

Данный аспект генерации трафика уже очень хорошо изучен [6][7][13][19] и был создан весьма широкий спектр программного обеспечения [16], который будет рассмотрен в первой главе. Но их количество не означает, что данная тема исчерпана. Количество различных генераторов говорит о том, что идеального решения пока нет. Одни [10] тестируют аппаратуру и топологию сети, насколько они хорошо справляются с нагрузкой разного профиля. Другие - веб-серверы, или IDS/IPS. Часть из них концентрируется на временных показателях и размерах пакетов. Другие - на полезной нагрузке протоколов уровня приложений, но поддерживаются только пара протоколов (например, HTTP). Плюс важно в каком виде задаются шаблоны на генерируемую полезную нагрузку и какие дополнительные ограничения это подразумевает.

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

1. Изучить область по генерации трафика. Существующие решения и методы;

2. Разработать механизм statefull-генерации HTTP запросов к серверам с ожиданием ответа и генерацией на его основе следующих запросов;

3. Собрать статистические данные по поведению пользователей в сети интернет;

4. Разработать методы моделирования поведения пользователя в сети;

5. Разработать модульную архитектуру создаваемой программе, с возможностью её дальнейшей интеграции в существующую в ИСП РАН систему работы с сетевым трафиком;

6. Разработать программу генерации сетевого трафика с параметрами, задаваемыми через конфигурационные файлы;

7. Разработать техническую документацию.

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



Глава 1. Обзор области генерации сетевого трафика

Генерация сетевых данных в высокой степени зависит от уровня [11], на котором стек протоколов наблюдается и от метода анализа влияния сетей или систем (определение производительности). Генерация часто требует использование обоих уровней свойств: статических и динамических. Генерация синтетических, но реалистичных сетевых нагрузок до сих пор остаётся сложной и открытой проблемой. В литературе и на рынке наблюдается распространение специфичных подходов и средств, разрабатываемых под специфические сценарии: от кластерных вычислений и передачи мультимедиа до беспроводных средств связи, веб-серверов, роутеров и протоколов транспортного уровня.

С другой стороны, общие подходы к генерации сетевых нагрузок - software-based и hardware-based - не могу генерировать реалистичные сетевые нагрузки в каждом сценарии (проблемы каждого из направлений будут рассмотрены ниже)

Первые (software-based) обычно работают на COTS (Commercial off-the-shelf) оборудование и просты в реализации функциональных требований. В то же время последние (hardware-based), основанные на специализированном клиентской аппаратуре, страдают от гораздо меньше гибкости, более жёсткой привязке к архитектуре, а также от гораздо более высоких затрат на разработку и поддержку.

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

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

Таблица. 1. Параметры сетевого трафика [2]

Уровень	Параметры
Хост	Количество принятых/отправленных пакетов Расположение Полезная нагрузка пакетов (отсутствует, минимальная, высокая) На какой порт/адрес отправляются и принимают системные и информационные(~DNS) пакеты
Сеть	На какой порт/адрес отправляются и принимают пакеты достижимости (~ICMP) Устанавливаемое TimeToLive Байты типа обслуживания
Поток	Длительность Время ожидания перед запуском Количество принятых/отправленных пакетов Тип приложения (skype, Microsoft word, BitTorrent Counter Strike, Quake 3) Распределения для размера пакета (Константное, Равномерное, Экспоненциальное, Паретто, Нормальное, Гамма и т.п.) Распределения для времени между пакетами Направление обмена трафика (в одну или в обе стороны)
Транспортный	Исходящий порт и порт назначения Транспортный протокол (TCP, UDP, SCTP, DCCP)

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

1.1 Ostinato

Ostinato - создаёт и обрабатывает пакеты, генерирует сетевой трафик и анализирует его. Реализован с богатым графическим пользовательским интерфейсом. Также предоставляет мощное Python API для автоматизации сетевого тестирования. Создаёт и отправляет пакеты нескольких потоков с разными протоколами и разной частотностью. Можно рассматривать его как “Wireshark in Reverse”.

Ostinato нацелен на предоставления средства для генерации трафика и сетевого тестирования для сетевых инженеров и разработчиков.

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

§ Работа через GUI или Python API

§ Создание и настройка множества потоков

§ Конфигурация частоты пакетов в потоке

§ Сбор и трансляция real-time статистик

§ Эмуляция поведения сетевых устройств (ARP и ICMP) для множества IP hosts

§ Поддержка наиболее распространённых протоколов:

· Ethernet/802.3/LLC SNAP

· VLAN

· ARP, IPv4, IPv6, IP-in-IP

· TCP, UDP, ICMPv4, ICMPv6, IGMP, MLD

· HTTP, SIP, RTSP, NNTP etc.

§ Установка значения для любых полей любых протоколов

§ Изменений полей с течением времени (изменение IP/MACадресов)

§ Кроссплатформенный: Windows, Linux, BSD and Mac OS X

Проблемой является то, что достаточно сложно настраивать гибкость изменения протоколов уровня приложения, чтобы те отвечали полям трафика из реального мира. В целом можно считать, что Ostinato это некий стандарт в данной области знания, для использования на протоколах до уровня приложений. Скорости порядка 10 ГБит/секунда. Достигаются за счёт применения DPDK framework [4], и отправки пакетов на сетевую карту напрямую, без обращений к операционной системе.

1.2 AndroGenerator

Генерация трафика Android приложениями.

В качестве целей создания отмечается важность для сетевых операторов и аналитиков безопасности понимания сетевого трафика, создаваемого новыми приложениями для Android, в целях управления сетью, анализа трафика приложений и обнаружения вредоносных программ. Ручная установка и запуск приложений Android для генерации сетевого трафика является трудоемкой и утомительной, в связи с чем возникла необходимость автоматизировать данный процесс. В работе [18] отмечается, что мобильные трафик вырос на 5000% за последние три года (2012-2015).

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

§ Распределение размера пакета;

§ Характеристики потока, включающие в себя распределения количества и длинны пакетов;

§ Распределение длин HTTP запросов и ответов

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

Основным недостатком в выбранной области является то, что анализируется не полное поведение приложение, а только инициализирующую коммуникацию приложения с сервером (первый запуск).

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



1.3 MoonGen

Скриптовый высокоскоростной генератор пакетов

В работе совмещены hard и soft-ware решения. Для кодовой базы был использован DPDK - framework, в котором реализована большая часть функционала, необходимая для работы с высокоскоростным трафиком. Утверждается что экспериментально доказана возможность создания сетевого пакета на этом framework за 80 тактов CPU. Для hard-ware части был выбран FPGA [5]

В качестве объяснений выбранной схемы объединения двух различных исторических подходов (soft & hard) выделяется следующее:

§ Чисто аппаратные решения (IXIA, Spirent или XENA), дающие очень высокие скорости, обычно работают с предопределёнными верхнеуровневыми заголовками, например, тестирование специальных use-cases производительности по RFC 2544. В результате данные аппаратные генераторы находятся в угле быстрых, но простых решений.

§ Программные средства после большого количества исследований [19] показывают, что они не могут качественно работать с временными промежутками между пакетами.



Рисунок 2. Архитектура MoonGen [9]

Как показано на Рис. 2 в данной системы была реализована кластерная архитектура, при которой существует мастер, который рассылает конфигурации на узлы, конфигурируя тем самым систему в целом. На Рис. 3 представлен механизм регуляции времени между пакетами.



Рисунок. Контроль частоты пакетов и времени между ними [9]

Как результат - использование скриптового язык Lua для генерации верхнеуровневых заголовков, DPDK для создания пакетов и FPGA - для контроля времени между пакетами.

Комбинация данных подходов позволила им отправлять до 14,88 миллионов пакетов в секунду, в условиях минимального размера пакетов. При увеличении же сложности пакетов, временные характеристики ухудшались не значительно ввиду возможности введения кластерного формирования пакетов и их отправки.

1.4 OpenAirInterface

A Realistic Traffic Generation Tool for Emerging Application Scenarios

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

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

В результат была реализована распределённая система. Генерируется трафик весьма ограниченного числа протоколов. в качестве низкоуровневых протоколов передачи пакетов используются беспроводные соединения 3G, LTE. Создания трафика ограничивается двумя способами:

1. Копируя сохранённые трассы;

2. Генерируя трафик статистически эквивалентный с сохранённым.

1.5 Новое направление в существующей области

В последнее набирают популярность атаки, первым этапом которых является определение профилей пользователей компании (или отдельных пользователей). Под профилем - подразумевается частотное распределение посещаемых данным пользователе сетевых ресурсов/сайтов/страниц. К таким атакам относится, в частности “watering hole” [1]. Наша цель заключается в том, чтобы размывать данные профили, т.е. сделать статистически невозможным определение сайтов, которые посещает конкретный пользователь. Данная проблематика становится всё более актуальной в наши дни. На Рис. 1 наглядно представлены масштабы, которые принимает данная проблема. Если же говорить о более конкретных [20] цифрах потерь, то только из одного Центробанка Бангладеш в результате данной атаки было похищено 81млн долларов, и преступники были близки к краже млрд, но данную преступную активность вовремя успели обнаружить и пресечь.

сетевой трафик алгоритм программный



Рисунок 1. Количество организаций и компаний пострадавшие от атаки типа "watering hole" за период октябрь 2016 - март 2017, от одной группы кибер-преступников [20]



Выводы по первой главе

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

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

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

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

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

Диаграмма. 1 Классификация по типу используемых средств



Диаграмма. 2 Классификация по источнику данных для создания пакетов



Глава 2. Описание выбранных методов, моделей, алгоритмов решения задач

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

2.1 Метод генерации запросов

В ситуации необходимости полной симуляции поведения пользователя, приходится оперировать уровнем выше - повторять не трафик, исходящий от пользователя во время его работы, а повторение действий самого пользователя. Что обычный пользователь делает Электронный ресурс: можно выразить как «переходить от сайта к сайту по ссылкам» - а это протокол HTTP, являющийся базой для WWW. В дополнение к этому необходимо отметить, что, помимо переходов по ссылкам, пользователь так же просматривает контент на конкретной странице (читает текст, смотрит картинки/видео), или заполняет некоторую информацию (формы, сообщения, посты). Соответственно, обобщённо, получается следующий список действий пользователя:

1. Переход по ссылке - в этом случае браузер генерирует запрос к веб-серверу, получает HTML код страницы, затем выполняет js-скрипты и подгружает дополнительную информацию, необходимую для корректного отображения страницы такие как: картинки, видео, баннеры сторонних сайтов.

2. Просмотр страницы - в это время с точки зрения сетевого обмена не происходит никаких действий = задержка

3. Взаимодействие со страницей - здесь может быть, как переход на другую страницу, отправка формы так и запуск на выполнение определённого скрипта. В первых двух случаях это ничто иное как обращение к серверу по определённому url, с параметрами. В третьем - исполнение jsскрипта происходит локально, в ином случае его можно классифицировать как отправка формы (= стандартный REST запрос)

В результате получается, что с точки зрения сетевого обмена все действия пользователя можно подразделить на два типа: отправка REST запроса по url адресу и ожидание (простой). Как симулировать второе действие - очевидно. С первым чуть сложнее, но тоже достаточно просто если представить, что составление запроса, его отправку на веб-сервер и последующую обработку ответа предоставить браузеру - такому же, каким пользуется среднестатистический пользователь.

В результате приведённого анализа появилась реализованная концепция полной загрузки веб-страниц браузером. Но существовали ограничения:

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

2. Данное средство (браузер) должно использоваться большим количеством пользователей

3. Легковесность, чтобы была возможность запускать множество потоков (= загрузок) параллельно.

Распределение браузеров по популярности использования на ПК за период с Января по Март 2017 года представлена на рис. 4.



Рисунок 4. Распределение популярности браузеров за 01.17-03.17 [14]

Далее в таблице 2 приведены движки, на которых в данный момент базируются представленные (и некоторые другие, известные в России) браузеры. Отсортирован лист по убыванию процента аудитории, использующего браузеры на данном движке

Таблица. 2. Движки браузеров с процентом аудитории [14]

Движок	Браузеры	Процент аудитории
WebKit (позднее - Blink)	Chrome, Safari, Opera, Яндекс браузер	>68%
Gecko	Mozilla Firefox	14.88%
Trident	IE, Edge	13.48%

По второму пункту требований самым подходящий оказывается движок WebKit. Это открытый движок, разработанный в начале 2000-х в компании Apple. Существуют его связки с KDE, Qt, GTK. Написанный на c++, так же имеет API для работы с ним через python. В итоге, связка WebKit + GTK [17] + python обеспечивает первое и третье требования.



2.2 Создание модели поведения пользователя

2.2.1 Выбор ссылок

Рассмотрим логику поведения пользователей. То, как они попадают на ту или иную страницу:

1. Переход по ссылке, с одной страницы на другую

2. Использование поисковых систем

3. Прямой переход (например, из закладок в браузере)

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

1. Переход по ссылке с одной страницы на другую. Если существует такой переход, значит в HTMLкоде страницы существует соответствующий тэг. Таким образом, алгоритм действий таков: загрузка первой страницы, парсинг HTMLразметки, выбор всех тэгов-ссылок (<a>). Далее случайным образом выбор из получившегося списка ссылки, переход по ней и повторение действий с начала. Другой вариацией этого подхода, является переход по нескольким ссылкам на одной странице (симуляция возврата пользователя назад, и переход в другое место)

2. Использование поисковых систем. Подразумевается отправка пользователем запроса и переход по нескольким наиболее популярным ссылкам. С которыми, далее, возможен повторения сценария из пункта 1. В качестве основной поисковой системы был выбран Google - см. описание пакета google 1.9. в Python package Index [21], в связи с тем, что его использует практически 90% пользователей сети (Рис. 5) А так же у него есть функция отображения наиболее популярных, среди поисковых выдачей страниц. Два способа работы с поисковой системой:

Рисунок 5. Распределение использования поисковых систем пользователями ПК за последние три месяца [14]

a. Запрос вида site:<адрес_сайта> - в данном случае выбираются наиболее релевантные страницы на заданном сайте

b. Задаётся список любых возможных запросов к поисковой системе, и с выдачей по каждому запросу идёт отдельная генерация (проход по первым N ссылкам из выдачи с возможностью углубления по каждой ссылке)

3. Прямой переход. Для реализации данного метода (а также желание не повторяться с предыдущими) было выбрано использование sitemaps (описание протокола [22]). Это, в основном, xml файл, предоставляемый большинством сайтов, в котором находится информация обо всех страницах сайтах и, зачастую, с проставленным приоритетом страниц (= популярностью среди пользователей). Соответственно из данного списка, определённым образом выбираются страницы для дальнейшего открытия. Механизм выбора - настраиваемый: случайным образом или последовательно.



2.2.2 Распределение времени ожидания

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

1. Константа

2. Равномерное

3. Нормальное (с обрезкой отрицательного конца)

Далее делается предположение, что существует два типа просмотра страницы пользователем:

1. Беглый, при котором пользователей определяет, стоит ли ему углубляться в изучение материала, или необходимо искать другой источник - происходит в течении нескольких секунд (редко превышает временной промежуток в 10-20 секунд) - при большом количестве сайтов и усреднении пользователей можно предположить нормальное распределение с математическим ожиданием в районе 10, и дисперсией около 3,5 (= график распределения выглядит как вытянутая колба)

2. Глубокий просмотр - происходит после беглого осмотра, время, затраченное на него, сильно зависит от пользователя и содержания конкретной страницы. Снова, при большом количестве сайтов и усреднении пользователя логичным является использование нормального распределения, но в этот раз с большой дисперсией - из-за сильного разброса в содержимом сайтов. Колба распределения становится гораздо более пологая.

Объединяя два упомянутых распределения - получается сумма нормальных распределений - новое распределение с 5ю параметрами. В программе реализована его упрощённый вид, с предположением что p = Ѕ.

Сумму двух нормальных распределений с весами p и 1-p соответственно можно вычислить по формуле:

Далее было проведено исследование на реальных значениях, по данным ресурса WebStat [23] (которые создатели сайта выложил в открытом доступе). В их базе данных представлены значения - сколько времени пользователь находился на сайте, и сколько страниц он за этот временной промежуток просмотрел. Формат данных представлен в Таблице 3.

Таблица. 3. Часть статистики пользователей сайта web-stat.com [23]

Time	Visit Depth	Visit Duration (sec)
13/05/2017 10:09	1	3
13/05/2017 10:09	2	2
13/05/2017 10:09	2	10
13/05/2017 10:09	2	3
13/05/2017 10:09	1	2
13/05/2017 10:09	4	14
13/05/2017 10:09	1	38
13/05/2017 10:08	2	59
13/05/2017 10:08	2	28
13/05/2017 10:08	1	7
13/05/2017 10:08	1	34
13/05/2017 10:08	4	13
13/05/2017 10:08	1	75
13/05/2017 10:08	1	11
13/05/2017 10:07	1	2

На Рисунках 6 и 7 представлено распределение времени на каждой странице и количество посещённых страниц пользователями. Статистика основана на данных по 8000 пользователям. Синие линии показывают реальные значения количества пользователей. Красные линии - усреднённые значения (в первом случае - полиноминально среднее, во втором - среднее). Данные усреднённые линии напоминаю экспоненциальное распределение. Подтверждение данной гипотезы на Рисунке 8. Синяя линия - распределения вероятностей для каждой секунды в промежутке от 1 до 50 - полученное путём деления количества пользователей, которые были на странице данное количество времени и делёное на общее количество пользователей.

Рисунок 6 Среднее время просмотра 1 страницы пользователём на сайте www.web-stat.com [23]

Рисунок 7 Количество посещённых страниц пользователями сайте www.web-stat.com [23]

Рисунок 8. Сравнение реального распределения времени на одной странице (с сайта www.web-stat.com [23]) с экспоненциальным распределением

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

Но статистические критерии схожести, например, критерий описанный на Рисунке 9, показывают, что гипотеза о схожести не верна. Т.к. после вычисления значение получилось 162499,3412 (при количестве степеней свободы = 50). Что отвергает гипотезу о схожести даже при самых высоких уровнях значимости.



Рисунок 9 Описание способа вычисления критерия хи-квадрат (http://www.machinelearning.ru/wiki/index.php?title=Критерий_хи-квадрат)

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

В результате полный список поддерживающихся распределение следующий:

1. Константа

2. Равномерное

3. Нормальное (с обрезкой отрицательного конца)

4. Сумма двух нормальных (дуал-нормальное)

5. Экспоненциальное

6. Пользовательское

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

2.2.3 Распределение количества посещённых страниц сайта

Так же задаётся распределениями, указанными в предыдущем пункте. Оснований для внесения дополнительных статистических распределений выделено не было так как график реального распределения (Рисунок 9) схож с графиком для количества времени на сайте. При визуальном сравнении с экспоненциальным распределением они так же во многом кажутся схожими, но при проверке критерием (количество степеней свободы - 20) = 1211,81087 - статистически нельзя говорить о схожести этих распределений.

Но эти две характеристик раздельные - т.е. возможно для одного сайта использовать различные распределения для времени ожидания и для количества страниц.

Рисунок 10. Сравнение реального и экспоненциального распределения (лямбда = 0.4) на количество просмотренных пользователем страниц сайта www.web-stat.com

Ещё вводится дополнительная особенность: режим обхода страниц в сети «бесконечный сёрфинг» - когда нет ограничений на количество открываемых страниц. Данный режим работает по следующему алгоритму:

1. Задаётся начальная ссылка, открывается и добавляется время ожидания;

2. Сбор с данной страницы всех активных ссылок;

3. Выбор из списка ссылок одну (случайным образом);

4. Переход по выбранной ссылке, ожидание;

5. Повторение п.2.



Выводы по второй главе

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



Глава 3. Выбор средств реализации программного продукта, проект/прототип программного продукта

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

Поэтому базовым технологическим стеком является:

1. Python 3.4

2. PyGTK 3

3. WebKitGtk

В дополнении к нему, для обеспечения работы логгирования и сбора и отображения статистик:

1. Rsyslog

2. Logstash

3. Elasticsearch 1.4

4. Kibana 3.0

Вся функциональная часть системы разработана в модульном архитектурном подходе.



3.1 Описание модулей

Launcher

Модуль для запуска всей системы в целом. На вход принимает путь к конфигурационному файлу системы, в котором указано количество запускаемых генераторов, их имена и пути к конфигурационным файлам. По полученным данным этот модуль запускает генераторы, как отдельные процессы. Пример конфигурационного файла:

{

"time_to_live": 10000,

"processes": [

{

"name":"Yandex_catalog",

"config":"config/yandex_catalog.json"

},

{

"name":"Surfing",

"config":"config/surfing.json"

}

]

}

Generator

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

Пример конфигурационного файла:

{

“user_agen”: “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30”

“max_time_loading”: 50

"schemes": {

"fast_going": {

"page_generator": "site-scraping",

"time_between_page": {

"type": "uniform",

"low_boundary": 1,

"up_boundary": 5

},

"page_number":{

"type": "uniform",

"low_boundary": 1,

"up_boundary": 10

}

}

},

"sites":[

{

"type": "loaded_list",

"file_type": "xlsx",

"file_name": "support_files/sitelist.xlsx",

"worksheet":"List",

"column":"A",

"count_for_visit": 0,

"scheme": "fast_going"

}

]

}

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

Worker

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

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

1.1. file_type - расширения файла

1.2. file_name - относительный путь к файле

1.3. worksheet - имя листа, на котором находится список

1.4. column - имя колонки в которой находится список

1.5. count_for_visit - количество сайтов из списка для посещения. Если 0 - то бесконечно открывать сайты по-кругу

1.6. scheme - схема обхода (из листа schemes)

2. Loaded_list - задаётся список сайтов (в текущем виде ожидает exel таблицу), и совершает последовательный обход сайтов из этого списка. Так же подразумевается открытие нескольких ссылок на каждом сайте

2.1. url - начальный сайт, точка входа в сёрфинг

2.2. scheme - схема обхода

3. Usual_site - открытие одного сайта, для которого совершается обход в соответствии с заданной схемы

3.1. url - сайт для обхода

3.2. scheme - схема обхода

4. Google Engine - задаётся список запросов (человеко-читаемых) к поисковой системе, количество сайтов для каждой выдачи и способ обхода каждого сайта из выдачи.

4.1. queries - лист запросов к поисковой системе

4.2. site_count - объект задающий распределение, определяющее количество сайтов из выдачи для посещения

4.3. scheme - схема обхода сайта

Utils

Различные методы, которые используется в других модулях. Например: сбор ссылок со страницы сайта, отправка запроса к google и т.п.

Distribution

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

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

"time_between_page": {

"type": "uniform",

"low_boundary": 1,

"up_boundary": 5

},

- На данный момент реализованы все, указанные в п. 2.2 распределения: (в скобках указаны параметры для каждого распределения):

1. Fix (value)

2. Uniform (low_boundary, up_boundary)

3. Positive-normal (M,D)

4. Dual-normal (M1,D1,M2,D2)

5. Exponential (L)

6. Custom (array)

Logger

Вывод в rsyslog статистик о том, какие страницы открывались, время между страницами, и количество страниц на сайте (найденных и открытых). Вывод информации о неисправностях и ошибках в работе.

Кофигурационный файл rsyslog:

:msg,startswith,"PRCSS" /var/log/prcss.log

:msg,startswith,"PRCSS" @@localhost:5544

:msg,startswith," PRCSS" /var/log/prcss.log

:msg,startswith," PRCSS" @@localhost:5544

Конфигурационный файл Logstash:

input {

tcp {

port => 5544

type => syslog

}

udp {

port => 5544

type => syslog

}

}

filter {

if [type] == "syslog" {

grok {

overwrite => "message"

match => {

"message" => "^(?:<%{POSINT:syslog_pri}> ?)?%{SYSLOGTIMESTAMP:timestamp} %{IPORHOST:host} (?:%{PROG:program}(?:\[%{POSINT:pid}\])?:) ?PRCSS %{PROG:mess_type}%{GREEDYDATA:message}"

}

}

syslog_pri { }

date {

# season to taste for your own syslog format(s)

match => [ "timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss", "ISO8601" ]

}

}

}

output {

stdout {codec => rubydebug}

elasticsearch {

host => localhost

protocol => http

}

}

Конфигурационный файл Elasticsearch:

node.local: true

http.cors.allow-origin: "/.*/"

http.cors.enabled: true



3.2 Описание работы журналирования и сбора статистик

Диаграмма 3. Схема работы логирования и сбора статистик



Рисунок 11. Логи работы

Рисунок12. Отображение статистик работы системы

На диаграмме 3 представлена последовательность работы элементов подсистемы журналирования и сбора статистик. На Рисунках 11 и 12 представлен пример результата работы системы в целом, выраженный в логах и графиков статистик.



Выводы по третьей главе

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



Заключение

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

В рамках выпускной квалификационной работы был представлен новый взгляд в этой области, и решалась новая задача - предотвращение атак типа «watering hole» путём размытия профиля пользователя в сети, который достигается за счёт генерации значительного объёма реалистичного трафика. Для реализации поставленной цели были разработаны алгоритмы моделирования поведения пользователя в сети - задающие методы генерации посещённых сайтов и страниц, распределения количества открываемых страниц на каждом сайте и количество времени, отводимое на задержку на данной странице. Был применён метод загрузки страниц, на котором основано большинство современных браузеров - WebKit.

Таким образом, в процессе выполнения ВКР были решены следующие задачи:

1. Изучена область по генерации трафика. В первой главе был произведён подробный анализ существующих методов генерации и способов оценки качестве генерируемого трафика;

2. Разработан механизм statefull-генерации HTTP запросов к серверам с ожиданием ответа и генерацией на его основе следующих запросов путём использования библиотеки WebKit в связке с GTK+

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

4. Разработаны методы моделирования поведения пользователя в сети путём реализации нескольких способов генерации списка страниц и различных распределений для количественных характеристик

5. Разработана модульная архитектура, с возможностью её дальнейшей интеграции в существующую в ИСП РАН систему работы с сетевым трафиком;

6. Разработана программа генерации сетевого трафика с параметрами, задаваемыми через конфигурационные файлы;

7. Разработана техническая документация к созданной программе.

После выполнения всей работы были произведены испытания получившейся системы. Реальные результаты запусков программы показывают, что удалось достичь вероятностных распределений, описанных в разделе 2.2 Создание модели поведения пользователя. Программа и Методика испытаний в разделе 6 Методика Испытаний.

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

- Интеграция разработанной программы в систему работы с сетевым трафиком Института Системного Программирования РАН;

- Расчёт экономической стоимости внедрения и поддержки разработанной системы на предприятиях различных отраслей;

- Реализация методов определения времени на странице через анализ содержимого страницы.



Основные определения, термины и сокращения

DNS (Domain Name System) - протокол для системы доменных имён. Используется для получения IP-адреса по имени хоста

DPDK (Data Plane Development Kit) - набор библиотек и драйверов для высокоскоростной обработки данных (обработки сетевых пакетов)

Framework - программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта

GUI (Graphical User Interface) - графический пользовательский интерфейс

HTML (HyperText Markup Language) -- «язык гипертекстовой разметки» -- стандартизированный язык разметки документов во Всемирной паутине.

HTTP (Hyper Text Transport Protocol) - протокол прикладного уровня передачи данных в сети. Существует набор состояний клиента и сервера при обмене данных (например, 200 - сервер успешно принял и обработал сообщение клиента). Statefull - поддержка всех состояний работы протокола

HTTPS (Hyper Text Transport Protocol Secure) - расширение протокола HTTP, для поддержки шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов SSL (Secure Sockets Layer) или TLS (Transport Layer Security)

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

IDS (Intrusion Detection System) - устройство или приложения для мониторинга сети или системы и обнаружения случившихся вторжений или вирусов

IPS (Intrusion Prevention Systems) - приложение для сетевой безопасности, не допускающее в сеть или систему запросы или файлы, которые могут быть вредоносными

JS (JavaScript) - язык программирования, в основном используется на веб-сайтах

REST (Representational state transfer) запрос - HTTP Get или Post запрос, соответствующий общим архитектурным принципам взаимодействия распределённого приложения.

Statefull HTTP запросы - загрузка html-кода страницы и последующая обработка js-скриптов, поддержка сертификатов для HTTPS, загрузка картинок и иного медиа-контента. Например, в случае страницы отдельного видео на youtube - должна происходить его полная загрузка - как это происходит у пользователей, т.к. включается авто-проигрывание при открытии страницы.

URL (Uniform Resource Locator) - текстовое значение, служит стандартизированным способом записи адреса ресурса в сети Интернет.

Watering Hole - тип сетевых атак, при которых доступ к системе жертвы достигается путём заражения стороннего ресурса.

Wireshark - приложение для захвата и анализа сетевого трафика. На данный момент считается стандартов в данной области

WWW (World Wide Web) - всемирная паутина. Набор всех сайтов, входящих в сеть интернет

Сетевой пакет - последовательный набор байт, передаваемых по сети. Включает в себя несколько заголовков различных уровней. В модели TCP/IP выделяют 4 уровня - канальный, сетевой, транспортный, прикладной. Протоколы канального уровня называют также низкоуровневыми протоколами, последние два - высокоуровневыми. Для каждого из уровней существует определённый набор протоколов.



Список использованных источников

[1] Abendan Oscar Celestino Angelo Watering Hole 101 [Электронный ресурс] // Trend Micro. - 13 02 2013 г.. - 25 01 2017 г.. - https://www.trendmicro.com/vinfo/us/threat-encyclopedia/web-attack/137/watering-hole-101.

[2] Alessio Botta Alberto Dainotti, Antonio Pescapй A tool for the generation of realistic network workload for emerging networking scenarios [Журнал] // Elsevier. - Napoli : Elsevier, 24 March 2012 г.. - 80125 : Т. 21.

[3] Aymen Hafsaoui Navid Nikaein, Lusheng Wang OpenAirInterface Traffic Generator (OTG): A Realistic Traffic Generation Tool for Emerging Application Scenarios. [Отчет] / Mobile Communications Department ; Eurocom. - Sophia : [б.н.], 2012.

[4] Data plane development kit [Электронный ресурс]. - Febuary 2017 г.. - http://dpdk.org.

[5] Field-programmable gate array [Электронный ресурс] // Wikipedia. - 2017 г.. - Febuary 2017 г.. - https://en.wikipedia.org/wiki/Field-programmable_gate_array.

[6] J. Sommers H. Kim, P. Barford Harpoon: a flow-level traffic generator for router and network tests [Отчет]. - [б.м.] : SIGMETRICS, 2013.

[7] Nicola Bonelli Andrea Di Pietro, Stefano Giordano, Gregorio Procissi Flexible High Performance Traffic Generation on Commodity Multi-Core Platforms [Отчет] / Universit`a di Pisa. - Pisa : Universit`a di Pisa, 2014.

[8] P. Srivats Ostinato [Электронный ресурс] // Ostinato. - 2010 г.. - January 2017 г.. - http://ostinato.org.

[9] Paul Emmerich Sebastian Gallenmьller, Daniel Raumer, Florian Wohlfart, Georg Carle MoonGen: A Scriptable High-Speed Packet Generator [Отчет] / Department of Computer Science ; Technische Universitдt Mьnchen. - [б.м.] : Technische Universitдt Mьnchen.

[10] Raffaele Bolla Roberto Bruschi, Marco Canini A High Performance IP Traffic Generation Tool Based on the Intel IXP2400 Network Processor [Журнал]. - [б.м.] : Distributed Cooperative Laboratories: Networking, Instrumentation, and Measurements Signals and Communication Technology, 206 г.. - стр. 127-142.

[11] Sandor Molna Geza Szabo How to Validate Traffic Generators [Конференция] // IEEE International Conference on Communications. - [б.м.] : IEEE ICC'13, 2013.

[12] Shalvi Srivastava Sweta Anmulwar, A.M.Sapkal Comparative Study of Various Traffic Generator Tools [Конференция] // RAECS UIET. - Chandigarh : Panjab University Chandigarh, 2014.

[13] Sommers J. и Barford P. Self-Configuring Network Traffic Generation [Конференция] // IMC'04. - Taormina : IMC, 2004.

[14] StatCounter Statcounter [Электронный ресурс] // Statcounter. - StatCounter. - March 2017 г.. - https://statcounter.com.

[15] Stefano Avallone Antonio Pescapи, Giorgio Ventre Analysis and Experimentation of Internet Traffic Generator [Конференция] // Distributed Computing Systems. - [б.м.] : 10th IEEE International Workshop, 2004. - стр. 277- 283.

[16] Sudhakar Mishra Shefali Sonavane, Anil Gupta Study of Traffic Generation Tools [Журнал] // International Journal of Advanced Research in Computer and Communication Engineering. - 6 2015 г.. - 6 : Т. 4.

[17] The WebKitGTK+ team [Электронный ресурс]. - Febuary 2017 г.. - https://webkitgtk.org.

[18] Xin Su Dafang Zhang, Wenjia Li, Xiaofei Wang AndroGenerator: An automated and configurable android app network traffic generation system [Журнал] // SECURITY AND COMMUNICATION NETWORKS. - [б.м.] : Wiley Online Library, 15 September 2015 г.. - 4273 : Т. 8.

[19] Yeongrak Choi Jae Yoon Chung, Byungchul Park, Paul Barford Automated Classifier Generation for Application-Level Mobile Traffic Identification [Отчет] / Division of IT Convergence Engineering. - Pohang : POSTECH, 2012.

[20] Нефёдова Мария Недавняя атака на польские банки связана с хак-группой Lazarus, взломавшей Sony Picture [Электронный ресурс] // Хакер. - 14 02 2017 г.. - 20 02 2017 г.. - https://xakep.ru/2017/02/14/lazarus-new-campaign/.

[21] Google 1.9.3 Python Package Index [Электронный ресурс]. - March 2017 г.. - https://pypi.python.org/pypi/google.

[22] XML-формат файла Sitemap [Электронный ресурс]. - Febuary 2017 г.. - https://www.sitemaps.org/ru/protocol.html.

[23] Web-Stat / Live Web Traffic Analysis and Visitors Details [Электронный ресурс]. - Febuary 2017 г.. - http://www.web-stat.com.

Размещено на Allbest.ru