Durcir le pare-feu Windows contre le mouvement latéral

Chaque version prise en charge de Windows embarque un pare-feu hôte à états tout à fait capable. Dans beaucoup d'environnements, il est soit désactivé (« le pare-feu réseau s'en occupe »), soit laissé dans son état par défaut, où les programmes d'installation et les administrateurs locaux ajoutent librement des règles entrantes. Bien utilisé, c'est l'un des contrôles les moins coûteux et les plus efficaces contre le mouvement latéral : la technique qui transforme un portable compromis en réseau compromis.

Ce guide construit une stratégie pour les postes de travail et les serveurs avec la stratégie de groupe (les mêmes paramètres existent dans Intune sous Endpoint security > Firewall).

Principes

1. Les trois profils actifs (Domaine, Privé, Public), imposés par stratégie.
2. Entrant par défaut : bloqué. Seul le trafic explicitement autorisé entre.
3. Seules les règles centrales comptent. La fusion des règles locales est désactivée.
4. Les protocoles d'administration ne viennent que des réseaux d'administration. RDP, WinRM, SMB, RPC et WMI sont joignables depuis les serveurs de rebond et les PAW, pas depuis n'importe quel autre client.
5. Journaliser les paquets rejetés, dimensionner le journal et le collecter.

Étape 1 : paramètres des profils

Chemin GPO : Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Ouvrez les propriétés et définissez, pour chacun des profils Domaine, Privé et Public :

L'équivalent PowerShell, pratique pour tester sur une seule machine :

Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True `
  -DefaultInboundAction Block -DefaultOutboundAction Allow `
  -NotifyOnListen False -AllowLocalFirewallRules False `
  -LogBlocked True -LogMaxSizeKilobytes 16384 `
  -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log"

Vérifiez l'état effectif (le résultat fusionné des paramètres locaux et de stratégie de groupe) :

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

Avec AllowLocalFirewallRules à False, les règles créées localement par les programmes d'installation sont ignorées. C'est voulu, et c'est pourquoi il faut inventorier les règles entrantes dont vos applications ont réellement besoin (étape 3) avant le déploiement.

Étape 2 : règles des postes de travail

Les postes de travail ont besoin de très peu de trafic entrant. Une liste d'autorisations réaliste :

Tout le reste, notamment SMB, RPC et WinRM depuis d'autres postes de travail, reste bloqué. Cette seule décision stoppe l'essentiel des sauts « de portable en portable » pratiqués par les affiliés ransomware.

Les règles restreintes ressemblent à ceci (dans une GPO, c'est la même chose via l'onglet Scope) :

New-NetFirewallRule -DisplayName "RDP from Tier2 admin subnet" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress 10.20.50.0/24 -Action Allow -Profile Domain

New-NetFirewallRule -DisplayName "SMB from management servers" -Direction Inbound `
  -Protocol TCP -LocalPort 445 -RemoteAddress 10.20.10.11,10.20.10.12 -Action Allow -Profile Domain

Méfiez-vous des groupes de règles prédéfinis comme Remote Desktop, File and Printer Sharing ou Windows Remote Management : activer le groupe active des règles dont l'étendue distante est Any. Modifiez leur étendue dans la GPO ou créez plutôt vos propres règles restreintes.

Étape 3 : règles des serveurs

Les serveurs ont besoin de règles entrantes pour le service qu'ils rendent, plus une administration restreinte :

• Ports applicatifs (HTTPS 443 sur un serveur web, 1433 sur SQL Server) limités aux clients ou aux répartiteurs de charge qui les utilisent, et pas « Any » si vous pouvez l'éviter.
• Ports d'administration limités aux serveurs de rebond Tier 1 ou aux PAW.
• Sur les contrôleurs de domaine, l'ensemble des ports AD (Kerberos 88, LDAP 389/636, GC 3268/3269, DNS 53, SMB 445, RPC 135 et la plage dynamique) doit rester joignable par tous les membres du domaine ; restreignez les protocoles d'administration (RDP, WinRM) aux hôtes d'administration Tier 0.

Avant d'appliquer, inventoriez ce qui écoute réellement et qui se connecte :

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
  Sort-Object LocalPort -Unique

Croisez cela avec quelques jours de pfirewall.log, journalisation des connexions réussies activée, pour que les règles collent à la réalité plutôt qu'à la documentation.

Sortant sur les serveurs. La plupart des serveurs n'ont besoin de parler qu'à un ensemble connu de destinations : DNS, contrôleurs de domaine, serveurs de mises à jour, leur base de données. Un refus par défaut en sortie, en particulier sur les serveurs Tier 0, complique fortement le command-and-control et l'exfiltration de données. Commencez par log successful connections pour construire la liste, puis passez l'action sortante par défaut à Block avec des règles d'autorisation.

Étape 4 : bloquer les abus habituels

Quelques règles supplémentaires à envisager :

• Bloquer entièrement l'entrant sur le profil Public des portables (le blocage par défaut le fait si vous n'ajoutez aucune règle d'autorisation Public).
• Bloquer le SMB sortant (TCP 445) vers Internet au niveau de l'hôte ; il n'a aucune raison légitime d'exister et cela empêche les fuites d'identifiants via une authentification forcée vers des hôtes externes.
• Empêcher mshta.exe, wscript.exe, cscript.exe et les hôtes de scripts similaires d'établir des connexions sortantes là où ils ne sont pas utilisés. Le contrôle des applications est la vraie solution, mais ceci ne coûte presque rien.

New-NetFirewallRule -DisplayName "Block outbound SMB to Internet" -Direction Outbound `
  -Protocol TCP -RemotePort 445 -RemoteAddress Internet -Action Block

Internet est un mot-clé intégré qui exclut le sous-réseau local et les plages privées définies comme intranet ; vérifiez qu'il correspond à votre adressage, ou listez explicitement vos plages internes avec une règle d'autorisation.

Étape 5 : journalisation et surveillance

pfirewall.log est un journal texte brut présent sur chaque hôte. Il est utile en investigation mais rarement collecté. Options :

• Le collecter avec votre agent de journaux.
• Ou activer l'audit de la plateforme de filtrage Windows (Advanced Audit Policy > Object Access > Filtering Platform Connection, échecs uniquement), qui produit des événements de sécurité 5157 pour les connexions bloquées. C'est très bruyant avec l'audit des succès : commencez par les échecs et filtrez au niveau du collecteur.
• Surveillez toujours les modifications de configuration du pare-feu : événements de sécurité 4946 à 4948 (règle ajoutée, modifiée, supprimée) et 4950 (paramètre modifié), issus de Audit MPSSVC Rule-Level Policy Change.

Un attaquant qui désactive le pare-feu ou ajoute une règle d'autorisation pour son outil laisse précisément ces événements.

Liste de contrôle

• Pare-feu actif sur tous les profils, imposé par GPO ou Intune
• Entrant bloqué par défaut ; fusion des règles locales désactivée
• Les postes n'acceptent RDP/WinRM/SMB/RPC que depuis les hôtes d'administration et de gestion
• Groupes de règles prédéfinis remplacés ou restreints
• Règles serveurs construites à partir des ports en écoute et des connexions observées
• Serveurs Tier 0 en refus par défaut en sortie
• Paquets rejetés journalisés ; alertes sur les événements de modification de règles 4946-4950

Les pare-feu hôtes complètent le tiering de l'administration : le tiering empêche les identifiants privilégiés d'atteindre les postes de travail, et le pare-feu empêche les postes de servir de tremplin même quand un identifiant finit par fuiter.