EN FR Accueil

Sécurité d'un serveur NTP
Menaces, durcissement et comment le tester

NTP n'est pas authentifié par défaut et passe par UDP. Voici ce qui menace réellement un serveur de temps, comment le durcir, et comment vérifier le vôtre en quelques minutes.

Publié le 21 septembre 2026 · Sources vérifiées le 21 septembre 2026 · Par Richard DEMONGEOT, RDEM Systems · À propos de l'auteur

1. NTP, une surface d'attaque

NTP expose un serveur à deux titres. NTP n'est pas authentifié par défaut : un client ordinaire accepte ce que le serveur envoie, et un attaquant capable d'usurper la source peut décaler l'horloge d'une victime — ce qui casse la validité des certificats TLS, les fenêtres TOTP/MFA, Kerberos, et les horodatages dont dépend tout journal d'audit. Et NTP passe par UDP, ce qui le rend utilisable pour la réflexion/amplification contre un tiers : une petite requête usurpée provoque une grosse réponse vers la victime. Le cas classique est la commande monlist des vieux ntpd (CVE-2013-5211), amplifiant des centaines de fois.

2. Les menaces, concrètement

  • Amplification / réflexion — un serveur qui répond aux requêtes de contrôle héritées (mode 7 monlist, mode 6 readvar) renvoie bien plus qu'il ne reçoit. En usurpant la source, on en fait un réflecteur DDoS. C'est le seul contrôle que nous ne lançons que sur preuve de possession.
  • Décalage d'horloge — une manipulation on-path ou off-path déplace l'horloge d'un client de quelques secondes à plusieurs années. « Précis mais faux » est pire qu'une panne visible : cela invalide silencieusement certificats et jetons.
  • Kiss-o'-Death usurpé — un paquet KoD forgé dit à un client de se détourner d'une source légitime, vers un serveur de l'attaquant.
  • False ticker — une source dont l'heure contredit la majorité ; avec trop peu de sources, elle peut l'emporter (le fonctionnement de la sélection est traité sur notre site de diagnostic).
  • Panne silencieuse en stratum 16 — une source désynchronisée annonce stratum 16 ; sans supervision, l'exploitant croit que l'heure coule alors qu'elle est figée.
  • Pollution de pool — un serveur bénévole hostile injecté dans un pool public ; contré en choisissant des opérateurs connus et plusieurs sources indépendantes, pour que la sélection écarte la mauvaise. L'authentification prouve qui répond, pas que l'heure est juste.

3. Durcir un serveur de temps

  • Authentifier le canal avec NTS (RFC 8915) : clés établies par TLS, puis NTP authentifié. Cela déjoue l'usurpation pour les clients qui l'utilisent. chrony, ntpd-rs et NTPsec récents le gèrent.
  • Désactiver ou restreindre le contrôle hérité : couper les requêtes distantes mode 6/7 (chrony n'y répond pas du tout ; sur ntpd, restrict ... noquery et supprimer monlist). Ferme le vecteur d'amplification.
  • Limiter le débit et KoD : plafonner le débit par client pour que le serveur ne serve pas de réflecteur même s'il répond.
  • Plusieurs sources diversifiées et authentifiées (opérateurs et réseaux différents) : résilience face à un amont défaillant ou capturé. Les référentiels en recommandent au moins deux (ce que chacun exige vraiment).
  • Superviser offset, reach et strate, et alerter sur stratum 16 ou false ticker : une panne d'horloge doit être un événement détectable.

4. Comment tester votre serveur NTP

Le validateur de l'accueil interroge n'importe quel serveur public depuis notre côté et rend, en une mesure : sert-il du NTP non authentifié (strate, leap, aller-retour) ; le NTS fonctionne-t-il (poignée, identité TLS attestée pour le nom, jours restants du certificat) ; et sa traçabilité (identifiant de référence, strate, écart à notre référence avec l'incertitude).

Le contrôle de réflexion / amplification est celui qui pourrait être détourné contre un tiers : il n'est lancé que sur une adresse dont l'exploitant a prouvé le contrôle — un défi curl unique depuis le serveur lui-même, comme un défi HTTP Let's Encrypt. Prouvez-le une fois, et le rapport revient dans votre terminal :

$ curl -4 --interface 203.0.113.10 https://ntp.rdem-systems.com/verify/<jeton>
NTP validation for 203.0.113.10  (2026-09-21 10:20 UTC)
--------------------------------------------------------
ownership: proven for this address (source of your request matched)
NTS-KE: present (identity attested) - cert 56 d left
stratum 2 (refid 192.53.103.108) - offset vs our server +0.619 ms - leap 0
hardening: closed - no amplifying reply to a legacy control query (good)
--------------------------------------------------------
NTP works iff unauthenticated time is obtained; NTS iff authenticated time is.
The two verdicts are independent. Refid is the raw value the server announces.
One measurement from one vantage point - not an audit, not a certification.

Pour votre horloge plutôt qu'un serveur, utilisez ntp-tester.eu ; pour diagnostiquer pourquoi un démon ne se synchronise pas, check-ntp.net.

Questions fréquentes

Mon serveur NTP est-il un amplificateur ouvert ?

Il l'est s'il répond aux requêtes de contrôle héritées (mode 7 monlist, mode 6 readvar) par une réponse plus grosse que la requête, sans limitation de débit. chrony n'y répond jamais&nbsp;; un ntpd corrigé avec « restrict noquery » non plus. Notre validateur lance un contrôle de durcissement d'amplification, mais seulement sur une adresse dont l'exploitant prouve le contrôle.

Comment tester si mon serveur NTP est sécurisé ?

Vérifiez trois choses qu'un client normal voit — sert-il du NTP non authentifié, le NTS authentifie-t-il le canal, son heure est-elle traçable — et une qui demande une preuve de possession&nbsp;: amplifie-t-il une requête de contrôle héritée. Le validateur de notre accueil fait les quatre&nbsp;; le contrôle d'amplification exige un défi curl unique depuis le serveur.

NTP a-t-il besoin d'authentification ?

Aucune norme n'impose l'authentification NTP nommément, mais une source de temps non authentifiée peut être usurpée, et une heure usurpée casse certificats, MFA et journaux d'audit. NTS (RFC 8915) est la façon normalisée d'authentifier le canal, recommandée là où l'intégrité de l'heure compte.

Qu'est-ce que l'attaque par amplification monlist ?

monlist est une ancienne commande mode 7 de ntpd qui renvoie la liste des clients récents — une petite requête provoque une grosse réponse. En usurpant l'adresse de la victime, le serveur devient un réflecteur DDoS (CVE-2013-5211). Désactivez les requêtes distantes mode 6/7 et limitez le débit pour la fermer.