Sécuriser NTP contre le spoofing et la dérive d’horloge

Une horloge système fausse ne produit pas seulement des journaux mal rangés. Elle invalide des certificats valides, casse des mécanismes d’authentification et rend une investigation incertaine au moment précis où chaque seconde compte. NTP (Network Time Protocol) doit donc être traité comme une dépendance de sécurité, pas comme un service de confort laissé à la configuration par défaut.

→ Lire l’explication complète de la marmotte

L’horloge système est une dépendance de confiance

Les protocoles de sécurité utilisent le temps pour borner une décision. Un certificat X.509 contient une période de validité, notBefore et notAfter. Une machine en avance rejettera un certificat qui n’est pas encore valable à son heure locale. Une machine en retard acceptera un certificat expiré, dans la limite de la dérive imposée. Le certificat reste cryptographiquement correct, mais la politique temporelle est évaluée sur une horloge corrompue.

TLS (Transport Layer Security) n’est pas seul concerné. Kerberos limite la réutilisation des tickets avec une tolérance d’horloge souvent réglée à cinq minutes. OAuth (Open Authorization) et OpenID Connect manipulent des jetons contenant des dates d’émission, d’expiration et parfois de début de validité. Une dérive peut provoquer des refus aléatoires, ou prolonger l’acceptation d’un jeton volé. Le symptôme ressemble volontiers à une panne d’identité. C’est plus vendeur de blâmer le fournisseur d’identité que de regarder l’heure, mais le réseau n’a aucune obligation de respecter les narratifs de comité.

La chaîne de confiance de la PKI et de TLS dépend donc d’une source temporelle fiable. Cette dépendance pose un compromis central : multiplier les sources réduit le risque qu’une source mente ou tombe, mais élargit la surface d’attaque et l’exposition réseau. La position à retenir est nette : utiliser au moins trois sources indépendantes pour les systèmes généralistes, les authentifier quand l’exposition le justifie, et isoler les clients des serveurs publics directs par des relais internes durcis.

Une précision nécessaire : NTP ne rend pas le temps exact. Il estime l’écart entre l’horloge locale et plusieurs références, avec une incertitude influencée par la latence, son asymétrie et la qualité de l’oscillateur local. Exiger une précision absolue sur un réseau IP revient à demander à un pigeon voyageur de remplir un registre d’audit. Pour les besoins industriels ou de trading à très faible latence, PTP (Precision Time Protocol), des horloges matérielles et une architecture dédiée deviennent nécessaires. Ce n’est pas le même problème.

Corrélation des logs et chronologie d’incident

Un journal horodaté sans horloge maîtrisée ne permet pas d’établir une séquence fiable. Un pare-feu peut consigner une connexion à 10:00:03, le serveur cible son authentification à 09:59:51, et le collecteur central recevoir les deux événements à 10:00:07. Sans mesure de dérive, l’investigation invente un ordre causal qui n’existe peut-être pas.

La règle opérationnelle est de journaliser les horodatages en UTC (Coordinated Universal Time), avec une précision explicite, et de superviser l’écart de chaque hôte. UTC élimine les ambiguïtés de fuseau horaire et de changement d’heure, pas les dérives. Les formats doivent conserver le décalage ou employer UTC explicitement, par exemple RFC 3339. Un champ timestamp sans zone temporelle est une dette technique déguisée en chaîne de caractères.

La centralisation ne corrige pas l’heure à la source. Un SIEM (Security Information and Event Management) peut ordonner les événements selon l’heure de réception, mais cela masque les délais de transport et d’ingestion. Il faut conserver à la fois l’heure émise par la source et l’heure reçue par le collecteur. L’écart entre les deux devient un signal d’intégrité et de disponibilité, pas une colonne décorative destinée à faire respirer un tableau de bord.

Les investigations décrites dans une architecture cyber reposent sur cette discipline : attribution des actions, reconstruction de session, détection de déplacement latéral, comparaison entre authentifications et modifications de privilèges. Sans temps cohérent, la corrélation perd son sens. Une signature cryptographique de journal peut démontrer qu’une ligne n’a pas changé après émission ; elle ne démontre pas que son horodatage était juste. Il faut les deux.

Spoofing NTP, retards artificiels et sources malveillantes

Le NTP classique échange des messages UDP (User Datagram Protocol), généralement sur le port 123. Sans authentification, un attaquant capable d’injecter, de rediriger ou de modifier le trafic peut envoyer une réponse paraissant provenir d’un serveur de temps. C’est le spoofing NTP : la cible accepte une heure manipulée parce que l’adresse source et les champs du protocole semblent plausibles.

L’attaque ne vise pas forcément un saut spectaculaire de plusieurs années. Les implémentations modernes filtrent souvent les corrections aberrantes, et un saut brutal déclenche des alertes quand elles existent. Une dérive progressive, compatible avec les seuils de sélection, est plus discrète. Elle peut rendre un certificat prématurément invalide, créer une fenêtre de réutilisation de jeton ou désordonner des preuves. Une attaque élégante ne fait pas toujours exploser le serveur, hélas.

L’asymétrie de délai est un autre problème. Un adversaire qui retarde seulement les paquets dans un sens peut biaiser l’estimation du temps sans falsifier tous les messages. L’authentification protège l’intégrité et l’origine du paquet, pas la disponibilité ni la latence du chemin. NTP authentifié n’empêche donc pas un homme du milieu de faire attendre les paquets, de les supprimer ou de provoquer un déni de service.

NTS (Network Time Security) est le choix à privilégier pour les clients synchronisés sur des services externes. NTS protège les échanges NTP par des cookies chiffrés et authentifiés, obtenus via NTS-KE (Network Time Security Key Establishment), qui s’appuie sur TLS. Les anciennes clés symétriques NTP restent acceptables entre quelques serveurs internes administrés, mais elles imposent une distribution, une rotation et une protection de secrets qui vieillissent mal à grande échelle. Une clé partagée entre cent clients ne devient pas une architecture parce qu’elle est rangée dans un coffre-fort numérique.

NTS ne résout pas le problème d’amorçage. La validation du certificat TLS du serveur de temps exige déjà une date approximativement crédible. Une RTC (Real-Time Clock), horloge matérielle locale, doit donc être maintenue, avec batterie surveillée sur les matériels concernés. Après une perte totale d’alimentation ou une image virtuelle restaurée, l’horloge peut être suffisamment erronée pour empêcher NTS de démarrer. Prévoir une source de démarrage contrôlée, une correction initiale auditée et des alertes de dérive excessive.

Architecture NTP durcie et conditions de confiance

La topologie recommandée sépare les rôles. Quelques serveurs de temps internes reçoivent des références externes authentifiées et indépendantes. Les postes, serveurs applicatifs et équipements réseau interrogent uniquement ces relais internes. Les relais sont surveillés, durcis et placés dans des zones réseau distinctes lorsque l’architecture le permet. Exposer tous les hôtes aux pools publics transforme une dépendance commune en trafic diffus impossible à gouverner.

Une source indépendante signifie des opérateurs, réseaux et mécanismes distincts. Trois noms DNS qui aboutissent au même fournisseur ou au même réseau ne constituent pas trois avis. Pour les environnements à forte exigence, ajouter une référence locale, par exemple un récepteur GNSS (Global Navigation Satellite System) protégé contre le brouillage et le spoofing, apporte de la résilience mais introduit une surface physique et radio. Une antenne GPS (Global Positioning System) sur un toit n’est pas une racine de confiance tombée du ciel, même si les slides aiment le laisser croire.

Les serveurs internes doivent refuser les requêtes hors des sous-réseaux attendus, ne jamais agir comme relais ouverts et désactiver les fonctions de diagnostic inutiles. Les équipements NTP historiques ont participé à des attaques par amplification : une petite requête provoquait une réponse beaucoup plus grande vers une victime usurpée. Les commandes de contrôle et les implémentations anciennes doivent être inventoriées, mises à jour et filtrées. Autoriser UDP/123 depuis Internet vers un serveur interne sans nécessité documentée est une erreur d’architecture, pas une tolérance opérationnelle.

L’algorithme de sélection doit exiger plusieurs sources lorsque le service le permet. Une seule source rend sa compromission immédiatement décisive. En revanche, imposer trois sources sur un site isolé qui n’en possède qu’une rend la synchronisation indisponible. Le bon seuil dépend de la tolérance à la dérive et de la criticité : refuser l’heure en cas de désaccord est préférable pour une autorité de certification, moins acceptable pour un capteur autonome dont la télémétrie devra être marquée comme incertaine.

Configuration Chrony avec NTS

Chrony est généralement préférable à ntpd sur les systèmes Linux modernes : il converge mieux après une longue indisponibilité, gère les hôtes intermittents et expose des métriques exploitables. Cette recommandation suppose Chrony 4.x avec prise en charge NTS, OpenSSL ou une bibliothèque TLS équivalente, une RTC fonctionnelle et une résolution DNS disponible au démarrage.

L’exemple suivant configure un client Linux utilisant plusieurs associations NTS. Les noms retenus doivent être validés selon les fournisseurs autorisés par la politique d’architecture. Le fichier se place généralement dans /etc/chrony/chrony.conf ou /etc/chrony.conf selon la distribution.

# Exiger plusieurs sources, sinon ne pas déclarer l'horloge synchronisée.
minsources 2

# Sélectionner uniquement des sources dont l'authentification est vérifiée.
authselectmode require

# Établir les associations NTS via TLS avec des sources distinctes.
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts

# Corriger vite au démarrage, puis éviter les sauts d'horloge prolongés.
makestep 1.0 3

# Maintenir la RTC alignée une fois la synchronisation acquise.
rtcsync

Après redémarrage, vérifier la sélection et l’authentification :

# Vérifier les sources et rechercher le marqueur NTS dans les détails.
chronyc -N sources -v
chronyc -N ntpdata

# Vérifier l'écart estimé, la synchronisation et le serveur de référence.
timedatectl status
chronyc tracking

Un état Leap status : Not synchronised, une source injoignable ou un écart qui augmente doivent déclencher une alerte. Superviser au minimum : nombre de sources sélectionnables, offset, dispersion, âge de la dernière mesure, changement de source et état NTS. L’offset acceptable dépend du protocole le plus strict de l’environnement. Si Kerberos tolère cinq minutes, alerter à quatre minutes serait une supervision décorative ; alerter bien avant le seuil laisse le temps de réparer.

Exploitation, rotation et reprise après incident

Les secrets NTS côté client sont principalement des cookies de session renouvelables. Côté serveur, protéger les clés de signature et le certificat TLS associé au service NTS-KE. Ces éléments suivent les mêmes règles que les autres clés privées de service : stockage protégé, accès minimal, rotation planifiée, sauvegarde chiffrée et procédure de restauration testée. Un HSM (Hardware Security Module) peut protéger une clé de serveur si le débit et l’intégration le justifient, mais il ne corrige ni une mauvaise source de temps ni une règle de pare-feu absurde.

Pour les associations NTP à clé symétrique, employer une clé distincte par client ou par groupe réduit le rayon d’explosion d’une fuite. Une clé unique distribuée partout interdit une révocation ciblée. La rotation doit accepter une période de chevauchement avec ancienne et nouvelle clé, puis supprimer explicitement l’ancienne. Sans inventaire des consommateurs, la rotation devient une chasse au trésor dont le lot est un incident d’authentification.

Les sauvegardes d’images virtuelles et les restaurations sont un piège fréquent. Restaurer une machine depuis un instant ancien peut réintroduire une horloge reculée, des cookies expirés et des journaux dont la chronologie ne correspond plus au monde extérieur. Au redémarrage, empêcher les services sensibles de déclarer leur disponibilité avant synchronisation. Les bases de données distribuées, les autorités de certification et les systèmes d’identité méritent une dépendance explicite à l’état de temps, pas une confiance optimiste dans le premier paquet UDP reçu.

NTP ne garantit ni l’intégrité des logs, ni la disponibilité du réseau, ni la sécurité d’une identité compromise. Il fournit une référence temporelle avec un niveau de confiance défini. L’intégrité des journaux exige aussi contrôle d’accès, transport chiffré, conservation protégée et éventuellement scellement cryptographique. La disponibilité exige redondance réseau et surveillance. La sécurité des certificats exige une PKI correctement exploitée. Une horloge correcte ne sauve pas une architecture bancale, mais une horloge incorrecte peut faire mentir une architecture pourtant bien conçue.

🐝 Ce qui arrive si on s’en passe

Sans source de temps authentifiée et supervisée, une horloge reculée rend de nouveau « fraîches » des réponses OCSP et des listes de révocation périmées : un certificat révoqué repasse le contrôle si la réponse rejouée date d’avant sa révocation. Les signatures DNSSEC, bornées par des dates d’inception et d’expiration, subissent le même effet : des enregistrements anciens, capturés puis rejoués, redeviennent valides, tandis qu’une horloge en avance fait échouer la résolution de zones saines. Les codes TOTP d’authentification à deux facteurs, calculés sur l’heure courante, cessent de correspondre ou prolongent la validité d’un code intercepté. Une horloge poussée vers l’avant déclenche aussi prématurément les purges de rétention et la rotation des journaux : les traces supprimées avant l’échéance réelle ne peuvent plus servir à l’investigation.

🦫 Explication de la marmotte 🍫

Chaque machine possède une horloge interne qui avance toute seule. Elle dérive avec le temps, surtout après une coupure, une restauration de sauvegarde ou un défaut matériel. Pour éviter cela, elle demande régulièrement l’heure à des serveurs sur le réseau. Elle compare plusieurs réponses, mesure le temps de trajet et ajuste progressivement son horloge.

Cette heure sert à vérifier des règles de sécurité. Un certificat indique à partir de quand et jusqu’à quand il est accepté. Un ticket de connexion et un jeton d’accès ont aussi une durée limitée. Si l’horloge locale est trop en avance, la machine refuse des éléments pourtant valides. Si elle est trop en retard, elle peut accepter des éléments déjà expirés. Les journaux d’activité deviennent aussi difficiles à comparer : deux machines peuvent enregistrer le même événement dans un ordre différent.

Un attaquant peut essayer d’envoyer de fausses réponses d’heure ou de retarder les vraies réponses. La machine ajuste alors son horloge vers une mauvaise valeur. Pour réduire ce risque, les réponses doivent provenir de plusieurs sources et être protégées par une preuve cryptographique. Les machines internes interrogent de préférence des serveurs de temps internes contrôlés, eux-mêmes reliés à plusieurs sources externes.

Si la synchronisation échoue, les services sensibles ne doivent pas prétendre fonctionner normalement. Il faut surveiller l’écart d’horloge, l’état des sources et la date de la dernière synchronisation.

Pages voisines

La citent

Sécuriser NTP contre le spoofing et la dérive d’horloge

Elle cite

: les deux pages se citent l’une l’autre.

Sécuriser NTP contre le spoofing et la dérive d’horloge

Sécuriser NTP contre le spoofing et la dérive d’horloge

L’horloge système est une dépendance de confiance

Corrélation des logs et chronologie d’incident

Spoofing NTP, retards artificiels et sources malveillantes

Architecture NTP durcie et conditions de confiance

Configuration Chrony avec NTS

Exploitation, rotation et reprise après incident

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines