10fb7f4e18
- Раздел 22: Балансировщик: мониторинг и диагностика - Раздел 23: Распознавание протоколов (DPI Engine) - Раздел 24: Траблшутинг Каждый раздел включает команды, описания и практические примеры для диагностики и мониторинга работы балансировщика и системы фильтрации.
166 lines
18 KiB
Markdown
166 lines
18 KiB
Markdown
# 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)
|