Windows Firewall Logs

Auf dieser Seite beschreibe ich, wie man mithilfe von Windows Firewall Logs das Verhalten von Clients analysieren und auswerten kann. Ich denke da an "unbekannte Ziele", unerlaubte eingehende Verbindungen oder seltsame Protokolle.

Einsatz-Szenarien

Ich gebe ihnen mal ein paar Beispiele für den sinnvollen Einsatz dieser Logs in Verbindung mit einer Auswertung. Das gilt insbesondere, wenn Sie auf dem Netzwerk nicht mit SFlow/NetFlow/IPFix arbeiten und die Firewall vielleicht nicht unter ihrer Kontrolle steht.

  • Wer spricht mit meinem Server
    Die Firewall kann sowohl "ALLOW" als auch DENY-Verbindungen protokollieren. Bei einem Exchange Server sieht man so schön die IP-Adressen, die z.B. POP3/IMAP4 nutzen. Aber noch mehr sieht man welche anderen Ports "probiert" werden.
  • Sicherer Port-Honeypot
    Es ist durchaus interessant in einer Umgebung auf einem Client einfach alle "verbotenen" Verbindungen zu protokollieren. Speziell wenn Sie ein System betreiben, was sich nirgendwo einträgt und quasi "unsichtbar ist. Bis auf eben die Systeme, die per Subnet-Scan oder PortScan versuchen offene Systeme zu finden
  • Verkehrsbeziehungen
    Auch wenn das Firewall-Log keine "Deep Inspection" macht, und das Feld "SIZE" bei mir eigentlich immer leer war, ist das Wissen um "Verbindungen" schon nützlich für Planungen und Betrachtungen. So können Sie z.B. auch erkennen, welche Server noch genutzt werden.
  • Ausgehende Verbindungen auf "unerwünschte Ports"
    Gerade die Client-Firewall erlaubt zwar nur bestimmte eingehende aber fast alle ausgehende Ports. Ein Client könnte also selbst zum "Subnetz Scanner" missbraucht werden oder Verbindungen zu Command&Control-Servern im Internet herstellen. Hier kann es schon hilfreich sein solche Verbindungen frühzeitig zu erkennen und die betroffenen Clients dingfest machen zu können. Natürlich geht das viel besser über die Log der zentralen Firewall. Da hat ein Windows Client Admin aber oft keinen Zugriff.

Für solche Ansätze gibt es natürlich auch kommerzielle Lösungen, aber oftmals scheitert man einfach am Preis oder ist sich noch unsicher. Leider funktioniert so ein Logging natürlich nur auf Systemen, die auch entsprechend kontrolliert und überwacht sind.

Eventlog oder Text-Datei

Die Windows Firewall unterstützt beide Verfahren zur Protokollierung von Events. Sie haben also je nach Umgebung die Wahl, welches Verfahren Sie einsetzen. Sie können auch beide Verfahren parallel einsetzen

  • Security Eventlog
    Hat den Vorteil, dass Sie mit verschiedenen Event-Forwardern arbeiten und so Meldungen zentralisieren können. Im Eventlog werden dann auch Konfigurationsänderungen der Firewall protokolliert. Allerdings wird ein sehr aktives System hier viele Logs produzieren und ggfls. das Security-Log fluten. Leider ist kein alternatives Log möglich.
  • Dateien
    Die Datei entspricht in etwas dem IISLog und enthält alle Verbindungen. Sie können mit verschiedenen Werkzeugen auch diese Dateien einsammeln und zentral auswerten. Aber selbst "Notepad" ist ein legitimes Mittel zur schnellen Betrachtung und Suche

Eventlog aktivieren

Die Firewall sendet standardmäßig keine Meldungen ins Eventlog. Damit dies funktioniert, müssen Sie zwei Funktionen aktivieren:

  • Audit process tracking
  • Audit policy change

Die Einstellung können Sie für einen einzelnen Client durchaus über die "Local Security Policy" einrichten.

Ich bin aber eher ein Freund einer zentralen Konfiguration und daher finde ich die Einstellung über Gruppenrichtlinien am einfachsten und stellt zudem sicher, dass auch alle Clients die Einstellung bekommen und kein Angreifer sie allzu leicht abschalten kann. Meldungen sehen dann wie folgt aus

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          17.06.2019 02:03:49
Event ID:      5152
Task Category: Filtering Platform Packet Drop
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      SERVER1.UCLABOR.de
Description:
The Windows Filtering Platform has blocked a packet.

Application Information:
   Process ID:	        0
   Application Name:    s-

Network Information:
   Direction:	        Inbound
   Source Address:      192.168.100.11
   Source Port:	        389
   Destination Address: 192.168.100.52
   Destination Port:    65176
   Protocol:            6

Filter Information:
   Filter Run-Time ID:  67130
   Layer Name:          Transport
   Layer Run-Time ID:   13
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>5152</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>12809</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2019-06-17T00:03:49.763761300Z" />
    <EventRecordID>158051968</EventRecordID>
    <Correlation />
    <Execution ProcessID="4" ThreadID="1468" />
    <Channel>Security</Channel>
    <Computer>SERVER1.UCLABOR.de</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="ProcessId">0</Data>
    <Data Name="Application">-</Data>
    <Data Name="Direction">%%14592</Data>
    <Data Name="SourceAddress">192.168.100.11</Data>
    <Data Name="SourcePort">389</Data>
    <Data Name="DestAddress">192.168.100.52</Data>
    <Data Name="DestPort">65176</Data>
    <Data Name="Protocol">6</Data>
    <Data Name="FilterRTID">67130</Data>
    <Data Name="LayerName">%%14597</Data>
    <Data Name="LayerRTID">13</Data>
  </EventData>
</Event>

Eine Filterung nach "Windows Firewall With Advanced Security" liefert hier also nicht die richtigen Einträge. Die folgenden Events mit Links hat Microsoft dokumentiert.

Insofern ist die Windows Firewall durchaus gesprächig und wer heute schon eine Lösung zum Einsammlen von Eventlogs hat, kann damit schon erste Spuren verfolgen.

Datei-Logging aktivieren

Damit die Windows Firewall alle Zugriffe in eine Datei protokolliert, müssen Sie diese Funktion erst aktivieren. Sie können das direkt über die GUI der Firewall machen. Hier sehen sie die per Gruppenrichtlinie aktiviere Konfiguration in meiner Domäne.

Aber auch hier finde ich es besser, diese Einstellungen per Gruppenrichtlinien vorzugeben. Die Konfiguration über eine Gruppenrichtlinie ist schnell gemacht.

Denken Sie daran, das das Logging für die drei Netzwerkzonen Domain, Privat, Public separat zu konfigurieren ist und der Systemdienst natürlich die Schreibrechte im Zielverzeichnis haben muss.

Der Standardpfad ist "%systemroot%\system32\logfiles\firewall\pfirewall.log" und die Datei wird per Default nicht größer als 4 Megabyte. Laut Microsoft schreibt der Log-Mechanismus beim Erreichen der Grenze am Ende weiter und löscht die Informationen davor. Das ist allerdings so nicht richtig. Wenn die Größe erreicht ist, wird die bestehende Date nach ".OLD" umbenannt und eine neue Datei begonnen.

Die jeweils aktive Datei ist gesperrt und kann nicht gelöscht werden

Sie kann aber natürlich mit den entsprechenden Berechtigungen gelesen werden. Leider vergibt die MMC auf dem Server bei Aktivierung des Logging die Berechtigungen aber die per GPO konfigurierten Einstellungen können dies nicht machen. Insofern müssen Sie manuell auf dem Verzeichnis die entsprechenden Rechte vergeben. Wobei die Quellen hier etwas "durchwachsen" sind. Auf einem Server ohne aktivem Logging sind folgende Rechte auf dem Verzeichnis vergeben:

Relevant hier ist das Konto "NT Service\MpsSvc". Manchmal ist es nicht auf dem Verzeichnis berechtigt. Achten Sie auch darauf, wenn sie das Verzeichnis an einen anderen Ort umleiten.

Die Logdateien müssen Sie aber nicht regelmäßig löschen oder gar manuell anlegen, wie dies in dem folgenden Blog-Artikel beschrieben ist:

Logging per PowerShell

Wer unbedingt die Einstellungen per PowerShell setzen will, kann das natürlich auch. So können Sie Umgebungen ohne Active Directory, z.B. alleinstehende AzureVMs während des Deployments oder per Software-Verteilung mit den Einstellungen versehen. Etwas komisch ist, die Verwendung von "True". Folgendes geht nicht:

Get-NetFirewallProfile | Set-NetFirewallProfile -LogAllowed $True -LogBlocked $True
et-NetFirewallProfile : Die Argumenttransformation für den Parameter "LogAllowed" kann nicht verarbeitet werden. Der
Wert "True" kann nicht in den Typ "Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.GpoBoolean"
konvertiert werden. Fehler: "Ungültige Umwandlung von "System.Boolean" in
"Microsoft.PowerShell.Cmdletization.GeneratedTypes.NetSecurity.GpoBoolean"."

Sie müssen "True" ohne das "$"-Zeichen schreiben.

Get-NetFirewallProfile | Set-NetFirewallProfile -LogAllowed True -LogBlocked True

Über das Gegenstück "Get-NetFirewallProfile" können Sie die aktuellen Einstellungen auslesen.

PS C:\> Get-NetFirewallProfile | fl name,log*

name                : Domain
LogMaxSizeKilobytes : 4096
LogAllowed          : True
LogBlocked          : True
LogIgnored          : NotConfigured
LogFileName         : %systemroot%\system32\LogFiles\Firewall\pfirewall.log

name                : Private
LogMaxSizeKilobytes : 4096
LogAllowed          : True
LogBlocked          : True
LogIgnored          : NotConfigured
LogFileName         : %systemroot%\system32\LogFiles\Firewall\pfirewall.log

name                : Public
LogMaxSizeKilobytes : 4096
LogAllowed          : True
LogBlocked          : True
LogIgnored          : NotConfigured
LogFileName         : %systemroot%\system32\LogFiles\Firewall\pfirewall.log

Firewall Logs im RAW-Format

Sobald das Logging aktiv ist, schreibt der Firewall-Dienst kontinuierlich die Datei.

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2019-06-10 20:38:38 ALLOW UDP 169.254.24.108 239.255.255.250 61870 1900 0 - - - - - - - RECEIVE
2019-06-10 20:38:38 ALLOW UDP 172.18.9.33 239.255.255.250 61873 1900 0 - - - - - - - SEND
2019-06-10 20:38:44 ALLOW UDP 192.168.178.11 192.168.178.255 138 138 0 - - - - - - - RECEIVE
2019-06-10 20:38:49 ALLOW TCP 127.0.0.1 127.0.0.1 28588 9395 0 - 0 0 0 - - - SEND
2019-06-10 20:42:16 ALLOW 2 192.168.178.50 224.0.0.22 - - 0 - - - - - - - SEND
2019-06-10 20:42:53 ALLOW ICMP fe80::d142:c6d8:1694:f9d5 ff02::16 - - 0 - - - - 143 0 - SEND
2019-06-10 20:44:24 DROP UDP 192.168.178.1 192.168.178.50 53 56921 132 - - - - - - - RECEIVE	
2019-06-10 20:44:34 DROP UDP 192.168.178.24 192.168.178.50 63310 161 141 - - - - - - - RECEIVE
2019-06-10 20:45:29 ALLOW ICMP fe80::b834:32de:131e:9b44 ff02::1:ff34:3d04 - - 0 - - - - 135 0 - SEN

Als einfache Textdatei können Sie diese relativ einfach weiter weiter verarbeiten.

Einlesen

Um zu sehen, wie die Logs geschrieben werden, reicht schon ein "Get-Content" von PowerShell mit dem Parameter "-Wait"

gc C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Wait -Tail 1

Danach sehen Sie jede Änderung der Datei, bei der Windows etwas hinten anhängt. Bei mir hat es aber in der Regel etwas gedauert, bis neue Verbindungen auch im Log aufgetaucht sind. Bei den meisten Logs kann ich auch nur die ersten 8 Felder sinnvoll auswerten. Insbesondere das Feld "SIZE" ist bei mir immer 0 und auch die nachfolgenden Felder sind meist nicht.

#Einlesen per Import CSV mit den störenden Zeilen am Anfang, ca. 400ms
import-csv C:\Windows\System32\LogFiles\Firewall\pfirewall.log `
   -Delimiter " " `
   -Header date,time,action,protocol,src-ip,dst-ip,src-port,dst-port,size,tcpflags,tcpsyn,tcpack,tcpwin,icmptype,icmpcode,info,path


# Einlesen mittels Get-Content zum ignorieren der ersten Zeile. mit 600ms etwas langsamer

Get-Content C:\Windows\System32\LogFiles\Firewall\pfirewall.log `
| Select-Object -Skip 4 `
| ConvertFrom-Csv `
   -Delimiter " " `
   -Header date,time,action,protocol,src-ip,dst-ip,src-port,dst-port,size,tcpflags,tcpsyn,tcpack,tcpwin,icmptype,icmpcode,info,path

Damit, oder mit anderen Werkzeugen, steht einer weiteren Auswertung natürlich nichts im Wege. Wenn Sie die Logs auf mehreren Servern erfassen, dann macht eine Zusammenführung in eine Quelle natürlich Sinn. Ja nach Ziel gibt es verschiedene Agenten, die solche Logs einsammeln. Aber auch mit Bordmitteln lassen sich interessante Aussagen treffen. Ich habe einfach mal ein "GROUP feldname" gemacht. So ist gut zu sehen, welche Werte die Felder so annehmen können:

Feldname

Ausgabe

Beschreibung

Action

 
Count Name
----- ----
    1 Windows
    1 Local
    1 time
 8536 ALLOW
 2075 DROP
    3 INFO-EVENTS-LOST

Die überwiegende Anzahl an Events finden sich zu "DROP" und "ALLOW". Anscheinend gibt es aber auch Fälle, wo die Events nicht lückenlos aufgezeichnet werden. Die Events "Windows, Local, time" sind die ersten drei Zeilen mit der Überschrift. Leider kann man bei Import-CSV nicht die ersten Zeilen überspringen. Dann müssten Sie ein Get-Content mit Select-Object und ConvertFrom-CSV kombinieren.

Protocol

 
Count Name
----- ----
    1 Firewall
    1
    1 action
 8481 UDP
 2307 TCP
  109 ICMP
    3 -
   34 2

Auch hier sind einige Felder durch die Überschrift zusätzlich. Interessant ist sicher UDP; TCP ICMP. Auch das Protocol "2" = IGMP.

Src-ip
Dst-ip und Ports

entfällt

Diese Gruppierung macht nur bedingt Sinn, da hier die eigene IP-Adresse nach nach Richtung der Verbindung erscheint und die meisten Computer sehr viele Verbindungen haben. Interessant ist aber die Kopplung mit dem Port. Hier ein Beispiel zu ausgehenden DNS-Anfragen:

... |?{$_."dst-port" -eq 53} | group dst-ip -NoElement

Count Name
----- ----
  870 192.168.100.20
  614 192.168.100.21
  746 192.168.178.1
   19 46.105.206.200

Das Log enthält natürlich alle Verbindungen eines Clients. Hier gibt es die beiden DNS-Server in einem Firmennetzwerk aber auch meine Fritz!Box zu sehen und ein DNS-Server von "dns200.anycast.me". Darauf kann man dann weiter filtern und den Zeitraum festlegen, z.B. mit:

... | ?{$_."dst-ip" -eq "46.105.206.200"} | ft date,time 

date       time
----       ----
2019-07-12 20:11:22
2019-07-12 20:11:23
2019-07-12 20:11:24

In meinem Beispiel war das wohl der Start des Tor-Browsers, der eben nicht die DNS-Server des Computers nutzt.

Size

 
Count Name
----- ----
    3 -
11213 0
    3 100
    5 101
    3 102
    2 104

Zuerst habe ich gedacht, dass "Size" komplett leer oder 0 ist. Aber eine Übersicht zeigte dann schon, dass es ganz viele Pakete mit "Size=0" gibt während andere einen Wert enthalten. Über weitere Filter habe ich schnell erkannt, dass werte hier nur bei UDP und TCP vorhanden sind. Bei einer weiteren Einschränkung konnte ich bei mir nur "DROP"-Pakete finden.

Das ist schade, dass die Windows Firewall nicht die Gesamtgröße einer Verbindung mit ausgeben kann, sondern nur bei abgelehnten Paketen die Größe meldet.

Für eine Analyse der Datenmenge wird man doch auf PacketBeat oder NetFlow/sFlow/IPFix/cFlow umsteigen müssen. Wenn alle Komponenten per NetFlow/sFlow/IPFix/cFlow erfassen, dann können Sie sich zumindest im LAN die Firewall Logs sparen.

Sie können als auf die Schnelle auch aus den Windows Firewall Logs schon allein mit etwas Powershell Informationen sammeln

Zentrales Monitoring

Interessant wird dies natürlich, wenn Sie die Daten mehrerer Systeme auf eine zentrale Plattform zusammenführen und dann gezielt Analysen und Regeln hinterlegen. Interessant finde sich z.B.

Report Beschreibung

Invalid DNS-Servers

In einem internen LAN gibt es in der Regel "bekannte" DNS-Server, die von allen Clients gefragt werden. Anfragen auf den Zielport 53/UDP und sonstige IP-Adressen sind ein Hinweis auf eine Fehlkonfiguration

Portscan SMTP

Auch die Mailserver eines Unternehmen, die per SMTP erreichbar sein müssen, lassen sich an einer Hand abzählen. Zugriff auf "DstPort=25/TCP" und andere IP-Adressen sind vielleicht nur eine Fehlkonfiguration oder eben eine Suche nach einem offenen Relay

verbotene Ports

In jedem Netzwerk gibt es erlaubte aber auch explizit verbotene Ports, z.B. sensible Ports oder bekannte Hintertüren etc., deren Verwendung schon zumindest fragwürdig ist. z.B. VPN-Ports, die in der Firma nicht genutzt werden, SQL-Derivate, die nicht lizenziert sind etc. So lassen sich Missbrauch und Umgehungsversuche früh erkennen.

Diese Liste könnten Sie umfangreich weiter führen. Auch eine Auswertung nach "Drops/Zeit" hinsichtlich einem hohen Wachstum kann auf Fehler oder Angriffe hinweisen. Das macht aber, wie gesagt, nur mit einer zentralen Protokoll-Instanz Sinn.

Produkte, die ich mir in dem Zuge an anschauen möchte sind:

Leider bin ich noch nicht dazu gekommen, in die Richtung mal weiter zu recherchieren.

Wenn einer meine Leser mir hier noch weitere Tipps geben möchte, dann schreiben Sie mich doch einfach an

Weitere Links