Windows-Netzwerkverkehr blockieren und abrufen

• Windows-Netzwerkverkehr blockieren und abrufen

Windows Netzwerkverkehr blockieren und abrufen

• Windows Netzwerkverkehr blockieren und abrufen
  • Testprojekt einrichten
  • Block-Ereignisse über Audit abrufen
    • Provider-Informationen abrufen
    • Block-Ereignisse erzeugen
  • Netzwerkevents (NET_EVENT) überwachen
  • Netzwerkverbindungen (NetConnection) überwachen
  • Application Layer Enforcement (ALE) Einführung
  • Codierung
  • Fazit
  • Anhang
    • WFP-Architektur
    • Datenfluss
    • Referenzlinks

• Es ist notwendig, den blockierten Datenverkehr zu identifizieren, einschließlich eingehender und ausgehender Richtungen.
• Blockierung erfolgt in zwei Formen: basierend auf Verbindungen (connection) und basierend auf Paketen (packet). Paketverwerfung ist häufiger und üblich, daher muss der Verwerfungsgrund überprüft werden. Blockierung auf Verbindungsebene entspricht eher den tatsächlichen Blockierungsszenarien, die beachtet werden müssen.
• Viele normale Pakete werden ebenfalls verworfen, daher müssen Drop- und Block-Aktionen unterschieden werden. Wir konzentrieren uns hauptsächlich auf Block-Szenarien.

Testprojekt einrichten

WFP arbeitet hauptsächlich im Usermode, ein Teil davon im Kernelmode, wobei die Fähigkeiten in Form von Treibern bereitgestellt werden. Die Einrichtung einer Testumgebung ist komplex. Die empfohlene Methode ist, eine andere physische Maschine als Testgerät zu verwenden, nachdem auf der Entwicklermaschine kompiliert wurde, Remote-Debugging auf dem Testgerät durchzuführen. Aufgrund von Einschränkungen können wir auch lokal debuggen.

• Microsoft WFP Sample Projekt
  • Nur Fokus auf: Windows-driver-samples\network\trans\WFPSampler
• WFPSampler Projektanleitung

Kompilierungsprobleme:

• Fehlende api-ms-win-net-isolation-l1-1-0
• wfpcalloutsclassreg nicht gefunden

Andere Probleme:

• Treiber kann nicht ausgeführt werden
• Wie man signiert
• Testgerät für die Bereitstellung vorbereiten

Block-Ereignisse über Audit abrufen

• Audit Dokumentation
• auditpol Dokumentation

Standardmäßig ist das Audit für WFP deaktiviert.

• Das Audit kann pro Kategorie über die Gruppenrichtlinien-Editor MMC-Verwaltungseinheit, die lokale Sicherheitsrichtlinien MMC-Verwaltungseinheit oder den Befehl auditpol.exe aktiviert werden.
• Das Audit kann pro Unterkategorie über den Befehl auditpol.exe aktiviert werden.
• GUIDs sollten für die Einstellungen verwendet werden, um Probleme mit Lokalisierung in Systemen unterschiedlicher Sprachen zu vermeiden.
• Audit verwendet zirkuläres Logging, 128KB, daher keine Bedenken hinsichtlich Ressourcenverbrauch.

Kategorienhttps://docs.microsoft.com/en-us/windows/win32/secauthz/auditing-constants

Objektzugriff Unterkategorien und entsprechende GUIDs https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpac/77878370-0712-47cd-997d-b07053429f6d

Richtlinienänderung Unterkategorien und entsprechende GUIDs:

# Handbuch zu auditpol: https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/auditpol
# Dieser Abschnitt konzentriert sich hauptsächlich auf die Kategorie 'Objektzugriff'
# Verfügbare Felder abrufen
# -v zeigt GUIDs an, -r zeigt CSV-Bericht
auditpol /list /category /v
auditpol /list /subcategory:* /v
# Einstellungen einer bestimmten Unterkategorie abrufen
auditpol /get /category:'Object Access' /r | ConvertFrom-Csv| Get-Member
# GUID abfragen
auditpol /get /category:'Object Access' /r | ConvertFrom-Csv| Format-Table Subcategory,'Subcategory GUID','Inclusion Setting'
# Unterkategorie suchen
auditpol /list /subcategory:"Object Access","Policy Change" -v
# Backup
auditpol /backup /file:d:\audit.bak
# Wiederherstellen
auditpol /restore /file:d:\audit.bak
# Richtlinie ändern
# **Policy Change**    | {6997984D-797A-11D9-BED3-505054503030}
auditpol /set /category:"{6997984D-797A-11D9-BED3-505054503030}" /success:disable /failure:disable
# Filtering Platform Policy Change | {0CCE9233-69AE-11D9-BED3-505054503030}
auditpol /set /subcategory:"{0CCE9233-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

# **Object Access**    | {6997984A-797A-11D9-BED3-505054503030}
auditpol /get /category:"{6997984A-797A-11D9-BED3-505054503030}"
auditpol /set /category:"{6997984A-797A-11D9-BED3-505054503030}" /success:disable /failure:disable
# Filtering Platform Packet Drop | {0CCE9225-69AE-11D9-BED3-505054503030}
auditpol /set /subcategory:"{0CCE9225-69AE-11D9-BED3-505054503030}" /success:disable /failure:enable
# Filtering Platform Connection  | {0CCE9226-69AE-11D9-BED3-505054503030}
auditpol /set /subcategory:"{0CCE9226-69AE-11D9-BED3-505054503030}" /success:disable /failure:enable

# Ereignisse lesen
$Events = Get-WinEvent -LogName 'Security'
foreach ($event in $Events) {
    ForEach ($line in $($event.Message -split "`r`n")) {
        Write-host $event.RecordId ':' $Line
        break
    }
}

Ereigniserklärungen:

Detaillierte Erklärungen der Ereignisse, auf die wir achten:

• Audit Filtering Platform Packet Drop

  • Diese Ereignisse werden in sehr großer Menge erzeugt. Es wird empfohlen, das Ereignis 5157 zu beachten, da es nahezu die gleichen Informationen aufzeichnet, aber pro Verbindung und nicht pro Paket.

  • Die Menge der Fehlerereignisse ist für diese Unterkategorie in der Regel sehr hoch und wird typischerweise für die Fehlersuche verwendet. Wenn Sie blockierte Verbindungen überwachen müssen, ist es besser, „5157(F): Die Windows Filtering Platform hat eine Verbindung blockiert“, zu verwenden, da es fast die gleichen Informationen enthält und pro Verbindung und nicht pro Paket generiert wird.

  • 5152

  • 5153

• Audit Filtering Platform Connection
  • Es wird empfohlen, nur Fehlerereignisse zu beachten, wie blockierte Verbindungen, und je nach Bedarf erlaubte Verbindungen.
  • 5031
    • Wenn Sie keine Firewallregeln (Allow oder Deny) in Windows Firewall für bestimmte Anwendungen haben, erhalten Sie dieses Ereignis aus der Windows Filtering Platform-Schicht, da diese Schicht standardmäßig alle eingehenden Verbindungen blockiert.
  • 5150
  • 5151
  • 5155
  • 5157
  • 5159

Provider-Informationen abrufen

# Sicherheitsbezogene Provider-Informationen abrufen
Get-WinEvent -ListProvider "*Security*"  | Select-Object providername,id
# Microsoft-Windows-Security-Auditing                             54849625-5478-4994-a5ba-3e3b0328c30d
# Provider bereitgestellte Task-Informationen abrufen
Get-WinEvent -ListProvider "Microsoft-Windows-Security-Auditing"  | Select-Object -ExpandProperty tasks
# SE_ADT_OBJECTACCESS_FIREWALLCONNECTION       12810 Filtering Platform Connection          00000000-0000-0000-0000-000000000000

Block-Ereignisse erzeugen

Es ist sehr wichtig darauf zu achten, dass beim Erzeugen von Block-Ereignissen der Betrieb anderer Software auf dem lokalen Rechner beeinträchtigt wird! Sie können .\WFPSampler.exe -clean verwenden, um Filter zu bereinigen.

Vorgehensweise:

1. Aktivieren Sie den Audit-Schalter für Filtering Platform Connection: auditpol /set /subcategory:"{0CCE9226-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

2. Öffnen Sie den Ereignisanzeiger, erstellen Sie eine benutzerdefinierte Ansicht und ein Filter. Wir konzentrieren uns vorerst nur auf die Ereignisse 5155, 5157 und 5159.

3. Erstellen Sie einen Filter, wir verwenden WFPSampler.exe, um einen Filter zu erzeugen, der das Lauschen auf Port 80 blockiert: .\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_LISTEN_V4 -iplp 80

4. Verwenden Sie einen Drittanbieter-HTTP-Server (nicht IIS), hier nginx, das standardmäßig Port 80 lauscht. Doppelklicken Sie zum Starten, um das Ereignis 5155 auszulösen

5. Filter zurücksetzen: .\WFPSampler.exe -clean

6. Audit-Schalter zurücksetzen: auditpol /set /category:"{0CCE9226-69AE-11D9-BED3-505054503030}" /success:disable /failure:disable

# 5155 blockierte eine Anwendung oder einen Dienst beim Lauschen auf einen Port für eingehende Verbindungen
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_LISTEN_V4
# 5157 blockierte eine Verbindung
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_CONNECT_V4
# 5159 blockierte ein Binden an einen lokalen Port
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V4

# Sonstiges
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V4_DISCARD
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4_DISCARD
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_CONNECT_V4_DISCARD

# Um einen bestimmten Windows Filtering Platform-Filter anhand der ID zu finden, führen Sie den folgenden Befehl aus:
netsh wfp show filters
# Um eine bestimmte Windows Filtering Platform Layer-ID zu finden, müssen Sie den folgenden Befehl ausführen:
netsh wfp show state

Netzwerkevents (NET_EVENT) überwachen

• Netzwerkevents unterstützen Enumeration und Abonnement.
• Enumerationsweise unterstützt benutzerdefinierte Filterbedingungen und erhält Netzwerkevents innerhalb eines bestimmten Zeitraums.
• Abonnementweise kann eine Callback-Funktion injizieren, die Echtzeit-Feedback liefert.

Unterstützte Ereignistypen:

typedef enum FWPM_NET_EVENT_TYPE_ {
  FWPM_NET_EVENT_TYPE_IKEEXT_MM_FAILURE = 0,
  FWPM_NET_EVENT_TYPE_IKEEXT_QM_FAILURE,
  FWPM_NET_EVENT_TYPE_IKEEXT_EM_FAILURE,
  FWPM_NET_EVENT_TYPE_CLASSIFY_DROP,
  FWPM_NET_EVENT_TYPE_IPSEC_KERNEL_DROP,
  FWPM_NET_EVENT_TYPE_IPSEC_DOSP_DROP,
  FWPM_NET_EVENT_TYPE_CLASSIFY_ALLOW,
  FWPM_NET_EVENT_TYPE_CAPABILITY_DROP,
  FWPM_NET_EVENT_TYPE_CAPABILITY_ALLOW,
  FWPM_NET_EVENT_TYPE_CLASSIFY_DROP_MAC,
  FWPM_NET_EVENT_TYPE_LPM_PACKET_ARRIVAL,
  FWPM_NET_EVENT_TYPE_MAX
} FWPM_NET_EVENT_TYPE;

Unterstützte Filterbedingungen (FWPM_NET_EVENT_ENUM_TEMPLATE):

Nicht-Treiber-Aufrufe können nur normale Drop-Ereignisse erhalten.

Netzwerkverbindungen (NetConnection) überwachen

Im Vergleich zur Überwachung von Netzwerkevents erfordert die Überwachung von Verbindungen höhere Berechtigungen. Callback-Verfahren

Der Aufrufer benötigt FWPM_ACTRL_ENUM-Zugriff auf die Container der Verbindungsobjekte und FWPM_ACTRL_READ-Zugriff auf die Verbindungsobjekte. Weitere Informationen finden Sie unter Access Control.

Überwachung von Netzwerkverbindungen war bisher nicht erfolgreich.

Gleiche Probleme gefunden, Receiving in/out traffic stats using WFP user-mode API, gleiche Phänomene wie in meiner Untersuchung, die Abonnementfunktion erhält keine Rückmeldungen, keine Ereignisse, keine Fehler. Jemand hat darauf hingewiesen, dass im Nicht-Kernelmodus nur Drop-Ereignisse gemeldet werden können, was nicht ausreicht, um Blockierungsereignisse zu erhalten.

Beispiel zum Hinzufügen von Sicherheitsdeskriptoren: https://docs.microsoft.com/en-us/windows/win32/fwp/reserving-ports

Application Layer Enforcement (ALE) Einführung

• ALE umfasst eine Reihe von Filtern im Kernelmodus, die Zustandsfilterung unterstützen.
• ALE-Ebene Filter können die Erstellung von Verbindungen, Portzuweisungen, Socket-Management, Raw-Socket-Erstellung und promiskuitiven Empfang autorisieren.
• ALE-Ebene Filter werden entweder nach Verbindung (connection) oder nach Socket klassifiziert, während Filter auf anderen Ebenen nur nach Paket klassifiziert werden können.
• ALE-Filter-Referenz ale-layers
  • Weitere Filter-Referenz filtering-layer-identifiers

Codierung

Die meisten WFP-Funktionen können sowohl aus Usermode als auch aus Kernelmode aufgerufen werden. Allerdings geben Usermode-Funktionen DWORD-Werte zurück, die Win32-Fehlercodes darstellen, während Kernelmode-Funktionen NTSTATUS-Werte zurückgeben, die NT-Statuscodes darstellen. Daher sind Funktionsnamen und Semantik zwischen Usermode und Kernelmode gleich, aber die Funktions-Signaturen unterscheiden sich. Dies erfordert separate Header für Usermode und Kernelmode-spezifische Funktionsprototypen. Usermode-Header enden mit “u”, Kernelmode-Header mit “k”.

Fazit

Die Anforderung erfordert nur das Wissen um das Eintreten von Ereignissen, nicht die sofortige Verarbeitung von Ereignissen. Außerdem bringt die Entwicklung von Treibern ein höheres Risiko mit sich. Daher wird beschlossen, die Ereignisüberwachung zu verwenden und Ereignisse durch Überwachung von Protokollaufzeichnungen zu erhalten. Ein neuer Thread wird erstellt, um NotifyChangeEventLog zu verwenden, um Protokollaufzeichnungsereignisse zu überwachen.

Anhang

WFP-Architektur

WFP (Windows Filter Platform)

Datenfluss

Datenfluss:

1. Ein Paket kommt in den Netzwerkstapel.
2. Der Netzwerkstapel findet und ruft ein Shim auf.
3. Das Shim ruft den Klassifizierungsprozess auf einer bestimmten Ebene auf.
4. Während der Klassifizierung werden Filter abgeglichen und die resultierende Aktion ausgeführt. (Siehe Filterarbitrierung.)
5. Wenn während des Klassifizierungsprozesses Callout-Filter abgeglichen werden, werden die entsprechenden Callouts aufgerufen.
6. Das Shim agiert entsprechend der endgültigen Filterentscheidung (z. B. Paket verwerfen).

Referenzlinks

• Filtertypen
• Zusätzliche Bedingungen für Filter
• Fehlercodes
• WFP-Fehlercodes

• ←Zurück
• Weiter→