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.
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.
La cible reçoit des réponses qu’elle n’a jamais demandées.
La mitigation doit agir en amont ou sur l’edge protégé.
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.
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.
Une amplification NTP exploite des serveurs de temps exposés. L’attaquant usurpe l’adresse de la victime et provoque des réponses UDP/123 qui reviennent vers elle, parfois depuis de nombreux serveurs réels.
Même si les anciens abus de type monlist sont aujourd’hui mieux connus, le principe reste dangereux : la cible reçoit des réponses qu’elle n’a jamais demandées. Le filtrage doit donc vérifier le sens du flux et le contexte de la destination.
La cible reçoit des réponses qu’elle n’a jamais demandées.
La mitigation doit agir en amont ou sur l’edge protégé.
Le trafic légitime doit continuer à atteindre l’origine.
NTP paraît secondaire, mais une vague UDP/123 peut saturer un port, augmenter les pertes et rendre instables des services sans lien direct avec l’heure. Pour un serveur de jeu ou une offre dédiée, le client voit surtout des timeouts.
Les environnements réseau sérieux dépendent aussi d’une horloge correcte pour logs, supervision, TLS et corrélation d’incident. Il ne faut donc pas confondre protection contre l’abus NTP et blocage aveugle de tous les usages temporels légitimes.
La mesure la plus propre consiste à ne pas exposer de vieux serveurs NTP permissifs et à limiter l’accès aux services internes. Mais la victime ne contrôle pas toujours les serveurs utilisés comme réflecteurs.
Côté cible, la mitigation doit filtrer les réponses UDP/123 inattendues en amont, contrôler les tailles, les ports source/destination et réduire les vagues avant que le lien client ne soit rempli.
Peeryx traite NTP amplification comme un vecteur UDP identifiable. Quand le client ne fournit pas de service NTP public, les règles peuvent être strictes et rapides ; si NTP est utile, elles sont contextualisées.
Le trafic nettoyé peut ensuite être livré par BGP, GRE/IPIP/VXLAN, cross-connect ou VM routeur. Pour les services gaming, l’objectif est que le bruit NTP soit supprimé avant d’impacter la latence joueur.
Imaginez un serveur dédié hébergeant une communauté FiveM. Le serveur n’utilise pas NTP publiquement, mais son IP reçoit une vague UDP/123. Le firewall local voit arriver des paquets inutiles pendant que les joueurs perdent la connexion.
Avec Peeryx, cette vague est traitée avant le chemin client. Les réponses NTP incohérentes sont retirées, puis le trafic nécessaire au jeu ou à l’administration est relivré normalement avec une observation claire du volume bloqué.
La première erreur est de répondre uniquement côté serveur. Si le port ou le tunnel est saturé, la règle locale ne reçoit déjà plus le trafic utile. La deuxième est de bloquer sans regarder les services réellement exposés.
Une autre erreur est de ne pas surveiller les paquets par seconde. Une attaque NTP peut gêner par le volume, mais aussi par le nombre de paquets et les files d’attente qu’elle provoque sur les équipements.
Peeryx est pertinent lorsque l’IP publique doit rester joignable malgré un vecteur UDP/123 : transit IP protégé, serveur dédié, tunnel vers infrastructure existante ou protection gaming.
L’avantage vient de la combinaison entre capacité amont, règles précises et relivraison propre. Le client ne dépend pas d’un simple firewall local placé après le point de saturation.
Oui. L’attaque abuse de serveurs NTP tiers ; la cible reçoit des réponses volumineuses sans héberger elle-même NTP.
Non. Le sujet n’est pas de couper UDP partout, mais de bloquer les signatures, tailles et sources incompatibles avec un usage légitime.
Le filtrage doit se faire avant que l’attaque NTP ne remplisse le port ou le tunnel de relivraison.
Oui. Peeryx peut protéger le service exposé et renvoyer uniquement le trafic utile vers l’infrastructure existante.
Une attaque NTP amplification se reconnaît par son vecteur : du trafic UDP/123 réfléchi, souvent sans rapport avec le service réellement hébergé par la victime.
La protection efficace consiste à réduire ce flux en amont, garder les vrais usages temporels si nécessaire et relivrer le trafic propre sans ajouter de latence inutile.
Peeryx peut filtrer les vagues NTP amplification avant votre serveur et relivrer le trafic propre vers votre réseau, serveur dédié ou service gaming.