Règles du pare-feu Windows qui comptent vraiment (et les paramètres par défaut dignes de confiance)

Les règles qui comptent vraiment (90% des résultats)

La plupart des jeux de règles du pare‑feu Windows sont bruyants pour la même raison que la plupart des placards sont encombrés : personne ne veut jeter quelque chose qui pourrait servir. C’est ainsi que vous vous retrouvez avec 700 règles entrantes, 600 d’entre elles désactivées, et quelques entrées « TEMP – DO NOT DELETE » de 2019 que tout le monde a peur de toucher.

Si vous exécutez des systèmes de production, un petit nombre de catégories de règles décide si vous passez une journée normale ou une tsunami de tickets :

1) Accès de gestion à distance (RDP, WinRM, WMI)

Ceci est existentiel. Si vous bloquez votre propre plan de gestion, votre « durcissement de sécurité » devient un générateur de pannes. Décidez quels moyens de gestion à distance vous utilisez et autorisez-les explicitement depuis des sources connues. Puis testez depuis ces sources.

• RDP TCP/3389 (ou votre port personnalisé, si vous insistez)
• WinRM TCP/5985 (HTTP) et TCP/5986 (HTTPS)
• WMI/DCOM RPC endpoint mapper TCP/135 plus ports RPC dynamiques (plus d’explications plus loin)

2) Ports d’écoute réels de l’application

Si l’application écoute sur TCP/443, vous vous souciez de TCP/443 entrant. Tout le reste est accessoire. N’« ouvrez pas une plage au cas où ». Ouvrez le port auquel le service est lié, limité aux réseaux sources qui en ont besoin.

3) Résolution de noms et synchronisation horaire (DNS, NTP)

Le DNS casse tout tout en ayant l’air de rien. La dérive horaire casse l’authentification tout en semblant « aléatoire ». Le DNS sortant (UDP/TCP 53) et le NTP sortant (UDP 123) sont les règles ennuyeuses que vous ne devriez pas complexifier.

4) Dépendances des services d’annuaire (pour serveurs joints au domaine)

Kerberos, LDAP/LDAPS et les appels RPC occasionnels sont les piliers cachés sous « la connexion fonctionne » et « les GPO s’appliquent ». Beaucoup d’organisations s’en sortent en « autorisant tout en sortie » sur les serveurs, ce qui est désordonné mais fonctionnel. Si vous serrez la sortie, les dépendances de domaine doivent être planifiées, pas découvertes à 2 h du matin.

5) Partage de fichiers (SMB) et partages administratifs

SMB est puissant et fréquemment détourné. Pour les serveurs qui n’ont pas besoin de SMB entrant, bloquez-le. Pour ceux qui en ont besoin, limitez fortement et journalisez.

• SMB TCP/445
• Les ports NetBIOS hérités (UDP/137, UDP/138, TCP/139) doivent être traités comme « pourquoi c’est encore là ? »

6) Contrôles sortants qui empêchent qu’un « petit incident devienne grand »

Les règles entrantes empêchent l’accès non sollicité. Les règles sortantes empêchent votre serveur de devenir un participant zélé du modèle économique de quelqu’un d’autre. Dans un environnement mature, la politique sortante compte—surtout pour les serveurs qui ne devraient parler qu’à quelques dépendances internes.

Une vérité sèche : si vous n’êtes pas prêt à inventorier les dépendances, ne commencez pas par un blocage sortant agressif. Vous créerez simplement un nouveau sport appelé « deviner la sortie manquante ».

Blague #1 : Une règle de pare‑feu nommée « TEMP » a une demi‑vie plus longue que le plutonium dans la plupart des entreprises.

Paramètres par défaut dignes de confiance (et quand ne pas leur faire confiance)

Les paramètres par défaut de Windows Defender Firewall ne sont pas aléatoires. Ils sont conçus pour garder le système utilisable dans une gamme ridiculement large d’environnements : ordinateurs portables sur le Wi‑Fi d’un café, serveurs dans un domaine, postes de dev exécutant des chaînes d’outils douteuses, et kiosques qui n’auraient jamais dû être en ligne.

Ce à quoi vous pouvez généralement faire confiance

• Comportement inbound par défaut : bloquer le trafic entrant non sollicité sauf si une règle l’autorise. C’est la bonne base pour les hôtes Windows.
• Comportement stateful : les connexions établies fonctionnent comme prévu. Si votre serveur initie une connexion TCP sortante, le trafic de retour est autorisé sans règles entrantes pour les ports éphémères.
• Règles réseau de base : de nombreuses règles intégrées existent pour que Windows puisse faire ses choses (DHCP, comportement client DNS, ICMP basique, etc.). Vous n’avez pas besoin de « simplifier » en les supprimant. Désactivez ou limitez intentionnellement si nécessaire, mais n’allez pas au tout‑brûlé.
• Profils distincts : la séparation Domaine/Privé/Public est réellement utile—lorsque la machine est correctement classée.

Où les paramètres par défaut peuvent vous trahir

Les paramètres par défaut ne valent que par les hypothèses qui les soutiennent. Voici où vous êtes blessé :

• Mauvaise classification de profil : un serveur qui pense être sur un réseau Public appliquera le profil Public. Ce profil est souvent plus restrictif. Résultat : « ça marchait hier, rien n’a changé », sauf que si.
• Règles « Autoriser si sécurisé » : certaines règles intégrées reposent sur IPsec ou un contexte d’authentification. Si vous n’utilisez pas cela, ces règles peuvent ne pas se comporter comme « autoriser ».
• Outils de sécurité tiers : les suites de protection des endpoints ajoutent parfois des callouts WFP, des filtres ou des règles locales. Vous vous retrouvez à dépanner le « Pare‑feu Windows » alors que le blocage se situe ailleurs dans la pile.
• Règles locales vs GPO : en environnement de domaine, les politiques se fusionnent. Votre « correctif » local peut être remplacé ou ne jamais s’appliquer, et vous diagnostiquerez mal le problème si vous ne vérifiez pas la politique effective.

La posture pratique : faites confiance au comportement de base (stateful, refus par défaut entrant), faites confiance aux règles intégrées de la plomberie OS sauf motif contraire, et ne faites pas confiance à tout ce qui dépend du profil réseau tant que vous ne l’avez pas vérifié.

Profils : Domaine vs Privé vs Public (et pourquoi une mauvaise classification ruine des journées)

Windows Defender Firewall applique les règles par profil. Les profils ne sont pas cosmétiques. Ce sont effectivement des ensembles de politiques différents. Si le profil est incorrect, vous jurerez que le pare‑feu est « aléatoire ». Il ne l’est pas. Il obéit—simplement au mauvais profil.

Profil Domaine

S’applique quand Windows croit être connecté à son domaine et peut atteindre un contrôleur de domaine. Dans les environnements serveurs, c’est là que vous placez généralement votre vraie politique : autoriser la gestion depuis des bastions, autoriser les ports d’application depuis des load balancers, autoriser la supervision depuis des sous‑réseaux de monitoring, bloquer le reste.

Profil Privé

Typiquement pour les réseaux non‑domaine de confiance. Dans les entreprises, il finit souvent comme « profil labo dev » ou « profil serveur en groupe de travail ». Traitez‑le comme semi‑fiable. Ne le transformez pas en un joker « tout autoriser ».

Profil Public

Pour les réseaux non fiables. Les ordinateurs portables adorent ce profil. Les serveurs ne devraient presque jamais l’utiliser—sauf quand ils le font, parce que quelqu’un a placé un serveur dans une DMZ sans connectivité au domaine et a oublié que Windows classe en fonction de l’awareness de localisation réseau.

Diagnostiquement : quand quelque chose casse après un redémarrage, après un déplacement de sous‑réseau, après des changements VPN, ou après une fenêtre de maintenance d’un contrôleur de domaine, vérifiez le profil actif avant de faire quelque chose d’ingénieux.

Évaluation des règles et précédence : comment Windows décide « autorisé » vs « non »

Windows Defender Firewall peut ressembler à un tableur jusqu’à ce que vous réalisiez qu’il est implémenté via le Windows Filtering Platform (WFP). Vous n’avez pas besoin de devenir ingénieur WFP, mais vous avez besoin de quelques modèles mentaux :

Filtrage stateful : le trafic de retour n’est pas « inbound autorisé »

Si un serveur effectue une connexion sortante à TCP/443, le trafic de réponse est autorisé. Les gens créent parfois des règles entrantes pour des ports éphémères pour « régler » ça, et c’est ainsi que vous obtenez des politiques en forme de gruyère.

Les règles de blocage prévalent sur les règles d’autorisation

Si le trafic correspond à une règle explicite de blocage, il est bloqué même si une autre règle l’autoriserait. C’est bien. Cela vous permet de créer « autoriser large, bloquer étroit » ou l’inverse selon votre style de politique. Mais cela signifie aussi qu’une règle de blocage trop large peut tuer l’accès en silence.

Les règles plus spécifiques ne sont pas toujours « de priorité supérieure » comme vous l’attendez

Windows évalue en fonction de l’ensemble des règles applicables. Vous ne pouvez pas compter sur « j’ai créé une règle après » comme mécanisme de priorité. Vous devez vous assurer qu’il n’y a pas de règle de blocage en conflit, et vous devez valider la politique effective.

GPO vs politique locale : la réalité fusionnée

En environnements de domaine, les règles peuvent provenir de :

• La politique locale du pare‑feu sur l’hôte
• Les règles de pare‑feu appliquées via Group Policy
• Callouts WFP tiers (pas des « règles » mais des filtres qui se comportent comme telles)

Quand quelqu’un dit « je l’ai autorisé dans le pare‑feu », votre question suivante devrait être « dans quelle couche, et est‑ce effectif ? »

Services Windows essentiels : les ports à considérer, pas à mémoriser

Les listes de ports sont utiles jusqu’à ce qu’elles deviennent un culte. Pensez en dépendances et rôles :

Dépendances d’identité et de domaine

• Kerberos : TCP/UDP 88 (authentification)
• LDAP : TCP/UDP 389 ; LDAPS : TCP/636
• Global Catalog : TCP 3268/3269
• DNS : TCP/UDP 53 (parce que AD est collé à DNS)
• Heure : UDP 123 (Kerberos y tient énormément)

Plan de gestion

• RDP : TCP 3389
• WinRM : TCP 5985/5986
• Logs d’événements à distance / outils MMC : peuvent nécessiter RPC/SMB selon la méthode utilisée

Partage de fichiers et imprimantes (SMB)

SMB (TCP/445) est celui qui compte. Si vous voyez encore des ports NetBIOS en 2026, demandez « quelle dépendance héritée nous retient en otage ? » puis planifiez sa suppression.

Ports RPC dynamiques : la partie que les gens brisent volontairement

RPC n’est pas « ouvrez 135 et c’est bon ». TCP/135 est le mappage d’endpoints. Le service réel utilise souvent des ports dynamiques. Si vous devez autoriser la gestion basée sur RPC à travers des pare‑feu, vous contraignez généralement la plage de ports dynamiques et autorisez explicitement cette plage. Sinon vous finissez soit par (a) des échecs aléatoires, soit (b) une large plage de ports ouverte « temporairement ».

Tâches pratiques : 12+ commandes, sorties et décisions

Voici les commandes que j’exécute réellement quand je suis sur une machine Windows (ou en session distante) pour répondre à une question : « Le pare‑feu est‑il la raison pour laquelle ce trafic meurt ? » Chaque tâche inclut ce que signifie la sortie et la décision que vous prenez ensuite.

Task 1: Check which firewall profiles are active

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain     True Block                Allow
Private   False Block                Allow
Public    False Block                Allow

Ce que cela signifie : Le profil Domaine est actif et applique « Bloquer les entrées, Autoriser les sorties. » C’est une base saine.

Décision : Si le mauvais profil est activé (Public sur un serveur de domaine), corrigez la classification réseau avant de toucher aux règles.

Task 2: Confirm the network category (Private/Public) and domain connectivity signal

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory, IPv4Connectivity, DomainAuthenticationKind"
InterfaceAlias NetworkCategory IPv4Connectivity DomainAuthenticationKind
-------------- -------------- --------------- ------------------------
Ethernet0       DomainAuthenticated Internet   Kerberos

Ce que cela signifie : Windows pense être authentifié au domaine. Bien. Si ceci indique Public, attendez‑vous à une politique plus stricte.

Décision : Si la catégorie est erronée après un déplacement, vérifiez les problèmes NLA, DNS et la reachabilité du contrôleur de domaine ; ne « réglez » pas ça avec des exceptions larges du pare‑feu.

Task 3: Verify the service is actually listening

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -in 443,3389,5985 } | Select-Object LocalAddress, LocalPort, OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- ------------
0.0.0.0             443        4120
0.0.0.0            3389        1096

Ce que cela signifie : Quelque chose écoute sur 443 et 3389. Si le port n’écoute pas, le pare‑feu n’est pas votre suspect principal.

Décision : Si rien n’écoute, allez d’abord à la configuration du service / liaison d’application. N’ouvrez pas de ports pour des services qui n’existent pas.

Task 4: Map the listening port to a process and service

cr0x@server:~$ powershell -NoProfile -Command "$p=Get-Process -Id 4120; $p.Name"
w3wp

Ce que cela signifie : Le processus worker IIS possède 443. Vous savez maintenant ce que vous protégez et ce que vous cassez.

Décision : Si le processus propriétaire est inattendu, vous avez peut‑être le mauvais service lié au port ou un service fantôme le détournant.

Task 5: Check effective inbound rules that match a port (example: 443)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 443 } | Select-Object InstanceID, LocalPort, Protocol"
InstanceID                              LocalPort Protocol
----------                              --------- --------
{A1B2C3D4-1111-2222-3333-444455556666}  443       TCP

Ce que cela signifie : Il existe au moins une règle d’autorisation activée pour TCP/443 entrant.

Décision : Si aucune règle d’autorisation n’existe, créez‑en une limitée aux sources requises. Si elle existe, cherchez une règle de blocage conflictuelle ou une mauvaise correspondance de profil.

Task 6: Hunt for explicit block rules that could override your allow

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Block | Select-Object DisplayName, Profile, PolicyStoreSource | Format-Table -AutoSize"
DisplayName                         Profile        PolicyStoreSource
-----------                         -------        -----------------
Block inbound from guest VLAN       Domain         GroupPolicy
Block all inbound (temporary)       Domain,Public  Local

Ce que cela signifie : Un « Block all inbound » local peut vous péter la journée, et il prévaudra sur beaucoup de règles allow.

Décision : Si une règle de blocage trop large existe, désactivez‑la ou restreignez‑la, puis retestez. Aussi : découvrez qui l’a créée et pourquoi.

Task 7: Validate the rule scope (remote addresses) for the allow rule

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Where-Object DisplayName -Match 'HTTPS' | Get-NetFirewallAddressFilter | Select-Object RemoteAddress"
RemoteAddress
-------------
10.20.30.0/24

Ce que cela signifie : La règle n’autorise qu’un sous‑réseau spécifique. Parfait pour la sécurité ; terrible si votre load balancer se trouve ailleurs.

Décision : Si des clients légitimes sont en dehors de cette portée, étendez la portée avec précaution (ajoutez les sous‑réseaux corrects), pas « Any ».

Task 8: Turn on firewall logging (temporarily) for the active profile

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallProfile -Name Domain -LogAllowed True -LogBlocked True -LogFileName 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' -LogMaxSizeKilobytes 32768"

Ce que cela signifie : La journalisation est maintenant activée. Cela vous aide à cesser de deviner.

Décision : Utilisez la journalisation pendant un incident, puis ajustez : gardez la journalisation des blocs pour les serveurs clés, mais ne noyez pas les disques sur des machines bruyantes.

Task 9: Read recent blocked traffic from the firewall log

cr0x@server:~$ powershell -NoProfile -Command "Get-Content 'C:\Windows\System32\LogFiles\Firewall\pfirewall.log' -Tail 10"
2026-02-05 12:01:21 DROP TCP 10.20.40.15 10.20.30.10 51512 443 60 S 1234567890 0 65535 - - - RECEIVE
2026-02-05 12:01:22 DROP TCP 10.20.40.15 10.20.30.10 51513 443 60 S 1234567891 0 65535 - - - RECEIVE

Ce que cela signifie : Le client 10.20.40.15 se voit refuser l’accès lors de la connexion à 10.20.30.10:443. C’est votre preuve évidente.

Décision : Ajoutez/ajustez une règle d’autorisation pour cette source (ou corrigez le routage/NAT si l’IP source n’est pas celle attendue).

Task 10: Test connectivity to a remote service from the Windows host

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.50.20 -Port 1433"
ComputerName     : 10.20.50.20
RemoteAddress    : 10.20.50.20
RemotePort       : 1433
InterfaceAlias   : Ethernet0
SourceAddress    : 10.20.30.10
TcpTestSucceeded : True

Ce que cela signifie : La sortie vers le serveur SQL fonctionne depuis cet hôte (au moins la poignée de main TCP).

Décision : Si cela échoue, examinez les règles sortantes, le profil et tout pare‑feu en amont. Si cela réussit mais que l’app échoue, vous avez un problème d’authentification, TLS ou couche applicative.

Task 11: List outbound rules that might be blocking critical egress

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object Action -eq 'Block' | Select-Object DisplayName, Profile, PolicyStoreSource | Format-Table -AutoSize"
DisplayName                          Profile PolicyStoreSource
-----------                          ------- -----------------
Block outbound to Internet           Domain  GroupPolicy
Block outbound except allowlist      Domain  GroupPolicy

Ce que cela signifie : Vous êtes dans un environnement avec restriction sortante (bien), et vous devez maintenant vous assurer que les dépendances sont explicitement autorisées (également bien, mais du travail).

Décision : Si la dépendance manque, ajoutez une règle d’autorisation pour les IP/ports de destination et documentez pourquoi elle existe.

Task 12: Check which rules are coming from GPO vs local

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True | Select-Object -First 5 DisplayName, PolicyStoreSource, PolicyStoreSourceType | Format-Table -AutoSize"
DisplayName                          PolicyStoreSource PolicyStoreSourceType
-----------                          ---------------  ---------------------
Core Networking - DNS (UDP-Out)      Local            Local
Allow HTTPS inbound to web tier      GroupPolicy      GroupPolicy
Block all inbound (temporary)        Local            Local
Allow WinRM from bastion             GroupPolicy      GroupPolicy
Core Networking - DHCP (UDP-Out)     Local            Local

Ce que cela signifie : Vous pouvez voir la provenance. Cela met fin aux disputes.

Décision : Si une règle locale est en conflit avec la GPO, décidez si les règles locales sont autorisées ; souvent la bonne correction se fait dans la GPO pour être cohérente.

Task 13: Confirm whether local rules are even allowed (GPO setting can disable them)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile -Name Domain | Select-Object Name, AllowLocalRules, AllowLocalIPsecRules"
Name   AllowLocalRules AllowLocalIPsecRules
----   -------------- --------------------
Domain            True                 True

Ce que cela signifie : Les règles locales peuvent s’appliquer. Si ceci était False, les « corrections » locales n’aideraient pas.

Décision : Si les règles locales sont interdites, arrêtez d’éditer localement et allez à la source de la politique (GPO) ou à l’équipe qui la gère.

Task 14: Quick snapshot of firewall status (legacy netsh still useful)

cr0x@server:~$ netsh advfirewall show allprofiles
Domain Profile Settings:
----------------------------------------------------------------------
State                                 ON
Firewall Policy                        BlockInbound,AllowOutbound
LocalFirewallRules                      N/A (GPO-store only)
LocalConSecRules                        N/A (GPO-store only)
Logging:
LogAllowedConnections                   Enable
LogDroppedConnections                   Enable
FileName                               C:\Windows\System32\LogFiles\Firewall\pfirewall.log
MaxFileSize                             32768

Private Profile Settings:
----------------------------------------------------------------------
State                                 OFF

Public Profile Settings:
----------------------------------------------------------------------
State                                 OFF

Ce que cela signifie : Le domaine est activé ; les règles locales ne sont pas applicables parce que le magasin de politique est uniquement GPO (ce format de sortie varie selon la version/politique).

Décision : Si vous voyez « GPO-store only », vous devez corriger les règles au niveau GPO, pas via des changements locaux.

Task 15: Capture a targeted firewall trace when logs aren’t enough

cr0x@server:~$ netsh wfp capture start file=C:\Temp\wfptrace.cab
WFP capture started.

cr0x@server:~$ netsh wfp capture stop
WFP capture stopped.

Ce que cela signifie : Vous avez capturé des événements WFP. C’est plus lourd que pfirewall.log et utile quand un callout tiers bloque le trafic.

Décision : Utilisez‑le quand vous suspectez fortement « ce n’est pas les règles du pare‑feu, c’est quelque chose dans WFP », et que vous avez besoin de preuves pour le propriétaire de l’outil de sécurité.

Task 16: Add a safe, scoped inbound allow rule (example: allow HTTPS from load balancers)

cr0x@server:~$ powershell -NoProfile -Command "New-NetFirewallRule -DisplayName 'Allow HTTPS from LB subnets' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 443 -RemoteAddress 10.20.40.0/24,10.20.41.0/24 -Profile Domain"

Ce que cela signifie : Vous avez ajouté une règle d’autorisation étroitement ciblée sur le profil Domaine seulement.

Décision : Retestez immédiatement depuis ces sous‑réseaux. Si cela fonctionne, poussez le changement dans votre processus policy‑as‑code ou GPO pour qu’il survive aux audits et reconstructions.

Task 17: Temporarily disable a suspicious rule (with a paper trail)

cr0x@server:~$ powershell -NoProfile -Command "Disable-NetFirewallRule -DisplayName 'Block all inbound (temporary)'"

Ce que cela signifie : Cette règle n’est plus appliquée.

Décision : Si le service revient, vous avez trouvé le coupable. Remplacez ensuite par une règle de blocage précise ou retirez‑la de la source de vérité. Ne laissez pas des règles « temporaires » désactivées devenir des artefacts permanents.

Fiche de diagnostic rapide (premier/deuxième/troisième)

Quand une connexion échoue, vous poursuivez généralement une des quatre choses : le service n’écoute pas, la route est fausse, un pare‑feu bloque, ou TLS/auth échoue. L’astuce est d’identifier dans quel panier vous êtes en quelques minutes, pas en réunions.

Premier : prouver que le service existe sur la cible

• Vérifiez que le port écoute (Get-NetTCPConnection -State Listen).
• Confirmez le processus/service qui le possède (map PID → process).
• Si rien n’écoute, arrêtez. Réparez le service. Les règles de pare‑feu ne ressusciteront pas un listener.

Second : prouver que les paquets arrivent (ou pas)

• Activez la journalisation du pare‑feu (court terme) et recherchez des DROP vers le port de destination.
• Si vous voyez des DROP, c’est le pare‑feu local ou WFP. Si vous ne voyez rien, le trafic peut ne pas atteindre l’hôte (ACL en amont, routage, VIP erroné, IP erronée).
• Validez que l’IP source indiquée dans les logs correspond à ce que vous attendez (les load balancers et le NAT aiment surprendre).

Troisième : valider la politique effective et les conflits

• Vérifiez le profil actif. Les hôtes mal profilés sont le tueur silencieux.
• Recherchez des règles de blocage pouvant annuler des autorisations.
• Vérifiez la portée des règles (adresses distantes, types d’interface, profils).
• Confirmez la source de la règle (GPO vs local). Ne « corrigez pas localement » ce qui est appliqué centralement.

Quatrième (quand c’est encore bizarre) : suspectez les callouts WFP et la sécurité endpoint

• Si les logs indiquent « allowed » mais le trafic échoue, ou si rien n’apparaît, capturez une trace WFP.
• Corrélez avec les modifications de l’endpoint security. Le « pare‑feu » pourrait ne pas être le composant qui bloque.

Trois mini‑histoires d’entreprise venues des tranchées du pare‑feu

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse (profil ≠ domaine)

L’environnement était propre sur le papier : serveurs web Windows dans un domaine, règles de pare‑feu gérées par GPO, entrées uniquement depuis les load balancers, gestion uniquement depuis un bastion. Le genre de configuration qui fait hocher la tête aux auditeurs et dormir les opérateurs.

Puis une fenêtre de maintenance a mis hors ligne une paire de contrôleurs de domaine sur un site distant. Ce site hébergeait aussi quelques serveurs web derrière un load balancer local. Les serveurs ont continué à tourner, mais en une heure les vérifications d’état ont commencé à échouer. La moitié du pool est devenue « non saine », puis la plupart.

Tout le monde a d’abord chassé le load balancer. Le VIP était stable. La config des health checks n’avait pas changé. L’équipe réseau a montré des flux propres au switch. L’équipe applicative insistait que le service était en ligne. Il l’était—localement.

Le vrai problème : les serveurs ont silencieusement basculé de DomainAuthenticated à Public parce qu’ils ne pouvaient pas atteindre un contrôleur de domaine. Le profil Public n’avait pas de règle d’autorisation entrante pour la source du health check, parce que personne ne s’attendait à ce qu’un serveur de domaine soit « Public ». Le pare‑feu a fait exactement ce qu’on lui a dit, dans le profil qu’il croyait actif.

La correction n’était pas « ouvrir plus de ports ». La correction était de rendre l’environnement résilient aux coupures de DC : assurer une connectivité redondante aux contrôleurs de domaine, et pour certains rôles DMZ‑ish, définir explicitement ce qui doit se passer si le profil Domaine n’est pas actif. Aussi, faire alerter la surveillance sur les changements de profil. La panne n’était pas causée par le pare‑feu ; elle était causée par une hypothèse.

Mini‑histoire 2 : L’optimisation qui s’est retournée (refus sortant sans inventaire)

Un programme de sécurité a décidé de « réduire la surface d’attaque » en mettant en place un refus par défaut sortant sur les serveurs Windows. Philosophically, c’est raisonnable. Pratiquement, c’est un projet de découverte de dépendances déguisé en trench coat.

Ils l’ont déployé par phases. Les premiers résultats semblaient bons : moins de trafic sortant, moins de connexions étranges vers Internet, plein de tableaux de bord qui vont dans la bonne direction. Puis la nuit des patchs est arrivée.

Windows Update a été bloqué. Les vérifications CRL/OCSP pour les certificats TLS de quelques applications aussi. Puis l’agent de monitoring n’a plus pu joindre son collecteur parce que quelqu’un a oublié qu’il utilisait TCP/443 vers un endpoint SaaS. Pendant ce temps l’équipe ops, essayant de stabiliser, a ajouté des règles d’autorisation ad‑hoc au niveau local—pour découvrir que les règles locales étaient désactivées par la GPO.

Le retour de bâton n’est pas que le contrôle sortant est mauvais. Le retour de bâton est d’en faire une « optimisation » ponctuelle plutôt qu’une capacité opérationnelle. L’autorisation sortante par liste blanche exige un catalogue de dépendances maintenu, un processus d’exception rapide, et de l’observabilité (logs) pour voir ce que vous bloquez.

Ils ont finalement réussi, mais seulement après avoir construit une pipeline d’autorisation liée aux manifests d’application et aux tags d’environnement. Leçon : les contrôles de sécurité non opérables deviennent des pannes. Les pannes deviennent des exceptions. Les exceptions deviennent la vraie politique.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (règles ciblées + journalisation)

Un système financier avait une règle simple : chaque serveur Windows de production doit avoir la journalisation des paquets bloqués activée pour le profil Domaine, avec envoi centralisé des logs. Pas de verbosité permanente ; juste assez pour répondre à « qu’est‑ce qui a été bloqué ? » sans RDPer dans tout le parc.

Un matin, un job batch a commencé à échouer pour atteindre un serveur de fichiers. Le job tournait depuis un compte de service sur un serveur applicatif, et il fonctionnait depuis des années. L’équipe du serveur de fichiers a dit qu’elle « n’avait rien changé ». L’équipe applicative a dit qu’elle « n’avait rien changé ». Tous techniquement corrects, ce qui est le pire type de correct.

Les logs de drop ont raconté l’histoire en cinq minutes : l’IP source avait changé. Le serveur applicatif avait été reconstruit sur un nouveau sous‑réseau dans le cadre d’un nettoyage de virtualisation. La règle SMB sur le serveur de fichiers n’autorisait que l’ancien sous‑réseau. C’est tout. Pas de mystère.

La correction fut tout aussi ennuyeuse : mettre à jour la règle SMB pour inclure le nouveau sous‑réseau, valider l’accès, et mettre à jour l’automatisation de build pour que les reconstructions inscrivent leurs nouvelles adresses dans la source de vérité de la portée des règles. Personne n’a eu à deviner. Personne n’a eu à « ouvrir temporairement le 445 à Any ». La pratique ennuyeuse—règles ciblées plus logs centralisés—a sauvé la journée.

Blague #2 : Le moyen le plus rapide d’apprendre de quoi dépend votre application est de bloquer le trafic sortant et d’attendre que quelqu’un hurle.

Erreurs courantes : symptôme → cause racine → correction

1) « Ça marche depuis un sous‑réseau mais pas un autre »

Symptôme : Certains clients se connectent bien ; d’autres expirent ou se voient refuser.

Cause racine : La règle Allow a une portée RemoteAddress étroite qui n’inclut pas le sous‑réseau en échec, ou le trafic est NATé si bien que l’IP source diffère.

Correction : Vérifiez les logs de drop pour l’IP source réelle. Étendez la portée de la règle pour inclure les plages sources correctes. Si le NAT est impliqué, coordonnez‑vous avec l’équipe réseau pour autoriser la source traduite.

2) « Après reboot, rien ne peut se connecter »

Symptôme : Le serveur redémarre, les services fonctionnent, mais l’accès entrant meurt.

Cause racine : Le profil a changé (Domaine → Public) à cause d’un NLA / reachabilité DC. Ou la GPO s’est réappliquée et a supprimé une exception locale.

Correction : Vérifiez le profil et l’état d’authentification au domaine. Corrigez DNS / reachabilité DC. Ne bourrez pas une règle allow large dans Public sauf si vous supportez intentionnellement un scénario hors domaine.

3) « RDP est bloqué mais la règle est activée »

Symptôme : RDP expire ; vous voyez une règle allow pour 3389.

Cause racine : La règle s’applique au mauvais profil, au mauvais type d’interface, ou est surclassée par une règle de blocage plus large. Possibilité aussi : RDP a été déplacé sur un autre port et la règle n’a pas été mise à jour.

Correction : Confirmez le port d’écoute, le profil actif, et recherchez des règles de blocage entrantes. Restreignez la règle allow au réseau du bastion seulement. Vérifiez que la configuration du service correspond à la règle.

4) « WinRM fonctionne sur certains serveurs mais pas d’autres »

Symptôme : L’automatisation échoue contre un sous‑ensemble d’hôtes Windows.

Cause racine : Application GPO incohérente, règles locales désactivées sur certains hôtes, ou WinRM lié à HTTPS sans chaîne de certificats atteignable (ressemble à un problème réseau).

Correction : Vérifiez la source de la politique. Validez la configuration du listener WinRM et les ports. Si vous utilisez 5986, assurez‑vous de la confiance de la chaîne de certificats et de la reachabilité CRL/OCSP (les règles sortantes comptent).

5) « Le DNS est cassé mais seulement sur ce serveur »

Symptôme : La résolution de noms échoue ; la connectivité IP est OK.

Cause racine : UDP/53 sortant bloqué par une politique sortante, ou bascule DNS sur TCP bloquée, ou mauvaise config de serveur DNS combinée à des limitations sortantes.

Correction : Testez UDP et TCP vers le serveur DNS. Ajoutez des autorisations sortantes explicites vers les serveurs DNS. Vérifiez la configuration DNS du serveur et les forwarders conditionnels de l’environnement.

6) « L’application du vendeur nécessite ‘plein de ports’, alors on a ouvert 1–65535 »

Symptôme : Le vendeur l’a demandé. La demande a été approuvée. Personne ne se souvient pourquoi.

Cause racine : Manque de cartographie des dépendances et gestion des changements guidée par la peur.

Correction : Restaurez le principe du moindre privilège : identifiez les ports d’écoute réels, contraignez les plages RPC dynamiques si nécessaire, autorisez seulement les sources requises. Utilisez les logs pour vérifier ce qui est bloqué lorsque vous serrez.

7) « On a créé la règle mais ça ne marche toujours pas »

Symptôme : La règle existe ; le trafic échoue toujours.

Cause racine : La règle est dans le magasin local mais les règles locales sont désactivées par la GPO. Ou la règle est activée mais non applicable à cause d’un mauvais profil/type d’interface.

Correction : Vérifiez AllowLocalRules et la source de la règle. Mettez la règle dans le magasin de politique correct (typiquement GPO) et assurez‑vous qu’elle correspond au profil actif.

Listes de contrôle / plan étape par étape

Checklist A: Posture minimale viable du pare‑feu pour serveurs Windows

1. Conserver le blocage entrant par défaut sur tous les profils. Ne « permettez pas tout » temporairement. Faites que ce soit socialement inacceptable.
2. Autoriser la gestion (RDP/WinRM) uniquement depuis les sous‑réseaux bastion/jump. Si vous l’autorisez depuis « Any », vous avez créé une cible.
3. Autoriser les ports applicatifs uniquement depuis les réseaux clients réels (load balancers, couches applicatives, sous‑réseaux utilisateurs selon besoin).
4. Autoriser la sortie vers DNS interne et NTP explicitement si vous imposez des restrictions sortantes.
5. Bloquer SMB entrant sur les serveurs qui n’en ont pas besoin. S’ils en ont besoin, autorisez depuis les réseaux d’administration uniquement.
6. Activer la journalisation des paquets bloqués au moins sur les couches critiques, et agrégez les logs centralement.
7. Documenter les exceptions avec propriétaire + date d’expiration. Puis appliquez l’expiration.

Checklist B: Quand on vous demande « ouvrir des ports pour une appli »

1. Identifier les ports d’écoute de l’application sur l’hôte (ne faites pas confiance au PDF du vendeur).
2. Identifier les réseaux sources qui ont besoin d’accès (clients, load balancers, monitoring, jobs batch).
3. Créer des règles allow entrantes limitées par : profil, protocole, port local, adresse distante, et (si possible) programme/service.
4. Si RPC est impliqué, contraindre la plage de ports dynamiques et autoriser cette plage—n’ouvrez pas « tous les ports élevés ».
5. Activer la journalisation pendant le déploiement. Vérifier que les clients attendus sont autorisés et que les scans inattendus sont bloqués.
6. Capturer le jeu de règles dans le système de référence (template GPO, gestion de configuration, policy‑as‑code). Les changements locaux uniquement sont un instrument de dette.

Checklist C: Durcir sans se saboter

1. Commencez par le moindre privilège entrant avant la sortie. C’est plus simple et réduit réellement le risque.
2. Si vous poursuivez des contrôles sortants, faites‑le par rôle (web, app, DB, gestion) avec des catalogues de dépendances.
3. Testez explicitement les dépendances de domaine pour les hôtes joints (Kerberos, LDAP, DNS, heure).
4. Surveillez les changements de profil et les modifications de politique de pare‑feu comme des signaux de première classe.
5. Ne supprimez pas les règles intégrées juste pour vous sentir productif. Désactivez avec intention et notez pourquoi.

Faits et contexte intéressants (parce que l’histoire explique les paramètres par défaut)

• Fait 1 : Le pare‑feu Windows est devenu réellement « activé par défaut » pour beaucoup d’utilisateurs autour de l’ère Windows XP SP2, après que des vers ont rendu le coût d’un inbound ouvert douloureusement évident.
• Fait 2 : Le moteur d’application moderne en dessous est le Windows Filtering Platform (WFP), qui permet à plusieurs composants (y compris des produits de sécurité) de participer aux décisions de trafic.
• Fait 3 : Les profils (Domaine/Privé/Public) sont liés à la Network Location Awareness de Windows. Ce ne sont pas des « étiquettes » manuelles ; ils changent selon ce que Windows peut détecter du réseau.
• Fait 4 : Beaucoup de règles « Core Networking » existent parce que Windows a besoin d’effectuer des opérations hôtes de base (DHCP, découverte des voisins, comportement DNS). Les supprimer tend à créer des échecs qui ressemblent à « Windows est instable ».
• Fait 5 : Le comportement des ports dynamiques RPC est historiquement flexible pour éviter les collisions de ports et supporter plusieurs services ; c’est aussi une raison fréquente pour laquelle les projets de durcissement du pare‑feu deviennent chaotiques.
• Fait 6 : Group Policy n’ajoute pas seulement des règles de pare‑feu—elle peut aussi décider si les règles locales sont autorisées à s’appliquer du tout, d’où le « j’ai ajouté une règle localement » qui parfois ne fait rien.
• Fait 7 : Le filtrage stateful signifie que les ports éphémères entrants ne doivent pas être ouverts pour le trafic de retour, mais les gens le font encore parce qu’ils ont appris les pare‑feux sur des modèles plus anciens sans état.
• Fait 8 : Les règles de pare‑feu Windows peuvent être limitées par programme/service, pas seulement par ports, ce qui est plus robuste sur les hôtes exécutant plusieurs applications.
• Fait 9 : Le format du journal du pare‑feu (pfirewall.log) est intentionnellement simple. Il est conçu pour être parsable et expédiable, pas joli.

Une idée opérationnelle paraphrasée qui reste vraie en toute époque : La fiabilité vient de la gestion des pannes prévisibles, pas d’espérer qu’elles n’arrivent pas. — John Allspaw (paraphrase)

FAQ

Q1: Dois‑je faire confiance aux paramètres par défaut du pare‑feu Windows sur les serveurs ?

Faites confiance au modèle de base : blocage entrant par défaut, trafic de retour stateful, et règles intégrées de mise en réseau. Ne faites pas aveuglément confiance au fait que les profils seront toujours corrects ni à l’absence de filtres ajoutés par des tiers.

Q2: Pourquoi mon serveur de domaine affiche‑t‑il parfois le profil Public ?

Généralement parce qu’il ne peut pas atteindre un contrôleur de domaine ou que le DNS est mal configuré, donc la Network Location Awareness ne peut pas confirmer l’authentification de domaine. Corrigez la connectivité et la résolution de noms ; ne le masque z pas par des règles Public « allow all ».

Q3: Ai‑je besoin de règles entrantes pour les ports éphémères ?

Pas pour le trafic de retour des connexions initiées par votre hôte. Vous devez penser aux ports dynamiques lorsque vous autorisez la gestion entrante basée sur RPC ou des services qui négocient des ports dynamiques.

Q4: Quelle est l’approche la plus simple et sûre pour autoriser RDP ?

Autorisez TCP/3389 entrant uniquement depuis un sous‑réseau bastion/jump (ou des postes admin spécifiques via VPN), sur le profil Domaine. Journalisez les drops. N’autorisez pas RDP depuis « Any » à moins d’aimer la réponse aux incidents comme hobby.

Q5: Si mon appli utilise HTTPS, puis‑je simplement autoriser 443 depuis n’importe où ?

Vous pouvez, mais vous ne devriez pas par défaut. Ciblez par réseaux sources (load balancers, reverse proxies, sous‑réseaux utilisateurs) et pensez à utiliser le scoping par programme/service pour empêcher un processus aléatoire de binder 443 et d’hériter de votre confiance.

Q6: Pourquoi je vois une règle allow mais le trafic est toujours bloqué ?

Causes courantes : une règle de blocage la remplace, la règle s’applique à un autre profil, les règles locales sont désactivées par la GPO, ou un callout WFP tiers bloque. Vérifiez les logs et la provenance des règles.

Q7: Le blocage sortant vaut‑il la peine ?

Oui, mais seulement si vous pouvez l’exploiter : maintenez des inventaires de dépendances, ayez un processus d’exception rapide, et surveillez les blocs. Sinon cela devient une usine à pannes et finit par être contourné.

Q8: Comment savoir vite si le pare‑feu est le goulot d’étranglement ?

Confirmez que le port écoute, activez/vérifiez les logs de drop pour ce port de destination, et validez le profil ainsi que les conflits de règles. Si les drops montrent le flux exact, c’est la politique locale. Si rien n’apparaît, le trafic n’atteint probablement pas l’hôte.

Q9: Dois‑je supprimer les règles intégrées pour réduire l’encombrement ?

Non. Désactivez avec intention si nécessaire, mais supprimer les règles intégrées est rarement une victoire de sécurité et souvent une perte de stabilité. L’encombrement se gère mieux par discipline de politique et conventions de nommage.

Conclusion : étapes pratiques suivantes

Si vous voulez que le pare‑feu Windows cesse d’être une maison hantée, vous n’avez pas besoin de centaines de règles. Vous avez besoin d’un petit ensemble de règles qui sont ciblées, attribuables et testées—plus la discipline de ne pas « corriger temporairement » la production avec un marteau.

1. Auditez le profil actif et les actions par défaut sur votre flotte de serveurs. Les hôtes mal profilés sont une classe d’incidents récurrente.
2. Définissez une politique standard de gestion (RDP/WinRM) avec portée source et journalisation.
3. Pour chaque rôle serveur, documentez les ports d’écoute et créez des règles entrantes limitées aux clients réels.
4. Décidez si la sortie est Allow‑by‑default ou liste blanche, et si c’est liste blanche, construisez d’abord l’inventaire de dépendances et la journalisation.
5. Activez la journalisation des paquets bloqués pour les couches critiques et centralisez‑la. Deviner coûte cher.
6. Déplacez les règles dans votre système de référence (GPO/gestion de configuration). Les ajustements locaux ne montent pas en charge et ne survivent pas aux reconstructions.

Le but n’est pas « paramètres de sécurité maximaux ». Le but est une politique de pare‑feu que vous pouvez expliquer pendant un incident sans mentir, et que vous pouvez changer sans prier.