Isolation de domaine et de serveurs avec IPsec

Les règles de pare-feu fondées sur les adresses IP répondent à la question « d'où vient ce paquet ? ». Les attaquants savent très bien arriver du bon endroit : un poste compromis dans le bon sous-réseau, ou un portable branché sur une prise de salle de réunion. Les règles de sécurité de connexion IPsec ajoutent une question plus forte : « quel ordinateur, ou quel utilisateur, authentifié se trouve à l'autre bout ? »

Avec l'isolation de domaine, les membres du domaine n'acceptent le trafic entrant que depuis d'autres membres du domaine authentifiés. Avec l'isolation de serveurs, un serveur sensible n'accepte le trafic que de certains ordinateurs ou utilisateurs, identifiés par Kerberos, quelle que soit leur adresse IP. Les deux reposent sur les mêmes composants du pare-feu Windows que vous gérez déjà via la stratégie de groupe à grande échelle, et prolongent les principes de restriction du guide pilier sur le durcissement du pare-feu Windows.

C'est un contrôle avancé. Il modifie la façon dont chaque connexion s'établit : le déploiement compte autant que la configuration.

Les briques de base

Les règles de sécurité de connexion n'autorisent aucun trafic à elles seules. Elles garantissent que le trafic est authentifié ; ce sont ensuite les règles de pare-feu qui décident si le trafic authentifié de ce pair est autorisé.

Étape 1 : définir les paramètres IPsec par défaut

Chemin GPO : Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security, propriétés, onglet IPsec Settings, Customize :

En PowerShell, les jeux de chiffrement sont des objets distincts référencés par les règles :

$mm = New-NetIPsecMainModeCryptoProposal -Encryption AES256 -Hash SHA256 -KeyExchange DH19
New-NetIPsecMainModeCryptoSet -Name 'MM-Strong' -DisplayName 'MM-Strong' -Proposal $mm -PolicyStore 'corp.example.com\FW-IPsec'

$qm = New-NetIPsecQuickModeCryptoProposal -Encapsulation ESP -ESPHash SHA256
New-NetIPsecQuickModeCryptoSet -Name 'QM-Integrity' -DisplayName 'QM-Integrity' -Proposal $qm -PolicyStore 'corp.example.com\FW-IPsec'

$auth = New-NetIPsecAuthProposal -Machine -Kerberos
New-NetIPsecPhase1AuthSet -Name 'P1-ComputerKerberos' -DisplayName 'P1-ComputerKerberos' -Proposal $auth -PolicyStore 'corp.example.com\FW-IPsec'

Les règles référencent ces jeux par leur Name et non par leur nom d'affichage, d'où le -Name explicite pour chaque jeu ; sans lui, Windows génère un GUID et la règle ci-dessous ne trouve pas le jeu.

Étape 2 : isolation de domaine en mode demande

Créez une règle de sécurité de connexion de type Isolation dans une nouvelle GPO liée à une UO pilote :

• Requirements : Request authentication for inbound and outbound connections.
• Authentication method : Computer (Kerberos V5).
• Profile : Domain.

New-NetIPsecRule -DisplayName 'Domain isolation' -InboundSecurity Request -OutboundSecurity Request `
  -Phase1AuthSet 'P1-ComputerKerberos' -Profile Domain -PolicyStore 'corp.example.com\FW-IPsec'

Le mode demande ne bloque jamais rien. Les membres du domaine qui ont tous deux la règle négocient des associations de sécurité ; tout le reste retombe en trafic en clair. Cette phase vous montre quels pairs savent s'authentifier et lesquels non, sans interruption de service.

Ajoutez des exemptions d'authentification pour l'infrastructure qui ne peut pas ou ne doit pas négocier IPsec :

• Contrôleurs de domaine, pour que les clients puissent obtenir les tickets Kerberos dont IPsec a lui-même besoin. Laissez les DC en mode demande plutôt qu'en mode exigé.
• Serveurs DHCP et DNS s'ils ne sont pas des DC.
• Équipements réseau, imprimantes, IoT et systèmes non Windows qui communiquent avec les membres du domaine.

Gardez la liste d'exemptions courte, documentée et fondée sur des adresses que vous maîtrisez ; chaque exemption est un trou dans le modèle.

Étape 3 : exiger l'authentification entrante

Une fois que la surveillance montre que la quasi-totalité du trafic du domaine est protégée (voir la section surveillance plus bas), basculez d'abord les serveurs, puis les postes, en Require inbound and request outbound. Les appareils sans identité de domaine ne peuvent plus leur ouvrir de connexion. Le sortant reste en request pour que les membres du domaine puissent encore joindre les systèmes exemptés et non Windows.

Évitez Require inbound and outbound, sauf pour des groupes de serveurs étroitement contrôlés : cela casse toute connexion sortante vers un pair incapable de négocier IPsec.

Étape 4 : isolation de serveurs pour les systèmes sensibles

Pour un serveur sensible, comme une base de données financière ou un serveur d'administration Tier 0, créez des règles de pare-feu entrantes qui n'acceptent que le trafic authentifié provenant d'ordinateurs autorisés :

1. Créez un groupe de sécurité d'ordinateurs, par exemple IPsec-FinanceDB-Clients, contenant les serveurs d'applications autorisés à se connecter.
2. Sur le serveur, créez une règle d'autorisation entrante pour le port du service avec Allow the connection if it is secure et, dans l'onglet Remote Computers, n'autorisez que ce groupe. Ajoutez éventuellement Remote Users pour une autorisation au niveau utilisateur (cela nécessite une seconde authentification avec Kerberos utilisateur).
3. Supprimez toute autre règle d'autorisation pour ce port.

$sid = (Get-ADGroup 'IPsec-FinanceDB-Clients').SID.Value
New-NetFirewallRule -DisplayName 'SQL 1433 - authorised computers only' -Direction Inbound `
  -Protocol TCP -LocalPort 1433 -Action Allow -Authentication Required `
  -RemoteMachine "D:(A;;CC;;;$sid)" -Profile Domain -PolicyStore 'corp.example.com\FW-FinanceDB'

Ajoutez -Encryption Required lorsque le protocole ne chiffre pas déjà. L'appartenance aux groupes d'ordinateurs est transportée dans le ticket Kerberos : l'ajout d'un ordinateur au groupe ne prend effet qu'après le renouvellement du ticket de cet ordinateur (un redémarrage ou klist purge -li 0x3e7).

Le même schéma fournit un accès d'administration fondé sur l'identité : RDP et WinRM sur les serveurs Tier 0 acceptés uniquement depuis les ordinateurs d'un groupe Tier0-PAW, ce qui s'aligne sur le tiering de l'administration et le modèle de tiers.

Ce qu'IPsec arrête et n'arrête pas

L'isolation IPsec rend un appareil non géré présent sur le réseau largement inutile pour atteindre les membres du domaine, et rend inefficaces l'usurpation d'adresse IP et les relais réseau simples contre les serveurs isolés. Elle complète, sans la remplacer, le durcissement des protocoles comme la signature SMB et les restrictions NTLM du guide sur les protocoles hérités : un attaquant qui contrôle un ordinateur joint au domaine s'authentifie en tant que cet ordinateur. L'isolation de serveurs limite les ordinateurs du domaine qui sont éligibles ; les protections contre le NTLM relay restent nécessaires.

Ce qui casse

• Répartiteurs de charge et NAT entre clients et serveurs : le mode transport IPsec est négocié de bout en bout, donc un répartiteur de charge qui termine ou réécrit les connexions casse l'authentification. Exemptez la VIP ou protégez uniquement le trafic derrière le répartiteur.
• Supervision réseau et IDS perdent la visibilité sur les données utiles quand vous exigez le chiffrement. ESP en intégrité seule garde les paquets lisibles.
• Systèmes hors domaine et d'autres forêts : ils ont besoin de certificats ou d'exemptions.
• Les problèmes Kerberos deviennent des problèmes de connectivité : décalage d'horloge, SPN cassés ou DC injoignables se traduisent désormais par des connexions échouées.
• Performances : la surcharge CPU est faible sur du matériel moderne avec déchargement sur la carte réseau, mais testez les serveurs à fort débit.
• Dépannage : plus difficile pour des équipes peu habituées à IPsec. Formez les équipes réseau et serveurs avant d'imposer.

Surveiller les associations de sécurité

Activez l'audit IPsec sous Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff : Audit IPsec Main Mode et Audit IPsec Quick Mode (échecs au minimum), plus System > Audit IPsec Driver. Événements utiles du journal Sécurité :

Une hausse des 4653 après le passage en mode exigé désigne des pairs sans identité valide : précisément les appareils à exempter ou à corriger. Les événements de succès sont très volumineux ; collectez les échecs centralement et échantillonnez les succès.

Vérifier

Sur un serveur concerné :

Get-NetIPsecRule -PolicyStore ActiveStore | Select-Object DisplayName, InboundSecurity, OutboundSecurity, Enabled
Get-NetIPsecMainModeSA | Select-Object RemoteEndpoint, LocalFirstId, RemoteFirstId
Get-NetIPsecQuickModeSA | Select-Object RemoteEndpoint, RemotePort, LocalPort

RemoteFirstId indique l'identité d'ordinateur authentifiée de chaque pair. Dans wf.msc > Monitoring > Security Associations, vous voyez les mêmes données sous forme graphique. Testez ensuite en négatif : depuis un portable hors domaine sur le même sous-réseau, Test-NetConnection <server> -Port 445 doit échouer dès que le serveur exige l'authentification entrante, tandis qu'un membre du domaine appartenant au groupe autorisé se connecte toujours.

Liste de contrôle

• Paramètres IPsec par défaut définis : pas de SHA-1 ni de DH Group 2, ICMP exempté
• Règle d'isolation de domaine déployée en mode demande sur un pilote, puis largement
• DC, DHCP, DNS et infrastructure non Windows exemptés et documentés
• Serveurs passés en entrant exigé, sortant demandé, après mesure de la couverture des SA
• Serveurs sensibles limités à des groupes d'ordinateurs autorisés avec « autoriser si sécurisé »
• Chiffrement exigé uniquement là où le protocole ne se protège pas lui-même
• Échecs des modes principal et rapide IPsec audités et transférés

Voir la thématique Pare-feu Windows pour la série complète, y compris la journalisation et la gestion des stratégies.