Un service de synchronisation de l'heure est actif
Garantit qu'au moins un démon de synchronisation de l'heure (chrony, chronyd, systemd-timesyncd, ntp ou ntpsec) est actif afin que l'horloge système reste exacte.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Domaine peu couvert par Pavois aujourd’hui, voir la couverture.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
Des horloges précises et synchronisées sont un prérequis à une sécurité fiable. Sans synchronisation, les horodatages des journaux dérivent d'un hôte à l'autre, rendant la corrélation d'incidents et l'analyse forensique peu fiables ; l'authentification TLS/Kerberos échoue (fenêtres de validité des certificats, durée de vie des tickets) ; les tâches planifiées et les renouvellements de certificats se déclenchent au mauvais moment ; et les exigences d'audit PCI-DSS / ANSSI reposant sur une référence temporelle commune ne peuvent être satisfaites.
Ce que vérifie Pavois
Pavois interroge systemd sur l'état réel de l'unité via systemctl is-active, en parcourant chaque démon de temps connu et en validant dès que l'un d'eux tourne. Cela audite le statut effectif du service, pas la présence d'un fichier de configuration ni d'un paquet installé : un démon peut être installé et configuré tout en étant masked, failed ou simplement arrêté. Seul is-active reflète si l'horloge est réellement disciplinée à l'instant présent.
describe command('for s in chrony chronyd systemd-timesyncd ntp ntpsec; do systemctl is-active --quiet "$s" && { echo ok; exit 0; }; done; echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Vérifiez le démon actif, par ex. systemctl is-active chrony (attendu active), et confirmez qu'il suit réellement une source :
# chrony
chronyc tracking
# systemd-timesyncd
timedatectl status # "System clock synchronized: yes"
Inspecter et investiguer
Utilisez systemctl show <unité> pour l'état de l'unité et journalctl -u chrony (ou -u systemd-timesyncd) pour les événements de synchronisation, la sélection de source et les messages de saut/glissement. timedatectl status résume si l'horloge est synchronisée et quel service en a la charge ; chronyc sources -v liste les pairs amont et leur joignabilité.
Remédiation
Le plan de durcissement utilise une ressource choose : par défaut il installe et active chrony (paquet chrony, service chrony), avec timesyncd (systemd-timesyncd) en alternative. pavois harden apply installe le paquet choisi et active son service afin qu'un démon de synchronisation tourne. Choisissez timesyncd sur les hôtes minimalistes où chrony n'est pas souhaitable.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| default | chrony |
|---|---|
| options | chrony: package: chrony, service: chrony.service, timesyncd: package: systemd-timesyncd, service: systemd-timesyncd |
| resource | choose |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Activer un démon de temps présente peu de risque. Deux précautions : (1) un seul démon doit discipliner l'horloge : chrony, ntp/ntpsec et systemd-timesyncd entrent en conflit, donc activer chrony doit s'accompagner de la désactivation/masquage de timesyncd pour éviter qu'ils se disputent l'horloge ; (2) à la première synchronisation, un grand écart peut provoquer un saut d'horloge (un bond soudain), pouvant perturber les tâches longues, les bases de données ou les sessions TLS : sur les hôtes sensibles, préférez le glissement (défaut de chrony) et assurez-vous que l'hôte peut joindre ses serveurs NTP (UDP/123 sortant) avant de vous y fier. Dans les conteneurs qui partagent l'horloge de l'hôte, aucun démon interne n'est nécessaire.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R71 | direct | 2.0 | haute |
| CIS | 2.3.1.1, 2.3.2, 2.3.1 | direct | per OS, see the benchmark table | haute |
| NIST | 3.3.7, SC-45 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.6.1 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-215020, UBTU-24-100010 | direct | per OS STIG release | haute |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.