Enregistrer les tentatives d'accès infructueuses aux fichiers - creat
Impose une règle auditd (clé access) qui enregistre les tentatives infructueuses (permission refusée) d'accès et de modification de fichiers.
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
Les tentatives infructueuses d'accès ou de modification de fichiers, celles échouant avec EACCES (permission refusée) ou EPERM (opération non permise), sont un indicateur fort d'activité malveillante, comme un attaquant sondant le système de fichiers ou cherchant à dépasser ses droits. Auditer ces appels creat/open/openat/truncate en échec capture la preuve d'une tentative de compromission qu'une politique n'auditant que les succès laisserait passer.
Ce que vérifie Pavois
Pavois exécute auditctl -l et vérifie qu'une règle de clé access 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=)access\b/) }
end
describe command("grep -rhwsE 'access' /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=)access' (en root). La sortie attendue est l'ensemble des règles d'appel système capturant les échecs EACCES/EPERM, par exemple :
-a always,exit -F arch=b64 -S creat,open,openat,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access-a always,exit -F arch=b64 -S creat,open,openat,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access
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 accès fichier refusé, trouvez l'enregistrement avec grep 'key="access"' /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 en échec, le fichier ciblé et le code de sortie EACCES/EPERM.
Remédiation
pavois harden apply utilise la ressource audit_ruleset pour ajouter les règles d'appel système access 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
Ce sont des surveillances d'appels système passives, elles n'enregistrent que les accès en échec et ne bloquent jamais rien, donc les applications continuent de fonctionner ; elles ajoutent seulement des enregistrements dans /var/log/audit/audit.log. Précautions :
- Les événements de permission refusée sont fréquents en fonctionnement normal (applications sondant des chemins optionnels), donc cette règle peut être bruyante, assurez-vous que
/var/log/auditdispose d'espace et de rotation, et surveillez la limite de backlog d'auditdavant de l'activer sur des hôtes très sollicités. - 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 | 6.2.3.7, 6.3.3.11, 6.3.3.7 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.7, AU-12(c), AU-2(d), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.2.1.4 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-654165, UBTU-24-900160 | 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.