Файл: Конспект лекций методы инспекции пакетов и анализа трафика (наименование дисциплины) СанктПетербург 2021 1.pdf

2.3 Алгоритм работы серверов DPI
Рассмотрим в упрощенном виде алгоритм работы DPI с указанием задач выполняемых на специализированных серверах системы.
На вход системы DPI поступает пакет. На аппаратном фильтре (HWF) проводится анализ потоков
(ow-based analysis), в процессе которого не учитываются данные пакетов и анализируется метаинформация о потоках. В отличие от packet-based анализа, при котором анализируются данные пакетов, анализ потоков требует меньшую мощность вычислителя. Анализ потоков может выполняться как локально, так и удалјнно от точки сбора данных. Определяются характеристики потока: tuples 7 (о которых говорилось ранее, а так же набор счјтчиков о числе переданных пакетов и байт, время создания и завершения потока. Поток отслеживается не всегда в течение всего промежутка времени из-за ограниченности памяти анализирующего устройства.
Таким образом, система DPI распределяет поступающие пакеты на потоки (сессии) согласно используемым сокетам (tuples 5-7). Скорость поступления пакетов на DPI систему достигает величины в несколько миллионов в секунду, и для контроля за трафиком на такой скорости необходимо применять программную или аппаратную разгрузку, более подробно о которых можно прочесть в [29]. Процедура разгрузки
(Ooading) позволяет поддерживать производительность системы. Аппаратная разгрузка (аппаратный фильтр) позволяет достигнуть большей мощности системы DPI, чем программная разгрузка за счет переноса функций быстрой обработки непосредственно в программируемые логические интегральные схемы (ПЛИС). Кроме того в ПЛИС добавляются функции ограничения скорости потоков и предобработки трафика для дальнейшей классификации. Обычно анализ и извлечение необходимой информации требуют значительных вычислительных ресурсов, и чаще применяют специализированные аппаратные средства.
Однако для добавления новых возможностей DPI путем обновления ПО (т.е. без дополнительных затрат на аппаратную часть), необходимо реализовывать методы анализа пакетов на программном уровне. Программная разгрузка представляет собой специальные функции быстрой обработки, производящие большое количество простых операций с пакетами с малым потреблением вычислительных ресурсов, работающие с уже классифицированными потоками данных. Основные действия которые производит программная разгрузка - это пропуск в соответствии с политикой, подсчет, пересылка пакетов между сетевыми интерфейсами платформы или отброс пакетов.
Если на этапе выделения потоков пакет принадлежит существующему потоку данных, то он передается на аппаратный фильтр (в функцию разгрузки). В HWF проводится анализ 2-4 уровней и заголовков туннелей, а последующий анализ проводится в Front-End (Analyser). В аппаратном фильтре (режиме разгрузки) не ведется анализ 5-7 уровней, но производится подсчет трафика для заданного приложения.
На основе фильтров для ранее определенных потоков, отсеиваются принадлежащие к ним пакеты.
Один или несколько пакетов нового потока подвергаются процедуре анализа на Front-End, с помощью сопоставления с сигнатурами. Пакеты упорядочиваются, т.к. обычно у них нарушена очередность следования,
по причине использования разных маршрутов. При необходимости проводится дешифрование. Для выполнения анализа потока в сервере Front-End (DPI analyser) не обязательно проводить инспекцию всех пакетов потока.
Под сигнатурой понимается шаблон описания данных, который однозначно соответствует приложению или протоколу.
Сигнатурный анализ бывает различных типов (рис.30):
€ стандартная сигнатура (HEX-код);
€ статистическая сигнатура;
€ поведенческая сигнатура;
€ методы data-mining;
€ эврестическая сигнатура.
Стандартной сигнатурой DPI является набор ключевых байт из всей полезной нагрузки (payload inspection). Сигнатура представляет собой фиксированную последовательность символов, которая должна быть расположена в пакете, либо с определенным смещением, либо в случайной позиции. Сигнатуры можно разделить на 3 группы: точное значение строки hex-кода, строка с применением регулярных выражений, и основанные на статистических характеристиках.
Сигнатурный анализ пакетов подразумевает применение стандартных паттернов, по которым можно однозначно определить принадлежность пакета определјнному приложению. Например, по формату заголовков,
номерам портов и т.п.
К статистическим характеристикам потока данных относят: среднюю длину пакета и ее среднеквадратичное отклонение, битовую и пакетную скорость потока, временной интервал между поступлением пакетов. В
большинстве случаев именно эти характеристики больше всего зависят от протокола прикладного уровня
25

Рис. 30: Типы сигнатур
[19]. Так же используется анализ сетевых транзакций, в том числе количества и размера пакетов в ответ на запрос, размер первого пакета в потоке, уровень энтропии в потоке.
Кроме того применяется поведенческий анализ трафика, который позволяет распознать приложения,
не использующие для обмена данными заранее известные заголовки и структуры данных. Поведенческий анализ изучает следующие параметры пакетов принадлежащих одному потоку: транспортный порт отправителя и получателя, размер пакета, частоту открытия новых сессий в единицу времени и т.д. Сигнатурами могут выступать особенности процедур приложения до начала передачи пользовательских данных. Например,
размер пакетов UDP, которыми обмениваются приложения, или размер и количество TCP пакетов при процедурах рукопожатия. Для выявления такого рода поведенческих сигнатур могут применяться методы
Data Mining. Еще одним методом является частотно-временной анализ определенного потока трафика приложения. В момент пользовательской передачи и в момент простоя он позволяет выявить частотно- временные характеристики (ЧВХ) потока. Этот метод можно рассматривать как крайний случай поведенческого анализа. Однако, когда ЧВХ одинакова при передаче и простое, выявление фактов обмена информацией затруднительно, но такую характеристику можно использовать в качестве сигнатуры приложения. Так же на основе ЧВХ потока речи (видео) можно выявить применяемый кодек. Все эти сигнатуры используются для определения приложения, использующего ранее выявленный поток с заданным tuples (IP-адресов и транспортных портов), для дальнейшего контроля над потоком данных (статистики, тарификации,
прослушивания или блокировки)
В целом сигнатурный анализ можно представить как сравнение информации 5-7 уровней модели
OSI каждого из поступивших на Front-End (Analyser) пакетов с базой сигнатур приложений. Обычно в DPI содержится более 1000 сигнатур, которые хранятся в Back-End, и переодически обновляются и дополняются. По мере необходимости Front-End запрашивает сигнатуры с Back-End, и хранит их в своей кэш-памяти.
В результате анализа выявляется приложение, породившее поток пакетов. Сперва проверяется наличие данных о политике обработки потока пакетов для такого приложения в кэш-памяти Front-End. При их отсутствии Front-End запрашивает идентификатор политики, которую необходимо применить к потоку у PCRF. Front-End передает PCRF идентификатор абонента или тип услуги. В PCRF хранится только соответствие номер политики идентификатор абонента/тип услуги, а все подробности политики хранятся в Back-End. Далее Front-End по номеру политики ищет правила ее применения в кэш-памяти, и если их не находит, то запрашивает их у Back-End. Analyser (Front-End) сообщает политики обработки потока пакетов на аппаратный фильтр, который пропускает, ограничивает, перенаправляет поток или совершает другие действия. Далее на аппаратном фильтре (функции сканирования) классифицированный поток обрабатывается в зависимости от применяемой политики.
Помимо режима анализа поступающих в данный момент пакетов DPI системы могут работать в режиме обучения, в котором анализируются примеры разнородных помеченных потоков трафика. Режим обучения имеет следующие этапы: захват пакетов, считывание меток истинных значений потоков трафика,
получение сигнатур и запись в БД (рис.31).
В 2012 г. ITU утвердил Y.2770 Requirements for deep packet inspection in Next Generation Networks
(Рекомендации для глубокого пакетного анализа в сетях следующего поколения)[8] требования к объектам глубокой инспекции пакетов (DPI):
26

Рис. 31: Типы сигнатур
€ идентификация приложений,
€ идентификация потоков,
€ типы проверяемого трафика,
€ управление сигнатурами,
€ представление отчетов системе управления сетью (NMS, Network Management System)
€ взаимодействие с функциональным объектом принятия решения в соответствии с политикой сети.
В рекомендации ITU-T Y.2770[8] определен общий формат правил политики DPI (рис.32). Политика
набор правил по управлению доступом.
Примеры описания политик, в соответствии с рекомендацией Y.2770[8] представлены на рис.34 и рис.35.
Рис. 32: Политика
27

Рис. 33: Политика - расширенное описание
28

Рис. 34: Пример политики 1 29

Рис. 35: Пример политики 2 30

Рис. 36: Политика
Простейшим способом осуществить обработку трафика в соответствии с политикой на практике можно с помощью свободного программного обеспечения (которое естественно имеет ограничения по производительности),
применив такие пакеты как: nDPI (рис.54), IPTables, tc.
Система nDPI предполагает применение одного сервера без взаимодействия. Вендорные системы DPI
обычно не имеют описания сценариев взаимодействия в открытых источниках. Тем не менее, расмотрим возможные варианты сценариев взаимодействия системы DPI отталкиваясь от стандартов ITU-T, 3GPP
и данных в открытых источниках.
Например, при интеграции DPI в СПС, требуется наладить ее взаимодействие с сервером PCRF,
обычно для этого применяется протокол DIAMETER (рис.37).
На рис.38 представлено описание взаимодействия согласно ITU-T Y.2772[10].
2.4 Сигнатурный анализ в DPI
DPI выявляет приложения, использующие:
€ закрытые проприетарные протоколы;
€ с гибким выбором транспортных портов;
€ встроенными механизмами преодоления NAPT (Network Address Port Translation).
Для их определения нельзя ограничиться номером протокола в заголовке IP и номерами портов в заголовке протокола транспортного уровня.
Ранее (рис.30) было дано описание типов сигнатур посредством которых осуществляется определение приложения, которое передает свои данные в потоке пакетов.
DPI анализирует первые пакеты потока трафика или все проходящие через нее пакеты. Применяются:
сигнатурный анализ, статистические методы слежения за характеристиками пакетов, поведенческий анализ и др. Рассмотрим особенности применения различных сигнатур подробнее.
Поведенческий анализ трафика распознает приложения, без заранее известных заголовков и структуры данных. Например, используется для определения BitTorrent. Применяется анализ последовательности пакетов, принадлежащих к одному потоку.
31

Рис. 37: Пример взаимодействия DPI и PCRF при запросе квоты
Рис. 38: Пример взаимодействия DPI и PCRF при запросе квоты
32

Рис. 39: Пример стандартной сигнатуры заданной с помощью программного кода
Суммарное применение различных методов анализа (рис.30) позволяет значительно увеличить точность идентификации трафика.
Так же могут применяться явно заданные правила для блокировки, ограничения, приоритетного обслуживания согласно критерию для какого-либо приложения. Например, для определенного сайта можно указать определенную веб-страницу или пользователя, непосредственно из меню системы DPI,
и задать какое правило следует применить к трафику в случае обнаружения такого запроса.
Сигнатура это набор байт в пакете (рис.39, листинг, рис.40, рис.41) или файле, позволяющий однозначно определить, к какому приложению, протоколу относится трафик, и классифицировать его. Сигнатуры разрабатываются и распространяются вендором. Сигнатура может быть описана с помощью программного кода (рис.42). Базу сигнатур необходимо обновлять автоматически или вручную.
Листинг фрагмента сигнатуры для ozon:
if((packet->payload_packet_len == 18
&& packet->payload[0] == 0x01
&& packet->payload[1] == 0xbb
&& packet->payload[8] == 0xf3
&& packet->payload[9] == 0x34
&& packet->payload[15] == 0x40
&& packet->payload[16] == 0x00)
|| ((packet->payload_packet_len == 31
&& packet->payload[0] == 0x01
&& packet->payload[1] == 0xbb
&& packet->payload[8] == 0x50
&& packet->payload[9] == 0x18
&& packet->payload[12] == 0x00))
) { ...
Стандартные параметры при поведенческий анализе трафика: транспортные порты отправителя и получателя, размер пакета (рис.43, 44, 45), частота открытия новых сессий в единицу времени. Существует множество поведенческих моделей соответствующих протоколов и приложений. Точность определения различается.
Еще одним способом выявления приложения является эврестический анализ. Эврестический алгоритм
- это алгоритм решения задачи, правильность которого для всех возможных случаев не доказана, но про который известно, что он дает достаточно хорошее решение в большинстве случаев. Эврестический анализ - это технология обнаружения по признакам (без гарантированной точности). Используется когда невозможно определить трафик с помощью стандартного сигнатурного анализа, т.к. с помощью поиска и сравнения по базе стандартных сигнатур. Обьектам обнаруживываемым с помощью эврестического анализа присваивается вероятность соответствия (например, 85%). Совместное использование с другими методами анализа позволяет увеличить точность общей идентификации трафика (рис.46).
33

Рис. 40: Вывод nDPI для сигнатуры Ozon
Рис. 41: Вывод ntopng для сигнатуры Ozon
34

Рис. 42: Пример стандартной сигнатуры заданной с помощью программного кода
Рис. 43: Пример поведенческой сигнатуры
35

Рис. 44: Пример поведенческой сигнатуры 2
Рис. 45: Пример поведенческой и статистической сигнатур
36

Рис. 46: Совместное применение сигнатур
37

Рис. 47: Концепция ETSI
3 DPI и СОРМ
3.1 Поколения СОРМ
По известным причинам в телекоммуникационных сетях США, Европы, РФ и других государств давно существует практика законного перехвата телефонных разговоров и сообщений LI (Lawful Interception).
Такие процедуры определены в стандартах европейской ETSI (European Telecommunications Standards
Institute) и североамериканской CALEA (Communications Assistance for Law Enforcement Act)[18, 22]. В
России оборудование законного перехвата известно под названием СОРМ (средства оперативно-розыскных мероприятий).
Концепция законного перехвата описывается в том числе в ETSI TS 101 331 ѕRequirements of Law
Enforcement Agenciesї как показано на рис.47 (в период с 1998 по 2006 год было выпущено большое число документов ETSI пор тематике законного перехвата, а так же у IETF, ATSI, и другие национальные стандарты США, Германии, Нидерландов, Англии и пр.). Где IIF: функция внутреннего перехвата, INI:
внутренний интерфейс сети, а так же 3 канала: HI1: административная информация, HI2: информация,
связанная с перехватом, HI3: содержимое соединения табл.4.
Согласно ETSI HI1 ѕручнойї интерфейс обычно представлен в виде бумажного документооборота, где
LEA на основании выданной лицензии отправляет по факсу или письмом запрос на предоставление услуг законного перехвата. HI2 - интерфейс передачи информации, относящейся к перехватываемому вызову,
предназначен для транспортировки информации IRI (Intercept Related Information) от NWO/AP/SvP к
LEMF/LEA с помощью выбранного для существующей сетевой инфраструктуры протокола передачи данных, например, протокола Х.25. Интерфейс HI3 интерфейс передачи содержимого связи для транспортировки непосредственно содержимого СС (Content of Communication), т.е. самого телефонного разговора, содержания факса или другого передаваемого контента, от NWO/AP/SvP к LEMF/LEA.
Архитектура построения российской СОРМ предусматривает наличие трех каналов передачи информации
1, 2 и 3, которые могут быть помещены в разные временные интервалы тракта E1, число которых определялось согласно рис.48. Первым является специальный административный канал для передачи управляющих сообщений. Данный интерфейс называется канал 1 и может быть отдельным модемным каналом, либо организуется в ИКМ-32(E1). При помощи данного канала ПУ СОРМ (пульт управления)
управляет работой модуля СОРМ на станции и самостоятельно передает команды об установке пользователя на контроль, снятии его с контроля, запрос на передачу статистической информации и т. д.[18]
При постановке абонентов на контроль им присваивается одна из двух его категорий: полный или статистический контроль.
При статистическом контроле на ПУ в реальном масштабе времени должна передаваться только информация о фазах установления соединений и данные о контролируемых вызовах. Кроме того, должна обеспечиваться возможность изменения параметров контроля объекта наблюдения. Для передачи информации статистического контроля используется канал 2.
При полном контроле на ПУ в реальном масштабе времени должна передаться информация о фазах установления соединений, данные о контролируемых вызовах, а также осуществляться съем и трансляция
38