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:

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:

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:

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:

• Weiterleitung aller generierten Windows Events (System, Applikation, Sicherheit, etc.)
• Konvertierung des nativen Formats zu syslog RFC5424
• Eliminierung aller Zeilenumbrüche und Tabstopps in einer Message.
• Weiterleitung der modifizierten Events über TCP auf Port 10514 an server x.y.z.1

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

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

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.

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.

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.

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.

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:

• Liest und schreibt Events (im_ steht für Inputmodule)
• Verarbeitet diese Events (pm_ steht für Prozessmodule)
• Weiterleitung und/oder Speicherung der Events (om_ steht für Outputmodul)

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

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.

• Beschaffen oder erstellen Sie Zertifikate für beide Endpoints (NXlog Client und den Sammelpunkt)
• Beschaffen Sie sich den Certificates Authority Public Key (selbst-signierte Zertifikate sind zwar nicht empfohlen, funktionieren aber auch)
• Der Sammelpunkt muss SSL-Verschlüsselung unterstützen (NXlog als Server tut das)

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

• Deklarieren Sie %CERTDIR% als Verzeichnis, in dem Zertifikate gespeichert zu Beginn der nxlog.conf (der Sektion mit den Definitionen) gespeichert werden.
• Ersetzen Sie das om_tcp-Modul mit om_ssl. Sehen Sie die im Code entsprechend auskommentierte Zeile.
• Deklarieren Sie, wo die Zertifikate im pem-Format abgelegt sind.
• Deklarieren Sie, dass Sie nur vertrauenswürdige und verschlüsselte Verbindungen akzeptieren.
• Wir nehmen hier an, dass der Private Key in Klartext gespeichert ist und von NTFS ACL gesichert wird. Sollte dem nicht so sein, dann müssen Sie noch den _KeyPass_-Value angeben, der die Passphrase für den client-privkey.pem enthält. Dies ist aber nicht empfohlen.

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:

• Definition einer Event Generation Policy
• Definition einer Sammlungs- und Retentionspolicy
• Definition, wie die Datenmenge analysiert und verarbeitet werden soll.
• Definition einer raisonablen Alerting Policy.

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 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

• http://nxlog.org/docs
• http://nxlog.org/products/nxlog-community-edition
• http://www.ietf.org/rfc/rfc3164.txt
• http://www.ietf.org/rfc/rfc5424.txt
• https://nxlog.org