# 23. Распознавание протоколов (DPI Engine) [← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md) --- Распознавание протоколов — одна из ключевых функций фильтра ТСПУ. Внутренний движок DPI анализирует проходящие сессии и определяет, к какому протоколу или приложению они относятся: Telegram, WhatsApp, Viber, OpenVPN, BitTorrent и другие. Распознавание особенно важно для **шифрованного трафика**, где нет очевидных полей, указывающих на конкретный протокол, и идентификация выполняется **косвенным образом**. ## 23.1. Многофакторный анализ сессий DPI-движок фильтра анализирует не отдельные пакеты, а **целые сессии**. Для распознавания необходимо, чтобы в рамках одной сессии прошло **несколько пакетов** в обоих направлениях — одного первого пакета недостаточно. Анализ проводится по **множеству параметров одновременно** — их может быть десяток и более. Совокупность этих параметров формирует уникальный «профиль» трафика конкретного протокола. ### 23.1.1. Размеры пакетов и их вариации Один из ключевых параметров анализа — **размеры пакетов** в рамках сессии и их **вариации**: - Средний размер пакетов; - Разброс размеров (минимальный, максимальный, стандартное отклонение); - Характерные паттерны размеров (например, первые пакеты одного размера, последующие — другого). Разные протоколы и приложения генерируют пакеты с **характерными размерными профилями**. Например, голосовой трафик мессенджера будет иметь иной размерный профиль, чем передача файлов через тот же мессенджер. ### 23.1.2. Частота прохождения пакетов **Частота прохождения пакетов** — ещё один важный параметр: - Интервалы между пакетами; - Регулярность или нерегулярность этих интервалов; - Всплески активности и паузы. Голосовые вызовы, например, генерируют поток пакетов с **регулярными короткими интервалами**, тогда как обмен текстовыми сообщениями создаёт **нерегулярный** трафик с длительными паузами. ### 23.1.3. Ключевые слова и паттерны внутри пакетов DPI-движок также анализирует **содержимое пакетов** — ищет характерные ключевые слова, последовательности байтов и структурные паттерны: - Специфичные заголовки и поля протокола; - Характерные байтовые последовательности (сигнатуры); - Структура данных внутри пакета (порядок полей, длины полей). Помимо очевидных параметров (source/destination IP, порты), анализируются **менее очевидные** признаки, которые в совокупности позволяют отнести сессию к конкретному протоколу. ### 23.1.4. Особенности анализа шифрованного трафика Шифрованный трафик представляет **особую сложность** для распознавания: - Содержимое пакетов зашифровано — нет очевидных полей, указывающих на протокол; - Ключевые слова и сигнатуры **недоступны** для анализа; - Распознавание выполняется **исключительно косвенными методами** — по размерам пакетов, частоте, вариациям и другим статистическим параметрам. Для распознавания шифрованных протоколов (например, Telegram) используется **многофакторный анализ** — математическая модель, которая на основе совокупности косвенных признаков делает вывод о принадлежности сессии к конкретному протоколу. Конкретные алгоритмы и математика этого анализа являются внутренней разработкой и в открытом виде не раскрываются. > **Принцип работы:** DPI-движок берёт сессию (не один пакет, а несколько пакетов в обоих направлениях), анализирует их по множеству параметров и принимает решение — например, «данный трафик в этой сессии — это Telegram» или «это WhatsApp». ## 23.2. Ложноположительные срабатывания Многофакторный анализ **не является стопроцентным** — возможны **ложноположительные срабатывания** (false positives), когда один шифрованный трафик по тем же косвенным критериям ошибочно распознаётся как другой протокол. Причины ложноположительных срабатываний: | Причина | Описание | | -------------------------------- | ------------------------------------------------------------------------------------------- | | **Похожие профили трафика** | Разные протоколы могут генерировать трафик с похожими размерами пакетов и частотой | | **Шифрование скрывает различия** | Без доступа к содержимому пакетов анализ опирается на меньше признаков | | **Новые версии протоколов** | Обновления приложений могут изменить профиль трафика, сделав его похожим на другой протокол | **Последствия ложного срабатывания:** если фильтр ошибочно распознал легитимный трафик как блокируемый протокол и сразу заблокировал его — пользователь потеряет доступ к полезному ресурсу. Именно поэтому прямая блокировка по результатам DPI на фильтре **не применяется** для протоколов — вместо этого используется двухстадийная схема. ## 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (подробная схема — в [разделе 8](08.md)): ```text ┌─────────────────────────────────────────────────────────────────┐ │ Этап 1: Распознавание (фильтр) │ │ │ │ • DPI-движок анализирует сессию │ │ • Определяет протокол (Telegram, WhatsApp, ...) │ │ • Результат записывается в лог │ │ • Трафик НЕ БЛОКИРУЕТСЯ (behavior: ignore) │ │ • Логи отправляются на SPFS → ЦСУ │ └──────────────────────────┬──────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Очистка (ЦСУ) │ │ │ │ • Сбор логов со ВСЕХ площадок (~350 площадок, ~5000 устройств)│ │ • Сопоставление сессий с разных фильтров │ │ • Глубокий статистический анализ │ │ • Обогащение данных сторонней информацией │ │ • Формирование очищенных списков (IP + порт) │ │ • Вероятность ложного срабатывания — крайне низка │ └──────────────────────────┬──────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ Этап 2: Блокировка (фильтр / Eco Highway) │ │ │ │ • Очищенные списки загружаются на фильтры (HTTP) │ │ и на Eco Highway (BGP) │ │ • Загрузка в ОТДЕЛЬНЫЙ DPI-лист (не тот, где распознавание) │ │ • На этом DPI-листе: behavior: block │ │ • Блокировка по проверенным адресам │ └─────────────────────────────────────────────────────────────────┘ ``` ### Разделение DPI-листов На одном фильтре **одновременно работают два процесса**: | DPI-лист | Behavior | Назначение | | ------------------- | ---------- | ------------------------------------------------------ | | DPI-лист 0 | **ignore** | Распознавание протоколов, запись логов, без блокировки | | DPI-лист 5 (пример) | **block** | Блокировка по очищенным спискам из ЦСУ | Таким образом, распознавание и блокировка выполняются **в разных DPI-листах** — это позволяет независимо управлять каждым процессом. ### Преимущества централизованного анализа ЦСУ видит данные **со всех фильтров на всех площадках**, а не только с одного конкретного устройства. Это даёт принципиально **более полную картину**: - Один фильтр видит только «свои» сессии — ЦСУ видит **все сессии** по всей стране; - Статистический анализ на большой выборке **значительно точнее**; - Возможность обогащения данных **сторонней информацией** повышает качество распознавания. ### Время полного цикла От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 8.6](08.md)). ## 23.4. Обфускация и борьба с обходом блокировок Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации. ### Принцип «нанайских мальчиков» Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны. ### Типы обфускации и возможности распознавания | Тип обфускации | Возможность распознавания | | ------------------------------------------- | ---------------------------------------------------------------------- | | **Простая** (например, XOR) | Фильтр может «развернуть» обфускацию и распознать протокол | | **Протокол притворяется другим** | Распознавание возможно, но требует разработки новых сигнатур и методик | | **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода | ### Обновление сигнатур Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость: 1. **Анализа изменений** — что именно изменилось в новой версии протокола; 2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений; 3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры. > **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения. ### Защита от ложных блокировок при борьбе с обфускацией Двухстадийная система блокировки (раздел 23.3) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников. --- [← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md) · [Раздел 24: Траблшутинг →](24.md)