Obtention du trafic réseau bloqué sous Windows

• Obtention du trafic réseau bloqué sous Windows

Obtention du trafic réseau bloqué sous Windows

• Obtention du trafic réseau bloqué sous Windows
  • Création d’un projet de test
  • Obtention des événements block via audit
    • Obtention des informations du provider
    • Construction des événements block
  • Surveillance des événements réseau (NET_EVENT)
  • Surveillance des connexions réseau (NetConnection)
  • Introduction à Application Layer Enforcement (ALE)
  • Codage
  • Conclusion
  • Annexe
    • Architecture WFP
    • Flux de données
    • Liens de référence

• Il est nécessaire d’identifier le trafic bloqué, qui comprend les directions entrante et sortante.
• Deux formes de blocage : basé sur la connexion (connection) et basé sur le paquet (packet). Le rejet de paquets est fréquent et courant, nécessitant une revue des raisons du rejet. Le blocage basé sur la connexion correspond mieux aux scénarios de blocage réels à surveiller.
• De nombreux paquets traités normalement sont également rejetés, il faut donc distinguer les actions drop et block. Nous nous concentrons principalement sur les cas de block.

Création d’un projet de test

WFP fonctionne principalement en mode utilisateur, avec une autre partie en mode noyau, dont les capacités se manifestent sous forme de pilotes. La méthode de configuration de l’environnement de test est assez complexe. La méthode recommandée consiste à utiliser une autre machine physique comme machine de test, compiler sur la machine de développement, puis envoyer pour débogage à distance. En raison de contraintes de conditions, nous pouvons également effectuer le débogage localement.

• Projet d’exemple Microsoft WFP
  • Se concentrer uniquement sur : Windows-driver-samples\network\trans\WFPSampler
• Guide du projet WFPSampler

Problèmes de compilation:

• api-ms-win-net-isolation-l1-1-0 manquant
• wfpcalloutsclassreg non trouvé

Autres problèmes:

• Pilote impossible à exécuter
• Comment signer
• Préparation de la machine de test pour le déploiement du pilote

Obtention des événements block via audit

• Documentation sur l’audit
• Documentation sur auditpol

Par défaut, l’audit de WFP est désactivé.

• L’audit peut être activé par catégorie via l’unité de gestion du Gestionnaire d’objets de stratégie de groupe, l’unité de gestion de Stratégie de sécurité locale ou la commande auditpol.exe.
• L’audit peut être activé par sous-catégorie via la commande auditpol.exe.
• Il faut utiliser un GUID pour la configuration, sinon il y a des problèmes de localisation sur différents systèmes linguistiques.
• L’audit utilise des journaux circulaires de 128KB, pas besoin de se soucier de la consommation de ressources.

Catégories https://docs.microsoft.com/en-us/windows/win32/secauthz/auditing-constants

Sous-catégories Object Access et GUID correspondants https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gpac/77878370-0712-47cd-997d-b07053429f6d

Sous-catégories Policy Change et GUID correspondants :

# Voir le manuel auditpol : https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/auditpol
# Cette section se concentre principalement sur la catégorie 'Object Access'
# Obtenir les champs pouvant être interrogés
# -v affiche le GUID, -r affiche un rapport CSV
auditpol /list /category /v
auditpol /list /subcategory:* /v
# Obtenir les paramètres d'audit pour une sous-catégorie spécifique
auditpol /get /category:'Object Access' /r | ConvertFrom-Csv| Get-Member
# Interroger le GUID
auditpol /get /category:'Object Access' /r | ConvertFrom-Csv| Format-Table Subcategory,'Subcategory GUID','Inclusion Setting'
# Rechercher la sous-catégorie
auditpol /list /subcategory:"Object Access","Policy Change" -v
# Sauvegarde
auditpol /backup /file:d:\audit.bak
# Restauration
auditpol /restore /file:d:\audit.bak
# Modifier la politique
# **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

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

Description des événements :

Description détaillée des événements à surveiller :

• Audit Filtering Platform Packet Drop

  • Ces événements se produisent très fréquemment, il est recommandé de se concentrer sur les événements 5157, qui enregistrent presque les mêmes informations, mais 5157 est enregistré par connexion plutôt que par paquet.

  • Le volume des événements d’échec est généralement très élevé pour cette sous-catégorie et est généralement utilisé pour le dépannage. Si vous devez surveiller les connexions bloquées, il est préférable d’utiliser « 5157(F) : La plateforme de filtrage Windows a bloqué une connexion », car elle contient presque les mêmes informations et se génère par connexion, pas par paquet.

  • 5152

  • 5153

• Audit Filtering Platform Connection
  • Il est recommandé de ne surveiller que les événements d’échec, tels que les connexions bloquées, et de surveiller les connexions autorisées selon les besoins.
  • 5031
    • Si vous n’avez aucune règle de pare-feu (Autoriser ou Refuser) dans le Pare-feu Windows pour des applications spécifiques, vous recevrez cet événement de la couche de plateforme de filtrage Windows, car par défaut cette couche refuse toute connexion entrante.
  • 5150
  • 5151
  • 5155
  • 5157
  • 5159

Obtention des informations du provider

# Obtenir les informations du provider liées à la sécurité
Get-WinEvent -ListProvider "*Security*"  | Select-Object providername,id
# Microsoft-Windows-Security-Auditing                             54849625-5478-4994-a5ba-3e3b0328c30d
# Obtenir les informations sur les tâches fournies par le provider
Get-WinEvent -ListProvider "Microsoft-Windows-Security-Auditing"  | Select-Object -ExpandProperty tasks
# SE_ADT_OBJECTACCESS_FIREWALLCONNECTION       12810 Filtering Platform Connection          00000000-0000-0000-0000-000000000000

Construction des événements block

Il est très important de noter que lors de la construction d’événements block, cela affectera le fonctionnement d’autres logiciels locaux ! Vous pouvez utiliser .\WFPSampler.exe -clean pour nettoyer les filtres rapidement.

Étapes opérationnelles :

1. Ouvrez l’audit pour Filtering Platform Connection, auditpol /set /subcategory:"{0CCE9226-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable

2. Ouvrez Event Viewer, créez une Custom View, créez un filtre, nous ne surveillons temporairement que les événements 5155, 5157, 5159.

3. Créez un filtre, nous utilisons WFPSampler.exe pour créer un filtre, bloquant l’écoute du port 80 local, .\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_LISTEN_V4 -iplp 80

4. Utilisez un serveur http tiers (non IIS), ici nginx, écoutant par défaut le port 80, double-cliquez pour lancer, ce qui déclenche l’événement 5155

5. Restaurez le filtre, .\WFPSampler.exe -clean

6. Restaurez l’audit, auditpol /set /category:"{0CCE9226-69AE-11D9-BED3-505054503030}" /success:disable /failure:disable

# 5155 blocked an application or service from listening on a port for incoming connections
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_AUTH_LISTEN_V4
# 5157 blocked a connection
.\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, blocked a bind to a local port
.\WFPSampler.exe -s BASIC_ACTION_BLOCK -l FWPM_LAYER_ALE_RESOURCE_ASSIGNMENT_V4

# Other
.\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

# To find a specific Windows Filtering Platform filter by ID, run the following command:
netsh wfp show filters
# To find a specific Windows Filtering Platform layer ID, you need to execute the following command:
netsh wfp show state

Surveillance des événements réseau (NET_EVENT)

• Les événements réseau prennent en charge l’énumération et l’abonnement.
• La méthode d’énumération prend en charge des conditions de filtrage personnalisées, permettant d’obtenir des événements réseau sur une période donnée.
• La méthode d’abonnement peut injecter une fonction de rappel pour un retour en temps réel.

Types d’événements pris en charge :

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;

Conditions de filtrage prises en charge (FWPM_NET_EVENT_ENUM_TEMPLATE) :

Les appels non pilotes ne peuvent obtenir que les événements drop ordinaires.

Surveillance des connexions réseau (NetConnection)

Par rapport à la surveillance des événements réseau, la surveillance des connexions nécessite des privilèges plus élevés. Mode de rappel

L’appelant a besoin d’un accès FWPM_ACTRL_ENUM aux conteneurs d’objets de connexion et d’un accès FWPM_ACTRL_READ aux objets de connexion. Voir Contrôle d’accès pour plus d’informations.

La surveillance des connexions réseau n’a pas encore été réussie.

J’ai trouvé le même problème, Receiving in/out traffic stats using WFP user-mode API, identique à ce que j’ai rencontré lors de mes recherches, la fonction d’abonnement ne reçoit aucun rapport, aucun événement, aucune erreur. Activer l’audit et augmenter les privilèges n’ont pas réussi. Quelqu’un a indiqué que le mode non noyau ne peut obtenir que les rapports d’événements drop, ce qui ne répond pas au besoin d’obtenir les événements de blocage.

Exemple d’ajout de descripteur de sécurité : https://docs.microsoft.com/en-us/windows/win32/fwp/reserving-ports

Introduction à Application Layer Enforcement (ALE)

• ALE comprend une série de filtres en mode noyau, prenant en charge le filtrage d’état.
• Les filtres de la couche ALE peuvent autoriser la création de connexions, l’allocation de ports, la gestion de sockets, la création de sockets bruts et la réception en mode promiscuous.
• Les filtres de la couche ALE sont classés par connexion (connection) ou par socket, alors que les filtres des autres couches ne peuvent être classés que par paquet (packet).
• Pour plus de filtres ALE, voir ale-layers
  • Pour plus de filtres, voir filtering-layer-identifiers

Codage

La plupart des fonctions WFP peuvent être appelées en mode utilisateur ou en mode noyau. Cependant, les fonctions en mode utilisateur retournent des valeurs DWORD représentant les codes d’erreur Win32, tandis que les fonctions en mode noyau retournent des valeurs NTSTATUS représentant les codes d’état NT. Par conséquent, les noms et la sémantique des fonctions sont identiques entre le mode utilisateur et le mode noyau, mais les signatures de fonctions diffèrent. Cela nécessite des en-têtes distincts spécifiques au mode utilisateur et au mode noyau pour les prototypes de fonctions. Les noms de fichiers d’en-tête en mode utilisateur se terminent par “u”, et les noms de fichiers d’en-tête en mode noyau se terminent par “k”.

Conclusion

Le besoin ne nécessite que de savoir quand un événement se produit, sans traitement instantané, et le développement de pilotes entraîne davantage de risques. Nous décidons donc d’utiliser l’audit des événements et de surveiller la génération d’événements dans les journaux.
Ouvrir un nouveau thread pour utiliser NotifyChangeEventLog afin de surveiller les événements de journalisation.

Annexe

Architecture WFP

WFP (Windows Filter Platform)

Flux de données

Flux de données :

1. Un paquet arrive dans la pile réseau.
2. La pile réseau trouve et appelle un shim.
3. Le shim invoque le processus de classification à une couche particulière.
4. Pendant la classification, les filtres sont appariés et l’action résultante est prise. (Voir Arbitrage des filtres.)
5. Si des filtres de callout sont appariés pendant le processus de classification, les callouts correspondants sont invoqués.
6. Le shim agit sur la décision de filtrage finale (par exemple, supprimer le paquet).

Liens de référence

• Types de filtres
• Conditions de filtres disponibles à chaque couche de filtrage
• Codes d’erreur
• Codes d’erreur WFP

• ←Précédent
• Suivant→