{"id":20882,"date":"2026-08-22T08:31:38","date_gmt":"2026-08-22T06:31:38","guid":{"rendered":"https:\/\/webhosting.de\/tcp-syn-cookies-schutz-syn-flood-kernel\/"},"modified":"2026-08-22T08:31:38","modified_gmt":"2026-08-22T06:31:38","slug":"protection-contre-les-cookies-syn-tcp-attaque-par-inondation-syn-noyau","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/tcp-syn-cookies-schutz-syn-flood-kernel\/","title":{"rendered":"Cookies TCP SYN dans le noyau Linux : protection contre les attaques par inondation SYN"},"content":{"rendered":"<p><strong>Cookies TCP SYN<\/strong> Dans le noyau Linux, ils limitent la charge li\u00e9e \u00e0 la proc\u00e9dure de handshake en encodant cryptographiquement les informations d'\u00e9tat dans le num\u00e9ro de s\u00e9quence initial (Initial Sequence Number) et en n'\u00e9tablissant compl\u00e8tement une connexion qu'apr\u00e8s r\u00e9ception d'un ACK valide. J'\u00e9vite ainsi que les attaques SYN-Flood n'engorgent la file d'attente des connexions semi-ouvertes et ne bloquent les clients l\u00e9gitimes.<\/p>\n\n<h2>Points centraux<\/h2>\n\n<ul>\n  <li><strong>Fonctionnement<\/strong>: Cookie dans l'ISN, \u00e9tat confirm\u00e9 uniquement apr\u00e8s l'ACK<\/li>\n  <li><strong>Commande sous Linux<\/strong>: net.ipv4.tcp_syncookies avec les modes 0\/1\/2<\/li>\n  <li><strong>Avantages<\/strong>: faible consommation de m\u00e9moire lors d'une charge de travail li\u00e9e aux attaques<\/li>\n  <li><strong>Fronti\u00e8res<\/strong>: ne prot\u00e8ge pas contre les attaques visant la bande passante ou les applications<\/li>\n  <li><strong>Tuning<\/strong>: D\u00e9finir avec soin les valeurs de backlog et de retry<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-schutz-8574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comment les attaques SYN-Flood ralentissent la poign\u00e9e de main TCP<\/h2>\n\n<p>Un pirate inonde le serveur de <strong>Paquets SYN<\/strong> et ignore les r\u00e9ponses SYN\/ACK suivantes, ce qui fait que des entr\u00e9es semi-ouvertes occupent la file d'attente SYN. Je constate alors que les nouvelles requ\u00eates l\u00e9gitimes ne trouvent pas de place et que les d\u00e9lais d'attente s'accumulent. C'est pr\u00e9cis\u00e9ment l\u00e0 qu'interviennent <strong>Syncookies<\/strong> \u00c0 : Dans un premier temps, le noyau n'enregistre pas l'\u00e9tat de la connexion et transf\u00e8re les donn\u00e9es n\u00e9cessaires dans le num\u00e9ro de s\u00e9quence. Seul un ACK correct prouve l'existence d'un v\u00e9ritable correspondant, ce qui permet \u00e0 l'\u00e9tablissement de la connexion de se poursuivre normalement. LWN.net et les documents de l'universit\u00e9 technique de Munich (TUM) d\u00e9crivent ce principe comme une protection de la poign\u00e9e de main bien \u00e9tablie et efficace, sans consommation m\u00e9moire excessive. Cette architecture permet au serveur de rester r\u00e9actif m\u00eame en cas de trafic intense, car il ne cr\u00e9e les \u00e9tats co\u00fbteux qu'\u00e0 un stade tr\u00e8s tardif.<\/p>\n\n<h2>Fonctionnement technique : un cookie remplace l'ancien syst\u00e8me d'\u00e9tat<\/h2>\n\n<p>Le noyau r\u00e9pond \u00e0 un <strong>SYN<\/strong> avec un SYN\/ACK sp\u00e9cialement cod\u00e9, dont l'ISN est d\u00e9riv\u00e9 d'une cl\u00e9 secr\u00e8te, d'options TCP et de tranches de temps. Si un ACK portant le num\u00e9ro correspondant arrive, je reconstitue les param\u00e8tres de session \u00e0 partir de l'ISN et j'ouvre le socket normalement. En l'absence de r\u00e9ponse, il n\u2019y a pas non plus d\u2019\u00e9tat semi-ouvert occup\u00e9, ce qui permet d\u2019\u00e9conomiser de la m\u00e9moire et de r\u00e9duire la charge du processeur. Cette approche r\u00e9duit consid\u00e9rablement la vuln\u00e9rabilit\u00e9 de la phase d\u2019acceptation sans modifier de mani\u00e8re permanente le chemin normal. Selon la documentation d\u2019Ubuntu et de Red Hat, cette technique fonctionne de mani\u00e8re fiable depuis de nombreuses g\u00e9n\u00e9rations de noyaux et n\u2019intervient que lorsque la file d\u2019attente menace de d\u00e9border.<\/p>\n\n<h2>Activation et v\u00e9rification : tcp_syncookies en pratique<\/h2>\n\n<p>\u00c0 propos du commutateur sysctl <strong>net.ipv4.tcp_syncookies<\/strong> Je contr\u00f4le le comportement : 0 = d\u00e9sactiv\u00e9, 1 = uniquement en cas de surcharge, 2 = en permanence. Dans les environnements de production, je r\u00e8gle g\u00e9n\u00e9ralement le mode 1 afin que la poign\u00e9e de main standard reste intacte et que la protection ne s'active qu'en cas de besoin. Je peux rapidement consulter l\u2019\u00e9tat depuis le shell ; j\u2019applique les modifications via sysctl ou de mani\u00e8re permanente dans \/etc\/sysctl.d\/. Un article de fond sur le comportement des sockets et les sch\u00e9mas d\u2019attaque aide \u00e0 planifier l\u2019ensemble ; j\u2019approfondis les d\u00e9tails dans l\u2019article <a href=\"https:\/\/webhosting.de\/fr\/syn-protection-contre-les-inondations-socket-handling-server-defense\/\">Protection SYN-Flood<\/a>. J'utilise r\u00e9guli\u00e8rement les commandes suivantes :<\/p>\n\n<pre><code>Afficher l'\u00e9tat de #\nsysctl net.ipv4.tcp_syncookies\n\nActiver temporairement # (jusqu'au red\u00e9marrage)\nsudo sysctl -w net.ipv4.tcp_syncookies=1\n\nConfigurer # de mani\u00e8re permanente\necho \"net.ipv4.tcp_syncookies = 1\" | sudo tee \/etc\/sysctl.d\/60-syncookies.conf\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>Limites : ce que les cookies SYN ne permettent pas de faire<\/h2>\n\n<p>Les cookies SYN s'adressent principalement aux <strong>Syn-Queue<\/strong> et emp\u00eachent les \u00e9tats semi-ouverts de monopoliser la m\u00e9moire. Ils ne permettent toutefois pas de contrer une ligne surcharg\u00e9e, une logique d'application satur\u00e9e ou une saturation du processeur. En cas d'attaques volum\u00e9triques, j'ai besoin de filtres en amont, de la qualit\u00e9 de service (QoS) et, le cas \u00e9ch\u00e9ant, d'un syst\u00e8me de \u00ab scrubbing \u00bb. Les attaques au niveau de l\u2019application, telles que les inondations de requ\u00eates HTTP GET, n\u00e9cessitent \u00e9galement des contr\u00f4les, des limites et des caches suppl\u00e9mentaires. J\u2019int\u00e8gre donc toujours les syncookies dans une d\u00e9fense \u00e0 plusieurs niveaux qui combine le r\u00e9seau, le noyau et le niveau des services.<\/p>\n\n<h2>Optimisation : retards, files d'attente et nouvelles tentatives<\/h2>\n\n<p>Avant qu'un incident ne survienne, je... <strong>retards<\/strong> et les tentatives de r\u00e9essai, afin que les pics de trafic l\u00e9gitimes ne d\u00e9clenchent pas inutilement le mode de protection. tcp_max_syn_backlog influe sur la file d\u2019attente des connexions semi-ouvertes, tandis que somaxconn d\u00e9termine la longueur maximale de la file d\u2019attente d\u2019acceptation pour les connexions en attente d\u2019acceptation (accept()). Avec tcp_synack_retries, je d\u00e9termine combien de fois le noyau tente de r\u00e9it\u00e9rer une r\u00e9ponse SYN\/ACK avant d\u2019abandonner. Des files d'attente plus importantes absorbent les pics de charge de courte dur\u00e9e, mais consomment de la m\u00e9moire ; un nombre r\u00e9duit de tentatives lib\u00e8re plus rapidement des emplacements, mais comporte le risque de p\u00e9naliser trop s\u00e9v\u00e8rement les clients d\u00e9connect\u00e9s. Je teste ces compromis sous une charge r\u00e9aliste \u00e0 l'aide d'outils tels que hping3 ou tcp_syn_flooder dans un r\u00e9seau isol\u00e9.<\/p>\n\n<pre><code># : candidats pour les pics de charge\nsudo sysctl -w net.core.somaxconn=4096\nsudo sysctl -w net.ipv4.tcp_max_syn_backlog=8192\nsudo sysctl -w net.ipv4.tcp_synack_retries=3\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcpsyncookies_7432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparaison des modes de fonctionnement : cons\u00e9quences et utilisation<\/h2>\n\n<p>Pour le quotidien, je choisis la <strong>Modes<\/strong> Il faut en \u00eatre conscient, car ils influencent le diagnostic, les m\u00e9triques et le comportement en situation de pression. Les cookies persistants (2) \u00e9vitent toute gestion pr\u00e9coce de l'\u00e9tat, mais modifient les valeurs mesur\u00e9es 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\u00e9bordement. Le mode d\u00e9sactiv\u00e9 (0) n'est pertinent que dans des situations de laboratoire ou sur des r\u00e9seaux ferm\u00e9s. Le tableau suivant r\u00e9sume cela de mani\u00e8re concise :<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Mode<\/th>\n      <th>Description<\/th>\n      <th>Avantage<\/th>\n      <th>Effet ind\u00e9sirable potentiel<\/th>\n      <th>Exemple<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>0<\/td>\n      <td><strong>D\u00e9sactiv\u00e9<\/strong>, pas de cookies<\/td>\n      <td>Comportement de r\u00e9f\u00e9rence clair<\/td>\n      <td>L'attaquant remplit la file d'attente Syn<\/td>\n      <td>R\u00e9seau de test isol\u00e9<\/td>\n    <\/tr>\n    <tr>\n      <td>1<\/td>\n      <td><strong>Adaptatif<\/strong>, uniquement en cas de d\u00e9bordement<\/td>\n      <td>TCP normal en mode veille<\/td>\n      <td>Calibrer le point de commutation<\/td>\n      <td>Services publics<\/td>\n    <\/tr>\n    <tr>\n      <td>2<\/td>\n      <td><strong>Forc\u00e9<\/strong>, toujours actif<\/td>\n      <td>Sortie pr\u00e9coce<\/td>\n      <td>Les valeurs d'analyse varient<\/td>\n      <td>Situation d'attaque difficile<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Effets mesurables : latences et taux de r\u00e9ussite<\/h2>\n\n<p>Sous l'effet de la pression, le <strong>Besoin de m\u00e9moire<\/strong> \u00e0 chaque \u00e9tablissement de connexion, car aucun \u00e9tat semi-ouvert ne se produit. Ainsi, les cookies SYN maintiennent un taux d'acceptation \u00e9lev\u00e9, et les courtes rafales provoquent moins d'interruptions. J'observe une reprise plus rapide en cas de trafic intense d\u00e8s que la source se tarit. Les directives d\u2019Ubuntu et de Tenable recommandent une utilisation adaptative afin que les clients normaux continuent de fonctionner sans changement. Pour les tests de r\u00e9gression, je v\u00e9rifie les retransmissions, les taux de perte et la latence du serveur lors du passage en mode cookie.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-syn-cookies-lnx-protection-4281.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Couches de protection suppl\u00e9mentaires : pare-feu et limites<\/h2>\n\n<p>Je supprime les \u00ab syncookies \u00bb avec <strong>R\u00e8gles de filtrage<\/strong> et des limites de d\u00e9bit, afin que la charge n'atteigne m\u00eame pas la pile TCP. Sous Linux, je privil\u00e9gie les r\u00e8gles nftables pour limiter ou rejeter d\u00e8s le d\u00e9part les utilisateurs malveillants en fonction de leur d\u00e9bit de connexion. Le guide propose un aper\u00e7u concis des filtres de paquets modernes <a href=\"https:\/\/webhosting.de\/fr\/netfilter-vs-nftables-technologies-modernes-de-pare-feu-sous-linux-shield\/\">nftables vs. Netfilter<\/a>. En compl\u00e9ment, les sc\u00e9narios SYNPROXY mis en place sur les pare-feu p\u00e9riph\u00e9riques permettent d'interrompre la phase de n\u00e9gociation et de ne laisser passer que les connexions valides. Pour les ports expos\u00e9s, je d\u00e9finis des r\u00e8gles d'ouverture strictes, des seuils de journalisation et un nombre maximal de tentatives de connexion par adresse source.<\/p>\n\n<h2>Approches hautes performances : XDP et autres.<\/h2>\n\n<p>Lorsque les attaques par volume <strong>Taux PPS<\/strong> Pour optimiser les performances, je d\u00e9place la logique de filtrage vers la p\u00e9riph\u00e9rie du r\u00e9seau via XDP. Je rejette ainsi les paquets SYN suspects avant m\u00eame la couche socket, ce qui r\u00e9duit la charge du processeur et all\u00e8ge la file d'attente de r\u00e9ception. Une introduction \u00e0 cette technique facilite la prise en main de <a href=\"https:\/\/webhosting.de\/fr\/xdp-traitement-de-paquets-haute-performance-vitesse-du-noyau\/\">Traitement des paquets XDP<\/a>. Associ\u00e9 aux cookies SYN, cela donne lieu \u00e0 un syst\u00e8me en deux \u00e9tapes : d'abord une s\u00e9lection approximative au niveau de la carte, puis une v\u00e9rification fiable de la poign\u00e9e de main au niveau du noyau. Cette cha\u00eene r\u00e9duit sensiblement la surface d'attaque et garantit l'accessibilit\u00e9 des services.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tech_office_tcp_syn_cookies_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagnostic : bien interpr\u00e9ter les indicateurs et les messages de journal<\/h2>\n\n<p>En cas de <strong>Timeouts<\/strong> Je v\u00e9rifie les statistiques netstat\/ss, les messages dmesg et les tableaux Grafana indiquant les d\u00e9bits de connexion. Une proportion croissante de SYN-RECV, un nombre \u00e9lev\u00e9 de retransmissions et de paquets perdus indiquent le passage en mode de protection. Je surveille les messages de d\u00e9bordement de la file d'attente SYN et je les mets en corr\u00e9lation avec la charge du processeur et des IRQ. Les captures de paquets avec tcpdump confirment la logique des num\u00e9ros de s\u00e9quence et aident \u00e0 d\u00e9tecter les faux positifs. \u00c0 l\u2019aide des compteurs iptables\/nftables, je mesure \u00e9galement le nombre de d\u00e9clenchements des r\u00e8gles de limitation de d\u00e9bit.<\/p>\n\n<h2>Compatibilit\u00e9 : options TCP et cas limites<\/h2>\n\n<p>Programmer des noyaux modernes <strong>Options<\/strong> tels que MSS, SACK ou Timestamp, de mani\u00e8re \u00e0 ce que les cookies puissent \u00eatre transport\u00e9s de fa\u00e7on \u00e0 permettre leur reconstruction. Les piles plus anciennes ou peu courantes peuvent pr\u00e9senter des particularit\u00e9s ; c'est pourquoi je v\u00e9rifie les chemins critiques avant le d\u00e9ploiement. J'observe particuli\u00e8rement attentivement le comportement, notamment avec les proxys, le NAT et les topologies Anycast. LWN.net aborde des d\u00e9tails de conception qui expliquent pourquoi les impl\u00e9mentations actuelles fonctionnent de mani\u00e8re fiable. Dans des sc\u00e9narios tr\u00e8s sp\u00e9cifiques, le mode de fonctionnement forc\u00e9 (2) reste un outil que je n'utilise qu'\u00e0 bon escient.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/developer_desk_tcp_syn_8793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Id\u00e9es re\u00e7ues courantes : ce que je corrige souvent<\/h2>\n\n<p>Les \u00ab syncookies \u00bb ne remplacent pas <strong>D\u00e9fense contre les DDoS<\/strong> en p\u00e9riph\u00e9rie, ils prot\u00e8gent surtout la phase de n\u00e9gociation. Une valeur \u00e9lev\u00e9e de somaxconn ne suffit pas \u00e0 elle seule \u00e0 emp\u00eacher les d\u00e9bordements si les paquets SYN\/ACK ne re\u00e7oivent jamais de r\u00e9ponse. De m\u00eame, 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\u00e9cessaires pour ajuster les seuils de basculement et les limites. Les tests de charge restent indispensables pour s\u2019assurer que la configuration et le mat\u00e9riel sont adapt\u00e9s \u00e0 la dynamique r\u00e9elle des acc\u00e8s.<\/p>\n\n<h2>Exemple pratique : les \u00e9tapes pour parvenir \u00e0 une hypoth\u00e8se solide<\/h2>\n\n<p>Je commence avec <strong>Mode 1<\/strong> pour tcp_syncookies et je v\u00e9rifie le point d'intervention sous charge. Ensuite, j'augmente mod\u00e9r\u00e9ment les valeurs de tcp_max_syn_backlog et somaxconn, tout en r\u00e9duisant tcp_synack_retries et en mesurant les taux de r\u00e9ussite. Les limites de d\u00e9bit du pare-feu et les filtres g\u00e9o\/ASN \u00e9liminent le bruit avant la pile. Je r\u00e9serve les filtres XDP ou SmartNIC aux situations o\u00f9 le PPS est \u00e9lev\u00e9, afin d\u2019utiliser les ressources de mani\u00e8re cibl\u00e9e. Enfin, je documente les m\u00e9triques afin que les ajustements ult\u00e9rieurs s\u2019appuient sur des donn\u00e9es concr\u00e8tes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/netzsicherheit-datenzentrum-8173.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IPv6 et double pile : m\u00eame commutateur, m\u00eame logique<\/h2>\n\n<p>Dans les environnements \u00e0 double pile, les \u00e9l\u00e9ments suivants se comportent <strong>IPv4 et IPv6<\/strong> coh\u00e9rent dans le contexte des cookies. Le bouton <em>net.ipv4.tcp_syncookies<\/em> g\u00e8re la protection de mani\u00e8re globale pour TCP, y compris pour les sockets v6. Je teste donc le passage en mode \u00ab cookie \u00bb sur les deux protocoles, en particulier lorsque les p\u00e9riph\u00e9riques en amont utilisant IPv6 recourent \u00e0 d\u2019autres chemins de filtrage. Important : les cookies SYN prot\u00e8gent exclusivement le protocole TCP. Les services UDP ou QUIC n\u00e9cessitent leurs propres limites de d\u00e9bit et une politique en p\u00e9riph\u00e9rie afin que le trafic volum\u00e9trique n\u2019\u00e9puise pas le processeur.<\/p>\n\n<h2>Les m\u00e9triques du noyau : des indicateurs fiables<\/h2>\n\n<p>Pour assurer un suivi fiable, j'utilise des compteurs du noyau qui identifient explicitement les cookies. Outre <em>ss -s<\/em> Pour surveiller les distributions d'\u00e9tats, je tiens compte du nombre de cookies envoy\u00e9s, accept\u00e9s et rejet\u00e9s. Cela me permet de d\u00e9terminer si la protection fonctionne, si les clients l\u00e9gitimes parviennent \u00e0 passer et s'il existe des erreurs de configuration.<\/p>\n\n<pre><code>Aper\u00e7u #\nss -s\nss -ant state syn-recv | wc -l\n\nCompteur de cookies # (noyau : \/proc\/net\/netstat)\ngrep -E 'Syncookies|ListenOverflows|ListenDrops' \/proc\/net\/netstat\n\n# Affichage en temps r\u00e9el\nwatch -n1 'grep -E \"Syncookies(Sent|Recv|Failed)|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n\n# Indicateurs dans les journaux (exemple de message)\n# dmesg affiche notamment :\n# TCP : Possible SYN flooding sur le port 443. Envoi de cookies. V\u00e9rifier les compteurs SNMP.\n<\/code><\/pre>\n\n<p>Monter <em>D\u00e9passements de capacit\u00e9 des listes<\/em> et <em>ListenDrops<\/em> parall\u00e8lement \u00e0 <em>SyncookiesSent<\/em> , j'ajuste les files d'attente, les tentatives de reconnexion et les filtres en amont. Il reste <em>SyncookiesRecv<\/em> si c'est le cas, cela indique un simple afflux de bots ; en revanche, si <em>SyncookiesFailed<\/em>, je v\u00e9rifie les chemins NAT\/proxy et les \u00e9ventuelles manipulations en cours de route.<\/p>\n\n<h2>Proxys, \u00e9quilibreurs de charge et Kubernetes<\/h2>\n\n<p>\u00c0 l'adresse suivante : <strong>Cha\u00eenes de proxys et d'\u00e9quilibrage de charge<\/strong> d\u00e9termine l\u2019emplacement de la protection des cookies. Si un \u00e9quilibreur de charge L4\/L7 intercepte la poign\u00e9e de main TCP, une avalanche de paquets SYN n\u2019atteint m\u00eame pas les backends ; j\u2019active alors les cookies au niveau de la p\u00e9riph\u00e9rie. Si l\u2019\u00e9quilibreur de charge fonctionne uniquement en mode passif (DSR, ECMP), les n\u0153uds backends doivent se prot\u00e9ger de mani\u00e8re autonome. Dans Kubernetes, j\u2019ajuste les param\u00e8tres sysctl sur les n\u0153uds de travail, en particulier pour les charges de travail utilisant NodePort ou HostNetwork. Pour les contr\u00f4leurs Ingress dot\u00e9s de leur propre d\u00e9fense contre les inondations SYN (SYNPROXY, eBPF), j\u2019ajuste les politiques de mani\u00e8re \u00e0 ce qu\u2019elles ne se g\u00eanent pas mutuellement. Je tiens compte des contr\u00f4les de sant\u00e9 du r\u00e9partiteur de charge dans les tests, car sinon, des fen\u00eatres de test courtes avec un faible nombre de tentatives peuvent faussement indiquer une instabilit\u00e9.<\/p>\n\n<h2>Cas limites en d\u00e9tail : options, tranches de temps, NAT<\/h2>\n\n<p>Les cookies ne font que <strong>param\u00e8tres limit\u00e9s<\/strong>. Les impl\u00e9mentations Linux modernes reconstituent g\u00e9n\u00e9ralement de mani\u00e8re fiable les protocoles MSS, SACK et Window Scaling ; les horodatages et certaines options peu courantes peuvent toutefois pr\u00e9senter des limitations selon la version du noyau. Je privil\u00e9gie donc le mode de fonctionnement (1), afin que le chemin par d\u00e9faut pr\u00e9vale et que les cookies ne s'appliquent qu'en cas de d\u00e9passement. La validit\u00e9 d\u2019un cookie est li\u00e9e \u00e0 des tranches de temps : en cas de trajets fortement asym\u00e9triques ou de pics de d\u00e9lai, un ACK l\u00e9gitime peut se situer juste en dehors de la fen\u00eatre. Dans les sc\u00e9narios WAN et par satellite, je mesure donc la variance aller-retour avant de r\u00e9duire le nombre de tentatives. Les NAT et les \u00ab middleboxes \u00bb qui modifient les num\u00e9ros de s\u00e9quence ou les options constituent d\u2019autres cas limites ; \u00e0 l\u2019aide de captures cibl\u00e9es, je localise les endroits o\u00f9 des bits sont perdus.<\/p>\n\n<h2>Inondations d'ACK\/RST et variantes au-del\u00e0 de la \u00ab temp\u00eate SYN \u00bb<\/h2>\n\n<p>Toutes les <strong>Attaque de transport<\/strong> Il s'agit d'un simple d\u00e9luge de paquets SYN. Les d\u00e9luge d'ACK ou de RST visent le processeur et les chemins de paquets sans d\u00e9clencher la phase de n\u00e9gociation \u2013 les cookies ne sont gu\u00e8re utiles dans ce cas. J\u2019utilise alors des filtres en amont (nftables\/XDP) avec une logique d\u2019\u00e9tat ou une limitation minimale du d\u00e9bit d\u2019ACK. Je mets notamment fin aux vagues de RST visant des connexions \u00e9tablies \u00e0 l\u2019aide d\u2019un ensemble de r\u00e8gles qui rejette les RST inattendus sans fen\u00eatre correspondante. Je couvre \u00e9galement les r\u00e9p\u00e9titions semi-ouvertes (SYN avec usurpation d\u2019adresse et ACK tardifs) via des limites de d\u00e9bit par espace de r\u00e9seau source.<\/p>\n\n<h2>Autres optimisations : files d'attente \u00ab Listen \u00bb et \u00ab Accept \u00bb et erreurs rapides<\/h2>\n\n<p>Outre les param\u00e8tres classiques, j'utilise des commutateurs suppl\u00e9mentaires qui influencent le comportement en situation limite :<\/p>\n\n<ul>\n  <li><strong>Backlog vs. somaxconn<\/strong>: La valeur dans <em>listes (carte)<\/em> par processus est d\u00e9termin\u00e9 par <em>net.core.somaxconn<\/em> limit\u00e9. Je veille \u00e0 ce que les logiciels serveur et le noyau fonctionnent en harmonie, sinon les optimisations ne servent \u00e0 rien.<\/li>\n  <li><strong>tcp_abort_on_overflow<\/strong>: Que la requ\u00eate soit silencieusement rejet\u00e9e lorsque la file d'attente Accept est pleine ou qu'une r\u00e9ponse RST soit activement renvoy\u00e9e. Dans les API \u00e0 fort volume, une erreur rapide peut permettre au client d'effectuer rapidement une nouvelle tentative ; pour les clients TLS ou h\u00e9rit\u00e9s, je pr\u00e9f\u00e8re g\u00e9n\u00e9ralement le rejet par d\u00e9faut.<\/li>\n  <li><strong>Gestion des ports et du mode TIME-WAIT<\/strong>: Les cookies ne permettent pas d'\u00e9viter <em>Goulot d'\u00e9tranglement du port \u00e9ph\u00e9m\u00e8re<\/em>. Je pr\u00e9vois <em>ip_local_port_range<\/em> Soyez g\u00e9n\u00e9reux et utilisez les optimisations TIME-WAIT avec prudence afin que la r\u00e9utilisation n'entra\u00eene pas de bogues.<\/li>\n  <li><strong>SO_REUSEPORT<\/strong>: La pr\u00e9sence de plusieurs files d'attente \u00ab Accept \u00bb par port permet de r\u00e9partir la charge entre les processus de travail et de r\u00e9duire les d\u00e9bordements sur les diff\u00e9rents processeurs.<\/li>\n<\/ul>\n\n<h2>M\u00e9thodes d'essai : reproductibles et fiables<\/h2>\n\n<p>Je simule des charges proches des sc\u00e9narios r\u00e9els et je mesure le point de basculement vers le mode \u00ab cookie \u00bb, le taux de r\u00e9ussite des connexions l\u00e9gitimes ainsi que le temps de r\u00e9cup\u00e9ration apr\u00e8s le pic de charge. Pour ce faire, je combine des flux SYN synth\u00e9tiques avec de v\u00e9ritables requ\u00eates d'application.<\/p>\n\n<pre><code>G\u00e9n\u00e9rer un flux # (en laboratoire !)\nsudo hping3 -S -p 443 --flood --rand-source \n\nFaire varier les conditions r\u00e9seau #\nsudo tc qdisc add dev eth0 root netem delay 80ms 30ms loss 1%\n\n# M\u00e9langer le trafic l\u00e9gitime\nwrk -t8 -c512 -d60s https:\/\/\/\n\n# Surveillance en parall\u00e8le\nwatch -n1 'ss -s; echo; grep -E \"Syncookies|Listen(Overflows|Drops)\" \/proc\/net\/netstat'\n<\/code><\/pre>\n\n<p>Ces \u00e9tapes me permettent de d\u00e9terminer si les tentatives de r\u00e9essai diminuent de mani\u00e8re 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\u00e9bordent de mani\u00e8re disproportionn\u00e9e. Je consigne les indicateurs cl\u00e9s (taux de r\u00e9ussite des connexions l\u00e9gitimes proche de 100%, taux de r\u00e9ussite des cookies, comportement de la latence) afin de pouvoir proc\u00e9der ult\u00e9rieurement \u00e0 des ajustements fond\u00e9s sur des donn\u00e9es.<\/p>\n\n<h2>Exploitation et maintenance : garantir la stabilit\u00e9 tout au long du cycle de vie<\/h2>\n\n<p>En fonctionnement continu, je pr\u00e9vois <strong>Rotation secr\u00e8te<\/strong> (automatiquement au niveau du noyau) et j'observe si les changements de tranche de temps ont des effets visibles sur les liaisons \u00e0 tr\u00e8s long RTT. Je maintiens le noyau et les pilotes \u00e0 jour afin que les am\u00e9liorations apport\u00e9es \u00e0 l'impl\u00e9mentation de Cookie (meilleur encodage des options, tranches de temps robustes) produisent leurs effets. Pour les audits, je note quand le mode de protection s\u2019est d\u00e9clench\u00e9, combien de connexions il a laiss\u00e9es passer et si des filtres suppl\u00e9mentaires ont \u00e9t\u00e9 activ\u00e9s. En cas de modifications apport\u00e9es \u00e0 la MTU, au d\u00e9chargement ou aux piles NF (par exemple, de nouveaux ensembles nftables), je r\u00e9p\u00e8te des tests rapides afin de d\u00e9tecter rapidement d\u2019\u00e9ventuelles interactions ind\u00e9sirables.<\/p>\n\n<h2>Version courte pour les personnes press\u00e9es<\/h2>\n\n<p>Les cookies SYN conservent les <strong>charge de la poign\u00e9e de main<\/strong> r\u00e9duisent les retards en ne cr\u00e9ant des \u00e9tats qu\u2019apr\u00e8s r\u00e9ception d\u2019un ACK confirm\u00e9, prot\u00e9geant ainsi la file d\u2019attente SYN contre les inondations. J\u2019active le mode 1, je r\u00e8gle avec pr\u00e9caution les backlogs et les tentatives de reconnexion, et je mesure les effets \u00e0 l\u2019aide d\u2019indicateurs clairs. Des couches suppl\u00e9mentaires telles que les limitations de d\u00e9bit nftables, SYNPROXY et XDP freinent le trafic avant m\u00eame qu\u2019il n\u2019atteigne la pile TCP. Au final, je prot\u00e8ge ainsi les services Web, de messagerie, VPN et API contre les inondations SYN, sans p\u00e9naliser les clients normaux. En mettant rigoureusement en \u0153uvre ces mesures, on renforce la disponibilit\u00e9 et on r\u00e9duit sensiblement les pannes en cas de charge d'attaques.<\/p>","protected":false},"excerpt":{"rendered":"<p>Les \u00ab TCP SYN Cookies \u00bb du noyau Linux offrent une protection fiable contre les attaques par inondation SYN. D\u00e9couvrez comment ce m\u00e9canisme fonctionne et comment le configurer.<\/p>","protected":false},"author":1,"featured_media":20875,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20882","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"101","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"TCP SYN Cookies","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20875","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20882","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20882"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20882\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20875"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20882"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20882"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20882"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}