Оглавление
Введение
Глава 1. Обзор области генерации сетевого трафика
.1 Ostinato
.2 AndroGenerator
.3 MoonGen
.4 OpenAirInterface
.5 Новое направление в существующей области
Выводы по первой главе
Глава 2. Описание выбранных методов, моделей, алгоритмов решения задач
.1 Метод генерации запросов
.2 Создание модели поведения пользователя
.2.1 Выбор ссылок
.2.2 Распределение времени ожидания
.2.3 Распределение количества посещённых страниц сайта
Выводы по второй главе
Глава 3. Выбор средств реализации программного продукта, проект/прототип программного продукта
.1 Описание модулей
.2 Описание работы журналирования и сбора статистик
Выводы по третьей главе
Заключение
Основные определения, термины и сокращения
Список использованных источников
Область генерации синтетического сетевого трафика развивалась вместе с веб и интернет технологиями. Стандартным и общепринятым взглядом на генерацию трафика [12] [15] является вопрос тестирования и развития новый сетевых элементов таких как оборудование, протоколы, приложения относительно их производства и исследования. Это крайне важно - предсказывать поведения компьютерный сетей в реальных условиях. Запуск сетей без соответствующего тестирования с созданием сходных с реальными условиями приводит к повышенному риску при эксплуатации данной новой системы и может быть причиной неожиданного и неприемлемого поведения или неудовлетворительных показателей производительности. Генерация трафика делает возможным тестировать и изучать производительность сетевых систем и без потерь, которые неизбежно происходят при запуске с ошибками в реальных условиях. Генерация трафика помогает исследователям в понимании динамики сетевых соединений и в разработке подходящих модификаций и улучшений в существующих протоколах и оборудовании.
Данный аспект генерации трафика уже очень хорошо изучен [6][7][13][19] и был создан весьма широкий спектр программного обеспечения [16], который будет рассмотрен в первой главе. Но их количество не означает, что данная тема исчерпана. Количество различных генераторов говорит о том, что идеального решения пока нет. Одни [10] тестируют аппаратуру и топологию сети, насколько они хорошо справляются с нагрузкой разного профиля. Другие - веб-серверы, или IDS/IPS. Часть из них концентрируется на временных показателях и размерах пакетов. Другие - на полезной нагрузке протоколов уровня приложений, но поддерживаются только пара протоколов (например, HTTP). Плюс важно в каком виде задаются шаблоны на генерируемую полезную нагрузку и какие дополнительные ограничения это подразумевает.
В рамках данной работы была поставлена цель - разработать программу для генерации сетевого трафика с заданными параметрами. Для достижения этой цели необходимо решить задачи:
. Изучить область по генерации трафика. Существующие решения и методы;
. Разработать механизм statefull-генерации HTTP запросов к серверам с ожиданием ответа и генерацией на его основе следующих запросов;
. Собрать статистические данные по поведению пользователей в сети интернет;
. Разработать методы моделирования поведения пользователя в сети;
. Разработать модульную архитектуру создаваемой программе, с возможностью её дальнейшей интеграции в существующую в ИСП РАН систему работы с сетевым трафиком;
. Разработать программу генерации сетевого трафика с параметрами, задаваемыми через конфигурационные файлы;
. Разработать техническую документацию.
Работа структурирована следующим образом: в первой главе приводится обзор
области генерации трафика, существующие подходы и решения. Так же выделяется
новое направление в новой области и объясняется его актуальность. Вторая глава
посвящена разбору методов решения проблемы на выбранном направлении. Алгоритмы
создания списков страниц и моделирование поведения пользователя. В третьей
главе описаны особенности реализации программы.
Генерация сетевых данных в высокой степени зависит от уровня [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], и отправки пакетов на сетевую карту напрямую, без обращений к операционной системе.
В качестве целей создания отмечается важность для сетевых операторов и аналитиков безопасности понимания сетевого трафика, создаваемого новыми приложениями для 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. Создания трафика ограничивается двумя способами:
. Копируя сохранённые трассы;
. Генерируя трафик статистически эквивалентный с сохранённым.
В последнее набирают популярность атаки, первым этапом которых является определение профилей пользователей компании (или отдельных пользователей). Под профилем - подразумевается частотное распределение посещаемых данным пользователе сетевых ресурсов/сайтов/страниц. К таким атакам относится, в частности “watering hole” [1]. Наша цель заключается в том, чтобы размывать данные профили, т.е. сделать статистически невозможным определение сайтов, которые посещает конкретный пользователь. Данная проблематика становится всё более актуальной в наши дни. На Рис. 1 наглядно представлены масштабы, которые принимает данная проблема. Если же говорить о более конкретных [20] цифрах потерь, то только из одного Центробанка Бангладеш в результате данной атаки было похищено 81млн долларов, и преступники были близки к краже млрд, но данную преступную активность вовремя успели обнаружить и пресечь.
сетевой трафик алгоритм программный
Рисунок 1. Количество организаций и компаний пострадавшие от атаки типа
"watering hole" за период октябрь 2016 - март 2017, от одной группы
кибер-преступников [20]
Выводы по первой главе
Основываясь на приведённых аналогах и в целом на изучении области, можно разделить существующие подходы к генерации трафика на несколько категорий по нескольким определяющим характеристикам. На первой диаграмме представлено существующее разделение программ по тому, на каком уровне происходит формирование пакетов. На следующем - по принципу построения сетевых пакетов и потоков. Как было упомянуто ранее, аппаратные решения не предоставляют достаточной точности в симуляции протоколов верхнего уровня и стоимость таких решений гораздо выше программных. Второй фактор так же относится и к смешанному подходу. В связи с этим для новой, разработанной системы был выбран чисто программный подход - т.к. необходима поддержка statefull HTTP запросов. Для достижения удовлетворительных скоростных показателей, реализуется кластерный подход, при котором запуск возможен одновременно на многих узлах, и при этом достигается почти линейная зависимость выдаваемой производительности от количества участвующих в генерации узлов.