Les flags TCP peuvent rendre une règle FlowSpec précise contre des floods SYN, ACK ou RST, mais ils deviennent risqués s’ils ignorent l’état des connexions, le routage asymétrique et le comportement légitime du protocole.
Ils décrivent l’intention d’un paquet, pas la légitimité complète d’une connexion.
Ils peuvent toucher du trafic établi ou des comportements de récupération.
FlowSpec réduit le volume ; les filtres downstream valident le contexte quand nécessaire.
Le matching des flags TCP est l’une des fonctions BGP FlowSpec les plus tentantes, car beaucoup d’attaques semblent avoir une signature évidente : SYN flood, ACK flood, tempête de RST ou combinaisons rarement produites par des stacks normales. Bien utilisé, ce matching retire un gros volume en amont. Mal utilisé, il coupe des sessions légitimes, casse un chemin asymétrique ou masque le vrai problème derrière une règle élégante sur le papier. Cet article explique quand les flags TCP aident, comment les borner, pourquoi l’état reste important et comment les combiner avec du transit protégé.
Le problème des flags TCP est qu’ils semblent plus significatifs qu’ils ne le sont réellement. Un SYN ouvre une connexion, un ACK appartient souvent à un flux établi, un RST ferme parfois une session. Mais FlowSpec voit un paquet isolé. Il ne sait pas si un SYN est un pic légitime, si un ACK appartient à une vraie connexion vue par un autre chemin ou si les RST sont le symptôme d’une application saturée.
La situation devient plus délicate avec le routage asymétrique. Si le trafic entrant passe par la mitigation et le trafic sortant par un autre transit, une règle FlowSpec amont ne voit pas toute la machine d’état TCP. Une règle sûre en laboratoire peut devenir trop agressive en production avec NAT, load balancers, proxies ou chemins retour séparés.
Les floods TCP peuvent être destructeurs même sans saturation pure de bande passante. PPS élevé, pression sur backlog SYN, tables de connexion et timeouts applicatifs peuvent dégrader un service avant que les liens soient pleins. Les flags TCP aident à retirer en amont la partie évidente de cette pression.
Mais TCP est stateful, donc les faux positifs coûtent cher. Bloquer les mauvais ACK peut figer des sessions. Bloquer les RST aveuglément peut ralentir la récupération. Bloquer trop largement les SYN peut empêcher les nouveaux utilisateurs d’entrer. Les flags TCP doivent donc rester une réponse mesurée, pas une recette permanente copiée d’un autre réseau.
Ils décrivent l’intention d’un paquet, pas la légitimité complète d’une connexion.
Ils peuvent toucher du trafic établi ou des comportements de récupération.
FlowSpec réduit le volume ; les filtres downstream valident le contexte quand nécessaire.
Pour un SYN flood, une règle étroite peut viser les SYN excessifs vers un hôte ou un port précis, surtout si une validation SYN ou proxy existe derrière. Pour un ACK flood, il faut plus de prudence : vérifier que ce n’est pas du trafic retour légitime, observer les sessions établies et éviter les règles globales sur tout un préfixe. Pour les RST, préférer un confinement court et une analyse downstream avant d’élargir.
La meilleure solution combine les couches. FlowSpec retire en amont le flood évident chargé en flags. La stack de mitigation derrière suit les baselines, anomalies de rate, ports de service et comportements. Pour un jeu ou une API, de la logique supplémentaire peut valider les sessions au lieu de croire qu’un flag raconte toute l’histoire.
Utile contre les floods d’ouverture de connexion, si la destination est précise.
Puissant mais risqué ; vérifier asymétrie et trafic établi avant.
À utiliser brièvement, car RST peut faire partie de la récupération.
Utiliser du downstream pour le contexte que FlowSpec ne voit pas.
Peeryx utilise les flags TCP seulement quand ils rendent une règle amont plus précise. Le modèle préféré n’est pas de bloquer “tout ACK” ou “tout SYN” parce que la courbe fait peur. La règle doit être liée à la destination attaquée, au port, au motif de rate et au comportement légitime attendu.
Derrière la règle amont, Peeryx conserve une mitigation plus fine. Cette séparation est essentielle : FlowSpec protège capacité et PPS, tandis que la stack downstream protège la qualité des sessions. Pour les clients en transit protégé, GRE/IPIP/VXLAN ou VM routeur, cela permet de réagir vite sans transformer TCP en deny-list aveugle.
Les flags affinent les règles au lieu de créer des blocages larges permanents.
Le trafic accepté et le comportement des connexions sont observés après chaque changement.
Transit, tunnel ou VM routeur selon la topologie client.
Une API web reçoit un SYN flood sur TCP/443. L’attaque surcharge les tables downstream. Une règle FlowSpec étroite sur les SYN vers la destination attaquée peut retirer une grande partie du flood, pendant que les systèmes derrière gèrent les vrais handshakes. C’est un bon usage des flags TCP.
À l’inverse, sur un ACK flood avec chemin asymétrique, un drop ACK trop large peut sembler efficace dans la courbe amont mais supprimer du trafic établi réel que FlowSpec ne peut pas corréler. L’option sûre est de commencer par destination et taux, observer les sessions légitimes et déplacer la validation complexe vers la mitigation.
Confirmer si SYN, ACK, RST ou une combinaison domine réellement.
Éviter les règles TCP flags sur tout un préfixe si une alternative existe.
Savoir si le chemin retour et l’état TCP sont visibles par la couche de filtrage.
Les règles de flags doivent évoluer avec l’attaque.
Pas toujours de la même manière. Il faut vérifier composants et actions supportés.
Souvent oui, car SYN est lié à l’ouverture de connexion, mais il faut quand même borner destination et taux.
Non. Il réduit le volume amont ; la validation reste dans une couche state-aware.
Avec prudence. Certains jeux utilisent aussi TCP pour login, HTTP/TLS ou chargement de ressources.
L’architecture Anti-DDoS la plus sûre est celle qui donne un rôle clair à chaque couche : le routage oriente le trafic, les règles amont réduisent la pression évidente et la mitigation downstream protège le contexte du service.
Peeryx se concentre sur cette clarté opérationnelle : transit IP protégé, modes de livraison maîtrisés et décisions de filtrage assez fortes pour stopper les attaques sans transformer le trafic légitime en dommage collatéral.
Peeryx peut analyser vos préfixes, votre mode de livraison et votre exposition aux attaques afin de proposer du transit IP protégé, une livraison par tunnel ou un reverse proxy gaming quand c’est le bon scénario.
