Détecter et bloquer les attaques brute-force RDP avec PowerShell

Le protocole RDP (Remote Desktop Protocol) est l'un des vecteurs d'attaque les plus exploités en cybersécurité. Des millions de serveurs Windows exposent ce port (3389 par défaut) directement sur Internet, constituant une cible de choix pour les attaquants, les ransomwares et les botnets. L'attaque brute-force RDP consiste à tenter des milliers de combinaisons de noms d'utilisateur et de mots de passe jusqu'à trouver des credentials valides. Contrairement à des attaques sophistiquées nécessitant des outils spécialisés, le brute-force RDP est accessible à n'importe quel script kiddie grâce à des outils comme Hydra, Medusa ou Crowbar. Les statistiques sont alarmantes : les honeypots exposant un port RDP reçoivent en moyenne des dizaines de milliers de tentatives de connexion par jour dans les heures suivant leur mise en ligne. Face à cette menace, les systèmes Linux ont depuis longtemps des solutions comme Fail2ban pour bloquer automatiquement les IP offensives. Windows Server, en revanche, ne dispose pas nativement d'un équivalent aussi simple à mettre en place. Ce guide vous présente une solution complète et gratuite basée sur PowerShell : un script qui analyse les Event Logs Windows pour détecter les tentatives de brute-force RDP, bloque automatiquement les IP agressives via le pare-feu Windows (Windows Firewall), gère une whitelist d'IPs légitimes, et s'exécute automatiquement via une tâche planifiée. Nous aborderons également les solutions complémentaires pour renforcer la sécurité RDP au-delà du simple blocage IP.

Comprendre l'attaque brute-force RDP (Event ID 4625, IP source, fréquence)

Avant d'écrire le script de défense, il faut comprendre comment Windows trace les tentatives d'authentification échouées sur RDP.

Lorsqu'une connexion RDP échoue (mauvais mot de passe ou compte inexistant), Windows génère l'Event ID 4625 dans le journal de sécurité. Cet événement contient plusieurs champs clés :

• SubStatus : raison de l'échec — 0xC000006A (mauvais mot de passe), 0xC0000064 (nom de compte inexistant), 0xC000006D (mauvaise authentification)
• LogonType : type de connexion — valeur 3 (réseau) ou 10 (remote interactif) pour RDP
• IpAddress : adresse IP source de la tentative
• TargetUserName : nom du compte ciblé
• WorkstationName : nom de la machine source (souvent vide pour les attaques externes)

Une attaque brute-force typique se caractérise par :

• Des dizaines à des milliers de 4625 en quelques minutes depuis la même IP source
• Des noms de comptes variés ou toujours les mêmes (admin, administrator, user...)
• Des connexions LogonType 3 ou 10
• Une IP source externe ou inconnue

Le seuil de détection doit être calibré : trop bas (ex: 3 échecs) génère des faux positifs (utilisateur qui a oublié son mot de passe) ; trop haut (ex: 1000 échecs) laisse passer des attaques lentes (slow brute-force). Un seuil de 10 à 20 échecs en 10 minutes est généralement un bon équilibre.

Sur les contrôleurs de domaine, l'Event ID à surveiller est différent : c'est le 4776 (NTLM) ou 4771 (Kerberos pre-authentication failure). Sur un serveur membre ou un poste de travail en workgroup, c'est bien le 4625 qui est pertinent pour RDP. Pour approfondir la configuration des politiques d'audit qui génèrent ces événements, consultez notre article sur l'audit avancé Active Directory via GPO.

Prérequis — activer l'audit des connexions (Event ID 4625 Logon Failure)

Le script de détection ne fonctionnera que si l'audit des échecs d'authentification est activé. Sans cela, les Event IDs 4625 ne sont pas générés.

Pour activer l'audit sur un serveur standalone (hors domaine AD) via la politique locale :

# Vérifier la configuration actuelle
auditpol /get /subcategory:"Logon"

# Activer les échecs de logon
auditpol /set /subcategory:"Logon" /failure:enable

# Vérifier
auditpol /get /subcategory:"Logon"
# Logon    Failure

Pour un serveur membre d'un domaine Active Directory, configurez via GPO comme expliqué dans notre guide dédié à l'audit AD. Sur la GPO liée à l'OU des serveurs :

Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Logon/Logoff → Audit Logon → Failure : Enable

Vérifiez que les événements sont bien générés en effectuant une tentative de connexion RDP avec un mauvais mot de passe depuis un autre poste, puis cherchez l'événement 4625 :

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4625]]" -MaxEvents 5 |
  Select-Object TimeCreated, @{n='IP';e={$_.Properties[19].Value}}, @{n='User';e={$_.Properties[5].Value}}

Si cette commande retourne des résultats, l'audit est fonctionnel. Assurez-vous également que le journal de sécurité a une taille suffisante (au moins 256 Mo) pour ne pas perdre d'événements :

wevtutil sl Security /ms:268435456

Script PowerShell de détection (parcourir les Event Logs, compter les échecs par IP)

Voici le premier composant du système : le script de détection qui analyse les Event Logs et identifie les IPs offensives.

# RDP-BruteForce-Detector.ps1
# Détection des attaques brute-force RDP via Event ID 4625
# -------------------------------------------------------

param(
    [int]$Threshold = 15,          # Nombre d'échecs avant blocage
    [int]$TimeWindowMinutes = 10,   # Fenêtre temporelle d'analyse
    [string]$LogFile = "C:\Scripts\rdp-bruteforce.log",
    [string]$WhitelistFile = "C:\Scripts\rdp-whitelist.txt"
)

function Write-Log {
    param([string]$Message)
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$timestamp - $Message" | Tee-Object -FilePath $LogFile -Append
}

function Get-Whitelist {
    if (Test-Path $WhitelistFile) {
        return Get-Content $WhitelistFile | Where-Object { $_ -notmatch "^#" -and $_ -ne "" }
    }
    return @()
}

# Période d'analyse
$startTime = (Get-Date).AddMinutes(-$TimeWindowMinutes)
$whitelist = Get-Whitelist

Write-Log "=== Début analyse RDP brute-force (fenêtre: ${TimeWindowMinutes}min, seuil: ${Threshold}) ==="

# Récupérer les Event ID 4625 (LogonType 3 ou 10) de la période
try {
    $failedLogons = Get-WinEvent -LogName Security -FilterXPath `
        "*[System[EventID=4625 and TimeCreated[@SystemTime>='$($startTime.ToUniversalTime().ToString("o"))']]]" `
        -ErrorAction Stop
} catch {
    Write-Log "ERREUR: Impossible de lire les événements: $_"
    exit 1
}

Write-Log "Événements 4625 trouvés: $($failedLogons.Count)"

# Extraire les IPs sources
$ipFailures = @{}
foreach ($event in $failedLogons) {
    $xml = [xml]$event.ToXml()
    $ns = New-Object System.Xml.XmlNamespaceManager($xml.NameTable)
    $ns.AddNamespace("e", "http://schemas.microsoft.com/win/2004/08/events/event")

    # LogonType (index 8 dans EventData)
    $logonType = $xml.SelectSingleNode("//e:Data[@Name='LogonType']", $ns).'#text'

    # Filtrer LogonType 3 (réseau) et 10 (remote interactif/RDP)
    if ($logonType -notin @("3", "10")) { continue }

    # IP source (index 19 dans EventData)
    $ipAddress = $xml.SelectSingleNode("//e:Data[@Name='IpAddress']", $ns).'#text'

    # Ignorer les IPs vides, locales, ou en whitelist
    if ([string]::IsNullOrEmpty($ipAddress) -or $ipAddress -eq "-" -or $ipAddress -eq "127.0.0.1" -or $ipAddress -eq "::1") { continue }
    if ($whitelist -contains $ipAddress) {
        Write-Log "IP whitelistée ignorée: $ipAddress"
        continue
    }

    if (-not $ipFailures.ContainsKey($ipAddress)) {
        $ipFailures[$ipAddress] = 0
    }
    $ipFailures[$ipAddress]++
}

# Identifier les IPs dépassant le seuil
$suspiciousIPs = $ipFailures.GetEnumerator() | Where-Object { $_.Value -ge $Threshold }

if ($suspiciousIPs.Count -eq 0) {
    Write-Log "Aucune IP suspecte détectée"
} else {
    Write-Log "IPs suspectes détectées: $($suspiciousIPs.Count)"
    foreach ($ip in $suspiciousIPs) {
        Write-Log "SUSPECT: $($ip.Key) — $($ip.Value) échecs en ${TimeWindowMinutes}min"
    }
}

# Retourner les IPs suspectes pour le script de blocage
return $suspiciousIPs | Select-Object @{n='IP';e={$_.Key}}, @{n='Failures';e={$_.Value}}

Script de blocage automatique (New-NetFirewallRule pour bannir l'IP)

Le deuxième composant bloque effectivement les IPs identifiées comme offensives via le pare-feu Windows :

# RDP-BruteForce-Blocker.ps1
# Blocage automatique des IPs RDP via Windows Firewall
# -------------------------------------------------------

param(
    [string]$LogFile = "C:\Scripts\rdp-bruteforce.log",
    [string]$WhitelistFile = "C:\Scripts\rdp-whitelist.txt",
    [int]$Threshold = 15,
    [int]$TimeWindowMinutes = 10
)

function Write-Log {
    param([string]$Message)
    $timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    "$timestamp - $Message" | Tee-Object -FilePath $LogFile -Append
}

function Block-IP {
    param([string]$IPAddress, [int]$Failures)

    $ruleName = "RDP-BruteForce-Block-$IPAddress"

    # Vérifier si déjà bloquée
    $existingRule = Get-NetFirewallRule -DisplayName $ruleName -ErrorAction SilentlyContinue
    if ($existingRule) {
        Write-Log "IP déjà bloquée: $IPAddress"
        return
    }

    # Créer la règle de blocage
    try {
        New-NetFirewallRule `
            -DisplayName $ruleName `
            -Direction Inbound `
            -Protocol TCP `
            -LocalPort 3389 `
            -RemoteAddress $IPAddress `
            -Action Block `
            -Enabled True `
            -Profile Any `
            -Description "Blocked by RDP-BruteForce-Blocker on $(Get-Date). Failures: $Failures" |
            Out-Null

        Write-Log "BLOQUÉ: $IPAddress ($Failures tentatives)"

        # Journaliser dans le Windows Event Log (Application)
        Write-EventLog -LogName Application `
            -Source "RDP-BruteForce-Blocker" `
            -EventId 9001 `
            -EntryType Warning `
            -Message "IP bloquée: $IPAddress - $Failures tentatives RDP en ${TimeWindowMinutes} minutes" `
            -ErrorAction SilentlyContinue

    } catch {
        Write-Log "ERREUR blocage $IPAddress : $_"
    }
}

# Créer la source d'événement si nécessaire
if (-not [System.Diagnostics.EventLog]::SourceExists("RDP-BruteForce-Blocker")) {
    New-EventLog -LogName Application -Source "RDP-BruteForce-Blocker" -ErrorAction SilentlyContinue
}

# Appeler le script de détection
$suspiciousIPs = & "C:\Scripts\RDP-BruteForce-Detector.ps1" `
    -Threshold $Threshold `
    -TimeWindowMinutes $TimeWindowMinutes `
    -LogFile $LogFile `
    -WhitelistFile $WhitelistFile

# Bloquer chaque IP suspecte
foreach ($entry in $suspiciousIPs) {
    Block-IP -IPAddress $entry.IP -Failures $entry.Failures
}

# Rapport du nombre de règles actives
$activeRules = (Get-NetFirewallRule -DisplayName "RDP-BruteForce-Block-*" -ErrorAction SilentlyContinue).Count
Write-Log "Total IPs bloquées: $activeRules"
Write-Log "=== Fin du cycle de vérification ==="`

Automatiser avec une tâche planifiée Windows (toutes les X minutes)

Pour que le script s'exécute automatiquement, créez une tâche planifiée Windows. Créez d'abord les répertoires nécessaires :

# Créer les répertoires
New-Item -ItemType Directory -Path "C:\Scripts" -Force

# Créer le fichier whitelist initial
@"
# Whitelist RDP BruteForce Blocker
# Une IP par ligne. Lignes commençant par # = commentaires.
192.168.1.0/24
10.0.0.0/8
"@ | Set-Content "C:\Scripts\rdp-whitelist.txt"

# Créer la tâche planifiée (exécution toutes les 5 minutes)
$action = New-ScheduledTaskAction `
    -Execute "PowerShell.exe" `
    -Argument "-NonInteractive -ExecutionPolicy Bypass -File C:\Scripts\RDP-BruteForce-Blocker.ps1"

$trigger = New-ScheduledTaskTrigger -RepetitionInterval (New-TimeSpan -Minutes 5) -Once -At (Get-Date)

$principal = New-ScheduledTaskPrincipal `
    -UserId "SYSTEM" `
    -LogonType ServiceAccount `
    -RunLevel Highest

$settings = New-ScheduledTaskSettingsSet `
    -ExecutionTimeLimit (New-TimeSpan -Minutes 2) `
    -MultipleInstances IgnoreNew

Register-ScheduledTask `
    -TaskName "RDP-BruteForce-Protection" `
    -TaskPath "\Security\" `
    -Action $action `
    -Trigger $trigger `
    -Principal $principal `
    -Settings $settings `
    -Description "Détection et blocage automatique des attaques brute-force RDP" `
    -Force

Write-Host "Tâche planifiée créée avec succès"

Pour vérifier que la tâche fonctionne :

# Déclencher manuellement
Start-ScheduledTask -TaskName "\Security\RDP-BruteForce-Protection"

# Vérifier le statut
Get-ScheduledTask -TaskName "RDP-BruteForce-Protection" | Select LastRunTime,LastTaskResult,State

# Vérifier les logs
Get-Content "C:\Scripts\rdp-bruteforce.log" -Tail 20

Gérer la whitelist (IPs légitimes à ne jamais bannir)

La whitelist est un composant critique pour éviter de bloquer accidentellement des administrateurs ou des systèmes légitimes. Le fichier C:\Scripts\rdp-whitelist.txt doit être configuré rigoureusement avant de déployer le script en production.

Éléments à inclure impérativement dans la whitelist :

• Vos plages d'IP internes (réseau d'entreprise, VPN)
• Les IPs des administrateurs système (si fixes)
• Les IPs des outils de monitoring (Zabbix, PRTG, etc.) qui effectuent des connexions de vérification
• Les IPs de vos passerelles RD Gateway ou VPN
• Les IPs des serveurs de sauvegarde et de patch management

La gestion des plages CIDR dans la whitelist nécessite une fonction supplémentaire :

# Ajouter au script de détection — fonction IsIPInWhitelist
function Test-IPInWhitelist {
    param([string]$IPToCheck, [string[]]$Whitelist)

    foreach ($entry in $Whitelist) {
        if ($entry -match "/") {
            # Traitement CIDR
            $network, $prefix = $entry.Split("/")
            $networkIP = [System.Net.IPAddress]::Parse($network)
            $checkIP = [System.Net.IPAddress]::Parse($IPToCheck)
            $maskBytes = [Convert]::ToInt64(("1" * [int]$prefix + "0" * (32 - [int]$prefix)), 2)
            $mask = [System.Net.IPAddress]::new([BitConverter]::GetBytes([IPAddress]::HostToNetworkOrder($maskBytes))[0..3])
            $networkBytes = $networkIP.GetAddressBytes()
            $checkBytes = $checkIP.GetAddressBytes()
            $maskBytesArr = $mask.GetAddressBytes()
            $isInSubnet = (-not (0..3 | Where-Object { ($networkBytes[$_] -band $maskBytesArr[$_]) -ne ($checkBytes[$_] -band $maskBytesArr[$_]) }))
            if ($isInSubnet) { return $true }
        } elseif ($entry -eq $IPToCheck) {
            return $true
        }
    }
    return $false
}

Débannir une IP (Remove-NetFirewallRule)

Si une IP légitime est accidentellement bloquée (utilisateur en déplacement avec une nouvelle IP, partenaire externe), voici les commandes pour la débloquer rapidement :

# Débloquer une IP spécifique
$ipToBan = "203.0.113.45"  # Remplacez par l'IP à débloquer
Remove-NetFirewallRule -DisplayName "RDP-BruteForce-Block-$ipToBan" -ErrorAction SilentlyContinue
Write-Host "IP $ipToBan débloquée"

# Lister toutes les IPs actuellement bloquées
Get-NetFirewallRule -DisplayName "RDP-BruteForce-Block-*" |
  Select-Object DisplayName, @{n='CreatedDate';e={$_.Description -replace '.*on ([\d-]+\s[\d:]+).*','$1'}} |
  Sort-Object CreatedDate -Descending

# Nettoyer toutes les règles de blocage (reset complet)
Get-NetFirewallRule -DisplayName "RDP-BruteForce-Block-*" | Remove-NetFirewallRule
Write-Host "Toutes les règles de blocage supprimées"

# Optionnel : automatiser le déblocage après 24h (ajout d'un champ date dans la description)
$oldRules = Get-NetFirewallRule -DisplayName "RDP-BruteForce-Block-*" |
  Where-Object { $_.Description -match "Blocked by RDP-BruteForce-Blocker on (\d{4}-\d{2}-\d{2})" } |
  Where-Object { [datetime]($Matches[1]) -lt (Get-Date).AddHours(-24) }
$oldRules | Remove-NetFirewallRule
Write-Host "Règles de plus de 24h supprimées: $($oldRules.Count)"

Comparer avec d'autres solutions (CrowdSec, Microsoft Defender, NPS Account Lockout)

Le script PowerShell présenté dans ce guide est une solution légère, gratuite et entièrement maîtrisée. D'autres solutions existent avec des fonctionnalités différentes.

CrowdSec est une alternative open source particulièrement puissante. Il fonctionne comme un Fail2ban collaboratif : les IPs offensives détectées par tous les membres de la communauté CrowdSec sont partagées dans une intelligence de menaces collective. L'agent Windows s'installe facilement, les "parsers" pour les Event Logs Windows sont disponibles nativement, et le "bouncer" Windows Firewall bloque automatiquement les IPs signalées. L'avantage principal : vous bénéficiez de la détection collaborative de milliers d'organisations.

Microsoft Defender for Identity (anciennement Azure ATP) offre une détection comportementale avancée qui dépasse le simple comptage de tentatives. Il analyse les patterns d'authentification Kerberos et NTLM, détecte le Password Spray (attaque sur de nombreux comptes avec peu de tentatives par compte, évitant le blocage classique), et s'intègre nativement avec Microsoft Sentinel. Solution idéale pour les environnements hybrides Azure AD.

NPS Network Policy Server + Account Lockout Policy : la politique de verrouillage de compte Windows intégrée à l'AD (Fine-Grained Password Policy) peut compléter le blocage IP en verrouillant les comptes après N tentatives. Attention : le verrouillage de compte peut lui-même devenir un vecteur de DoS si l'attaquant cible des comptes sensibles. La combinaison blocage IP + verrouillage compte modéré (10-15 tentatives) est recommandée.

RD Gateway (Remote Desktop Gateway) est la solution architecturale la plus robuste : au lieu d'exposer directement le port RDP sur Internet, les connexions passent par un gateway HTTPS avec authentification forte (MFA). Les serveurs cibles ne sont plus exposés directement, éliminant structurellement le vecteur brute-force RDP direct.

Renforcer RDP au-delà du blocage IP (NLA, RDP Gateway, port non standard)

Le blocage IP réactif est une mesure de mitigation, pas une solution complète. Pour une sécurisation efficace de RDP, combinez plusieurs couches :

Network Level Authentication (NLA) — à activer impérativement. Avec NLA, l'authentification se produit avant l'établissement de la session RDP complète, réduisant la surface d'attaque. Activez via GPO :

# Via PowerShell (registre)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  -Name "UserAuthentication" -Value 1

# Via GPO
# Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services
# → Remote Desktop Session Host → Security
# → "Require use of specific security layer" = SSL
# → "Require user authentication for remote connections" = Enabled

MFA pour RDP — via Azure AD Application Proxy, Duo Security, ou Microsoft Entra MFA. Même si un attaquant obtient les credentials corrects, le second facteur bloque l'accès.

Restriction des connexions RDP par groupe AD :

# Via GPO : Computer Configuration → Windows Settings → Security Settings → Local Policies
# → User Rights Assignment → "Allow log on through Remote Desktop Services"
# Limiter au groupe "RDP Users" plutôt que "Remote Desktop Users" (trop large)

Port RDP non standard — mesure de sécurité par l'obscurité qui réduit le volume de scans automatisés (mais ne remplace pas une vraie sécurisation) :

# Changer le port RDP (nécessite ouverture du nouveau port dans le pare-feu)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
  -Name "PortNumber" -Value 33890

# Ouvrir le nouveau port dans le pare-feu
New-NetFirewallRule -DisplayName "RDP Custom Port" -Direction Inbound -Protocol TCP `
  -LocalPort 33890 -Action Allow

# Fermer le port 3389 standard (si NLA bien configuré)
New-NetFirewallRule -DisplayName "Block RDP Standard" -Direction Inbound -Protocol TCP `
  -LocalPort 3389 -Action Block

VPN obligatoire avant RDP — la solution la plus robuste pour les accès distants : les connexions RDP ne sont acceptées que depuis le réseau interne ou via VPN. Cela élimine structurellement l'exposition Internet du port RDP, rendant le brute-force impossible depuis l'extérieur. Pour approfondir la détection et la réponse aux incidents liés à Active Directory, consultez notre article sur les top 10 des attaques Active Directory ainsi que notre guide d'audit avancé Active Directory.

La documentation Microsoft sur l'audit des événements de connexion et les guides CrowdSec pour la protection RDP complètent utilement ce guide pour les déploiements plus complexes.

FAQ — Blocage brute-force RDP avec PowerShell

Le script PowerShell peut-il bloquer par erreur un administrateur légitime ?

Oui, si l'IP de l'administrateur n'est pas dans la whitelist et qu'il effectue plusieurs tentatives de connexion échouées (mauvais mot de passe, verrouillage de session). C'est pourquoi la whitelist doit être configurée et validée avant tout déploiement en production. En pratique, incluez systématiquement toutes les plages IP du réseau interne, les IPs de vos administrateurs si elles sont fixes, et l'IP de votre VPN d'entreprise. En cas de blocage accidentel, l'administrateur doit se connecter localement au serveur ou via un accès console (IPMI, iDRAC, ILO) pour exécuter Remove-NetFirewallRule et se débloquer.

Quelle est la différence entre ce script et Fail2ban sur Linux ?

Les deux approches sont fonctionnellement similaires : analyse des logs, détection de patterns d'échec, blocage via le pare-feu. Fail2ban sur Linux est plus mature, dispose d'un écosystème de "jails" préconfiguré pour des dizaines de services, et offre une gestion native des durées de ban (unban automatique après X heures). Le script PowerShell présenté ici est plus léger et ne nécessite aucune installation tierce, mais implémente les mêmes concepts. Pour un environnement Windows en production à large échelle, CrowdSec offre des fonctionnalités proches de Fail2ban avec en plus l'intelligence collective partagée.

Comment adapter le script pour détecter le Password Spray plutôt que le brute-force classique ?

Le Password Spray consiste à tester un seul mot de passe sur de nombreux comptes différents, évitant ainsi le déclenchement des politiques de verrouillage de compte. Pour le détecter, modifiez le script pour analyser non plus le nombre d'échecs par IP, mais le nombre de comptes différents ciblés par une même IP. Une IP qui génère des 4625 sur plus de 10 comptes distincts en 10 minutes avec 1-3 tentatives par compte est caractéristique d'un spray. L'Event ID 4648 (explicite credential logon) peut également signaler du Password Spray via des outils comme CrackMapExec.

Le script fonctionne-t-il aussi pour protéger d'autres ports que le RDP (SSH via Bitvise, FTP) ?

Oui, le script peut être adapté pour d'autres services. Modifiez le paramètre LogonType pour cibler les connexions de type 3 (réseau) pour FTP/SSH, et changez le LocalPort dans New-NetFirewallRule (22 pour SSH, 21 pour FTP). Pour SSH via Bitvise ou OpenSSH sur Windows, les événements de log sont différents (journal Applications and Services Logs → OpenSSH) et nécessitent un parser spécifique plutôt que l'Event ID 4625. Adaptez la commande Get-WinEvent pour lire le bon journal et extraire les IPs source du format de log SSH.

Combien de règles de pare-feu Windows peut-on créer avant d'impacter les performances ?

Windows Firewall supporte théoriquement plusieurs milliers de règles, mais en pratique les performances commencent à dégrader au-delà de 500-1000 règles individuelles IP. Pour gérer un grand nombre d'IPs bloquées, utilisez une seule règle de pare-feu avec plusieurs adresses IP dans le champ RemoteAddress plutôt qu'une règle par IP : Set-NetFirewallRule -DisplayName "RDP-BruteForce-Block-All" -RemoteAddress (Get-Content "C:\Scripts\blocked-ips.txt"). Cette approche est bien plus efficace et maintient les performances du pare-feu même avec des milliers d'IPs bloquées. Alternativement, utilisez IPset (via netsh) pour gérer des listes d'IPs à grande échelle.