Протокол управления передачей (TCP), стандартизированный в документе RFC 793, использует трехстороннее рукопожатие с сохранением состояния перед передачей прикладных данных. Клиент отправляет начальный синхронизирующий сегмент (SYN). Сервер отвечает сегментом подтверждения (SYN-ACK) и выделяет память ядра для блока управления передачей (Transmission Control Block — TCB). Соединение удерживается в состоянии ожидания (SYN-RECEIVED) до прихода финального подтверждения (ACK).

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

Отражение атак на истощение ресурсов требует устранения предварительного сохранения состояния. Если в стеке TCP на транспортном уровне L4 эту задачу решают алгоритмы SYN Cookies по RFC 4987, то современные VPN-протоколы (в частности, WireGuard) применяют двухуровневые коды аутентификации сообщений (mac1 и mac2), исключая перегрузку процессора и памяти.

Принцип работы атаки TCP SYN Flood и исчерпание очереди

Когда сетевой стек ядра принимает входящий сегмент SYN на прослушиваемом порту, запрос помещается в очередь полуоткрытых соединений (SYN backlog).

Клиент (Атакующий)                  Сервер (Жертва)
       |                                   |
       |------- SYN (Поддельный IP A) ---->| Выделение TCB в очереди backlog
       |------- SYN (Поддельный IP B) ---->| Выделение TCB в очереди backlog
       |------- SYN (Поддельный IP C) ---->| Выделение TCB в очереди backlog
       |                                   | (Переполнение очереди SYN!)
       |                                   | Сброс новых запросов SYN
       |                                   | Легитимные клиенты заблокированы

В обычных условиях полуоткрытое соединение находится в памяти несколько секунд в ожидании завершающего ACK. Во время атаки SYN Flood:

  1. Спуфинг адресов (IP Spoofing): Атакующий генерирует непрерывный поток пакетов TCP SYN со случайными или недостижимыми адресами источника.
  2. Истощение системных ресурсов: Поскольку несуществующие хосты не отправляют завершающий 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 в оперативной памяти ядро формирует криптографически синтезированный начальный порядковый номер (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time (5 бит) | MSS (3 бита) |      Криптографический хэш (24) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Бинарный формат включает:

  • Счетчик времени (5 бит): Циклически обновляемое значение (каждые 64 секунды), предотвращающее повторное воспроизведение устаревших cookie.
  • Кодировщик MSS (3 бита): Индекс одного из 8 стандартных размеров максимального сегмента (MSS), позволяющий согласовать размер кадра без выделения памяти.
  • Криптографический хэш (24 бита): Свертка по IP-адресам, портам источника и назначения, временному счетчику и секретному ключу ядра.

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

Алгоритм WireGuard MAC2: бессерверная защита VPN от DoS-атак

Если для веб-трафика базовой защитой являются SYN Cookies, то виртуальные частные сети функционируют поверх UDP на сетевом уровне L3. В протоколах туннелирования невозможно опираться на порядковые номера TCP. Кроме того, серверы VPN подвержены риску исчерпания ресурсов CPU из-за ресурсоемких асимметричных вычислений на эллиптических кривых Curve25519.

Для устранения этих рисков в WireGuard встроен двухуровневый механизм кодов проверки сообщений.

Проблема асимметричной нагрузки на процессор

При отправке клиентом пакета инициализации рукопожатия (Handshake Initiation) шлюз VPN проводит операцию асимметричного обмена ключами Curve25519 Diffie-Hellman.

Вычисление ключа требует значительно больших вычислительных мощностей процессора, чем генерация исходящего UDP-кадра. Ботнет с поддельными адресами способен завалить сервер запросами, загрузив 100% мощности CPU и вызвав отказ в обслуживании для реальных пользователей.

Двухуровневая схема аутентификации MAC

К каждому пакету рукопожатия WireGuard присоединяются два поля MAC размером по 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: оптимизация очередей и SYN Cookies

Администраторам серверов рекомендуется настроить параметры ядра для повышения устойчивости к перегрузкам:

Конфигурация параметров через 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

# Количество отброшенных соединений из-за переполнения очередей listen
netstat -s | grep -i "listen"

Архитектура защиты от DoS-атак в инфраструктуре VPNRice

Защита сетевых коммуникаций требует многоуровневого подхода на всех уровнях протокольного стека:

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

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