Guide DDoSPublié le 06/05/2026Temps de lecture : 14 min
Protection contre une attaque NTP amplification : comment mitiger ce DDoS
Une amplification NTP transforme de petites requêtes usurpées en réponses UDP beaucoup plus lourdes vers votre IP. Voici comment filtrer sans casser le trafic légitime.
Trafic UDP réfléchi
La cible reçoit des réponses qu’elle n’a jamais demandées.
Filtrage avant saturation
La mitigation doit agir en amont ou sur l’edge protégé.
Relivraison propre
Le trafic légitime doit continuer à atteindre l’origine.
L’amplification NTP est un vecteur DDoS réfléchi : l’attaquant usurpe l’adresse IP de la victime, envoie des requêtes vers des serveurs NTP exposés, puis laisse ces serveurs répondre à la cible. La victime n’a pas besoin d’exploiter elle-même un service NTP pour être attaquée ; elle reçoit simplement des réponses amplifiées. Pour un hébergeur, un client en transit protégé, un serveur dédié ou un réseau gaming, l’impact se voit souvent d’abord sur la capacité, les files de paquets et la latence.
La bonne protection n’est pas un blocage UDP global. NTP reste un trafic légitime pour la synchronisation horaire. L’objectif est d’identifier les réponses NTP non sollicitées, de les retirer avant qu’elles ne saturent l’edge client, puis de conserver un chemin propre pour le web, TCP, les jeux UDP et l’administration.
Impact commercial
Protection contre une attaque NTP amplification
Une amplification NTP transforme de petites requêtes usurpées en réponses UDP beaucoup plus lourdes vers votre IP. Voici comment filtrer sans casser le trafic légitime.
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.
Le détail important est le contexte : un compteur de paquets isolé ne suffit pas. La mitigation doit savoir si le service protégé attend normalement ce protocole, dans quel sens et à quel rythme.
Trafic UDP réfléchi
La cible reçoit des réponses qu’elle n’a jamais demandées.
Filtrage avant saturation
La mitigation doit agir en amont ou sur l’edge protégé.
Relivraison propre
Le trafic légitime doit continuer à atteindre l’origine.
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.
C’est aussi un sujet commercial pour l’hébergement et le gaming. Les clients ne jugent pas l’incident par le nom du vecteur ; ils jugent surtout si leur service est resté joignable.
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.
Une configuration pratique prépare des règles d’urgence, mais conserve aussi des bases de référence. Tailles de paquets, ports, pays et ratios protocolaire permettent de filtrer vite sans bloquer à l’aveugle.
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.
Peeryx peut donc combiner un soulagement amont grossier avec des décisions edge plus précises. L’objectif est de réduire la pression vite, puis d’affiner pour préserver les sessions légitimes.
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.
Pendant l’incident, le bon tableau de bord n’est pas seulement un graphe de trafic bloqué. Il faut aussi observer le trafic accepté, la latence, l’état des tunnels et les symptômes utilisateurs.
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.
Dernière erreur : appliquer le même modèle à tous les clients. Un client BGP, un serveur dédié et un proxy de jeu n’exposent pas les mêmes services et ne tolèrent pas les mêmes faux positifs.
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.
