Новая нумерация и оглавление по частям, раздел 22 объединён, заглушки по старым адресам

2026-10-02 03:38:09 +03:00 · 2026-09-23 21:15:53 +02:00
parent 0d45afd550
commit f53aed1ef6
48 changed files with 749 additions and 596 deletions
@@ -1,18 +1,18 @@
-# 23. Распознавание протоколов (DPI Engine)
+# 22. Распознавание протоколов и двухстадийная блокировка

-[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md)
+[← Оглавление](../README.md) · [← Раздел 21: Центральная система управления](central-management.md)

 ---

 Распознавание протоколов — одна из ключевых функций фильтра ТСПУ. Внутренний движок DPI анализирует проходящие сессии и определяет, к какому протоколу или приложению они относятся: Telegram, WhatsApp, Viber, OpenVPN, BitTorrent и другие. Распознавание особенно важно для **шифрованного трафика**, где нет очевидных полей, указывающих на конкретный протокол, и идентификация выполняется **косвенным образом**.

-## 23.1. Многофакторный анализ сессий
+## 22.1. Многофакторный анализ сессий

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

 Анализ проводится по **множеству параметров одновременно** — их может быть десяток и более. Совокупность этих параметров формирует уникальный «профиль» трафика конкретного протокола.

-### 23.1.1. Размеры пакетов и их вариации
+### 22.1.1. Размеры пакетов и их вариации

 Один из ключевых параметров анализа — **размеры пакетов** в рамках сессии и их **вариации**:

@@ -22,7 +22,7 @@ DPI-движок фильтра анализирует не отдельные

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

-### 23.1.2. Частота прохождения пакетов
+### 22.1.2. Частота прохождения пакетов

 **Частота прохождения пакетов** — ещё один важный параметр:

@@ -32,7 +32,7 @@ DPI-движок фильтра анализирует не отдельные

 Голосовые вызовы, например, генерируют поток пакетов с **регулярными короткими интервалами**, тогда как обмен текстовыми сообщениями создаёт **нерегулярный** трафик с длительными паузами.

-### 23.1.3. Ключевые слова и паттерны внутри пакетов
+### 22.1.3. Ключевые слова и паттерны внутри пакетов

 DPI-движок также анализирует **содержимое пакетов** — ищет характерные ключевые слова, последовательности байтов и структурные паттерны:

@@ -42,7 +42,7 @@ DPI-движок также анализирует **содержимое пак

 Помимо очевидных параметров (source/destination IP, порты), анализируются **менее очевидные** признаки, которые в совокупности позволяют отнести сессию к конкретному протоколу.

-### 23.1.4. Особенности анализа шифрованного трафика
+### 22.1.4. Особенности анализа шифрованного трафика

 Шифрованный трафик представляет **особую сложность** для распознавания:

@@ -54,7 +54,7 @@ DPI-движок также анализирует **содержимое пак

 > **Принцип работы:** DPI-движок берёт сессию (не один пакет, а несколько пакетов в обоих направлениях), анализирует их по множеству параметров и принимает решение — например, «данный трафик в этой сессии — это Telegram» или «это WhatsApp».

-## 23.2. Ложноположительные срабатывания
+## 22.2. Ложноположительные срабатывания

 Многофакторный анализ **не является стопроцентным** — возможны **ложноположительные срабатывания** (false positives), когда один шифрованный трафик по тем же косвенным критериям ошибочно распознаётся как другой протокол.

@@ -68,9 +68,39 @@ DPI-движок также анализирует **содержимое пак

 **Последствия ложного срабатывания:** если фильтр ошибочно распознал легитимный трафик как блокируемый протокол и сразу заблокировал его — пользователь потеряет доступ к полезному ресурсу. Именно поэтому прямая блокировка по результатам DPI на фильтре **не применяется** для протоколов — вместо этого используется двухстадийная схема.

-## 23.3. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка
+## 22.3. Обфускация и борьба с обходом блокировок

-Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (подробная схема — в [разделе 8](08.md)):
+Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации.
+
+### Принцип «нанайских мальчиков»
+
+Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны.
+
+### Типы обфускации и возможности распознавания
+
+| Тип обфускации                              | Возможность распознавания                                              |
+| ------------------------------------------- | ---------------------------------------------------------------------- |
+| **Простая** (например, XOR)                 | Фильтр может «развернуть» обфускацию и распознать протокол             |
+| **Протокол притворяется другим**            | Распознавание возможно, но требует разработки новых сигнатур и методик |
+| **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода  |
+
+### Обновление сигнатур
+
+Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость:
+
+1. **Анализа изменений** — что именно изменилось в новой версии протокола;
+2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений;
+3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры.
+
+> **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения.
+
+### Защита от ложных блокировок при борьбе с обфускацией
+
+Двухстадийная система блокировки (раздел 22.4) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников.
+
+## 22.4. Двухстадийная блокировка: распознавание → очистка в ЦСУ → блокировка
+
+Для минимизации ложноположительных срабатываний блокировка протоколов выполняется **в два этапа** (этапы подробно описаны ниже — в [разделах 22.5–22.10](#225-первый-этап-распознавание-протоколов-на-фильтрах-тспу-тип-а)):

 ```text
    ┌─────────────────────────────────────────────────────────────────┐
@@ -128,38 +158,155 @@ DPI-движок также анализирует **содержимое пак

 ### Время полного цикла

-От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 8.6](08.md)).
+От момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки проходит **от 5 до 15 минут** (подробнее — в [разделе 22.10](#2210-время-полного-цикла-блокировки-515-минут)).

-## 23.4. Обфускация и борьба с обходом блокировок
+## 22.5. Первый этап: распознавание протоколов на фильтрах (ТСПУ тип А)

-Обфускация — это намеренное изменение характеристик протокола, направленное на то, чтобы DPI-движок **не смог его распознать**. Это постоянная «гонка вооружений» между разработчиками средств обхода блокировок и разработчиками систем фильтрации.
+Блокировка протоколов (Telegram, WhatsApp, Viber и др.) в системе ТСПУ реализована **в два этапа** — так называемая двухстадийная блокировка. Необходимость двухстадийного подхода обусловлена природой распознавания шифрованного трафика: фильтр анализирует сессию по множеству косвенных признаков (размеры пакетов, частота прохождения, вариации размеров, ключевые слова внутри пакетов), и такое распознавание **не является стопроцентным**. Возможны ложноположительные срабатывания — когда другой шифрованный трафик по тем же критериям ошибочно распознаётся как, например, Telegram. Прямая блокировка по результатам DPI на фильтре привела бы к случайной блокировке легитимных ресурсов.

-### Принцип «нанайских мальчиков»
+На **первом этапе** фильтры ТСПУ тип А выполняют только **распознавание** протоколов, но **не блокируют** их:

-Борьба между системами обхода и системами блокировки описывается как **постоянное противостояние**: одна сторона в какой-то момент имеет преимущество, которое затем нивелируется следующим шагом противоположной стороны.
+1. Трафик проходит через фильтр и обрабатывается движком DPI;
+2. DPI-движок анализирует каждую сессию по множеству параметров (многофакторный анализ) и определяет, к какому протоколу она относится;
+3. Фильтр фиксирует результат распознавания в виде **протокольного лога** — записи о том, что конкретная сессия предварительно опознана как сессия определённого протокола;
+4. Сессия при этом **не блокируется** — трафик продолжает проходить без ограничений.

-### Типы обфускации и возможности распознавания
+Распознавание выполняется в отдельном DPI-листе, на котором установлен режим **behavior: ignore** — это означает, что срабатывание правил фиксируется, но никаких блокирующих действий не предпринимается. Лист 0 для этого не используется: в нём по умолчанию работает фильтрация по реестру Роскомнадзора ([раздел 10.1.3](filter.md)).

-| Тип обфускации                              | Возможность распознавания                                              |
-| ------------------------------------------- | ---------------------------------------------------------------------- |
-| **Простая** (например, XOR)                 | Фильтр может «развернуть» обфускацию и распознать протокол             |
-| **Протокол притворяется другим**            | Распознавание возможно, но требует разработки новых сигнатур и методик |
-| **Качественная имитация другого протокола** | Распознать **невозможно** без разработки принципиально нового подхода  |
+## 22.6. Отправка логов на SPFS (сервер предварительного формирования списков)

-### Обновление сигнатур
+Протокольные логи с результатами распознавания отправляются с фильтров на **SPFS** (сервер предварительного формирования списков), расположенный на той же площадке ТСПУ.

-Когда обнаруживается, что новая версия приложения или протокола **перестала распознаваться** фильтром, это означает необходимость:
+Отправка настраивается в секции **debug logger** конфигурации фильтра:

-1. **Анализа изменений** — что именно изменилось в новой версии протокола;
-2. **Разработки новой сигнатуры** — обновление правил распознавания для учёта изменений;
-3. **Обновления прошивки** — доставка обновлённого DPI-движка на фильтры.
+- **Включение отправки** — секция активируется для нужных протоколов;
+- **Выбор протоколов** — по умолчанию `all` (все распознаваемые протоколы), но можно указать только конкретные (Telegram, WhatsApp и т.д.);
+- **Количество пакетов на протокол** — определяет, сколько пакетов из каждой распознанной сессии будет отправлено в лог. По умолчанию значение 0 (без ограничения, что соответствует первым 30 пакетам). На практике для корректного анализа достаточно **3 пакетов** — это значение было подтверждено в ходе тестов на Урале. Значение 30 генерирует избыточный объём лог-трафика;
+- **Лог-интерфейс** — по умолчанию используется выделенный лог-интерфейс (DPDK). Возможно переключение на management-интерфейс, однако это **не рекомендуется**, так как производительность отправки логов значительно снизится;
+- **Адрес и порт назначения** — указываются координаты сервера SPFS на площадке.

-> **Практический подход:** к этому процессу следует относиться с пониманием — это нормальная и ожидаемая ситуация. Полное и постоянное распознавание всех протоколов **невозможно** в принципе. Задача системы — поддерживать актуальные сигнатуры и оперативно реагировать на изменения.
+SPFS занимается **накоплением** поступающих протокольных логов со всех фильтров площадки и их **предварительной обработкой** перед отправкой в центральную систему управления.

-### Защита от ложных блокировок при борьбе с обфускацией
+## 22.7. Передача логов по GRPC в центральную систему управления

-Двухстадийная система блокировки (раздел 23.3) особенно важна в контексте борьбы с обфускацией. Обфусцированный трафик **по определению** имеет нестандартный профиль, что повышает вероятность ложноположительного срабатывания. Централизованная очистка на ЦСУ снижает этот риск, сопоставляя данные с множества источников.
+Накопленные и предварительно обработанные логи SPFS передаёт в **центральную систему управления (ЦСУ)** по протоколу **gRPC**.
+
+```text
+    ТСПУ тип А (площадка)               Центральная система управления
+    ┌──────────────────────┐             ┌──────────────────────────┐
+    │                      │             │                          │
+    │  Фильтр 1 ──┐       │             │  Подсистема формирования │
+    │  Фильтр 2 ──┼→ SPFS ├── gRPC ───→│  списков фильтрации      │
+    │  Фильтр N ──┘       │             │                          │
+    │                      │    VPN      │  • Сбор логов со всех   │
+    └──────────────────────┘  (Континент)│    площадок ТСПУ тип А  │
+                                         │  • Сохранение в БД       │
+    ТСПУ тип А (площадка)               │  • Периодический анализ  │
+    ┌──────────────────────┐             │  • Формирование списков  │
+    │                      │             │                          │
+    │  Фильтр 1 ──┐       │             └──────────────────────────┘
+    │  Фильтр 2 ──┼→ SPFS ├── gRPC ───→
+    │  Фильтр N ──┘       │
+    │                      │
+    └──────────────────────┘
+```
+
+ЦСУ представляет собой **многокомпонентную распределённую систему**, развёрнутую на двух независимых площадках. Связь между площадками ТСПУ и ЦСУ осуществляется через **VPN** (криптошлюз «Континент»). Данные поступают со **всех площадок** ТСПУ тип А по всей стране — это порядка 350 площадок и около 5 000 устройств.
+
+Протокольные логи отправляются **только с фильтров ТСПУ тип А** (первого эшелона). Фильтры ТСПУ тип Б (эшелон) протокольных логов **не генерируют** — на них отсутствует функционал распознавания протоколов, поскольку блокировка протоколов на эшелоне выполняется самим балансировщиком Eco Highway по уже готовым спискам.
+
+## 22.8. Анализ, очистка от ложных срабатываний, формирование списков
+
+Внутри ЦСУ за обработку протокольных логов отвечает **подсистема формирования списков фильтрации**. Эта подсистема выполняет несколько ключевых функций:
+
+**Сбор и хранение.** Логи со всех площадок ТСПУ тип А сохраняются в базе данных ЦСУ. Система агрегирует данные с множества фильтров, что даёт ей **значительно более полную картину**, чем та, которую видит каждый отдельный фильтр.
+
+**Периодический анализ.** С заданной периодичностью подсистема проводит анализ накопленных данных. Периодичность анализа — **настраиваемый параметр**: можно запускать анализ раз в минуту, раз в 5 минут и т.д. Более частый анализ требует большей производительности серверов.
+
+**Очистка от ложных срабатываний.** Ключевое преимущество централизованного анализа — возможность проведения **более глубокого анализа**, чем на отдельном фильтре:
+
+- **Сопоставление сессий с различных устройств** — ЦСУ видит данные с множества фильтров на разных площадках, а не только с одного конкретного. Это позволяет выявлять закономерности, недоступные на уровне единичного фильтра;
+- **Статистический анализ** — использование накопленных статистических данных для верификации результатов распознавания;
+- **Обогащение данных** — дополнение результатов распознавания сторонней информацией для повышения точности;
+- **Выделение конкретных адресов** — на примере Telegram: из всех сессий, распознанных как Telegram, формируется список IP-адресов и портов, на которых были обнаружены серверы Telegram или его прокси различных типов.
+
+**Формирование очищенных списков.** По результатам анализа создаются **очищенные списки**, в которых вероятность ложноположительного срабатывания **крайне низка**. Эти списки содержат конкретные IP-адреса и порты (для каждого протокола — свой список), которые система с высокой степенью уверенности идентифицировала как принадлежащие блокируемому протоколу.
+
+## 22.9. Загрузка очищенных списков обратно на фильтры (HTTP) и на Eco Highway (BGP)
+
+Сформированные очищенные списки загружаются обратно на оборудование ТСПУ двумя путями:
+
+### Загрузка на фильтры ТСПУ тип А (по HTTP)
+
+Очищенные списки загружаются на фильтры по протоколу **HTTP** в **отдельный DPI-лист**, отличный от того, в котором выполняется распознавание:
+
+| DPI-лист | Назначение | Behavior |
+|----------|-----------|----------|
+| Лист распознавания | Распознавание протоколов (первый этап) | **ignore** — срабатывание фиксируется, но не блокируется |
+| DPI-лист 5 (пример) | Блокировка по очищенным спискам из ЦСУ | **block** — трафик блокируется |
+
+Таким образом, на одном фильтре **одновременно работают два процесса**:
+- в листе распознавания продолжается распознавание новых сессий и отправка логов;
+- в DPI-листе 5 выполняется блокировка по уже проверенным и очищенным спискам.
+
+### Загрузка на Eco Highway (по BGP)
+
+Те же очищенные списки, но в **несколько ином формате**, загружаются по протоколу **BGP** на балансировщики **Eco Highway** (ТСПУ тип Б). На эшелоне блокировка протоколов выполняется **самим балансировщиком** по IP-адресам и портам — без участия фильтров.
+
+```text
+    Центральная система управления
+    ┌──────────────────────────────┐
+    │  Очищенные списки            │
+    │  (IP + порт для каждого     │
+    │   протокола)                │
+    └───────┬──────────┬──────────┘
+            │          │
+        HTTP │          │ BGP
+            │          │
+            ▼          ▼
+    ┌───────────┐  ┌───────────┐
+    │  Фильтры  │  │   Eco     │
+    │  ТСПУ А   │  │  Highway  │
+    │           │  │  ТСПУ Б   │
+    │ DPI-лист 5│  │           │
+    │ behavior: │  │ Блокировка│
+    │   block   │  │ по L3/L4  │
+    └───────────┘  └───────────┘
+```
+
+Фильтры ТСПУ тип Б получают от Eco Highway только тот трафик, который требует URL-фильтрации по реестру РКН. Блокировка протоколов в прошивке фильтров эшелона **отсутствует** — она не нужна, поскольку этим занимается сам балансировщик.
+
+## 22.10. Время полного цикла блокировки: ~5–15 минут
+
+Полный цикл двухстадийной блокировки — от момента появления нового, ранее неизвестного сервера блокируемого протокола до его фактической блокировки — составляет **от 5 до 15 минут**.
+
+```text
+    ┌────────────────────────────────────────────────────────────────┐
+    │                    Полный цикл блокировки                     │
+    │                                                               │
+    │  1. Абонент подключается к новому серверу       ─┐            │
+    │     (например, новая Telegram-прокси)             │            │
+    │                                                   │ ~5–15 мин │
+    │  2. Фильтр распознаёт протокол (DPI)             │            │
+    │  3. Лог отправляется на SPFS                     │            │
+    │  4. SPFS передаёт в ЦСУ (gRPC)                   │            │
+    │  5. ЦСУ анализирует и формирует список           │            │
+    │  6. Список загружается на фильтры (HTTP)         │            │
+    │     и Eco Highway (BGP)                          │            │
+    │  7. Блокировка активируется                     ─┘            │
+    └────────────────────────────────────────────────────────────────┘
+```
+
+Эти данные получены в ходе тестирования эшелонированной системы в тестовой зоне в Сургуте. Время полного цикла **зависит от настроек**:
+
+- **Периодичность анализа на ЦСУ** — чем чаще запускается анализ базы данных (например, раз в минуту вместо раз в 5 минут), тем быстрее формируются списки, но тем выше нагрузка на серверы;
+- **Настройки SPFS** — параметры накопления и предварительной обработки логов;
+- **Количество сессий по данному протоколу** — при большом количестве сессий (много абонентов используют блокируемый протокол) блокировка срабатывает быстрее, так как данных для анализа больше.
+
+**Важно:** до момента обновления списка фильтр **не обрывает** существующие сессии блокируемого протокола. Например, если появилась новая Telegram-прокси, которая ранее нигде не была зафиксирована, абонент может свободно работать через неё до тех пор, пока фильтр не получит обновлённый список, содержащий адрес этой прокси.
+
+Поскольку проект подобного масштаба реализуется впервые, текущие параметры основаны на эмпирических данных из тестовых сегментов. Не исключена корректировка параметров в ту или иную сторону по мере накопления опыта эксплуатации. Если серверы будут перегружаться, можно снизить частоту анализа — это увеличит время блокировки, но позволит существующим серверам справляться с нагрузкой.

 ---

-[← Оглавление](../README.md) · [← Раздел 22: Балансировщик: мониторинг и диагностика](22.md) · [Раздел 24: Траблшутинг →](24.md)
+[← Оглавление](../README.md) · [← Раздел 21: Центральная система управления](central-management.md) · [Раздел 23: Траблшутинг →](troubleshooting.md)