Windows Logs mit NXlog sammeln

Windows Logs mit NXlog sammeln

Andrea Covello
von Andrea Covello
Lesezeit: 15 Minuten

Endlich haben wir das Bewusstsein in den Köpfen der Kunden, dass das Sammeln von Systemlogs ein guter Ausgangspunkt sind, um mehr über die eigene Infrastruktur zu erfahren.

Aber bis zum Punkt der guten Übersicht ist es eine lange Reise. Zuerst gilt es eine Log-Management-Infrastruktur aufzusetzen und am Ende, wenn wir das richtig gemacht haben, haben wir eine Security Monitoring Solution die funktioniert. Aber wir greifen vor. Als erstes, bevor irgendetwas ausgewertet werden kann, müssen alle Events von ihren Ursprungsorten in unser Log-Management gelangen. Diese Events kommen von allerlei Geräten wie Switches, Routers, Anwendermaschinen und generic purpose systems. Natürlich würde es Sinn ergeben, alle Daten mit dem de-facto Standard syslog zu sammeln. Das Format wird von fast allen Systemen nativ unterstützt. Aber halt nur fast allen. Die kleine Ausnahme: Windows.

Also, in diesem Fall (und in manch einem anderen) haben wir mit einer grossen Zahl von Windows Server Systemen zu tun, die eine noch grössere Zahl an Events generieren, die gesammelt, gespeichert, normalisiert und analysiert werden müssen.

Nun denn, wie kommen wir an alle diese Windows Logs? Wenn im ganzen Netzwerk nur Microsoft-Systeme sind, dann können wir Windows Remote Management (WinRM) nutzen, oder Windows Management Instrumentation (WMI) Solutions. Aber wenn wir es mit einem heterogenen Umfeld zu tun haben, dann ist es wohl am besten, syslog zu verwenden.

Die Loggingphasen

Im Logmanagement müssen mehrere Phasen berücksichtigt werden. Diese sind:

Phase Beschreibung Details
1 Event Generation Das System oder die Applikation muss so konfiguriert werden, dass ein Logeintrag für einen spezifischen Event generiert wird.
2 Event Forwarding/Storing Das System, das den Event generiert leitet den Eintrag weiter und/oder speichert ihn an einem vorbestimmten Ort (lokal oder remote) in einem vorbestimmten Format
3 Event Collecting Ein verteiltes Netz von Sammelsystemen stellen sicher, dass all Logevents an einen zentralen Ort gelangen, um dort weiterverarbeitet zu werden (mindestens zwei Knotenpunkte)
4 Event Storing/Archiving Alle Events werden für die weitere Verarbeitung abgespeichert und/oder archiviert
5 Event Normalizing Alle Logevents werden von einem Filter geparst um alle Logevents im selben Format zu erhalten
6 Event Analyzing Events werden analysiert um strukturierte Informationen in Form von klaren und informativen Reports zu erhalten.
7 Event Correlation Events werden mit vordefinierten logischen Regeln weiterverarbeitet um Notifikationen und Warnungen zu erhalten.

In diesem Artikel werden wir aber nur die zweite Phase ansehen: Log Forwarding/Storing.

Bevor wir uns aber in die Arbeit stürzen, muss ich eines feststellen: Syslog ist nicht die Lösung aller Problem wenn es um Logmanagement geht. Aber als Transportprotokoll ist es das richtige Tool um eine Vielzahl an Systemevents in einem gemeinsamen Parsingformat zusammenzustellen.

Windows Event Forwarding mit NXlog

Es gibt einige syslog-Konverter für Windows, aber wenn es um Stabilität und Features geht, ist es sehr wahrscheinlich, dass NXlog alle Anforderungen erfüllt.

In diesem Artikel werden wir uns auf die Community Edition NXlogs konzentrieren. Die Enterprise Edition kommt mit allen Supportfeatures für ein Unternehmen. Aber alle Features des Programms sind in der Community Edition enthalten, was es von anderen Lösungen unterscheidet. Und ich persönlich find das sehr gut. ;)

Also, schauen wir uns die Features NXlogs an:

Feature Notiz
NXlog ist ein komplettes Framework NXlog kann als Client und/oder als Server auf fast allen Servern agieren: RedHat/CentOS-, Debian-, Ubuntu-Linux; Windows und Android
Unterstützt TCP und UDP Transport Protocol Syslog verwendet standardmässig UDP/514 aber das fire and forget Prinzip UDPs kann unter Umständen die Anforderungen an Reliability nicht erfüllen
Transportverschlüsselung mit SSL _Confidentiality_-Anforderungen können eine _Over the Line_-Verschlüsselung implizieren
Einfaches Deployment Kleine und kurze Installation, läuft als service/daemon
Gut dokumentiert Das Handbuch ist sehr gut gemacht und dazu gibt es weitere Informatioenn online.
Open Source Mal ehrlich, vermissen Sie dieses Feature irgendwo? ;)
Unterstützt syslog-Format (RFC3164 und RFC5424) Auch wenn es nicht das beste Eventformat der Welt ist, bietet syslog immer Kompatibilität für weitere Verarbeitung
Unterstützt strukturierte Eventformate (meta-data structure awareness) NXlog ist in der Lage, das Windows-Event-Log-Format nativ zu verarbeiten. Es liest CSV, JSON, XML, GELF wie auch Windows EventLog
Saubere und einfache Konfiguration Sie können eine sehr komplexe Konfiguration mit vielen Features erstellen. Aber eine solide funktionierende Basisinstallation kann schon nach wenigen Minuten laufen
Eingebautes Scheduling und Logrotation NXlog hat einen eingebauten Scheduler, ähnlich dem crons, aber mit besser ausgearbeiteten Timing-Features
Keine Messages gehen verloren NXlog wird keine Logmessages droppen. Es wird aber den Input wo immer möglich drosseln. Wie dem auch sei, NXlog kann explizit instruiert werden, bestimmte Logmessages zu droppen um den möglichen unnötigen Verbrauch an Ressourcen zu vermeiden
Modulare Architektur Module sind dynamisch ladbar in Form von Plugins. Diese fügen NXlog weitere Features und neue Funktionalität hinzu

Windows Event Format

Windows EventLog erlaubt Messages, die mehrere Zeilen lang sind, damit der Text wesentlich besser lesbar ist. Mit Abständen, Tabstopps und Zeilenumbrüchem werden die Messages im Event Viewer dargestellt. Hier die XML-Ansicht eines solchen Windows Event Logs:

XML-Ansicht eines Windows Event Logs

Aber syslog arbeitet nur mit einzeiligen Messages. Daher muss all die Formatierung entfernt werden. Mit diesem Vorgang geht aber die meta-data verloren.

NXlog kann diese Felder lesen, erkennt die Struktur und leitet diese remote weiter (oder handelt aus Warnungsgründen nach den Messages). Das spart Zeit und Ressourcen. Wenn Sie also das NXlog Framework (client/server) verwenden, dann werden Sie keine Zeit mit dem Schreiben von Patterns, das Usernamen, IP-Adressen und andere meta-data extrahiert, verschwenden müssen.

Wenn Sie mich fragen, dann hat NXlog killer Features.

Konfiguration eines NXlog Clients auf einem Windows Server

Schauen wir uns nun eine funktionierende NXlog Client Konfiguration auf einer Maschine an, auf der Windows Server 2008/2012 läuft.

Die Anforderungen:

Eine funktionierende NXlog Config

NXlog Client Configuration für Windows Server 2008/2012 (nxlog.conf)

Schauen wir uns die Konfigurationssyntax etwas genauer an (weitere Informationen hier)

Ordnerdefinition in NXlog

Der erste Teil definiert, wo die NXlog-Binaries und -Module gefunden werden und wo geschrieben werden kann. NXlog muss seine eigenen Logs wie auch andere relevante Informationen schreiben können, um zu funktionieren.

Module werden in NXlog geladen

Hier deklariert NXlog, welches Modul geladen wird. Beachtlich ist die Nutzung der Modulfunktion, die sehr effizient gehandhabt wird.

In diesem Fall brauchen wir das Modul, das den Export ins syslog-Format handhabt und das Modul, welches das EventLog-Format aus Microsoft Windows Vista oder später zieht.

Es gibt logischerweise verschiedene Module. Zum Beipsiel könnten Sie ein Modul verwenden, das Dateien liest (im_file), in denen Events geschrieben sind. Dies passt gut für Applikationen die keine Microsoft EventLog API unterstützen.

Handling von eingehenden Events in NXlog

In diesem Teil wird definiert, wie die eintreffenden Events verarbeitet und umgewandelt werden.

Die beinhaltet die Definition zur Konvertierung der Events in ein Format, das mit syslog RFC/5424 übereinstimmt.

Definition der Transport Layer in NXlog

Hier definieren wir die Transport Layer, welche die umgewandelten Events zum zentralen Sammelpunkt schickt, der die Adresse x.y.z.1 hat, schickt. Dies tut sie über TCP Port 10514.

Bevor irgendetwas über das Netzwerk geht, werden alle Mehrzeiligkeiten und Tabstopps entfernt.

Definition der Verarbeitungspfade in NXlog

In diesem Schritt leiten wir die Verarbeitung über unseren prädefinierten Pfad. Im Grunde genommen sagen wir, dass der Input eventlog vom Prozessor p_anco_01 verarbeitet werden muss und dann an den heron-Output gesendet werden muss.

Stellen Sie sich das als Abstraction Layer vor, in der wir sagen, was mit der Eventinformation geschehen muss bevor sie zum Ziel, dem zentralen Sammelpunkt, geleitet wird.

Zusammenfassend macht NXlog Folgendes:

Eine NXlog Sequenz

Und nun ist es Zeit, eine weitergeleitete Eventmessage auf dem empfangenden syslog Server anzusehen:

Eine Eventmessage in syslog

Ich werde mich jetzt mal nicht über das Zeitformat beschweren, weil das würde einen separaten Artikel benötigen. Zudem ist es so, dass das Format, das wir hier erhalten von jedem syslog-lesenden Verarbeitungstool genutzt werden kann.

Wie Sie sehen haben wir die meta-data Formatierung verloren, aber das war notwendig und die Resultate der Konfiguration fallen wie erwartet aus. In diesem Fall empfängt der Prozess rsyslogd auf einem Ubuntu Linux Server, der eine ganz normale RFC3164 für die weitere Verarbeitung der Messages benötigt.

Sie könnten natürlich einen NXlog Server-Prozess einrichten, der Eventmessages empfängt und die meta-data Formatierungen beibehält, was die Einbettung von NXlog Server Filterung und dessen Analysefähigkeiten. Allerdings ist das nicht Teil dieses Artikels, da sich diese Lösung auf die Logmanagementphasen drei bis sieben bezieht.

TLS/SSL Encryption hinzufügen

Da Logmessages über normalen TCP mitgelesen werden oder gar im Zuge einer Man-in-the-middle-Attacke verändert werden können, bietet das Modul im_ssl eine sichere Methode zum Transport der Logs.

Stellen Sie sicher, dass Sie folgende Anforderungen erfüllen.

Fügen Sie nun Folgendes ihrer _output_-Sektion der NXlog-Konfiguration hinzu:

SSL-Verschlüsselung in NXlog

Zusammenfassung

Es ist wohl kaum notwendig, festzustellen, dass wir nur grade an der Oberfläche der Möglichkeiten des NXlog-Frameworks kratzen. Mehr Informationen finden Sie hier.

Ich muss zudem erwähnen, dass dieser Artikel nur ein Teil des Puzzles ist, das am Ende eine komplette Log-Management-Lösung ergibt, die das Fundament eines soliden und funktionierenden Security Monitorings darstellt.

Grössere Mühe werden die Feineinstellungen des Frameworks sein. Dazu gehören:

Tools wie NXlog arbeiten verlässlich und erfüllen die Anforderungen. Das ist ohnehin ein Prärequisit. Um aber das Endziel des funktionierenden und einfachen Security Monitorings zu erreichen, ist – zusätzlich zu NXlog – noch eine Menge Arbeit notwendig. Sowohl auf der Prozess- wie auch der operationalen Ebene.

Wie dem auch sei: Viel Spass auf dem Weg dahin. ;)

Über den Autor

Andrea Covello

Andrea Covello ist seit den 1990er Jahren im Bereich der Informationssicherheit tätig. Seine Schwerpunkte liegen traditionell im Engineering, wobei er als Spezialist im Bereich Windows-Sicherheit, Firewalling und Virtualisierung gilt.

Links

Sie wollen Ihr Log und Monitoring auf das nächste Level bringen?

Unsere Spezialisten kontaktieren Sie gern!

×
TIBER-EU Framework

TIBER-EU Framework

Dominik Altermatt

Vertrauen und KI

Vertrauen und KI

Marisa Tschopp

Datenverschlüsselung in der Cloud

Datenverschlüsselung in der Cloud

Tomaso Vasella

Cyber Threat Intelligence

Cyber Threat Intelligence

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv