PowerShell permet d'administrer le pare-feu Windows Defender. Dans ce cours, je vais tenter de vous faire un résumé des commandes les plus importantes (que j'utilise vraiment) pour le manipuler.
D'abord, quelques explications sur le fonctionnement de Defender. Sur Windows, il existe par défaut 3 profils de configuration du pare-feu :
Chaque profil applique des règles spécifiques afin d'offrir une sécurité adaptée à chaque contexte réseau. Une règle de pare-feu peut s'appliquer à un ou plusieurs de ces profils selon le contexte (par exemple restreindre une règle à un usage en domaine uniquement). Vous pouvez en décider vous-même.
Le pare-feu Windows est activé par défaut sur tous les profils réseau, bloquant tout le trafic entrant non sollicité et autorisant le trafic sortant (sauf règles contraires).... Enfin... pas vraiment... Mais nous allons le découvrir !
Il faut bien comprendre que Defender n'est pas un pare-feu simple à manipuler du tout ! Le maîtriser requiert une certaine expérience (voir être masochiste sur les bords). Vous allez donc devoir expérimenter sur des VM pour comprendre son fonctionnement. Et pour expérimenter à partir de rien : il faut supprimer toutes les règles et créer des règles de blocage par défaut, avant de pouvoir expérimenter la création de règles et comprendre comment fonctionne Windows en réalité. (Voir la fin de l'article pour les commandes permettant de tout virer)
Dans ce cours, je vous récapitule les commandes qui sont véritablement utiles (car il y a à boire et à manger avec PowerShell).
Grâce à PowerShell donc, on peut créer, manipuler et éditer des règles entrantes (Inbound) et sortantes (Outbound).
Pour commencer, voici comment vérifier l'état du pare-feu sur chaque profil :
Get-NetFirewallProfile | Format-Table Name, EnabledGet-NetFirewallRule | Format-Table Name, DisplayName, Enabled, Direction, Action, Profile -AutoSizePar défaut, vous verrez qu'il y a de très nombreuses règles déjà en place dès l'installation de Windows.
Cette commande affiche chaque règle avec son Nom interne, son Nom d'affichage (plus lisible), son statut (Enabled = actif/inactif), sa Direction (Entrante ou Sortante), l'Action (Allow = autorisée, Block = bloquée) et les Profils où elle s'applique. Vous pouvez ainsi repérer rapidement les règles actives et leur portée.
Il faut utiliser le Nom interne d'une règle (donc celui affiché dans la colonne de gauche lorsqu'on utilise la commande précédente) lorsqu'on souhaite la manipuler car le nom d'affichage (DisplayName) est souvent traduit dans l'édition de Windows installée, générant beaucoup de problèmes (!!!).
Get-NetFirewallRule -Direction Inbound -Enabled TrueGet-NetFirewallRule -Action Block -Direction OutboundGet-NetFirewallRule -Action Allow -Direction InboundGet-NetFirewallRule -Name "EventForwarder-RPCSS-In-TCP" | Get-NetFirewallAddressFilterSur Defender, vous pouvez créer :
New-NetFirewallRule -Name "SSH" -DisplayName "Autoriser SSH (Port 22)" -Profile Domain -Enabled True -Direction Inbound -Protocol TCP -LocalPort 22 -LocalAddress 192.168.100.13 -Action AllowDans cet exemple, la règle "SSH" autorisera des connexions entrantes vers le port 22 uniquement sur l'adresse IP locale 192.168.100.13 du serveur et lorsque celui-ci est connecté sur un réseau de type Domaine. Le paramètre Enabled à True l'active immédiatement. Si Name n'avait pas été spécifié, PowerShell aurait généré un identifiant unique (GUID) en guise de nom de règle.
New-NetFirewallRule -Name "Autoriser DHCP Client" -Direction Outbound -Program "$env:SystemRoot\system32\svchost.exe" -RemoteAddress LocalSubnet -Action AllowIci, -Program cible le service client DHCP et -RemoteAddress LocalSubnet limite la règle aux IP de même sous-réseau que le serveur. Cette règle s'appliquera par défaut sur tous les profils (Profile = Any) sauf précision contraire.
New-NetFirewallRule -Name "Bloquer Firefox" -DisplayName "Bloquer Firefox" -Description "Blocage navigateur Firefox" -Program "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -Action Block -Direction Outbound -Profile Domain,PrivateCette règle Outbound bloque toute tentative de l'exécutable Firefox à sortir sur le réseau pour les profils Domaine et Privé. Aucune spécification de port n'est nécessaire ici, on bloque l'application entièrement.
Les paramètres LocalPort, RemoteAddress, etc. acceptent plusieurs valeurs (tableaux ou liste d'adresses IP séparées par des virgules). Par exemple, on pourrait autoriser plusieurs ports en une seule règle ou plusieurs IP/subnets d'un coup. Ci-dessous, on ouvre les ports TCP 80 et 443 en entrée pour les profils Domain et Private via une seule règle :
New-NetFirewallRule -Name "Web Inbound" -DisplayName "Entree HTTP" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80,443 -Profile Domain,PrivateDe même, on peut spécifier une liste d'IP ou de sous-réseaux en RemoteAddress (ou LocalAddress). Si la liste devient longue, il peut être judicieux de la stocker dans une variable ou un fichier texte. Par exemple :
$ips = @("192.168.2.15-192.168.2.40", "192.168.100.15-192.168.100.200", "10.1.0.0/16")
New-NetFirewallRule -Name "Allow ICMPv4 from ranges" -DisplayName "Autoriser ICMPv4 from ranges" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress $ips -Action AllowIci on utilise un tableau $ips contenant des plages d'adresses et des sous-réseaux en notation CIDR, puis on crée deux règles ICMP (une pour IPv4, on pourrait ajouter une pour IPv6) autorisant le ping seulement depuis ces adresses.
Une fois des règles créées, on peut être amené à les ajuster : restreindre davantage leur scope, changer l'action, le port, ou encore les activer/désactiver temporairement. La cmdlet Set-NetFirewallRule est conçue pour modifier une règle existante en se basant sur un identifiant (Name ou DisplayName). Seules les propriétés spécifiées en paramètre seront modifiées, les autres restant inchangées.
Limiter la règle "MyApp-Web" à l'adresse locale 10.10.10.11 et aux profils Domaine et Privé :
$IpLocale = "10.10.10.11"
Set-NetFirewallRule -Name "MyApp-Web" -LocalAddress $IpLocale -Profile Domain,PrivateDésormais, MyApp-Web ne s'appliquera plus que si les paquets sont destinés à l'IP locale 10.10.10.11 (et pas aux autres IP du serveur) sur les profils Domain/Private. Ceci est utile pour scinder les règles par rôle ou interface réseau.
$IpRemote = "10.10.10.11"
Set-NetFirewallRule -Name "MyApp-Web" -RemoteAddress $IpRemote -Profile Domain,Private,Public$ruleNames = @(
"RemoteDesktop-In-TCP-WS",
"RemoteDesktop-In-TCP-WSS",
"RemoteDesktop-Shadow-In-TCP",
"RemoteDesktop-UserMode-In-TCP",
"RemoteDesktop-UserMode-In-UDP"
)
Get-NetFirewallRule -Name $ruleNames | Set-NetFirewallRule -LocalAddress "192.168.43.10" -Profile Private(Attention, vous devez DEJA avoir ajouté une IP auparavant, autrement la valeur de $currentIPs sera « Any » et ne sera pas manipulable avec les commandes suivantes.)
$ruleName = "RemoteDesktop-UserMode-In-TCP"
$currentIPs = (Get-NetFirewallRule -Name $ruleName | Get-NetFirewallAddressFilter).RemoteAddress
$newIPs = $currentIPs + "192.168.2.210"
Set-NetFirewallRule -Name $ruleName -RemoteAddress $newIPsOption 1 : utiliser Set-NetFirewallRule pour passer Enabled à false
Set-NetFirewallRule -Name "SSH" -Enabled FalseOption 2 : utiliser le raccourci Disable-NetFirewallRule
Disable-NetFirewallRule -Name "SSH"Dans les deux cas, la règle SSH est maintenant inactivée (elle existe toujours mais n'est plus appliquée).
Vérifier l'état :
Get-NetFirewallRule -Name "SSH"Pour la réactiver ultérieurement :
Set-NetFirewallRule -Name "SSH" -Enabled Trueou bien
Enable-NetFirewallRule -Name "SSH"Si une règle est obsolète ou n'est plus nécessaire, on peut la supprimer du pare-feu à l'aide de Remove-NetFirewallRule.
Identifier le Name de la règle à supprimer (colonne de gauche des résultats) :
Get-NetFirewallRule | Format-Table Name, DisplayName, Enabled, Direction, Action, Profile -AutoSizeSuppression d'une règle par son nom interne ou GUID :
Remove-NetFirewallRule -Name "RemoteDesktop-UserMode-In-UDP"Attention : Cette action est irréversible -- il n'y a pas de corbeille pour les règles de pare-feu. Une fois supprimée, la règle ne peut être restaurée qu'en la recréant manuellement (sauf si vous l'aviez exportée au préalable). Il est donc prudent de désactiver la règle d'abord si vous avez un doute, ou d'exporter la configuration courante avant des changements massifs.
C'est là que tout se complique terriblement...
Avec Defender, vous aurez beau essayer de mettre en place certaines règles, vous n'y parviendrez tout simplement pas. C'est le cas avec le RDP par exemple. Il ne suffit pas de créer des règles autorisant le port 3389 en TCP/UDP dès lors que vous avez mis en place des politiques de blocage par défaut sur tous les profils et des règles bloquantes. Car ces processus utilisent des mécanismes sous-jacents relativement complexes et dépendent de plusieurs autres logiciels qui doivent eux aussi être autorisés. (je parle notamment du diabolique svchost).
Windows a donc un magasin de règles préconfigurées en lecture seule. Ce magasin peut être manipulé en graphique pour ré-introduire des règles par défaut via la manipulation d'API internes... Problème : il ne peut pas être manipulé en PowerShell ! Il y a une véritable opacité sur ce sujet (probablement à raison). Les IA vous répondent d'ailleurs systématiquement à côté...
Mais... il y a un moyen ! 😉
Quelques conseils donc, pour manipuler les règles par défaut en PowerShell et vous mettre le pied à l'étrier sur la sécurité Windows ! Nous partons du postulat que vous avez supprimé TOUTES les règles de Defender (entrantes et sortantes), que vous avez appliqué une politique de blocage par défaut sur tous les profils et créé des règles de blocage :
Get-NetFirewallRule -Direction Inbound | Remove-NetFirewallRule
Get-NetFirewallRule -Direction Outbound | Remove-NetFirewallRule
Set-NetFirewallProfile -Profile Domain,Private,Public -DefaultInboundAction Block -DefaultOutboundAction Block
New-NetFirewallRule -DisplayName "Block inbound from 224.0.0.0-239.255.255.255" -Direction Inbound -Action Block -Protocol Any -RemoteAddress "224.0.0.0-239.255.255.255" -Profile Domain,Private,Public
New-NetFirewallRule -DisplayName "Block inbound from 239.255.255.250" -Direction Inbound -Action Block -Protocol Any -RemoteAddress "239.255.255.250" -Profile Domain,Private,Public
New-NetFirewallRule -DisplayName "Block outbound to 224.0.0.0-239.255.255.255" -Direction Outbound -Action Block -Protocol Any -RemoteAddress "224.0.0.0-239.255.255.255" -Profile Domain,Private,Public
New-NetFirewallRule -DisplayName "Block outbound to 239.255.255.250" -Direction Outbound -Action Block -Protocol Any -RemoteAddress "239.255.255.250" -Profile Domain,Private,PublicAprès l'application de ces règles, votre serveur n'émet plus rien. Enfin.. pas tout à fait... il y a des manipulations à faire sur regedit... (et oui.. Defender est bypassé par certaines options plus profondes du système... :-D)... mais bon.. passons. ça n'est pas l'objet du cours !
Une fois toutes ces règles virées, plus rien ne sort ni ne rentre ! Si certaines applications peuvent émettre sans dépendre de la pile svchost, d'autres ne le peuvent pas. (cas de Edge notamment, du Terminal Windows, ou des requêtes DNS classiques). Firefox est l'un des seuls navigateurs à ne pas dépendre de svchost pour info, et vous pouvez activer DNS sur HTTPS dans ses paramètres pour résoudre le soucis des requêtes liés au blocage de svchost...). Donc dans 9 cas sur 10, vous devrez donc autoriser svchost... et donc toute la télémétrie de Windows qui va avec, puisque je le rappelle : il est impossible de stopper la télémétrie de Windows sans couper svchost. Or l'objectif premier de la sécurité informatique est clair : maîtriser les flux ! Il faut donc travailler avec des logiciels qui ne dépendent pas d'svchost, point ! Et c'est un véritable apprentissage car il va vous falloir apprendre à créer des règles de pare-feu adaptées et beaucoup expérimenter pour trouver comment faire. Egalement, beaucoup d'applications ne fonctionneront simplement plus. Il faudra donc vous tourner vers des applications compatibles.
J'ai une liste de méthodes pour des applications courantes (navigateurs, clients mails etc.) sur demande.
Mais continuons sur les règles du magasin :
Get-NetFirewallRule -PolicyStore SystemDefaults | Select-Object Name, DisplayName, DisplayGroup, Enabled, ProfileGet-NetFirewallRule -PolicyStore SystemDefaults | Where-Object { $_.DisplayName -like "*Remote Desktop*" -or $_.Name -like "*RemoteDesktop*" } | Select-Object Name, DisplayName, DisplayGroup, Enabled, ProfileComment, maintenant, recréer ces règles par défaut, puisque nous ne pouvons pas simplement les copier du magasin pour les placer sur nos listes Inbound/Outbound ?
Nous allons les recréer en nous servant de tous les détails de ces règles du magasin.
Get-NetFirewallRule -PolicyStore SystemDefaults |
Where-Object { $_.DisplayName -like "*Bureau à distance*" -or $_.Name -like "*RemoteDesktop*" } |
ForEach-Object {
[PSCustomObject]@{
Name = $_.Name
DisplayName = $_.DisplayName
DisplayGroup = $_.DisplayGroup
Enabled = $_.Enabled
Profile = $_.Profile
Direction = $_.Direction
Action = $_.Action
Description = $_.Description
Program = (Get-NetFirewallApplicationFilter -AssociatedNetFirewallRule $_).Program
Service = (Get-NetFirewallServiceFilter -AssociatedNetFirewallRule $_).Service
Protocol = (Get-NetFirewallPortFilter -AssociatedNetFirewallRule $_).Protocol
LocalPort = (Get-NetFirewallPortFilter -AssociatedNetFirewallRule $_).LocalPort
RemotePort = (Get-NetFirewallPortFilter -AssociatedNetFirewallRule $_).RemotePort
LocalAddress = (Get-NetFirewallAddressFilter -AssociatedNetFirewallRule $_).LocalAddress
RemoteAddress= (Get-NetFirewallAddressFilter -AssociatedNetFirewallRule $_).RemoteAddress
InterfaceType= (Get-NetFirewallInterfaceTypeFilter -AssociatedNetFirewallRule $_).InterfaceType
}
} | Format-List *Grâce à ces informations complètes, nous allons pouvoir recréer les règles RDP par défaut :
New-NetFirewallRule `
-Name "RemoteDesktop-UserMode-In-TCP" `
-DisplayName "Bureau à distance - Mode utilisateur (TCP entrant)" `
-Description "Règle de trafic entrant pour le service Bureau à distance pour autoriser le trafic RDP. [TCP 3389]" `
-Direction Inbound `
-Action Allow `
-Protocol TCP `
-LocalPort 3389 `
-Program "%SystemRoot%\system32\svchost.exe" `
-Service "termservice" `
-Profile Domain,Private `
-Enabled TrueNew-NetFirewallRule `
-Name "RemoteDesktop-UserMode-In-UDP" `
-DisplayName "Bureau à distance - Mode utilisateur (UDP entrant)" `
-Description "Règle de trafic entrant pour que le service Bureau à distance autorise le trafic RDP. [UDP 3389]" `
-Direction Inbound `
-Action Allow `
-Protocol UDP `
-LocalPort 3389 `
-Program "%SystemRoot%\system32\svchost.exe" `
-Service "termservice" `
-Profile Domain,Private `
-Enabled TrueNew-NetFirewallRule `
-Name "RemoteDesktop-Shadow-In-TCP" `
-DisplayName "Bureau à distance - Contrôle à distance (TCP-In)" `
-Description "Règle entrante pour que le service Bureau à distance autorise le contrôle à distance d'une session Bureau à distance existante. (TCP-In)" `
-Direction Inbound `
-Action Allow `
-Protocol TCP `
-Program "%SystemRoot%\system32\RdpSa.exe" `
-Profile Domain,Private `
-Enabled FalseNew-NetFirewallRule `
-Name "RemoteDesktop-In-TCP-WS" `
-DisplayName "Bureau à distance - (TCP-WS-entrant)" `
-Description "Règle de trafic entrant pour que le service Bureau à distance autorise le trafic RDP sur WebSocket. [TCP 3387]" `
-Direction Inbound `
-Action Allow `
-Protocol TCP `
-LocalPort 3387 `
-Program "System" `
-Profile Domain,Private `
-Enabled FalseNew-NetFirewallRule `
-Name "RemoteDesktop-In-TCP-WSS" `
-DisplayName "Bureau à distance - (TCP-WSS-entrant)" `
-Description "Règle de trafic entrant pour que le service Bureau à distance autorise le trafic RDP sur WebSocket sécurisé. [TCP 3392]" `
-Direction Inbound `
-Action Allow `
-Protocol TCP `
-LocalPort 3392 `
-Program "System" `
-Profile Domain,Private `
-Enabled FalseLes règles d'origine indiquent « Profile : Any », ce qui signifie que ces règles sont potentiellement applicables à tous les profils (Domain, Private, Public), mais par défaut dans Windows, elles sont habituellement activées uniquement sur les profils Domain et Private pour des raisons évidentes de sécurité.
Si vous souhaitez précisément coller à la configuration initiale de Windows, vous pouvez appliquer :
Ici, j'ai pris l'approche sécurisée (Domain, Private), qui correspond à l'état généralement appliqué par Windows lorsqu'on active manuellement le RDP.
Les règles RDP du magasin utilisent des mécanismes préconfigurés très complexes. J'ai personnellement banni l'usage de RDP, ne pouvant pas accéder au code sous-jacent. Priorisez toujours OpenSSH, même sur Windows Serveur !
Lorsque vous êtes parvenus à mettre en place un ensemble de règles concrètes et fonctionnelles, il est préférable d'en faire une copie, afin de pouvoir les restaurer en cas de soucis.
Voici un petit script qui vous permettra de le faire (il est en batch.. pour changer un peu :-D).
@echo off
chcp 65001 > nul
setlocal enabledelayedexpansion
:: Créer le dossier C:\BACKUP s'il n'existe pas
if not exist "C:\BACKUP" (
mkdir "C:\BACKUP"
if !errorlevel! neq 0 (
exit /b 1
)
)
:: Set the output file name
set "output_file=C:\BACKUP\firewall_rules_export.wfw"
:: Get the current date and time for the file name
for /f "tokens=2 delims==" %%I in ('wmic os get localdatetime /value') do set datetime=%%I
set "datetime=%datetime:~0,8%_%datetime:~8,6%"
:: Set the final output file name with date and time
set "final_output_file=firewall_rules_export_%datetime%.wfw"
:: Export all firewall rules
netsh advfirewall export "%output_file%"
:: Check if the export was successful
if %errorlevel% equ 0 (
ren "%output_file%" "%final_output_file%"
) else (
exit /b 1
)Nous envoyons ainsi toutes nos règles sauvegardées dans un nouveau dossier C:\BACKUP créé par le script à cette occasion.
@echo off
chcp 65001 > nul
setlocal enabledelayedexpansion
:: Définir le chemin du dossier de sauvegarde
set "backup_folder=C:\BACKUP"
:: Trouver le fichier le plus récent
for /f "delims=" %%i in ('dir /b /od "%backup_folder%\firewall_rules_export_*.wfw" 2^>nul') do set "latest_file=%%i"
:: Construire le chemin complet du fichier
set "input_file=%backup_folder%\%latest_file%"
:: Importer les règles de pare-feu
netsh advfirewall import "%input_file%" > nul 2>&1Windows est un excellent système, mais dès lors qu'il s'agît de sécurité et de confidentialité, il y a bien plus de travail que sur Linux/BSD/Unix !... Mais on y arrive ! Je vous rassure !
J'espère que cette introduction à la manipulation de Defender en PowerShell ne vous aura pas donné la nausée :-D.. moi j'adore !!