Qu'est-ce qu'un false ticker NTP ?

Un false ticker est une source NTP que le client a décidé de ne pas faire confiance car son temps reporté diverge de la majorité des autres sources configurées. RFC 5905 §11.2 (l'algorithme de sélection) le marque du préfixe 'x' dans ntpq -p, ou exclu du set sélectionné dans chronyc. Un false ticker ne contribue en rien à l'horloge combinée — il est effectivement ignoré jusqu'à ce qu'il s'accorde à nouveau.

Comment NTP décide-t-il quelle source est le false ticker ?

L'algorithme Marzullo-Mills prend l'intervalle de correction [offset − root_distance, offset + root_distance] de chaque source, et choisit le plus grand sous-ensemble qui se chevauche sur un point commun dans le temps. Les sources dans ce chevauchement sont des 'truechimers' ; les sources hors chevauchement sont des false tickers. L'algorithme fonctionne avec aussi peu que 3 sources mais ne devient robuste qu'à 4+ — avec moins, une seule source fausse peut voler la majorité.

Pourquoi une source NTP apparemment saine serait-elle marquée false ?

Quatre raisons courantes : (1) le serveur amont est réellement décalé de plusieurs secondes (mal configuré ou compromis), (2) l'asymétrie de chemin pousse l'offset mesuré hors de l'intervalle de correction des autres peers, (3) le peer reporte une root_distance gonflée qui rend son intervalle trop large pour chevaucher, (4) vous n'avez que 3 sources et une diverge — la sélection est en impasse. Notre page stratum-16 couvre le scénario d'impasse.

Comment identifier le false ticker sur chrony ?

Lancez 'chronyc sources'. Les colonnes 'M' (mode) et 'S' (état) vous disent : '*' = source de synchronisation actuelle, '+' = sélectionnée pour le combine, '-' = rejetée par l'algorithme de clustering, '?' = connectivité perdue, 'x' = falseticker, '~' = trop variable. Toute source avec 'x' est un false ticker. Vérifiez avec 'chronyc sourcestats' pour voir son offset vs la source sélectionnée.

Dois-je juste retirer le false ticker de ntp.conf ?

Retirer sans comprendre est dangereux — vous pourriez supprimer une source véridique et garder les menteurs. Lancez d'abord 'chronyc sourcestats' sur toutes les sources et comparez l'offset à une référence connue-bonne (ce validateur, time.cloudflare.com, ou une horloge GPS). Remplacez la source confirmée-fausse par une d'un opérateur et AS distincts. Ne tournez jamais NTP avec moins de 4 sources en production.

NTP False Ticker | Détecter & Corriger les Sources Temporelles Rejetées

Sommaire

1. Ce qu'est un false ticker (et ce qu'il n'est pas)
2. Comment Marzullo-Mills le marque
3. Décoder le préfixe « x » de ntpq et les états chronyc
4. Les 4 causes réelles
5. Confirmer quelle source est vraiment fausse
6. Remplacer sans créer une nouvelle impasse
7. Sécurité : quand un false ticker est une attaque

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 ~ ou marginal).
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.

Implication. Avec 4 peers vous tolérez 1 false ticker (3 truechimers outvote toujours). Avec 3 peers et 1 false ticker, vous êtes en impasse : 2/1 n'est pas décisif, et selon la disposition des intervalles, la sélection peut échouer entièrement — exactement le scénario qui produit stratum 16 avec sources joignables.

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 variable

4. 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.php

Comparez 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
rtcsync

7. 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.org et 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.

Défense. Déployez NTS (Network Time Security) sur chaque source authentifiable. Un attaquant ne peut pas forger un paquet NTS-AEAD sans le cookie — les attaques false-ticker deviennent impossibles côté client.

Après correction. Lancez le diagnostic en direct de ce validateur pour confirmer la sync restaurée. Mesurez le jitter sur le nouveau set de sources pour vous assurer que le remplaçant n'est pas lui-même jittery. Pour les environnements réglementés, produisez les preuves d'audit du déploiement NTS et de la diversification 4 sources.

Détection & Correction NTP False Ticker