Vérifier le groupe propriétaire du fichier /var/log/auth.log
Garantit que /var/log/auth.log appartient au groupe adm afin que les enregistrements d'authentification restent confidentiels et résistants à l'altération.
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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
/var/log/auth.log enregistre les tentatives de connexion, l'usage de sudo, les sessions SSH et les événements d'authentification, la principale piste forensique après un incident. Si un groupe non privilégié le possède, un attaquant pourrait le lire pour récolter des noms d'utilisateurs et des horaires, ou l'altérer pour effacer ses traces. Restreindre le fichier au groupe adm préserve l'intégrité et la confidentialité des enregistrements d'authentification.
Ce que vérifie Pavois
Pavois lit l'appartenance de groupe résolue de /var/log/auth.log via la ressource InSpec file et vérifie que le groupe est adm. Il inspecte les métadonnées réelles de l'inode au moment de l'audit, ce qui reflète la propriété réelle du fichier, même après une rotation des journaux qui aurait pu le recréer.
only_if { file('/var/log/auth.log').exist? }
describe file('/var/log/auth.log') do
its('group') { should eq 'adm' }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%G' /var/log/auth.log. La sortie attendue est :
adm
Affichez-le avec ls -l /var/log/auth.log et vérifiez les copies tournées avec ls -l /var/log/auth.log*.
Inspecter et investiguer
Ce fichier est lui-même le journal d'authentification : inspectez-le avec tail -f /var/log/auth.log ou, pour l'équivalent du journal systemd, journalctl -u ssh et journalctl _COMM=sudo. Pour tracer les changements de permissions sur ce fichier, ajoutez une surveillance auditd (auditctl -w /var/log/auth.log -p wa -k logperms) et recherchez key="logperms" dans /var/log/audit/audit.log.
Remédiation
Le plan de durcissement de Pavois applique la ressource file pour définir le groupe de /var/log/auth.log sur adm. Il s'applique avec pavois harden apply et laisse inchangés le propriétaire et les bits de permission.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | adm |
|---|---|
| path | /var/log/auth.log |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un mauvais groupe propriétaire expose l'historique d'authentification aux utilisateurs non privilégiés et peut permettre à un attaquant d'effacer ses traces. La correction ne modifie que le groupe propriétaire, sans impact sur le service. Précaution : assurez-vous que rsyslog/logrotate recréent le fichier avec le groupe adm (vérifiez /etc/logrotate.d/rsyslog et la directive create) afin que le réglage persiste après les rotations ; sinon, la prochaine rotation pourrait l'annuler.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.1.4.1, 6.2.2.1 | direct | per OS, see the benchmark table | 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.