Sur cette page
À retenir
- FlowSpec est un outil amont assez grossierIl réduit très bien du volume évident, mais ne prend pas toutes les décisions applicatives.
- La portée de règle est le vrai dangerUne règle trop large peut supprimer du trafic légitime à grande échelle.
- Le support fournisseur varieActions, composants, limites et propagation ne sont pas identiques selon les réseaux.
Le problème opérationnel
La première limite est sémantique. FlowSpec matche des champs d’en-tête : destination, source, protocole, ports, longueur de paquet, flags TCP et composants similaires selon l’implémentation. C’est très utile pour un UDP flood répétitif, mais cela ne sait pas si un paquet appartient à une vraie session joueur, à un client API valide ou à un pic attendu après une mise à jour. FlowSpec voit des champs, pas le contexte métier.
La seconde limite est opérationnelle. Les fournisseurs peuvent limiter le nombre de règles, les composants supportés, la portée destination ou les actions disponibles. Certains acceptent seulement un petit sous-ensemble de matches. D’autres rejettent les règles complexes. Une architecture qui suppose une précision FlowSpec illimitée peut échouer au moment où le client en a le plus besoin.
Pourquoi cela compte avant l’attaque
Comprendre ces limites évite des erreurs coûteuses. Une règle FlowSpec trop large peut couper la production avant même que le trafic n’arrive sur les filtres du client. Comme elle s’applique en amont, le rayon d’impact est plus grand qu’une erreur de firewall local. Le client peut voir une courbe propre alors que les utilisateurs ne se connectent plus.
Cela fixe aussi la bonne attente commerciale. FlowSpec n’est pas “la protection DDoS à lui seul”. C’est un moyen de retirer en amont du trafic lourd, évident et répétitif, afin que le transit protégé, les serveurs de filtrage et les systèmes plus intelligents terminent le travail avec moins de pression.
- FlowSpec est un outil amont assez grossier
- Il réduit très bien du volume évident, mais ne prend pas toutes les décisions applicatives.
- La portée de règle est le vrai danger
- Une règle trop large peut supprimer du trafic légitime à grande échelle.
- Le support fournisseur varie
- Actions, composants, limites et propagation ne sont pas identiques selon les réseaux.
Les approches techniques possibles
L’approche la plus sûre consiste à utiliser FlowSpec pour dégrossir. Autrement dit : cibler les parties de l’attaque qui sont clairement mauvaises, temporaires et mesurables. Les règles doivent privilégier une destination précise, un protocole précis, des plages de ports limitées, des longueurs de paquets justifiées et une logique d’expiration.
Pour les décisions complexes, il faut garder de l’intelligence plus bas : filtrage DPDK/VPP, XDP, logique proxy, validation gaming, heuristiques de connexion ou règles firewall spécifiques. C’est là que l’état, les baselines et la connaissance du service peuvent être appliqués sans demander à un routeur amont de devenir un firewall applicatif.
- Règles étroites
- Limiter destination, protocole et portée pour réduire le dommage collatéral.
- Expiration automatique
- Des règles courtes évitent que des filtres obsolètes pénalisent le trafic futur.
- Intelligence downstream
- Laisser aux filtres spécialisés les décisions qui demandent de l’état ou du contexte.
- Mesure du légitime
- Observer le trafic accepté, pas seulement le trafic bloqué.
Cas concret d’utilisation
Un fournisseur reçoit un UDP flood de 180 Gbps avec un port destination et une taille de paquet répétitifs. Une règle FlowSpec étroite peut retirer une grande partie de l’attaque en amont et éviter la saturation du port client. Mais une règle qui matche tout l’UDP vers le préfixe client peut aussi tuer DNS, sessions de jeu ou supervision.
Le design le plus sûr est progressif : commencer par la signature malveillante évidente, mesurer le trafic accepté, puis laisser la couche de mitigation downstream traiter le trafic restant plus mélangé. Si l’attaque mute, mieux vaut générer une nouvelle règle précise qu’élargir la première jusqu’à en faire un blackhole déguisé.
Identifier ce qui est réellement stable
Ne pas créer une règle à partir d’un échantillon trop court si l’attaque change toutes les secondes.
Borner la destination
Préférer l’hôte attaqué ou une portion de préfixe plutôt qu’une règle trop globale.
Ajouter une expiration
Une règle FlowSpec sans durée devient de la dette technique.
Prévoir le rollback
Les opérateurs doivent savoir retirer ou remplacer la règle immédiatement.
Erreurs fréquentes à éviter
- Utiliser FlowSpec comme firewall permanent.
- Matcher une destination ou un protocole trop large.
- Oublier quotas et composants supportés par le fournisseur.
- Supposer que longueur de paquet ou flags TCP sont toujours sûrs.
- Ne pas mesurer le trafic légitime après propagation.
FAQ
FlowSpec peut-il stopper un DDoS seul ?
Il peut stopper certaines attaques simples, mais une mitigation sérieuse combine FlowSpec, capacité protégée et filtrage downstream.
Pourquoi les règles larges sont-elles dangereuses ?
Parce qu’elles s’appliquent en amont, avant que le client puisse récupérer le trafic légitime localement.
Tous les fournisseurs supportent-ils les mêmes champs ?
Non. Support, quotas et actions varient selon le réseau.
Les règles FlowSpec doivent-elles être permanentes ?
En général non. Les règles DDoS doivent être courtes sauf politique très maîtrisée.
