Протокол керування передачею (TCP), стандартизований у документі RFC 793, вимагає виконання триетапного узгодження зі збереженням стану (three-way handshake) перед початком обміну прикладними даними. Коли клієнт ініціює з'єднання, він надсилає синхронізаційний сегмент (SYN). Сервер відповідає сегментом підтвердження (SYN-ACK), одночасно виділяючи пам'ять ядра для блоку керування передачею (Transmission Control Block — TCB). З'єднання перебуває в проміжному стані очікування (SYN-RECEIVED), доки клієнт не надішле остаточне підтвердження (ACK).

Така архітектура попереднього виділення пам'яті створює вразливість для атак типу TCP SYN Flood. Надсилаючи шквал запитів SYN із підробленими IP-адресами та навмисно ігноруючи фінальний етап надсилання ACK, нападник переповнює системну чергу з'єднань, унеможливлюючи доступ для реальних користувачів.

Захист від виснаження системних ресурсів вимагає усунення передчасного збереження стану. Якщо у вебмережах на транспортному рівні L4 це завдання вирішує механізм SYN Cookies згідно з RFC 4987, то сучасні протоколи віртуальних приватних мереж (зокрема WireGuard) використовують двошарову автентифікацію повідомлень (mac1 та mac2), запобігаючи перевантаженню процесора та пам'яті під час DoS-атак.

Механізм атаки TCP SYN Flood та переповнення черги

Коли мережевий стек ядра операційної системи отримує вхідний пакет SYN на порту прослуховування, запит поміщається в чергу напіввідкритих з'єднань (SYN backlog).

Клієнт (Нападник)                   Сервер (Жертва)
       |                                   |
       |------- SYN (Підроблена IP A) ---->| Виділення пам'яті TCB у черзі
       |------- SYN (Підроблена IP B) ---->| Виділення пам'яті TCB у черзі
       |------- SYN (Підроблена IP C) ---->| Виділення пам'яті TCB у черзі
       |                                   | (Переповнення черги SYN!)
       |                                   | Скидання нових запитів SYN
       |                                   | Доступ для клієнтів заблоковано

У нормальних умовах напіввідкритий запис утримується в оперативній пам'яті лише кілька секунд в очікуванні відповіді. Під час атаки SYN Flood:

  1. Підробка IP-адрес (IP Spoofing): Нападник генерує безперервний потік пакетів TCP SYN із випадковими або недосяжними адресами джерела.
  2. Виснаження пам'яті: Оскільки фіктивні вузли не отримують пакетів SYN-ACK, підтвердження ACK ніколи не надходить. Сервер утримує в пам'яті тисячі незавершених блоків TCB, вичерпуючи дескриптори сокетів та оперативну пам'ять.
  3. Переповнення системної черги: Коли ліміт черги вичерпується (згідно з параметром додатка listen(backlog) та налаштуваннями sysctl), ядро відкидає всі нові запити, позбавляючи обслуговування реальних клієнтів.
Етап узгодження TCP Звичайне з'єднання Сценарій атаки SYN Flood
Початковий пакет SYN Клієнт передає початковий номер черги Масивний потік пакетів із підробленими IP
Відповідь сервера Виділення пам'яті TCB та надсилання SYN-ACK Ресурси витрачаються на неіснуючі хости
Фінальний пакет ACK Клієнт завершує тристоронній процес Відповідь відсутня; очікування тайм-ауту
Стан мережевого ядра Перехід у робочий стан ESTABLISHED Черга переповнена; запити відхиляються

Алгоритм RFC 4987 SYN Cookies: математичне узгодження без збереження стану

Описана в RFC 4987 технологія SYN Cookies переводить процедуру ініціалізації TCP у режим без збереження стану в моменти екстремального мережевого навантаження.

Замість розміщення структури TCB у пам'яті під час отримання SYN, сервер генерує криптографічно синтезований початковий порядковий номер (Initial Sequence Number — ISN) та повертає його у відповіді SYN-ACK. Сервер відразу видаляє інформацію про з'єднання з пам'яті.

Бінарний формат 32-бітного номера SYN Cookie кодує критичні параметри підключення:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Час (5 бітів) | MSS (3 біти) |     Криптографічний хеш (24 біти)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Його структура містить:

  • Лічильник часу (5 бітів): Значення, що циклічно оновлюється (кожні 64 секунди) для захисту від повторного надсилання застарілих номерів.
  • Індекс MSS (3 біти): Визначає один із 8 стандартних розмірів максимального сегмента (MSS), зберігаючи узгодження без фіксації стану.
  • Секретний криптографічний хеш (24 біти): Обчислюється на основі IP-адрес джерела та призначення, номерів портів, лічильника часу та закритого ключа сервера.

Коли легітимний клієнт надсилає завершальний ACK, поле підтвердження дорівнює значенню cookie плюс одиниця (cookie + 1). Сервер віднімає одиницю, вилучає параметри MSS і таймстампи, після чого повторно розраховує хеш за допомогою локального ключа. У разі збігу ядро підтверджує автентичність клієнта й лише в цей момент виділяє системну пам'ять для встановлення з'єднання.

Алгоритм WireGuard MAC2: захист VPN від DoS на рівні L3

Якщо для TCP-з'єднань базовим захистом є SYN Cookies, то віртуальні приватні мережі функціонують переважно поверх UDP на третьому мережевому рівні L3. Тунелі не можуть спиратися на послідовні номери TCP. Крім того, шлюзи VPN наражаються на небезпеку виснаження ресурсів CPU через ресурсомісткі асиметричні обчислення на еліптичних кривих Curve25519.

Для вирішення цього завдання у WireGuard інтегровано дворівневу автентифікацію повідомлень.

Небезпека асиметричного навантаження на процесор

Коли пристрій ініціює з'єднання зі шлюзом WireGuard, він надсилає пакет ініціалізації (Handshake Initiation). За нормальних умов шлюз перевіряє пакет та здійснює обчислення ключів Curve25519.

Проте операція на еліптичних кривих потребує у сотні разів більше процесорного часу, ніж звичайна обробка UDP-пакета. Мережа ботів із підробленими IP-адресами здатна повністю завантажити ядра CPU шлюзу, позбавивши доступу справжніх користувачів.

Дворівнева архітектура аутентифікації MAC

До кожного пакета узгодження WireGuard додаються два 16-байтні поля автентифікації:

+---------------------------------------------------------------+
|                    Тіло повідомлення узгодження               |
+---------------------------------------------------------------+
|                       Поле mac1 (16 байтів)                   |
+---------------------------------------------------------------+
|                       Поле mac2 (16 байтів)                   |
+---------------------------------------------------------------+
  1. Поле mac1 (Контроль цілісності): Хеш, розрахований за допомогою публічного ключа сервера. Якщо це поле некоректне, пакет відкидається негайно без використання обчислювальних ресурсів.
  2. Поле mac2 (Підтвердження зворотної доступності адреси): У штатному режимі поле містить нулі. Якщо частота запитів перевищує встановлений поріг безпеки (під час DoS-атаки), сервер переходить у режим перевірки cookie.

У разі перевантаження сервер призупиняє пряме виконання операцій Curve25519 і запускає швидкий протокол:

  1. Генерація токена Cookie: Шлюз формує зашифрований за допомогою ChaCha20-Poly1305 токен, що об'єднує IP-адресу клієнта, порт та внутрішній ключ, який оновлюється кожні 2 хвилини.
  2. Надсилання Cookie Reply: Сервер відправляє токен назад. Якщо IP-адреса була підроблена, пакет не дійде до нападника.
  3. Повторний запит із mac2: Легітимний клієнт зберігає отриманий cookie та повторно надсилає пакет ініціалізації, розраховуючи значення mac2 за допомогою цього токена.
  4. Миттєва перевірка: Сервер перевіряє mac2 за допомогою швидкої симетричної функції. Це дозволяє відсіювати мільйони підроблених запитів на секунду без навантаження на CPU.

Протягом цього процесу шлюз WireGuard не зберігає записів про незавершені спроби й залишається повністю безстанційним.

Налаштування параметрів ядра Linux для захисту від перевантажень

Системні адміністратори можуть суттєво підвищити стабільність системи шляхом оптимізації параметрів sysctl:

Активація та оптимізація SYN Cookies

Перевірте поточний стан параметра:

# Перевірка статусу SYN Cookies (1 = активовано)
sysctl net.ipv4.tcp_syncookies

Для оптимізації стійкості черг внесіть параметри до конфігураційного файлу /etc/sysctl.d/99-network-dos-protection.conf:

# Активація механізму захисту SYN Cookies
net.ipv4.tcp_syncookies = 1

# Збільшення розміру черги напіввідкритих з'єднань
net.ipv4.tcp_max_syn_backlog = 8192

# Збільшення ліміту черги для системного виклику listen
net.core.somaxconn = 8192

# Зменшення спроб повторної відправки SYN-ACK для звільнення сокетів
net.ipv4.tcp_synack_retries = 2

# Збільшення ємності вхідної черги мережевих карт на кожне ядро CPU
net.core.netdev_max_backlog = 16384

Застосування налаштувань без перезавантаження операційної системи:

sudo sysctl --system

Моніторинг активних з'єднань та відкинутих пакетів

Контролюйте стан мережевих сокетів за допомогою стандартних утиліт:

# Статистика активних сокетів TCP
ss -s

# Кількість скинутих підключень через переповнення черги
netstat -s | grep -i "listen"

Багаторівневий захист від DoS у мережі VPNRice

Захист інфраструктури від масованих атак вимагає узгоджених дій на всіх рівнях стека:

  1. Безстанційна обробка підключень RiceGuard: Реалізація перевірок mac1 та mac2 протоколу WireGuard дозволяє шлюзам VPNRice фільтрувати великі обсяги сміттєвих запитів без деградації процесора та оперативної пам'яті.
  2. Апаратна фільтрація за допомогою eBPF/XDP: На прикордонних серверах працюють правила eBPF, які перевіряють заголовки пакетів безпосередньо на рівні мережевої карти, відсікаючи шкідливий трафік до його надходження в ядро Linux.
  3. Ізоляція користувацького трафіку: Дані клієнтів передаються всередині зашифрованого тунелю L3, що запобігає маніпуляціям із чергами TCP у відкритих або ненадійних мережах.

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