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
- Lassen Sie sich alle Fehler seit dem letzten Start anzeigen.
- Lesen Sie die Logs von ssh live mit und melden Sie sich einmal falsch an.
- Wie viele Starts sind gespeichert, und wie viel Platz braucht das Journal?
- Suchen Sie alle Meldungen von sudo des heutigen Tages.
- Lassen Sie sich die letzte Meldung mit allen Feldern anzeigen. Welche Felder kennen Sie schon?
Für Schnelle
- Begrenzen Sie das Journal auf 200 MB und prüfen Sie es mit --disk-usage.
- Richten Sie FSS ein und prüfen Sie das Journal mit --verify.
- Schicken Sie das Journal einer VM per systemd-journal-upload an eine zweite VM und lesen Sie es dort.
Weiter