S'assurer que journald est configuré pour la transmission des journaux vers rsyslog
Définit ForwardToSyslog=no afin que journald ne duplique pas chaque enregistrement vers syslog, ne laissant qu'un seul pipeline de journalisation maîtrisé.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
Domaine partiellement couvert par Pavois aujourd’hui, voir la couverture.
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
Quand journald transmet aussi tout vers syslog, les enregistrements sont écrits deux fois, gaspillant disque et E/S et créant des copies divergentes. La base durcie conserve un seul pipeline faisant autorité ; l'envoi centralisé/distant doit être configuré explicitement (par ex. une règle rsyslog @@distant) plutôt que de s'appuyer sur une transmission systématique. Stocker les journaux sur un hôte distant protège aussi leur intégrité : si un attaquant obtient root localement, il peut altérer ou supprimer les logs locaux ; un unique chemin de transmission configuré à dessein est plus simple à sécuriser et à maîtriser.
Ce que vérifie Pavois
Pavois recherche dans /etc/systemd/journald.conf et les drop-ins journald.conf.d/ un ForwardToSyslog=no actif. Comme journald fusionne les drop-ins par-dessus le fichier de base, scanner les deux donne la valeur effective, un drop-in à no surcharge correctement un yes de base.
only_if { !service('rsyslog').running? && !service('syslog-ng').running? }
describe command('systemd-analyze cat-config systemd/journald.conf 2>/dev/null | grep -iE "^[[:space:]]*ForwardToSyslog[[:space:]]*=" | tail -1') do
its('stdout') { should match(/=\s*no/i) }
endComment vérifier qu’elle est appliquée
Exécutez grep -riE '^\s*ForwardToSyslog\s*=\s*no' /etc/systemd/journald.conf /etc/systemd/journald.conf.d/. Attendu : au moins une ligne correspondante. Appliquez avec systemctl restart systemd-journald.
Inspecter et investiguer
Vérifiez l'état de journald avec journalctl -u systemd-journald et systemctl status systemd-journald. Si syslog est utilisé, confirmez l'éventuelle duplication en comparant la sortie de journalctl à /var/log/syslog (Debian/Ubuntu) ou /var/log/messages (RHEL). Config active : /etc/systemd/journald.conf et /etc/systemd/journald.conf.d/*.conf.
Remédiation
pavois harden apply écrit la ressource file /etc/systemd/journald.conf.d/99-Pavois.conf (root:root, 0644) contenant [Journal] avec Compress=yes, ForwardToSyslog=no et Storage=persistent, ce drop-in unique satisfait donc d'un coup les règles journald de compression, de transmission et de stockage. Rechargez ensuite journald (systemctl restart systemd-journald) pour qu'il prenne effet.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| content | [Journal] ForwardToSyslog=no |
|---|---|
| group | root |
| mode | 0644 |
| owner | root |
| path | /etc/systemd/journald.conf.d/99-pavois-forward.conf |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Désactiver la transmission est peu risqué, mais ne la désactivez pas aveuglément si syslog est votre seul chemin vers un SIEM central, vous cesseriez d'exporter les logs hors machine. Précaution : avant d'appliquer, vérifiez comment les logs atteignent votre collecteur ; si c'est via journald→syslog, mettez d'abord en place un rsyslog distant explicite / systemd-journal-upload, puis coupez la transmission. Le drop-in est réécrit à chaque application : tout réglage [Journal] manuel dans ce fichier doit être intégré au contenu de Pavois. Redémarrer journald suspend brièvement les écritures de journaux.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.1.3.3, 6.2.2.2, 6.2.1.1.4 | 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.