Wer die Logs der On-Board Firewall auf seinen Windows Clients und Servern überwachen und auf verdächte oder ungewohnte Aktivitäten analysieren möchte, sendet die Logs am besten zu einer zentralen Security Log Monitoring Lösung. In unserem Test-Lab wird eine Option gezeigt, wie man dies bewerkstelligen kann. Dazu sollen die Windows Firewall Logs eines Windows 10 Clients an Graylog gesendet werden.

Um eine eigene Graylog Instanz zu erstellen, kann man sich an die guten Beschreibungen der jeweiligen Hersteller wenden. In dem Falle des Test-Labs wurde ein aktuelles CentOS auf einer VM installiert und mit einer aktuellen Graylog Version bestückt. Als Log-Shipper auf den Windows Client wurde die NXLog Community Edition gewählt.

Windows Firewall Logs aktivieren

Zur Überraschung mancher, oder auch nicht, ist auf den Windows Clients und Server das Logging der On-board Firewall nicht per Default aktiviert. Somit muss dies aktiviert werden, damit Log-Daten gesammelt werden können.

Via GUI kann das Logging der Windows Firewall unter Windows Defender Firewall with Advanced Security -> Properties -> [Domain/Private/Public] Profile Tab -> Logging Costumize aktiviert werden.

Dazu den Wert No (Default) bei den Punkten Log dropped packages und Log successful connections auf Yes ändern. Weiter ist hier empfohlen die Size Limit des Logfiles auf 16384 KB oder grösser anzupassen.

Die gleiche Wirkung kann auch mittels folgenden Group Polices erzielt werden:

NXLog Konfigurieren

Nachdem man NXlog nach der Anleitung des Herstellers auf seinem Windows System installiert hat, muss NXLog entsprechend konfiguriert werden. Da als Empfänger eine Graylog Instanz gegenübersteht, sollen die Firewall-Logs mittels dem Graylog Extened Log Format (GELF) über UDP gesendet werden.

Die entsprechenden Einstellungen werden im Konfigurations-File von NXLog bewerkstelligt. Dieses ist in dessen Installationsverzeichnis zu finden (Default Pfad):

C:\Program Files (x86)\nxlog\conf\nxlog.conf

Folgende Anpassungen wurde in nxlog.conf gemacht. Als Ausgangslage diente dazu das Default Konfigurations-File.

1. GELF aktivieren

1. Per Default ist syslog als Log-Format definiert, mittels # kann diese Zeile auskommentiert werde
2. Auf einer Neuen Zeile wird das Modul GELF hinzugefügt
3. Weiter wurde der Name der Extension von _syslog auf _gelf angepasst

<Extension _gelf>
   Module	xm_gelf
   #Module	xm_syslog
</Extension>

2. Log Input konfigurieren

1. Das Modul im_vistalog wurde duch im_file ersetzt, um so aus einem File Logs auszulesen
2. Anschliessend wird der Pfad des Log-Files definiert. In unserem Falle mittels File "C:\Windows\system32\LogFiles\Firewall\pfirewall.log"
3. Zusätzlich wurde hier Exec Statment nötigt. Dieses liest per Regex den Timestamp einer Log-Line aus und schreibt diesen in das vorgesehen Feld in GELF, damit anschliessend Graylog den korrekten Timestamp der Log-Line in das dafür vorgesehene Feld schreiben kann. Ohne dieses Exec-Statement würde Graylog ein verfälschten Timestamp erhalten und darstellen. Damit wären Auswertungen der Log-Files nicht adäquat möglich. Eventuell sind hier auch effizientere Möglichkeiten zielführend aber innerhalb des Test-Labs schien diese Lösung als akzeptabel.
4. Weiter wurde der Name des <input> auf WinFirewallLog angepasst

<Input WinFirewallLog>
   Module	im_file
   File		"C:\Windows\system32\LogFiles\Firewall\pfirewall.log"
   Exec		if $raw_event =~ /(\d\d\d\d\-\d\d-\d\d \d\d:\d\d:\d\d)/ {$EventTime = strptime($1, '%Y-%m-%d%t%H:%M:%S');}
   # For windows 2003 and earlier use the following:
   # Module	im_mseventlog
</Input>

3. Graylog als Empfänger konfigurieren

1. Das Modul om_tcp wurde durch om_udp ersetzt
2. Als Host die IP Adresse des Graylog Servers eintragen
3. Als Port den entsprechenden freien Listener Port des Graylog Servers eintragen
4. Das bestehende Exec-Statement wird mittels # auskommentiert und somit deaktiviert
5. Das Exec $ShortMessage = $raw_event; Statement wird eingefügt. Dieses stellt sicher, dass die gesamte Log-Line im Feld Message gesendet werden. Ohne dieses Statement wird die Message nach 64 Zeichen abgeschnitten.
6. In einer weiteren Zeile den OutputType als GELF definieren
7. Der Name des Output wurde bei dem Default-Wert out belassen

<Output out>
   Module	om_udp
   Host		192.168.1.10
   Port		12202
   Exec 	$ShortMessage = $raw_event;
   #Exec        to_syslog_snare();
   OutputType	GELF
</Output>

4. NXLog Service neu starten, um neue Konfiguration zu übernehmen

Wer übrigens bereits Windows Event Logs mittels NXLog versendet oder diese auch gleich mitsenden möchte, sollte in der NXLog Konfiguration drauf achten einen separaten <input>, <output> und <route> per Log Thema zu definieren. Dies könnte dann folgendermassen aussehen:

1. Die <input> werden mit entsprechenden Namen definiert, hier einmal <Input WinEventLog> und einmal <Input WinFirewallLog>
2. Zwei separate <Output>, diese unterscheiden sich dadurch, dass verschiedene Ports definiert wurden. Damit ist man in Graylog in der Lage einen speifischen Input per Port für die unterschiedlichen Log-Themen zu definieren um diese getrennt analysieren zu können. Hier als <Output out1> und <Output out2>.
3. Entsprechend müssen nun zwei <Route> definiert sein. Diese folgen dem Format Input ⇒ Output. Also muss eine <Route> mit Path WinEventLog => out1 und eine mit Path WinFirewallLog => out2 definiert werden.

<Input WinEventLog>
   Module      im_msvistalog
</Input>

<Input WinFirewallLog>
   Module	im_file
   File		"C:\Windows\system32\LogFiles\Firewall\pfirewall.log"
   Exec		if $raw_event =~ /(\d\d\d\d\-\d\d-\d\d \d\d:\d\d:\d\d)/ {$EventTime = strptime($1, '%Y-%m-%d%t%H:%M:%S');}
</Input>

<Output out1>
   Module	om_udp
   Host		192.168.1.10
   Port		12201
   OutputType	GELF
</Output>

<Output out2>
   Module	om_udp
   Host		192.168.1.10
   Port		12202
   Exec		$ShortMessage = $raw_event;
   OutputType	GELF
</Output>

<Route 1>
   Path		WinEventLog => out1
</Route>

<Route 2>
   Path		WinFirewallLog => out2
</Route>

Graylog Konfigurieren

Um die Logs nun auf Graylog empfangen zu können, muss ein entsprechender Input definiert werden:

1. Login auf der Webkonsole von Graylog
2. Im Top Menu unter System -> Input öffnen
3. Auf der Input-Page, im Dropdown GELF UDP auswählen und Launch new input anklicken
4. Im entsprechenden Fenster die nötigen Daten eintragen:
   1. Aktuelle Graylog Node wählen
   2. Dem Input einen Namen geben, z.B WindowsClient_FirewallLogs
   3. Bind Adresse des Graylog Servers angeben: 192.168.1.10 (wie im <output> im nxlog.conf)
   4. Sowie der entsprechende Port 12202 (wie im <output> im nxlog.conf)
   5. Die übrigen Einstellungen werden für das Test-Lab bei den Default-Werten belassen

Nun können bereits die ersten Logs empfangen werden. Da im Test-Lab eine CentOS für Graylog verwendet wird, muss noch sichergestellt werden, dass ein entsprechender Port auf der Firewall von CentOS geöffnet wurde.

Aktuell werden die einzelnen Felder der Log-Lines als einen String im Message Feld dargestellt. Dies jedoch verhindert die Möglichkeit mit Graylog über alle Felder hinweg Auswertungen anzustellen. Graylog biete dazu einen Extractor an, mit welchem die empfangenen Logs z.B. mittels GROK, ausgelesen und in entsprechende Felder in Graylog geschrieben werden können.

Graylog bietet bereits einen Fundus von GROK Pattern an. Dies sollten für die Log-Lines der Windows Firewall Logs noch etwas angepasst werden, da falls in der Log-Line keine Wert vorhanden ist, dies mit einem – als Platzhalter geliefert wird. Somit sollten die GROK-Pattern, die für den Extractor der Firewall Logs verwendet werden, das Minus-Zeichen hinzugefügt werden.

In der Graylog Webkonsole können die GROK Pattern unter System->GROK Patterns verwaltet werden. Um alle Felder der Windows Firewall Log-Line mit einem GROK Pattern abzubilden, wurden folgende neue GROK Patterns auf Basis der vorhanden erstellt.

Nun sollte dem Erstellen des Extractors nicht mehr im Wege stehen:

1. Unter dem zuvor erstellen Input unter Manage Extractor -> Add Extractor -> Get Started
2. Ein Untermenu erscheint mit dem Button Load Message, in welchem eine empfangene Log Message ausgesucht werden kann, wahlweise auch eine ganz bestimmte durch die Eingabe der entsprechenden Message ID. Dies um den Extractor in den nächsten Schritte gleich testen zu können.
3. Klickt man auf den Button, erscheint die Message, dabei kann auf jedem Feld eine Extractor konfiguriert werden. In unserem Falle solle dies auf dem Feld Message mittels GROK Pattern geschehen.
4. Folgendes GROK Pattern kann nun im dafür vorgesehen Feld eingetragen werden: %{DATESTAMP:UNWANTED} %{WINFIREWALL_WORD:action} %{WINFIREWALL_WORD:protocol} %{WINFIREWALL_IP:src-ip} %{WINFIREWALL_IP:dst-ip} %{WINFIREWALL_INT:src-port} %{WINFIREWALL_INT:dst-port} %{WINFIREWALL_INT:size} %{WINFIREWALL_INT:tcpflags} %{WINFIREWALL_INT:tcpsyn} %{WINFIREWALL_INT:tcpack} %{WINFIREWALL_INT:tcpwin} %{WINFIREWALL_INT:icmptype} %{WINFIREWALL_INT:icmpcode} %{WINFIREWALL_WORD:info} %{WINFIREWALL_WORD:path}
5. Mit dem Button Try, kann man sogleich Test ob das Pattern funktioniert
6. Zuletzt den Extractor hinzufügen
7. Nun können alle Felder der Windows Firewall Log-Lines mit den Funktionen von Graylog analysiert werden

Zuletzt muss auf dem Graylogserver die Default Zeitzone UTC entsprechend angepasst werden, damit ein allfälliger Off-Set in den Graylog Message Timestamps gelöst werden kann. In unserem Fall auf CET. Diese Anpassung wird im Konfigurations-File von Graylog unter /etc/graylog/server/server.conf gemacht:

root_timezone = CET

Nach einem Restart des Graylog-Services können nun alle Felder der Windows Firewall Log-Lines mit den Funktionen von Graylog analysiert werden.

Fazit

Im Rahmen des Lab-Setups kann schnell und bequem ein zentrales Security Log Monitoring über die Firewall Logs der eigenen Windows Population erstellt und betrieben werden. Sobald man herausgefunden hat, wie man die Logs in einem sinnvollen Format in Graylog verarbeiten kann. Es ist gut vorstellbar, dass allenfalls noch einfachere oder effizienter Methoden für die Format-Probleme bei Windows Firewall Logs existierten, aber für einen ersten Test reicht es allemal aus. Wer ähnliches in einer produktiven Umgebung plant, sollte sich ausserdem mit den Hardening von Graylog selbst und dessen Host beschäftigen.

Weitere Informationen über Security Logging können in unseren Beiträgen gefunden werden.

Über den Autor

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

• https://centos.org/download/
• https://nxlog.co/products/nxlog-community-edition
• https://www.graylog.org