Journalisation et surveillance efficaces du pare-feu Windows

Un pare-feu hôte qui bloque le trafic sans prévenir personne n'est qu'un demi-contrôle. Les rejets qu'il enregistre révèlent les scans, les tentatives de mouvement latéral et les applications mal configurées. Ses événements de modification de configuration révèlent un attaquant qui ouvre un port pour ses outils ou désactive le pare-feu. La plupart des environnements ne collectent ni les uns ni les autres.

Le guide pilier sur le durcissement du pare-feu Windows fixe la stratégie : tous les profils actifs, entrant bloqué par défaut, protocoles d'administration limités aux hôtes de gestion. Ce guide construit la surveillance par-dessus. Il y a trois sources, chacune avec un rôle différent :

La vue d'ensemble du domaine se trouve sur la page thématique Pare-feu Windows.

Étape 1 : configurer pfirewall.log par profil

Chemin GPO : Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Ouvrez les propriétés et, sur chacun des onglets Domain Profile, Private Profile et Public Profile, cliquez sur Customize sous Logging :

Quand le fichier atteint sa taille limite, Windows le renomme en pfirewall.log.old et en commence un nouveau, en écrasant le .old précédent. Sur un serveur bavard, cela peut ne représenter que quelques heures d'historique : collectez le fichier ou appuyez-vous sur les événements de l'étape 2.

Vous pouvez utiliser un fichier distinct par profil (domainfw.log, publicfw.log) pour voir d'un coup d'œil dans quel profil se trouvait un portable lorsqu'un paquet a été rejeté. Si vous placez le journal ailleurs que dans le dossier par défaut, le service de pare-feu doit pouvoir y écrire :

$path = 'D:\Logs\Firewall'
New-Item -ItemType Directory -Path $path -Force | Out-Null
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
  'NT SERVICE\mpssvc','Modify','ContainerInherit,ObjectInherit','None','Allow')
$acl.AddAccessRule($rule); Set-Acl -Path $path -AclObject $acl

Dans Intune, les paramètres de profil équivalents se trouvent dans le catalogue de paramètres, catégorie Firewall, par profil : Log File Path, Log Max File Size, Enable Log Dropped Packets et Enable Log Success Connections (CSP Firewall MdmStore/DomainProfile/LogFilePath, LogMaxFileSize, EnableLogDroppedPackets, EnableLogSuccessConnections, et les mêmes sous PrivateProfile et PublicProfile). Sur un appareil qui reçoit aussi la stratégie de groupe, la valeur GPO du chemin et de la taille du journal l'emporte sur la valeur MDM.

Lire le fichier

Le fichier est délimité par des espaces avec une ligne d'en-tête #Fields:. Analysez-le à partir de cet en-tête plutôt que de supposer un ordre de colonnes fixe, car les builds récentes de Windows ont ajouté des champs :

$log = "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log"
$fields = (Get-Content $log -TotalCount 10 | Where-Object { $_ -like '#Fields:*' }) -replace '^#Fields:\s*' -split ' '
Get-Content $log | Where-Object { $_ -and $_ -notlike '#*' } |
  ConvertFrom-Csv -Delimiter ' ' -Header $fields |
  Where-Object action -eq 'DROP' |
  Group-Object 'src-ip','dst-port' | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Une source unique qui frappe de nombreux ports, ou de nombreuses sources internes qui frappent TCP 445 ou 5985 sur les postes de travail : c'est exactement le schéma que les règles du guide pilier sont conçues pour stopper.

Étape 2 : activer l'audit de la plateforme de filtrage Windows

WFP est le moteur sous-jacent du pare-feu. Ses événements d'audit sont plus utiles que le journal texte pour la surveillance centralisée, car ils incluent le chemin de l'application et la direction, et passent par le pipeline d'événements habituel.

Chemin GPO : Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object Access :

Rappelez-vous que la stratégie d'audit avancée ne s'applique que si Audit: Force audit policy subcategory settings to override audit policy category settings est activé sous Security Options, ce que fait déjà tout référentiel moderne.

Sur une seule machine, pour tester :

auditpol /set /subcategory:"Filtering Platform Connection" /failure:enable
auditpol /get /subcategory:"Filtering Platform Connection","MPSSVC Rule-Level Policy Change"

L'événement 5157 indique « The Windows Filtering Platform has blocked a connection » et contient le processus (sous forme de chemin de périphérique comme \device\harddiskvolume3\windows\system32\svchost.exe), la direction, les adresses et ports source et destination, le protocole et un Filter Run-Time ID. Pour retrouver le filtre ou la règle à l'origine d'un blocage, exportez l'état WFP et cherchez cet identifiant :

netsh wfp show filters file="$env:TEMP\filters.xml"
Select-String -Path "$env:TEMP\filters.xml" -Pattern '<filterId>123456</filterId>' -Context 0,20

Notez que 5157 se déclenche aussi pour les paquets rejetés par l'action de blocage par défaut, pas seulement par des règles de blocage explicites : un flux continu de 5157 est donc normal. Ce qui compte, c'est qui est bloqué et depuis où.

Étape 3 : toujours auditer les modifications de configuration du pare-feu

Les modifications de configuration sont rares, peu coûteuses à collecter et à forte valeur. Activez Audit MPSSVC Rule-Level Policy Change en succès et en échec sous Advanced Audit Policy Configuration > Audit Policies > Policy Change. Les événements clés du journal Sécurité :

L'actualisation de la stratégie de groupe produit des 4954 et, sur certaines builds, des rafales de 4946/4948 lorsque les règles de stratégie sont réappliquées. Construisez votre détection autour des modifications qui ne coïncident pas avec une actualisation de stratégie, ou qui proviennent d'un processus autre que ceux de votre outillage de gestion.

Le journal Applications and Services Logs > Microsoft > Windows > Windows Firewall With Advanced Security > Firewall enregistre les mêmes modifications avec le détail des règles et l'application qui les a faites. Ses ID d'événements varient selon les versions de Windows (les anciennes builds utilisaient 2004, 2005 et 2006 pour les règles ajoutées, modifiées et supprimées) : vérifiez les ID sur vos images Windows 11 24H2/25H2 et Server 2025 actuelles avant d'écrire des règles de détection dessus.

Surveillez aussi le service lui-même. Un attaquant qui arrête MpsSvc ou modifie son type de démarrage laisse des événements 7036 et 7040 du Service Control Manager dans le journal Système.

Étape 4 : transférer ce qui compte

Pour les événements WFP et de modification de stratégie, Windows Event Forwarding (voir l'entrée du glossaire WEF) ou votre agent SIEM assure le transport. Gardez l'abonnement serré pour que les 5157 ne noient pas le collecteur :

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID&gt;=4946 and EventID&lt;=4950) or EventID=4954 or EventID=4956]]</Select>
    <Select Path="Security">*[System[EventID=5157]] and *[EventData[Data[@Name='Direction']='%%14592']]</Select>
  </Query>
</QueryList>

%%14592 est la valeur de la direction entrante. Les connexions entrantes bloquées sur les postes de travail sont celles qui intéressent pour le mouvement latéral ; les blocages sortants sont plus bruyants et surtout utiles sur les serveurs en refus sortant par défaut. Si le volume reste trop élevé, ne collectez les 5157 que sur les serveurs et un échantillon de postes, et appuyez-vous sur la télémétrie réseau de l'EDR pour le reste.

Pour pfirewall.log, pointez votre agent de journaux sur le fichier (et sur le fichier .old) et analysez-le avec les champs d'en-tête présentés plus haut.

Idées de détection

• Pare-feu désactivé ou entrant par défaut passé à Allow : 4950 pour n'importe quel profil, hors fenêtre de changement. Alerte immédiate.
• Nouvelle règle d'autorisation entrante créée localement : un 4946 sur un appareil où la fusion des règles locales est désactivée provient souvent d'un attaquant ou d'un programme d'installation et restera sans effet, mais il signale une intention.
• Scan interne : une adresse source qui produit des 5157 contre de nombreux hôtes ou ports de destination en quelques minutes.
• Trafic d'administration de poste à poste : 5157 entrant sur TCP 445, 135, 3389 ou 5985 depuis des sous-réseaux non administratifs.
• SMB sortant bloqué vers Internet : tentative d'authentification forcée ou d'exfiltration de données.

La référence des ID d'événements de sécurité les place à côté des événements d'ouverture de session et de processus avec lesquels vous les corrélerez.

Ce qui casse

• Rotation du journal Sécurité : activer l'audit des succès de Filtering Platform Connection sur tout le parc peut faire tourner le journal Sécurité en quelques minutes et masquer les événements d'ouverture de session. Augmentez la taille du journal Sécurité (au moins 1 Go sur les serveurs) et limitez-vous aux échecs sur les clients.
• Charge du collecteur : un abonnement 5157 non filtré est souvent la première source d'événements d'un déploiement WEF. Filtrez à la source avec XPath.
• Chemins de journal personnalisés sans droit d'écriture pour NT SERVICE\mpssvc : aucun fichier n'est produit, sans erreur visible.
• Profil inadapté : une journalisation configurée uniquement dans le profil Domaine ne donne rien quand un portable est sur le profil Public à domicile.

Vérifier

Contrôlez la configuration de journalisation effective, qui reflète la GPO et le MDM plutôt que les paramètres locaux :

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, LogFileName, LogMaxSizeKilobytes, LogBlocked, LogAllowed
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory
auditpol /get /subcategory:"Filtering Platform Connection","MPSSVC Rule-Level Policy Change"

Testez ensuite de bout en bout : depuis un poste non administratif, lancez Test-NetConnection <target> -Port 445 contre un autre poste. Sur la cible, vous devez voir une ligne DROP TCP dans pfirewall.log et un événement 5157 ; sur le collecteur, le 5157 doit arriver dans votre intervalle de transfert. Enfin, ajoutez puis supprimez une règle de test inoffensive et confirmez que 4946 et 4948 atteignent le SIEM.

Liste de contrôle

• Journalisation des paquets rejetés active dans les trois profils, taille de fichier d'au moins 16 Mo
• Chemins de journal personnalisés accessibles en écriture à NT SERVICE\mpssvc
• Filtering Platform Connection audité en échec ; succès uniquement sur des serveurs choisis
• MPSSVC Rule-Level Policy Change audité en succès et en échec
• Événements 4946-4950, 4954 et 5157 (filtré) transférés au SIEM
• Alertes sur pare-feu désactivé, règles d'autorisation locales et schémas de scan interne
• Test de bout en bout réalisé : connexion bloquée et modification de règle visibles centralement

La journalisation n'est utile que si la stratégie qui la sous-tend est cohérente sur tout le parc ; l'étape suivante consiste à gérer la stratégie de pare-feu à grande échelle.