Vérifier l'existence d'un fichier de journal sudo dédié
Déclare un fichier de journal dédié à sudo (Defaults logfile="/var/log/sudo.log") afin que chaque commande privilégiée soit écrite dans un fichier qui lui est propre, indépendant de syslog. Sans cela, la trace de sudo n'est qu'un flux parmi d'autres dans auth.log ou secure, facilement noyé dans le bruit ou emporté par la rotation de ce flux.
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
Un fichier de journal dédié à sudo simplifie l'audit des commandes exécutées avec des privilèges.
Ce que vérifie Pavois
Pavois exécute grep -rqE '^[^#]*Defaults[^#]*\blogfile\b' /etc/sudoers /etc/sudoers.d/ et attend ok. Le grep est récursif sur le répertoire de drop-ins : un Defaults logfile posé dans n'importe quel fichier tiré par @includedir /etc/sudoers.d est donc pris en compte, exactement comme sudo le lirait, et l'ancrage ^[^#]* écarte les lignes commentées. Contrairement à SSH, sudo n'offre aucun équivalent non privilégié de sshd -T : la politique est réanalysée à chaque invocation, d'où le type persistent-config de ce contrôle plutôt que effective-runtime.
describe command('grep -rqE \'^[^#]*Defaults[^#]*\blogfile\b\' /etc/sudoers /etc/sudoers.d/ 2>/dev/null && echo ok || echo ko') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Exécutez sudo grep -rE '^[^#]*Defaults.*logfile' /etc/sudoers /etc/sudoers.d/. Sortie attendue :
/etc/sudoers.d/99-pavois-logfile:Defaults logfile="/var/log/sudo.log"
Puis prouvez-le de bout en bout : lancez n'importe quelle commande sudo et lisez la dernière entrée avec sudo tail -1 /var/log/sudo.log. Vérifiez que l'ensemble sudoers reste analysable avec sudo visudo -c.
Inspecter et investiguer
Une fois la règle appliquée, chaque invocation de sudo aboutit dans /var/log/sudo.log :
Jul 14 10:12:03 : alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/systemctl restart nginx
La destination logfile s'ajoute aux autres : sudo continue d'écrire vers syslog (/var/log/auth.log sur Debian/Ubuntu, /var/log/secure sur RHEL, journalctl -t sudo), une chaîne de collecte fondée sur syslog n'est donc pas perturbée.
Remédiation
Le plan de durcissement Pavois utilise la ressource file pour créer /etc/sudoers.d/99-pavois-logfile, appartenant à root:root, en mode 0440, contenant l'unique ligne Defaults logfile="/var/log/sudo.log". Le fichier est validé par visudo -cf <fichier> avant d'être conservé : une erreur de syntaxe ne peut donc jamais atteindre l'ensemble sudoers actif. Aucun service à recharger : sudo relit sa politique à l'invocation suivante et crée le fichier de journal dès son premier usage.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| content | Defaults logfile="/var/log/sudo.log" |
|---|---|
| group | root |
| mode | 0440 |
| owner | root |
| path | /etc/sudoers.d/99-pavois-logfile |
| resource | file |
| verify | visudo -cf %{path} |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Sans fichier dédié, la trace de qui a exécuté quoi en root n'existe que dans le flux d'authentification général, où elle rivalise avec le bruit de SSH et de PAM et hérite de la rétention de ce flux. Deux précautions à l'application. D'abord, tout fichier mal formé dans /etc/sudoers.d/ casse sudo pour tout le monde : c'est pourquoi le plan conditionne l'écriture à visudo -cf et pose le mode 0440 (sudo ignore les fichiers accessibles en écriture au groupe ou à tous) ; gardez une session root ouverte pendant la modification de sudoers. Ensuite, /var/log/sudo.log n'est couvert par aucune règle logrotate par défaut : sur un hôte chargé, il croît sans borne. Ajoutez-lui un fichier logrotate et traitez sa rétention comme une donnée d'audit, puisqu'il contient l'historique des commandes privilégiées.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 5.2.3 | direct | per OS, see the benchmark table | haute |
| PCI DSS | 2.2.6 | 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.