 Hallo und guten Abend auf der GPN 20. Ich heiße Hilko Beng, herzlich willkommen. Ich möchte heute Abend mit uns über die Reduktion von Schmerzen reden, die beim Auditing und Monitoring von Systemen entsteht. Hilko arbeitet in einem SERT und beschäftigt sich beruflich, damit Eindringenden und Inzidenz in Systemen zu erkennen, zu monitoringen und nachzuverfolgen und hat während dieser Forschung dazu ein Monitoring System entwickelt und möchte uns das heute vorstellen. Hilko, vielen Dank, dass du da bist. Ich wünsche euch allen viel Spaß beim Talk. Und ja, los geht's, würde ich sagen. Ja, danke für die nette Vorstellung. Und danke, dass ihr alle so zahlreich erschienen seid. Ich habe mich nicht damit gerechnet, dass es auf solches Interesse stoßen würde. Ja, es geht um die Reduktion von Schmerzen bei Monitoring. Aber in dieser Situation des Schmerzes muss man sich ja auch erst mal begeben haben. Wie kommt man dahin? Also man möchte gezielte Angriffe auf meistens Unternehmensnetzwerke, aber auch andere Netzwerke erkennen. Man will diese Angreifer möglichst frühzeitig erkennen, um sie dann mit geeigneten Maßnahmen wieder rauszuschmeißen und eben zu verhindern, dass die Angreifer einen Erfolg davon tragen können. In den letzten Jahren, also das eigentlich kein neuer Huts, das ist eigentlich ein ziemlich alter Hut, freien Netzwerkbasierte Ansätze sind da eher schwierig geworden. Also hat man vielleicht Bro, heutzutage Sieg, Suricata verwendet, um verdächtigen Netzwerk-Traffic zu erkennen und da dann irgendwie Aktionen raus abzuleiten, was man dann tun muss. Das ist deswegen schwieriger geworden, weil halt heute sehr viel Netzwerk-Traffic verschlüsselt ist, eigentlich eine gute Sache. Und Angreifer machen sich das natürlich auch zu Nutze und verwinden einfach das HTTPS-Protokoll als Tunnel-Everything-Protokoll. Da hatten wir dann also als Verteidiger nicht mehr so viele gute Karten. DNS geht noch ein bisschen was, aber auch das wird schwieriger mit DNS hoher HTTPS, da überhaupt noch etwas zu sehen. Also muss man den Blickwinkel ein bisschen verlagern. Man guckt sich da eher die potenziell angegriffenen Systeme an, die Endpoints und versucht eben dort Events, die man auswertet, zu generieren und die dann in ein Siem zu verfrachten, dort nach Regeln setzen, auszuwerten. Und das möglichst zeitnah. Das, was ich auf einem Linux-System klassischerweise habe, also das, was in einem Syslog landet, ist dafür einfach viel zu wenig. Man will, ich gebe mal ein Beispiel, zum Beispiel erkennen können, wenn ein Angreifer eine Web-Stelle irgendwo hintroppt und darüber was ausführt. Also solche feinerrandulare Events wirst du in einem Syslog nicht finden. Du wirst auch Probleme haben, die in den Web-Server-Access-Logs irgendwie wiederzuerkennen, wenn du nicht ganz gezielt nach spezifischen Angriffen suchst. Aber wir wollen eigentlich generisch, möglichst generische Erkennungsmethoden haben, um die eigentlich die Angreifer dann auch nicht so sehr einfach drum herumkommen. Also wie gesagt, Syslog ist zu wenig. Man kann auf einer viel niedrigeren Ebene, kann man protokollieren. Auf Windows-Seite gibt es da seit Jahren, am Jahrzehnten muss man sagen, das Sysmon, das von Sysinternals, das mittlerweile zum Microsoft gehört, seit vielen Jahren entwickelt worden ist, wo man so Erkzonen erkennen kann, wie Prozess wurde gestartet mit diesen und jeden Parametern. Dateien wurden angelegt, Netzwerkverbindungen, ganz primitive Sachen. Das geht auf Linux, geht das im Prinzip auch, und zwar mit dem Ordet-Subsystem. Das Ordet-Subsystem funktioniert so, Administrator konfiguriert Regelsätze, was der Kernel denn alles über eine Logging-Schnittstelle mitteilen soll, z.B. in Syscall-Events oder im Datei-System-Operation. Datei-System-Operationen haben wegen dieses Paradigmas everything is a file, natürlich in einen gewissen Charme. Also wenn ich bestimmte Konfigurationsdateien schreibe, dann kann ich zumindest diesen Open-Call, der dazu führt, dass eine Datei schreiben geöffnet wird, den kann ich protokollieren lassen. Und wenn das irgendwelche speziellen interessanten Konfigurationsdateien sind oder in den interessanten Farben liegen, da kann man halt schöne Regelsätze drauf bauen. Dieser Regelsatz, der wird vom Administrator festgelegt, also was wird protokolliert? Der Kernel schreibt dann, wenn so ein Syscall ausgeführt wird oder ein Datei angefasst wird oder Dateien ausgeführt werden, schreibt da entsprechend Einträge, Audit-Einträge und die werden über einen dedizierten Users-Basedeam in Audit.D werden die entgegengenommen. Der Audit, die liest das, führt gegebenenfalls eine einfache Übersetzung durch. Man muss dazu sagen, das meiste, was aus dem Kernel kommt, ist schon ein textbasiertes Protokoll. Kommen wir gleich nochmal darauf zu sprechen, weil da liegen so ein bisschen die Schmerzen auch. Aber der Audit, der liest es halt, schreibt es in ein Lockfile, rotiert es und dann gibt es dann auch eine Möglichkeit, eigene Programme einzuhängen, die diese Events auch erhalten. Wenn man das entsprechend konfiguriert, dann können auch User IDs, Sock-Address-Strukturen, Group IDs steht hier auch, die Syscalls, die kommen eigentlich auch nur als Nummern, weil der Kernel intern natürlich nur mit Zahlen operiert. Auch wenn das dann als Text formatiert hat, intern sind es nur Zahlen und auch User IDs sind für den Kernel halt nur Zahlen. Also wenn mein User Hilco, der ist auf meiner Workstation hier, ist dann die 100.000 und der Kernel, der weiß von dem Namen nichts. Das muss man dann also übersetzen lassen. Also das bietet der Audit hier auch schon an. Und schließlich können bestimmte Userspace-Programme, also Sie können dieses Audit-System für eigenes Logging mitverhalten, so gut ein Logging-Programm und User-Add und viele andere mehr tun das, um so einfache Aktionen mitzuprotokollieren. Das geht dann einmal durch den Kernel, landet dann auch im Audit und wurde auf dem Weg noch angereichert durch eine User ID. Aber das sind alles Details. Das sehen wir vielleicht im Beispiel gleich normal ein bisschen. Es sind halt nicht nur Schmerzen, auch wenn ich anfangs über Schmerzen gesprochen habe, oder es eben darum geht, Schmerzen zu vermeiden. Also das System an sich ist gut oder es ist ziemlich brauchbar. Das erste Gute daran ist, dass es einfach hervorhanden ist. Es ist auf Linux-Systemen seit 15 Jahren oder länger, ist es einfach verfügbar. Es ist irgendwann mal in den 2000ern bei Red Hat entwickelt worden und in jeder Distribution dann irgendwann mit aufgenommen worden. Die eigentliche Informationsquelle, bis auf dieses User-Space-Logging, ist der Kernel. Also wenn man den Kernel vertraut, dann kann man davon ausgehen, dass die Informationen, die da wegprotokolliert worden sind, integer sind und dass da nicht irgendwie mit rumgefroren worden ist. Der Informationsgehalt, würde ich sagen, ist grob vergleichbar mit Systemen für Windows. Es gibt mittlerweile auch ein System für Linux, aber das ist featuremäßig. Es ist längst nicht so weit wie das Windows-Bondon. Ich glaube, es ist eher so ein Checklisten-Produkt gewesen. Oder Checklisten-Projekt. Diese Regelsätze, mit denen man Audit die konfiguriert oder eigentlich konfiguriert man den Kernel, was er eben zu protokollieren hat, die sind ganz gut verstanden. Hier habe ich ein paar Anregungen angegeben, was man sich angucken kann. Was ganz interessant ist, sind diese Vorgaben oder Richtlinie vom Center for Internet Security, wenn man überhaupt keine Ahnung hat, was man tut, um Linux-System zu härten, sind die gar nicht verkehrt. Es gibt ganz gute Unterstützung dann noch für lokale Analyse und Reporting-Werkzeuge, aber es sind eben lokale Analyse und Reporting-Werkzeuge. Das ORT-Chase ist so ein bisschen ein Pondon zu S-Trace, das eben dieses Audit-Subsystem mitverwendet, um zu protokollieren, was einzelne Prozesse nicht tun. Und es braucht halt keine Debackschnittstelle dafür. Aber jetzt kommen wir zu den Schmerzen. Ich hatte schon angedeutet, das Format, das Lokformat, das aus dem Kernel fällt, das ist textbasiert und es ist ein bisschen erregulär. Es ist auf gar keinen Fall dazu geeignet, dass man das irgendwie von einem Menschen vorwirft. Zum Teil sind so Binärdaten, kommen wir gleich nochmal drauf. Die werden einfach dann hexcodiert und da ist halt von diesem Vorteil von textbasiertem Logging, ist da nichts mehr da. Und da das ja so Teil der Kernel-Userschnittstelle ist, kann man da auch nichts mehr dran ändern praktischerweise. Man könnte das Ganze neu bauen, irgendwelche Custom-Formate sich ausdenken, die dann schließlich, die dann irgendwie als Binärdaten aus dem Kernel kommen, aber das würde halt große Änderungen bedeuten. Ich glaube nicht, dass es jemand tun wird. Für diese Events, diese Events können halt unterschiedliche Aspekte haben und die muss man dann zusammenfassen. Also es steht vorne immer eine Event-ID dran und so ein Syscall-Event mag irgendwie mit Faden handieren oder ein X-ACV-E, ein X-ACV-E-Syscall, der hat dann noch ein extra Message dabei, wo drin steht, was für ein Programm denn eigentlich ausgeführt wird, solche Dinge, die muss man zusammenfassen über die Event-ID. Weil wenn man das Ganze in ein Siem pumpt, dann wird es schlimm, weil die meisten modernen Siemesysteme sind im Kern eigentlich Volltext-Duchmaschinen und sie sind nicht so besonders gut darin, so Join-Operationen, wie man sie von Daten manken kennt, durchzuführen. Man kann das zwar tun, aber es wird sehr schnell sehr langsam und man wird damit nicht glücklich und da gibt es ein paar Lösungsansätze dafür, dass das Rohformat ist jedenfalls da nicht so das gelbe vom Ei. Datenmenge spielt sicherlich auch eine Rolle, je nachdem wie viel Münzen man bei Splunk eingeworfen hat, kann einem das aber relativ egal sein. Und diese Reporting-Werkzeuge, die ich gerade erwähnt hatte, die müssen halt lokal laufen für so einen Siembetrieb, sind die auch nicht geeignet. Kommen wir zum ersten Beispiel. Wir wollen uns melden lassen, wenn Konfigurations-Dateien, die uns besonders wichtig sind, in diesem Fall halt die Konfiguration für Sudow, wenn da jemand was dran ändert. Also machen wir zwei Regeln. Einmal eine Regel dafür, dass das protokolliert wird, wenn die Datei etc. Sudow selbst geändert wird und die zweite, wenn in etc. Sudow SD, in einem Verzeichnis irgendwo eine Datei geschrieben wird. Diese Protokollierung sieht dann so aus wie unten angegeben. Also unten ist das ganze Event, was zu dem Open-Event gehört. Also der Angreifer hat jetzt ausgeführt, die ITC Sudow SD Backdoor, die komische Schreibweise mit den umlautenden Absicht. Denn da sehen wir schon, dass in dem zweiten Path-Eintrag der Name total verhackstückt wird. Also eigentlich ist er nicht verhackstückt worden, sind alle Informationen noch da, alles kein Problem. Aber richtig lesbar ist das halt nicht und richtig gerettbar und automatisch in der Volltextsuche zu verarbeiten, ist das halt auch nicht. Da muss man also ein bisschen Post-Processing machen. Gehen wir mal auf die einzelnen Komponenten ein. Also das Tee können wir sehen, gleich mehrfach, das Programm-Tee wird ausgeführt oder ist ausgeführt worden und taucht dann als Kontext in unserem Discord-Event auf. In der ersten Zeile, wir haben ein Event, wo wir das Current Working Directory dieses Aufrufs mitgeteilt bekommen. Das ist halt bei Aufrufen wie OpenEd ist das wichtig. Und ist das hier ein OpenEd? Ich glaube ja, ich sehe es gerade nicht. Ah, ich habe hier die Übersetzung nicht mit dabei. Sonst werde ich Slide noch unübersichtlicher geworden. Dieses Keyword-Scope, das wir oben in den Regeln angegeben haben, das landet mit in dem ersten Eintrag zumindest. Wir können also einfach darauf matchen auf das Keyword-Scope, aber wie gesagt, dieser Pfadname, den müssen wir dann nachverarbeiten. Am Ende ist noch dieses Prog-Titel-Stück-Daten. Das sind die ersten, ich glaube, 128-byte der Kommando-Zeile des gerade laufenden Programms. Also das Tee, dann ein 0-byte und dann das erste Argument in dem Fall. Was haben wir noch? Uns wird die Architektur mitgeteilt. Die Syscall-Nummer, die wir uns entsprechend konfiguriert hätten, würde uns die Architektur in x8664 übersetzen. Den Syscall würde es uns, glaube ich, in OpenEd übersetzen. Dann gibt es noch Syscall-Argumente, A0 bis A3. Hier fällt auf, dass die Syscall-Argumente sind eben in Hex-Darstellung. Das ist kein 0x davor. Man muss da schon ein bisschen Wissen mitbringen, um das richtig deuten zu können. Ich könnte jetzt sagen, die Zahl 257, das ist mir gerade unwichtig, wenn die sowieso übersetzt wird. Aber diese User ID, die AguID, die ist dann halt wieder Dezimal. ProzessID, Parent-ProzessID haben wir. In den Path-Teilen haben wir noch den File-Mode jeweils. Der ist in Octal. Also das ist ein schönes Durcheinander. Gibt es bisher Fragen? Gut, machen wir ein nächstes Beispiel. Angreifer ist auf dem System angekommen, ruft so eine PerlReverse-Shell, so ein Einzeiler auf. Dann haben wir auch wieder dieses ganze Event. In diesem Fall ist es ein EXEC-Event. Perl wird aufgerufen mit so einer langen guando-Zeile. Das ist hier umgebrochen, liegt daran, dass der Monitor zu schmal ist. Aber es ist eigentlich so ein klassischer Perl-Einziler. Wir haben da oben die IP-Adresse, zu der wir hinkonekten. Am Ende, wenn das gut gegangen ist, würde er halt eine Shell aufrufen, bin SH. Und davon sehen wir fast nichts wieder. Also das Perl sehen wir wieder. Das Minus E sehen wir noch. Aber der Rest ist halt auch wieder hexantizimal kodiert, weil, also da reicht dann auch schon ein Zeichen, dass das irgendwie eine besondere Bedeutung hätte, in dieser Syntagsvorstellung. Normale Strings, die gut darstellbar sind, oder die ohne Umkulierung darstellbar sind, die kriegen halt so kurze Zeichen drumherum. Wenn der String selber einen Quotzeichen enthält, dann wird das nicht etwa escape, sondern das ganze Ding wird einfach durch Hex-Encoling gejagt. Macht natürlich die Datenmenge auch nochmal größer. Ich habe hier dann mal auch farblich markiert, was da die IP-Adresse der Port ist. Und am Ende natürlich auch das bin SH. Das ist im Prinzip das, was uns als Verteidiger interessieren würde, um diese Reverse Shells zu erkennen. Na klar, kann man jetzt sagen, Angreifer kann sich dagegen natürlich schön wappnen, indem er dann in der Kommando-Zeile noch irgendwelches Adhoc-Encoding, Decoding macht, irgendwie auch Friskation. Für andere Friskated-Geschichten stehen wir hier eigentlich schon, haben wir hier schon ja ungünstige Grundvoraussetzungen. Dann gibt es da noch diesen blauen Teil, Einet Ato N. Der steht da am Ende, also da sieht man eben, dass dieses Prog-Titel, das ist wohl das, was man auch in der Ausgabe von PS sehen würde, das ist halt am Ende abgeschnitten. Das sind irgendwo so und so viel bei euch. Wie gesagt, ich glaube, ich glaube, es waren 128. Das ist also ja auch so optimal. Drittes Beispiel, aber das ist dann auch das letzte Beispiel. Anfang letzten Jahres gab es mal so eine Sudo-Schwachstelle, von der viele, die sich für Linus interessiert haben, von euch sicherlich gehört haben. Ein Logikfehler, den man letztlich mit einem Buffer Overflow verbinden konnte gefunden wurde da bei Qualys Labs und die hatten dann so eine einfache Prüfung veröffentlicht, die, glaube ich, auch in dem Schwachstellenscanner von Qualys eine Zeit lang verwendet wurde. Ist halt ein bisschen unschön. Man ruft Sudo-Added-minus-S Backslash und dann ein langes String auf, also das Perl steht in Backquotes. Wir kriegen da 64 Kilobyte, einfach große Ars. Und das Schöne ist bei dieser Orde, die Ausgabe, dass die ganzen 64 Kilobyte tatsächlich auch gelockt werden können. Also wie sinnvoll das dann mal einzulernen ist, ist so ein bisschen mal dahingestellt, aber uns gehen da erstmal keine Daten verloren. Wie sie dargestellt werden, ist halt großarmist. Auch hier habe ich es wieder farblich markiert. Wir sehen da hier das Sudo-Added, die Kommando-Zahlen-Argumente minus S und Backslash. Und ja, es gibt für dieses aufgespaltene Längenfeld, es sind eben mehrere Events, die man dann über diese Event-ID zusammenkorrollieren müsste. Für das lange Event gibt es dann halt netterweise noch eine Längenangabe. Wir wissen also, wie viele von diesen Zahlen wir erwarten können, wenn wir das pausen wollen. Und ja, da eben alles extra decimalkodiert ist, obwohl es für sich als Style-String wäre, dass alles in normalen Strings darstellbar ist, wird halt trotzdem alles verhext. Wir haben dann mit Kollegen uns im letzten Jahr irgendwann angefangen, nach Alternativen umzusehen, weil wir eben diesen Schmerz gespürt haben. Und es gibt ein paar Alternativen, die man Stadt-Order-D nehmen kann. Von Elastic gibt es dieses Order-Beat in Go geschrieben. Im Prinzip machen die schon keine komplett falschen Sachen. Sie fassen diese ganzen Eventfragmente zusammen anhand der Event-ID, packen das in den JSON und loggen das. Ist dann gut konsumierbar für Elasticsearch. Und im Prinzip kann man damit arbeiten, wie ihr jedoch nicht. Denn wir haben mal ein bisschen experimentiert, wie das auf System ist, die die hohe Last haben und wo Anwendungen drauflaufen, die aus riesigen Shell-Skripten irgendwelche Batch-Verarbeitung für Logistik-Gedöns machen. Bei irgendwie mehr als 100.000 XX pro Sekunde, weil es eben alles Shell ist, wirst du da nicht glücklich. Order-Beat schied einfach deswegen aus. Nicht alle unsere Systeme sind von dieser Eigenart, aber die wollen wir schon auch monitorn. Und wenn das nicht geht, dann geht das eben nicht. Go-Order ist von Slack auf den ersten Blick ein ähnlicher Ansatz. Macht auch eine JSON-Codierung der Events fast da die einzelnen Aspekte zusammen. Aber diese Aufbereitung, die man von Order-D in UserIDs in Namen und so weiter, das wird überhaupt nicht gemacht und auch dieses Zusammenfassen aus diesem Beispiel, das würde bei Go-Order gar nicht passieren. Also keine Umkotierung, nichts. Also geht in die richtige Richtung, ist aber eben nur halbherzig. Die beiden Projekte haben ein wichtiges anderes Problem. Sie sind nicht coexistenzfähig mit Order-D. Also es kann da nur ein Prozess geben, der diese Order-Events abnimmt. Und wer erwägten zu dem Zeitpunkt auf manchen Systemen als EDR Defender ATP für Linux einzusetzen und Defender ATP für Linux verwendet Order-D als eine Eventquelle. Oder dieses Order-Subsystem als eine Eventquelle. Das wäre daran gescheitert. Und wir wollten uns nicht darauf festnageln, also wir wollen uns diesen möglichen Weg nicht verbauen. Es ist letztlich anders gekommen, Defender ATP verwenden wir nicht. Aber ich will hier keine Rands über EDR-Produkte vom Sound brechen, das vielleicht nachher bei einem Bier oder einem Chunk oder in einem anderen Talk irgendwann mal. Ich hatte anfangs auf diese Plug-In-Schnittstelle hingewiesen. Das ist so dieses Dispatcher-Plug-In. Über diese Plug-In-Schnittstelle kann man eigene Programme starten lassen, die die gleichen Events bekommen wie Order-D, die sie in die Logfiles schreibt. Und da kann man dann im Prinzip tun, was man will und umkodieren, wie man will. Und da gibt es auch einige Projekte, die das versuchen, sogar mit Jason als einem Zielformat. Aber alles das, was ich gefunden habe, war entweder seit Jahren nicht gepflegt oder an das Crypt-Sprache geschrieben. Und wenn das Audit-Beat, das in Go geschrieben ist, schon an Performance-Problemen zusammen bricht, dann will ich da erst recht keinen Pearl oder Python haben. C oder C++ macht Respekt, weil es wäre halt schon schlecht, wenn gerade das Zert dafür verantwortlich gemacht würde, irgendwelche Sicherheitslücken in die große Infrastruktur gerissen zu haben und man darüber angeohnt wird. Wollten wir auch nicht so gern. OSpreer haben wir uns angeguckt, stellte sich auch schnell raus, das kann nicht mit Audit-D korrexistieren und hat eigentlich einen ganz anderen Ansatz, aber wir haben es mal ausprobiert. Die Audit-Logs sind für OSpreer halt nur eine Eventquelle und man fragt dann mit SQL-Syntags seine Flotte ab, wo gibt es denn den Prozess namens XY? Also sowas kann man damit machen und eine Eventquelle ist dafür eben audit, aber so einen kontinuierlichen Datenstrom zu erzeugen, den man zentral in einem Siem verarbeitet, das geht nicht. Schließlich kam noch, also das war nach, ich muss dazu sagen, die Qualifikation und unseren weiteren Entscheidungen. Sysmon für Linux kam dann irgendwann raus, verwendet EPPF Probes, schreibt das gleiche wunderschöne XML-Format, das auch die Windows-Variante schreibt. War zumindest, als es erschien, unglaublich unperformant, das hat sich danach geändert, aber so die Informationslage, die aus dem Sysmon für Linux rausfällt, ist auch nicht so toll. Wenn man jetzt tolles Tooling hat, das mit Windows schon gut kann und das Windows gut eingestellt ist und einfach das Gleiche ohne nachzudenken für Linux mitverwenden will, mag das was sein. So, dann dachten wir uns, warum nicht selber schreiben? Es ist ja eigentlich nicht viel zu tun. Man verwendet diese Dispatcher-Schnittstelle, liest von StandardIn die Events Pass, die eben kurz passen nach EventID zusammen, formatiert ein bisschen was um, vor allen Dingen diese hexkludierten Strings und die Zusammenfassung von langen exec.v.es und gibt das so als JSON-Format aus. Also, im Prinzip so eine ähnliche Idee auf der Ausgabe Seite, wie das was OrderedBeat auch macht. Und dann haben wir mal Prototypen gebaut. Mit Go wurde ich schnell unglücklich. Ich wäre gern dabei geblieben, aber es stellte sich halt raus, dass der bei hoher Last der garbage-collector einem in die Suppe spuckt. Und, ja, man kam halt schnell an einen Punkt, wo der Code, den man was man so an Logik geschrieben hatte, um es dann per Formant zu bekommen, das Resultat war dann nicht mehr wartbar. Ich bin auf einigermaßen akzeptable Zahlen angekommen. Aber damit wollte man dann nicht weiterarbeiten. Ein zweiter Prototyp war Rust. Pasa Generator musste ein anderer sein, weil RegalStateMachineCompiler keinen Rust-Backend hatte. Aber ich habe eine Alternative gefunden auf Rust-Macro-Basis, zumindest für den Prototypen, dass ich da so die Kramatik nicht mehr ausgedacht hatte für dieses irreguläre Format weitestgehend weiterverwenden konnte. Performance war aus dem Stand besser, als das, was ich mit Go in 3-4 Wochen Profiling erreicht hatte, liegt vor allen Dingen daran, dass keine Zeit mehr im garbage-collector verbracht wurde. Dieser JSON-Encoder, der quasi Standard, den man bei Rust verwendet, nämlich SeriD, der hat da gute Arbeit geleistet. War ich sehr zufrieden mit und bin es auch immer noch. Die beiden Prototypen haben wir dann weggeworfen. Aber dann irgendwann was Produktiv, Produktionsreifes entwickelt. Das Ding heißt Laurel. Tut das, was ich jetzt schon dreimal erzählt habe, also das Parson codieren nach JSON. Dort wohnen nötig oder sinnvoll, wenn man noch Informationen aus dem Proc-Datei-System dazu geholt. Ich kann umgebungsvariablen loggen, also die würden dann in dem Fall aus dem Proc-Datei-System kommen, zum Beispiel so diese LD-Preload-Angriffe zu erkennen. In this privilege-Prinzip, dazu habe ich noch gar nichts gesagt. Also der OrderD läuft als Route. Und die Plugins, die von OrderD nachgestartet werden auch. Aber das lassen wir dann nach der Setup-Phase bleiben. Wir laufen als unprividigierte User weiter und behalten nur die Rechte bei, die wir eben zum Lesen des Proc-Datei-Systems brauchen. Ein operationelles Problem, das wir mit OrderD hatten, war den Admins beizubringen, dass sie den OrderD so konfigurieren müssen, dass unser Splunk-Universal-Forwarder das Resultat dann auch lesen kann. Ihr glaubt nicht, wie viel Rennerei man damit haben kann. Und vor allen Dingen, das dann irgendwie fernzudiebacken, wenn man sich diese Arbeit sparen kann, dann spart man sich die. Und dadurch, dass wir von vornherein brauchbare Permissionssätzen, ist das Problem eigentlich gegessen. Diese Zahlenwerte, wie ich vorhin angerissen hatte, also Hexadezimal, Octal, Dezimal, das wird klar ausgezeichnet mit den entsprechenden Präfixes, 0x, 0o, die man so kennt. Zahlenwerte sind dann da auch tatsächlich Jason-Zahlen. Floats kommen nicht vor. Insofern ist das alles kein Problem. Das Ganze ist unter der GPL3-Lizenz veröffentlicht. Resultat kann dann so aussehen. Also hier haben wir wieder unseren schönen Pearl-Einziler. Und man kann hier erkennen, in einem XC4e-Teil, dass wir da eben die die IP-Adresse, insbesondere die IP-Adresse, insbesondere den Port, und eben das BNSH. Am Ende klar leserlich dargestellt bekommt. Also klar leserlich, wenn man jetzt mal von Jason String-Codierung absieht. Das ist aber auf jeden Fall etwas, was man im Sieben direkt weiterverarbeiten kann, ohne da irgendwelche Umkodierung machen zu müssen. Was kann man noch erwähnen? Ja gut, es hängt eben alles an, es ist eben alles ein Dokument. Es wird alles auf einer Zeile ausgegeben. Ich habe das jetzt hier nur umgebrochen, damit das gut auf die Slide passt. Oben eben diese Message-ID. Und alles andere ist, so würde ich mittlerweile denken, aber vielleicht bin ich da auch Betriebsblind geworden, selbst erklären. Gibt es dazu Fragen? Nicht. Okay. Dann noch ein bisschen was zu Performance. Einige dieser Messungen, die hier zu sehen sind, sind in dieser Prototypenphase schon gemacht oder vor der Prototypenphase. Man sieht eben ganz deutlich diese gelbe Linie. Audit Beat war, falls es ihm vor, Sysmon für Linux rauskam, war damals wirklich der schlechteste Kandidat. Mittlerweile ist Sysmon für Linux, nachdem jemand Performance gefunden hatte, steht es etwas besser da als Audit Beat. Wir haben hier eine grüne und eine blaue Linie. Einmal Audit D. Ohne diese Übersetzung von User IDs-Innahmen und so weiter. Und Audit D. Mit dieser Übersetzung, dieses Enriched Format, die braucht halt ein bisschen mehr CPU-Huf. Umsonst ist das halt nicht zu haben. Go Audit, irgendwo dazwischen sieht also gar nicht so schlecht aus, aber Go Audit macht halt überhaupt keine Übersetzung. Audit D. Plus Laurel in einer früheren Version. Wir sind mittlerweile ein bisschen weiter. Sieht da gar nicht so schlecht aus. Also das, vielleicht ist es auch noch Performance zu finden. Müssen wir mal gucken. Gemessen ist das alles auf einer AWS EC2-T2. Small Instance. Also das waren wirklich vergleichbare Verhältnisse und was ich eben gemacht hatte, um die Last zu generieren, in einer so schnell wie es ging oder eigentlich eher so schnell, wie es gewünscht war, so ein Binshow zu starten. Immer wieder, immer wieder, immer wieder. 60.000 mal die Sekunde, 60.000 mal die Minute und dann eben die Counter für CPU, User-CPU-System vorher nachher zu vergleichen. Also kein großes Hexenwerk eigentlich. Man sieht da nach rechts hin auch, die Linien so ein bisschen abknicken. Also bei Ordered Beat viel, viel früher. Da war einfach alles an CPU-Zeit auf der Instanz schon ausgelastet und man kann auch davon ausgehen, dass an der Stelle schon Events verloren gegangen sind. Aber wie gesagt, diese 1000 X6 pro Sekunde ist wirklich etwas, was wir auf einigen von uns zu überwachtenden Systeme sehen und deswegen muss so eine Nachverarbeitung von Ordered Events da eben auch mithalten können. Das war uns sehr wichtig. So, dann kommen wir so langsam zum Schluss. Ich habe irgendwann nochmal eigene Übersetzung von Syscalls, also dieses Enriched Feature in Text implementiert, innerhalb von Laurel. Das brachte ein bisschen Performance. Was auch ein bisschen Performance brachte, war der Austausch des Parsers oder des Pasa Generators sind Detailfragen. Wir haben irgendwann noch ein Record dazu getan, Parent Info, dass man mehr als nur die Parent Process ID gelockt bekommt, auch den Namen und sind dann noch am Denken, ob wir noch mehr dazu tun, vielleicht die User ID oder so. Mittlerweile ist auch etwas implementiert, um ganze Bäume von Messen zu markieren, wenn ich also zum Beispiel mein Paketmanagement ausführe abt oder jammen oder die Package RPM, was auch immer. Dann kann ich davon ausgehen, dass alle Kindprozesse davon auch diesen Prozess mit zugeschrieben werden können. Also packe ich einfach an den Elternprozessen-Label dran und vererb dieses Label an die Kindprozesse. Das wäre alles schön einfach, wenn es eben so einfach wäre, dann irgendwelcher modernen Hipster-Paketmanagement-Systeme, wie Snap, die dann keine stabilen Fahre mehr haben, muss man da dann mittlerweile mit regulären Ausdrücken arbeiten. Das geht natürlich nicht im Körnel, sondern das wird dann in der Nachverarbeitung durch Laurel gemacht. Aber im Prinzip ist da das Gleiche. Wenn ein Prozess matcht, dann kriegt da halt so ein Label verpasst im Bookkeeping von Laurel und die Kindprozesse erden das auch. Was wir gelernt haben, ist, dass dieses Auditextformat hat ein Haufen komischer Cornercases, die ich jetzt oben nicht angesprochen hatte, die irgendwie Sonderbahnen umbrauchten. Ich glaube mittlerweile laufen wir da nicht mehr in Parsing-Probleme. Was auch nötig war, war eben Unterstützung von SE-Linux-Polices. Jetzt kann man sich natürlich hinstellen, wie manche Vendoren dann sagen, macht das SE-Linux einfach aus oder auf Non-Enforcing. Aber das war halt auch eben nicht unser Anspruch für dieses Audit-Deplug in, muss da halt auch entsprechend eine Policy geschrieben werden. Und das ist leider auch im Jahr 2022 immer noch fehleträchtiger und problematischer, als man das eigentlich haben möchte. Ich glaube, das ist dann genau ein Aufblick, gibt es noch. Ein paar Ideen, die im Kopf herumschwirren, was man so machen könnte noch, was noch fehlt, weil Audit-De, oder das Linux-Audit-Subsystem, das selbst nicht zur Verfügung stellt, Container-Runtime-Kontexte, weil das, weil dieses Konzept von Container-Runtimes kein koärentes Kernel-Konzept ist, kann man da auch wenig gegen sagen. Aber da wäre es halt doch schön, wenn man da irgendwie Lebes draus machen könnte und was anotieren könnte. Das steht auf jeden Fall ja, ich will nicht sagen auf einer Roadmap, weil Roadmap werden versprechen. Aber da denkt man drüber nach. Man könnte noch mehr an Übersetzungen machen, also die, diese, die Flex, die in einem Open-Syscall übergeben werden, die könnte man in, in Text übersetzen, so dass der Analyst, der in seinen Siem start, das nicht ist, und das wäre halt noch eine Idee. Ja, Filtern von Events, um einfach die Datenmenge kleiner zu kriegen, da bin ich noch ganz am Anfang drüber nachzudenken. Was wirklich gut wäre, wäre so, also ein, ein tolles Feature in Sysmon ist eben, dass jeder Prozess und auch jeder Thread, nee, nicht jeder Thread, aber jeder Prozess kriegt so eine GUID, dass jeder, der da ist, über die ganze Flotte unik ist, und das ist halt so ein, so ein 128-Bit-Wert in der Textarstellung, nach der man gut in seiner Volltext-Super-Schiene suchen kann. Und das ist halt, das ist halt super praktisch, da, das werde ich wahrscheinlich recht bald implementieren. Da 3 Hashes ist zu berechnen, ist wahrscheinlich auf Linux-Systemen viel, viel weniger sinnvoll als auf Windows-Systemen und momentan haben wir halt was gebaut, was in Logfile schreibt, das dann in unserem Fall vom Splunk Forwarder ausgelesen und dann weiter verschifft werden kann. Da wir auch denkbar, es hat schon Leute gegeben, die da gerne alternative Back-ins für gehabt hätten. Wenn da jemand sich berufen fühlt, Prorequest zu stellen, ich gucke mir das gerne an. So, inhaltlich haben wir eine tolle Basis, zumindest eine brauchbare Basis. Also es könnte immer besser sein, aber es ist nicht so schlimm wie geschrumpfen wird. Und das ordert dieses Ordizutsystem. Aber das Ausgabeformat ist halt so eine Fehlentscheidung aus den 2000ern und die kann man nicht mehr rückgängig machen und diese Schwachstelle beheben war. Und wir haben jetzt mit dem, was wir gebaut haben, eine Fremdform, auf der vielleicht auch noch weitere Anreichungen dazutun können. Der Appetit kommt immer mit messen und so bin ich guter Hoffnung, dass da die Features, die jetzt implementiert sind, vielleicht über neue Detection-Use geht es auf wieder zu neuen Ideen, die man da implementieren können. Damit bin ich am Ende angelangt. Danke mich für die Aufmerksamkeit und für das Interesse und für die Aufmerksamkeit. Ja, wenn noch Fragen sind, hat er jetzt die Gelegenheit. Vielen Dank auch. Wenn ihr Fragen habt, so wie ihr das gerade schon vorgemacht habt, Handheben, ich komme mit die Mikro zu euch, dann kann jeder die Frage gut hören. Ich habe es vorhin ausgehört, die Anwendungsentwicklung ist nicht ganz unbeteiligt in der Flut von Informationen nach dem, wie es die Architektur baut. Sie ist ja dann großen Hebel, die dazu zu bringen, es sind halt viele Teams, mit denen man sprechen muss. Und wenn jetzt die Entwicklung irgendwie schon seit 15 Jahren so geht, dass man irgendwelche Schelzkripte im schönen Yolo-Engineering vor sich laufen lässt und wenn die Performance nicht stimmt, die Antwort einfach ist, ja gut, dann stellen wir halt noch eine Box daneben. Dann sehe ich da wenig Einflussmöglichkeit von unserer Seite, dass wir da also das Einzige, was letztlich was diese Teams tatsächlich motivieren kann sind irgendwie Kostenersparnisse und diese Kostenersparnisse die müssen ja auch herbei argumentiert werden. Also da muss man jemand genau hingeguckt haben, hier wäre dieses oder jenes Potenzial so und so viele Maschinen zu sparen wenn ich so und so mach, dann werdet ihr nachts weniger oft rausgeklingelt über solche Hebel kannst du sie natürlich kriegen, aber rein über die Möglichkeit des Security Monitoring ja gut, man könnte sagen, wir können eurem Systeme nicht monitoren, mach mal Risikoübernahme das geht natürlich auch, aber so ist das wie wird das Ganze konfiguriert? wie wird das Ganze konfiguriert? mal gucken, ob ich hier ein Netz hab das zeige ich jetzt nicht das kann ich dem Nachgang zeigen im Wesentlichen ist es eine Konfigurationsdatei für Auditd hinlegen dass eben dieses Plugin gestartet wird das Plugin selbst braucht ne also das Programm Laurel braucht selbst ne Konfigurationsdatei und das Programm muss jetzt salieren das ist dann schon alles Dankeschön weitere Fragen, Jawoll ich komme nach hinten eine Frage, sondern eigentlich eine Anmerkung wir in der Firma haben das weil wir kein solches Tool installieren wollten so gelöst, dass wir ein Arsyslock genommen haben, weil wir die Daten eh damit fortschieben und dann ein Start Message TrackX eingebaut haben das heißt, dass wir bestimmte Auditd Keys zusammenfassen und dann halt einer Zeile dann halt weg schicken es ist zwar nicht so schön, wenn man das Backslash N mit dabei hat aus dem Template ein Arsyslock aber es funktioniert schlussendlich auch ein löst Arsyslock für dich das hext jetzt die Zimalkodierungsprobleme? ne, das leider nicht da haben wir bisher noch keine wirkliche Lösung gefunden also ich habe mit dem Kollegen jetzt letzte Woche noch darüber geschaut es gibt auf dem Linnungssystem selbst sehr wenige Implementierungen, die das machen können bisher wer hat noch keine Frage gestellt und will noch gerne eine stellen ja, dann würde ich sagen falls es noch weitergehende Sachen gibt oder ihr Konfigurationsdateien sehen wollt dann findet euch danach direkt an Hilko ansonsten, vielen Dank für dein Tor zu später Stunde und die zahlreiche Teilnahme und dann würde ich sagen, verabschieden wir ihn mit einem großartigen Applaus in den Abend und euch allen auch noch viel Spaß auf der GTM vielen Dank