Технологии анализа трафика DPI и оптимизация фрагментации TCP/TLS-пакетов: архитектурный разбор стека Zapret (nfqws) и ByeDPI с позиции сетевой инженерии

В современной сетевой инженерии и корпоративной кибербезопасности особое место занимает исследование того, как аппаратно-программные комплексы глубокого анализа пакетов (DPI — Deep Packet Inspection и NGFW — Next-Generation Firewalls) обрабатывают фрагментированные, сегментированные и внеочередные (Out-of-Order) пакеты стека TCP/IP. Открытые исследовательские инструменты анализа сетевого стека — такие как набор утилит Zapret (nfqws / tpws) для ядра Linux и локальный SOCKS5-манипулятор TCP-сегментов ByeDPI (ciadpi / byebyedpi) — позволяют сетевым архитекторам детально изучить различия между пассивными/инлайн-анализаторами трафика и конечной реализацией протокола TCP (RFC 9293) на целевом сервере. Разберём физику этих процессов с точки зрения сетевой инженерии и настройки корпоративных систем обнаружения вторжений (IDS/IPS/NGFW).

1. Как устроены современные комплексы анализа трафика DPI и NGFW

Чтобы понимать механику взаимодействия сетевого стека ОС с промежуточными фильтрами, необходимо разделить комплексы инспекции трафика на две архитектурные категории по способу включения в оптическую или медную магистраль:

Разбор реального интерфейса приложения ByeByeDPI (локальная сегментация пакетов)

На представленных реальных скриншотах открытого приложения ByeByeDPI (оболочка над демоном ciadpi) хорошо видна логика работы локального манипулятора TCP/TLS-сегментов без использования сторонних серверов:

• 1. Главный экран («Подключено (VPN)» — 127.0.0.1:1080): отображает статус локального перехвата трафика на петлевом интерфейсе 127.0.0.1:1080, активную строку параметров фрагментации (-d1 -d3+s -s6+s -d9+s -s12+s -d15+s -s20+s -d25+s -s30+s -t 15 -a 2 -q1 -Y -At -f-1 -r1+s -As) и четыре кнопки быстрого управления: Редактор, Настройки, Подбор и Списки.
• 2. Экран «Аргументы командной строки»: содержит тумблер «Использовать аргументы командной строки» для ручного ввода ключей демона ciadpi (смещения разрезания пакетов -s, внеочередной отправки -d, фрагментации записи TLS -r1+s, модификации TTL и флагов автодесинхронизации -At / -As), а также сохранённый «Список стратегий» с возможностью применить или отредактировать любой набор параметров в один клик.
• 3. Экран «Подбор стратегий» («Проверка завершена — 28/33»): встроенный инструмент автоматического аудита сетевого стека, который последовательно проверяет предустановленные комбинации сегментации TCP/TLS и выводит процент успешного прохождения рукопожатий (например, 90% — 29/32 с готовой кнопкой ПРИМЕНИТЬ).
• 4. Экран «Настройки → Общие»: позволяет переключать Режим работы приложения (локальный VPN через системный VpnService или чистый локальный Proxy SOCKS5 на порту 1080), задавать адрес DNS (8.8.8.8), включать поддержку IPv6 и настраивать Фильтр приложений.

2. Анализ TCP/TLS-рукопожатия: какие поля анализирует инспектор уровня L7

При установке защищённого соединения по протоколу TLS 1.3 (RFC 8446) после завершения классического трёхэтапного рукопожатия TCP (SYN → SYN-ACK → ACK) клиент отправляет первый пакет данных — TLS ClientHello (обычно размером от 517 до 1400 байт с учётом гибридных постквантовых ключей X25519MLKEM768 в браузерах 2026 года).

Внутри этого пакета в открытом (незашифрованном) виде передаются критические метаданные сессии:

• Расширение server_name (SNI — тип 0x0000): содержит доменное имя запрашиваемого узла в виде открытой ASCII-строки.
• Расширение application_layer_protocol_negotiation (ALPN — тип 0x0010): указывает список прикладных протоколов (h2, http/1.1).
• Отпечаток параметров (JA3 / JA4): последовательность номеров расширений, поддерживаемых групп эллиптических кривых и алгоритмов подписи.

Простейший потоковый парсер на стороне промежуточного узла ожидает увидеть весь блок ClientHello (или как минимум заголовок TLS Record 0x16 0x03 0x01 и расширение SNI) внутри одного первого TCP-сегмента, следующего сразу за ACK.

3. Архитектурный разбор стека Zapret (nfqws и tpws) на уровне ядра Linux

Исследовательский проект Zapret (разработанный инженером bol-van) представляет собой эталонный инструмент для тестирования того, как сетевое оборудование обрабатывает нестандартную сегментацию TCP и десинхронизацию конечных автоматов (TCP State Machine Desynchronization). В его состав входят два архитектурно разных демона:

1. tpws (Transparent Proxy Workaround) — уровень сокетов пространства пользователя

Работает как прозрачный локальный TCP-прокси (через правила перенаправления iptables REDIRECT или nftables tproxy или как локальный SOCKS5). Поскольку tpws оперирует на уровне стандартного сокетного API ОС (send() / setsockopt()), он не генерирует «сырых» (raw) пакетов и не требует прав модификации заголовков L3, а управляет отправкой данных за счёт последовательных вызовов записи в сокет малыми порциями с флагом TCP_NODELAY:

• При получении от браузера 600-байтового буфера ClientHello демон tpws делает первый вызов write(fd, buf, pos) точно до смещения поля SNI, принуждая ядро ОС немедленно отправить первый короткий TCP-сегмент, а затем вторым вызовом отправляет оставшийся хвост пакета.

2. nfqws (Netfilter Queue Workaround) — пакетный перехват в ядре Linux

Работает напрямую с подсистемой пакетного фильтра ядра Linux через очередь NFQUEUE (или на Windows через драйвер перехвата пакетов WinDivert). Перехватывая уже сформированные ядром пакеты на выходе сетевого интерфейса (хук POSTROUTING / mangle), nfqws исследует поведение сетевых анализаторов при различных режимах модификации потока:

1. Сегментация на уровне L4 (split2 / multisplit): разделение одного TCP-пакета с полезной нагрузкой на два или более валидных TCP-сегмента по заданным точкам смещения (например, на 2-м байте заголовка TLS и посередине расширения SNI). Для конечного сервера по стандарту RFC 9293 это абсолютно легитимная ситуация (например, при прохождении маршрута с меньшим MTU/MSS), и ядро сервера штатно склеивает сегменты в приёмном буфере сокета.
2. Внеочередная доставка сегментов (disorder2 / multidisorder): отправка второго TCP-сегмента (содержащего вторую половину ClientHello с более высоким номером последовательности SEQ) раньше первого сегмента. Если промежуточный анализатор трафика не хранит буфер внеочередной реассемблии (Out-of-Order Reassembly Buffer), он видит пакет из середины потока без заголовка TLS и пропускает его без анализа, тогда как целевой сервер дожидается первого сегмента и собирает поток в правильном порядке.
3. Тестирование синхронизации состояний TCP (TCP Desync): проверка того, проверяет ли промежуточный инспектор трафика контрольную сумму заголовка TCP (Checksum), время жизни пакета (IP TTL), окно временных меток (TCP Timestamp) или наличие опции криптографической подписи TCP MD5 (RFC 2385, Option 19).

# Схема работы очереди NFQUEUE в Linux при аудите сегментации пакетов:

[Приложение / Браузер]
        |
        v  (Формирует TLS 1.3 ClientHello)
[Стек TCP/IP ядра Linux]
        |
        v  (Правило nftables: tcp dport 443 ct original packets 1-6 queue num 200)
[Демон nfqws в Userspace]
        |--> Разбивает ClientHello по офсету SNI на валидные сегменты SEQ_1 и SEQ_2
        v
[Физический сетевой интерфейс NIC] --> [Тестируемый NGFW / IDS] --> [Целевой сервер]

4. Архитектурный разбор ByeDPI (ciadpi / byebyedpi): локальная сегментация без root-прав

В отличие от nfqws, требующего привилегий суперпользователя (CAP_NET_ADMIN) и доступа к очередям ядра NFQUEUE, открытый проект ByeDPI (исполняемый демон ciadpi на языке C и его оболочка ByeByeDPI для Android) реализует концепцию локального манипулятора сегментов в пространстве пользователя (Userspace SOCKS5 Proxy):

• Работа через стандартный API сокетов ОС: демон открывает локальный порт (например, 127.0.0.1:1080) и принимает соединения по протоколу SOCKS5. На мобильных устройствах Android оболочка поднимает локальный виртуальный интерфейс VpnService исключительно для того, чтобы завернуть трафик приложений в локальный процесс ciadpi на самом смартфоне (никакие внешние серверы при этом не задействуются).
• Управление буферами сокета (--split, --disorder, --oob, --tlsrec):
  • Флаг --tlsrec (TLS Record Splitting) работает даже выше уровня TCP — на уровне самого протокола TLS (L6/L7): вместо одного большого фрейма TLS Record (type 0x16) клиент формирует два последовательных абсолютно валидных по спецификации RFC 8446 фрейма TLS Record, граница между которыми проходит внутри расширения SNI. Поскольку это легитимная фрагментация записей TLS, она проходит даже через те прокси и файрволы, которые полностью собирают TCP-поток, но парсят записи TLS по одной!
  • Флаг --split управляет отправкой отдельных буферов TCP через последовательные системные вызовы send() с отключённым алгоритмом Нейгла (TCP_NODELAY).

5. Рекомендации для инженеров ИБ (Blue Team): как настроить корпоративный NGFW и IDS Suricata для корректной сборки фрагментированных потоков

С точки зрения защиты корпоративного периметра (когда перед службой ИБ стоит задача не допустить обхода корпоративных политик DLP, фильтрации фишинговых доменов или командных серверов C2 вредоносного ПО с помощью техник сегментации split / tlsrec / disorder), администраторам корпоративных межсетевых экранов NGFW и сенсоров IDS/IPS необходимо соблюдать четыре инженерных правила:

1. Обязательная потоковая реассемблия TCP (Stateful TCP Stream Reassembly): в конфигурациях корпоративных сенсоров (например, в suricata.yaml блок stream.reassembly) должна быть включена полная сборка внеочередных сегментов с достаточной глубиной буфера (depth: 1mb) до передачи потока парсеру прикладного уровня TLS.
2. Сборка фрагментированных записей TLS Record (Multi-Record ClientHello Parsing): парсер TLS на корпоративном шлюзе не должен ограничиваться анализом первой записи 0x16 0x03 0x01 — он обязан склеивать последовательные фрагменты Handshake Protocol до полного получения структуры ClientHello.
3. Нормализация трафика в режиме Inline (Traffic Scrubber / Normalizer): корпоративный межсетевой экран, стоящий в разрыв канала, должен отбрасывать пакеты с некорректными контрольными суммами TCP (checksum-validation: yes), нормализовать поле TTL (предотвращая атаки типа TTL Insertion, когда пакет доходит до сенсора IDS, но умирает за один хоп до целевого сервера) и очищать нестандартные данные срочности TCP Urgent Pointer (OOB).
4. Инспекция QUIC (UDP/443): поскольку в протоколе QUIC пакет Client Initial также может быть фрагментирован на несколько криптофреймов (CRYPTO frames) в разных номерах пакетов или снабжён начальным заполнением, корпоративный NGFW должен либо поддерживать реассемблию фреймов QUIC по RFC 9000, либо принудительно переводить трафик филиала на контролируемый стек TCP/TLS.

# Пример эталонной настройки корпоративной системы IDS/IPS Suricata 7+
# для защиты от десинхронизации TCP-стека и фрагментации TLS ClientHello:

stream:
  memcap: 512mb
  checksum-validation: yes      # Отбрасывать пакеты с невалидной контрольной суммой TCP
  inline: yes                   # Режим строгой нормализации потока в разрыв канала
  reassembly:
    memcap: 1gb
    depth: 1mb                  # Глубина буфера сборки потока
    toserver-chunk-size: 2560
    raw: yes

app-layer:
  protocols:
    tls:
      enabled: yes
      detection-ports:
        dp: 443, 8443
      ja3-fingerprints: auto
      ja4-fingerprints: auto