Thomas.will: Neue Seite: Baustein Journal und Logging

2026-10-17T15:47:28Z

Neue Seite: Baustein Journal und Logging

Neue Seite

[[Kategorie:systemd]]
{| class="wikitable"
! Baustein !! ab Stufe !! Lernpfad
|-
| '''Journal und Logging''' || [[Systemd Stufe 1 Basic|Stufe 1]] bis [[Systemd Stufe 3 Security|Stufe 3]] || [[Systemd Lernpfad|Ü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=
{| class="wikitable"
! 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.
{| class="wikitable"
! 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
<pre>
Archived and active journals take up 166.7M in the file system.
</pre>
*Grenzen setzen mit einem Drop-in: '''/etc/systemd/journald.conf.d/size.conf'''
<pre>
[Journal]
SystemMaxUse=1G
MaxRetentionSec=3month
</pre>
*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==
{| class="wikitable"
! 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.
<pre>
journalctl --setup-keys
</pre>
*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==
{| class="wikitable"
! 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
<pre>
[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/journal/remote/
</pre>
*Im Betrieb immer HTTPS mit Zertifikaten.
;Sender
*/etc/systemd/journal-upload.conf
<pre>
[Upload]
URL=http://logserver.lab.lan:19532
</pre>
*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
<pre>
[Journal]
ForwardToSyslog=yes
</pre>
*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=
*[[Systemd Lernpfad|Übersicht: Lernpfad systemd]]
*Alte Seiten: [[Systemd journald]] · [[Systemd-journalctl-beschreibung]] · [[Journald Remote Logging]]

Systemd Baustein Journal - Versionsgeschichte

Thomas.will: Neue Seite: Baustein Journal und Logging