SYN flood : protéger l’ouverture des connexions TCP

Ce qu’un SYN flood cherche vraiment à épuiser

Un SYN flood cible le mécanisme d’ouverture TCP. Normalement, un client envoie un paquet SYN, le serveur répond par SYN-ACK, puis le client confirme avec ACK. À ce moment-là, la connexion est établie. Lors d’une attaque, la cible reçoit un volume anormal de SYN, souvent depuis des sources usurpées, distribuées ou très instables. Le serveur ou l’équipement intermédiaire peut alors conserver de l’état pour des connexions qui ne seront jamais terminées.

Le résultat n’est pas seulement une hausse de trafic. C’est une pression sur les ressources de connexion : tables d’état, backlog TCP, CPU de firewall, files d’attente, mémoire, système de NAT, load balancer, reverse proxy ou serveur web. Même si le volume en Gbps reste inférieur à la capacité annoncée, le nombre de paquets par seconde et la quantité d’états incomplets peuvent rendre le service indisponible.

Une attaque SYN flood peut aussi être mélangée à d’autres vecteurs. Par exemple, une vague UDP sature le lien pendant qu’un SYN flood tente d’épuiser les composants stateful. Dans ce cas, une défense qui regarde uniquement le débit moyen ou qui bloque brutalement un port ne suffit pas. Il faut comprendre où la saturation apparaît et quelle couche doit être soulagée en premier.

Épuisement du backlog

Trop de connexions incomplètes empêchent les vrais clients d’obtenir une place dans la file TCP.

Pression sur les équipements stateful

Firewall, NAT et load balancer peuvent tomber avant le serveur d’origine.

Sources spoofées ou distribuées

Les paquets peuvent venir de nombreuses IPs, parfois usurpées, ce qui rend le blocage par source moins fiable.

Pourquoi c’est important pour une infrastructure qui vend en ligne

Pour l’utilisateur final, un SYN flood ne se voit pas comme une attaque réseau. Il se voit comme une page qui ne charge pas, un panel qui refuse la connexion, une API qui timeout, un serveur de jeu qui devient instable ou un service professionnel qui paraît hors ligne. Si le service est au cœur de la génération de prospects, de clients ou de revenus, quelques minutes d’indisponibilité peuvent suffire à perdre une vente ou à dégrader la confiance.

La difficulté vient du fait que TCP est utilisé partout : sites web, API, SSH, panels clients, bases exposées dans certains scénarios, proxies, load balancers, tunnels et services métier. Une mitigation trop agressive peut donc provoquer des faux positifs massifs. Bloquer un port TCP exposé peut arrêter le graphe d’attaque, mais cela revient aussi à couper le service. Un vrai design doit maintenir assez de capacité et de précision pour que les clients légitimes puissent continuer à établir leurs sessions.

Ce point est encore plus important pour les entreprises qui misent sur leur visibilité en ligne, LinkedIn ou X. Un prospect acquis difficilement doit tomber sur une infrastructure disponible. La protection DDoS devient alors un sujet commercial autant que technique : elle protège le taux de conversion, la crédibilité et la continuité du service.

Les solutions possibles contre un SYN flood

La première réponse connue est l’activation de protections TCP côté système, comme les SYN cookies, l’ajustement du backlog ou certains seuils kernel. Ces mécanismes sont utiles, mais ils ne résolvent pas tout. Ils aident le serveur à ne pas réserver trop tôt de ressources, mais ils ne protègent pas le lien, le routeur, le firewall ou le load balancer si l’attaque arrive déjà trop loin dans l’architecture.

Une autre approche consiste à faire du rate limiting. Elle peut fonctionner pour réduire un bruit évident, mais elle devient risquée si le trafic légitime augmente réellement ou si l’attaque imite des ouvertures normales. Un seuil trop bas bloque les vrais utilisateurs ; un seuil trop haut ne protège pas assez. Le rate limiting doit donc être contextualisé par service, port, comportement attendu et capacité réelle.

Les ACL, les règles stateless, le filtrage par taille de paquet, par flags TCP ou par caractéristiques réseau peuvent être très efficaces lorsqu’ils sont appliqués tôt. Mais ils doivent être précis. Une règle trop large peut couper des utilisateurs, perturber certains chemins réseau ou casser des services qui ont des contraintes particulières. C’est pour cela que le filtrage amont, le scrubbing et la relivraison propre sont souvent nécessaires dès que l’exposition devient sérieuse.

SYN cookies et tuning kernel

Utile pour renforcer l’origine, mais insuffisant contre la saturation amont.

Rate limiting contextualisé

Efficace si les seuils sont adaptés au vrai service et pas copiés génériquement.

Filtrage stateless précoce

Réduit la pression avant les équipements qui conservent de l’état.

Transit protégé ou scrubbing

Permet de nettoyer le trafic avant la production et de relivrer uniquement ce qui est exploitable.

Un filtrage TCP adapté au service réel, pas une règle générique

Le trafic peut entrer par transit IP protégé avec annonce BGP, par IP protégées, par tunnel GRE/IPIP/VXLAN ou par cross-connect selon l’architecture. L’intérêt est de positionner la mitigation avant que l’attaque atteigne les équipements les plus fragiles. Le trafic propre est ensuite renvoyé vers l’infrastructure du client de manière lisible, avec un handoff qui respecte ses contraintes réseau.

Pour les vagues très volumétriques ou très haut PPS, une logique de filtrage peut aussi être combinée à du soulagement amont, notamment lorsque l’objectif est de réduire le bruit avant qu’il ne consomme du port ou de la capacité de traitement. L’usage doit rester précis, temporaire et proportionné : il ne s’agit pas de blackholer le client, mais de raboter l’attaque pour que la couche de mitigation fine garde la main.

Selon le client, la même logique peut servir à protéger un transit IP avec BGP, un serveur dédié exposé, un panel web, une API ou un service de jeu qui dépend de connexions TCP stables comme Minecraft. L’important est de choisir le bon point de filtration et le bon mode de relivraison au lieu d’appliquer une règle générique à toute l’infrastructure.

• identifier où la pression apparaît : lien, firewall, load balancer, kernel ou application
• filtrer le plus tôt possible ce qui est clairement illégitime
• éviter les règles stateful coûteuses sur le chemin chaud
• garder une relivraison propre vers le client : cross-connect, GRE, IPIP, VXLAN ou VM routeur
• adapter le profil au service au lieu de copier un modèle unique pour tous les clients

Un service web et un panel client sous SYN flood

Imaginons un hébergeur ou une plateforme SaaS avec un site commercial, un panel client et plusieurs services TCP exposés. L’attaque démarre avec un volume modéré en Gbps, mais un très grand nombre de SYN par seconde. Le lien n’est pas forcément plein, pourtant les clients voient des timeouts. Le firewall stateful commence à consommer beaucoup de CPU et le load balancer garde trop d’états incomplets.

Le résultat attendu n’est pas magique : il dépend du service, de la volumétrie, du chemin réseau et du comportement légitime. Mais le design devient beaucoup plus propre. Le client ne tente plus de sauver seul un serveur déjà noyé ; il reçoit un trafic réduit, plus lisible et plus proche de ce que son application peut réellement traiter.

1. Baseline

   Comprendre le trafic TCP normal : ports, rythme d’ouverture, pics attendus et profil des utilisateurs.

2. Détection

   Identifier les signes d’un SYN flood : déséquilibre SYN/ACK, sources instables, PPS anormal ou backlog sous pression.

3. Filtrage

   Bloquer tôt le trafic incohérent et éviter de faire travailler les couches stateful sur du bruit.

4. Relivraison

   Renvoyer le trafic propre vers le client par le mode d’intégration le plus adapté.

Erreurs fréquentes à éviter

Un SYN flood paraît simple, donc beaucoup d’équipes le traitent avec une seule règle. C’est souvent insuffisant. La vraie question est de savoir quelle ressource est en train de céder et à quel endroit du chemin la décision doit être prise.

La deuxième erreur consiste à confondre protection serveur et protection réseau. Durcir Linux, Nginx ou HAProxy est utile, mais cela ne protège pas un port saturé ni un firewall déjà dépassé. Le serveur ne peut pas filtrer un paquet qui n’arrive plus jusqu’à lui ou qui a déjà fait tomber une couche intermédiaire.

• se fier uniquement au Gbps et ignorer les paquets par seconde
• activer un rate limit global sans connaître le trafic légitime
• placer la première vraie défense derrière un firewall stateful fragile
• bloquer toutes les nouvelles connexions et appeler cela une mitigation
• oublier de tester le mode de relivraison avant l’attaque réelle

FAQ