Linux-Sicherheitsmonitoring: auditd, journald und Sysmon for Linux

Linux-Sicherheitsmonitoring ist der blinde Fleck vieler Blue Teams, deren Erkennung stark auf Windows ausgerichtet ist. Dabei laufen die kritischsten Systeme oft unter Linux: Webserver, Datenbanken, Container-Hosts, die ganze Cloud-Infrastruktur. Ein Angreifer, der einen Linux-Server übernimmt, findet dort häufig weniger Überwachung vor als auf einem Windows-Client, und genau diese Lücke gilt es zu schließen. Dieser Beitrag zeigt die drei zentralen Logquellen unter Linux, was jede leistet und wofür sie zuständig ist, wie man sie konfiguriert und zentralisiert, und welche Erkennungen den größten Nutzen bringen. Er ist das Linux-Gegenstück zur Event-ID-Referenz, die den Windows-Teil abdeckt und im ausgebauten Abschnitt bereits auf auditd verweist.

auditd: die sicherheitsrelevanten Kernel-Ereignisse

Das Audit-System des Linux-Kernels, gesteuert durch den Dienst auditd, ist die wichtigste Sicherheitslogquelle unter Linux, das Gegenstück zum Windows-Sicherheitsprotokoll. Es protokolliert auf Kernel-Ebene, was auf dem System geschieht, und es tut das anhand von Regeln, die man selbst festlegt. Die wertvollsten Ereignisse: die Ausführung von Programmen (welcher Prozess, mit welcher Befehlszeile, von welchem Benutzer), Zugriffe auf sicherheitskritische Dateien (die Passwortdatei, die Konfiguration der Benutzer, die SSH-Schlüssel), Änderungen an Rechten und Benutzern, und die Nutzung privilegierter Systemaufrufe. Wie bei Sysmon unter Windows entscheidet die Regelkonfiguration über den Nutzen: Ohne Regeln protokolliert auditd wenig, mit zu vielen Regeln erzeugt es eine Flut. Als Ausgangspunkt haben sich gepflegte Regelsätze etabliert, etwa der an die Vorgaben verschiedener Standards angelehnte Satz von Florian Roth, den man wie eine Sysmon-Referenzkonfiguration übernimmt und an die eigene Umgebung anpasst. Die auditd-Ereignisse sind roh und schwer lesbar, weshalb sie im SIEM aufbereitet werden müssen, aber sie sind die verlässlichste Quelle für das, was ein Angreifer auf dem System tut.

journald: die System- und Dienstprotokolle

Der zweite Baustein ist journald, das zentrale Protokollsystem von systemd, das auf fast jeder modernen Linux-Distribution läuft. Es sammelt die Protokolle des Systems und der Dienste an einem Ort: die Anmeldungen (auch die fehlgeschlagenen), die Aktivität von sudo, das Starten und Stoppen von Diensten, die Meldungen von SSH und den Anwendungen. Wo auditd die Kernel-Ebene abdeckt, deckt journald die Dienst- und Anwendungsebene ab, und beide zusammen ergeben das Bild. Für die Sicherheit besonders wichtig sind die Anmeldeereignisse und die sudo-Nutzung: Eine fehlgeschlagene Anmeldeserie ist der Linux-Ausdruck des Password Sprayings, und eine ungewöhnliche sudo-Nutzung deutet auf einen Versuch der Rechteausweitung. journald ist leichter lesbar als auditd, aber es lässt sich vom Angreifer mit Rechten auch leichter manipulieren, weshalb die Weiterleitung an ein zentrales System hier besonders zählt.

Sysmon for Linux: die ATT&CK-orientierte Telemetrie

Microsoft hat Sysmon auf Linux portiert, und Sysmon for Linux liefert dort dieselbe Art detaillierter, auf ATT&CK ausgerichteter Telemetrie wie unter Windows: Prozesserstellung mit vollständiger Befehlszeile und Elternprozess, Netzwerkverbindungen mit dem verursachenden Prozess, Dateiänderungen. Es baut technisch auf demselben Audit-Unterbau auf, liefert die Daten aber im vertrauten, gut strukturierten Sysmon-Format, das sich mit denselben Sigma-Regeln auswerten lässt wie die Windows-Variante. Der praktische Vorteil: Wer bereits Sysmon-Erkennungen unter Windows betreibt, kann viele davon auf Linux übertragen, und die Telemetrie ist konsistenter und leichter zu korrelieren als die rohen auditd-Ereignisse. In der Praxis nutzen viele Teams eine Kombination: auditd oder Sysmon for Linux für die Prozess- und Dateiebene, journald für die Dienste, alles zentral zusammengeführt.

Zentralisieren und schützen

Das Prinzip ist dasselbe wie im Beitrag zu Log-Management und Aufbewahrung: Ein Log, das nur lokal auf dem System liegt, ist im Vorfall wertlos, weil der Angreifer es kontrolliert. Die Linux-Logs müssen so schnell wie möglich an ein zentrales SIEM weitergeleitet werden, per Agent oder über die Weiterleitungsfunktion der Protokollsysteme. Das ist unter Linux besonders wichtig, weil ein Angreifer mit Root-Rechten die lokalen Logs vollständig kontrolliert: Er kann journald-Einträge löschen, die auditd-Regeln ändern oder den Dienst stoppen. Genau dieses Abschalten gehört überwacht, denn das Stoppen von auditd oder das Löschen der Protokolle ist selbst ein starkes Alarmsignal. Was schon im SIEM liegt, bevor der Angreifer aufräumt, ist gerettet, und die Manipulation der lokalen Protokollierung wird zur Erkennung.

Die wichtigsten Erkennungen

• Persistenz. Neue oder geänderte Einträge in den Autostart-Mechanismen: cron-Jobs, systemd-Dienste und Timer, die Profildateien der Shell, geänderte SSH-Schlüssel in authorized_keys. Das ist die Linux-Entsprechung der Persistenz-Erkennung unter Windows.
• Rechteausweitung. Ungewöhnliche sudo-Nutzung, das Setzen von SUID-Bits, der Missbrauch bekannter Rechteausweitungspfade und verdächtige Aufrufe, die aus einem Dienstkonto heraus eine Root-Shell öffnen.
• Ungewöhnliche Prozessausführung. Ein Webserver-Prozess, der plötzlich eine Shell startet, ein Interpreter, der aus einem Upload-Verzeichnis läuft, oder die typischen Werkzeuge der Angreifer. Das ist das Linux-Gegenstück zum ungewöhnlichen Elternprozess aus dem Threat-Hunting-Beitrag.
• Ausgehende Verbindungen. Ein Serverdienst, der eine ausgehende Verbindung zu einem ungewöhnlichen Ziel aufbaut, ist oft der Command-and-Control-Kanal oder der Datenabfluss, sichtbar in der Netzwerktelemetrie von Sysmon for Linux.
• Manipulation der Protokollierung. Das Stoppen von auditd, das Leeren der Journale oder das Ändern der Audit-Regeln, jeweils ein sofortiger Alarm, weil es fast nie einen legitimen Grund hat.

Der Einstieg

1. Eine Prozess- und Dateiquelle wählen. Entweder auditd mit einem gepflegten Regelsatz oder Sysmon for Linux, je nachdem, ob man das rohe Kernel-Audit oder das strukturierte Sysmon-Format bevorzugt. Wer schon Sysmon unter Windows nutzt, hat mit Sysmon for Linux den kürzeren Weg.
2. journald mitnehmen. Die Anmelde-, sudo- und Dienstereignisse aus journald ergänzen die Prozessebene und sind schnell angebunden.
3. Zentral weiterleiten. Alles ins SIEM, so schnell wie möglich, und die auditd-Ereignisse dort in eine lesbare Form bringen.
4. Auf die Kern-Erkennungen abzielen. Mit den oben genannten anfangen, Persistenz, Rechteausweitung, ungewöhnliche Prozesse und die Manipulation der Protokollierung, statt zu versuchen, alles auf einmal abzudecken.
5. Testen. Mit Atomic Red Team, das auch Linux-Techniken abdeckt, im Homelab prüfen, ob die erwarteten Ereignisse ankommen und die Regeln greifen.

Fazit

Linux-Sicherheitsmonitoring schließt den blinden Fleck vieler Windows-lastiger Blue Teams. Die drei Logquellen greifen ineinander: auditd für die sicherheitsrelevanten Kernel-Ereignisse, journald für die System- und Dienstprotokolle, Sysmon for Linux für die strukturierte, ATT&CK-orientierte Telemetrie, die sich mit denselben Sigma-Regeln auswerten lässt wie unter Windows. Wie überall gilt: Die Konfiguration entscheidet über den Nutzen, die Rohdaten müssen sofort zentralisiert werden, bevor der Angreifer sie löscht, und die Erkennung zielt auf Persistenz, Rechteausweitung und ungewöhnliche Prozesse. Für ein Blue Team ist die Linux-Überwachung kein Sonderthema, sondern die Übertragung der vertrauten Prinzipien auf die Systeme, die oft die wertvollsten im Netz sind. Das dritte Betriebssystem behandelt der Beitrag zum macOS-Sicherheitsmonitoring.