GPN20:Linux Security Monitoring mit Audit Events: Schmerzen reduzieren
Ein Vortrag von Hilko Bengen auf der GPN20.
Netzwerktraffic im Klartext ist eher zu einer Seltenheit geworden, das ist natürlich gut. Die Kehrseite der Medallie ist, dass für die Erkennung von Angriffen in Unternehmens- und anderen Netzwerken netzwerkbasierte Indikatoren an Bedeutung verloren haben und hostbasierte Indikatoren heute eine größere Rolle spielen. Wir wollen nicht nur schauen sondern sehen, sind aber nicht bereit, dafür auf jedem System eine Horde von Blockchain-AI-EDR-Agenten zu installieren. Also müssen wir etwas fürs Logging tun, und zwar mehr als die üblichen Authentifizierungs- und Autorisierungs-Events.
Für Windows gibt es hierfür das bei SysInternals entwickelte "Sysmon", es ist closed source aber kostenlos und kein von Microsoft unterstütztes Produkt. Auf Linux-Systemen haben wir dafür seit 15 Jahren mit dem Audit-Subsystem eine gut funktionierende aber leider schlecht verständliche Quelle der Wahrheit: Das textbasierte Logformat ist für typische SIEM-Systeme zu irregulär und schlecht zu parsen. Unterschiedliche Aspekte eines Events sind auf mehrere Zeilen verteilt; nun sind die üblichen SIEM-Systeme im Kern eher Suchmaschinen und nicht besonders gut darin, JOIN-Operationen auszuführen. Leider ist das alles kaum noch zu ändern, weil die Rohdaten direkt im Kernel-Code erzeugt werden und als Teil einer Kompatibilitätszusage verstanden werden.
Bestehende Lösungsansätze ersetzen ohne Not das bestehende auditd-Userland (go-audit, auditbeat), bringen große Performanceprobleme mit sich (auditbeat, osquery, Skriptsprachen) oder setzen mit eBPF ohne Not auf "shiny new tech", ohne daraus einen Erkenntnis- oder Performancegewinn zu ziehen (Sysmon for Linux).
Um die bestehenden Schmerzen zu lindern, ist [LAUREL](https://github.com/threathunters-io/laurel) als _auditd_-Plugin entstanden, das die Events in Echtzeit aufbereitet und in ein SIEM- und Analysten-verträgliches JSONlines-Format kodiert. Dabei kommt LAUREL auch bei hoher Event-Rate mit vertretbarem CPU-Overhead aus.
War es ursprünglich als reines Umkodierungstool gedacht, fallen nach der ersten produktiven Bewährungsprobe natürlich weitere Use-Cases auf, mit der wir uns z.B. über die Markierung von Prozess-Beziehungen die Arbeit erheblich ereleichtern können, ohne dass aus dem Plugin zur Log-Aufbereitungs gleich ein EDR-Agent mit zu vielen Rechten und Pflichten werden muss.