Durcir la journalisation avec journald et rsyslog

La menace : on attaque les journaux précisément parce qu'ils détiennent la preuve

Les journaux sont là où une intrusion laisse ses empreintes, et c'est précisément pour cela qu'on les attaque. Un adversaire qui prend pied sur un hôte se tourne vite vers l'anti-forensique : effacer /var/log/journal, tronquer les fichiers syslog, ou simplement déclencher un redémarrage quand le journal ne réside qu'en mémoire volatile. Pire, le danger est souvent le silence : avec le Storage=auto par défaut, les journaux peuvent rester dans /run et disparaître au prochain démarrage ; un journal non plafonné peut remplir la partition de logs, après quoi journald abandonne les nouveaux enregistrements et la preuve de l'attaque en cours n'est jamais écrite. Si les logs ne sont stockés que localement, le même accès root qui a laissé entrer l'attaquant lui permet d'en modifier ou d'en supprimer la preuve. Sans journaux dignes de confiance, un incident devient indémontrable.

Pourquoi le durcir

La journalisation est le seul contrôle dont la valeur se révèle après la compromission. Toute autre défense vise à arrêter l'attaquant ; la journalisation suppose que l'un d'eux finira par passer et pose la question : peut-on reconstituer la chronologie ? Durcir le pipeline garantit que la réponse est oui : les enregistrements survivent aux redémarrages, la partition ne se remplit pas en silence, l'altération est détectable, et une copie réside quelque part que l'attaquant local ne peut atteindre.

Principes de défense appliqués

• Persistance : Storage=persistent écrit les journaux dans /var/log/journal afin qu'ils survivent aux plantages, coupures de courant et redémarrages, au lieu de s'évaporer de /run.
• Disponibilité du canal de logs : Compress=yes et des plafonds de rétention (SystemMaxUse=, SystemKeepFree=, MaxRetentionSec=) allongent l'historique pour un même budget disque et empêchent qu'une partition pleine n'abandonne les enregistrements. RateLimitIntervalSec/RateLimitBurst atténuent un déni de service par inondation de logs, mais réglez-les généreusement pour ne jamais perdre un vrai événement de sécurité.
• Pipeline unique et maîtrisé : ForwardToSyslog=no évite la double écriture aveugle ; l'envoi centralisé est configuré explicitement (règle rsyslog @@distant ou systemd-journal-upload).
• Intégrité hors machine : transmettre à un collecteur distant / SIEM pour que les logs existent hors de portée du root local.
• Traçabilité : intégrer la piste d'audit du noyau au journal avec Audit=yes, et conserver un enregistrement complet et ordonné dans le temps.

Comment rendre les journaux infalsifiables ? Le scellement à sécurité persistante

Un attaquant local disposant de root peut éditer les fichiers de journal. Le Forward Secure Sealing (FSS) rend cela détectable : journald scelle périodiquement le journal avec une clé qui évolue, de sorte que toute édition rétroactive brise le sceau. Générez la paire de clés une fois, activez le scellement, et vérifiez à la demande :

journalctl --setup-keys          # génère la clé de scellement + une clé de verification (stockez-la hors machine)
# posez Seal=yes dans journald.conf, puis :
systemctl restart systemd-journald
journalctl --verify              # PASS, ou signale la premiere entree alteree

Le FSS détecte l'altération ; il ne l'empêche pas. Couplez-le à l'envoi hors machine pour conserver aussi une copie intacte.

Ce que Pavois audite : la configuration effective de journald

Pavois audite la configuration effective de journald telle que le démon la résout. Comme journald fusionne son répertoire de drop-ins /etc/systemd/journald.conf.d/ par-dessus le fichier de base /etc/systemd/journald.conf, Pavois recherche dans les deux ; ainsi un fichier de base surchargé par un drop-in est lu comme la valeur qui s'applique réellement, là où un scan d'un seul fichier (OVAL/oscap) rapporterait un état erroné. Ses règles Logging (journald) vérifient Storage=persistent (journald-storage), Compress=yes (journald-compress), et ForwardToSyslog=no (journald-forwardtosyslog). Ces contrôles correspondent aux référentiels CIS de journald et à ANSSI BP-028 R71, et pavois harden apply peut écrire un drop-in unique (/etc/systemd/journald.conf.d/99-Pavois.conf) qui satisfait les trois, suivi de systemctl restart systemd-journald.

Vérifier

journalctl --disk-usage                       # occupation du journal face au plafond
journalctl --list-boots                       # historique persistant entre redemarrages
journalctl --verify                           # contrôle d'intégrité FSS
systemd-analyze cat-config systemd/journald.conf  # la config effective fusionnee
journalctl -k -b -1                           # log noyau du boot précédent, preuve de persistance

Pièges

• Storage=auto n'est pas de la persistance : il ne persiste que si /var/log/journal existe déjà. Utilisez Storage=persistent (ou créez le répertoire).
• Un RateLimitBurst agressif jette des événements de sécurité : un bruteforce ou un scan peut être réduit au silence par votre propre limite. Réglez-la haut pour les unités sensibles.
• Le FSS détecte, n'empêche jamais : il vous dit que les logs ont été altérés après coup ; seul l'envoi hors machine préserve une copie intacte.
• Un redémarrage segmente mais ne supprime pas : ne confondez pas la séparation par --list-boots avec une perte de logs.

FAQ

Comment prouver que les journaux n'ont pas été altérés ? Activez le Forward Secure Sealing (journalctl --setup-keys, Seal=yes) et lancez journalctl --verify ; un sceau brisé pointe la première entrée altérée.

Pourquoi ForwardToSyslog=no si je veux une journalisation centrale ? Parce que le transfert aveugle double-écrit tout ; configurez l'envoi explicitement (rsyslog @@distant ou systemd-journal-upload) pour n'avoir qu'un seul pipeline faisant autorité.

Pourquoi Pavois lit-il à la fois journald.conf et le répertoire de drop-ins ? Parce que le démon les fusionne ; un drop-in peut surcharger la base, donc seul le résultat fusionné est la vérité.