Sur cette page
À retenir
- Au-delà de 100Gbps, le design compte plus que le chiffreLien, PPS, CPU, handoff propre et logique de secours doivent être pensés ensemble pour qu’une mitigation reste exploitable.
- Le Gbps n’est pas toutUne attaque peut casser par le lien, par le PPS ou par le coût CPU de la logique de mitigation.
- Le pré-filtrage amont compte énormémentIl sert à dégrossir, pas à tout résoudre, afin que les couches plus intelligentes restent stables.
- Définir le test de réceptionFixez les tailles de paquets, les règles, le trafic légitime, les pertes et la reprise ; observez la file la plus chargée et le chemin restant après panne.
100 Gbit/s désigne un débit de lien, pas une performance de filtrage
Commencez par le premier segment limité et la couche à laquelle le débit est mesuré. Une attaque observée, un port physique, un total multisite et une capacité réservée au client sont des grandeurs différentes. Une interface à 100 Gbit/s peut être le point de saturation même si le fournisseur annonce beaucoup plus de capacité ailleurs.
Les valeurs suivantes sont un calcul théorique sur le câble, pour un sens de transmission Ethernet. La longueur comprend la trame et son FCS ; ajoutez 8 octets de préambule/SFD et 12 octets d’intervalle entre trames. Mpps = Gbit/s × 1 000 ÷ [8 × (octets de trame + 20)]. Ce ne sont pas des benchmarks logiciels et ils ne décrivent pas les limites d’une implémentation donnée.
| Trame Ethernet, FCS inclus | Débit théorique à 100 Gbit/s | Interprétation |
|---|---|---|
| 64 octets | 148,81 Mpps | Les petites trames multiplient les décisions par paquet |
| 128 octets | 84,46 Mpps | Même débit du lien, autre cadence de paquets |
| 512 octets | 23,50 Mpps | Les états et les règles peuvent encore dominer le coût |
| 1 518 octets | 8,13 Mpps | Les grandes trames ne prouvent pas la performance sur les petites |
Volumétrique vs applicatif : ce n’est pas le même combat
Une attaque volumétrique cherche d’abord à casser le chemin réseau : bande passante, buffers, tables de flux, PPS. Une attaque applicative cherche plutôt à épuiser une logique de service, un proxy ou une ressource métier. Les deux peuvent coexister, mais elles ne se filtrent pas au même endroit.
Quand on parle de plus de 100Gbps, la priorité est presque toujours de survivre au volume et au PPS. Si le lien tombe avant, votre meilleure logique applicative n’a plus aucune utilité.
- Le volumétrique se traite d’abord au niveau absorption et tri de masse.
- L’applicatif exige ensuite un filtrage plus fin, plus contextuel et plus prudent.
- Mélanger trop tôt ces deux niveaux crée soit des faux positifs, soit des coûts CPU inutiles.
Saturation lien, saturation PPS, saturation CPU : trois pannes différentes
Un DDoS ne casse pas un service d’une seule manière. Il peut saturer un lien, remplir un plan de commutation par le nombre de paquets, ou pousser trop loin le coût CPU d’une logique de mitigation trop lourde. C’est pour cela qu’un simple chiffre de capacité n’a pas beaucoup de sens sans architecture.
Mesurez la charge par file et par cœur en plus des totaux. Une répartition inégale des flux peut surcharger une file tandis que d’autres cœurs restent libres. Deux ports 100G peuvent servir respectivement à l’entrée et à la sortie : ils ne constituent pas alors un chemin de filtrage à 200 Gbit/s dans un sens. Indiquez le sens, la couche de comptage et le rôle de chaque port dans le rapport.
Saturation lien
Le port ou le transit prend trop de volume avant analyse détaillée.
Saturation PPS
Le nombre de paquets devient le vrai tueur, même si le Gbps semble “supportable”.
Saturation CPU
La pile de filtrage voit le trafic, mais dépense trop de cycles pour rester stable.
Le rôle du pré-filtrage en amont
Le pré-filtrage amont sert à dégrossir. Son rôle n’est pas de prendre seul toute la décision de légitimité, mais de retirer les patterns suffisamment évidents pour que le bruit massif n’atteigne pas les étages les plus chers.
C’est souvent le meilleur rapport coût / efficacité : faire moins passer vers le serveur de filtrage, conserver des liens respirables et garder de la marge pour les cas qui demandent plus d’intelligence.
Le rôle d’un serveur de filtrage
Validez un serveur de filtrage avec une charge reproductible, pas seulement avec sa référence CPU. Consignez les versions du logiciel et des règles, la carte et son pilote, la répartition des files, le placement NUMA, les tailles de paquets et les fonctions à états activées. Mesurez le trafic reçu, l’attaque rejetée, le trafic légitime transféré, les pertes et la latence dans les mêmes conditions.
Utilisez un environnement de test isolé et autorisé. La RFC 2544 décrit une méthode de benchmark ; la RFC 6815 explique pourquoi son application en production peut perturber les utilisateurs. Testez séparément la reprise après panne et le chemin restant à la charge prévue. Un bon résultat en laboratoire ne démontre pas la capacité d’une topologie de production non testée.
Le rôle des tunnels et du retour propre du trafic
Mitiger ne suffit jamais. Il faut encore réinjecter un trafic propre là où le client en a besoin, sans casser l’existant. C’est là que GRE, IPIP, VXLAN, BGP over GRE ou cross-connect prennent du sens.
Le bon modèle dépend du contexte : serveur dédié existant, backbone, cluster, proxy ou besoin de conserver les IPs publiques. Le plus important n’est pas le nom du tunnel, mais la cohérence du handoff avec la topologie réelle.
- Un bon handoff évite une migration complète imposée par l’anti-DDoS.
- Le tunnel fait partie du modèle d’exploitation, pas seulement du transport.
- Le retour propre doit être pensé avant l’attaque, pas après la saturation.
Erreurs fréquentes
- Croire que 100Gbps est uniquement un sujet de bande passante.
- Mettre toute la logique dans une seule couche et découvrir trop tard qu’elle ne peut pas tout absorber.
- Négliger le retour propre du trafic jusqu’au jour où la prod ne sait plus reprendre le flux légitime.
- Sur-filtrer en amont sans baseline fiable du trafic normal.
- Acheter une promesse de mitigation sans comprendre le mode de handoff.
FAQ
Une attaque de plus de 100Gbps signifie-t-elle forcément la chute du service ?
Non, mais elle impose une architecture préparée. Sans absorption, dégrossissement et relivraison propre, le risque monte très vite.
Un simple serveur de filtrage peut-il suffire ?
Pas toujours. Il peut être très utile, mais sans soulagement amont il peut lui aussi devenir le point de rupture.
Pourquoi insister autant sur le retour propre du trafic ?
Parce qu’une mitigation n’a de valeur que si le client récupère un trafic réellement exploitable.
Peut-on garder une infrastructure existante ?
Oui, très souvent. C’est justement l’intérêt d’un bon modèle de delivery.
Quel premier indicateur regarder avant de parler de 100Gbps ?
Commencez par distinguer saturation de lien, saturation en paquets par seconde et saturation CPU. C’est cette lecture qui évite de mal dimensionner la mitigation.
