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.
- 5150(-):
The Windows
Filtering
Platform
blocked a
packet
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5150
- 5151(-):
A more
restrictive
Windows
Filtering
Platform
filter has
blocked a
packet.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5151
- 5152(F):
The Windows
Filtering
Platform
blocked a
packet.
https://docs.microsoft.com/de-de/windows/security/threat-protection/auditing/event-5152
- 5153(S):
A more
restrictive
Windows
Filtering
Platform
filter has
blocked a
packet.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5153
- 5154(S):
The Windows
Filtering
Platform has
permitted an
application
or service
to listen on
a port for
incoming
connections
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5154
- 5155(F):
The Windows
Filtering
Platform has
blocked an
application
or service
from
listening on
a port for
incoming
connections.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5155
- 5156(S):
The Windows
Filtering
Platform has
permitted a
connection
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5156
- 5157(F):
The
Windows
Filtering
Platform
has
blocked
a
connection
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5157
- 5158(S):
The Windows
Filtering
Platform has
permitted a
bind to a
local port.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5158
- 5159(F):
The Windows
Filtering
Platform has
blocked a
bind to a
local port.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5159
- 5031(F):
The Windows
Firewall
Service
blocked an
application
from
accepting
incoming
connections
on the
network.
https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-5031
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.
- Known Issues for Using the Security Log
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc776821%28v%3dws.10%29
- Windows Security Log Event ID 4950 A
Windows Firewall setting has changed
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4950 - Windows Security Log Event ID 5031 The
Windows Firewall Service blocked an
application from accepting incoming
connections on the network.
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=5031
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:
- Windows Firewall not writing to its
logfiles
https://www.neroblanco.co.uk/2017/03/windows-firewall-not-writing-logfiles
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
- Set-NetFirewallProfile
https://docs.microsoft.com/en-us/powershell/module/netsecurity/set-netfirewallprofile?view=win10-ps - NetFirewallProfile "Enabled" arg not
auto variable?
https://powershell.org/forums/topic/netfirewallprofile-enabled-arg-not-auto-variable/
Ü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
- Get-NetFirewallProfile
https://docs.microsoft.com/en-us/powershell/module/netsecurity/get-netfirewallprofile?view=win10-ps
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.
- Interpreting the Windows Firewall Log
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc758040(v=ws.10)
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 |
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
- Learn How to Use PowerShell to Parse the
Firewall Log
https://devblogs.microsoft.com/scripting/learn-how-to-use-powershell-to-parse-the-firewall-log/ - Collecting and sending Windows Firewall Event logs to ELK
https://www.syspanda.com/index.php/2017/10/04/collecting-sending-windows-firewall-event-logs-elk/
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:
- Syslog mit
NXLog Community Edition
NXLOG kann Eventlogs und Logfiles einsammeln und weiterleiten.
Windows Firewall : 133.1. Logging Windows Firewall traffic information
https://nxlog.co/documentation/nxlog-user-guide/windows-firewall.html - Elastic Stack mit Logbeat und eventuell Packetbeat
- Splunk
- Azure Log Services
Sammeln von benutzerdefinierten Protokollen mit dem Log Analytics-Agent in Azure Monitor
https://docs.microsoft.com/de-de/azure/azure-monitor/agents/data-sources-custom-logs - andere
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
-
Firmen werden gehackt
Ein Warnruf an all die "Es wird schon nichts passieren"-Administratoren und Geschäftsführer -
Interne Firewalls
Alle Server in einem Subnetz ist vielleicht nicht optimal. Überlegungen zur internen Segmentierung -
Interne Firewalls
Alle Server in einem Subnetz ist vielleicht nicht optimal. Überlegungen zur internen Segmentierung - Konfigurieren der Windows Defender-Firewall
mit erweitertem Sicherheitsprotokoll
https://docs.microsoft.com/de-de/windows/security/threat-protection/windows-firewall/configure-the-windows-firewall-log - Using the Security Log
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738118(v=ws.10) - Windows-Firewall: Blockierte Verbindungen im Log-File untersuchen
https://www.windowspro.de/wolfgang-sommergut/windows-firewall-blockierte-verbindungen-im-log-file-untersuchen - How to Track Firewall Activity with the
Windows Firewall Log
https://www.howtogeek.com/220204/how-to-track-firewall-activity-with-the-windows-firewall-log/ - Configure the Windows Firewall Log
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc947815(v=ws.10) - Windows-Firewall: Blockierte
Verbindungen im Log-File untersuchen
https://www.windowspro.de/wolfgang-sommergut/windows-firewall-blockierte-verbindungen-im-log-file-untersuchen - Simple Network Monitoring With Windows
Firewall Logging And Reporting
https://www.webspy.com/blog/simple-network-monitoring-with-windows-firewall-logging-and-reporting/ - Sending Windows Firewall Logs zu GrayLog
https://www.scip.ch/en/?labs.20180719 - Enhancements to Behavior Monitoring and Network Inspection System in the Microsoft anti-malware platform
https://techcommunity.microsoft.com/t5/Configuration-Manager-Archive/Enhancements-to-Behavior-Monitoring-and-Network-Inspection/ba-p/273238 - What is
“Microsoft Network Realtime Inspection
Service” (NisSrv.exe) and Why Is It Running
On My PC?
https://www.howtogeek.com/357184/what-is-microsoft-network-realtime-inspection-service-nissrv.exe-and-why-is-it-running-on-my-pc/ - Overview of
the Windows Firewall Security Log File in
Windows XP
http://ecross.mvps.org/howto/overview-of-the-windows-firewall-security-log-file-in-windows-xp.htm - IPredator
Blog: Windows Firewall Logging
https://blog.ipredator.se/howto/windows-firewall-logging.html - Using NXLog with
Elasticsearch and Kibana
https://nxlog.co/news/using-nxlog-elasticsearch-and-kibana
https://nxlog.co/documentation/nxlog-user-guide-full#elasticsearch - Building a Logging Forensics Platform
using ELK (Elasticsearch, Logstash, Kibana)
http://blog.davidvassallo.me/2015/04/21/building-a-logging-forensics-platform-using-elk-elasticsearch-logstash-kibana/ - Windows Logs mit NXLOG
sammeln
https://www.scip.ch/?labs.20141106