Détection & Correction NTP False Ticker
Identifier la source fautive, la remplacer, garder la majorité véridique
1. Ce qu'est un false ticker (et ce qu'il n'est pas)
Dans le jargon NTP, un truechimer est une source dont le temps reporté s'accorde avec la majorité des autres sources dans la tolérance de correction du protocole. Un false ticker est une source qui diverge — soit parce qu'elle est fausse, soit parce que le chemin est si asymétrique que la mesure ment sur elle.
Ce qu'un false ticker N'EST PAS :
- Une source à jitter élevé — c'est une source peu fiable mais potentiellement correcte (taguée
~oumarginal). - Une source à stratum élevé — stratum mesure juste la distance à la référence atomique, pas la correction.
- Une source à reach 0 — c'est injoignable, pas faux ; aucune mesure n'a eu lieu.
2. Comment Marzullo-Mills le marque
Pour chaque peer, NTP construit un intervalle de correction : [offset − root_distance, offset + root_distance] où root_distance = root_delay/2 + root_dispersion. Cet intervalle exprime « le temps vrai est quelque part dedans, et je suis au moins aussi large à son sujet ».
L'algorithme Marzullo-Mills (RFC 5905 §11.2.1) trouve le plus grand sous-ensemble de peers dont les intervalles partagent un point commun. Les peers dans cette intersection sont des truechimers ; les peers hors intersection sont des false tickers.
3. Décoder le préfixe « x » de ntpq et les états chronyc
ntpq préfixe chaque peer d'un flag d'état 1 caractère. Ceux pertinents pour le diagnostic false-ticker :
| Préfixe ntpq | Signification |
|---|---|
* | System peer — la source sélectionnée |
+ | Candidat — dans le set combine |
- | Outlyer — rejeté par l'algorithme de clustering |
x | False ticker — rejeté par intersection |
. | Rejet « too-many-survivors » |
# | Bon mais non utilisé (trop de candidats) |
(espace) | Rejet (injoignable, mauvaise cohérence, stratum élevé) |
chronyc utilise deux colonnes : M (mode : ^ serveur, = peer) et S (état) :
MS Name/IP address
^* ntp.rdem-systems.com sync, source actuelle
^+ time.cloudflare.com combinée
^- time.google.com rejetée par cluster
^x rogue-server.example.com FALSE TICKER
^? down-server.example.com connectivité perdue
^~ jittery.example.com trop variable4. Les 4 causes réelles
Cause A — le serveur amont est réellement décalé
La cause la plus courante. Un Stratum 2 dont l'amont est passé en stratum 16, un serveur sous systemd-timesyncd sans backup, un membre de pool avec GPS cassé — tous peuvent produire des secondes d'offset réel. Vérifiez le chronyc tracking / ntpq -c rv propre à la source côté opérateur, ou interrogez-la depuis un point de vue indépendant avec ntpdate -q.
Cause B — chemin asymétrique
Si le chemin vers un peer passe par un tunnel (IPsec, VPN, GRE) alors que les autres peers sont directs, les latences aller simples sont radicalement différentes. NTP suppose la symétrie ; l'asymétrie apparaît comme offset et peut faire passer une source par ailleurs correcte pour un menteur.
Cause C — root distance gonflée
Un peer qui reporte un root_delay ou root_dispersion élevé a un intervalle de correction large. Si son offset est proche du correct mais son intervalle est plus large que le chevauchement des autres, Marzullo-Mills peut quand même l'exclure par sécurité (il ne peut pas affiner le chevauchement, donc est rejeté comme non-contributif).
Cause D — nombre de peers insuffisant
Avec seulement 3 peers, tout désaccord réel crée une division paire. Deux peers d'accord ne suffisent pas à Marzullo-Mills pour sereinement écarter le troisième — donc les trois peuvent finir marqués ou la sélection échoue entièrement. Correctif : configurez toujours 4+ peers en production.
5. Confirmer quelle source est vraiment fausse
Avant d'éditer ntp.conf, confirmez qui dit la vérité.
# Obtenir les offsets pour chaque source configurée
$ chronyc sourcestats -v
# Interroger chaque source indépendamment
$ for s in ntp.rdem-systems.com time.cloudflare.com ntp1.ptb.de suspect.example.com; do
echo -n "$s: "
ntpdate -q "$s" 2>&1 | grep offset
done
# Recouper contre ce validateur en direct
$ curl -s https://ntp.rdem-systems.com/time-api.phpComparez les offsets. Celui qui diverge est votre false ticker.
6. Remplacer sans créer une nouvelle impasse
Une fois identifié :
- Ne retirez pas simplement le peer — remplacez-le. Vous voulez 4+ peers actifs à tout moment.
- Choisissez un remplaçant sur un opérateur et ASN différents de vos autres peers. Voir nos combinaisons dual-opérateur.
- Préférez des sources authentifiées NTS quand disponibles — elles empêchent un attaquant man-in-the-middle de transformer un truechimer en false ticker.
- Après rechargement de chrony/ntpd, attendez 4–8 intervalles de poll (~5–15 min) pour que le nouveau peer atteigne 377 et que la sélection se stabilise.
# Exemple chrony.conf avec 4 sources diversifiées (3 NTS, 1 pool)
server ntp.rdem-systems.com iburst nts # FR, AS206014
server time.cloudflare.com iburst nts # anycast
server nts.netnod.se iburst nts # SE, Netnod
pool 2.pool.ntp.org iburst
makestep 1.0 3
rtcsync7. Sécurité : quand un false ticker est une attaque
Sans NTS, UDP 123 n'est pas authentifié. Un attaquant sur le chemin peut :
- Répondre plus vite que le serveur légitime et gagner la course,
- Injecter des réponses forgées sous l'IP du serveur,
- Empoisonner le résultat DNS
pool.ntp.orget substituer un serveur fautif.
Signes qu'un false ticker est une attaque plutôt qu'un bug :
- L'offset « faux » est dans la direction des certificats TLS expirés (futur) ou des tickets Kerberos expirés (passé).
- La source fautive est un entry du pool et change chaque minute.
- L'IP source de réponse apparaît légitime mais le TTL ou le routage diffère.
Après correction — sites liés :
- Mesurer jitter, offset, latence → ntp-tester.eu
- Preuves d'audit NIS 2 / ISO 27001 → online-ntp-validator.com
- Déploiement NTS entreprise → ntp.rdem-systems.com/nts