Sécuriser RDP : protéger un serveur Windows contre les attaques

Un serveur Windows qui arrive sur le réseau avec le port 3389 ouvert ne sera pas attaqué un jour ou l'autre : il l'est en quelques minutes. Les scanners tournent en permanence, ils connaissent chaque plage d'adresses IPv4 et enchaînent mécaniquement les noms d'utilisateur et les mots de passe. Presque tous les incidents de ransomware sur les petits serveurs commencent exactement là : un compte nommé Administrator, un mot de passe que quelqu'un a jugé suffisant, et aucun blocage après le millième essai raté.

Ce guide passe les mesures en revue dans l'ordre de leur efficacité réelle, pas dans l'ordre où on les trouve dans la plupart des articles. Toutes les commandes s'exécutent dans une session PowerShell disposant des droits d'administrateur, sur Windows Server 2016 à 2025.

Pourquoi RDP est la porte la plus attaquée

RDP n'est pas un mauvais protocole. Le problème, c'est qu'il expose un formulaire de connexion complet sur l'internet ouvert et que Windows laisse par défaut le remplir un nombre illimité de fois. Un attaquant n'a besoin d'aucune faille, seulement de patience et d'une liste de mots de passe.

Vous pouvez mesurer en une seule ligne à quel point votre serveur est touché. Comptez les connexions échouées des dernières 24 heures :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Measure-Object | Select-Object -ExpandProperty Count

Un serveur interne sans accessibilité depuis internet se situe généralement à quelques dizaines par jour, surtout des mots de passe oubliés et de vieux comptes de service. Un serveur dont le 3389 est ouvert atteint vite les milliers, voire les dizaines de milliers. Ce chiffre est votre point de référence : après les mesures ci-dessous, il doit chuter de plusieurs ordres de grandeur. Si Get-WinEvent répond « Aucun événement n'a été trouvé correspondant aux critères de sélection spécifiés », c'est que votre serveur ne journalise pas du tout les connexions échouées. Nous corrigeons cela plus bas.

Avant la première modification : sécuriser votre voie de retour

Chacune des mesures qui suivent peut vous verrouiller dehors. Sur un serveur que vous n'atteignez que par RDP, c'est la fin de la session et le début d'une longue soirée. Trois précautions coûtent cinq minutes et évitent exactement cela.

Premièrement : vérifiez que vous disposez d'une console qui fonctionne indépendamment de RDP. Sur les serveurs root KVM de KernelHost, vous trouvez dans l'espace client une console VNC qui regarde directement l'écran de la machine virtuelle. Elle fonctionne encore lorsque le pare-feu, le réseau et le service RDP sont cassés en même temps. Ouvrez-la une fois à titre de test avant de changer quoi que ce soit, pas après.

Deuxièmement : créez un deuxième compte administrateur, pour qu'un identifiant verrouillé ne signifie pas un serveur perdu. Les noms de groupe dépendent de la langue, nous travaillons donc avec les SID fixes (S-1-5-32-544 est le groupe des administrateurs locaux, S-1-5-32-555 celui des utilisateurs du Bureau à distance) :

New-LocalUser -Name 'kh-adm' -Password (Read-Host -AsSecureString -Prompt 'Mot de passe') -FullName 'Compte de maintenance' -PasswordNeverExpires
Add-LocalGroupMember -SID 'S-1-5-32-544' -Member 'kh-adm'
Add-LocalGroupMember -SID 'S-1-5-32-555' -Member 'kh-adm'

La troisième ligne est à proprement parler superflue, car les membres du groupe des administrateurs locaux entrent de toute façon par RDP. Elle ne nuit pas et rend l'intention visible si vous retirez plus tard ce compte du groupe des administrateurs.

Troisièmement : laissez ouverte, pendant toute la bascule, la session RDP dans laquelle vous travaillez, et testez chaque changement avec une deuxième connexion, toute neuve. Une session existante n'est pas coupée immédiatement par de nouvelles règles de pare-feu, alors qu'une nouvelle connexion échoue aussitôt. Vous repérez ainsi l'erreur tant que vous pouvez encore la défaire.

Imposer l'authentification au niveau du réseau

Sans authentification au niveau du réseau (en anglais Network Level Authentication, NLA), le serveur ouvre d'abord une session, dessine un écran de connexion et demande les identifiants ensuite. Chaque tentative de connexion anonyme coûte donc de la RAM et du CPU, et tout le code situé derrière l'écran de connexion est accessible avant la moindre authentification. C'est précisément là que se logeaient les grosses failles RDP du passé.

Avec NLA, le serveur vérifie les identifiants via CredSSP avant même qu'une session existe. Un bot qui ne possède pas de données valides n'obtient rien d'autre qu'une connexion TLS refusée.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 1
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value 2

SecurityLayer à 2 impose TLS pour la négociation. La valeur 1 (négocier) laisse un client retomber au besoin sur l'ancienne couche de sécurité RDP, 0 est cette ancienne couche sans TLS. Pour vérifier :

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' | Select-Object UserAuthentication, SecurityLayer

Aucun redémarrage n'est nécessaire, les valeurs s'appliquent à chaque connexion nouvellement établie. Les sessions existantes se poursuivent sans changement, ce qui est pratique si vous venez justement de verrouiller un client dehors.

Quand plus personne ne parvient à se connecter

Deux symptômes reviennent régulièrement après l'activation de NLA.

« L'ordinateur distant nécessite une authentification au niveau du réseau, que votre ordinateur ne prend pas en charge. Contactez l'administrateur système ou le support technique. » Le client est trop ancien ou ne parle pas CredSSP. Les clients Windows actuels en sont capables depuis des années. Sous Linux, FreeRDP réclame l'option /sec:nla, Remmina le réglage du protocole de sécurité sur NLA, et les clients macOS très anciens échouent systématiquement. La solution passe toujours par un client plus récent, jamais par la désactivation de NLA.

La connexion échoue alors que le mot de passe est correct. C'est le piège que la plupart des guides passent sous silence : si un compte porte l'option « L'utilisateur doit changer le mot de passe à la prochaine ouverture de session » ou si son mot de passe a expiré, ce compte ne peut plus du tout se connecter avec NLA actif. CredSSP ne connaît pas le changement de mot de passe, c'est prévu ainsi. Selon la version, le serveur signale une erreur d'authentification ou simplement des identifiants incorrects. La porte de sortie passe par la console de l'espace client, ou bien vous exemptez les comptes de maintenance de l'expiration :

Set-LocalUser -Name 'kh-adm' -PasswordNeverExpires $true

Verrouillage de compte : l'interrupteur le plus efficace

Un mot de passe solide protège contre la devinette, un verrouillage de compte protège contre la devinette illimitée. Sans lui, un attaquant dispose de millions d'essais par semaine, avec lui il en a dix par quart d'heure. Définissez le seuil, la durée de verrouillage et la fenêtre d'observation en un seul appel, sinon Windows refuse la durée tant que le seuil est encore à 0 :

net accounts /lockoutthreshold:10 /lockoutduration:15 /lockoutwindow:15

La durée de verrouillage doit toujours être supérieure ou égale à la fenêtre d'observation. Contrôlez le résultat :

net accounts

Les versions récentes de Windows livrent déjà une valeur par défaut de cet ordre de grandeur, mais pas les installations plus anciennes ni beaucoup d'images système fournies par les hébergeurs. Vérifier ne coûte rien.

Inclure le compte Administrateur intégré

Historiquement, le compte que tout attaquant essaie en premier était justement exempté du verrouillage. Il existe pour cela la stratégie « Autoriser le verrouillage du compte Administrateur ». Elle suppose toutefois une version récente, à savoir Windows 11 22H2 ou Windows Server 2025. Sur un Windows Server 2022 (build 20348), l'export de la stratégie de sécurité ne contient pas du tout la ligne AllowAdministratorLockout : dans la section [System Access] on n'y trouve que des valeurs comme LockoutBadCount et MinimumPasswordLength. Vérifiez donc d'abord ce que votre système exporte réellement :

secedit /export /cfg C:\secpol.inf
Select-String -Path C:\secpol.inf -Pattern 'AllowAdministratorLockout'

Si aucune occurrence ne remonte, votre build ne connaît pas cette stratégie et la section est réglée pour vous. C'est exactement là que se trouve le piège créé par la plupart des guides : la ligne habituelle avec -replace remplace une chaîne qui n'existe pas dans le fichier, sans signaler la moindre erreur, et le secedit /configure qui suit se termine avec succès. Vous croyez ensuite que le verrouillage du compte Administrateur est actif alors que rien n'a changé.

Sur un build qui connaît la stratégie, vous modifiez la ligne si elle existe et vous l'insérez sinon. Cette version couvre les deux cas :

$c = Get-Content C:\secpol.inf
if ($c -notmatch 'AllowAdministratorLockout') { $c = $c -replace '(LockoutBadCount = \d+)', "`$1`r`nAllowAdministratorLockout = 1" } else { $c = $c -replace 'AllowAdministratorLockout = 0','AllowAdministratorLockout = 1' }
$c | Set-Content C:\secpol.inf -Encoding Unicode

Le -Encoding Unicode est obligatoire et ce n'est pas un détail : le fichier INF doit être en UTF-16 LE avec byte order mark. Dans Windows PowerShell 5.1, Set-Content écrit sinon en ANSI, et secedit refuse le fichier. Avant la réécriture, secedit /validate C:\secpol.inf contrôle le fichier, ensuite :

secedit /configure /db C:\Windows\security\local.sdb /cfg C:\secpol.inf /areas SECURITYPOLICY

Et relisez impérativement après coup, car une exécution réussie de secedit ne prouve rien à cet endroit. Exportez à nouveau la stratégie dans un deuxième fichier et regardez si la valeur y figure bien avec 1.

Sur un contrôleur de domaine, ces réglages locaux ne s'appliquent pas. La stratégie de verrouillage y appartient à la Default Domain Policy, sous Configuration ordinateur, Paramètres Windows, Paramètres de sécurité, Stratégies de comptes.

Le revers de la médaille et comment revenir

Un verrouillage de compte est aussi une arme contre vous : celui qui connaît votre nom d'utilisateur peut le maintenir verrouillé en permanence en envoyant dix mots de passe faux toutes les 15 minutes. C'est exactement pour cela que le verrouillage n'est que la deuxième ligne de défense, la première étant la restriction par adresse IP décrite dans la section suivante.

Lorsqu'un compte local est verrouillé, le client annonce en substance « Le compte référencé est actuellement verrouillé et ne peut pas être utilisé pour ouvrir une session ». Le retour le plus simple consiste à attendre, car Windows déverrouille de lui-même à l'expiration de la durée. Si vous ne voulez pas attendre, déverrouillez depuis la console :

$u = [ADSI]"WinNT://./kh-adm,user"; $u.IsAccountLocked = $false; $u.SetInfo()

Dans Active Directory, c'est plus court avec Unlock-ADAccount -Identity kh-adm.

Des mots de passe qui rendent le verrouillage utile

Dix essais par quart d'heure ne sont un obstacle que si le mot de passe ne figure pas en troisième position de toutes les listes. Vous définissez la longueur minimale et la complexité ainsi :

net accounts /minpwlen:14

La règle de complexité se trouve à nouveau dans la stratégie de sécurité, section [System Access], clé PasswordComplexity = 1. La démarche est la même que plus haut avec secedit.

Deux points issus de la pratique. Premièrement, le changement de mot de passe imposé tous les 30 jours n'apporte manifestement pas grand-chose et provoque, combiné à NLA, exactement le problème de connexion de la section précédente. Des mots de passe longs, définis une seule fois et rangés dans un gestionnaire de mots de passe, valent nettement mieux. Deuxièmement, la stratégie ne vaut que pour les mots de passe nouvellement définis. Un mot de passe existant de six caractères reste valable jusqu'à ce que vous le changiez.

Limiter l'accès à des adresses IP connues

C'est la mesure qui met vraiment fin au trafic d'attaque, et de façon complète. Toutes les règles du groupe Bureau à distance peuvent être restreintes à une liste d'adresses. Utilisez l'identifiant de groupe neutre du point de vue de la langue, pour que le script fonctionne aussi sur des installations anglaises :

Get-NetFirewallRule -Group '@FirewallAPI.dll,-28752' | Select-Object Name, DisplayName, Enabled, Profile

Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress @('203.0.113.10','198.51.100.0/24')

Attendez-vous à plus de résultats que vous n'avez de règles en tête. -Group touche toutes les règles du groupe : sur un système de test, cela faisait six règles, y compris les règles fantômes et des copies supplémentaires nommées par GUID dans le profil Public. C'est voulu et c'est correct, sinon l'une des copies resterait ouverte. La liste préalable avec Get-NetFirewallRule vous montre à l'avance ce qui sera concerné.

Contrôle des adresses réellement enregistrées :

Get-NetFirewallRule -Group '@FirewallAPI.dll,-28752' | Get-NetFirewallAddressFilter

Si vous avez changé le port, les règles intégrées ne mordent plus, car elles sont fixées sur 3389. Il vous faut alors votre propre règle :

New-NetFirewallRule -DisplayName 'RDP restreint' -Direction Inbound -Protocol TCP -LocalPort 34567 -RemoteAddress '203.0.113.10' -Action Allow -Profile Any

La bouée de sauvetage contre votre propre règle de pare-feu

Celui qui recopie mal son adresse IP ou qui saisit une adresse dynamique se verrouille dehors à coup sûr. Créez donc au préalable une tâche qui annule la restriction d'elle-même au bout de dix minutes :

Set-Content -Path C:\rdp-secours.ps1 -Value "Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress Any"

Register-ScheduledTask -TaskName 'RDP-Secours' -Action (New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-ExecutionPolicy Bypass -File C:\rdp-secours.ps1') -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(10)) -User 'SYSTEM' -RunLevel Highest

Si la nouvelle connexion fonctionne, supprimez à nouveau la tâche :

Unregister-ScheduledTask -TaskName 'RDP-Secours' -Confirm:$false

Si vous n'avez pas d'adresse IP fixe, la solution propre consiste à ne pas exposer RDP sur internet du tout, mais à y accéder par un VPN. Notre guide sur le serveur VPN WireGuard explique comment le mettre en place. Le serveur n'écoute alors plus que sur l'adresse VPN, et le port 3389 disparaît complètement d'internet.

Changer le port et ce que cela apporte vraiment

Un autre port n'est pas une mesure de sécurité, c'est une mesure antibruit. La grande masse des bots ne scanne que le 3389 et ne vous trouve plus ensuite, ce qui fait en général chuter fortement votre compteur 4625 et rend les journaux d'événements à nouveau lisibles. Celui qui cherche de façon ciblée trouve quand même le service : les moteurs de recherche de services exposés reconnaissent RDP à son empreinte protocolaire, quel que soit le port, et un scan complet des 65535 ports prend quelques secondes.

Le changement de port a donc du sens en complément, mais jamais en remplacement de NLA, du verrouillage de compte et de la restriction d'adresses. Nous avons décrit séparément la mise en œuvre pratique, y compris la partie que presque tous les guides ratent, à savoir le faire sans redémarrage : changer le port RDP sans redémarrage. Pensez dans tous les cas à créer une règle de pare-feu pour le nouveau port avant de basculer le service.

Exploiter les journaux de connexion

Il faut d'abord que la journalisation soit activée. Les noms de sous-catégories d'auditpol sont traduits, une commande en anglais échoue donc sur un système en français avec « Erreur 0x00000057 : Le paramètre est incorrect. » Le GUID, lui, fonctionne dans toutes les versions linguistiques :

auditpol /set '/subcategory:{0CCE9215-69AE-11D9-BED3-505054503030}' /success:enable /failure:enable

auditpol /get '/subcategory:{0CCE9215-69AE-11D9-BED3-505054503030}'

Les apostrophes simples autour du paramètre entier ne sont pas une coquetterie, elles sont obligatoires. PowerShell interprète sinon les accolades comme un bloc de script et les supprime : d'un argument on passe à trois, et auditpol s'interrompt avec Erreur 0x00000057 : Le paramètre est incorrect. et le code de sortie 87, suivi du texte d'aide. Dans cmd.exe, l'écriture sans apostrophes fonctionne, dans PowerShell non. Avec les apostrophes, les deux passent avec le code de sortie 0, et la requête de contrôle répond alors Ouverture de session Succès et échec.

Sous le feu, le journal de sécurité se remplit en quelques heures et écrase justement les entrées dont vous avez besoin. Donnez-lui plus de place :

wevtutil sl Security /ms:1073741824

Ensuite, les adresses sources les plus fréquentes de la semaine écoulée, triées par nombre. La variante qui passe par la structure XML est la plus robuste, car elle ne dépend pas de l'ordre des champs :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object { $_.Name -eq 'IpAddress' } | Select-Object -ExpandProperty '#text' } | Group-Object | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

Le -ErrorAction SilentlyContinue a sa place dans chacun de ces appels. Get-WinEvent s'arrête sur une erreur rouge dès qu'aucun événement correspondant n'existe sur la période : « Aucun événement n'a été trouvé correspondant aux critères de sélection spécifiés. » Sur un serveur fraîchement sécurisé, c'est précisément le cas normal, la commande échoue donc exactement au moment du succès que ce guide vise.

La question décisive n'est cependant pas de savoir qui a essayé, mais si quelqu'un a réussi. Les connexions Bureau à distance réussies portent l'ID d'événement 4624 avec le type d'ouverture de session 10 (RemoteInteractive) :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue | Where-Object { $_.Properties[8].Value -eq 10 } | Select-Object TimeCreated, @{n='Utilisateur';e={$_.Properties[5].Value}}, @{n='Source';e={$_.Properties[18].Value}} | Format-Table -AutoSize

Si vous y voyez un nom d'utilisateur ou une adresse source que vous ne pouvez rattacher à rien, quelqu'un a trouvé un mot de passe valide. Affiner les stratégies ne sert alors plus à rien, le serveur doit être réinstallé.

Un coup d'œil dans le journal RDP dédié vaut également la peine. L'événement 1149 nomme l'utilisateur, le domaine et l'adresse source de chaque connexion autorisée, en une seule ligne :

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -FilterXPath '*[System[EventID=1149]]' -MaxEvents 25 | Format-List TimeCreated, Message

Renommer le compte Administrateur, mieux encore le désactiver

Le compte Administrateur intégré est le seul nom d'utilisateur que tout attaquant connaît à coup sûr. Le renommer ne coûte rien :

Rename-LocalUser -Name 'Administrator' -NewName 'kh-svc'

Soyez toutefois conscient de la limite : le SID du compte se termine toujours par -500, et tout accès authentifié peut résoudre le nouveau nom par ce biais. Le renommage agit contre les bots de masse, pas contre un attaquant ciblé qui a déjà un pied dans la porte. Voici comment retrouver le compte malgré son nouveau nom :

Get-LocalUser | Where-Object { $_.SID.Value -like '*-500' } | Select-Object Name, Enabled

Nettement plus efficace : désactiver complètement le compte intégré, une fois que votre propre compte administrateur de la section « sécuriser votre voie de retour » fonctionne de façon avérée. Testez la connexion avec le nouveau compte dans une deuxième session, seulement ensuite :

Disable-LocalUser -Name 'kh-svc'

Restreignez en plus l'accès RDP aux personnes qui en ont besoin. Par défaut, tout membre du groupe des administrateurs locaux peut entrer par RDP, y compris des comptes de service qui ne devraient jamais le faire. Voici qui en a le droit actuellement :

Get-LocalGroupMember -SID 'S-1-5-32-555'

Comment savoir que cela a vraiment fonctionné

Cocher plutôt qu'espérer. Ces cinq vérifications vous disent si la bascule est bien passée :

1. NLA : Get-ItemProperty sur RDP-Tcp renvoie UserAuthentication : 1 et SecurityLayer : 2. Une nouvelle connexion demande désormais les identifiants avant l'établissement de la connexion, et non plus sur un écran de connexion affiché dans la fenêtre.
2. Verrouillage : net accounts affiche un seuil de verrouillage différent de « Jamais ». Contre-test avec un compte jetable : après le onzième mot de passe faux, le client doit afficher le message de verrouillage, et non plus celui sur des identifiants incorrects.
3. Pare-feu : Get-NetFirewallAddressFilter affiche vos adresses au lieu de Any. Un test de connexion depuis une adresse étrangère doit aboutir à un dépassement de délai, pas à une invite de connexion. Vérifiez-le depuis l'extérieur avec Test-NetConnection -ComputerName votreserveur -Port 3389, le résultat doit être TcpTestSucceeded : False.
4. Journaux : auditpol /get signale succès et échec pour la sous-catégorie.
5. Le chiffre : comptez à nouveau les événements 4625 24 heures après la bascule. Il doit être nettement plus bas. S'il reste élevé, c'est qu'une de vos règles ne mord pas, le plus souvent parce qu'il existe une deuxième règle de pare-feu, plus permissive, pour le port 3389, créée par une image système d'hébergeur ou par l'installation d'un logiciel. Cette ligne la trouve : Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 3389 } | Get-NetFirewallRule | Select-Object DisplayName, Enabled, Profile, Action. L'ordre dans le pipeline est volontaire. Si vous l'inversez et envoyez d'abord toutes les règles de pare-feu dans Get-NetFirewallPortFilter, l'appel prend, mesure à l'appui, environ 12 secondes au lieu d'une, et surtout le nom de la règle manque dans la sortie : vous voyez alors quatre résultats sans apprendre de quelles règles il s'agit.

Si vous êtes de toute façon en train d'installer un serveur neuf, traitez ces points dès le départ plutôt que de les rajouter après coup. Pour les systèmes Linux, le même schéma s'applique avec SSH à la place de RDP, décrit dans sécuriser SSH et mettre en place la connexion par clé, et l'ordre des premières étapes se trouve dans notre checklist pour les nouveaux serveurs root.

Ce que le durcissement de RDP ne couvre pas

Les mesures ci-dessus protègent contre les tentatives de connexion. Elles ne protègent pas contre les attaques volumétriques qui visent à rendre le serveur injoignable via son raccordement réseau. Dans ce cas, seul un filtrage dans le réseau en amont aide. Le fonctionnement de ces attaques est expliqué dans qu'est-ce qu'une attaque DDoS, et les précautions qui restent utiles côté serveur dans protéger un serveur contre les attaques DDoS. Tous les serveurs de KernelHost se trouvent dans le datacenter maincubes à Francfort-sur-le-Main, derrière un filtrage qui intercepte le trafic d'attaque avant même le serveur.

Et elles ne remplacent pas une sauvegarde. Un serveur sur lequel quelqu'un s'est connecté avec succès n'est plus digne de confiance, quelle que soit la rapidité avec laquelle vous changez ensuite le mot de passe. Le seul retour fiable est une sauvegarde antérieure à l'incident.