S'assurer qu'auditd collecte les modifications des tâches cron - /etc/cron.d/
Ajoute une surveillance d'audit sur /etc/cron.d/ (clé cronjobs) afin que toute modification des tâches planifiées de ce répertoire soit enregistrée.
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
/etc/cron.d/ est un point d'ancrage classique de persistance et d'élévation de privilèges : un attaquant qui y dépose ou modifie un fichier peut planifier des commandes arbitraires en tant que root. Auditer les modifications de ce répertoire conserve une trace responsabilisante de chaque changement, au service de la détection d'incident comme de l'investigation forensique. Sans cette surveillance, une entrée cron malveillante peut être ajoutée puis retirée sans laisser de trace.
Ce que vérifie Pavois
Pavois exécute auditctl -l, le jeu de règles d'audit effectif et chargé dans le noyau en cours d'exécution, et exige une règle de clé cronjobs surveillant /etc/cron.d/. Lire le jeu de règles actif, et non /etc/audit/rules.d/*.rules, est ce qui rend ce contrôle fiable : une règle présente dans un fichier mais jamais chargée (pas de augenrules --load, ou une erreur de syntaxe) passerait à tort un scan basé sur les fichiers mais échouerait correctement ici.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)cronjobs\b/) }
end
describe command("grep -rhwsE 'cronjobs' /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 cronjobs. Sortie attendue : une ligne de surveillance du type -w /etc/cron.d/ -p wa -k cronjobs.
Inspecter et investiguer
Les modifications de /etc/cron.d/ sont enregistrées dans /var/log/audit/audit.log avec l'étiquette key="cronjobs". Recherchez directement dans le journal brut (grep 'key="cronjobs"' /var/log/audit/audit.log) plutôt que de vous fier à ausearch -k cronjobs, qui peut signaler à tort aucune correspondance.
Remédiation
Le plan de durcissement de Pavois utilise la ressource audit_ruleset pour ajouter la surveillance de /etc/cron.d/ (clé cronjobs) aux règles d'audit persistantes et la charger dans le noyau ; reboot_required est signalé car les règles d'audit ne deviennent pleinement immuables et faisant autorité qu'après un redémarrage (option d'activation -e 2). Appliquez-le avec pavois harden apply.
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
Une surveillance de répertoire présente un risque faible et ajoute un bruit négligeable (les fichiers cron changent rarement). Le point d'attention principal est le redémarrage : si la configuration d'audit est verrouillée en immuable (-e 2), tout nouveau changement de règle nécessite un redémarrage pour prendre effet. Précaution : chargez la règle avec augenrules --load pour l'appliquer immédiatement, et planifiez le redémarrage pour le drapeau immuable durant une fenêtre de maintenance. Vérifiez que la règle apparaît dans auditctl -l après chargement pour que la couverture soit réellement active.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| DISA STIG | UBTU-22-654041, UBTU-24-200270 | 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.