Partager via

Gérer le Pare-feu Windows avec la ligne de commande

Cet article fournit des exemples de gestion du Pare-feu Windows avec PowerShell et netsh.exe, qui peuvent être utilisés pour automatiser la gestion du Pare-feu Windows.

Définir les valeurs par défaut globales du profil

Les valeurs par défaut globales définissent le comportement de l’appareil par profil. Le Pare-feu Windows prend en charge les profils de domaine, privés et publics.

Le Pare-feu Windows supprime le trafic qui ne correspond pas au trafic non sollicité autorisé, ou le trafic envoyé en réponse à une demande de l’appareil. Si vous constatez que les règles que vous créez ne sont pas appliquées, vous devrez peut-être activer le Pare-feu Windows. Voici comment activer le Pare-feu Windows sur un appareil local :

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

Contrôler le comportement du Pare-feu Windows

Les paramètres globaux par défaut peuvent être définis via l’interface de ligne de commande. Ces modifications sont également disponibles via la console du Pare-feu Windows. Les scripts suivants définissent les actions entrantes et sortantes par défaut, spécifient les connexions réseau protégées et interdisent l’affichage des notifications à l’utilisateur lorsqu’un programme est bloqué pour recevoir des connexions entrantes. Il autorise la réponse en monodiffusion au trafic réseau de multidiffusion ou de diffusion, et spécifie les paramètres de journalisation pour la résolution des problèmes.

Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow -NotifyOnListen False -AllowUnicastResponseToMulticast True -LogFileName %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log

Désactiver le Pare-feu Windows

Microsoft recommande de ne pas désactiver le Pare-feu Windows, car vous perdez d’autres avantages, tels que la possibilité d’utiliser les règles de sécurité de connexion IPsec (Internet Protocol Security), la protection réseau contre les attaques qui utilisent l’empreinte digitale réseau, le renforcement du service Windows et les filtres de temps de démarrage. Les logiciels de pare-feu non-Microsoft peuvent désactiver par programme uniquement les types de règles du Pare-feu Windows qui doivent être désactivés pour la compatibilité. Vous ne devez pas désactiver le pare-feu vous-même à cet effet. Si la désactivation du Pare-feu Windows est requise, ne le désactivez pas en arrêtant le service Pare-feu Windows (dans le composant logiciel enfichable Services, le nom complet est Pare-feu Windows Defender et le nom du service est MpsSvc). L’arrêt du service Pare-feu Windows n’est pas pris en charge par Microsoft et peut entraîner des problèmes, notamment :

  • Le menu Démarrer peut cesser de fonctionner
  • L’installation ou la mise à jour des applications modernes peuvent échouer
  • Échec de l’activation de Windows par téléphone
  • Incompatibilités d’application ou de système d’exploitation qui dépendent du Pare-feu Windows

La méthode appropriée pour désactiver le Pare-feu Windows consiste à désactiver les profils de pare-feu Windows et à laisser le service en cours d’exécution. Utilisez la procédure suivante pour désactiver le pare-feu ou désactiver le paramètre stratégie de groupe Configuration de l’ordinateur |Modèles d’administration |Réseau|Connections réseau |Pare-feu Windows |Domaine Prolfile|Pare-feu Windows : protégez toutes les connexions réseau. Pour plus d’informations, consultez Guide de déploiement du Pare-feu Windows. L’exemple suivant désactive le Pare-feu Windows pour tous les profils.

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

Déployer des règles de pare-feu de base

Cette section fournit des exemples de scriptlet pour la création, la modification et la suppression de règles de pare-feu.

Créer des règles de pare-feu

L’ajout d’une règle de pare-feu dans Windows PowerShell ressemble beaucoup à celui de Netsh, mais les paramètres et les valeurs sont spécifiés différemment. Voici un exemple montrant comment autoriser l’application Telnet à écouter sur le réseau. Cette règle de pare-feu est limitée au sous-réseau local à l’aide d’un mot clé au lieu d’une adresse IP. Tout comme dans Netsh, la règle est créée sur l’appareil local et prend effet immédiatement.

New-NetFirewallRule -DisplayName "Allow Inbound Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow

Le scriptlet suivant montre comment ajouter une règle de pare-feu de base qui bloque le trafic sortant d’une application et d’un port local spécifiques vers un objet stratégie de groupe (GPO) dans Active Directory. Dans Windows PowerShell, le magasin de stratégies est spécifié en tant que paramètre dans l’applet de commande New-NetFirewall. Dans Netsh, vous devez d’abord spécifier l’objet de stratégie de groupe que les commandes d’une session Netsh doivent modifier. Les commandes que vous entrez sont exécutées sur le contenu de l’objet de stratégie de groupe, et l’exécution reste effective jusqu’à la fin de la session Netsh ou jusqu’à ce qu’une autre commande set store soit exécutée. Ici, domain.contoso.com est le nom de votre services de domaine Active Directory (AD DS) et gpo_name est le nom de l’objet de stratégie de groupe que vous souhaitez modifier. Des guillemets sont requis s’il existe des espaces dans le nom de l’objet de stratégie de groupe.

New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -LocalPort 23 -Action Block -PolicyStore domain.contoso.com\gpo_name

Mise en cache des objets de stratégie de groupe

Pour réduire la charge sur les contrôleurs de domaine occupés, Windows PowerShell vous permet de charger un objet de stratégie de groupe dans votre session locale, d’apporter toutes vos modifications dans cette session, puis de l’enregistrer une fois. La commande suivante effectue les mêmes actions que l’exemple précédent (en ajoutant une règle Telnet à un objet de stratégie de groupe), mais nous le faisons en appliquant la mise en cache des objets de stratégie de groupe dans PowerShell. La modification de l’objet de stratégie de groupe en le chargeant sur votre session locale et en utilisant le paramètre -GPOSession ne sont pas pris en charge dans Netsh

$gpo = Open-NetGPO -PolicyStore domain.contoso.com\gpo_name
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\telnet.exe -Protocol TCP -LocalPort 23 -Action Block -GPOSession $gpo
Save-NetGPO -GPOSession $gpo

Cette commande ne traite pas vos modifications individuelles, elle charge et enregistre l’ensemble de l’objet de stratégie de groupe à la fois. Par conséquent, si d’autres modifications sont apportées par d’autres administrateurs ou dans une autre fenêtre Windows PowerShell, l’enregistrement de l’objet de stratégie de groupe remplace ces modifications.

Modifier une règle de pare-feu existante

Lorsqu’une règle est créée, Netsh et Windows PowerShell vous permettent de modifier les propriétés et l’influence de la règle, mais la règle conserve son identificateur unique (dans Windows PowerShell, cet identificateur est spécifié avec le paramètre -Name). Par exemple, vous pouvez avoir une règle Autoriser le web 80 qui active le port TCP 80 pour le trafic entrant non sollicité. Vous pouvez modifier la règle pour qu’elle corresponde à une adresse IP distante différente d’un serveur Web dont le trafic sera autorisé en spécifiant le nom localisé et lisible par l’utilisateur de la règle.

Set-NetFirewallRule -DisplayName "Allow Web 80" -RemoteAddress 192.168.0.2

Netsh vous oblige à fournir le nom de la règle pour qu’elle soit modifiée et nous n’avons pas d’autre moyen d’obtenir la règle de pare-feu. Dans Windows PowerShell, vous pouvez interroger la règle à l’aide de ses propriétés connues. Lorsque vous exécutez Get-NetFirewallRule, vous pouvez remarquer que les conditions courantes telles que les adresses et les ports n’apparaissent pas. Ces conditions sont représentées dans des objets distincts appelés Filtres. Comme indiqué précédemment, vous pouvez définir toutes les conditions dans New-NetFirewallRule et Set-NetFirewallRule. Si vous souhaitez interroger des règles de pare-feu basées sur ces champs (ports, adresses, sécurité, interfaces, services), vous devez obtenir les objets de filtre eux-mêmes. Vous pouvez modifier le point de terminaison distant de la règle Autoriser le web 80 (comme cela a été fait précédemment) à l’aide d’objets de filtre. À l’aide de Windows PowerShell, vous interrogez par port à l’aide du filtre de port, puis en supposant que d’autres règles affectent le port local, vous générez avec d’autres requêtes jusqu’à ce que la règle souhaitée soit récupérée. Dans l’exemple suivant, nous supposons que la requête retourne une seule règle de pare-feu, qui est ensuite redirigée vers l’applet de commande en utilisant la Set-NetFirewallRule capacité de Windows PowerShell à pipeliner les entrées.

Get-NetFirewallPortFilter | ?{$_.LocalPort -eq 80} | Get-NetFirewallRule | ?{ $_.Direction -eq "Inbound" -and $_.Action -eq "Allow"} | Set-NetFirewallRule -RemoteAddress 192.168.0.2

Vous pouvez également rechercher des règles à l’aide du caractère générique. L’exemple suivant retourne un tableau de règles de pare-feu associées à un programme particulier. Les éléments du tableau peuvent être modifiés dans les applets de commande suivantes Set-NetFirewallRule .

Get-NetFirewallApplicationFilter -Program "*svchost*" | Get-NetFirewallRule

Plusieurs règles d’un groupe peuvent être modifiées simultanément lorsque le nom de groupe associé est spécifié dans une commande Set. Vous pouvez ajouter des règles de pare-feu à des groupes d’administration spécifiés afin de gérer plusieurs règles qui partagent les mêmes influences. Dans l’exemple suivant, nous ajoutons des règles de pare-feu Telnet entrantes et sortantes au groupe Gestion Telnet. Dans Windows PowerShell, l’appartenance au groupe est spécifiée lorsque les règles sont créées pour la première fois. Nous recréons donc les exemples de règles précédents. L’ajout de règles à un groupe de règles personnalisé n’est pas possible dans Netsh.

New-NetFirewallRule -DisplayName "Allow Inbound Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow -Group "Telnet Management"
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program %SystemRoot%\System32\tlntsvr.exe -RemoteAddress LocalSubnet -Action Allow -Group "Telnet Management"

Si le groupe n’est pas spécifié au moment de la création de la règle, la règle peut être ajoutée au groupe de règles à l’aide de la notation par points dans Windows PowerShell. Vous ne pouvez pas spécifier le groupe à l’aide Set-NetFirewallRule de, car la commande autorise l’interrogation par groupe de règles.

$rule = Get-NetFirewallRule -DisplayName "Allow Inbound Telnet"
$rule.Group = "Telnet Management"
$rule | Set-NetFirewallRule

À l’aide de la Set commande, si le nom du groupe de règles est spécifié, l’appartenance au groupe n’est pas modifiée, mais toutes les règles du groupe reçoivent les mêmes modifications indiquées par les paramètres donnés. Le scriptlet suivant active toutes les règles d’un groupe prédéfini contenant la gestion à distance qui influencent les règles de pare-feu.

Set-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Enabled True

Il existe également une applet de commande distincte Enable-NetFirewallRule pour l’activation des règles par groupe ou par d’autres propriétés de la règle.

Enable-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Verbose

Supprimer une règle de pare-feu

Les objets de règle peuvent être désactivés afin qu’ils ne soient plus actifs. Dans Windows PowerShell, l’applet de commande Disable-NetFirewallRule laisse la règle sur le système, mais la place dans un état désactivé afin que la règle ne soit plus appliquée et ait un impact sur le trafic. Une règle de pare-feu désactivée peut être réactivée par Enable-NetFirewallRule. Cette applet de commande est différente de la méthode Remove-NetFirewallRule, qui supprime définitivement la définition de règle de l’appareil. L’applet de commande suivante supprime la règle de pare-feu existante spécifiée du magasin de stratégies local.

Remove-NetFirewallRule -DisplayName "Allow Web 80"

Comme avec d’autres applets de commande, vous pouvez également rechercher des règles à supprimer. Ici, toutes les règles de pare-feu bloquantes sont supprimées de l’appareil.

Remove-NetFirewallRule -Action Block

Il peut être plus sûr d’interroger les règles avec la commande Get et de l’enregistrer dans une variable, d’observer les règles à affecter, puis de les diriger vers la commande Remove , comme nous l’avons fait pour les commandes Set . L’exemple suivant montre comment afficher toutes les règles de pare-feu bloquantes, puis supprimer les quatre premières règles.

$x = Get-NetFirewallRule -Action Block
$x
$x[0-3] | Remove-NetFirewallRule

Gérer à distance

La gestion à distance à l’aide de WinRM est activée par défaut. Les applets de commande qui prennent en charge le paramètre CimSession utilisent WinRM et peuvent être gérées à distance par défaut. L’exemple suivant retourne toutes les règles de pare-feu du magasin persistant sur un appareil nommé RemoteDevice.

Get-NetFirewallRule -CimSession RemoteDevice

Nous pouvons effectuer des modifications ou afficher des règles sur des appareils distants à l’aide du paramètre -CimSession . Ici, nous supprimons une règle de pare-feu spécifique d’un appareil distant.

$RemoteSession = New-CimSession -ComputerName RemoteDevice
Remove-NetFirewallRule -DisplayName "AllowWeb80" -CimSession $RemoteSession -Confirm

Déployer des paramètres de règle IPsec de base

Une stratégie de sécurité du protocole Internet (IPsec) se compose de règles qui déterminent le comportement IPsec. IPsec prend en charge l’authentification homologue au niveau du réseau, l’authentification de l’origine des données, l’intégrité des données, la confidentialité des données (chiffrement) et la protection par relecture. Windows PowerShell pouvez créer des stratégies IPsec puissantes et complexes, comme dans Netsh et la console du Pare-feu Windows. Toutefois, étant donné que Windows PowerShell est basée sur des objets plutôt que sur des jetons de chaîne, la configuration dans Windows PowerShell offre plus de contrôle et de flexibilité. Dans Netsh, les jeux d’authentification et de chiffrement ont été spécifiés sous la forme d’une liste de jetons séparés par des virgules dans un format spécifique. Dans Windows PowerShell, au lieu d’utiliser les paramètres par défaut, vous devez d’abord créer les objets d’authentification ou de proposition de chiffrement souhaités et les regrouper dans des listes dans l’ordre de votre choix. Ensuite, vous créez une ou plusieurs règles IPsec qui référencent ces jeux. L’avantage de ce modèle est que l’accès par programmation aux informations contenues dans les règles est beaucoup plus facile. Consultez les sections suivantes pour clarifier des exemples. modèle objet pour la création d’une seule règle ipsec.

Créer des règles IPsec

L’applet de commande suivante crée une règle de mode de transport IPsec de base dans un objet stratégie de groupe. Une règle IPsec est simple à créer . tout ce qui est requis est le nom d’affichage, et les propriétés restantes utilisent les valeurs par défaut. Le trafic entrant est authentifié et l’intégrité est vérifiée à l’aide du mode rapide par défaut et des paramètres du mode main. Ces paramètres par défaut se trouvent dans la console sous Personnaliser les paramètres par défaut IPsec.

New-NetIPsecRule -DisplayName "Require Inbound Authentication" -PolicyStore domain.contoso.com\gpo_name

Ajouter des méthodes d’authentification personnalisées à une règle IPsec

Si vous souhaitez créer un ensemble personnalisé de propositions en mode rapide qui inclut à la fois AH et ESP dans un objet de règle IPsec, vous créez les objets associés séparément et liez leurs associations. Pour plus d’informations sur les méthodes d’authentification, consultez Choix du protocole IPsec. Vous pouvez ensuite utiliser les stratégies de mode rapide personnalisées nouvellement créées lorsque vous créez des règles IPsec. L’objet de jeu de chiffrement est lié à un objet de règle IPsec. objet de jeu de chiffrement. Dans cet exemple, nous nous appuyons sur la règle IPsec créée précédemment en spécifiant un jeu de chiffrement personnalisé en mode rapide. La règle IPsec finale exige que le trafic sortant soit authentifié par la méthode de chiffrement spécifiée.

$AHandESPQM = New-NetIPsecQuickModeCryptoProposal -Encapsulation AH,ESP -AHHash SHA1 -ESPHash SHA1 -Encryption DES3
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "ah:sha1+esp:sha1-des3" -Proposal $AHandESPQM -PolicyStore domain.contoso.com\gpo_name
New-NetIPsecRule -DisplayName "Require Inbound Authentication" -InboundSecurity Require -OutboundSecurity Request -QuickModeCryptoSet $QMCryptoSet.Name -PolicyStore domain.contoso.com\gpo_name

Règles de transport IPsec IKEv2

Un réseau d’entreprise peut avoir besoin de sécuriser les communications avec une autre agence. Toutefois, vous découvrez que l’agence exécute des systèmes d’exploitation non-Windows et nécessite l’utilisation de la norme Internet Key Exchange version 2 (IKEv2). Vous pouvez appliquer des fonctionnalités IKEv2 dans Windows Server 2012 en spécifiant IKEv2 comme module clé dans une règle IPsec. Cette spécification de fonctionnalité ne peut être effectuée qu’à l’aide de l’authentification par certificat d’ordinateur et ne peut pas être utilisée avec l’authentification de phase 2.

New-NetIPsecRule -DisplayName "Require Inbound Authentication" -InboundSecurity Require -OutboundSecurity Request -Phase1AuthSet MyCertAuthSet -KeyModule IKEv2 -RemoteAddress $nonWindowsGateway

Pour plus d’informations sur IKEv2, y compris les scénarios, consultez Sécurisation des Connections IPsec de bout en bout à l’aide d’IKEv2.

Copier une règle IPsec d’une stratégie vers une autre

Les règles de pare-feu et IPsec avec les mêmes propriétés de règle peuvent être dupliquées pour simplifier la tâche de les recréer dans différents magasins de stratégies. Pour copier la règle créée précédemment d’un magasin de stratégies vers un autre, les objets associés doivent également être copiés séparément. Il n’est pas nécessaire de copier les filtres de pare-feu associés. Vous pouvez interroger des règles à copier de la même façon que d’autres applets de commande. La copie de règles individuelles est une tâche qui n’est pas possible via l’interface Netsh. Voici comment vous pouvez le faire avec Windows PowerShell.

$Rule = Get-NetIPsecRule -DisplayName "Require Inbound Authentication"
$Rule | Copy-NetIPsecRule -NewPolicyStore domain.costoso.com\new_gpo_name
$Rule | Copy-NetPhase1AuthSet -NewPolicyStore domain.costoso.com\new_gpo_name

Gestion des erreurs Windows PowerShell

Pour gérer les erreurs dans vos scripts Windows PowerShell, vous pouvez utiliser le paramètre -ErrorAction. Ce paramètre est particulièrement utile avec les applets de commande Remove . Si vous souhaitez supprimer une règle particulière, vous remarquerez qu’elle échoue si la règle est introuvable. Lorsque des règles sont supprimées, si la règle n’est pas déjà présente, il est acceptable d’ignorer cette erreur. Dans ce cas, vous pouvez effectuer les opérations suivantes pour supprimer les erreurs « règle introuvable » pendant l’opération de suppression.

Remove-NetFirewallRule -DisplayName "Contoso Messenger 98" -ErrorAction SilentlyContinue

L’utilisation de caractères génériques peut également supprimer des erreurs, mais elles peuvent potentiellement correspondre à des règles que vous n’avez pas l’intention de supprimer. Ces caractères génériques peuvent être un raccourci utile, mais ne doivent être utilisés que si vous savez qu’il n’y a pas de règles supplémentaires qui seront supprimées accidentellement. Par conséquent, l’applet de commande suivante supprime également la règle, en supprimant toutes les erreurs « introuvables ».

Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*"

Lorsque vous utilisez des caractères génériques, si vous souhaitez doublement case activée l’ensemble de règles correspondant, vous pouvez utiliser le paramètre -WhatIf.

Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -WhatIf

Si vous souhaitez uniquement supprimer certaines des règles correspondantes, vous pouvez utiliser le paramètre -Confirm pour obtenir une invite de confirmation règle par règle.

Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -Confirm

Vous pouvez également simplement effectuer l’ensemble de l’opération, en affichant le nom de chaque règle au fur et à mesure de l’exécution de l’opération.

Remove-NetFirewallRule -DisplayName "Contoso Messenger 98*" -Verbose

Écran

Les commandes Windows PowerShell suivantes sont utiles dans le cycle de mise à jour d’une phase de déploiement. Pour vous permettre d’afficher toutes les règles IPsec dans un magasin particulier, vous pouvez utiliser les commandes suivantes. Dans Netsh, cette commande n’affiche pas les règles où profile=domain,public ou profile=domain,private. Il affiche uniquement les règles qui ont le domaine d’entrée unique inclus dans la règle. Les exemples de commandes suivants affichent les règles IPsec dans tous les profils.

Show-NetIPsecRule -PolicyStore ActiveStore

Vous pouvez surveiller les associations de sécurité en mode main pour obtenir des informations telles que les pairs actuellement connectés à l’appareil et la suite de protection utilisée pour former les associations de sécurité. Utilisez l’applet de commande suivante pour afficher les règles de mode main existantes et leurs associations de sécurité :

Get-NetIPsecMainModeSA

Rechercher l’objet de stratégie de groupe source d’une règle

Pour afficher les propriétés d’une règle ou d’un groupe de règles particulier, vous devez interroger la règle. Lorsqu’une requête retourne des champs spécifiés comme NotConfigured, vous pouvez déterminer de quel magasin de stratégies provient une règle. Pour les objets qui proviennent d’un objet de stratégie de groupe (le paramètre -PolicyStoreSourceType est spécifié en tant que GroupPolicy dans la commande Show ), si -TracePolicyStore est passé, le nom de l’objet de stratégie de groupe est trouvé et retourné dans le champ PolicyStoreSource .

Get-NetIPsecRule -DisplayName "Require Inbound Authentication" -TracePolicyStore

Il est important de noter que les sources révélées ne contiennent pas de nom de domaine.

Déployer une stratégie d’isolation de domaine de base

IPsec peut être utilisé pour isoler les membres de domaine des membres non-domaine. L’isolation de domaine utilise l’authentification IPsec pour exiger que les appareils joints au domaine établissent positivement les identités des appareils communiquants afin d’améliorer la sécurité d’un organization. Une ou plusieurs fonctionnalités d’IPsec peuvent être utilisées pour sécuriser le trafic avec un objet de règle IPsec. Pour implémenter l’isolation de domaine sur votre réseau, les appareils du domaine reçoivent des règles IPsec qui bloquent le trafic réseau entrant non sollicité qui n’est pas protégé par IPsec. Ici, nous créons une règle IPsec qui nécessite une authentification par les membres du domaine. Grâce à cette authentification, vous pouvez isoler les appareils joints à un domaine des appareils qui ne sont pas joints à un domaine. Dans les exemples suivants, l’authentification Kerberos est requise pour le trafic entrant et demandée pour le trafic sortant.

$kerbprop = New-NetIPsecAuthProposal -Machine -Kerberos
$Phase1AuthSet = New-NetIPsecPhase1AuthSet -DisplayName "Kerberos Auth Phase1" -Proposal $kerbprop -PolicyStore domain.contoso.com\domain_isolation
New-NetIPsecRule -DisplayName "Basic Domain Isolation Policy" -Profile Domain -Phase1AuthSet $Phase1AuthSet.Name -InboundSecurity Require -OutboundSecurity Request -PolicyStore domain.contoso.com\domain_isolation

Configurer le mode tunnel IPsec

La commande suivante crée un tunnel IPsec qui achemine le trafic d’un réseau privé (192.168.0.0/16) via une interface sur l’appareil local (1.1.1.1) attachée à un réseau public vers un deuxième appareil via son interface publique (2.2.2.2) vers un autre réseau privé (192.157.0.0/16). L’intégrité de tout le trafic via le tunnel est vérifiée à l’aide d’ESP/SHA1, et il est chiffré à l’aide de ESP/DES3.

$QMProposal = New-NetIPsecQuickModeCryptoProposal -Encapsulation ESP -ESPHash SHA1 -Encryption DES3
$QMCryptoSet = New-NetIPsecQuickModeCryptoSet -DisplayName "esp:sha1-des3" -Proposal $QMProposal
New-NetIPSecRule -DisplayName "Tunnel from HQ to Dallas Branch" -Mode Tunnel -LocalAddress 192.168.0.0/16 -RemoteAddress 192.157.0.0/16 -LocalTunnelEndpoint 1.1.1.1 -RemoteTunnelEndpoint 2.2.2.2 -InboundSecurity Require -OutboundSecurity Require -QuickModeCryptoSet $QMCryptoSet.Name

Déployer des règles de pare-feu sécurisées avec IPsec

Dans les situations où seul le trafic sécurisé peut être autorisé via le Pare-feu Windows, une combinaison de règles de pare-feu et IPsec configurées manuellement est nécessaire. Les règles de pare-feu déterminent le niveau de sécurité des paquets autorisés et les règles IPsec sous-jacentes sécurisent le trafic. Les scénarios peuvent être réalisés dans Windows PowerShell et dans Netsh, avec de nombreuses similitudes dans le déploiement.

Créer une règle de pare-feu sécurisée (autoriser si sécurisé)

La configuration de la règle de pare-feu pour autoriser les connexions si elles sont sécurisées nécessite que le trafic correspondant soit authentifié et protégé par l’intégrité, puis éventuellement chiffré par IPsec. L’exemple suivant crée une règle de pare-feu qui nécessite l’authentification du trafic. La commande autorise le trafic réseau Telnet entrant uniquement si la connexion à partir de l’appareil distant est authentifiée à l’aide d’une règle IPsec distincte.

New-NetFirewallRule -DisplayName "Allow Authenticated Telnet" -Direction Inbound -Program %SystemRoot%\System32\tlntsvr.exe -Authentication Required -Action Allow

La commande suivante crée une règle IPsec qui nécessite une première authentification (ordinateur), puis tente une deuxième authentification facultative (utilisateur). La création de cette règle sécurise et autorise le trafic via les exigences de règle de pare-feu pour le programme messenger.

$mkerbauthprop = New-NetIPsecAuthProposal -Machine -Kerberos
$mntlmauthprop = New-NetIPsecAuthProposal -Machine -NTLM
$P1Auth = New-NetIPsecPhase1AuthSet -DisplayName "Machine Auth" -Proposal $mkerbauthprop,$mntlmauthprop
$ukerbauthprop = New-NetIPsecAuthProposal -User -Kerberos
$unentlmauthprop = New-NetIPsecAuthProposal -User -NTLM
$anonyauthprop = New-NetIPsecAuthProposal -Anonymous
$P2Auth = New-NetIPsecPhase2AuthSet -DisplayName "User Auth" -Proposal $ukerbauthprop,$unentlmauthprop,$anonyauthprop
New-NetIPSecRule -DisplayName "Authenticate Both Computer and User" -InboundSecurity Require -OutboundSecurity Require -Phase1AuthSet $P1Auth.Name -Phase2AuthSet $P2Auth.Name

Isoler un serveur en exigeant le chiffrement et l’appartenance à un groupe

Pour améliorer la sécurité des appareils dans un organization, vous pouvez déployer l’isolation de domaine dans laquelle les membres du domaine sont limités. Ils nécessitent une authentification lors de la communication entre eux et rejettent les connexions entrantes non authentifiées. Pour améliorer la sécurité des serveurs avec des données sensibles, ces données doivent être protégées en autorisant l’accès uniquement à un sous-ensemble d’appareils au sein du domaine d’entreprise. IPsec peut fournir cette couche de protection supplémentaire en isolant le serveur. Dans l’isolement du serveur, l’accès aux données sensibles est limité aux utilisateurs et aux appareils ayant des besoins métier légitimes, et les données sont également chiffrées pour empêcher l’écoute clandestine.

Créer une règle de pare-feu qui nécessite l’appartenance au groupe et le chiffrement

Pour déployer l’isolation du serveur, nous superposons une règle de pare-feu qui limite le trafic aux utilisateurs ou appareils autorisés sur la règle IPsec qui applique l’authentification. La règle de pare-feu suivante autorise le trafic Telnet à partir de comptes d’utilisateur membres d’un groupe personnalisé appelé « Serveur d’accès autorisé ». Vous pouvez également restreindre cet accès en fonction de l’appareil, de l’utilisateur ou des deux en spécifiant les paramètres de restriction. Une chaîne SDDL (Security Descriptor Definition Language) est créée en étendant l’identificateur de sécurité (SID) d’un utilisateur ou d’un groupe. Pour plus d’informations sur la recherche du SID d’un groupe, consultez : Recherche du SID pour un compte de groupe. La restriction de l’accès à un groupe permet aux administrations d’étendre la prise en charge de l’authentification forte via le Pare-feu Windows et/ou les stratégies IPsec. L’exemple suivant montre comment créer une chaîne SDDL qui représente des groupes de sécurité.

$user = new-object System.Security.Principal.NTAccount ("corp.contoso.com\Administrators")
$SIDofSecureUserGroup = $user.Translate([System.Security.Principal.SecurityIdentifier]).Value
$secureUserGroup = "D:(A;;CC;;;$SIDofSecureUserGroup)"

En utilisant le scriptlet précédent, vous pouvez également obtenir la chaîne SDDL pour un groupe d’ordinateurs sécurisés, comme illustré ici :

$secureMachineGroup = "D:(A;;CC;;;$SIDofSecureMachineGroup)"

Pour plus d’informations sur la création de groupes de sécurité ou sur la façon de déterminer la chaîne SDDL, consultez Utilisation des SID. Telnet est une application qui ne fournit pas de chiffrement. Cette application peut envoyer des données, telles que des noms et des mots de passe, sur le réseau. Ces données peuvent être interceptées par des utilisateurs malveillants. Si un administrateur souhaite autoriser l’utilisation de Telnet, mais protéger le trafic, une règle de pare-feu qui nécessite le chiffrement IPsec peut être créée. Cette règle de pare-feu est nécessaire pour que l’administrateur puisse être certain que lorsque cette application est utilisée, tout le trafic envoyé ou reçu par ce port est chiffré. Si IPsec n’autorise pas la connexion, aucun trafic n’est autorisé à partir de cette application. Dans cet exemple, nous autorisons uniquement le trafic Telnet entrant authentifié et chiffré à partir d’un groupe d’utilisateurs sécurisé spécifié via la création de la règle de pare-feu suivante.

New-NetFirewallRule -DisplayName "Allow Encrypted Inbound Telnet to Group Members Only" -Program %SystemRoot%\System32\tlntsvr.exe -Protocol TCP -Direction Inbound -Action Allow -LocalPort 23 -Authentication Required -Encryption Required -RemoteUser $secureUserGroup -PolicyStore domain.contoso.com\Server_Isolation

Application de la sécurité des points de terminaison

L’exemple précédent a montré la sécurité de bout en bout pour une application particulière. Dans les situations où la sécurité des points de terminaison est requise pour de nombreuses applications, la mise en place d’une règle de pare-feu par application peut être fastidieuse et difficile à gérer. L’autorisation peut remplacer la base par règle et être effectuée au niveau de la couche IPsec. Dans cet exemple, nous définissons le paramètre IPsec global pour autoriser uniquement le trafic en mode de transport à provenir d’un groupe d’utilisateurs autorisé avec l’applet de commande suivante. Consultez les exemples précédents pour utiliser des groupes de sécurité.

Set-NetFirewallSetting -RemoteMachineTransportAuthorizationList $secureMachineGroup

Créer des règles de pare-feu qui autorisent le trafic réseau protégé par IPsec (contournement authentifié)

La déviation authentifiée permet au trafic provenant d’un appareil ou d’un utilisateur approuvé spécifié de remplacer les règles de blocage de pare-feu. Ce remplacement est utile lorsqu’un administrateur souhaite utiliser des serveurs d’analyse pour surveiller et mettre à jour des appareils sans avoir à utiliser d’exceptions au niveau du port. Pour plus d’informations, consultez Guide pratique pour activer la déviation du pare-feu authentifié. Dans cet exemple, nous supposons qu’une règle de pare-feu bloquante existe. Cet exemple autorise tout trafic réseau sur n’importe quel port à partir d’une adresse IP à remplacer la règle de blocage, si le trafic est authentifié comme provenant d’un appareil ou d’un compte d’utilisateur membre de l’appareil ou du groupe de sécurité utilisateur spécifié.

New-NetFirewallRule -DisplayName "Inbound Secure Bypass Rule" -Direction Inbound -Authentication Required -OverrideBlockRules $true -RemoteMachine $secureMachineGroup -RemoteUser $secureUserGroup -PolicyStore domain.contoso.com\domain_isolation