Протокол керування передачею (TCP), стандартизований у специфікації RFC 793 у 1981 році, залишається головним транспортним фундаментом глобальної мережі. У разі виникнення помилок сокета або аварійного завершення роботи вузла стек TCP застосовує прапорець скидання (RST) для негайного закриття з'єднання та вивільнення ресурсів операційної системи. Проте через відсутність вбудованого криптографічного підпису в заголовках TCP будь-який проміжний вузол, здатний відстежувати або підбирати параметри сесії, може надіслати підроблений пакет RST.

Цей тип втручання відомий як підробка та впровадження пакетів TCP RST (TCP RST Injection). Системи глибокого аналізу пакетів (DPI), проміжні шлюзи операторів зв'язку та зловмисники на маршруті використовують фальшиві пакети RST для примусового переривання завантажень, розриву сесій захищеної оболонки (SSH), з'єднань із базами даних та блокування веб-трафіку.

Щоб зрозуміти вразливість класичного TCP до сліпих атак у межах вікна прийому (blind in-window attacks), необхідно розглянути математику вікна TCP, захисні механізми стандарту RFC 5961 та криптографічну ізоляцію 3-го рівня.

[Стандартна обробка скидання у вікні згідно з базовим RFC 793]
Межі вікна прийому: [RCV.NXT = 10 000] <──────── 1 048 576 байтів ────────> [1 058 576]
                                                       ▲
                                   Підроблений RST: SEQ = 450 000
                                   (Схвалено! Сокет миттєво закривається)

─────────────────────────────────────────────────────────────────────────────────────────────

[Сувора верифікація скидання за стандартом RFC 5961]
Межі вікна прийому: [RCV.NXT = 10 000] <──────── 1 048 576 байтів ────────> [1 058 576]
                      ▲                                ▲
Приймається лише точний SEQ == 10 000!   RST у вікні активує Challenge ACK;
                                         З'єднання зберігається активним і стабільним.

Механізм атаки TCP RST Injection та вразливість вікна прийому

У вихідній специфікації RFC 793 вузол TCP у стані встановленого з'єднання (ESTABLISHED), отримуючи пакет із прапорцем RST, здійснює перевірку меж вікна. Сегмент вважається легітимним за умови:

$$\text{RCV.NXT} \le \text{SEG.SEQ} < \text{RCV.NXT} + \text{RCV.WND}$$

Де $\text{RCV.NXT}$ — наступний очікуваний порядковий номер, а $\text{RCV.WND}$ — оголошений розмір вікна прийому.

У ранніх мережах 1980-х років розмір вікна був незначним (переважно до 64 КБ). Проте сучасні швидкісні канали повсюдно використовують опцію масштабування вікна TCP Window Scale (RFC 7323), що розширює вікно прийому до кількох мегабайтів (зазвичай від 256 КБ до 4 МБ).

Це розширення кардинально спрощує сліпий підбір порядкових номерів:

  1. Звуження простору пошуку: У 32-бітному просторі ($2^{32} \approx 4,29 \times 10^9$ значень) відгадати точний порядковий номер майже неможливо. Проте щоб потрапити у вікно розміром 2 МБ, нападнику достатньо влучити у діапазон із $2,097,152$ послідовних чисел.
  2. Висока ймовірність влучання: Імовірність того, що випадковий пакет потрапить у валідне вікно, становить $\frac{\text{RCV.WND}}{2^{32}}$. За вікна 2 МБ відправлення кількох тисяч підроблених пакетів практично гарантовано призводить до розриву сесії.
  3. Асиметрія витрат: Нападник витрачає мінімальний трафік, надсилаючи короткі службові кадри розміром 40–54 байти, тоді як цільовий вузол миттєво звільняє системні ресурси сокета та передає додатку статус розриву зв'язку.

Якщо пристрій розташований безпосередньо на транзитному маршруті (in-path middlebox), йому взагалі не потрібно нічого вгадувати. Зчитуючи відкриті заголовки TCP та 5 параметрів IP-сесії, пристрій отримує актуальні значення $\text{SEG.SEQ}$ і надсилає пакети RST обом сторонам діалогу.

Стандарт RFC 5961 та вразливість витоку Challenge ACK

У серпні 2010 року інженерна група IETF ухвалила специфікацію RFC 5961 для захисту TCP від сліпих атак впровадження пакетів RST, SYN та фальшивих даних. Стандарт реалізував такі захисні принципи:

1. Сувора перевірка точного порядкового номера для RST

Згідно з розділом 3.2 RFC 5961, вхідний сегмент RST приймається для миттєвого закриття з'єднання виключно тоді, коли його порядковий номер абсолютно точно дорівнює очікуваному значенню:

$$\text{SEG.SEQ} == \text{RCV.NXT}$$

Якщо порядковий номер потрапляє в активне вікно, але не збігається точно ($\text{RCV.NXT} < \text{SEG.SEQ} < \text{RCV.NXT} + \text{RCV.WND}$), стек TCP не розриває з'єднання. Натомість він формує та надсилає назад перевірочний пакет Challenge ACK:

Клієнт                                                       Сервер
   |                                                            |
   | ------- Підроблений RST (У межах вікна, SEQ != RCV.NXT) -->|
   |                                                            |
   | <------ Challenge ACK (SEQ = SND.NXT, ACK = RCV.NXT) ----- |
   |                                                            |
   | (Сторонній нападник не може відповісти; потік даних триває)  |

Пакет Challenge ACK містить дійсний номер $\text{RCV.NXT}$. Якщо запит на скидання надіслав справжній партнер (наприклад, після перезавантаження сервера), той відповість валідним RST із точним номером із поля ACK. Якщо ж пакет надіслав зловмисник, справжній партнер просто проігнорує неочікуваний Challenge ACK, і передача даних триватиме безперебійно.

2. Обмеження частоти Challenge ACK та вразливість CVE-2016-5696

Відповідь на кожен підроблений пакет може спричинити атаку на відмову в обслуговуванні (DoS). Тому RFC 5961 запровадив обмеження частоти надсилання пакетів Challenge ACK.

У ядрі Linux цей механізм контролювався параметром net.ipv4.tcp_challenge_ack_limit, який спочатку встановлював ліміт у 100 або 250 пакетів на секунду для всієї системи.

У 2016 році група дослідників на чолі з Чжіюнем Цянем (Zhiyun Qian) виявила небезпечну вразливість у цьому механізмі (CVE-2016-5696). Оскільки лічильник був спільним для всіх з'єднань системи, сторонній нападник міг відкрити звичайне легітимне TCP-з'єднання з цільовим сервером. Надсилаючи тестові пакети у свій сокет і фіксуючи кількість отриманих Challenge ACK, нападник з'ясовував, чи вичерпався загальний ліміт пробним пакетом, спрямованим у сесію жертви.

Цей побічний канал дозволяв:

  • За лічені секунди визначити точний клієнтський порт.
  • Встановити діапазон порядкових номерів активного з'єднання між двома довільними хостами.
  • Здійснити впровадження шкідливих даних або розірвати сесію всупереч захисту RFC 5961.

Виправлення ядра операційної системи запровадили рандомізовані ліміти та роздільні таймери для окремих сокетів, що унеможливило успішну експлуатацію вразливості.

Виявлення впроваджених пакетів RST у мережевому трафіку

Мережеві фахівці можуть виявити атаки впровадження пакетів скидання під час аналізу дампів у tcpdump або Wireshark. Фальсифіковані пакети від проміжних пристроїв майже завжди містять характерні аномалії:

# Захоплення підозрілих пакетів RST на інтерфейсі eth0
sudo tcpdump -ni eth0 'tcp[tcpflags] & tcp-rst != 0' -vvv -c 20

Чотири діагностичні ознаки впровадження:

Атрибут заголовка Справжній віддалений сервер Впроваджений пакет від middlebox
Час життя пакета (TTL) Природне зменшення на кожному хопі (наприклад, 53) Аномальне значення (наприклад, 64 від сусіднього роутера)
Розмір вікна TCP Відповідає стану реального буфера прийому Фіксовані типові константи (0, 512 або 16384)
Опції TCP Options Наявні параметри SACK-Permitted та Timestamps Повна відсутність опцій (базовий 20-байтний заголовок)
Ідентифікатор IPID Послідовний приріст або рандомізація Дорівнює нулю або має розрив послідовності

Стрибок TTL з 52 до 62 у пакеті RST свідчить про те, що пакет був сформований транзитним маршрутизатором, а не сервером призначення.

Налаштування параметрів безпеки ядра системи

Системні адміністратори можуть перевірити та оптимізувати параметри ядра, пов'язані з RFC 5961:

# Перевірка поточного ліміту Challenge ACK у Linux
sysctl net.ipv4.tcp_challenge_ack_limit

# Підвищення ліміту та активація рандомізації
sudo sysctl -w net.ipv4.tcp_challenge_ack_limit=2000

# Перевірка активації масштабування вікон та SACK
sudo sysctl -w net.ipv4.tcp_window_scaling=1
sudo sysctl -w net.ipv4.tcp_sack=1

Утім, програмне налаштування ядра захищає лише від сліпих атак і не здатне зупинити пристрої, які безпосередньо зчитують відкриті заголовки пакетів на магістралі зв'язку.

Криптографічний захист 3-го рівня з VPNRice RiceGuard

Фундаментальна вразливість до атак впровадження полягає у відсутності криптографічної перевірки автентичності заголовків IPv4 та IPv6. Поки службові прапорці транспорту передаються у відкритому вигляді, проміжне обладнання зберігає технічну змогу маніпулювати потоком даних.

Шифрування прикладного рівня (TLS 1.3 чи SSH) захищає корисні дані користувача, але залишає зовнішні оболонки IP і TCP доступними для спостереження. Система фільтрації, розпізнавши доменне ім'я (SNI) чи адресу призначення під час рукостискання, може негайно надіслати підроблений RST і закрити транспортний сокет, навіть не маючи доступу до вмісту TLS.

[Передача без шифрування L3: загроза впровадження RST через DPI]
Заголовок IP | Заголовок TCP (Прапорець RST, SEQ) | Зашифровані дані TLS
                    ▲
                    Проміжний шлюз впроваджує RST -> З'єднання розірвано!

─────────────────────────────────────────────────────────────────────────────────────────────

[Інкапсуляція у VPNRice RiceGuard: надійний криптографічний бар'єр]
Зовнішній IP | Зовнішній UDP (WireGuard) | Код ChaCha20-Poly1305 | [Внутрішній IP | Внутрішній TCP | Дані]
                                                      ▲
                                 Усі внутрішні заголовки зашифровані та підписані!
                 Пакети без валідного коду підпису негайно відкидаються системою.

VPNRice розв'язує цю архітектурну проблему завдяки інкапсуляції всього мережевого трафіку в криптографічно захищений тунель 3-го рівня на базі технології RiceGuard:

  • Автентифіковане шифрування (AEAD): Кожен пакет, що передається тунелем, шифрується алгоритмом ChaCha20 та супроводжується 128-бітним кодом автентифікації Poly1305.
  • Приховування службових заголовків: Порядкові номери TCP, прапорці стану, розміри вікон та підтвердження надійно сховані всередині зашифрованого корисного навантаження UDP. Для сторонніх систем моніторингу трафік має вигляд суцільного ентропійного шуму.
  • Миттєве відкидання фальсифікацій: Якщо проміжне обладнання чи зловмисник намагається вставити фальшивий пакет RST у потік, він не матиме коректного коду Poly1305 і буде відкинутий підсистемою ядра на повній швидкості інтерфейсу, не діставшись внутрішнього стека TCP.
  • Захист інфраструктури DNS: Усі DNS-запити спрямовуються через виділені Anycast-сервери, що працюють виключно в оперативній пам'яті (RAM-only), унеможливлюючи витоки метаданих, які могли б спровокувати атаку.

Перенесення криптографічної перевірки автентичності на рівень мережевого інтерфейсу гарантує, що сесії TCP залишаються стабільними та повністю захищеними від несанкціонованого втручання на ненадійних ділянках зв'язку.