Gérer le pare-feu Windows à grande échelle (GPO, Intune)

Configurer le pare-feu Windows sur une machine est facile. Maintenir des milliers de machines sur une stratégie cohérente et voulue, c'est là que la plupart des programmes s'enlisent : les règles s'accumulent dans de nombreuses GPO, les programmes d'installation ajoutent des règles locales, Intune et la stratégie de groupe touchent les mêmes appareils, et personne ne sait dire quelle règle autorise réellement un port donné.

Le guide pilier sur le durcissement du pare-feu Windows définit ce que doit être la stratégie. Ce guide traite du comment la faire vivre à grande échelle : comment les sources de stratégie se combinent, comment les règles sont évaluées, comment structurer GPO et profils Intune, et comment prouver ce qu'un appareil applique réellement. Voir la thématique Pare-feu Windows pour la série complète.

Comment les magasins de stratégie se combinent

Le pare-feu Windows conserve les règles dans plusieurs magasins et les fusionne dans un magasin actif (active store) que le moteur applique :

Deux comportements de fusion différents s'appliquent :

• Les règles s'additionnent. Chaque règle de chaque GPO concernée se retrouve dans le magasin actif. Il n'y a pas de « le dernier qui écrit gagne » pour les règles.
• Les paramètres de profil suivent la priorité. L'état du pare-feu, les actions entrante et sortante par défaut, les notifications, la journalisation et les commutateurs de fusion locale sont des valeurs uniques ; pour la stratégie de groupe, l'ordre LSDOU habituel s'applique et la GPO de plus haute priorité l'emporte pour chaque paramètre.

Conséquence : une règle d'autorisation TCP 3389 depuis Any dans une vieille GPO oubliée, liée à la racine du domaine, est appliquée sur toutes les machines, quel que soit le soin avec lequel vos nouvelles GPO de rôle restreignent RDP.

Comment les règles sont évaluées

Quand un paquet arrive, le moteur applique les règles dans cet ordre :

1. Restrictions de durcissement des services Windows (intégrées, impossibles à outrepasser).
2. Règles de sécurité de connexion (IPsec) qui authentifient ou protègent le trafic.
3. Règles de contournement authentifié (règles d'autorisation avec Override block rules, utilisables uniquement avec IPsec).
4. Règles de blocage.
5. Règles d'autorisation.
6. Action par défaut du profil.

Le blocage l'emporte toujours sur l'autorisation. Erreur classique : une règle large « Bloquer SMB entrant » suivie d'une règle « Autoriser SMB depuis les serveurs de gestion » ; le blocage gagne et l'administration tombe. Avec une action entrante par défaut à Block, vous avez rarement besoin de règles de blocage entrantes explicites ; exprimez l'intention avec des règles d'autorisation restreintes, et gardez les blocages explicites pour ce qui ne doit jamais arriver (par exemple le SMB sortant vers Internet).

Étape 1 : désactiver partout la fusion des règles locales

Dans les propriétés du pare-feu de la GPO, pour chaque profil, cliquez sur Customize sous Settings et réglez Apply local firewall rules sur No, ainsi que Apply local connection security rules sur No. Dans Intune, les paramètres équivalents du profil de pare-feu sont Allow Local Policy Merge et Allow Local Ipsec Policy Merge, tous deux à False par profil (CSP Firewall MdmStore/<Profile>/AllowLocalPolicyMerge et AllowLocalIpsecPolicyMerge).

Les règles locales ne sont pas supprimées ; elles restent dans le PersistentStore et sont simplement ignorées. Le retour arrière est donc facile, mais il faut aussi savoir lesquelles de ces règles locales comptaient vraiment. Avant de basculer le commutateur sur un groupe pilote, exportez ce que les programmes d'installation ont créé :

Get-NetFirewallRule -PolicyStore PersistentStore -Direction Inbound -Enabled True -Action Allow |
  ForEach-Object {
    $port = $_ | Get-NetFirewallPortFilter
    $app  = $_ | Get-NetFirewallApplicationFilter
    [pscustomobject]@{ Name=$_.DisplayName; Profile=$_.Profile; Protocol=$port.Protocol
                       LocalPort=$port.LocalPort; Program=$app.Program }
  } | Export-Csv "$env:TEMP\local-inbound-rules.csv" -NoTypeInformation

Récupérez ce CSV sur un échantillon représentatif, supprimez ce dont personne n'a besoin et transformez le reste en règles centrales.

Étape 2 : structurer les GPO

Une organisation qui reste lisible au fil des années :

Règles de conduite qui évitent la dérive :

• Un propriétaire par GPO, nommé dans le commentaire de la GPO.
• Le nom des règles porte le ticket ou la finalité (SQL-1433-from-AppTier-CHG1234), et la propriété Group de la règle est renseignée pour pouvoir filtrer et rapporter les règles comme un ensemble.
• N'activez jamais les groupes de règles prédéfinis (Remote Desktop, File and Printer Sharing) sans modifier leur étendue distante ; elle vaut Any par défaut.
• Auditez les anciennes GPO à la recherche de règles de pare-feu. Exporter toutes les GPO avec Get-GPOReport -All -ReportType Xml et chercher les éléments de règles de pare-feu dans le résultat retrouve vite les stratégies oubliées.

Les règles de pare-feu GPO peuvent être scriptées directement dans une stratégie via une session GPO, ce qui évite d'éditer des centaines de règles à la main :

$gpo = Open-NetGPO -PolicyStore 'corp.example.com\FW-Role-SQL'
New-NetFirewallRule -GPOSession $gpo -DisplayName 'SQL-1433-from-AppTier' `
  -Group 'Role-SQL' -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress 10.30.20.0/24 -Profile Domain -Action Allow
Save-NetGPO -GPOSession $gpo

Conservez les scripts dans un gestionnaire de versions. Ils deviennent votre documentation et votre retour arrière.

Étape 3 : l'équivalent Intune

Dans le centre d'administration Intune, Endpoint security > Firewall propose deux types de profils pour Windows :

• Windows Firewall (paramètres de profil) : état, actions par défaut, fusion locale, journalisation, par profil.
• Windows Firewall Rules : les règles individuelles. Un profil contient un nombre limité de règles (150 au moment de la rédaction) : découpez par rôle, comme pour les GPO.

Affectez les profils de règles à des groupes d'appareils qui reflètent vos rôles GPO, et utilisez des filtres d'affectation pour les exceptions plutôt que de cloner les profils. Intune prend aussi en charge des groupes de paramètres réutilisables (reusable settings groups) pour les plages d'adresses IP distantes : le « sous-réseau d'administration Tier 2 » est défini une fois et référencé par toutes les règles qui en ont besoin ; modifiez la plage à un seul endroit et toutes les règles suivent.

Pour les appareils joints en mode hybride qui reçoivent à la fois une stratégie de pare-feu GPO et Intune, les deux jeux de règles arrivent dans le magasin actif. Évitez les paramètres de profil qui se chevauchent : choisissez une autorité par population et déplacez explicitement les appareils de l'une à l'autre. La stratégie MDMWinsOverGP ne s'applique qu'aux paramètres du Policy CSP, pas au Firewall CSP : elle ne résout donc pas les chevauchements. Le Firewall CSP documente sa propre règle de fusion : pour les paramètres de profil comme l'état du pare-feu, l'action entrante par défaut et les paramètres de journal, une valeur configurée par stratégie de groupe l'emporte sur la valeur MDM ; sur les appareils hybrides, une GPO de pare-feu résiduelle écrase donc silencieusement votre profil Intune.

Étape 4 : gestion des changements

Les modifications de pare-feu cassent la production plus vite que la plupart des changements de stratégie. Un processus viable :

1. Demande étayée : quel processus, port, direction et source, idéalement appuyés par pfirewall.log ou des événements 5157 issus de la journalisation du pare-feu.
2. Pilote : liez ou affectez d'abord à une UO ou un groupe pilote. Les anneaux Intune comme le filtrage de sécurité des GPO conviennent.
3. Enregistrer l'état antérieur : netsh advfirewall export sur un hôte de référence, et Backup-GPO pour la stratégie.
4. Promouvoir vers l'étendue large après la période pilote.
5. Revue trimestrielle : les règles qui n'ont correspondu à aucun trafic depuis des mois sont candidates à la suppression. Activer temporairement la journalisation des succès sur un échantillon rend cela mesurable.

Ce qui casse

• Les applications qui créent leurs propres règles à l'installation (clients de collaboration, composants de mise à jour pair à pair, outils de développement, plateformes de virtualisation et de conteneurs) ne reçoivent plus de trafic entrant une fois la fusion locale désactivée. La plupart des clients modernes fonctionnent en sortant uniquement ; les autres ont besoin d'une règle centrale.
• Les chemins de programmes par utilisateur sous %LocalAppData% sont difficiles à exprimer centralement. Pour ces applications, préférez des règles fondées sur le port et le protocole, restreintes aux bonnes adresses distantes.
• Les règles de blocage explicites pensées comme « bloquer sauf » écrasent silencieusement les règles d'autorisation ajoutées plus tard.
• Le mélange GPO et Intune fait apparaître des règles qu'aucune des deux équipes ne reconnaît.
• La mise en cache pair à pair de l'Optimisation de la distribution (Delivery Optimization, TCP 7680) et les fonctions similaires cessent de fonctionner entre clients si vous ne les autorisez pas ; décidez-le sciemment.

Vérifier

Le magasin actif fait foi. Demandez-lui d'où vient chaque règle :

Get-NetFirewallRule -PolicyStore ActiveStore |
  Group-Object PolicyStoreSourceType | Select-Object Name, Count

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound -Action Allow -Enabled True |
  Select-Object DisplayName, PolicyStoreSource, Profile |
  Sort-Object PolicyStoreSource

PolicyStoreSource indique la GPO ou le magasin de chaque règle, ce qui permet de repérer immédiatement une règle d'autorisation issue d'une GPO inattendue. Contrôlez les paramètres de profil de la même façon :

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

AllowLocalFirewallRules doit valoir False sur tous les profils. Complétez avec gpresult /h côté GPO et l'état des stratégies par appareil dans Intune côté MDM, et suivez l'événement de sécurité 4954 (paramètres de pare-feu de la stratégie de groupe appliqués) via votre chaîne de transfert d'événements.

Liste de contrôle

• Fusion des règles locales et des règles de sécurité de connexion désactivée dans chaque profil
• Règles locales des programmes d'installation exportées, revues et remplacées par des règles centrales si nécessaire
• Paramètres de profil dans une GPO de référence ou un profil Intune unique ; règles découpées par rôle
• Aucune règle de blocage entrante explicite utilisée comme « bloquer sauf »
• Groupes de règles prédéfinis restreints ; anciennes GPO auditées à la recherche de règles
• Une seule autorité de stratégie (GPO ou Intune) par population d'appareils
• Magasin actif revu par PolicyStoreSource ; changements pilotés et sauvegardés

Une stratégie cohérente et détenue centralement est aussi le socle des règles fondées sur l'identité avec l'isolation de domaine et de serveurs IPsec, et du modèle d'accès par niveaux décrit dans le tiering de l'administration.