Источник: https://github.com/AnaktaCTF/CTF/blob/main — Forensic/DPI Engine.md

Что такое DPI Engine

Введение

Технология DPI (Deep Packet Inspection) зачастую ассоциируется с блокировками, цензурой и различными ограничениями. Однако DPI — это лишь инструмент глубокого анализа сетевого трафика. В отличие от простого изучения отдельных уровней (например, только HTTP-заголовков), DPI анализирует пакет целиком, включая все уровни модели OSI.

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

Кроме того, DPI-системы выполняют не только классификацию сетевых потоков, но и участвуют в авторизации пользователей, применении политик доступа, ограничении скорости и контроле за соблюдением этих правил. Постоянное развитие сервисов и сетевых технологий — от смены доменов и брендов до появления новых протоколов и CDN — требует от DPI-решений гибкости и высокой точности. Этим задачам и посвящён отдельный класс систем — DPI Engine, которые отвечают за глубокий анализ и динамическую классификацию трафика независимо от типа сети.

Что такое сетевой протокол, пакет и слой?

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

Пакет — это определённым образом организованный набор байт, который поступает или отправляется через сетевой интерфейс.

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

Слой — это часть пакета, которая соответствует какому-то конкретному протоколу. Один и тот же байт не может относиться к нескольким протоколам одновременно — он принадлежит только одному слою.

Поле— это часть слоя, предназначенная для хранения определённой информации. Например, в заголовке IPv4, который обычно занимает 20 байт, на 12-м байте начинается поле с адресом отправителя (4 байта), а с 16-го байта — поле с адресом получателя (также 4 байта).

Слои протоколов внутри пакета

OSI

OSI (Open Systems Interconnection model) – иерархичная, многоуровневая модель сетевых протоколов, каждый уровень которой имеет свою роль в рамках передачи данных.

Модель OSI

Упрощённо описывая уровни OSI модели, можно сказать следующее:

Сетевой уровень отвечает за доставку данных на основе IP-адресов, то есть определяет маршрут к получателю в сети.

Транспортный уровень направляет данные не просто на устройство, но и в нужное приложение, используя порты — своего рода «адреса» внутри устройства.

Уровень представления заботится о том, как именно передаются данные: здесь происходит шифрование, сжатие и другие преобразования.

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

Передача данных согласно модели OSI

Сетевой поток (network flow) — это логическая группа сетевых пакетов, которые объединяются по определённым признакам. Если представить интернет как бесконечный поток разрозненных пакетов между множеством устройств, то сетевой поток помогает навести порядок и разбить этот хаос на осмысленные группы.

Например, если пакеты имеют одинаковые IP-адреса отправителя и получателя, их можно считать частью одного IP потока. Если к этому добавить ещё совпадающие TCP или UDP порты, то речь уже идёт о конкретном TCP или UDP соединении. У одного устройства может быть несколько таких соединений с другим устройством.

Таким образом, поток — это нечто вроде условной трубы, по которой в одном направлении «летят» пакеты от клиента к серверу, а по другой — обратно. Это удобно для анализа, мониторинга и управления трафиком.

Важно не путать сетевой поток (flow) с потоком исполнения (thread) — это совершенно разные понятия.

Прямой и реверсивный потоки

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

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

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

ТИП	Описание	Ключ
Tuple3	IPv4/IPv6 фрагментированный поток	{ src_ip, dst_ip, id }
Tuple5	IPv4/IPv6 поток с привязкой к портам и транспортному протоколу	{ src_ip, src_port, dst_ip, dst_port, protocol }
Tuple6	Тоннельный поток (VLAN-C-TAG, GRE, …)	{ src_ip, src_port, dst_ip, dst_port, protocol, tag }

То есть чтобы рассчитать ключ, нужно добраться до IP слоя, извлечь IP адреса, проверить, что поток не фрагментирован (проверка offset-ов и MF флага). Если пакет IP фрагментирован – взять поле ID и собрать Tuple3 ключ. Если не фрагментирован – дойти до следующего за IP слоя, извлечь порты (если это транспортный слой, и они есть) и собрать Tuple5 ключ.

Пример таблицы потоков

На схеме выше показано поле идентификатора для дальнейших ссылок, но фактически для поиска используется только поле key.

Ранее мы рассмотрели потоки с точки зрения их группировки по типу ключа — это важно для контроля контекста потока (буферизация данных, сбор статистики и т.д.). Однако есть и другая классификация — по плоскостям: Control Plane и User (или Data) Plane.

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

Например, в FTP протоколе: после установления TCP соединения клиент вводит логин/пароль, перемещается по каталогам, запрашивает размеры файлов — всё это Control Plane. Когда же начинается передача файла (после анонса сервером отдельного сокета), создаётся отдельный поток для передачи данных — это и есть User Plane поток.

Направление потоков

Потоки обычно делят на два направления: Client-To-Server (CTS) и Server-To-Client (STC). Чтобы определить, кто клиент, нужно понять, кто инициировал соединение. Например, если в TCP пакете установлен только флаг SYN — это первый пакет в сессии, а значит инициатором соединения является сокет src_ip:src_port. Этот поток будет направлен от клиента к серверу (CTS). Соответственно, если инвертировать IP-адреса и порты, получится поток от сервера к клиенту (STC).

На схеме выше видно, как прямой и обратный потоки (с идентификаторами 1 и 2) формируют сессию. В данном случае сервер — это устройство с адресом 192.168.1.33, на котором работает SSH-сервис на порту 22.

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

Кажется, что все пакеты, снятые с интерфейса Uplink, должны быть связаны с потоком CTS (Client-To-Server), а пакеты, снятые с Downlink, — с потоком STC (Server-To-Client). Однако это не всегда так. Например, если пользователь развернул мини-сервер у себя дома (с файловым хранилищем) и запросил статический IP-адрес у провайдера, то когда он едет в отпуск и подключается к своему серверу через интернет, трафик от сервера к пользователю (STC) будет идти по интерфейсу Uplink для провайдера, а трафик от пользователя к серверу (CTS) — по интерфейсу Downlink.

На схеме 6 изображены два устройства, подключённые к точке доступа (домашний роутер), которая, в свою очередь, связана с провайдером интернета (ISP). Для роутера и ISP весь трафик, идущий от планшета и ноутбука, будет считаться Uplink. Трафик, идущий от роутера к этим устройствам, будет Downlink.

Что такое reassembling?

Процесс reassembling (пересборки) в сетевых технологиях можно сравнить с тем, как перевозят грузы на поездах, когда несколько вагонов используются для доставки одного большого объема. Например, если нужно отправить 180 тонн угля, а вагон вмещает только 60 тонн, для доставки всей массы потребуется три вагона. Аналогично, в сети данные могут быть слишком большими для отправки в одном пакете, и они могут быть разделены на несколько частей, которые передаются отдельно. Когда все эти части (пакеты) приходят в пункт назначения, их необходимо собрать в одно целое сообщение — это и есть процесс reassembling.

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

Сегментация и фрагментация происходят на разных уровнях модели OSI и включают в себя такие протоколы, как IPv4/IPv6, TCP, DTLS, OpenVPN, QUIC, HTTP/2 и другие.

Например, если в сети используется фрагментация на уровне IPv4/IPv6, задача reassembler-а усложняется, так как он должен сначала собрать фрагменты на уровне IP, а потом – на транспортном уровне. В некоторых случаях, особенно когда используются более высокоуровневые протоколы, может потребоваться и сборка на уровне приложения.

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

Пример работы с reassembling в сети

Сборка сообщения

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

На стадии 0 пользовательское устройство отправляет 4 TCP сегмента на точку доступа (AP). Однако, по какой-то причине, точка доступа передает только 3 из них, и один сегмент задерживается. Затем, на стадии 1, точка доступа передает эти 3 сегмента на Интернет-поставщика (ISP), но из-за каких-то причин ISP может передать только два сегмента DPI-системе. На этом этапе, несмотря на то что часть сегментов уже передана, DPI-устройству еще недостаточно информации для того, чтобы принять решение о пропуске трафика или его блокировке.

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

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

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

Как reassembling влияет на классификацию трафика

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

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

В итоге, reassembling замедляет классификацию и увеличивает нагрузку на систему DPI, особенно в случае с большими объемами трафика.