Règles sortantes du pare-feu Windows : pilote ciblé

Que sont les règles sortantes du pare-feu Windows ?

Les règles sortantes du pare-feu Windows régissent les connexions qui quittent un ordinateur Windows. L’action sortante par défaut d’un profil détermine ce qui se passe lorsqu’aucune règle applicable n’autorise ni ne bloque ce trafic. Un pilote de blocage par défaut commence par une population définie et un ensemble documenté de connexions nécessaires, puis vérifie si ces connexions fonctionnent toujours avec la stratégie prévue.

Ce choix de durcissement entraîne des coûts opérationnels. Microsoft recommande d’autoriser le trafic sortant par défaut pour la plupart des déploiements et envisage le blocage par défaut pour certains environnements fortement sécurisés. Un constat sur l’action par défaut collectée ouvre donc une analyse ; il n’établit pas une obligation universelle de bloquer le trafic sortant dans tout le domaine. Consultez les recommandations de Microsoft sur les règles Windows Firewall.

La question pratique est de savoir si votre organisation peut maintenir une liste d’autorisation utile pour les ordinateurs choisis. Définissez qui est responsable des changements, quelles applications doivent communiquer et comment rétablir les dépendances défaillantes avant de modifier l’action par défaut. Une stratégie qui interrompt les mises à jour ou l’administration à distance sans voie de récupération peut compromettre l’objectif de l’exercice.

Fonctionnement : l’action par défaut d’un profil diffère d’une règle de blocage

Les profils Domain, Private et Public ont des paramètres distincts. Choisissez délibérément le profil du pilote et vérifiez celui utilisé sur le réseau cible. Une configuration du profil Domain ne démontre pas ce qui se passe lorsque le même ordinateur utilise un réseau Private ou Public.

Il faut distinguer deux conceptions. Avec une action sortante par défaut définie sur Block, une règle d’autorisation explicite applicable peut permettre le trafic nécessaire. Avec une règle de blocage explicite large, une règle d’autorisation ordinaire en conflit ne rétablit pas ce trafic : les règles de blocage explicites sont prioritaires. Une autorisation plus précise ne permet pas de contourner un blocage explicite qui la recouvre. Ces comportements de priorité s’appliquent aussi aux règles sortantes.

Les magasins de stratégies comptent également. Une règle enregistrée dans une GPO de gestion décrit la configuration prévue. L’ActiveStore de la cible représente la stratégie actuellement active, assemblée à partir des magasins applicables. La fusion des règles locales peut influer sur les exceptions prises en compte ; examinez les paramètres réels de fusion et les sources des règles au lieu de supposer qu’une exception créée localement sera utilisée. Le guide de gestion en ligne de commande de Microsoft documente les opérations locales et par GPO.

Séparez les restrictions d’authentification des restrictions de connectivité. Notre guide pour bloquer le NTLM sortant des systèmes Tier 0 traite de la restriction d’un mécanisme d’authentification impliqué dans la coercition et le relais. Cette décision ne définit pas une liste d’autorisation du pare-feu par application et destination, et une action sortante par défaut du pare-feu n’établit pas que l’authentification NTLM est désactivée.

Détection : comparer les données GPO collectées à la cible

Consignez l’ordinateur, le contexte réseau, le périmètre de stratégie prévu et l’heure de collecte. Exécutez séparément les commandes de lecture suivantes dans PowerShell sur une cible Windows représentative. Il s’agit d’exemples issus de la documentation, pas de mesures effectuées pour cet article.

Étape 1 : lire les paramètres des profils actifs

Microsoft documente Get-NetFirewallProfile avec ActiveStore :

Get-NetFirewallProfile -PolicyStore ActiveStore

Examinez Name, Enabled et DefaultOutboundAction pour chaque profil, ainsi que les paramètres de fusion des règles locales et de journalisation. Conservez la sortie obtenue. Confirmez quel profil réseau le pilote utilise réellement ; une valeur Block sur un profil inactif ne suffit pas à prouver que le flux testé a été filtré.

Comparez le résultat Domain à la valeur WindowsFirewall/DomainProfile/DefaultOutboundAction de la GPO collectée dans Registry.pol. Dans la représentation du détecteur, 0 signifie Allow et 1 signifie Block. Lorsque la valeur GPO est absente ou diffère de celle de la cible, examinez l’application de la stratégie et les sources de configuration concurrentes. Ne remplacez pas le résultat actif de l’ordinateur par la valeur choisie par le collecteur.

Étape 2 : examiner les règles sortantes et leurs sources

Utilisez la référence Get-NetFirewallRule pour récupérer les règles sortantes de la stratégie active et retrouver leurs magasins d’origine :

Get-NetFirewallRule -Direction Outbound -PolicyStore ActiveStore -TracePolicyStore

Examinez l’état d’activation, l’action, le profil, la source et les filtres associés d’application, de service, d’adresse et de port. Les objets de règle seuls n’affichent pas intégralement tous les filtres associés ; examinez ces détails dans Windows Firewall with Advanced Security ou avec les cmdlets de filtre NetSecurity correspondantes. Repérez les règles de blocage qui se recouvrent et les autorisations trop larges avant d’interpréter un test de connectivité.

Notre guide des quatre contrôles de sécurité GPO utilise la même méthode de vérification : comparer l’intention de la stratégie, les ordinateurs qui la reçoivent et la protection réellement utilisée. Ses contrôles LLMNR, WSUS, LSA et UNC n’établissent pas la couverture du pare-feu sortant. Appliquez ici cette méthode avec des preuves propres au pare-feu sur la cible.

Étape 3 : observer le trafic nécessaire et rejeté

Lisez le LogFileName configuré pour le profil au lieu de supposer que tous les ordinateurs utilisent le même chemin. Le guide en ligne de commande indique %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log. La référence Set-NetFirewallProfile documente la journalisation des paquets acceptés et abandonnés. Corrélez les entrées conservées avec l’opération applicative, l’horodatage, le protocole et les extrémités que vous testez.

Pour un pilote de laboratoire isolé et géré localement, cette commande active les deux options de journalisation pour Domain :

Set-NetFirewallProfile -Profile Domain -LogAllowed True -LogBlocked True

Pour les ordinateurs gérés, configurez plutôt la journalisation dans la stratégie qui les gouverne, puis vérifiez-la dans ActiveStore. Les changements de journalisation sont distincts de l’action sortante par défaut. Consignez les paramètres antérieurs et prévoyez la conservation des journaux pour garder les preuves de dépannage disponibles. Un paquet abandonné est un point de départ pour l’analyse, pas une preuve de logiciel malveillant ; le silence d’un journal ne prouve pas que tous les chemins applicatifs sont autorisés.

Remédiation : concevoir un pilote de blocage par défaut ciblé (Remediation)

Étape 1 : décider si le blocage par défaut convient à la population

Consignez la justification métier et de sécurité du pilote, les ordinateurs choisis et la limite du profil Domain. Sélectionnez une population maîtrisable avec des responsables applicatifs disponibles pour les tests. Identifiez les fenêtres de maintenance, les responsabilités de surveillance et une voie de récupération indépendante. Définissez les preuves permettant l’extension et les défaillances imposant un retour arrière.

Si l’inventaire des dépendances est incomplet ou si personne ne peut le maintenir, consignez cette limite et traitez-la avant la mise en application. L’objectif est une stratégie de connectivité maintenable. Clore un constat de configuration en modifiant une action par défaut à l’échelle du domaine sans en comprendre les effets n’est pas un critère de réussite utile.

Étape 2 : inventorier les applications et leurs dépendances

Pour chaque application et service, consignez son exécutable ou son identité de service, ses destinations prévues, le protocole, les ports de destination, les horaires de fonctionnement et le responsable. Incluez explicitement dans l’analyse la résolution DNS, la récupération des mises à jour, les agents de gestion, l’administration à distance et les outils de récupération. Inventoriez les opérations courantes comme les tâches de maintenance peu fréquentes ; une session interactive réussie ne teste pas une mise à jour ou une sauvegarde planifiée.

Construisez la liste à partir des exigences des fournisseurs et des opérations légitimes observées. Distinguez les destinations directement nécessaires à l’application de l’infrastructure de support, comme un proxy ou un résolveur. Lorsque les extrémités évoluent, consignez comment la liste d’autorisation sera maintenue. Ne déduisez pas une cartographie complète des dépendances d’une courte capture de paquets et n’approuvez pas automatiquement chaque connexion observée.

Étape 3 : préparer des règles d’autorisation documentées

Créez les exceptions nécessaires avant d’activer le blocage par défaut. Associez à chaque règle un responsable, une finalité, un profil et une décision de revue. Vérifiez que les règles atteignent le pilote par le magasin de stratégies prévu et résolvez les conflits avec les blocages explicites. Examinez la fusion des règles locales pour traiter délibérément les règles installées par les applications et les exceptions créées par les administrateurs.

La règle illustrative suivante utilise les paramètres documentés par New-NetFirewallRule. Le chemin, l’adresse, le port, le domaine et la GPO sont des exemples à remplacer par des valeurs d’inventaire vérifiées ; cette règle ne doit pas être déployée telle quelle :

New-NetFirewallRule -DisplayName "Pilot application to approved service" -Direction Outbound -Action Allow -Profile Domain -Program "C:\Program Files\Example\client.exe" -Protocol TCP -RemoteAddress 192.0.2.10 -RemotePort 443 -PolicyStore "corp.contoso.com\Outbound Pilot"

Une seule exception d’exemple ne constitue pas un inventaire des dépendances applicatives. Ajoutez uniquement les règles justifiées par la charge de travail réelle, y compris ses services de support. Examinez aussi les autorisations existantes larges : le blocage par défaut présente un intérêt limité si une exception générale permet encore les connexions que vous vouliez restreindre.

Étape 4 : modifier uniquement le périmètre choisi du profil Domain

Pour la GPO du pilote d’exemple, les paramètres documentés de Set-NetFirewallProfile permettent d’exprimer l’action par défaut sélectionnée :

Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Block -PolicyStore "corp.contoso.com\Outbound Pilot"

Confirmez que cette GPO ne s’applique qu’à la population sélectionnée avant de la modifier. Conservez le paramètre antérieur et laissez le pare-feu activé. Après l’application de la stratégie, répétez les requêtes ActiveStore sur les profils et les règles des ordinateurs cibles. Une commande de gestion réussie écrit la configuration ; elle ne démontre pas que chaque cible prévue l’a appliquée.

Étape 5 : mesurer les flux et répéter le retour arrière

Testez chaque opération consignée sous le profil Domain actif. Vérifiez le comportement applicatif, la résolution de noms, les recherches de mises à jour, l’accès de gestion et l’accès de récupération. Comparez les échecs au trafic abandonné et aux détails des règles. Lorsqu’une connexion est nécessaire, documentez sa finalité avant d’ajouter ou de corriger l’exception appropriée ; retestez ensuite l’opération initiale.

Définissez un test contrôlé du trafic que la stratégie doit rejeter, avec une destination et une charge de travail de test approuvées. Consignez le résultat attendu et les preuves réelles sur la cible. N’interprétez pas un rejet réussi comme une preuve que toutes les sorties indésirables sont bloquées. Conservez ensemble les relevés des opérations autorisées et rejetées pour que les réviseurs puissent évaluer l’intention de sécurité et la compatibilité.

Si l’action par défaut antérieure consignée pour la GPO d’exemple était Allow, sa commande de retour arrière est :

Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Allow -PolicyStore "corp.contoso.com\Outbound Pilot"

Rétablissez l’état réel de la stratégie précédente lorsqu’il était différent, y compris un paramètre non configuré si nécessaire. Examinez séparément les règles du pilote et les changements de journalisation. Un blocage explicite restant peut toujours empêcher la connectivité après le retour de l’action par défaut à Allow. Revérifiez ActiveStore et répétez l’opération métier en échec avant de déclarer la récupération terminée. N’étendez le pilote que lorsque l’inventaire, les responsabilités, les tests et le relevé du retour arrière justifient la population suivante.

Comment EtcSec détecte cette configuration

L’implémentation Detect() d’etc-collector examinée expose un contrôle pertinent ici : FIREWALL_OUTBOUND_NOT_BLOCKED. Elle initialise un constat de sévérité Low avec Count = 0, puis recherche l’entier collecté FirewallOutboundAction. Si la recherche renvoie nil ou une valeur autre que 1, elle définit Count = 1. Une valeur renvoyée de 1 laisse Count = 0.

Le parseur Registry.pol ne renseigne ce champ qu’à partir d’une clé correspondant à WindowsFirewall et DomainProfile, avec le nom de valeur DefaultOutboundAction. Les valeurs des profils Private et Public sont hors du périmètre de ce contrôle. La fonction auxiliaire pour les entiers recherche d’abord une valeur non nil dans Default Domain Controllers Policy, puis dans Default Domain Policy, puis dans une autre GPO disponible. Son mécanisme de repli parcourt une map Go ; il ne détermine pas la priorité des stratégies Windows.

Ces limites comptent lors de l’examen d’un constat. L’absence d’une valeur GPO collectée déclenche le contrôle sans mesurer l’action par défaut effective ni l’application réelle sur un ordinateur. Count = 1 ne compte pas les extrémités exposées et ne démontre pas un trafic de commande et contrôle. Count = 0 ne valide ni l’activation du pare-feu, ni les règles d’autorisation nécessaires, ni les conflits de blocage explicite, ni les exceptions locales, ni le bon fonctionnement du pilote.

Utilisez ce signal pour démarrer l’analyse ciblée décrite plus haut. Joignez à la revue le profil actif de la cible, les règles effectives, les tests applicatifs et les preuves de retour arrière. Décidez si le blocage par défaut convient à cette population, puis répondez à la question de configuration à partir des preuves obtenues plutôt que de la seule recherche agrégée dans les GPO.