ACK flood : protéger les sessions TCP

Ce qu’un ACK flood cherche réellement à casser

Un ACK flood envoie un très grand nombre de paquets TCP avec le flag ACK. En TCP normal, les ACK confirment la réception de données et font partie de sessions établies. Pendant une attaque, ces paquets ne correspondent pas forcément à de vrais flux, peuvent utiliser des sources usurpées, viser des ports aléatoires ou arriver à un rythme qui force les équipements réseau à faire des vérifications coûteuses.

Le premier point de rupture n’est souvent pas l’application. Cela peut être un firewall stateful qui tente de faire correspondre chaque paquet à une table de connexions, un load balancer qui suit les sessions, un routeur qui bascule sur un chemin CPU, un équipement NAT, une file kernel ou un système de logs incapable d’absorber des millions de paquets inutiles par seconde.

C’est pour cela que les ACK floods sont piégeux : le graphe en Gbps peut sembler moins impressionnant qu’un gros UDP flood, alors que le service devient indisponible. L’attaque brûle le budget de traitement et de validation d’état avant que le client légitime n’obtienne un chemin stable.

Pression sur les tables d’état

Les équipements qui valident chaque paquet contre des sessions existantes peuvent devenir le goulot.

ACK spoofés ou aléatoires

Beaucoup de paquets ne correspondent à aucune connexion réelle mais consomment du traitement.

Bruit par port et service

Le flood peut viser des ports exposés, fermés ou plusieurs services pour augmenter le coût.

Pourquoi cette protection compte pour transit, serveurs dédiés et gaming

TCP est partout : sites web, APIs, panels clients, SSH, monitoring, Minecraft Java, certaines briques FiveM, reverse proxies et services internes exposés par IP publique. Si un ACK flood rend TCP instable, le client voit des déconnexions, un panel lent, des logins qui échouent et un service intermittent même si le serveur d’origine n’est pas complètement tombé.

Pour une entreprise qui vend en ligne ou cherche des clients via Google, LinkedIn ou X, la disponibilité fait partie de la conversion. Un prospect qui tombe sur un timeout pendant une attaque ne distingue pas un problème serveur d’un problème réseau. Il quitte simplement la page.

Le risque augmente quand la protection est trop générique. Bloquer un port TCP arrête le symptôme mais coupe le service. Tout laisser passer préserve la fonctionnalité mais peut saturer l’edge. La bonne mitigation doit être assez précise pour garder les sessions et assez précoce pour protéger les équipements fragiles.

Les solutions pratiques contre un ACK flood

Le durcissement local est utile mais limité. Firewalls, kernels et load balancers peuvent être ajustés pour réduire la pression stateful, éviter les logs excessifs et dropper les paquets clairement invalides. Mais si le flood a déjà saturé un port ou poussé le firewall à 100% CPU, la règle côté serveur arrive trop tard.

Le filtrage stateless peut retirer beaucoup de paquets impossibles avant inspection coûteuse : ports inutilisés, combinaisons de flags incohérentes, tailles anormales, sources qui touchent trop de destinations trop vite ou modèles qui ne correspondent pas au service attendu. La règle doit être adaptée : un edge web, un proxy Minecraft et un client BGP n’ont pas le même profil.

La mitigation amont et le transit protégé ajoutent un avantage majeur : réduire l’attaque avant le réseau client. Le trafic propre peut ensuite revenir par BGP, IP protégée, GRE, IPIP, VXLAN, VM routeur ou cross-connect selon la topologie.

Tuning d’origine

Utile pour la résilience, insuffisant si le lien ou le firewall sature avant.

Drops stateless précoces

Retirer le trafic impossible avant les inspections coûteuses.

Transit protégé

Déplacer le premier point de mitigation en amont et relivrer un trafic propre.

Seuils par service

Un panel TCP, une API ou un service de jeu nécessite une baseline réelle.

Chemin du trafic protégé pour Protection ACK flood

L’objectif est de filtrer ce qui ne peut clairement pas être utile tout en évitant les dommages collatéraux sur les sessions établies. Selon le cas, la mitigation peut combiner transit IP protégé, règles amont pour les événements très haut PPS, logique de filtrage personnalisée et handoff propre vers le client.

Exemple concret : ACK flood contre un panel client et un réseau de jeu

Imaginons un hébergeur qui expose un panel client, des APIs et plusieurs serveurs dédiés protégés. L’attaque démarre avec des paquets ACK sur les ports TCP du panel et de services liés au jeu. Le lien n’est pas totalement rempli, mais le CPU firewall monte et les sessions légitimes échouent.

Une réaction purement locale augmente les limites et ajoute une règle deny large. Elle réduit une partie du bruit, mais risque aussi de couper des sessions réelles. Avec un transit protégé, l’attaque peut être filtrée plus tôt. Le client reçoit un flux plus propre, le firewall ne gaspille plus ses ressources sur des ACK impossibles et l’application garde de la marge.

Erreurs fréquentes pendant un ACK flood

La première erreur consiste à considérer tous les ACK comme malveillants. Cela casse TCP. La deuxième est de croire que le serveur d’origine sauvera la situation seul. Il ne peut pas protéger un port de transit, un routeur amont ou un firewall déjà dépassé.

Autre erreur fréquente : regarder uniquement les Gbps. Un ACK flood peut être dangereux par les paquets par seconde, les recherches dans les tables de connexion et la pression CPU. Un graphe faible en Gbps ne signifie pas une attaque faible.

Enfin, beaucoup d’équipes posent des règles d’urgence sans vérifier le routage. Si le chemin est asymétrique, un équipement peut ne voir qu’un sens du flux. Une validation parfaite en laboratoire peut devenir destructive en production.

FAQ