Guide architecture DDoSPublié le 6 mai 2026Lecture : 15 min
Attaque DDoS par amplification : comprendre pourquoi de petites requêtes deviennent un flood massif
Une attaque DDoS par amplification utilise des services tiers pour transformer de petites requêtes usurpées en réponses beaucoup plus volumineuses envoyées à la victime. La cible ne reçoit pas seulement du trafic de l’attaquant. Elle reçoit du trafic réfléchi depuis de nombreux serveurs légitimes sur Internet, souvent via des protocoles UDP. Comprendre l’amplification est indispensable avant de choisir un transit protégé, un scrubbing ou un proxy gaming.
La réflexion crée le flood
Des serveurs tiers répondent à la victime à cause de l’adresse source spoofée.
L’amplification augmente le volume
De petites requêtes peuvent générer des réponses plus grandes.
UDP est souvent abusé
Les protocoles sans connexion se reflètent plus facilement si le spoofing passe.
Le filtrage amont compte
Il faut réduire l’attaque avant la saturation du lien client.
Une attaque DDoS par amplification est dangereuse parce que l’attaquant n’a pas besoin d’envoyer directement tout le volume vers la cible. Il envoie de petites requêtes avec une adresse source usurpée à des services tiers. Ces services répondent à la victime, et les réponses sont plus grosses que les requêtes. La cible reçoit donc un flood qui semble venir de nombreux serveurs légitimes d’Internet.
C’est pour cela que les attaques par amplification saturent souvent le transit, les ports et les équipements amont avant que l’application ne soit le vrai goulot. La bonne mitigation doit réduire le trafic réfléchi près de l’entrée réseau, éviter qu’il n’atteigne les équipements stateful et conserver un chemin propre pour les vrais utilisateurs, clients et joueurs.
Impact commercial
Attaque DDoS par amplification
Une attaque DDoS par amplification utilise des services tiers pour transformer de petites requêtes usurpées en réponses beaucoup plus volumineuses envoyées à la victime. La cible ne reçoit pas seulement du trafic de l’attaquant. Elle reçoit du trafic réfléchi depuis de nombreux serveurs légitimes sur Internet, souvent via des protocoles UDP. Comprendre l’amplification est indispensable avant de choisir un transit protégé, un scrubbing ou un proxy gaming.
Le modèle technique est simple mais destructeur : des réponses UDP non sollicitées arrivent vers la victime alors que l’origine ne les a jamais demandées. Les règles placées uniquement sur le serveur voient le flood final, pas la chaîne de réflecteurs qui l’a produit.
Comme les paquets peuvent venir de vrais serveurs Internet, une liste de blocage naïve évolue lentement et crée du dégât collatéral. Le signal utile se trouve dans le comportement protocolaire, le sens du trafic, les ports attendus, le rythme, l’entropie et le fait que le service protégé ait réellement demandé ces réponses.
La réflexion crée le flood
Des serveurs tiers répondent à la victime à cause de l’adresse source spoofée.
L’amplification augmente le volume
De petites requêtes peuvent générer des réponses plus grandes.
UDP est souvent abusé
Les protocoles sans connexion se reflètent plus facilement si le spoofing passe.
Pourquoi c’est important
C’est important commercialement, car la coupure est visible pour les clients avant que la cause soit claire. Un serveur dédié peut afficher peu de CPU alors que les joueurs, clients ou pairs BGP voient de la perte et des timeouts.
Pour un client en transit protégé, le mode de livraison compte aussi. GRE, IPIP, VXLAN, cross-connect et VM routeur doivent être dimensionnés et filtrés pour que le trafic réfléchi soit retiré avant de brûler le chemin propre.
Les solutions possibles
La première couche est la capacité : les transitaires et ports de filtrage doivent absorber l’attaque pendant que le moteur de décision classe le vecteur. La deuxième couche est le filtrage adapté au protocole, qui retire les réponses impossibles, les charges anormales et le trafic qui ne correspond pas au profil attendu.
FlowSpec, ACL et filtrage edge peuvent réduire le volume rapidement, mais les règles doivent rester précises et temporaires. Un firewall stateful sur l’origine n’est pas la bonne première ligne quand l’attaque consomme déjà la capacité ou les paquets par seconde.
Peeryx cherche à retirer le trafic sale avant qu’il arrive côté client. Pour les clients BGP, le préfixe protégé peut être annoncé via la couche de mitigation ; pour des serveurs existants, le trafic propre peut être livré par tunnel, cross-connect ou VM routeur.
Pour les services gaming, le même principe s’applique avec le reverse proxy : le chemin joueur reste joignable pendant que le trafic d’attaque est filtré sur l’edge Peeryx, au lieu d’être transféré aveuglément vers l’origine.
Cas concret d’utilisation
Imaginez une communauté de jeu hébergée sur un serveur dédié. Le serveur est en ligne, mais l’IP publique reçoit un flood UDP réfléchi. Les joueurs voient des timeouts, la voix devient instable et le panel hébergeur n’affiche parfois qu’une saturation de bande passante.
Avec une relivraison protégée, l’IP ou le service attaqué passe par un point de mitigation. La plateforme filtre le vecteur réfléchi, conserve les vraies sessions TCP/UDP et transmet uniquement le trafic propre vers la machine existante.
Erreurs fréquentes
La première erreur est de bloquer tout UDP. Cela peut casser les jeux, DNS, monitoring et flux d’infrastructure légitimes. La deuxième erreur est d’attendre du serveur d’origine qu’il règle un problème de saturation réseau.
Autre erreur fréquente : compter uniquement sur des limites de débit génériques. Elles peuvent réduire un graphe, mais aussi pénaliser les vrais utilisateurs quand le service a besoin de pics ou quand l’attaquant reste juste sous le seuil.
Pourquoi choisir Peeryx pour ce risque DDoS
Si votre infrastructure dépend de TCP, UDP, DNS ou de trafic de jeu, Peeryx peut placer une couche réseau protégée devant elle et relivrer le trafic propre par tunnel, cross-connect, VM routeur ou reverse proxy gaming.
Transit IP protégé pour les clients qui ont besoin de BGP, tunnels ou cross-connect.
Protection de serveur dédié pour les services qui doivent rester sur leurs machines actuelles.
Reverse proxy gaming pour FiveM, Minecraft et communautés fortement UDP.
Filtrage adapté au protocole plutôt que promesses vagues “DDoS illimité”.
FAQ
Peut-on être touché sans utiliser ce service ?
Oui. Une attaque réfléchie envoie les réponses vers l’IP victime, même si la cible n’héberge pas le protocole abusé.
Bloquer UDP suffit-il ?
Non. Certains services ont besoin d’UDP. La mitigation doit séparer le trafic réfléchi malveillant du trafic légitime.
Où faut-il filtrer ?
Le plus en amont possible, avant que l’attaque ne sature le lien client, le tunnel ou le firewall.
Peeryx peut-il protéger un serveur existant ?
Oui. Le trafic propre peut être livré à une infrastructure existante par tunnel, cross-connect, VM routeur ou reverse proxy selon le service.
Conclusion
Si votre infrastructure dépend de TCP, UDP, DNS ou de trafic de jeu, Peeryx peut placer une couche réseau protégée devant elle et relivrer le trafic propre par tunnel, cross-connect, VM routeur ou reverse proxy gaming.
Le bon objectif n’est pas seulement de survivre au graphe, mais de garder les utilisateurs légitimes joignables pendant que l’attaque est absorbée et filtrée.
Ressources
Lectures liées
Pour approfondir le sujet, voici d’autres pages et articles utiles.
Réduire ce vecteur avant qu’il atteigne votre serveur
Si votre infrastructure dépend de TCP, UDP, DNS ou de trafic de jeu, Peeryx peut placer une couche réseau protégée devant elle et relivrer le trafic propre par tunnel, cross-connect, VM routeur ou reverse proxy gaming.
