Sur cette page
À retenir
- Les flags TCP sont utiles mais incompletsIls décrivent l’intention d’un paquet, pas la légitimité complète d’une connexion.
- ACK et RST demandent une prudence particulièreIls peuvent toucher du trafic établi ou des comportements de récupération.
- L’état doit rester à la bonne coucheFlowSpec réduit le volume ; les filtres downstream valident le contexte quand nécessaire.
Le problème opérationnel
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.
Pourquoi cela compte avant l’attaque
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.
- Les flags TCP sont utiles mais incomplets
- Ils décrivent l’intention d’un paquet, pas la légitimité complète d’une connexion.
- ACK et RST demandent une prudence particulière
- Ils peuvent toucher du trafic établi ou des comportements de récupération.
- L’état doit rester à la bonne couche
- FlowSpec réduit le volume ; les filtres downstream valident le contexte quand nécessaire.
Les approches techniques possibles
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.
- Matching SYN
- Utile contre les floods d’ouverture de connexion, si la destination est précise.
- Matching ACK
- Puissant mais risqué ; vérifier asymétrie et trafic établi avant.
- Matching RST
- À utiliser brièvement, car RST peut faire partie de la récupération.
- Validation combinée
- Utiliser du downstream pour le contexte que FlowSpec ne voit pas.
Un paquet SYN ne prouve pas une attaque
Prenons un SYN flood visant une API sur TCP 443. Une règle qui supprime tous les SYN vers cette destination supprime aussi les ouvertures de connexion légitimes. Restreindre la destination ne rend pas cette règle sûre pour les utilisateurs du service.
Avant de rejeter les paquets, identifiez un critère supplémentaire qui distingue le trafic indésirable des ouvertures valides, puis vérifiez-le sur du trafic légitime représentatif. Si le routeur ne dispose pas d’un tel critère, utilisez une validation TCP adaptée en aval. Un limiteur de débit s’applique à l’ensemble du trafic correspondant ; l’attaque peut aussi consommer ce quota.
Précisez les critères et l’action, vérifiez l’interprétation du masque TCP sur le routeur récepteur et observez nouvelles connexions et sessions établies. Prévoyez le retrait de la règle et un responsable de son expiration. FlowSpec ne prouve pas, à lui seul, l’appartenance à une session TCP valide.
Erreurs fréquentes à éviter
- Bloquer tous les ACK parce que l’attaque s’appelle ACK flood.
- Oublier que FlowSpec ne suit pas les sessions TCP.
- Réutiliser la même règle sur plusieurs services sans rapport.
- Laisser une règle temporaire après mutation de l’attaque.
- Ignorer NAT, load balancers ou proxies dans le chemin.
FAQ
Tous les fournisseurs FlowSpec supportent-ils les TCP flags ?
Pas toujours de la même manière. Il faut vérifier composants et actions supportés.
Le matching SYN est-il plus sûr que ACK ?
Souvent oui, car SYN est lié à l’ouverture de connexion, mais il faut quand même borner destination et taux.
FlowSpec remplace-t-il SYN cookies ou proxy ?
Non. Il réduit le volume amont ; la validation reste dans une couche state-aware.
Faut-il utiliser les flags TCP pour le gaming ?
Avec prudence. Certains jeux utilisent aussi TCP pour login, HTTP/TLS ou chargement de ressources.
