Systemd Baustein Journal

Baustein	ab Stufe	Lernpfad
Journal und Logging	Stufe 1 bis Stufe 3	Übersicht

Einfach erklärt

• journald sammelt alle Meldungen an einer Stelle: vom Kernel, aus der initramfs, von jedem Dienst und von syslog.
• Gespeichert wird nicht als Textdatei, sondern in einem Binärformat mit vielen Zusatzfeldern: Dienst, PID, Benutzer, Programm, Bootvorgang.
• Gelesen wird mit journalctl. Mit den Zusatzfeldern kann man sehr genau filtern.
• Für Sicherheit gilt: Ein Log auf dem eigenen Rechner kann ein Angreifer löschen. Deshalb gehören wichtige Logs zusätzlich auf einen zentralen Server oder ins SIEM.

Stufe 1: Lesen

Befehl	Wirkung
journalctl -e	ans Ende springen, die neuesten Meldungen
journalctl -f	live mitlesen
journalctl -u ssh	nur ein Dienst
journalctl -b	seit dem letzten Start
journalctl -b -1	der vorletzte Start
journalctl --list-boots	alle gespeicherten Starts
journalctl -k	nur Kernelmeldungen
journalctl -p err	nur Fehler und schlimmer
journalctl --since "1 hour ago"	nur die letzte Stunde
journalctl --since "2026-10-17 08:00" --until "2026-10-17 09:00"	ein Zeitraum
journalctl -g "Failed password"	Volltextsuche (grep)

• Die Stufen für -p: emerg, alert, crit, err, warning, notice, info, debug.
• Ohne sudo sieht man nur die eigenen Meldungen. Für alles: sudo oder Gruppe adm.

Stufe 2: Gezielt filtern

• Jede Meldung hat Felder, die mit _ beginnen. Diese setzt journald selbst, ein Programm kann sie nicht fälschen.

Filter	Wirkung
journalctl _SYSTEMD_UNIT=ssh.service	alles von einer Unit
journalctl _UID=1000	alles von einem Benutzer
journalctl _EXE=/usr/bin/sudo	alles von einem Programm
journalctl _PID=1	nur systemd selbst
journalctl _COMM=sshd + _COMM=sudo	mit + verknüpft: das eine oder das andere
journalctl -F _SYSTEMD_UNIT	welche Werte es für ein Feld gibt
journalctl -o verbose -n 1	alle Felder der letzten Meldung
journalctl -o json-pretty -n 1	dasselbe als JSON, gut für Skripte

Speicher und Größe

• Debian 13 und Rocky speichern das Journal dauerhaft unter /var/log/journal/. Fehlt das Verzeichnis, liegt es nur im RAM unter /run/log/journal/ und ist nach dem Neustart weg.
• journalctl --disk-usage

Archived and active journals take up 166.7M in the file system.

• Grenzen setzen mit einem Drop-in: /etc/systemd/journald.conf.d/size.conf

[Journal]
SystemMaxUse=1G
MaxRetentionSec=3month

• systemctl restart systemd-journald
• Aufräumen, betrifft immer das ganze Journal, nicht einzelne Dienste:
• journalctl --vacuum-size=500M
• journalctl --vacuum-time=30d

Stufe 3: Logs für die Sicherheit

Was man im Journal findet

Frage	Befehl
Fehlgeschlagene SSH-Anmeldungen	journalctl -u ssh -g "Failed password"
Wer hat sudo benutzt?	journalctl _COMM=sudo
Wurden Units geändert oder neu geladen?	journalctl _PID=1 -g "Reload"
Welche Dienste wurden gestartet?	journalctl _PID=1 -g "Started"
Wurde neu gestartet?	journalctl --list-boots

Logs gegen Manipulation sichern (FSS)

• Forward Secure Sealing versiegelt das Journal in Abständen. Ändert jemand nachträglich Einträge, fällt das bei der Prüfung auf.

journalctl --setup-keys

• Der Prüfschlüssel wird nur einmal angezeigt. Er gehört nicht auf den Rechner, sondern sicher weg.
• Prüfen: journalctl --verify --verify-key=SCHLÜSSEL
• Löschen kann ein Angreifer mit root trotzdem. Dagegen hilft nur das Wegschicken.

Logs wegschicken

Weg	Wofür
systemd-journal-upload → systemd-journal-remote	Journal zu Journal, mit allen Feldern
ForwardToSyslog=yes + rsyslog	klassisch per Syslog zu einem Syslog-Server oder SIEM
Agent des SIEM (z.B. Filebeat, Vector, Wazuh)	liest das Journal direkt und schickt es weiter

Journal zu Journal

• Auf beiden Rechnern: apt install systemd-journal-remote

Empfänger

• systemctl enable --now systemd-journal-remote.socket
• Er lauscht auf Port 19532. Die Logs landen unter /var/log/journal/remote/.
• Für den Test ohne Zertifikate per HTTP: systemctl edit systemd-journal-remote.service

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/journal/remote/

• Im Betrieb immer HTTPS mit Zertifikaten.

Sender

• /etc/systemd/journal-upload.conf

[Upload]
URL=http://logserver.lab.lan:19532

• systemctl enable --now systemd-journal-upload

Auf dem Empfänger lesen

• journalctl -D /var/log/journal/remote/ -f

Per Syslog

• /etc/systemd/journald.conf.d/syslog.conf

[Journal]
ForwardToSyslog=yes

• In rsyslog dann z.B.: *.* @@siem.lab.lan:514

Stolperfallen

• Nur RAM: Fehlt /var/log/journal, sind die Logs nach dem Neustart weg. mkdir /var/log/journal und systemctl restart systemd-journald.
• Kein sudo: journalctl zeigt ohne Hinweis nur einen Teil.
• Vacuum löscht alles Alte, nicht nur einen Dienst. Einzelne Dienste kann man nicht gezielt löschen.
• Zeit: --since und --until nutzen die lokale Zeit. Bei Rechnern in verschiedenen Zeitzonen --utc benutzen.
• journal-remote per HTTP schickt die Logs im Klartext durchs Netz. Nur im Lab.

Aufgaben

Grundaufgaben

1. Lassen Sie sich alle Fehler seit dem letzten Start anzeigen.
2. Lesen Sie die Logs von ssh live mit und melden Sie sich einmal falsch an.
3. Wie viele Starts sind gespeichert, und wie viel Platz braucht das Journal?
4. Suchen Sie alle Meldungen von sudo des heutigen Tages.
5. Lassen Sie sich die letzte Meldung mit allen Feldern anzeigen. Welche Felder kennen Sie schon?

Für Schnelle

1. Begrenzen Sie das Journal auf 200 MB und prüfen Sie es mit --disk-usage.
2. Richten Sie FSS ein und prüfen Sie das Journal mit --verify.
3. Schicken Sie das Journal einer VM per systemd-journal-upload an eine zweite VM und lesen Sie es dort.

Weiter

• Übersicht: Lernpfad systemd
• Alte Seiten: Systemd journald · Systemd-journalctl-beschreibung · Journald Remote Logging