CC BY
4
УДК 004.72
Карина Ж.М. студент магистратуры специальность "Информатика" Костанайский государственный университет
имени А.Байтурсынова научный руководитель: Калакова Г.К.
старший преподаватель кафедра информационных систем и информатики Республика Казахстан, г. Костанай
МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ДАННЫХ ПРИ ПРОВЕДЕНИИ ГЛУБОКОГО АНАЛИЗА ТРАФИКА
Аннотация:
В статье предложена объектная модель представления данных при проведении глубокого анализа сетевого трафика. В отличие от модели, используемой большинством существующих сетевых анализаторов, в ней поддерживается восстановление потоков данных, а также проведение их дальнейшего разбора. Тем самым обеспечивается повышение уровня представления (согласно модели OSI) данных, необходимое при анализе сетевого трафика: для понимания механизмов взаимодействия сетевых приложений нужно восстанавливать данные в том виде, в котором этими данными оперируют приложения. На базе предложенной модели реализована инфраструктура для проведения глубокого анализа трафика. Модель предлагает универсальный механизм связывания разборщиков заголовков сетевых протоколов - появляется возможность для независимой разработки функций разбора.
Ключевые слова: анализ сетевого трафика; восстановление потоков данных; модель представления данных; распознавание данных.
Karma J.M. Magistrantspecialty "Informatics" Kostanay state University named after A. Baitursynov
Republic of Kazakhstan, Kostanay Supervisor: Kalakova G.K.
senior lecturer of the Department of information systems and Informatics MODEL OF DATA HANDLING FOR IN-DEPTH ANALYSIS OF
NETWORK TRAFFIC
Annotation:
The article proposes an object model of data representation in conducting a deep analysis of network traffic. Unlike the model used by most existing network analyzers, it supports the recovery of data streams, as well as their further analysis. This increases the level of representation (according to the OSI model) of data required in the analysis of network traffic: to understand the mechanisms of interaction of network applications, you need to restore the data in the form in which
these data operate applications. On the basis of the proposed model, the infrastructure for in-depth traffic analysis is implemented. The model offers a universal mechanism for linking network Protocol header parsers-there is an opportunity for independent development ofparsing functions.
Keywords: network traffic analysis; data flow recovery; data representation model; data recognition.
В настоящее время задача анализа сетевого трафика имеет большую актуальность: этому способствует развитие и внедрение новых сетевых работ, поддерживается как Грант технологий, так и появление большого количества новых сетевых протоколов на прикладном уровне. Назовем некоторые практические задачи анализа:
• выявление проблем в работе сети
• тестирование (ремонт) сетевых протоколов [1, с.
36].
• сбор статистики, мониторинг сетевых каналов
• предотвращение сетевых атак [3, с. 26].
• Существует большое количество сетевых анализаторов, как коммерческих, так и свободно распространяемых. Как правило, каждый инструмент, опираясь на" базовый " функционал, направлен на анализ заголовков сетевых протоколов и восстановление передаваемых потоков данных. Большинство сетевых анализаторов поддерживает два режима работы:
• анализ трафика, поступающего в сетевой интерфейс
• анализ заранее сохранившихся сетевых трасс (далее-оффлайнализ) в реальном времени (далее-онлайн-анализ) [2, с. 36].
В режиме онлайн-анализа инструмент должен непрерывно работать с достаточной производительностью для анализа трафика, поступающего в сетевой интерфейс. При этом должна быть обеспечена возможность обработки возможного неограниченного потока доходов.
В случае оффлайн-анализа инструмент получает входящие данные из файла (конечный размер). Поэтому по сравнению с онлайн-анализом подобного трафика может быть проведен подробный анализ [4, С. 316].
В настоящее время большинство средств оффлайн полностью повторяет работу в режиме онлайн: вместо сетевого интерфейса пакеты рассчитываются из файла с сетевой трассой. Отсутствие требований к скорости обработки данных в режиме оффлайн открывает дополнительные возможности:
• визуализация структуры всех разобранных данных
• анализ восстановленных потоков данных на прикладном уровне
• использование к данным других дробителей при просмотре результатов (по сравнению с дробильщиком, выбранным инструментом))
• упорядочение модулей анализа тем протокола
• проверка инцидентов нарушения сетевой безопасности Ограничения на проведение подробного оффлайн-анализа в основном
связаны с архитектурными особенностями инструментов: большая часть аналитиков изначально ориентирована на работу в режиме онлайн. При этом отсутствует возможность дальнейшего анализа восстановленных потоков передаваемых данных. Рекомендуется реализовать две независимые системы: один онлайн, другой для оффлайн-анализа. Обе системы должны использовать единую инфраструктуру, включающую модули анализа тем протоколов (полный перечень требований приводится ниже). Созданная по такому принципу система позволяет в полном объеме использовать преимущества оффлайн-анализа, а также осуществлять анализ тематики протоколов и восстановление потоков данных, передаваемых в режиме онлайн. Основной результат, представленный в статье-объектная модель представления сетевых данных, используемая двумя системами.
Достаточно проработаны требования к системам глубокого анализа пакетов, работающих в режиме онлайн: в 2012 году опубликован стандарт МСЭ-Т. В разделе 2 составляется перечень уточненных функциональных требований для каждой системы, из которых сформулируются требования к модели представления данных в натуральном виде. В разделе 3 описана модель данных, используемая аналитиками сетевого трафика, такими как Snort, Wireshark, The Bro Network Security Monitor. Особое внимание уделяется его недостаткам и ограничениям [5, С. 200].
В то же время мы считаем, что данные по данной системе будут передаваться через пакеты. Каждый сетевой пакет состоит из управленческой информации и полезной нагрузки. В ходе анализа в пакете выделяются заголовки протоколов, анализируются значения полей данных тем. Если структура темы определяется спецификацией, то полезная нагрузка может включать данные, организованные свободно, но обычно представляет собой пакет протокола с более высоким уровнем - анализатор должен самостоятельно определить, какой этот протокол является протоколом. При достижении успеха анализ продолжается.
Главное, но естественное ограничение системы онлайн-анализа-это ресурсы вычислительной машины. Поскольку входной поток данных является потенциально неограниченным, необходимо сохранять результаты анализа на жестком диске со временем или при наступлении некоторых событий (или передать их в другой анализатор). Также онлайнанализ не предусматривает визуализацию структуры разобранных данных.
Оффлайн-аналитическая система, напротив, работает с линейной трассой последнего размера (точнее, нет ограничений, связанных с вычислительными ресурсами). Основная цель этой системы-наладка
дробилок. Визуальное отображение структуры разобранных пакетов (визуализация) значительно облегчает процесс ремонта. Также может быть полезен удобный механизм навигации между пакетами и восстановленными потоками.
Многие аналитики поддерживают проведение онлайн-и оффлайн-анализа. В данном случае, компания будет вынуждена отказать в осуществлении страховой выплаты, в случае отсутствия оригинала страхового полиса у одной из сторон. Анализ пакета представляет собой разделение полей всех тем существующих в нем сетевых протоколов. Выбор поля означает сравнение некоторых непрерывных блоков данных определенного размера. В результате выделенный блок может приобрести некоторую семантику, например, блок, указывающий длину пакета. Большинство существующих аналитических систем работают с такими понятиями, как пакет, протокол, блок данных [5, с. 45].]
В соответствии с базовой моделью обработка данных будет выглядеть следующим образом. На вход в средство передается буфер данных (сетевой путь в случае оффлайн-анализа). Выбирается необходимый дробильщик в соответствии с типом данных буфера. Разделяют дробильные блоки и при необходимости вызывают другие функции анализа. Результатом такой системы является некоторая деревянная видимость буфера, в которой в каждом выделенном блоке соответствует пик дерева. Система анализа позволяет аналитику просматривать данные в соответствии с каждым блоком. Назовите основные недостатки основной модели передачи данных:
1.Какие функции должен вызывать каждый дробящий анализ. Это удаляет систему гибкости: при добавлении новых видов необходимо изменить функции анализа существующих видов, так как вы можете использовать подключенные виды. На самом деле, чтобы дать возможность включить эти новые аналитические функции, разработчик должен раскрыть исходный код всех реализованных деталей. Ни один коммерческий анализатор таких возможностей не дает.
2.Деревянная характеристика конструкции не позволяет описывать пакеты с зашифрованными или сжатыми данными. Вместе с тем, объем данных, передаваемых по сети в модифицированном виде, постоянно растет.
3.описание структуры единственного входного буфера со всеми пакетами не позволяет описать построение сеансов. В этом случае под сеансом понимается восстановленная (частичная или полная) единица передачи данных протокола потока, отправленная (или полученная) через более одного сетевого пакета. В некоторых инструментах восстановление сеансов осуществлялось с дополнительными модулями (например, Snort, The Bro Network Security Monitor), однако эти сеансы не подвергаются дальнейшему анализу. Кроме того, анализ собранных сеансов позволяет восстановить данные высокого уровня прикладных протоколов, тем самым определил логику взаимодействия между узлами сети [6, с. 320].
Здесь и далее, по сравнению с базовой моделью, мы называем
расширенной декларируемой моделью. В расширенной модели процесс анализа основан на разделении логических непрерывных блоков данных. Обобщение понятия поля базовой модели (поле в расширенной модели называется блоком, обладающим определенными характеристиками). При анализе блока может потребоваться отдельная обработка какой-либо ее части. Для этого создается новый блок, который является дочерним по отношению к первичному блоку. Понятия родительских и дочерних блоков аналогичны соответственно понятиям родительских и дочерних площадей. Каждый блок характеризуется положительным числом-размером. В процессе анализа на каждом блоке ставится соответствующий тип. Тип (анализ) определяется разборщиком, посредством которого обрабатываются данные блока. Тип имеет уникальное название.
В системе вводится понятие определяющего для осуществления универсального (не требующего внесения изменений в код при добавлении новых типов) разборки. Определитель-это по данным блока и, возможно, некоторые дополнительные сведения определяют тип этого блока. Перед анализом блока его тип известен или нет. В последнем случае необходимо определить тип с помощью определителей. Аналитическая система предлагает функции для регистрации разъединителей на анализ, а также отвечает за правильное использование фиксированных разъединителей. Чаще всего функциональность по распознаванию требуется для полей в заголовках протоколов. Например, поле "Payload" в названии протокола IPv4 может содержать данные протоколов TCP, UDP и др. Формально, для определения типа фрагмента используются данные родительского блока. В этом случае можно выделить следующие значения: При регистрации идентификатора поля в системе необходимо указать название соответствующего поля, а также тип блока родителей. Определение поля используется только для поля с присвоенным именем при наличии данного типа соответствующего родительского блока [7, с. 158].
Для определения типа собранных сеансов используются поточные разъемы. Переключатель входного потока получает только данные соответствующего буфера. Кроме того, может использоваться форма накопления потока (форма накопления потока проставляется в соответствии с типом блоков, поступивших в буфер потока данных). Вид сбора позволяет ограничить (при необходимости) множество разъединителей, используемых в потоке.
Таким образом, можно выделить два варианта: 1) Выбор оборудования; 2) Выбор оборудования; 3) Выбор оборудования; 4) Выбор оборудования. Если определитель потока не использует тип сбора, его можно использовать для определения типа фрагмента.
Таким контекстом для ИС-сеанса является некоторые ИС-сети, а для сеанса TCP-ИС-сеанс в рамках ИС-сайта. Принимая во внимание, что данный высокий уровень должен обладать большим набором модели протокола, который должен обладать идентификационными характеристиками,
глобальная сеть в рамках настоящего Протокола. Для TCP-сеанса протокола, в частности, этот набор включает описание сеанса ИС, а также сеанс ИС. На самом деле, контекстное дерево имеет место, где каждый наконечник определяет набор характеристик для соответствующих сеансов, и этот набор содержит, по крайней мере, характеристики всех и одного дополнительных характеристик пика родителя. Для корня деревянная набор таких характеристик пустой.
К каждой вершине дерева контекста мы связываем набор контекстных экземпляров. Экземпляр контекста - это контекст, для которого известны все значения идентификационных характеристик. Ранее введенное понятие потока характеризует сеанс в полном объеме, а также типом сеанса (определение по типу потока). Сбор осуществляется в рамках экземпляра контекста потока (далее и сохранение).
Описание контекста для создания контекста, добавляя к нему, расширяем ранее введенное понятие модели. Если этот тип имеет обозначение, то система осуществляет контекстное переключение перед анализом блока соответствующего типа ядра (в частности, протокол перед анализом темы протокола IPv4). Каждый момент анализа является активным именно один контекст. Переключение активная замена контекста-это делается, если нужный контекст отсутствует. Контекст контекст данного вида, требующих блок называем вид [6, с. 301.].
Формальные, и контекстные экземпляры контекста предназначены для сгруппирования блоков вложения на одном уровне. На практике речь идет о классификации трафика (в статье подробно о методах классификации). Критерий группирования определяется типом (контекстом) на основе анализа содержания блока определяется конкретной и относящейся ее к группе функцией (в рамках некоторых контекстов каждый экземпляр описывает одну такую группу).
Сбор потоков производится в рамках одного экземпляра контекста. Это означает, что блоки, принадлежащие различным экземплярам контекста, не могут быть частью потока.
Отметим, что на уровне блоков поддерживается семантика (атрибут logic_type): согласно типу (атрибут флаги) блок-структура или структура (аналогично типу "структура" языка Си), либо последовательность. Соответственно, дочерние блоки в первом случае называются полями, а во втором случае - элементами последовательности. Каждое поле характеризуется именем, каждая последовательность элемента-порядковым номером. Расширенная модель, таким образом, полностью покрывает функционал базовой модели. Кроме того, в рамках контекста поток экземпляров идентифицируется ключом (атрибут stream_extensюn), размер (атрибут stream_ext_size) и структура определяется типом контекста [7, с. 90].
В статье представлена объективная модель представления данных, используемая в рамках онлайн - и аналитических инструментов оффлайн. Кроме того, в отличие от базовой модели, расширенная модель, лежащая на
основе анализа сетевого трафика, предлагает функциональность по построению сеансов, работает с модифицированными данными, позволяет разрабатывать независимые модули анализа. Аналогичная модель предлагает инструмент Wireshark помощи, но имеет существенный недостаток: сбор сеансов полностью относится к плечу разработчика аналитических модулей. На уровне ядра Wireshark помощи отсутствуют аналоги таких понятий, как поток, контекст и контекст: для каждого модуля (при необходимости сбор) необходимо их создавать отдельно. В результате, код дробильщиков является логикой перестройки. С другой стороны, предлагаемая в статье модель вводит абстракции для сбора сеансов на уровне ядра, что позволяет значительно упростить (сократить и предотвратить дополнительные ошибки) разделительный код.
Использованные источники:
1. Tsankov P., Dasht M. T., Basin D. SECFUZZ: Fuzz-testing Security Protocols. -М.: AST 2012, 2012.-202 c.
2. Пакулин Н. В., Шнитман В. З., Никешин А. В. Автоматизация тестирования соответствия для телекоммуникационных протоколов. - М.: том 26, выпуск 1, 2014. - 148 с.
3. Scarfone К., Mell P. Guide to Intrusion Detection and Prevention Systems (IDPS), . - М.: February 2007. -447с.
4. Маркин Ю., В., Санаров А. С. Обзор современных инструментов анализа сетевого трафика. - М.: Препринты ИСП РАН, №27, 2014. - 422 с.
5. Пакулин Н. В., Шнитман В. З., Никешин А. В. Тестирование реализаций клиента протокола TLS. - М.: том 27, выпуск 2, 2015. - 160 с.
6. Пакулин Н. В., Шнитман В. З., Никешин А. В. Разработка тестового набора для верификации реализаций протокола безопасности TLS. - М.: том 23, 2012. - 387 с.
7. Risso F., Baldini A., Baldi M., Monclus P., Morandi O. Lightweight, Payload-Based Traffic Classification: An Experimental Evaluation. - М.: Beijing (China), May 2008. - 559 с.
