DDoS volumétrique et applicatif : distinguer les cibles

Deux attaques qui ne visent pas la même faiblesse

Une attaque DDoS volumétrique cherche principalement à remplir le tuyau. Elle utilise du trafic massif, souvent distribué, parfois amplifié, pour saturer le transit, le port, la capacité de nettoyage ou les files de traitement réseau. Le serveur d’origine peut être techniquement capable de répondre, mais il ne reçoit plus un trafic exploitable : le lien est plein, la latence explose, les paquets légitimes sont perdus et les équipements intermédiaires travaillent dans une zone dangereuse.

Une attaque DDoS applicative vise plutôt la logique du service. Elle peut envoyer moins de bande passante, mais consommer beaucoup plus de ressources utiles : connexions HTTP, recherche coûteuse, endpoint de login, requêtes API, handshake de jeu, récupération d’informations FiveM, bot Minecraft, TLS, proxy ou mécanisme de session. Elle ressemble parfois à du trafic normal, ce qui rend le blocage brutal plus risqué.

La difficulté vient du fait que les deux formes peuvent se mélanger. Une attaque peut commencer par du volume, puis évoluer vers du protocole. Un service gaming peut subir un flood UDP évident et, en parallèle, des bots qui imitent le comportement d’un joueur. C’est pour cela qu’un discours limité à “nous avons beaucoup de Tbps” ne suffit pas : il faut savoir quelle couche protège quoi.

Volumétrique

Objectif : saturer la capacité réseau, le port, le transit, les buffers ou le nombre de paquets avant même que l’application réponde.

Applicatif

Objectif : épuiser la logique du service, une API, un login, un protocole de jeu, une couche HTTP/TLS ou une ressource métier.

Hybride

Objectif : combiner bruit réseau et abus applicatif pour forcer une mauvaise réaction ou créer des faux positifs.

Pourquoi c’est important avant de choisir une protection

Le mauvais diagnostic fait perdre du temps et de l’argent. Si l’attaque sature le lien, une règle applicative, un WAF ou un reverse proxy placé trop tard ne changera rien : le trafic légitime ne peut déjà plus atteindre la couche qui décide. La priorité est alors de déplacer l’entrée du trafic vers une infrastructure capable d’absorber, de réduire et de relivrer proprement.

À l’inverse, si le problème est applicatif, une grosse capacité réseau peut garder le port en vie mais laisser passer la douleur. Une API peut rester joignable tout en étant inutilisable, un serveur de jeu peut répondre mais bloquer au chargement, un panel peut rester accessible tout en consommant son CPU sur des actions inutiles. Dans ce cas, il faut comprendre le comportement du protocole, pas seulement compter les Gbps.

Cette distinction influence aussi la latence, le coût et l’exploitation. Une défense volumétrique doit être très rapide, peu intrusive et proche du réseau. Une défense applicative doit être plus contextuelle, mais elle peut introduire plus de complexité. Mélanger les deux sans architecture claire peut créer des faux positifs, casser des joueurs légitimes ou rendre l’incident impossible à diagnostiquer.

Les solutions possibles selon le point de rupture

Pour une attaque volumétrique, la meilleure réponse consiste à ne pas laisser le trafic brut arriver sur l’infrastructure client. Le trafic doit entrer dans une couche de mitigation disposant de capacité, de règles rapides et d’un chemin de sortie propre. Pour un opérateur, un hébergeur ou une entreprise qui annonce ses préfixes, le transit IP protégé est le modèle le plus naturel : BGP, préfixes, capacité amont, filtrage puis livraison du trafic nettoyé.

Lorsque le client ne veut pas déplacer ses serveurs, les tunnels GRE, IPIP ou VXLAN permettent de renvoyer le trafic propre vers l’infrastructure existante. Un cross-connect peut être préférable en datacenter quand le besoin est plus stable et plus capacitaire. Une VM routeur peut aussi servir de point propre pour terminer les tunnels, router, superviser et contrôler le retour vers la production.

Pour une attaque applicative, la défense doit se rapprocher du service. Un reverse proxy web ou gaming, une logique anti-bot, un filtrage de handshake, un rate limit par endpoint ou une couche spécialisée peut devenir nécessaire. Mais cette couche doit rester protégée contre le volume : si elle reçoit tout le bruit brut, elle devient elle-même la cible. Le bon modèle est donc souvent une combinaison : mitigation volumétrique en premier, puis filtrage applicatif quand le trafic arrive dans un état exploitable.

Transit IP protégé

Pour les préfixes, réseaux clients, hébergeurs, opérateurs et services qui veulent une entrée Anti-DDoS propre avec BGP.

Tunnel GRE/IPIP/VXLAN

Pour protéger un serveur ou un réseau déjà en place sans migration lourde, avec relivraison du trafic filtré.

Cross-connect

Pour une remise capacitaire et stable dans un datacenter, lorsque le design physique le permet.

Reverse proxy spécialisé

Pour les usages web, FiveM, Minecraft ou protocoles où le comportement applicatif doit être compris.

Hébergeur exposé et serveur de jeu populaire

Imaginons un hébergeur qui vend des VPS ou des serveurs dédiés à des communautés de jeu. Lors d’une attaque volumétrique, le problème principal n’est pas la machine du client : c’est la capacité amont. Le port se remplit, la file d’attente réseau se dégrade et les joueurs voient des timeouts. La bonne première réponse est de faire entrer le trafic dans un transit protégé, filtrer le flood et livrer un flux utilisable vers le réseau de l’hébergeur.

Maintenant, imaginons un serveur FiveM très visible. Le lien est protégé, mais certains joueurs restent bloqués au chargement parce que des bots abusent d’étapes précises du protocole. Ici, le problème n’est plus seulement la volumétrie. Une couche spécialisée peut analyser les comportements, réduire les faux positifs et éviter de casser le trafic légitime. Le reverse proxy ou la logique gaming a un intérêt, mais uniquement parce que la couche réseau protège déjà l’entrée.

Dans les deux cas, le client n’a pas besoin d’un discours généraliste. Il a besoin de savoir où l’attaque est absorbée, comment le trafic propre revient, ce qui est visible dans les logs et quelles actions sont possibles pendant l’incident. C’est cette lisibilité qui fait la différence entre une protection “présente sur le papier” et une mitigation réellement exploitable.

Erreurs fréquentes à éviter

• Acheter uniquement une promesse de capacité en Tbps sans vérifier le handoff, la latence, les ports, le PPS et le comportement en production.
• Croire qu’un WAF ou un reverse proxy applicatif peut sauver un service quand le lien réseau est déjà saturé.
• Croire qu’une protection volumétrique suffit contre des bots qui imitent un protocole ou abusent d’un endpoint précis.
• Oublier le retour du trafic : tunnel mal dimensionné, MTU non testé, routage asymétrique mal compris ou firewall stateful placé au mauvais endroit.
• Bloquer trop largement pendant une attaque et créer plus de faux positifs que l’attaque elle-même.
• Ne pas préparer de scénario d’urgence : qui annonce le préfixe, qui change le DNS, qui vérifie les logs, qui valide le retour à la normale.

FAQ : DDoS volumétrique et DDoS applicatif