Enregistrer les tentatives de modification de l'heure via clock_settime
Impose une règle auditd (clé time-change) qui enregistre les tentatives de réglage de l'horloge système via l'appel système clock_settime.
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.
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 modifications arbitraires de l'horloge système peuvent servir à masquer une activité malveillante dans les journaux (en faussant les horodatages) et à perturber des services dépendant d'une heure exacte, comme sshd, Kerberos et la validation des certificats TLS. L'appel système clock_settime est un moyen de régler l'heure directement : chacun de ces appels doit donc être audité. Une chronologie fiable et exacte est l'épine dorsale de toute investigation d'incident.
Ce que vérifie Pavois
Pavois exécute auditctl -l et vérifie qu'une règle de clé time-change est chargée. Lire le jeu de règles réellement chargé dans le noyau vaut mieux qu'analyser /etc/audit/rules.d/*.rules : une règle sur disque jamais chargée (pas de augenrules --load, erreur de syntaxe, échec de rechargement) ferait passer à tort un scanner de fichiers. auditctl -l reflète ce que le noyau audite à l'instant présent.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)time\-change\b/) }
end
describe command("grep -rhwsE 'time\-change' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez auditctl -l | grep -E '(-k |key=)time-change' (en root). La sortie attendue inclut les règles d'appel système clock_settime, par exemple :
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -k time-change-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -k time-change
Aucune sortie signifie que les règles ne sont pas chargées.
Inspecter et investiguer
Les événements aboutissent dans /var/log/audit/audit.log. Après un changement d'heure, trouvez l'enregistrement avec grep 'key="time-change"' /var/log/audit/audit.log (grep sur le journal brut ; ausearch peut signaler à tort l'absence de correspondance). L'enregistrement indique l'auid, l'appel système et l'horodatage.
Remédiation
pavois harden apply utilise la ressource audit_ruleset pour ajouter les règles d'appel système time-change manquantes dans un drop-in géré par Pavois sous /etc/audit/rules.d/ et les charger. Le sous-système d'audit étant verrouillé une fois lancé, la modification n'est pleinement effective qu'après un redémarrage (reboot_required: true).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Il s'agit d'une surveillance d'appel système passive, elle ne bloque jamais les changements d'heure, donc NTP/chrony et les date/timedatectl manuels continuent de fonctionner ; elle ajoute seulement des enregistrements dans /var/log/audit/audit.log. Précautions :
- Un démon NTP correctement configuré discipline l'horloge progressivement (via
adjtimex) plutôt que d'appelerclock_settime, donc le volume d'audit en régime permanent issu de cette règle est faible. - Si le jeu de règles est immuable (
-e 2), la règle ne peut être ajoutée qu'après un redémarrage. - Confirmez que la règle a été analysée avec
augenrules --loadpuis revérifiezauditctl -l.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | haute |
| CIS | 10.6.3, 6.2.3.4, 6.3.3.4 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.7, AC-6(9), AU-12(c), AU-2(d), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.6.3 | support | 4.0.1 | moyenne |
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.