Le pare-feu Windows et les applications métier — enregistrer les règles entrantes depuis l'installateur

« Ça fonctionne sans problème sur le poste de développement, mais une fois installé chez le client, impossible de se connecter du client au serveur. » « Un avertissement est apparu au premier lancement, et il semble que la personne sur place l’ait annulé. » « netstat montre que le port écoute, mais ça ne passe pas depuis le PC d’à côté. » — sur le terrain du déploiement d’applications métier, ce genre de remontée « impossible de communiquer » est le grand classique des grands classiques. Et le suspect numéro un, année après année, c’est le pare-feu Windows (Windows Defender Firewall).

Ce qui rend la chose délicate, c’est que le problème est invisible sur le poste de développement. Sur ce poste, on a soit cliqué soi-même sur « autoriser » pendant l’exécution en débogage sous Visual Studio, soit on est tout simplement administrateur, si bien qu’on livre sans jamais remarquer le blocage entrant par défaut. Chez le client, en revanche, c’est un utilisateur ordinaire sans droits d’administrateur qui manipule le poste, et le réseau est géré par GPO. Ce n’est pas que « quelque chose qui devrait fonctionner ne fonctionne pas » — la réalité, c’est que « le poste de développement fonctionnait par hasard ».

Cet article s’adresse aux développeurs d’applications métier qui se heurtent à « impossible de communiquer chez le client » avec leurs propres applications, et aux responsables informatiques des PME qui reçoivent ces remontées. Après avoir posé le minimum à connaître sur le comportement par défaut du pare-feu Windows et son mécanisme de profils, il fait le tour de la conception des règles entrantes, de la pratique de leur enregistrement depuis l’installateur, des procédures de diagnostic, et des points de vigilance sous gestion GPO/Intune, le tout fondé sur des sources primaires à la date d’août 2026.

1. La conclusion, d’abord

• Le pare-feu Windows bloque par défaut les connexions entrantes et autorise les sortantes. Le trafic entrant qui n’est pas une réponse à une requête est rejeté, sauf s’il correspond à une règle.¹
• Une règle entrante n’est nécessaire que pour les applications de type serveur qui écoutent un port. Une application cliente qui ne fait qu’initier des connexions communique avec les paramètres par défaut. Commencez le diagnostic par cette distinction.¹
• Il existe trois profils (Domaine/Privé/Public). Le profil Domaine s’applique automatiquement à la détection d’un contrôleur de domaine, le profil Public est celui par défaut pour un réseau non identifié. L’activation ou la désactivation des règles se décide profil par profil.¹
• Ne confiez pas la production à cette boîte de dialogue « avertissement important ». Si un administrateur l’annule, une règle de blocage est créée ; pour un utilisateur sans droits d’administrateur, une règle de blocage est créée quel que soit le bouton pressé. La boîte de dialogue ne réapparaît pas tant que la règle créée n’est pas supprimée.²
• La conclusion tient en une phrase : « enregistrer les règles entrantes d’une application métier depuis l’installateur ». Microsoft recommande lui-même de mettre en place la règle avant le premier lancement et de désactiver la notification entrante.²
• Concevez les règles selon le principe du moindre privilège. Construisez-les autour de programme + protocole + port, limitez le profil au domaine/privé, et restreignez l’IP distante au sous-réseau nécessaire. Les caractères génériques ne sont pas utilisables dans un chemin de programme.²³
• Le diagnostic se fait dans l’ordre Test-NetConnection → Get-NetFirewallRule → pfirewall.log. Le journal du pare-feu n’est pas écrit par défaut ; il ne se remplit qu’après avoir activé la journalisation des paquets rejetés.⁴⁵⁶
• La désactivation globale par arrêt du service n’est pas prise en charge. Sous gestion GPO/Intune, la « fusion des règles locales » peut être désactivée, auquel cas les règles locales n’ont aucun effet. Demandez à l’informatique une distribution centralisée des règles.¹²

2. Le comportement par défaut, avec précision — entrant bloqué, sortant autorisé

Commençons par poser précisément les bases. Le pare-feu Windows est un pare-feu hôte activé par défaut sur toutes les éditions, et son comportement par défaut tient en deux lignes.¹

• Entrant (inbound) : tout est bloqué, sauf s’il s’agit d’une réponse à une requête (solicited) ou si le trafic correspond à une règle
• Sortant (outbound) : tout est autorisé, sauf s’il correspond à une règle

Ces deux lignes conduisent à la distinction la plus importante pour une application métier : une règle entrante n’est nécessaire que pour le côté « qui écoute ».

• Une application cliente qui se connecte seulement, de son côté, à un serveur web interne, un serveur de base de données ou un système central → en principe, aucune règle n’est nécessaire. Les paquets de retour de la connexion sont une « réponse à une requête » et passent donc par défaut.
• Une application de type serveur ou un service Windows qui ouvre un port et attend des connexions, en TCP, gRPC ou un protocole propriétaire → une règle entrante est indispensable.
• Notez que l’usage distant des tuyaux nommés (named pipes) fait exception : un tuyau nommé distant transite non pas par un port propre à l’application, mais par SMB (TCP 445), si bien que ce n’est pas une règle pour l’application qui est nécessaire, mais une règle côté partage de fichiers (SMB).
• L’exception concerne les environnements à haute sécurité où le sortant par défaut a été explicitement basculé en blocage. Cette configuration ne concerne qu’une minorité d’organisations, mais dans ce cas, une demande de règle sortante est nécessaire même pour l’application cliente.²

flowchart TB
    APP["Recenser les communications de l'application"] --> Q{"Ouvre-t-elle un port pour<br/>attendre des connexions ?"}
    Q -- "N'attend pas<br/>(se connecte seulement comme client)" --> C1["Règle entrante en principe inutile<br/>Le retour de connexion passe comme « réponse »"]
    Q -- "Attend<br/>(type serveur, réception de rappel)" --> S1["Règle entrante indispensable<br/>→ enregistrer depuis l'installateur (chapitre 5)"]
    C1 -.-> EX["Exception : environnement à haute sécurité avec<br/>sortant bloqué par défaut → demander une règle sortante"]

Le cas où « une application censée n’être que cliente écoute en réalité aussi » (réception de rappel de résultat, point de réception de notifications d’autres processus, etc.) est facile à manquer. Si vous n’êtes pas sûr du mode de communication par lequel votre application écoute, consultez aussi « Comment choisir la communication interprocessus sous Windows » pour clarifier ce point dès la conception.

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

Les règles s’appliquent par profil réseau. Il existe trois profils.¹

Le profil actuellement appliqué se vérifie avec Get-NetConnectionProfile, et le basculement entre privé et public se fait avec Set-NetConnectionProfile.¹ Un incident fréquent sur le terrain est celui où le réseau d’un client en environnement workgroup est classé « public », si bien qu’une règle entrante construite pour le domaine/privé uniquement ne s’applique pas. Quand « la règle existe mais ça ne passe pas », suspectez d’abord la correspondance de profil, avant même le contenu de la règle.

2.2. L’ordre de priorité des règles

Lorsque plusieurs règles existent, leur évaluation ne suit pas une liste ordonnée pondérée, mais les principes cohérents suivants.²

1. Une règle d’autorisation explicite l’emporte sur le blocage par défaut
2. Une règle de blocage explicite l’emporte sur une règle d’autorisation en conflit
3. Dans la limite du point 2, la règle la plus spécifique l’emporte

L’implication pratique, c’est que dès qu’une seule règle de blocage existe quelque part, aucun nombre de règles d’autorisation ajoutées ensuite ne peut l’emporter. Comme on le verra au chapitre suivant, c’est précisément ce type de règle de blocage que la fameuse boîte de dialogue crée silencieusement.

3. La vraie nature de la boîte de dialogue « avertissement important » — pourquoi on ne peut pas s’y fier

Lorsqu’une application commence pour la première fois à écouter (listen) un port, si aucune règle d’autorisation ni règle définie par un administrateur n’existe pour cette application, Windows affiche la fameuse boîte de dialogue « Alerte de sécurité Windows », indiquant que certaines fonctionnalités de l’application sont bloquées par le pare-feu Windows Defender. Le comportement est clairement spécifié.²

• Affichée à un utilisateur disposant des droits d’administrateur : cliquer sur « Autoriser l’accès » crée une règle d’autorisation. Mais cliquer sur « Annuler » crée une règle de blocage, en général deux règles, une pour TCP et une pour UDP.
• Affichée à un utilisateur sans droits d’administrateur : quel que soit le choix, une règle de blocage est créée.
• Dans les deux cas, la boîte de dialogue ne réapparaît plus tant que la règle créée n’est pas supprimée, et la communication reste bloquée.

flowchart TB
    L["L'application commence à écouter un port"] --> Q1{"Une règle correspondant<br/>à cette application existe-t-elle ?"}
    Q1 -- "Oui" --> R1["La règle s'applique<br/>(pas de boîte de dialogue)"]
    Q1 -- "Non" --> Q2{"La notification entrante<br/>est-elle activée ?"}
    Q2 -- "Désactivée" --> R2["Blocage silencieux<br/>(aucune règle créée)"]
    Q2 -- "Activée" --> DLG["Boîte de dialogue « avertissement important »"]
    DLG -- "Administrateur clique « Autoriser l'accès »" --> OK["Une règle d'autorisation est créée"]
    DLG -- "Administrateur clique « Annuler »" --> NG1["Une règle de blocage est créée"]
    DLG -- "Utilisateur sans droits d'administrateur<br/>(quelle que soit l'action)" --> NG2["Une règle de blocage est créée"]
    NG1 --> NEVER["La boîte de dialogue ne réapparaît plus<br/>tant que la règle n'est pas supprimée"]
    NG2 --> NEVER

Autrement dit, cette boîte de dialogue a beau ressembler à un « mécanisme demandant l’autorisation de l’utilisateur », sur le terrain d’une application métier, elle fonctionne comme un « mécanisme qui grave une règle de blocage dès qu’un utilisateur ordinaire y touche ». Si la personne chargée du déploiement lance l’application pour la première fois avec un compte administrateur et autorise via la boîte de dialogue, la règle d’autorisation créée s’applique à tout le PC, et les utilisateurs ordinaires pourront donc communiquer dès le lendemain. Des incidents subsistent malgré tout — lorsqu’un utilisateur ordinaire déclenche pour la première fois un point d’écoute qui n’avait pas été sollicité lors de la vérification au déploiement, lorsque le profil réseau appliqué diffère de celui du déploiement, et lorsqu’une mise à jour change le chemin de l’exe (chapitres 4 et 5).

Microsoft énonce lui-même les bonnes pratiques suivantes pour les appareils utilisés par des personnes autres que l’administrateur.²

1. Mettre en place les règles nécessaires avant le premier lancement de l’application (via l’installateur ou une distribution administrative)
2. Désactiver la notification entrante (couper la notification supprime purement et simplement la création automatique de règle à l’exécution)

La désactivation de la notification se configure avec Set-NetFirewallProfile -NotifyOnListen False, ou via une stratégie de groupe.⁷ « Si la boîte de dialogue apparaît, demander à la personne sur place de cliquer sur autoriser » n’est pas une procédure d’exploitation : c’est réserver un incident à l’avance. Enregistrer la règle entrante au moment de l’installation — c’est la conclusion de cet article, et elle coïncide avec la recommandation de Microsoft.

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

Passons à la conception du contenu des règles à enregistrer. Il existe globalement trois grandes méthodes de désignation, à utiliser seules ou combinées selon le cas.

Au-delà de cela, il faut superposer des restrictions de portée. La recommandation de conception de Microsoft est elle aussi « rendre les règles entrantes aussi spécifiques que possible ».²

• Limitation du profil : pour une application métier utilisée uniquement en interne, limitez la règle entrante au domaine/privé et ne l’activez pas pour le public. Cela évite l’incident où un port d’écoute s’ouvre au monde entier dès qu’un portable se connecte à un Wi-Fi extérieur.
• Limitation de l’IP distante : si l’origine des connexions est connue, restreignez -RemoteAddress à ce sous-réseau. Pour les réseaux domestiques ou de petite taille, la restriction via le mot-clé LocalSubnet est recommandée.²³
• Direction et nombre de règles : si l’écoute se fait uniquement en TCP, une seule règle TCP suffit. Ne créez pas par habitude des règles TCP et UDP, comme le fait automatiquement la boîte de dialogue.

« Du bon correspondant, vers le bon port, pour le seul bon programme » — la conception d’une règle entrante se résume à cette phrase de moindre privilège.

5. La pratique de l’enregistrement depuis l’installateur — netsh et New-NetFirewallRule

5.1. Prérequis : des droits d’administrateur sont nécessaires

L’ajout ou la suppression d’une règle de pare-feu est un changement de configuration à l’échelle de tout l’ordinateur, ce qui nécessite de l’exécuter avec des droits d’administrateur (processus élevé).⁸ Comme un installateur s’exécute normalement avec des droits d’administrateur, il est logique de placer l’enregistrement de la règle dans le processus d’installation. Cela ne constitue pas une raison de faire tourner l’application elle-même en administrateur. Cette délimitation est détaillée dans « Quand les droits d’administrateur sont-ils nécessaires sous Windows ? ».

5.2. Enregistrement avec netsh advfirewall

Une méthode classique, mais facile à appeler depuis n’importe quel installateur, est netsh advfirewall firewall add rule.⁸

rem add rule ajoute toujours une nouvelle entrée même si une règle du même nom existe déjà ;
rem en prévision d'une réexécution lors d'une réinstallation, réparation ou mise à jour,
rem on supprime d'abord la règle homonyme avant de la recréer
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

rem Règle d'autorisation entrante par programme + port + profil limité
netsh advfirewall firewall add rule name="MyCompany OrderServer" dir=in action=allow program="C:\Program Files\MyCompany\OrderServer\OrderServer.exe" protocol=TCP localport=50051 profile=domain enable=yes

rem Lors de la désinstallation : suppression par nom
netsh advfirewall firewall delete rule name="MyCompany OrderServer"

add rule n’écrase pas une règle homonyme existante : il en ajoute une nouvelle sous le même nom. Sans exécuter delete rule au préalable, les règles se multiplient à chaque nouvelle exécution, et une ancienne règle d’autorisation subsiste même après une mise à jour ayant changé le chemin ou la portée (au premier lancement, le delete rule initial signale qu’aucune règle correspondante n’existe, mais l’exécution du script continue, si bien que cet enchaînement ne pose pas de problème ; si votre installateur évalue le succès via le code de sortie, basez-vous sur le résultat du add rule final). Vous pouvez aussi restreindre l’origine de connexion, par exemple avec remoteip=157.60.0.1,172.16.0.0/16,LocalSubnet.⁸ La suppression efface d’un coup toutes les règles correspondant au nom : il est donc plus sûr de rendre le nom de la règle unique, préfixé par le nom de votre société.

5.3. Enregistrement avec PowerShell (New-NetFirewallRule)

Pour un contrôle plus fin, utilisez le module NetSecurity. -DisplayName est obligatoire, et -Profile accepte plusieurs valeurs séparées par des virgules (sans espace).³

# Enregistrement (exécuté depuis l'installateur en mode élevé). -Name étant un identifiant
# unique, une réexécution lors d'une réinstallation, réparation ou mise à jour provoquerait
# une erreur de création de règle homonyme. On rend l'opération idempotente en supprimant
# d'abord la règle existante avant de la recréer
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue
New-NetFirewallRule -Name "MyCompany-OrderServer-In" `
    -DisplayName "MyCompany OrderServer (TCP 50051 entrant)" `
    -Direction Inbound -Action Allow `
    -Program "C:\Program Files\MyCompany\OrderServer\OrderServer.exe" `
    -Protocol TCP -LocalPort 50051 `
    -Profile Domain,Private -RemoteAddress LocalSubnet

# Lors de la désinstallation : ne pas générer d'erreur si la règle n'existe pas
Remove-NetFirewallRule -Name "MyCompany-OrderServer-In" -ErrorAction SilentlyContinue

Spécifier explicitement -Name ici a une raison précise. -Name est l’identifiant unique de la règle ; l’omettre lui attribue une valeur aléatoire. Le nom d’affichage (-DisplayName) pouvant varier selon la langue, Microsoft indique qu’il faut utiliser -Name comme clé pour identifier une règle depuis un script.³ Fixer -Name doit être considéré comme indispensable, ne serait-ce que pour garantir que le désinstalleur supprime exactement — et seulement — ses propres règles.

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

Une règle par programme fixe sa cible via un chemin complet. Autrement dit, si une mise à jour change le dossier d’installation ou le nom de l’exe, la règle subsiste mais perd sa cible, et l’écoute est de nouveau bloquée. L’exe au nouveau chemin est alors traité comme « une application sans règle » : dans un environnement où la notification est activée, la boîte de dialogue du chapitre 3 réapparaît, et si un utilisateur ordinaire la manipule, une règle de blocage se grave. Dans un environnement où la notification est désactivée comme recommandé au chapitre 3, l’échec est silencieux, sans même de boîte de dialogue. Cet incident est particulièrement fréquent avec un déploiement dans un dossier portant un numéro de version, ou avec un mécanisme d’auto-mise à jour dont l’emplacement de déploiement se déplace.

flowchart TB
    V1["Déploiement de la v1.0<br/>La règle pointe vers l'exe du dossier v1.0"] --> UP["Mise à jour déployée dans le dossier v1.1<br/>Le chemin de l'exe exécuté change"]
    UP --> MISS["La règle à l'ancien chemin perd sa cible<br/>(elle existe mais ne s'applique plus)"]
    MISS --> Q{"La notification entrante<br/>est-elle activée ?"}
    Q -- "Activée" --> DLG["La boîte de dialogue réapparaît<br/>Un utilisateur ordinaire qui la manipule crée une règle de blocage"]
    Q -- "Désactivée" --> SILENT["Blocage silencieux,<br/>sans même de boîte de dialogue"]
    MISS -.->|"Contre-mesure"| FIX["Fixer le chemin à travers les mises à jour,<br/>ou faire supprimer et recréer la règle par la mise à jour"]

La contre-mesure est simple : l’une des deux options suivantes.

• Fixer le dossier d’installation, de façon à ce que le chemin complet de l’exe ne change pas d’une mise à jour à l’autre
• Pour une mise à jour qui change le chemin, faire en sorte que le programme de mise à jour supprime l’ancienne règle et la réenregistre au nouveau chemin (exécuter les commandes de 5.2/5.3 aussi dans le processus de mise à jour)

Pour un MSI, l’usage classique consiste à intégrer l’enregistrement de la règle comme action personnalisée exécutée après le déploiement des fichiers (et l’action personnalisée de suppression côté désinstallation). Des jeux d’outils comme WiX proposent aussi des extensions pour décrire les règles de pare-feu de façon déclarative. L’emplacement de l’implémentation dépend du mode de distribution choisi ; consultez aussi « Comment choisir le mode de distribution d’une application Windows ». Par ailleurs, l’autre incident classique lors d’un déploiement chez un client, les faux positifs antivirus, est traité dans « Gérer les faux positifs de Microsoft Defender ».

6. Diagnostic — le déroulement du triage « impossible de communiquer »

Fixons à l’avance, dans l’ordre, la procédure à suivre lorsqu’une remontée arrive. Voici le déroulement d’ensemble.

flowchart TB
    S["« Impossible de communiquer depuis le client »"] --> N["Côté serveur : netstat -ano"]
    N -- "N'écoute pas" --> APP["Problème antérieur au pare-feu<br/>Enquêter côté application/service"]
    N -- "État LISTENING" --> T["Côté client : Test-NetConnection"]
    T -- "TcpTestSucceeded=True" --> OTHER["Accessibilité réseau normale<br/>Enquêter côté couche applicative (authentification, protocole)"]
    T -- "False" --> P["Côté serveur : Get-NetConnectionProfile<br/>Vérifier le profil actuellement appliqué"]
    P -- "Ne correspond pas à la cible de la règle" --> FIXP["Revoir la spécification de profil de la règle"]
    P -- "Correspond" --> R["Get-NetFirewallRule -PolicyStore ActiveStore<br/>Vérifier la présence de règles d'autorisation et l'éventuelle présence de règles de blocage"]
    R --> LOGCHK["Constater les rejets (DROP) dans pfirewall.log"]

Précision sur l’étape 4 : les conditions de port ou de programme se trouvent non pas dans la règle elle-même, mais dans un objet filtre associé ; pour retrouver une règle à partir d’un port, il faut donc interroger via ce filtre.⁵⁷

# Retrouver les règles liées au port 50051
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 50051 } | Get-NetFirewallRule

# Tracer l'origine des règles (locale ou GPO)
Get-NetFirewallRule -PolicyStore ActiveStore -TracePolicyStore |
    Select-Object Name, DisplayName, PolicyStoreSourceType, PolicyStoreSource

Le journal du pare-feu (pfirewall.log) mentionné à l’étape 5 n’enregistre rien du tout par défaut. Son chemin par défaut est %windir%\system32\logfiles\firewall\pfirewall.log, sa taille maximale par défaut est de 4 096 Ko, et il ne commence à être écrit qu’après avoir activé « journaliser les paquets rejetés » ou « journaliser les connexions réussies ».⁶ Sur une machine isolée, on peut l’activer ainsi.⁶

netsh advfirewall set allprofiles logging droppedconnections enable
netsh advfirewall set allprofiles logging allowedconnections enable

Le journal est un fichier texte où chaque ligne enregistre s’il s’agit d’un rejet (DROP) ou d’une autorisation (ALLOW), le protocole, ainsi que l’IP et le port source/destination : cela permet de trancher définitivement entre « le SYN du client arrive et est rejeté » et « il n’arrive tout simplement pas ». Notez que, dans un environnement où la journalisation est configurée par stratégie, il arrive que le fichier ne soit pas créé faute de droits d’écriture suffisants sur le dossier de journalisation (contrôle total requis pour le service mpssvc) ; il faut alors créer le dossier et lui attribuer les ACL nécessaires.⁶

Pour aller plus loin, activer la stratégie d’audit « Rejet de paquet de la plateforme de filtrage » enregistre l’événement de sécurité 5152 à chaque rejet. Le volume d’événements étant toutefois très important, Microsoft recommande plutôt l’événement 5157 (Connexion à la plateforme de filtrage), qui est enregistré par connexion. C’est un outil à activer seulement le temps d’un diagnostic, pas en usage permanent.⁹

Pour finir, précisons clairement ce qu’il ne faut pas faire pour diagnostiquer : la désactivation complète du pare-feu par arrêt du service (MpsSvc) n’est pas prise en charge, et provoque des problèmes côté OS tels que le menu Démarrer qui ne fonctionne plus ou les mises à jour des applications du Store qui échouent. Si vous devez vraiment le désactiver pour vérifier, désactivez le profil avec Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False en laissant le service actif, puis rétablissez-le immédiatement après vérification.¹⁷ Et une fois la cause confirmée comme étant le pare-feu, la solution n’est pas de rendre la désactivation permanente, mais d’ajouter la bonne règle.

7. Points de vigilance sous gestion organisationnelle — environnements où les règles locales n’ont pas d’effet, et la bonne façon de faire une demande

Même si l’installateur enregistre la règle, il existe des environnements où elle n’a pas d’effet. Dans les organisations qui gèrent le pare-feu de façon centralisée par GPO ou Intune (CSP), la « fusion des règles locales » (AllowLocalPolicyMerge) peut être désactivée par profil. Quand ce paramètre est désactivé, les règles créées par un administrateur local (y compris l’installateur) ne s’appliquent pas, et la règle d’une application nécessitant des connexions entrantes doit obligatoirement être distribuée de façon centralisée via GPO/CSP.²

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

Voici les précautions réalistes à prendre côté développement et déploiement.

• Concevoir l’enregistrement de la règle par l’installateur pour qu’il « ne puisse pas échouer » (l’enregistrement lui-même réussit toujours, donc une erreur ne permet pas de détecter le problème ; incluez une vérification de connectivité après le déploiement dans la procédure)
• Utiliser l’étape 4 du chapitre 6 (-TracePolicyStore) pour vérifier si l’origine des règles effectives est locale ou issue d’un GPO⁵
• Dès qu’on constate que les règles locales n’ont pas d’effet dans un environnement donné, basculer vers une demande de distribution des règles au service informatique

La demande doit fournir l’ensemble des informations suivantes. Comme une règle de pare-feu ne peut être créée qu’une fois réunis la direction, le programme, le port et la portée, ce tableau devient de facto la « fiche des spécifications réseau de l’application métier ».

Du point de vue de l’informatique aussi, la charge de travail diffère radicalement selon qu’une demande contient ce tableau ou non. À l’inverse, une demande du type « ouvrez-moi ce numéro de port », sans plus de précision, tend, comme on l’a vu au chapitre 4, à devenir une autorisation excessive. Notez par ailleurs que les exigences de communication autour du partage de fichiers et de l’authentification en environnement de domaine évoluent aussi via un durcissement distinct du pare-feu (rendre la signature obligatoire, par exemple). Consultez également « Signature SMB et liaison de canal LDAP ».

8. Conclusion

• Le pare-feu Windows bloque par défaut l’entrant et autorise le sortant. Une règle entrante n’est nécessaire que pour les applications de type serveur qui écoutent ; pour une simple connexion en tant que client, elle est en principe inutile.
• Les règles s’appliquent par profil (domaine/privé/public). Le premier suspect en cas de « la règle existe mais ça ne passe pas » est un décalage de profil.
• La boîte de dialogue « avertissement important » crée une règle de blocage lorsqu’elle est annulée ou manipulée par un utilisateur sans droits, et ne réapparaît plus ensuite. Ne confiez pas la production à cette boîte de dialogue.
• Enregistrer les règles entrantes d’une application métier depuis l’installateur — c’est le seul principe à retenir. Implémentez cela avec des droits d’administrateur, en fixant -Name jusque dans la suppression.
• Construisez les règles autour de programme + protocole + port, en les restreignant par profil et par IP distante. Si une mise à jour change le chemin de l’exe, n’oubliez pas de réenregistrer la règle.
• Menez le diagnostic mécaniquement dans l’ordre netstat → Test-NetConnection → vérification du profil → Get-NetFirewallRule (ActiveStore) → pfirewall.log. La désactivation par arrêt du service n’est pas prise en charge.
• Sous gestion GPO/Intune, la fusion des règles locales peut être désactivée. Dans ce cas, demandez à l’informatique une distribution en fournissant ensemble le nom de la règle, la direction, le programme, le port, l’IP distante et le profil.

Articles connexes

• Comment choisir la communication interprocessus sous Windows — tableau de décision tuyaux nommés / TCP / gRPC / mémoire partagée / COM
• Comment choisir le mode de distribution d’une application Windows — MSI/MSIX/ClickOnce/xcopy/mise à jour propriétaire
• Quand les droits d’administrateur sont-ils nécessaires sous Windows ? — UAC, zones protégées, comment le déterminer en conception
• Que faire quand votre application Windows maison est prise pour un virus — gérer les faux positifs de Microsoft Defender et composer avec leur impact sur les performances
• Signature SMB et liaison de canal LDAP — boucler en pratique la « seconde moitié » de la défense contre NTLM
• Créer et exploiter un service Windows — du choix face au Planificateur de tâches jusqu’à transformer un BackgroundService en service

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge la conception d’installateurs pour des applications métier de type serveur (y compris l’enregistrement et la suppression des règles de pare-feu), l’investigation des causes d’« impossible de communiquer » chez le client, et la clarification des exigences réseau en vue d’un déploiement sous gestion GPO. N’hésitez pas à nous consulter dès le stade du diagnostic de « ça fonctionne sur le poste de développement mais pas chez le client ».

• 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 besoin d'une règle de pare-feu ?

En principe non. Le pare-feu Windows bloque par défaut les connexions entrantes et autorise les sortantes, si bien qu'une application cliente qui ne fait qu'initier des connexions communique normalement avec les paramètres par défaut. Une règle entrante n'est nécessaire que pour le côté qui ouvre un port et attend des connexions, c'est-à-dire les applications de type serveur. Il existe toutefois deux exceptions. Dans les environnements à haute sécurité, le sortant peut lui aussi avoir été basculé en blocage par défaut, auquel cas une demande de règle sortante est nécessaire. Par ailleurs, même une application cliente a besoin d'une règle entrante pour toute partie conçue pour écouter elle-même un port, par exemple comme point de réception des notifications de résultat.

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

Cela règle le problème sur le moment, mais on ne peut pas confier la production à cette boîte de dialogue. Si un utilisateur disposant des droits d'administrateur l'annule, une règle de blocage est créée. Pire, pour un utilisateur sans droits d'administrateur, une règle de blocage est créée quel que soit le bouton pressé. Une fois la règle créée, la boîte de dialogue ne réapparaît plus tant que cette règle n'est pas supprimée, et la communication continue d'échouer. Dans les applications métier où c'est un utilisateur ordinaire qui manipule le PC sur le terrain, il est très facile d'arriver à un état où « quelqu'un a annulé une fois, et depuis on ne peut plus jamais communiquer ». Microsoft recommande d'ailleurs de mettre en place la règle avant le premier lancement de l'application, précisément pour éviter cela.

Une règle entrante doit-elle être construite par désignation du port ou du programme ?

La base consiste à les combiner plutôt qu'à en utiliser un seul. La désignation par programme permet de cibler précisément via le chemin complet de l'exe, mais si une mise à jour change ce chemin, la règle perd sa cible (les caractères génériques ne sont pas pris en charge). La désignation par port rend la demande auprès de l'informatique plus claire, mais elle laisse aussi passer tout autre processus qui viendrait écouter sur le même port. Pour une application métier en production, le schéma de moindre privilège consiste à construire la règle autour de « programme + protocole + port », à limiter le profil au domaine/privé, et à restreindre l'IP distante au sous-réseau où se trouve le client. N'utilisez la désignation par programme seule que lorsque le port est dynamique.

La règle que mon installateur a enregistrée ne semble pas s'appliquer sur le PC du client. Pourquoi ?

Il est probable que le pare-feu du client soit géré de façon centralisée par GPO ou Intune, avec la « fusion des règles locales » (AllowLocalPolicyMerge) désactivée. Quand ce paramètre est désactivé, une règle créée localement existe bien dans le profil mais n'est pas appliquée : les règles ne peuvent alors être distribuées que de façon centralisée via GPO/CSP. Vérifiez l'ensemble des règles effectivement actives avec Get-NetFirewallRule -PolicyStore ActiveStore, puis demandez au service informatique de distribuer la règle. La demande passe en une seule fois si vous fournissez ensemble le nom de la règle, la direction, le chemin du programme, le protocole et le port, la plage d'IP distantes, et le profil.

Peut-on désactiver temporairement le pare-feu pour un diagnostic de communication ?

Évitez absolument de le désactiver en arrêtant le service (MpsSvc). C'est une opération non prise en charge par Microsoft, qui provoque des problèmes côté OS tels que le menu Démarrer qui cesse de fonctionner ou les mises à jour des applications du Store qui échouent. Si vous devez vraiment le désactiver pour un diagnostic, la méthode correcte consiste à laisser le service actif et à désactiver le profil avec Set-NetFirewallProfile -Enabled False. Même ainsi, limitez cela à quelques minutes pour vérifier si le pare-feu est bien la cause, et rétablissez-le immédiatement une fois la vérification faite. Laisser le pare-feu désactivé en permanence, c'est échanger la protection de tout le PC contre un problème qu'une seule règle ajoutée aurait résolu.

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.