Synchroniser l'heure

La menace : chaque contrôle suppose en silence que l'horloge est juste

L'heure n'est pas un contrôle de sécurité en soi, mais presque tous les contrôles de sécurité supposent silencieusement que l'horloge est juste. Laissée sans synchronisation, une horloge système dérive : les oscillateurs à quartz perdent ou gagnent quelques secondes par jour, et les machines virtuelles dérivent bien plus après une migration ou une mise en pause de l'hôte. Les conséquences frappent là où un incident fait le plus mal :

• L'analyse forensique devient peu fiable. Quand vous recoupez les journaux d'une dizaine d'hôtes pour reconstituer une attaque, des horodatages décalés brouillent l'ordre des événements. Quelques minutes de dérive peuvent masquer le vrai point d'entrée ou faire croire qu'une réponse a eu lieu avant la compromission.
• L'authentification casse. Kerberos rejette les tickets dès que l'horloge dépasse sa tolérance (typiquement 5 minutes), et TLS valide les certificats contre les fenêtres notBefore/notAfter : une horloge fausse accepte un certificat expiré ou en rejette un valide.
• Un attaquant peut l'instrumentaliser. Manipuler l'horloge peut remettre des certificats expirés dans leur fenêtre de validité, rejouer des jetons à durée limitée, ou étaler une intrusion sur les chronologies de journaux pour déjouer la corrélation. Une source NTP malveillante ou usurpée est un vecteur d'attaque réel, d'où l'importance d'une heure authentifiée.

Pourquoi le durcir

Une heure juste est un prérequis pour faire confiance à tout le reste. Votre piste d'audit, votre chaîne de certificats, vos renouvellements planifiés et votre authentification reposent tous sur le fait que chaque hôte s'accorde sur le maintenant. PCI-DSS (exigence 10) et ANSSI BP-028 imposent explicitement une référence temporelle commune et de confiance, pour que les journaux d'audit soient recevables et corrélables. Durcir la synchronisation de l'heure est une assurance bon marché qui maintient le reste de votre durcissement honnête.

Principes de défense appliqués

• Une source unique de vérité : un seul démon doit discipliner l'horloge. chrony, ntp/ntpsec et systemd-timesyncd se disputent l'horloge système si plusieurs tournent ; choisissez-en un et masquez les autres.
• Une source authentifiée : pointez vers un serveur interne contrôlé ou un pool réputé, et préférez NTS (Network Time Security, RFC 8915) afin qu'une source usurpée ne puisse pas décaler votre horloge. NTS enveloppe NTP dans une authentification adossée à TLS.
• Rejeter les sauts invraisemblables : maxchange rejette un serveur qui annonce soudain un écart énorme (garde anti-usurpation) ; préférez le glissement au saut sur les hôtes sensibles pour qu'un grand écart ne perturbe pas les bases ou TLS, avec makestep borné au début du démarrage.
• Ne pas devenir un serveur NTP : un hôte qui répond aux requêtes NTP peut être détourné pour une amplification DDoS. chrony ne sert pas par défaut ; gardez-le ainsi (pas de allow), et liez le socket de contrôle à localhost.
• Auditer l'état effectif, pas le paquet : un démon de temps peut être installé et configuré tout en étant masked, failed ou arrêté ; seule l'unité qui tourne maintient réellement l'heure.

Comment le mettre en place ?

# /etc/chrony/chrony.conf  -- authentifie, source unique, step maitrise
server time.cloudflare.com iburst nts   # source amont authentifiee par NTS
ntsdumpdir /var/lib/chrony
makestep 1.0 3        # step seulement lors des 3 premieres mises a jour (boot), puis slew
maxchange 1000 1 2    # rejette une source qui fait sauter l'horloge de facon invraisemblable
rtcsync
# pas de ligne 'allow' : ne pas servir l'heure au reseau

Puis systemctl enable --now chronyd et systemctl mask systemd-timesyncd ntp pour qu'un seul démon discipline l'horloge.

Ce que Pavois audite : l'état réel de l'unité

Pavois interroge systemd sur l'état réel de l'unité plutôt que de vérifier un fichier de configuration ou un paquet installé. La règle time-sync-present exécute systemctl is-active sur chaque démon de temps connu (chrony, chronyd, systemd-timesyncd, ntp, ntpsec) et valide dès que l'un d'eux tourne. C'est l'angle de la configuration effective : un démon peut être présent et entièrement configuré tout en étant masked ou failed, auquel cas l'horloge n'est pas disciplinée et un scan par fichier signalerait à tort un succès. Pour remédier, pavois harden apply utilise une ressource choose qui installe et active chrony par défaut (avec systemd-timesyncd comme alternative légère). La règle est mappée vers ANSSI BP-028 R71, CIS 2.3.x, PCI-DSS 10.6.1, NIST 3.3.7 et les contrôles de temps du STIG Ubuntu.

Vérifier

timedatectl                  # 'System clock synchronized: yes', 'NTP service: active'
chronyc tracking             # offset, stratum, etat leap, derniere mise a jour
chronyc sources -v           # quels serveurs, joignabilite, source selectionnee (*)
chronyc authdata             # cookies NTS presents => la source est authentifiee
chronyc ntpdata              # detail par source, dont l'etat d'authentification

Pièges

• Deux démons de temps se battent : chrony et systemd-timesyncd actifs ensemble glissent l'un contre l'autre. Masquez tout sauf un.
• Un pare-feu bloquant UDP/123 (ou NTS-KE TCP/4460) casse la sync en silence : le démon tourne mais n'atteint aucune source. Vérifiez chronyc sources.
• Un makestep laissé permanent re-saute l'horloge à l'exécution : bornez-le au début du démarrage (makestep 1.0 3) pour que la production ne saute jamais en pleine session.
• Les conteneurs partagent en général l'horloge de l'hôte : faites tourner le démon de temps sur l'hôte/la VM, pas dans chaque conteneur.

FAQ

Comment empêcher un attaquant d'usurper ma source de temps ? Utilisez NTS (server ... nts) pour que l'amont soit authentifié cryptographiquement, et posez maxchange pour rejeter les sauts invraisemblables. Vérifiez avec chronyc authdata.

Pourquoi Pavois vérifie-t-il is-active plutôt que la config ? Parce qu'un démon configuré mais masked/failed ne maintient aucune heure ; seule l'unité qui tourne discipline l'horloge, donc l'état vivant est la vérité.

chrony ou systemd-timesyncd ? chrony pour les serveurs (NTS, meilleure précision, gère les réseaux intermittents) ; systemd-timesyncd est un client SNTP léger, suffisant pour les hôtes minimalistes ou proches du conteneur. N'en faites tourner qu'un seul.