Le protocole de contrôle de transmission (TCP), standardisé dans la RFC 793, requiert l'établissement d'une négociation à trois voies (three-way handshake) avec maintien d'état avant tout échange applicatif. Lorsqu'un client sollicite une connexion, il émet un segment de synchronisation (SYN). Le serveur accuse réception en renvoyant un segment de synchronisation et de confirmation (SYN-ACK), tout en allouant de la mémoire noyau pour stocker un bloc de contrôle de transmission (Transmission Control Block — TCB). La connexion reste dans l'état intermédiaire SYN-RECEIVED jusqu'à la réception de l'acquittement final (ACK).

Cette allocation préalable de mémoire expose les systèmes à une vulnérabilité asymétrique majeure : l'attaque par inondation TCP SYN Flood. En saturant un serveur de paquets SYN forgés avec des adresses IP usurpées sans jamais renvoyer le segment ACK conclusif, un assaillant peut épuiser la file d'attente du système hôte et rendre les services inaccessibles aux utilisateurs légitimes.

Pour contrecarrer ces attaques par saturation, l'infrastructure moderne privilégie les mécanismes sans état (stateless). Tandis que le Web recourt aux SYN Cookies de la RFC 4987 au niveau de la couche transport L4, les architectures VPN contemporaines comme WireGuard s'appuient sur un double code d'authentification de message (mac1 et mac2) pour neutraliser les dénis de service (DoS).

Fonctionnement du TCP SYN Flood et saturation de file d'attente

Dès qu'un paquet SYN parvient sur un port en écoute, le noyau place la requête dans une structure temporaire dénommée file d'attente des demi-connexions (SYN backlog).

Client (Attaquant)                  Serveur (Cible)
       |                                   |
       |------- SYN (IP usurpée A) ------->| Allocation TCB dans le backlog
       |------- SYN (IP usurpée B) ------->| Allocation TCB dans le backlog
       |------- SYN (IP usurpée C) ------->| Allocation TCB dans le backlog
       |                                   | (Surcharge de la file SYN !)
       |                                   | Rejet des nouveaux paquets SYN
       |                                   | Clients légitimes bloqués

En situation standard, ces entrées semi-ouvertes restent mémorisées quelques secondes en attente du segment final. Lors d'une inondation SYN Flood :

  1. Usurpation d'adresses IP (Spoofing) : L'assaillant émet des rafales de trames TCP SYN comportant des adresses IPv4/IPv6 aléatoires ou inexistantes.
  2. Épuisement des ressources : Comme les hôtes usurpés ne reçoivent jamais les segments SYN-ACK, aucun accusé de réception n'est émis en retour. Le serveur conserve des milliers de blocs TCB orphelins en mémoire noyau, mobilisant descripteurs de sockets et mémoire vive.
  3. Saturation du backlog : Dès que la capacité limite est atteinte (fixée par le paramètre applicatif listen(backlog) et les variables sysctl), le système d'exploitation rejette systématiquement les requêtes entrantes, privant les utilisateurs légitimes de tout accès.
Phase de négociation TCP Connexion nominale Scénario d'attaque SYN Flood
Segment SYN initial Envoi du numéro de séquence de base Rafales massives avec IP usurpées
Réponse du serveur Allocation mémoire TCB et envoi SYN-ACK Ressources mobilisées pour des hôtes fictifs
Segment ACK final Le client clôture la négociation à trois voies Aucun retour ; expiration du délai d'attente
Impact sur le noyau Passage sans encombre à l'état ESTABLISHED File d'attente pleine ; rejet des demandes

Les SYN Cookies RFC 4987 : la négociation mathématique sans état

Normalisé par la RFC 4987, le procédé des SYN Cookies transforme la négociation TCP en un mécanisme entièrement dénué d'état dès que le serveur fait face à une surcharge.

Au lieu de créer une structure TCB en mémoire dès l'arrivée du segment SYN, le serveur calcule un numéro de séquence initial (ISN) cryptographique et le transmet au sein du segment SYN-ACK. Le serveur détruit immédiatement le contexte local de la connexion.

La valeur binaire de 32 bits du SYN Cookie intègre l'ensemble des paramètres requis :

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Temps (5 bits)| MSS (3 bits) |          Hachage cryptographique (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Sa structure repose sur :

  • Un compteur temporel (5 bits) : Valeur incrémentée à intervalles réguliers (toutes les 64 secondes) pour éviter le rejeu d'anciens cookies.
  • Un index MSS (3 bits) : Représente l'une des 8 valeurs prédéfinies de taille maximale de segment (Maximum Segment Size), préservant la négociation de MTU sans mobiliser d'espace mémoire.
  • Un hachage secret (24 bits) : Condensat calculé à partir des adresses IP source et destination, des ports de communication, du compteur temporel et d'une clé secrète connue uniquement du noyau.

Lorsqu'un client légitime retourne son segment ACK, son champ d'acquittement correspond à la valeur du cookie plus un (cookie + 1). Le serveur soustrait un, extrait le timestamp et l'index MSS, puis recalcule le hachage avec sa clé secrète. Si les valeurs coïncident, le noyau valide l'existence réelle du client. C'est uniquement à cet instant que le serveur alloue les structures mémoire nécessaires à la session.

Si les SYN Cookies répondent aux exigences des flux TCP, les réseaux privés virtuels s'appuient principalement sur UDP au niveau de la couche réseau L3. Les tunnels chiffrés ne disposent pas de numérotation séquentielle TCP. En outre, les passerelles VPN subissent une double contrainte en cas de DoS : la saturation de mémoire et l'épuisement du CPU provoqué par les opérations de cryptographie asymétrique (comme l'échange de clés Curve25519 Diffie-Hellman).

Pour surmonter cette contrainte, WireGuard introduit un modèle d'authentification de message à deux niveaux.

Le défi de la dissymétrie de charge CPU

Lorsqu'un terminal s'adresse à une passerelle WireGuard, il transmet un paquet d'initialisation (Handshake Initiation). En fonctionnement normal, la passerelle valide le message et réalise un échange de clés Curve25519 pour dériver les clés de chiffrement de session.

Or, exécuter un calcul sur courbe elliptique Curve25519 nécessite infiniment plus de cycles processeur que l'émission d'un simple paquet UDP. Un réseau de botnets usurpant des adresses IP pourrait inonder une passerelle de faux paquets d'initialisation, immobilisant 100 % du CPU et coupant l'accès aux utilisateurs authentiques.

Architecture d'authentification MAC à deux niveaux

Chaque trame de négociation WireGuard comprend deux champs de code d'authentification de 16 octets :

+---------------------------------------------------------------+
|                    Corps du message d'initialisation          |
+---------------------------------------------------------------+
|                       Champ mac1 (16 octets)                  |
+---------------------------------------------------------------+
|                       Champ mac2 (16 octets)                  |
+---------------------------------------------------------------+
  1. Le champ mac1 (Intégrité et association) : Un condensat calculé avec la clé publique du destinataire. Si ce champ est erroné ou manquant, le paquet est immédiatement jeté sans aucun traitement cryptographique coûteux.
  2. Le champ mac2 (Preuve de joignabilité de l'expéditeur) : En temps normal, ce champ reste initialisé à zéro. Lorsque la fréquence des requêtes dépasse un seuil de sécurité (en phase d'attaque DoS), le serveur déclenche le mécanisme de défense par cookie.

En état de surcharge, la passerelle suspend les calculs Curve25519 et répond par un message léger Cookie Reply :

  1. Génération du Cookie : Le serveur émet un jeton chiffré via ChaCha20-Poly1305, combinant l'adresse IP et le port du client avec une clé secrète renouvelée toutes les 2 minutes.
  2. Transmission de la réponse : Le cookie est réexpédié vers l'adresse source. Si l'IP a été usurpée, le paquet parvient à une machine indifférente ou disparaît sur le réseau ; l'attaquant ne peut pas intercepter le jeton.
  3. Réémission avec mac2 : Le client légitime reçoit le cookie, l'enregistre dans son cache et renvoie son paquet d'initialisation en renseignant le champ mac2 dérivé de ce cookie.
  4. Validation instantanée : La passerelle contrôle la valeur de mac2 à l'aide d'un hachage symétrique hautement performant. Cette vérification permet de rejeter des millions de faux paquets par seconde sans surcharger le processeur.

Tout au long de cette procédure, la passerelle WireGuard ne crée aucune session en mémoire et demeure totalement sans état.

Durcissement du noyau Linux : paramétrage de Sysctl et des files d'attente

Les administrateurs d'infrastructures peuvent optimiser le comportement du noyau face aux vagues de trafic indésirable :

Activation et réglage des SYN Cookies

Vérifiez l'état d'activation sur votre serveur :

# Vérification de l'activation des SYN Cookies (1 = activé)
sysctl net.ipv4.tcp_syncookies

Ajoutez les directives d'optimisation dans /etc/sysctl.d/99-network-dos-protection.conf :

# Activer la protection par SYN Cookies
net.ipv4.tcp_syncookies = 1

# Augmenter la taille de la file des demi-connexions
net.ipv4.tcp_max_syn_backlog = 8192

# Élever le seuil d'écoute globale des sockets
net.core.somaxconn = 8192

# Réduire les relances SYN-ACK pour libérer rapidement les sockets
net.ipv4.tcp_synack_retries = 2

# Augmenter la capacité de réception des interfaces réseau par cœur CPU
net.core.netdev_max_backlog = 16384

Chargez les paramètres immédiatement :

sudo sysctl --system

Surveillance des connexions et des rejets de paquets

Supervisez l'état des sockets et identifiez les alertes de saturation :

# Synthèse des sockets TCP
ss -s

# Décompte des connexions rejetées pour cause de file saturée
netstat -s | grep -i "listen"

Stratégie de défense distribuée au sein de VPNRice

Faire face aux menaces DoS massives exige une coordination à chaque couche du réseau :

  1. Passerelles RiceGuard sans état : Grâce aux vérifications sans état mac1 et mac2, les serveurs d'entrée VPNRice absorbent des volumes colossaux de faux paquets d'initialisation sans dégradation matérielle.
  2. Nettoyage matériel eBPF/XDP : En périphérie de réseau, nos infrastructures appliquent des filtres eBPF directement au niveau des pilotes de cartes réseau, éliminant les flux illégitimes avant leur transmission au noyau.
  3. Isolation des flux clients : En acheminant le trafic dans des tunnels chiffrés de couche 3, nos utilisateurs restent immunisés contre les saturations TCP locales et les attaques par usurpation d'adresses.

L'alliance de protocoles sans état et d'une architecture compartimentée assure à VPNRice une disponibilité continue et une faible latence, même en cas de turbulences majeures sur le réseau mondial.