Sur cette page
À retenir
- Au-delà du chiffre 1TbpsUne mitigation crédible dépend aussi du PPS, du routage, du handoff propre, du pré-filtrage et de la stabilité sous attaque.
- Ce qu’il faut vérifierCapacité amont, méthode de relivraison, règles BGP/FlowSpec, latence, MTU, supervision et scénario de secours.
- Intégration en productionLa protection doit s’adapter à votre architecture : BGP, GRE/IPIP/VXLAN, cross-connect ou VM routeur.
1Tbps ne suffit pas à définir une bonne protection
Dire qu’un fournisseur possède une mitigation DDoS 1Tbps ne répond pas aux questions les plus importantes. Le chiffre indique une capacité théorique ou mutualisée, mais pas forcément la capacité réellement disponible pour un client, la localisation de l’absorption, le type d’attaque couvert, ni la qualité du trafic remis après filtrage. Une attaque 1Tbps peut saturer un lien, un port, une table stateful, une file RX, un firewall ou un CPU bien avant d’atteindre la limite marketing affichée.
Le vrai problème est donc architectural. Le trafic doit être attiré vers une couche capable d’encaisser le volume, filtré le plus tôt possible, puis renvoyé avec un mode de handoff compatible avec la production. Pour un client BGP, cela implique des annonces maîtrisées, une préférence de route claire et parfois du FlowSpec. Pour un client sans ASN, cela peut passer par des IPs protégées, un tunnel ou un reverse proxy. Dans tous les cas, le réseau doit être lisible.
- Capacité brute
- Utile pour absorber le volumétrique, mais insuffisante si le handoff, les limites PPS ou les faux positifs ne sont pas maîtrisés.
- PPS et états
- Un petit volume en Gbps peut tuer un service si les paquets par seconde, les SYN ou les états firewall explosent.
- Retour propre
- Le trafic légitime doit revenir au serveur, au routeur ou au datacenter sans asymétrie dangereuse ni perte inutile.
Pourquoi c’est important pour un réseau qui dépend vraiment d’Internet
Quand une entreprise vit de son exposition Internet, quelques minutes d’indisponibilité peuvent coûter plus cher qu’un mois de protection. Un hébergeur perd la confiance de ses clients, une plateforme gaming perd ses joueurs, un SaaS bloque ses utilisateurs, et un service critique donne l’impression d’être fragile. À 1Tbps, l’incident n’est plus un simple pic : il peut impacter les upstreams, les ports, les équipements de bordure et parfois les routes vers plusieurs services en même temps.
Préparez l’attraction du trafic, sa réduction, le filtrage et la relivraison avant l’incident. Notez les préfixes autorisés, les validations requises, le signal de panne, la personne habilitée à modifier les politiques et les conditions de retour. Testez la destination et le chemin retour réels : un tunnel établi dans le tableau de bord ne prouve pas qu’un utilisateur atteint son application.
Les solutions possibles pour encaisser et filtrer une attaque 1Tbps
La première option est le transit IP protégé avec BGP. Le client annonce ses préfixes, le fournisseur Anti-DDoS attire le trafic, filtre l’attaque, puis remet le trafic propre vers le client. C’est le modèle le plus naturel pour un opérateur, un hébergeur, un réseau avec ASN ou une entreprise qui veut garder la maîtrise de ses routes. Il faut vérifier la politique d’annonce, les communautés BGP disponibles, le support AS-SET, les filtres, et la capacité réellement activable.
La deuxième option est la relivraison par tunnel : GRE, IPIP ou VXLAN. Elle convient lorsque le serveur ou le réseau reste chez un autre fournisseur mais que le trafic doit passer par une couche de mitigation spécialisée. La troisième option est le cross-connect en datacenter, souvent plus propre pour les gros volumes et les architectures sensibles à la latence. Enfin, les reverse proxy gaming ou applicatifs sont utiles pour FiveM, Minecraft, HTTP ou certains protocoles exposés, mais ils ne remplacent pas toujours un vrai filtrage L3/L4 amont.
| Modèle | Quand l’utiliser | Point à vérifier |
|---|---|---|
| BGP / transit protégé | Préfixes, ASN, opérateurs, hébergeurs, infrastructures multi-services | Communautés, délai d’activation, politique d’annonce, capacité par port |
| GRE / IPIP / VXLAN | Serveur conservé chez un autre hébergeur, intégration rapide, migration progressive | MTU, routage retour, latence, monitoring du tunnel |
| Cross-connect | Gros volumes, présence datacenter, besoin de handoff stable | Port, VLAN, délai DC, redondance, capacité physique |
| Reverse proxy | Gaming, HTTP, API ou protocole où le contexte applicatif aide | Compatibilité protocole, latence, logs, faux positifs |
Exemple chiffré : quelle charge arrive sur une livraison à 10 Gbit/s ?
Exercice hypothétique de dimensionnement, et non attaque mesurée chez Peeryx ou promesse de filtrage : l’attaque représente 1 000 Gbit/s et le trafic légitime 8 Gbit/s. Supposons que l’étape amont préserve tout le trafic légitime. Les pourcentages ci-dessous désignent la part de l’attaque qui atteint encore l’étape suivante, pas la part bloquée. Tous les débits doivent être comptés à la même couche.
Si le lien à 10 Gbit/s précède un filtrage supplémentaire, les deux premiers cas dépassent son débit nominal. Le dernier ne laisse que 1 Gbit/s de marge nominale, avant encapsulation, rafales, croissance ou réserve pour une panne. Si le filtrage local précède la livraison, mesurez plutôt sa sortie réelle : ce tableau ne prédit pas ce que supprimera un filtre. Recalculez le budget à chaque segment limité, pas seulement au port client.
Un débit résiduel plus faible peut encore imposer beaucoup de paquets par seconde ou saturer les états. Un taux de réduction amont ne renseigne ni sur les paquets légitimes perdus, ni sur les connexions de joueurs acceptées, ni sur le temps de réponse applicatif. Mesurez ces résultats séparément et fixez leurs limites avant d’accepter l’architecture.
| Part de l’attaque restant après réduction amont | Attaque résiduelle | Attaque résiduelle + trafic légitime |
|---|---|---|
| 1 % | 10 Gbit/s | 18 Gbit/s |
| 0,3 % | 3 Gbit/s | 11 Gbit/s |
| 0,1 % | 1 Gbit/s | 9 Gbit/s |
Erreurs fréquentes avant d’acheter une mitigation DDoS 1Tbps
La première erreur est de comparer seulement le chiffre de capacité. Deux fournisseurs peuvent afficher 1Tbps, mais l’un peut avoir un meilleur handoff, une meilleure proximité réseau, des règles plus précises et un support plus réactif. La deuxième erreur est d’ignorer les paquets par seconde. Beaucoup d’incidents ne cassent pas l’infrastructure par le débit total, mais par la pression sur les files, les interruptions, les états ou les workers.
La troisième erreur est de ne pas tester le mode de retour. Un tunnel mal dimensionné, une MTU oubliée, un routage retour incohérent ou une asymétrie non assumée peuvent créer des pertes alors que la mitigation fonctionne. La quatrième erreur est de mettre tout le trafic derrière une règle trop agressive. Une bonne protection réduit l’attaque sans transformer les utilisateurs légitimes en dommages collatéraux.
- Acheter uniquement un chiffre en Tbps sans demander l’architecture.
- Oublier les limites PPS, CPU, ports et états firewall.
- Ne pas vérifier GRE, IPIP, VXLAN, BGP ou cross-connect avant l’urgence.
- Ne pas prévoir de monitoring pendant l’attaque.
- Confondre reverse proxy applicatif et mitigation volumétrique réseau.
FAQ sur la mitigation DDoS 1Tbps
Une mitigation DDoS 1Tbps garantit-elle que mon service ne tombera jamais ?
Non. Elle indique une capacité importante, mais la disponibilité dépend aussi du type d’attaque, du PPS, du mode de handoff, du routage, des règles appliquées et de la capacité de votre infrastructure à recevoir le trafic propre.
Faut-il forcément avoir un ASN et du BGP ?
Non. BGP est idéal pour protéger des préfixes et une infrastructure réseau, mais un client sans ASN peut aussi utiliser des IPs protégées, un tunnel GRE/IPIP/VXLAN ou un reverse proxy selon le service.
Quelle est la différence entre Anti-DDoS 1Tbps et transit IP protégé ?
L’Anti-DDoS décrit la capacité et le filtrage. Le transit IP protégé décrit le modèle réseau complet : entrée du trafic, annonce éventuelle, mitigation, puis relivraison propre vers le client.
Un reverse proxy FiveM ou Minecraft suffit-il contre 1Tbps ?
Pas toujours. Un reverse proxy est utile pour le contexte protocolaire et l’anti-bot, mais les attaques très volumétriques doivent être réduites en amont avant d’atteindre la couche applicative.
