journald transmet au démon syslog qui tourne réellement
Si un démon syslog tourne, journald doit lui transmettre (ForwardToSyslog=yes). Ce contrôle natif pavois affirme l'autre moitié de l'exigence CIS : les normes demandent qu'un démon syslog soit installé et actif, mais rien ne vérifie qu'il reçoit encore quelque chose. Un hôte où rsyslog est active (running) et où /var/log/syslog n'a pas gagné une ligne depuis le démarrage est conforme sur le papier et aveugle en pratique.
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.
Ce que vérifie Pavois
Deux couches. Un only_if cadre le contrôle sur le transport qui dépend réellement de la transmission : il s'exécute quand rsyslog ou syslog-ng tourne et que rsyslog ne charge pas le module imjournal (le défaut Debian et Ubuntu est imuxsock seul, donc sans transmission rsyslog ne reçoit rien). Là où rsyslog lit le journal directement via imjournal (le défaut RHEL et Fedora), la transmission est redondante et le contrôle est sauté, pas mis en échec. Le contrôle lit ensuite la valeur effective avec systemd-analyze cat-config systemd/journald.conf, en retenant la dernière ligne ForwardToSyslog= : cette commande fusionne le fichier fournisseur, /etc/systemd/journald.conf et tous les drop-ins, si bien qu'un no réintroduit en aval est détecté. Lire le seul fichier principal manquerait précisément cela.
only_if { (service('rsyslog').running? || service('syslog-ng').running?) && !command('grep -rqsE \'^[[:space:]]*(module\\(load="imjournal"|\\$ModLoad[[:space:]]+imjournal)\' /etc/rsyslog.conf /etc/rsyslog.d/ 2>/dev/null').exit_status.zero? }
describe command('systemd-analyze cat-config systemd/journald.conf 2>/dev/null | grep -iE "^[[:space:]]*ForwardToSyslog[[:space:]]*=" | tail -1 | grep -qiE "=[[:space:]]*(no|false|0)" && echo ko || echo ok') do
its('stdout.strip') { should eq 'ok' }
endComment vérifier qu’elle est appliquée
Lisez la valeur résolue, puis prouvez la chaîne de bout en bout :
systemd-analyze cat-config systemd/journald.conf | grep -i '^ForwardToSyslog'
logger -t pavois-test 'forwarding check'
tail -n 5 /var/log/syslog # /var/log/messages sur RHEL
La ligne de test doit apparaître dans le fichier en quelques secondes. C'est cette vérification de bout en bout, et non la valeur de configuration, qui aurait rattrapé l'incident à l'origine de ce contrôle.
Inspecter et investiguer
L'indice est la fraîcheur des journaux fichiers : comparez stat -c %y /var/log/syslog (ou /var/log/messages) avec l'uptime de la machine. Une date de modification figée à l'heure du démarrage, sur un hôte dont systemctl status rsyslog est vert, est l'empreinte exacte d'une transmission cassée. journalctl -u systemd-journald montre le démon redémarrer une fois le drop-in appliqué.
Remédiation
Pavois écrit un drop-in dédié /etc/systemd/journald.conf.d/99-pavois-forward.conf ne contenant que :
[Journal]
ForwardToSyslog=yes
Il supprime ensuite l'ancien drop-in agrégé 99-pavois.conf qui figeait ForwardToSyslog=no, puis redémarre systemd-journald et rsyslog. La forme un réglage par drop-in est tout l'enjeu : c'est elle qui empêche un autre contrôle journald d'écraser silencieusement celui-ci au prochain confkit harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | mkdir -p /etc/systemd/journald.conf.d && printf '[Journal]\nForwardToSyslog=yes\n' > /etc/systemd/journald.conf.d/99-pavois-forward.conf && rm -f /etc/systemd/journald.conf.d/99-pavois.conf && systemctl restart systemd-journald 2>/dev/null; systemctl restart rsyslog 2>/dev/null; true |
|---|---|
| name | journald-forward-to-running-syslog |
| not_if | ! test -e /etc/systemd/journald.conf.d/99-pavois.conf && ! systemd-analyze cat-config systemd/journald.conf 2>/dev/null | grep -iE "^[[:space:]]*ForwardToSyslog[[:space:]]*=" | tail -1 | grep -qiE "=[[:space:]]*(no|false|0)" |
| resource | exec |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Ce contrôle est né d'un bug de pavois : trois contrôles journald écrivaient le même fichier agrégé, dont le contenu figeait ForwardToSyslog=no. rsyslog restait active (running), /var/log/syslog n'avait pas reçu une seule ligne depuis le démarrage, et tous les contrôles étaient verts, alors que toute la chaîne qui lit les fichiers de log (expédition vers un SIEM, logrotate, analyse post-incident) était morte. Activer la transmission stocke chaque message deux fois (dans le journal et dans les fichiers syslog) et double donc à peu près l'occupation disque des logs : associez-la à growth-journal-bounded et growth-logrotate-active pour qu'aucun des deux stockages ne croisse sans borne. Sur RHEL et Fedora avec imjournal, le contrôle est sauté et rien ne change.