Windows Defender Firewall et les applications métier — enregistrer les règles entrantes depuis l'installateur

« Ça fonctionne sur le poste de développement, mais une fois installé chez le client, une autre machine ne peut pas s’y connecter. » Il y a des situations où un signalement de ce type fait soupçonner Windows Defender Firewall. Mais un échec de communication et un blocage par le pare-feu ne sont pas la même chose. Parfois l’application n’écoute pas du tout ; parfois la destination ou le port est faux ; parfois la règle d’autorisation ne correspond pas aux conditions du réseau.

Sur un poste de développement, des règles d’autorisation créées par le passé sont souvent encore là. Vérifier le comportement dans cet état ne reproduit pas celui d’un site d’installation neuf. Plutôt que de supposer que quelqu’un approuvera l’avertissement du premier lancement, la procédure de déploiement du produit doit couvrir quel trafic est autorisé, par qui, et à quelle étape. Microsoft recommande également de placer les règles requises avant le premier lancement de l’application.¹

Cet article prend pour exemple principal une application métier qui accepte des connexions TCP depuis une autre machine, et parcourt la conception des règles, l’intégration de l’enregistrement dans l’installateur, et l’ordre de vérification lorsque le trafic échoue chez un client. Il suppose un fonctionnement sous Windows 11 et Windows Server, et les explications techniques s’appuient sur la documentation publique de Microsoft confirmée le 8 septembre 2026. Les noms de produits, chemins, ports et plages d’IP dans les commandes sont des exemples. Remplacez-les pour correspondre à votre environnement.

1. D’abord la conclusion

Trois points à poser d’emblée.

• Le besoin d’une règle entrante se décide d’après le sens du trafic, pas d’après le nom de l’application. Distinguez le simple fait d’initier des connexions et l’écoute de nouveau trafic depuis une autre machine.²
• Placez les règles requises avant le premier lancement. Sur les machines où la gestion locale est permise, l’installateur est une option ; sur les machines gérées de façon centralisée, la distribution par stratégie de groupe, Intune ou un mécanisme similaire l’est.¹
• Quand quelque chose casse, vérifiez dans l’ordre : état d’écoute, connexion TCP, profil, règles, journal. L’important est de ne pas conclure que le trafic est autorisé du seul fait qu’une règle existe, ni que les paquets ne sont jamais arrivés du seul fait qu’il n’y a pas d’entrée de journal.³⁴⁵⁶

La conclusion de cet article, « l’enregistrer depuis l’installateur », ne signifie pas outrepasser la stratégie gérée de l’organisation. Elle signifie mettre en place les paramètres qu’exige le trafic pendant une étape de déploiement à la responsabilité claire, plutôt que dans la première interaction d’un utilisateur.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (35 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Bien comprendre le comportement par défaut — entrant bloqué par défaut, sortant autorisé par défaut

Windows Defender Firewall est un pare-feu hôte qui contrôle le trafic de la machine sur laquelle il s’exécute. Par défaut, il bloque le trafic entrant qui n’est ni une réponse à une requête ni une correspondance avec une règle d’autorisation, et il autorise le trafic sortant sauf si quelque chose comme une règle de blocage s’applique. Ce sont les valeurs par défaut de Windows, et elles ne garantissent pas que l’administrateur chez le client ne les a pas changées.²

Par exemple, si un client de saisie de commandes se connecte au TCP 50051 du serveur de saisie de commandes, c’est le serveur qui accepte la nouvelle connexion. Le client n’ouvre pas un port entrant du même numéro pour recevoir les réponses sur cette connexion.²

Les tubes nommés distants passent par SMB. Le SMB directement hébergé, le plus courant, utilise le TCP 445, donc une règle d’autorisation pour l’exe de votre propre application ne résout pas forcément le problème. Distinguez les tubes nommés locaux de l’usage à travers le réseau. L’authentification SMB et les droits d’accès sont également nécessaires séparément.⁷⁸

Le schéma ci-dessous, partant du blocage entrant par défaut, sert à localiser les parties qui acceptent des connexions depuis une autre machine. « Règle entrante requise » signifie qu’un paramètre autorisant le trafic entrant est nécessaire ; lorsque des règles gérées existantes le couvrent déjà, l’application n’a pas besoin d’ajouter une règle en double. Le trafic qui reste sur le même PC, et le trafic UDP, sont traités à part de ce schéma de connexions TCP.

flowchart TB
    APP["Inventorier le trafic de votre application"] --> Q{"Ouvre-t-elle un port et<br/>écoute-t-elle des connexions"}
    Q -- "N'écoute pas<br/>(se connecte seulement comme client)" --> C1["Règle entrante généralement inutile<br/>le trafic de retour passe comme une réponse"]
    Q -- "Écoute<br/>(type serveur ou récepteur de rappel)" --> S1["Règle entrante requise<br/>-> enregistrer depuis l'installateur (section 5)"]
    C1 -.-> EX["Exception : là où le sortant est bloqué par défaut<br/>dans un environnement haute sécurité, demander une règle sortante"]

Dans les environnements où le défaut sortant a été changé en blocage, ou où une règle interdit explicitement le trafic sortant de l’application, le côté qui se connecte a aussi besoin d’une règle d’autorisation. On ne peut pas dire d’emblée « c’est un client, donc le pare-feu n’entre pas en ligne de compte ».¹ Si vous voulez revoir le mécanisme de communication lui-même, voir aussi comment choisir une méthode de communication inter-processus.

2.1. Les profils et « l’emplacement réseau »

Chaque règle porte une condition indiquant dans quels profils réseau elle est active. La façon typique dont chacun s’applique est la suivante.²

Vous pouvez vérifier le réseau actuellement connecté avec la commande suivante. Sur les machines qui ont plusieurs adaptateurs ou un VPN, faites correspondre non seulement le nom mais aussi l’interface utilisée pour le trafic.²

Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Une règle limitée à Domaine et Privé ne s’applique pas si le trafic en question appartient au profil Public. Ce qui compte, toutefois, c’est de ne pas basculer le réseau en Privé ni élargir la règle à tous les profils juste pour faire passer le trafic. Décidez avec l’administrateur jusqu’où le réseau du client est de confiance et pour quels profils l’application est autorisée.

2.2. La priorité des règles

Avec les règles d’autorisation et de blocage ordinaires, une autorisation explicite l’emporte sur le blocage entrant par défaut, mais une règle de blocage explicite qui correspond au même trafic l’emporte sur une règle d’autorisation conflictuelle. Ce n’est pas un mécanisme où ce qui a été ajouté en dernier l’emporte.¹

Donc, lorsque « nous avons ajouté une règle d’autorisation et rien n’a changé », regardez si les conditions d’autorisation correspondent, et examinez aussi les règles de blocage qui s’appliquent à la même application ou au même port. Le simple fait d’avoir une règle qui arrête un trafic sans rapport n’arrête pas tout le trafic de cette machine. Les règles de contournement spéciales qui utilisent l’authentification IPsec sont un autre type de conception que les règles d’autorisation ordinaires traitées ici.

3. Ce qu’est vraiment la boîte de dialogue « Alerte de sécurité » — pourquoi il ne faut pas s’y fier

Lorsqu’une application sans règle correspondante commence à écouter, une notification indiquant que le Pare-feu Windows Defender a bloqué certaines fonctionnalités de cette application apparaît, selon la configuration et les conditions d’exécution. Elle n’apparaît pas sur les machines gérées où les notifications ont été désactivées, donc l’absence d’avertissement n’est pas une preuve que le trafic a été autorisé.¹

Microsoft décrit le comportement lorsque la notification s’affiche comme suit.¹

Une fois qu’une règle créée de cette façon est laissée en place, redémarrer l’application ne ramène pas la même invite. Si une règle de blocage a été créée en particulier, ajouter une règle d’autorisation seule peut ne pas suffire. Après avoir vérifié d’où vient chaque règle et si elle est nécessaire, l’administrateur les nettoie dans un périmètre limité. L’application ne doit jamais supprimer une règle de blocage que l’organisation a délibérément distribuée.

Le schéma suivant montre comment une règle est créée à partir de la notification. Les conditions dans lesquelles la notification apparaît réellement, et le libellé à l’écran, varient selon l’OS et les paramètres de gestion.

flowchart TB
    L["Une application commence à écouter un port"] --> Q1{"Existe-t-il une règle qui<br/>correspond à cette application"}
    Q1 -- "Oui" --> R1["La règle s'applique<br/>(aucune boîte de dialogue n'apparaît)"]
    Q1 -- "Non" --> Q2{"Les notifications entrantes<br/>sont-elles activées"}
    Q2 -- "Désactivées" --> R2["Bloqué en silence<br/>(aucune règle n'est créée)"]
    Q2 -- "Activées" --> DLG["Boîte de dialogue Alerte de sécurité Windows"]
    DLG -- "L'administrateur choisit Autoriser l'accès" --> OK["Une règle d'autorisation est créée"]
    DLG -- "L'administrateur choisit Annuler" --> NG1["Une règle de blocage est créée"]
    DLG -- "Utilisateur sans droits d'administrateur<br/>(n'importe quel choix)" --> NG2["Une règle de blocage est créée"]
    NG1 --> NEVER["La boîte de dialogue n'apparaît plus<br/>tant que la règle n'est pas supprimée"]
    NG2 --> NEVER

Même si quelqu’un l’approuve une fois au moment du déploiement, les conditions restent : une autre fonctionnalité commence à écouter, le profil réseau change, une mise à jour change le chemin de l’exe. Inventorier d’abord le trafic requis et préparer les règles avant le premier lancement rend le déploiement plus reproductible.¹

Pour les machines utilisées par des non-administrateurs, Microsoft recommande de placer les règles à l’avance et de désactiver les notifications entrantes. Les notifications se contrôlent avec Set-NetFirewallProfile -NotifyOnListen False ou par stratégie de groupe, mais c’est une décision de celui qui gère la stratégie de notification à l’échelle de la machine. Ce n’est pas une raison pour que l’installateur d’une application métier change, sans autorisation, un paramètre de notification qui touche aussi d’autres applications. Couper les notifications n’autorise pas le trafic dont vous avez besoin.¹⁹

4. Concevoir les règles entrantes — par programme, par port, par service

Commencez par écrire la spécification de communication en la découpant en entrant/sortant, TCP/UDP, port d’écoute, entité qui s’exécute, source distante et réseau utilisé. Puis combinez cela dans les conditions de la règle.¹⁰

Ce que vous passez à -Program, c’est l’exe qui effectue réellement la communication, pas un raccourci ni un lanceur. Si c’est un autre service ou processus hôte qui écoute, la conception doit correspondre à cette entité qui s’exécute. Même lorsque des ports dynamiques sont utilisés, n’ouvrez pas tout de suite tous les ports sans condition ; examinez jusqu’où vous pouvez resserrer par programme, service, source distante, etc.¹⁰³

Au-delà, limitez les réseaux utilisés avec -Profile et la source distante avec -RemoteAddress. Par exemple, si les clients de saisie de commandes sont connus pour se trouver dans 172.16.10.0/24, indiquez cette plage. LocalSubnet est un paramètre utilisable sur les petits réseaux et analogues, mais cela ne signifie pas que « tous les sites de l’entreprise » ou « l’autre côté du VPN » sont automatiquement inclus. Vérifiez la route réelle et l’adresse source telle que le côté récepteur la voit.¹¹⁰

Une fonctionnalité qui n’utilise que TCP n’a pas besoin que UDP soit autorisé « au cas où ». Et si une fonctionnalité uniquement interne doit aussi être activée sur Public, soyez prêt à expliquer séparément le besoin et la restriction des sources distantes. Le point de départ de la conception des règles est de ne laisser passer que le trafic dont vous avez besoin, pour le programme dont vous avez besoin, depuis les pairs dont vous avez besoin.

5. Enregistrer les règles depuis l’installateur en pratique — netsh et New-NetFirewallRule

5.1. Prérequis : des privilèges d’administrateur sont nécessaires

L’enregistrement, la modification ou la suppression de règles de pare-feu à l’échelle de la machine s’exécute avec des privilèges d’administrateur élevés. Même un utilisateur du groupe Administrateurs ne s’en sort pas forcément sans élévation UAC.¹¹

Si vous placez l’étape d’enregistrement dans la phase élevée de l’installateur, l’application elle-même n’a pas à s’exécuter en tant qu’administrateur en permanence. À l’inverse, un installateur par utilisateur qui se termine entièrement en utilisateur standard n’a pas le droit de changer les règles à l’échelle de la machine. Dans ce cas, faites d’une installation séparée exécutée par un administrateur, ou d’une distribution de la règle par l’organisation, une exigence de déploiement. Tenez les situations qui exigent des privilèges d’administrateur séparées des privilèges dont l’application a besoin pour l’exécution quotidienne.

Ce qui suit suppose que votre propre exe écoute sur un port fixe et que la machine autorise l’installateur à gérer les règles locales. Il n’inclut rien qui lève les restrictions imposées par une stratégie gérée.

5.2. Enregistrer avec netsh advfirewall

Avec netsh, vous pouvez indiquer ensemble le programme, le port TCP, les profils et la source distante comme suit. C’est un exemple de premier enregistrement sur une machine qui n’a pas encore la même règle. Il suppose une exécution en fichier batch depuis une invite de commandes démarrée en tant qu’administrateur.¹¹

@echo off
netsh advfirewall firewall add rule ^
  name="MyCompany OrderServer TCP 50051 In" ^
  dir=in action=allow enable=yes ^
  program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" ^
  protocol=TCP localport=50051 ^
  profile=domain,private remoteip=172.16.10.0/24
if errorlevel 1 exit /b 1

Répéter le même add rule ne met rien à jour, et peut vous laisser de plus en plus de règles du même nom. Supprimer la règle puis la recréer a son propre problème : si l’enregistrement échoue après la suppression, la règle a disparu. Pour les produits qui répètent réparations et mises à jour, la recommandation est une conception qui fixe un identifiant et met à jour la règle existante, comme dans la section suivante.

La commande de retrait est séparée. Exécutez la suppression ci-dessous uniquement à la désinstallation ; ne l’ajoutez pas à la fin du fichier batch d’enregistrement ci-dessus. Elle cible les règles qui correspondent au nom, donc utilisez un nom qui n’entre pas en collision avec d’autres produits.¹¹

netsh advfirewall firewall delete rule name="MyCompany OrderServer TCP 50051 In"

Enregistrez les codes de sortie et la sortie d’erreur dans le journal de l’installateur, et distinguez « échec de l’enregistrement », « déjà supprimé » et « pas de droit ». Il importe aussi de ne pas dire à l’utilisateur que la préparation de la communication est terminée alors que l’enregistrement a en fait échoué.

5.3. Enregistrer avec PowerShell (New-NetFirewallRule)

Le module NetSecurity de PowerShell permet de séparer -Name, qui identifie la règle, de -DisplayName, qui s’affiche à l’écran. Pour l’identifiant d’un script, utilisez un -Name fixe, non affecté par la langue d’affichage ni par les changements de libellé.¹⁰

Voici un exemple pour l’installation, la réparation et la mise à jour qui ne multiplie pas les règles lorsque le même traitement s’exécute à nouveau. Il utilise Set-NetFirewallRule si la règle existe déjà et New-NetFirewallRule sinon. Le paramètre pour mettre à jour le nom d’affichage est -NewDisplayName.¹²

# Pour l'installation, la réparation et la mise à jour. Exécuter en tant qu'administrateur.
$ErrorActionPreference = "Stop"
$ruleName = "MyCompany-OrderServer-In"
$displayName = "MyCompany OrderServer (TCP 50051 inbound)"
$program = "C:\Program Files\MyCompany\OrderServer\OrderServer.exe"

if (-not (Test-Path -LiteralPath $program -PathType Leaf)) {
    throw "Exécutable introuvable : $program"
}

# Paramètres de la règle locale que ce produit possède.
# Remplacer la source distante et les profils par les valeurs convenues avec l'administrateur du site.
$settings = @{
    PolicyStore   = "PersistentStore"
    Direction     = "Inbound"
    Action        = "Allow"
    Enabled       = "True"
    Program       = $program
    Protocol      = "TCP"
    LocalPort     = 50051
    Profile       = @("Domain", "Private")
    RemoteAddress = "172.16.10.0/24"
}

# Distinguer « la règle n'existe pas » d'un échec de la requête elle-même.
$existing = @(Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq $ruleName })

if ($existing.Count -eq 0) {
    New-NetFirewallRule -Name $ruleName -DisplayName $displayName @settings |
        Out-Null
} else {
    Set-NetFirewallRule -Name $ruleName -NewDisplayName $displayName @settings
}

Ce que cet exemple change, c’est seulement la règle du PersistentStore dont le nom est géré par votre société. N’utilisez pas le même identifiant à une autre fin. Et dans un produit qui a ensuite ajouté des conditions telles qu’un port source ou un service, concevez aussi explicitement la migration de ces conditions. Set-NetFirewallRule ne remet pas à l’état initial toutes les conditions que vous n’avez pas spécifiées.¹²

La suppression va dans le traitement réservé à la désinstallation suivant. Il ne supprime rien si la règle cible est absente, mais il ne masque pas un échec de la requête ou de la suppression elle-même.⁵⁹

# Pour la désinstallation. Ne pas l'exécuter juste après le traitement d'enregistrement.
$ErrorActionPreference = "Stop"
Get-NetFirewallRule -PolicyStore PersistentStore -ErrorAction Stop |
    Where-Object { $_.Name -eq "MyCompany-OrderServer-In" } |
    Remove-NetFirewallRule -ErrorAction Stop

Ce sont des exemples du traitement d’enregistrement, pas une implémentation de la transaction globale de l’installateur. Lorsque vous les intégrez à un produit, confirmez qu’un échec de changement de paramètre est remonté à l’installateur, qu’une mise à jour en échec peut revenir à l’ancienne version et aux anciens paramètres, et que la désinstallation ne supprime que vos propres règles.

5.4. Quand une mise à jour change le chemin de l’exe

Une règle par programme utilise le chemin enregistré comme condition. Par exemple, même s’il existe une règle pour l’exe du dossier v1.0, une fois que c’est l’exe du dossier v1.1 qui écoute après une mise à jour, cette ancienne règle ne correspond plus au nouvel exe.¹¹⁰

Le schéma suivant couvre le cas où vous ne dépendiez que de cette règle à l’ancien chemin. Il ne représente pas uniformément les cas où une autre règle d’autorisation effective existe, ni les conditions d’exécution dans lesquelles aucune notification n’apparaît.

flowchart TB
    V1["v1.0 est installé<br/>la règle pointe vers l'exe du dossier v1.0"] --> UP["Une mise à jour le place dans le dossier v1.1<br/>le chemin de l'exe qui s'exécute change"]
    UP --> MISS["La règle à l'ancien chemin perd sa cible<br/>(la règle reste mais n'a plus d'effet)"]
    MISS --> Q{"Les notifications entrantes<br/>sont-elles activées"}
    Q -- "Activées" --> DLG["La boîte de dialogue s'affiche à nouveau<br/>une règle de blocage si un utilisateur ordinaire répond"]
    Q -- "Désactivées" --> SILENT["Pas de boîte de dialogue non plus<br/>bloqué en silence"]
    MISS -.->|"Remède"| FIX["Garder le chemin fixe d'une mise à jour à l'autre<br/>ou supprimer et réenregistrer l'ancienne règle pendant la mise à jour"]

Le remède est soit de garder le chemin complet de l’exe fixe d’une mise à jour à l’autre, soit de changer la règle vers le nouveau chemin pendant l’étape de mise à jour. Avec l’approche de la section 5.3, vous pouvez mettre à jour la règle avec le même -Name vers le nouveau chemin. Si vous choisissez de supprimer l’ancienne règle et de l’enregistrer à nouveau, implémentez aussi le chemin de restauration en cas d’échec, afin de ne jamais laisser seulement une ancienne règle d’autorisation trop large.

Pour MSI, il existe des mécanismes qui traitent les règles de façon déclarative, comme l’extension pare-feu de WiX. Avant de lancer des commandes depuis une action personnalisée à vous, vérifiez quelles conditions l’outil que vous utilisez prend en charge et comment il gère les mises à jour et le retrait.¹³ Le raisonnement derrière chaque méthode de distribution est traité dans Choisir une méthode de distribution d’application Windows, et la détection antivirus dans Gérer les faux positifs de Microsoft Defender.

6. Dépannage — une démarche de diagnostic pour « ça ne communique pas »

Quand un signalement arrive, rassemblez d’abord la source et la destination, le nom ou l’adresse IP utilisés, TCP/UDP et le port, l’heure de l’échec, et l’erreur de l’application. L’exemple ci-dessous est un serveur de saisie de commandes qui utilise TCP. Ne mélangez pas les points que vous vérifiez sur le serveur et ceux que vous testez depuis le client réel.

TcpTestSucceeded=True dans le schéma signifie que la connexion TCP vers la destination testée a réussi. Cela ne garantit pas que l’authentification, le TLS et l’échange de données de l’application ont réussi, ni que le trafic sortant de l’application métier, qui est un autre exécutable, est autorisé.⁴

flowchart TB
    S["Impossible de communiquer depuis le client"] --> N["Sur le serveur : netstat -ano"]
    N -- "N'écoute pas" --> APP["Un problème en amont du pare-feu<br/>enquêter côté application ou service"]
    N -- "C'est LISTENING" --> T["Sur le client : Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["La joignabilité est bonne<br/>enquêter sur la couche application (authentification, protocole)"]
    T -- "False" --> P["Sur le serveur : Get-NetConnectionProfile<br/>vérifier le profil en vigueur"]
    P -- "Ne correspond pas à la portée de la règle" --> FIXP["Revoir le paramètre de profil de la règle"]
    P -- "Cela correspond" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>vérifier les règles d'autorisation et les règles de blocage égarées"]
    R --> LOGCHK["Mesurer les rejets (DROP) dans pfirewall.log"]

1. Pour l’état d’écoute, regardez l’adresse et le processus, pas seulement le port. Même avec LISTENING, s’il n’est lié qu’à 127.0.0.1 ou ::1, ce n’est pas une écoute à laquelle une autre machine peut se connecter telle quelle. Vérifiez s’il écoute sur l’adresse LAN en question, et si un autre processus utilise le même port. Faites correspondre le PID de netstat -ano avec le Gestionnaire des tâches ou un outil similaire, et avec les privilèges nécessaires netstat -abno révèle aussi l’exécutable. Vérifiez IPv4 et IPv6 séparément.³

2. Exécutez le test de connexion TCP depuis le client réel. Dans l’exemple ci-dessous, vérifiez RemoteAddress, SourceAddress, InterfaceAlias et TcpTestSucceeded.⁴

# Exécuter sur le client. Remplacer le nom et le port pour correspondre à l'environnement.
Test-NetConnection -ComputerName sv01 -Port 50051 -InformationLevel Detailed

Un False n’établit pas Windows Defender Firewall comme cause. La résolution de noms, la destination, la route, un VPN, les équipements réseau et les contrôles de trafic d’un autre produit sont aussi des candidats. À l’inverse, s’il est True, confirmez d’abord que la destination est le serveur que vous visiez, puis regardez les paramètres de destination de l’application métier, son authentification et son protocole. Un test avec une adresse IP sert à comparer la joignabilité TCP, mais il ne se comporte pas forcément comme une authentification fondée sur le nom ou une validation de certificat. Le paramètre -Port de cette cmdlet est un test TCP et ne sert pas à décider si l’UDP réussit ou échoue.⁴

3. Le profil et 4. les règles se vérifient d’après les paramètres qui s’appliquent réellement. Get-NetFirewallRule consulte par défaut le magasin persistant local. Pour voir la stratégie actuelle, y compris ce qui vient de la stratégie de groupe et analogues, indiquez -PolicyStore ActiveStore. Vérifiez non seulement que la règle existe, mais aussi les paramètres côté profil.⁵¹⁴

# Exécuter sur le serveur en tant qu'administrateur.
Get-NetConnectionProfile |
    Select-Object InterfaceAlias, InterfaceIndex, NetworkCategory

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
        AllowInboundRules, AllowLocalFirewallRules

$rules = @(Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Where-Object { $_.Enabled -eq "True" -and $_.Direction -eq "Inbound" })

$rules | Select-Object Name, DisplayName, Action, Profile,
    PolicyStoreSourceType, PolicyStoreSource

Dans une configuration où AllowInboundRules est désactivé, ajouter une règle d’autorisation ne suffit pas à autoriser le trafic entrant. Si les règles locales s’appliquent ou non se juge avec la stratégie gérée de la section 7. Pour des valeurs non configurées telles que NotConfigured, ne concluez pas autorisé ou non autorisé d’après cette chaîne seule ; confirmez les paramètres effectifs avec l’administrateur.¹⁵

Le programme, le port et l’adresse se trouvent sur les objets filtre associés à la règle. L’exemple ci-dessous affiche chacune des conditions de votre propre règle. Pour $rules, utilisez ce que la commande ci-dessus a récupéré.^5161718

$targetRules = @($rules | Where-Object { $_.Name -eq "MyCompany-OrderServer-In" })
$targetRules | Get-NetFirewallApplicationFilter | Select-Object Program
$targetRules | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort, RemotePort
$targetRules | Get-NetFirewallAddressFilter | Select-Object LocalAddress, RemoteAddress

# Examiner aussi les règles de blocage dont le nom diffère de celui de votre règle.
$rules | Where-Object { $_.Action -eq "Block" } |
    Select-Object Name, DisplayName, Profile, PolicyStoreSourceType, PolicyStoreSource

Pour les règles de blocage aussi, vérifiez les filtres des règles candidates de la même façon. Si un service est spécifié, regardez aussi cette condition, avec Get-NetFirewallServiceFilter et analogues. Une recherche en correspondance exacte telle que LocalPort -eq 50051 à elle seule rate les règles qui spécifient Any ou une plage de ports. Ne concluez pas « ça n’est pas apparu dans la recherche, donc il n’y a pas de règle conflictuelle ».¹⁷⁵

5. Pour le journal, activez l’enregistrement puis reproduisez le problème. Par défaut, le journal du pare-feu n’enregistre ni le trafic autorisé ni le trafic rejeté. L’emplacement par défaut est %windir%\system32\logfiles\firewall\pfirewall.log, et la taille maximale par défaut est 4 096 Ko. Commencez par vérifier les paramètres du profil en question et l’emplacement réel.⁶

# Sur le serveur. Lire seulement pour l'instant, sans modifier aucun paramètre.
Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, LogBlocked, LogAllowed, LogFileName, LogMaxSizeKilobytes

Si l’enregistrement des rejets est désactivé, obtenez l’accord de l’administrateur et activez-le pour le profil cible seulement, avec quelque chose comme Set-NetFirewallProfile -Profile Private -LogBlocked True. Private est ici un exemple. Enregistrez les paramètres tels qu’ils étaient, et restaurez les valeurs d’origine après l’enquête. Si les paramètres sont gérés de façon centralisée, faites-les changer par le côté gestion ; il n’est pas nécessaire de commencer par enregistrer le trafic autorisé en masse ni de changer tous les profils.⁹⁶

S’il y a un DROP qui correspond à l’heure de la reproduction, à l’IP source, à l’IP de destination, au protocole et au port, vous pouvez confirmer que le trafic a été rejeté. Toutefois, l’absence d’une telle ligne à elle seule n’établit pas que « le paquet n’est jamais arrivé ». Confirmez d’abord que les paramètres d’enregistrement s’appliquent, que vous ne regardez pas un autre emplacement, que le fichier est mis à jour, et qu’il n’y a pas de problème de droits d’écriture. Combinez cela avec une capture de paquets ou analogue si besoin. Lorsque le fichier journal n’est jamais créé, suivez aussi la procédure Microsoft pour vérifier le dossier et les droits de mpssvc.⁶

Pour aller plus loin, les événements d’audit 5152 et 5157 de Windows Filtering Platform sont des candidats. L’audit par paquet génère un très grand nombre d’événements, donc Microsoft oriente vers l’événement par connexion 5157 pour surveiller les connexions bloquées. Confirmez la stratégie d’audit et le volume d’enregistrements avec l’administrateur, et resserrez le périmètre et la période à ce qui est nécessaire.¹⁹

Ne faites pas de la désactivation du pare-feu votre premier pas de diagnostic ni votre correction permanente. Arrêter le service MpsSvc en particulier n’est pas pris en charge par Microsoft. Même lorsqu’un administrateur mène un test de comparaison dans un environnement de laboratoire isolé, laissez le service tourner, limitez le changement au profil en question, et rendez obligatoire la restauration des paramètres d’origine. Ce dont la production a besoin, c’est un paramètre corrigé pour correspondre à la cause, pas des défenses retirées en bloc.²

7. Points d’attention sous gestion centralisée — environnements où les règles locales n’ont aucun effet, et comment déposer une demande

Dans les environnements où le pare-feu est géré de façon centralisée par stratégie de groupe ou Intune, la fusion des règles locales peut être désactivée par profil. Dans ce cas, même si l’installateur peut créer une règle dans le magasin persistant local, elle n’est pas appliquée comme paramètre qui autorise le trafic. Une étape d’enregistrement réussie et le changement qui atteint la stratégie effective sont deux choses distinctes.¹

« Règles créées localement » dans le schéma désigne les règles locales ordinaires telles que celles créées dans le PersistentStore de la section 5. Elles sont traitées autrement que les règles configurées par stratégie de groupe locale. Il ne s’agit pas d’écrire dans un autre magasin pour contourner la restriction ; c’est une distinction qui existe pour que vous et l’administrateur chez le client vous accordiez sur une seule source de distribution.¹

flowchart TB
    GPOR["Règles distribuées par GPO ou Intune"] --> EFF["L'ensemble des règles réellement en vigueur<br/>(ActiveStore)"]
    LOCAL["Règles créées localement<br/>(y compris l'enregistrement par l'installateur)"] --> Q{"Fusion des règles locales<br/>(AllowLocalPolicyMerge)"}
    Q -- "Activée (défaut)" --> EFF
    Q -- "Désactivée" --> DROP["La règle existe mais n'est pas appliquée<br/>-> passer à une distribution centrale via GPO ou CSP"]

Dans un tel environnement, plutôt que de recréer des règles locales encore et encore, demandez au service informatique de distribuer la règle. L’installateur doit distinguer s’il gère la règle lui-même ou s’il suppose une distribution par le côté gestion, et être conçu pour ne pas changer la stratégie de gestion de son propre chef.

Une demande a besoin au minimum des informations suivantes. Veuillez ouvrir le TCP 50051 à elle seule ne tranche ni quelle machine, ni le trafic de qui, ni jusqu’où va l’autorisation.

Ne terminez pas les tests de déploiement avec des connexions depuis le poste de développement ou le serveur lui-même ; exécutez-les sur le lieu d’utilisation réel et avec les privilèges réels. S’il y a plusieurs routes, par exemple une via un VPN, vérifiez chaque route. Si l’authentification échoue après que la connexion TCP est passée, passez à une enquête distincte du pare-feu. Pour les sujets liés d’authentification et de protection du trafic, voir aussi Signature SMB et liaison de canal LDAP.

8. Résumé

La prise en charge de Windows Defender Firewall ne se limite pas à « l’approuver à l’avertissement » ou « ouvrir un port ». Le point de départ est d’inventorier les sens du trafic de l’application, de concevoir ensemble le programme, le port, la source distante et le profil, et de placer les paramètres requis avant le premier lancement.¹¹⁰

Si la gestion locale est permise, faites de l’enregistrement, de la mise à jour et de la suppression de la règle une responsabilité de l’installateur. Si les machines sont gérées par stratégie de groupe ou Intune, remettez la même spécification de communication à l’administrateur et faites-la distribuer. Faites de la condition d’un déploiement terminé non pas qu’une règle a pu être créée, mais que les pairs visés peuvent communiquer avec l’application réelle et qu’aucune plage inutile n’est autorisée.

Quand le trafic échoue, vérifiez dans l’ordre l’adresse d’écoute et l’entité qui s’exécute, la connexion TCP, le profil, la stratégie effective et le journal des rejets. Plutôt que de sauter à « ça ne se connecte pas, donc c’est le pare-feu » ou « il n’y a pas de journal, donc ça n’est jamais arrivé », séparer ce que chaque résultat vous a dit de ce que vous ne savez pas encore rend le prochain endroit à regarder clair.

Articles connexes

• Comment choisir la communication inter-processus sous Windows ── Tableau de décision : tubes nommés / TCP / gRPC / mémoire partagée / COM
• Choisir une méthode de distribution d’application Windows - MSI/MSIX/ClickOnce/xcopy/Updater personnalisé
• Quand Windows exige-t-il réellement des privilèges administrateur - UAC, zones protégées et comment le déterminer par conception
• Quand votre application Windows maison est signalée comme un virus — gérer les faux positifs de Microsoft Defender et composer avec l’impact sur les performances
• Signature SMB et liaison de canal LDAP ── boucler « l’autre moitié » des contre-mesures NTLM en pratique
• Comment créer et exploiter un service Windows ── du choix entre Planificateur de tâches et service à la transformation d’un BackgroundService en service Windows

Domaines de conseil associés

Outre le développement d’applications métier Windows, KomuraSoft LLC prend en charge la conception d’installateurs qui incluent des règles de pare-feu, l’investigation des causes d’échecs de connexion chez les clients, et le conseil technique en vue de déploiements sous gestion centralisée. Lorsque vous nous contactez, disposer de la source et de la destination, du mode de communication, des étapes de reproduction, et des erreurs ou journaux permet de concrétiser le périmètre de l’enquête.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Une application qui ne fait que se connecter à un serveur en tant que client a-t-elle aussi besoin d'une règle de pare-feu ?

Dans un environnement où le trafic sortant est autorisé par défaut, une application qui n'initie que des connexions et en reçoit les réponses n'a normalement pas besoin d'une règle entrante qui lui soit propre. Cela change si une stratégie d'organisation restreint le sortant ou si une règle de blocage explicite existe. De plus, même une application dite cliente a besoin que le trafic entrant soit autorisé pour toute partie qui écoute des rappels ou des notifications depuis une autre machine. Décidez d'après le sens réel du trafic, pas d'après le nom de l'application.

Ne suffit-il pas d'appuyer sur Autoriser l'accès dans la boîte de dialogue Alerte de sécurité Windows ?

Il est plus sûr de ne pas faire dépendre la procédure de mise en production de cette seule action. Microsoft documente qu'une règle de blocage est créée lorsque l'administrateur qui voit la notification l'annule, ou lorsqu'un utilisateur qui n'est pas administrateur y répond. Ajouter ensuite une règle d'autorisation ne fait pas passer le trafic tant qu'une règle de blocage conflictuelle existe. Placez les règles requises avant le premier lancement, depuis l'installateur ou par l'administrateur de l'organisation.

Une règle entrante doit-elle être construite autour du port ou du programme ?

Pour une application interne qui écoute sur un port fixe, la base est de combiner le chemin complet du programme avec le protocole et le port local, et de resserrer l'IP distante et le profil à la plage réellement nécessaire. Des ajustements sont nécessaires selon la configuration, par exemple ports dynamiques ou exécution en tant que service. Avec une règle par programme, faites en sorte que le processus de mise à jour tienne compte des changements de chemin de l'exécutable, et évitez de créer à la légère une large règle d'autorisation par port seul.

La règle que notre installateur a enregistrée ne semble pas prendre effet sur le PC du client. Pourquoi ?

Un enregistrement de règle réussi ne dit pas à lui seul que le trafic est autorisé. Vérifiez l'adresse d'écoute, le chemin de l'exécutable, le profil, l'IP distante et toute règle de blocage conflictuelle. De plus, si la fusion des règles locales est désactivée par stratégie de groupe ou Intune, la règle créée par l'installateur n'est pas appliquée. Dans ce cas, ne contournez pas la stratégie gérée ; passez à une distribution de la règle par le service informatique.

Est-il acceptable de désactiver temporairement le pare-feu pour trier un problème de communication ?

Enquêtez d'abord par l'état d'écoute, la stratégie effective et le journal des rejets. Ne faites pas de la désactivation de tout le pare-feu une réponse de routine, et évitez en particulier d'arrêter le service MpsSvc, que Microsoft ne prend pas en charge. Même lorsqu'un administrateur doit le désactiver temporairement dans un environnement de test isolé, laissez le service tourner, limitez le changement au profil concerné, enregistrez les paramètres tels qu'ils étaient, et restaurez-les immédiatement.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.