Einführung
In den Bereichen Systemadministration und Cybersicherheit ist die Protokollanalyse eine entscheidende Fähigkeit. Systemprotokolle zeichnen eine breite Palette von Ereignissen auf, von Routineoperationen über kritische Fehler bis hin zu potenziellen Sicherheitsverletzungen. Die Fähigkeit, diese Protokolle effektiv zu durchsuchen und zu interpretieren, ist unerlässlich für die Überwachung der Systemgesundheit, die Fehlerbehebung und die Reaktion auf Sicherheitsvorfälle.
Dieses Lab führt Sie in journalctl ein, das Standardwerkzeug zum Abfragen und Anzeigen von Protokollen des journald-Dienstes auf modernen Linux-Systemen. Sie lernen, grundlegende Protokollanalysetätigkeiten durchzuführen, die die Grundlage für Überwachung und Vorfallsreaktion bilden.
Während dieses Labs werden Sie:
- Systemstartprotokolle überprüfen.
- Protokolle filtern, um spezifische Ereignisse wie fehlgeschlagene Authentifizierungen zu finden.
- Ein verdächtiges Ereignis simulieren und erkennen.
- Protokolle für weitere Analysen exportieren.
System-Boot-Protokolle mit Journalctl überprüfen
In diesem Schritt lernen Sie, wie Sie den Befehl journalctl verwenden, um Systemprotokolle zu überprüfen, insbesondere die Meldungen, die während des letzten Bootvorgangs generiert wurden. Dies ist ein üblicher erster Schritt bei der Diagnose von Startproblemen.
Der Befehl journalctl ermöglicht es Ihnen, den Inhalt des systemd-Journals abzufragen. Ohne Argumente zeigt er alle Protokolle an, was überwältigend sein kann.
Um die Ausgabe überschaubarer zu gestalten, können wir die Option -b oder --boot verwenden, um nur die Protokolle der aktuellen Boot-Sitzung anzuzeigen.
Führen Sie den folgenden Befehl in Ihrem Terminal aus, um die Protokolle für den aktuellen Bootvorgang anzuzeigen:
journalctl -b
Sie sehen eine seitenweise Ausgabe, die mit den frühesten Meldungen des Bootvorgangs beginnt. Sie können die Pfeiltasten Auf und Ab zum Navigieren verwenden. Drücken Sie q, um den Pager zu verlassen und zur Eingabeaufforderung zurückzukehren.
-- Journal begins at Tue 2023-10-31 08:30:00 UTC, ends at Tue 2023-10-31 09:00:00 UTC. --
Oct 31 08:30:01 labex-vm kernel: Linux version 5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: KERNEL supported cpus:
Oct 31 08:30:01 labex-vm kernel: Intel GenuineIntel
Oct 31 08:30:01 labex-vm kernel: AMD AuthenticAMD
...
(END)
Dieser Befehl ist von unschätzbarem Wert, um zu verstehen, welche Dienste erfolgreich gestartet wurden, und um Fehler zu identifizieren, die während des Systemstarts aufgetreten sind.
Protokolle nach fehlgeschlagenen Authentifizierungen filtern
In diesem Schritt filtern Sie das Journal, um spezifische Ereignisse wie fehlgeschlagene Authentifizierungsversuche zu finden, die für die Sicherheitsüberwachung von entscheidender Bedeutung sind. Ein häufiges Ziel für Angreifer ist der SSH-Dienst, daher hat die Überwachung seiner Protokolle eine hohe Priorität.
Wir können die Option -u mit journalctl verwenden, um Protokolle nach einer bestimmten systemd-Einheit zu filtern. Für den SSH-Dienst ist die Einheit typischerweise ssh.service (auf Ubuntu/Debian) oder sshd.service (auf Red Hat/CentOS).
Filtern wir die Protokolle, um nur die Einträge anzuzeigen, die sich auf den SSH-Daemon beziehen. Beachten Sie, dass Sie möglicherweise sudo verwenden müssen, um Systemprotokolle anzuzeigen:
sudo journalctl -u ssh
Dieser Befehl zeigt alle Protokolleinträge an, die vom sshd-Dienst generiert wurden. Um unsere Suche auf potenzielle Sicherheitsprobleme einzugrenzen, können wir diese Ausgabe an den grep-Befehl weiterleiten, um nach Schlüsselwörtern wie "Failed" zu suchen.
Führen Sie den folgenden Befehl aus, um fehlgeschlagene Passwortversuche für den SSH-Dienst zu finden:
sudo journalctl -u ssh | grep "Failed password"
Wenn es keine kürzlichen fehlgeschlagenen Anmeldeversuche gab, liefert dieser Befehl möglicherweise keine Ausgabe. Dies ist auf einem sicheren System normal. Im nächsten Schritt werden wir selbst ein solches Ereignis generieren, um zu sehen, wie es in den Protokollen erscheint.
Verdächtigen Vorfall simulieren und Protokolle analysieren
Lassen Sie uns nun ein verdächtiges Ereignis simulieren und es dann mit unseren Fähigkeiten zur Protokollanalyse erkennen. Ein häufiges Anzeichen für einen Brute-Force-Angriff ist eine Reihe von fehlgeschlagenen Anmeldeversuchen. Wir simulieren einen solchen Versuch, indem wir versuchen, uns mit einem nicht existierenden Benutzernamen auf unserer eigenen Maschine (localhost) per SSH anzumelden.
Führen Sie den folgenden Befehl in Ihrem Terminal aus. Sie werden nach einem Passwort gefragt; Sie können alles eingeben, da erwartet wird, dass es fehlschlägt.
ssh non_existent_user@localhost
Das System wird die Verbindung verweigern, was das erwartete Ergebnis ist. Sie sollten eine Meldung wie diese sehen:
non_existent_user@localhost's password:
Permission denied, please try again.
non_existent_user@localhost's password:
Permission denied (publickey,password).
Nachdem wir nun ein fehlgeschlagenes Anmeldeereignis generiert haben, führen wir unseren Protokollanalysebefehl aus dem vorherigen Schritt erneut aus, um zu sehen, ob wir es finden können.
sudo journalctl -u ssh | grep "Failed password"
Dieses Mal sollte der Befehl eine Ausgabe erzeugen, die den gerade gemachten fehlgeschlagenen Versuch anzeigt.
Oct 31 09:15:12 labex-vm sshd[1234]: Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2
Diese einfache Übung demonstriert den Kernablauf der Vorfallreaktion: Ein Ereignis tritt auf, es wird protokolliert, und ein Administrator oder ein automatisiertes System analysiert die Protokolle, um es zu erkennen.
Protokolle für die Simulation zentralisierter Analysen exportieren
In einem realen Szenario würden Sie oft Protokolle von einzelnen Maschinen auf einen zentralen Protokollserver (wie ein SIEM) exportieren, um sie langfristig zu speichern und zu korrelieren. In diesem Schritt simulieren wir dies, indem wir unsere aktuellen SSH-Protokolle in eine Datei exportieren.
journalctl kann Protokolle in verschiedenen Formaten ausgeben. Das Format json-pretty ist besonders nützlich, da es sowohl für Menschen lesbar als auch leicht von anderen Werkzeugen zu parsen ist.
Exportieren wir alle SSH-Protokolle der letzten 10 Minuten in eine Datei namens ssh_logs.json in Ihrem aktuellen Verzeichnis (~/project).
sudo journalctl -u ssh --since "10 minutes ago" -o json-pretty > ~/project/ssh_logs.json
Überprüfen Sie nun, ob die Datei erstellt wurde:
ls -l ~/project
Sie sollten ssh_logs.json in der Dateiliste sehen.
total 4
-rw-r--r-- 1 labex labex 1234 Oct 31 09:20 ssh_logs.json
Schließlich betrachten wir den Inhalt unserer exportierten Protokolldatei.
cat ~/project/ssh_logs.json
Die Ausgabe ist ein strukturierter JSON-Array, wobei jeder Protokolleintrag ein Objekt ist. Dieses Format ist ideal für die Aufnahme in andere Analyseplattformen.
[
{
"__CURSOR" : "s=...",
"__REALTIME_TIMESTAMP" : "...",
"__MONOTONIC_TIMESTAMP" : "...",
"_BOOT_ID" : "...",
"_TRANSPORT" : "syslog",
"PRIORITY" : "6",
"SYSLOG_FACILITY" : "4",
"SYSLOG_IDENTIFIER" : "sshd",
"MESSAGE" : "Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2",
"_PID" : "1234",
...
}
]
Sie haben erfolgreich den Prozess der Vorbereitung von Protokollen für die zentrale Analyse simuliert.
Zusammenfassung
In diesem Lab haben Sie praktische Erfahrungen mit journalctl gesammelt, einem leistungsstarken Werkzeug zur Protokollanalyse auf modernen Linux-Systemen. Dies sind grundlegende Fähigkeiten für jeden Systemadministrator, DevOps-Ingenieur oder Sicherheitsexperten.
Sie haben gelernt, wie Sie:
- System- und Boot-Protokolle überprüfen, um Startprobleme zu diagnostizieren.
- Protokolle nach spezifischen Diensten und Nachrichteninhalt filtern, um relevante Ereignisse zu finden.
- Verdächtige Aktivitäten, wie fehlgeschlagene Anmeldungen, aus Protokolleinträgen identifizieren.
- Protokolle in einem strukturierten Format wie JSON für die zentrale Speicherung und weitere Analyse exportieren.
Die Beherrschung dieser Techniken wird es Ihnen ermöglichen, Ihre Systeme besser zu überwachen, Probleme effizienter zu beheben und die ersten Schritte bei der Reaktion auf Sicherheitsvorfälle zu unternehmen.
