Vérifier les permissions de /etc/audit/audit.rules
Garantit que /etc/audit/audit.rules n'est ni modifiable par le groupe ou les autres, ni lisible par les autres, et exempt des bits exécutable, setuid, setgid ou sticky.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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/audit/audit.rules est le jeu de règles auditd compilé et actif (généré par augenrules à partir des fragments de rules.d). Il définit exactement quels événements sont enregistrés. S'il est modifiable par le groupe ou les autres, un attaquant peut effacer les règles qui consigneraient son activité ; s'il est lisible par les autres, il apprend précisément ce qui est surveillé et peut le contourner. Le maintenir réservé à root protège l'intégrité et la confidentialité de la politique d'audit, socle de la détection et de l'imputation des incidents.
Ce que vérifie Pavois
Pavois inspecte les permissions réelles de l'inode /etc/audit/audit.rules avec la ressource InSpec file (un stat), sous only_if pour ignorer les hôtes sans auditd. Elle exige un mode effectif au plus permissif égal à 0640 root:root, aucune écriture groupe/autres, aucune lecture autres, aucun bit spécial. Lire les permissions réelles détecte un fichier régénéré ou modifié après l'installation, ce qu'un contrôle sur un défaut de paquet manquerait.
only_if { file('/etc/audit/audit.rules').exist? }
describe file('/etc/audit/audit.rules') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_readable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G' /etc/audit/audit.rules. La sortie attendue est le mode 640 (ou plus strict) appartenant à root root, par ex. 640 root root. Tout droit d'écriture groupe, de lecture autres ou bit spécial fait échouer la règle.
Inspecter et investiguer
auditd charge ce fichier au démarrage ; confirmez avec auditctl -l (règles actives) et journalctl -u auditd. Les altérations et changements de configuration apparaissent dans /var/log/audit/audit.log (grep CONFIG_CHANGE). Après régénération du fichier, rechargez avec augenrules --load.
Remédiation
Aucune remédiation automatique n'est définie ; appliquez-la manuellement : chmod u-x,g-wx,o-rwx /etc/audit/audit.rules && chown root:root /etc/audit/audit.rules (cible 0640 root:root). Sur les systèmes utilisant augenrules, ce fichier est régénéré ; durcissez donc aussi les fragments de rules.d (voir fileperm-etc-audit-rulesd) pour conserver le résultat.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0640 |
|---|---|
| path | /etc/audit/audit.rules |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Le changement est peu risqué : auditd lit le fichier en root et n'a besoin d'aucun accès plus large. Précaution : si votre distribution régénère audit.rules via augenrules, un chmod manuel peut être annulé au prochain rechargement, corrigez aussi les fragments sources. Vérifiez avec auditctl -l que les règles restent chargées. Laisser le fichier modifiable par le groupe ou les autres permet à un utilisateur non privilégié de désactiver l'audit sans être détecté.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.2.4.5, 6.3.4.5 | direct | per OS, see the benchmark table | haute |
| DISA STIG | UBTU-22-653065, UBTU-24-900040 | 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.