Passer au contenu 
Cookies TCP SYN Dans le noyau Linux, ils limitent la charge liée à la procédure de handshake en encodant cryptographiquement les informations d'état dans le numéro de séquence initial (Initial Sequence Number) et en n'établissant complètement une connexion qu'après réception d'un ACK valide. J'évite ainsi que les attaques SYN-Flood n'engorgent la file d'attente des connexions semi-ouvertes et ne bloquent les clients légitimes.
Points centraux
- Fonctionnement: Cookie dans l'ISN, état confirmé uniquement après l'ACK
- Commande sous Linux: net.ipv4.tcp_syncookies avec les modes 0/1/2
- Avantages: faible consommation de mémoire lors d'une charge de travail liée aux attaques
- Frontières: ne protège pas contre les attaques visant la bande passante ou les applications
- Tuning: Définir avec soin les valeurs de backlog et de retry
Comment les attaques SYN-Flood ralentissent la poignée de main TCP
Un pirate inonde le serveur de Paquets SYN et ignore les réponses SYN/ACK suivantes, ce qui fait que des entrées semi-ouvertes occupent la file d'attente SYN. Je constate alors que les nouvelles requêtes légitimes ne trouvent pas de place et que les délais d'attente s'accumulent. C'est précisément là qu'interviennent Syncookies À : Dans un premier temps, le noyau n'enregistre pas l'état de la connexion et transfère les données nécessaires dans le numéro de séquence. Seul un ACK correct prouve l'existence d'un véritable correspondant, ce qui permet à l'établissement de la connexion de se poursuivre normalement. LWN.net et les documents de l'université technique de Munich (TUM) décrivent ce principe comme une protection de la poignée de main bien établie et efficace, sans consommation mémoire excessive. Cette architecture permet au serveur de rester réactif même en cas de trafic intense, car il ne crée les états coûteux qu'à un stade très tardif.
Fonctionnement technique : un cookie remplace l'ancien système d'état
Le noyau répond à un SYN avec un SYN/ACK spécialement codé, dont l'ISN est dérivé d'une clé secrète, d'options TCP et de tranches de temps. Si un ACK portant le numéro correspondant arrive, je reconstitue les paramètres de session à partir de l'ISN et j'ouvre le socket normalement. En l'absence de réponse, il n’y a pas non plus d’état semi-ouvert occupé, ce qui permet d’économiser de la mémoire et de réduire la charge du processeur. Cette approche réduit considérablement la vulnérabilité de la phase d’acceptation sans modifier de manière permanente le chemin normal. Selon la documentation d’Ubuntu et de Red Hat, cette technique fonctionne de manière fiable depuis de nombreuses générations de noyaux et n’intervient que lorsque la file d’attente menace de déborder.
Activation et vérification : tcp_syncookies en pratique
À propos du commutateur sysctl net.ipv4.tcp_syncookies Je contrôle le comportement : 0 = désactivé, 1 = uniquement en cas de surcharge, 2 = en permanence. Dans les environnements de production, je règle généralement le mode 1 afin que la poignée de main standard reste intacte et que la protection ne s'active qu'en cas de besoin. Je peux rapidement consulter l’état depuis le shell ; j’applique les modifications via sysctl ou de manière permanente dans /etc/sysctl.d/. Un article de fond sur le comportement des sockets et les schémas d’attaque aide à planifier l’ensemble ; j’approfondis les détails dans l’article Protection SYN-Flood. J'utilise régulièrement les commandes suivantes :
Afficher l'état de #
sysctl net.ipv4.tcp_syncookies
Activer temporairement # (jusqu'au redémarrage)
sudo sysctl -w net.ipv4.tcp_syncookies=1
Configurer # de manière permanente
echo "net.ipv4.tcp_syncookies = 1" | sudo tee /etc/sysctl.d/60-syncookies.conf
sudo sysctl --system
Limites : ce que les cookies SYN ne permettent pas de faire
Les cookies SYN s'adressent principalement aux Syn-Queue et empêchent les états semi-ouverts de monopoliser la mémoire. Ils ne permettent toutefois pas de contrer une ligne surchargée, une logique d'application saturée ou une saturation du processeur. En cas d'attaques volumétriques, j'ai besoin de filtres en amont, de la qualité de service (QoS) et, le cas échéant, d'un système de « scrubbing ». Les attaques au niveau de l’application, telles que les inondations de requêtes HTTP GET, nécessitent également des contrôles, des limites et des caches supplémentaires. J’intègre donc toujours les syncookies dans une défense à plusieurs niveaux qui combine le réseau, le noyau et le niveau des services.
Optimisation : retards, files d'attente et nouvelles tentatives
Avant qu'un incident ne survienne, je... retards et les tentatives de réessai, afin que les pics de trafic légitimes ne déclenchent pas inutilement le mode de protection. tcp_max_syn_backlog influe sur la file d’attente des connexions semi-ouvertes, tandis que somaxconn détermine la longueur maximale de la file d’attente d’acceptation pour les connexions en attente d’acceptation (accept()). Avec tcp_synack_retries, je détermine combien de fois le noyau tente de réitérer une réponse SYN/ACK avant d’abandonner. Des files d'attente plus importantes absorbent les pics de charge de courte durée, mais consomment de la mémoire ; un nombre réduit de tentatives libère plus rapidement des emplacements, mais comporte le risque de pénaliser trop sévèrement les clients déconnectés. Je teste ces compromis sous une charge réaliste à l'aide d'outils tels que hping3 ou tcp_syn_flooder dans un réseau isolé.
# : candidats pour les pics de charge
sudo sysctl -w net.core.somaxconn=4096
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sudo sysctl -w net.ipv4.tcp_synack_retries=3
Comparaison des modes de fonctionnement : conséquences et utilisation
Pour le quotidien, je choisis la Modes Il faut en être conscient, car ils influencent le diagnostic, les métriques et le comportement en situation de pression. Les cookies persistants (2) évitent toute gestion précoce de l'état, mais modifient les valeurs mesurées pour les nouvelles tentatives et peuvent influencer des cas limites rares avec les options TCP. Le mode adaptatif (1) laisse la pile fonctionner normalement et intervient en cas de risque de débordement. Le mode désactivé (0) n'est pertinent que dans des situations de laboratoire ou sur des réseaux fermés. Le tableau suivant résume cela de manière concise :
| Mode | Description | Avantage | Effet indésirable potentiel | Exemple |
|---|---|---|---|---|
| 0 | Désactivé, pas de cookies | Comportement de référence clair | L'attaquant remplit la file d'attente Syn | Réseau de test isolé |
| 1 | Adaptatif, uniquement en cas de débordement | TCP normal en mode veille | Calibrer le point de commutation | Services publics |
| 2 | Forcé, toujours actif | Sortie précoce | Les valeurs d'analyse varient | Situation d'attaque difficile |
Effets mesurables : latences et taux de réussite
Sous l'effet de la pression, le Besoin de mémoire à chaque établissement de connexion, car aucun état semi-ouvert ne se produit. Ainsi, les cookies SYN maintiennent un taux d'acceptation élevé, et les courtes rafales provoquent moins d'interruptions. J'observe une reprise plus rapide en cas de trafic intense dès que la source se tarit. Les directives d’Ubuntu et de Tenable recommandent une utilisation adaptative afin que les clients normaux continuent de fonctionner sans changement. Pour les tests de régression, je vérifie les retransmissions, les taux de perte et la latence du serveur lors du passage en mode cookie.
Couches de protection supplémentaires : pare-feu et limites
Je supprime les « syncookies » avec Règles de filtrage et des limites de débit, afin que la charge n'atteigne même pas la pile TCP. Sous Linux, je privilégie les règles nftables pour limiter ou rejeter dès le départ les utilisateurs malveillants en fonction de leur débit de connexion. Le guide propose un aperçu concis des filtres de paquets modernes nftables vs. Netfilter. En complément, les scénarios SYNPROXY mis en place sur les pare-feu périphériques permettent d'interrompre la phase de négociation et de ne laisser passer que les connexions valides. Pour les ports exposés, je définis des règles d'ouverture strictes, des seuils de journalisation et un nombre maximal de tentatives de connexion par adresse source.
Approches hautes performances : XDP et autres.
Lorsque les attaques par volume Taux PPS Pour optimiser les performances, je déplace la logique de filtrage vers la périphérie du réseau via XDP. Je rejette ainsi les paquets SYN suspects avant même la couche socket, ce qui réduit la charge du processeur et allège la file d'attente de réception. Une introduction à cette technique facilite la prise en main de Traitement des paquets XDP. Associé aux cookies SYN, cela donne lieu à un système en deux étapes : d'abord une sélection approximative au niveau de la carte, puis une vérification fiable de la poignée de main au niveau du noyau. Cette chaîne réduit sensiblement la surface d'attaque et garantit l'accessibilité des services.
Diagnostic : bien interpréter les indicateurs et les messages de journal
En cas de Timeouts Je vérifie les statistiques netstat/ss, les messages dmesg et les tableaux Grafana indiquant les débits de connexion. Une proportion croissante de SYN-RECV, un nombre élevé de retransmissions et de paquets perdus indiquent le passage en mode de protection. Je surveille les messages de débordement de la file d'attente SYN et je les mets en corrélation avec la charge du processeur et des IRQ. Les captures de paquets avec tcpdump confirment la logique des numéros de séquence et aident à détecter les faux positifs. À l’aide des compteurs iptables/nftables, je mesure également le nombre de déclenchements des règles de limitation de débit.
Compatibilité : options TCP et cas limites
Programmer des noyaux modernes Options tels que MSS, SACK ou Timestamp, de manière à ce que les cookies puissent être transportés de façon à permettre leur reconstruction. Les piles plus anciennes ou peu courantes peuvent présenter des particularités ; c'est pourquoi je vérifie les chemins critiques avant le déploiement. J'observe particulièrement attentivement le comportement, notamment avec les proxys, le NAT et les topologies Anycast. LWN.net aborde des détails de conception qui expliquent pourquoi les implémentations actuelles fonctionnent de manière fiable. Dans des scénarios très spécifiques, le mode de fonctionnement forcé (2) reste un outil que je n'utilise qu'à bon escient.
Idées reçues courantes : ce que je corrige souvent
Les « syncookies » ne remplacent pas Défense contre les DDoS en périphérie, ils protègent surtout la phase de négociation. Une valeur élevée de somaxconn ne suffit pas à elle seule à empêcher les débordements si les paquets SYN/ACK ne reçoivent jamais de réponse. De même, il est trompeur de penser que les cookies permanents (2) constituent toujours le meilleur choix ; cela nuit aux diagnostics et aux cas particuliers. Sans surveillance, je ne dispose pas des signaux nécessaires pour ajuster les seuils de basculement et les limites. Les tests de charge restent indispensables pour s’assurer que la configuration et le matériel sont adaptés à la dynamique réelle des accès.
Exemple pratique : les étapes pour parvenir à une hypothèse solide
Je commence avec Mode 1 pour tcp_syncookies et je vérifie le point d'intervention sous charge. Ensuite, j'augmente modérément les valeurs de tcp_max_syn_backlog et somaxconn, tout en réduisant tcp_synack_retries et en mesurant les taux de réussite. Les limites de débit du pare-feu et les filtres géo/ASN éliminent le bruit avant la pile. Je réserve les filtres XDP ou SmartNIC aux situations où le PPS est élevé, afin d’utiliser les ressources de manière ciblée. Enfin, je documente les métriques afin que les ajustements ultérieurs s’appuient sur des données concrètes.
IPv6 et double pile : même commutateur, même logique
Dans les environnements à double pile, les éléments suivants se comportent IPv4 et IPv6 cohérent dans le contexte des cookies. Le bouton net.ipv4.tcp_syncookies gère la protection de manière globale pour TCP, y compris pour les sockets v6. Je teste donc le passage en mode « cookie » sur les deux protocoles, en particulier lorsque les périphériques en amont utilisant IPv6 recourent à d’autres chemins de filtrage. Important : les cookies SYN protègent exclusivement le protocole TCP. Les services UDP ou QUIC nécessitent leurs propres limites de débit et une politique en périphérie afin que le trafic volumétrique n’épuise pas le processeur.
Les métriques du noyau : des indicateurs fiables
Pour assurer un suivi fiable, j'utilise des compteurs du noyau qui identifient explicitement les cookies. Outre ss -s Pour surveiller les distributions d'états, je tiens compte du nombre de cookies envoyés, acceptés et rejetés. Cela me permet de déterminer si la protection fonctionne, si les clients légitimes parviennent à passer et s'il existe des erreurs de configuration.
Aperçu #
ss -s
ss -ant state syn-recv | wc -l
Compteur de cookies # (noyau : /proc/net/netstat)
grep -E 'Syncookies|ListenOverflows|ListenDrops' /proc/net/netstat
# Affichage en temps réel
watch -n1 'grep -E "Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)" /proc/net/netstat'
# Indicateurs dans les journaux (exemple de message)
# dmesg affiche notamment :
# TCP : Possible SYN flooding sur le port 443. Envoi de cookies. Vérifier les compteurs SNMP.
Monter Dépassements de capacité des listes et ListenDrops parallèlement à SyncookiesSent , j'ajuste les files d'attente, les tentatives de reconnexion et les filtres en amont. Il reste SyncookiesRecv si c'est le cas, cela indique un simple afflux de bots ; en revanche, si SyncookiesFailed, je vérifie les chemins NAT/proxy et les éventuelles manipulations en cours de route.
Proxys, équilibreurs de charge et Kubernetes
À l'adresse suivante : Chaînes de proxys et d'équilibrage de charge détermine l’emplacement de la protection des cookies. Si un équilibreur de charge L4/L7 intercepte la poignée de main TCP, une avalanche de paquets SYN n’atteint même pas les backends ; j’active alors les cookies au niveau de la périphérie. Si l’équilibreur de charge fonctionne uniquement en mode passif (DSR, ECMP), les nœuds backends doivent se protéger de manière autonome. Dans Kubernetes, j’ajuste les paramètres sysctl sur les nœuds de travail, en particulier pour les charges de travail utilisant NodePort ou HostNetwork. Pour les contrôleurs Ingress dotés de leur propre défense contre les inondations SYN (SYNPROXY, eBPF), j’ajuste les politiques de manière à ce qu’elles ne se gênent pas mutuellement. Je tiens compte des contrôles de santé du répartiteur de charge dans les tests, car sinon, des fenêtres de test courtes avec un faible nombre de tentatives peuvent faussement indiquer une instabilité.
Cas limites en détail : options, tranches de temps, NAT
Les cookies ne font que paramètres limités. Les implémentations Linux modernes reconstituent généralement de manière fiable les protocoles MSS, SACK et Window Scaling ; les horodatages et certaines options peu courantes peuvent toutefois présenter des limitations selon la version du noyau. Je privilégie donc le mode de fonctionnement (1), afin que le chemin par défaut prévale et que les cookies ne s'appliquent qu'en cas de dépassement. La validité d’un cookie est liée à des tranches de temps : en cas de trajets fortement asymétriques ou de pics de délai, un ACK légitime peut se situer juste en dehors de la fenêtre. Dans les scénarios WAN et par satellite, je mesure donc la variance aller-retour avant de réduire le nombre de tentatives. Les NAT et les « middleboxes » qui modifient les numéros de séquence ou les options constituent d’autres cas limites ; à l’aide de captures ciblées, je localise les endroits où des bits sont perdus.
Inondations d'ACK/RST et variantes au-delà de la « tempête SYN »
Toutes les Attaque de transport Il s'agit d'un simple déluge de paquets SYN. Les déluge d'ACK ou de RST visent le processeur et les chemins de paquets sans déclencher la phase de négociation – les cookies ne sont guère utiles dans ce cas. J’utilise alors des filtres en amont (nftables/XDP) avec une logique d’état ou une limitation minimale du débit d’ACK. Je mets notamment fin aux vagues de RST visant des connexions établies à l’aide d’un ensemble de règles qui rejette les RST inattendus sans fenêtre correspondante. Je couvre également les répétitions semi-ouvertes (SYN avec usurpation d’adresse et ACK tardifs) via des limites de débit par espace de réseau source.
Autres optimisations : files d'attente « Listen » et « Accept » et erreurs rapides
Outre les paramètres classiques, j'utilise des commutateurs supplémentaires qui influencent le comportement en situation limite :
- Backlog vs. somaxconn: La valeur dans listes (carte) par processus est déterminé par net.core.somaxconn limité. Je veille à ce que les logiciels serveur et le noyau fonctionnent en harmonie, sinon les optimisations ne servent à rien.
- tcp_abort_on_overflow: Que la requête soit silencieusement rejetée lorsque la file d'attente Accept est pleine ou qu'une réponse RST soit activement renvoyée. Dans les API à fort volume, une erreur rapide peut permettre au client d'effectuer rapidement une nouvelle tentative ; pour les clients TLS ou hérités, je préfère généralement le rejet par défaut.
- Gestion des ports et du mode TIME-WAIT: Les cookies ne permettent pas d'éviter Goulot d'étranglement du port éphémère. Je prévois ip_local_port_range Soyez généreux et utilisez les optimisations TIME-WAIT avec prudence afin que la réutilisation n'entraîne pas de bogues.
- SO_REUSEPORT: La présence de plusieurs files d'attente « Accept » par port permet de répartir la charge entre les processus de travail et de réduire les débordements sur les différents processeurs.
Méthodes d'essai : reproductibles et fiables
Je simule des charges proches des scénarios réels et je mesure le point de basculement vers le mode « cookie », le taux de réussite des connexions légitimes ainsi que le temps de récupération après le pic de charge. Pour ce faire, je combine des flux SYN synthétiques avec de véritables requêtes d'application.
Générer un flux # (en laboratoire !)
sudo hping3 -S -p 443 --flood --rand-source
Faire varier les conditions réseau #
sudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%
# Mélanger le trafic légitime
wrk -t8 -c512 -d60s https:///
# Surveillance en parallèle
watch -n1 'ss -s; echo; grep -E "Syncookies|Listen(Overflows|Drops)" /proc/net/netstat'
Ces étapes me permettent de déterminer si les tentatives de réessai diminuent de manière trop agressive, si les pare-feu en amont filtrent par erreur les horodatages ou si les files d'attente d'acceptation de certains travailleurs débordent de manière disproportionnée. Je consigne les indicateurs clés (taux de réussite des connexions légitimes proche de 100%, taux de réussite des cookies, comportement de la latence) afin de pouvoir procéder ultérieurement à des ajustements fondés sur des données.
Exploitation et maintenance : garantir la stabilité tout au long du cycle de vie
En fonctionnement continu, je prévois Rotation secrète (automatiquement au niveau du noyau) et j'observe si les changements de tranche de temps ont des effets visibles sur les liaisons à très long RTT. Je maintiens le noyau et les pilotes à jour afin que les améliorations apportées à l'implémentation de Cookie (meilleur encodage des options, tranches de temps robustes) produisent leurs effets. Pour les audits, je note quand le mode de protection s’est déclenché, combien de connexions il a laissées passer et si des filtres supplémentaires ont été activés. En cas de modifications apportées à la MTU, au déchargement ou aux piles NF (par exemple, de nouveaux ensembles nftables), je répète des tests rapides afin de détecter rapidement d’éventuelles interactions indésirables.
Version courte pour les personnes pressées
Les cookies SYN conservent les charge de la poignée de main réduisent les retards en ne créant des états qu’après réception d’un ACK confirmé, protégeant ainsi la file d’attente SYN contre les inondations. J’active le mode 1, je règle avec précaution les backlogs et les tentatives de reconnexion, et je mesure les effets à l’aide d’indicateurs clairs. Des couches supplémentaires telles que les limitations de débit nftables, SYNPROXY et XDP freinent le trafic avant même qu’il n’atteigne la pile TCP. Au final, je protège ainsi les services Web, de messagerie, VPN et API contre les inondations SYN, sans pénaliser les clients normaux. En mettant rigoureusement en œuvre ces mesures, on renforce la disponibilité et on réduit sensiblement les pannes en cas de charge d'attaques.
