Protokolle sind der einzige Ort, an dem nach einem Vorfall steht, was passiert ist. Das nützt nur, wenn man sie lesen kann und lesen lernt man nicht am Tag des Vorfalls, sondern an ruhigen Tagen, wenn nichts los ist.
Kein Loch, keine Frist. Aber der Unterschied zwischen „wir haben Protokolle“ und „wir konnten den Ablauf rekonstruieren“ entscheidet sich hier und der Aufwand ist eine Stunde einmalig plus zehn Minuten im Monat.
Die Referenz zuerst#
Bevor irgendetwas ungewöhnlich sein kann, muss gewöhnlich bekannt sein.
# Einmal auf einer gesunden Maschine, Ausgabe aufheben
journalctl --since -7d --priority=warning | awk '{$1=$2=$3="";print}' \
| sed 's/[0-9]\{1,\}/N/g' | sort | uniq -c | sort -rn | head -30Die Ersetzung aller Zahlen durch N fasst gleichartige Meldungen zusammen, aus dreitausend Zeilen werden zwanzig Muster. Diese zwanzig sind der Normalzustand. Alles, was später neu dazukommt, fällt beim Vergleich sofort auf.
Vier Fragen, vier Befehle#
Wer war auf der Maschine?
journalctl -u ssh --since -7d | grep -E 'Accepted|Failed' | awk '{print $1,$2,$3,$9,$11}' | sort | uniq -c | sort -rn | head
last -20Was hat sich am System geändert?
journalctl _COMM=systemd --since -7d | grep -Ei 'Started|Stopped|Reloaded' | grep -vi 'session|user' | head -20
grep -E 'install |remove |upgrade ' /var/log/dpkg.log | tail -20Wer hat mit erhöhten Rechten gearbeitet?
journalctl _COMM=sudo --since -7d | grep COMMAND | tail -20Was ist von außen gekommen?
# Webserver: die 20 häufigsten Anfragen mit Fehlercode
awk '$9 ~ /^[45]/ {print $9, $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20Diese vier Blöcke gehören in eine Datei, nicht ins Gedächtnis. Im Ernstfall zählt, dass man sie kopieren kann, statt sie zu erfinden.
Aufbewahrung bewusst setzen#
Standardmäßig wächst das Journal, bis es 10 % der Partition belegt. Auf einer kleinen Platte ist das zu viel, im Vorfall oft zu wenig Zeitraum.
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=1G
MaxRetentionSec=90day
MaxFileSec=1week
sudo systemctl restart systemd-journald
journalctl --disk-usage90 Tage sind ein brauchbarer Ausgangswert: lang genug, um einen Einbruch zu erfassen, der Wochen zurückliegt, kurz genug, um nicht zur Datenhalde zu werden. Was dabei rechtlich zu beachten ist, Protokolle enthalten IP-Adressen, also personenbezogene Daten, steht in Protokolle aufbewahren: wie lange ist erlaubt?.
Wer root hat, kann das Journal ändern oder leeren. Die vier Befehle oben sind Alltagswerkzeug; die Beweisfrage beantwortet nur eine Kopie auf einem anderen System, Protokolle, die den Angreifer überleben.
Rauschen abstellen statt ignorieren#
Wiederkehrende, bedeutungslose Meldungen sind der Hauptgrund, warum niemand mehr hinsieht. Sie gehören abgestellt, nicht überlesen:
# Welcher Dienst produziert die meisten Zeilen?
journalctl --since -24h -o json --output-fields=_SYSTEMD_UNIT 2>/dev/null \
| grep -o '"_SYSTEMD_UNIT":"[^"]*"' | sort | uniq -c | sort -rn | head -10Typische Kandidaten: ein Dienst mit zu hoher Protokollstufe, ein fehlgeschlagener Cronjob, der stündlich meckert, eine Anwendung, die jede erfolgreiche Verbindung meldet. Jeder Fall wird an der Quelle geregelt, Protokollstufe herabsetzen, den Fehler beheben, oder die Meldung bewusst ausfiltern.
Zehn Minuten im Monat#
- Musterliste erzeugen (Befehl ganz oben) und mit der Referenz vergleichen.
- Neue Muster ansehen: erklärbar oder Befund?
- Anmeldungen und
sudo-Aufrufe überfliegen. - Plattenverbrauch des Journals prüfen.
Wenn dabei etwas auffällt, geht es weiter mit dem Prüfdurchlauf aus Einen Einbruch erkennen und im Zweifel mit Die erste Stunde.
Geschrieben aus dem laufenden Betrieb: MRMedia betreibt eigene Hosts, Kundendienste und deren Härtung in der EU. Eine veraltete Anleitung ist hier ein Sicherheitsproblem, kein Schönheitsfehler. Korrekturen bitte über Discord.
