Durcir le Bureau à distance (RDP) sous Windows

Le Bureau à distance est le moyen d'administration de la plupart des serveurs Windows, et aussi l'un des canaux d'accès initial et de mouvement latéral les plus fréquents dans les incidents de ransomware. Un RDP exposé subit des attaques par force brute ; un RDP interne sert, avec des identifiants volés, à sauter de serveur en serveur. L'essentiel de la défense n'a rien d'exotique : s'authentifier avant qu'une session n'existe, chiffrer avec un certificat de confiance, limiter qui peut se connecter et d'où, et journaliser.

Ce guide fait partie du domaine Protocoles hérités. La protection des identifiants de l'administrateur sur le serveur cible (Restricted Admin et Remote Credential Guard) est un sujet distinct, traité dans RDP sans exposer les identifiants.

Les paramètres en un tableau

Tous les paramètres de stratégie de groupe ci-dessous se trouvent sous Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host, suivi du sous-dossier indiqué.

Les valeurs de registre correspondantes pour l'écouteur RDP se trouvent sous HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp : UserAuthentication = 1 (NLA), SecurityLayer = 2 (TLS), MinEncryptionLevel = 3 (élevé). Les valeurs de stratégie sont écrites sous HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services et sont prioritaires.

Étape 1 : garder RDP hors d'Internet

Aucun paramètre de ce guide ne rend RDP sûr à exposer directement. Pour l'accès distant, utilisez l'une de ces solutions :

• Passerelle Bureau à distance (RD Gateway) avec MFA (par exemple via l'extension NPS pour l'authentification multifacteur Microsoft Entra), qui n'expose que HTTPS.
• Un VPN avec MFA, RDP n'étant joignable que depuis le pool d'adresses du VPN.
• Un service de bastion cloud devant les VM hébergées dans le cloud.

Vérifiez régulièrement votre exposition depuis l'extérieur, et passez en revue les règles NAT des pare-feu pour le port 3389 et tout ce qui y est redirigé. Changer le port d'écoute (PortNumber sous la clé RDP-Tcp) n'est pas un contrôle.

Étape 2 : exiger l'authentification au niveau du réseau

Avec NLA, le client s'authentifie via CredSSP avant que le serveur ne crée une session ou n'affiche un écran d'ouverture de session. Cela supprime la surface d'attaque pré-authentification (les vulnérabilités de type BlueKeep étaient atténuées par NLA) et empêche les utilisateurs anonymes de consommer des ressources de session.

NLA est activée par défaut sur les versions actuelles de Windows, mais elle est souvent désactivée pour « réparer » un problème de connexion, et jamais réactivée. Imposez-la par stratégie, puis corrigez la cause réelle : typiquement un ancien client, un serveur de rebond hors domaine, ou un utilisateur qui doit changer un mot de passe expiré (NLA ne peut pas proposer de changement de mot de passe ; les utilisateurs ont besoin d'un autre moyen pour le faire).

Définissez aussi Encryption Oracle Remediation sur Force Updated Clients sous Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation, pour qu'aucune des deux parties n'accepte d'interlocuteur CredSSP non corrigé.

Étape 3 : utiliser TLS avec un certificat de confiance

Avec la couche de sécurité réglée sur SSL (TLS), chaque connexion est chiffrée en TLS et le serveur prouve son identité par un certificat. Par défaut, ce certificat est auto-signé, si bien que les utilisateurs prennent l'habitude de passer outre l'avertissement, ce qui est exactement ce sur quoi compte un attaquant en position d'intercepteur.

Émettez les certificats RDP depuis votre PKI interne :

1. Dupliquez le modèle Computer dans AD CS, nommez-le (par exemple RDP-Server) et vérifiez que les stratégies d'application incluent Server Authentication (ou l'OID dédié Remote Desktop Authentication 1.3.6.1.4.1.311.54.1.2). Accordez l'inscription automatique aux groupes d'ordinateurs concernés.
2. Définissez Server authentication certificate template sur ce nom de modèle. Les hôtes s'inscrivent automatiquement et lient le certificat à l'écouteur.
3. Sur les clients, laissez Configure server authentication for client (sous Remote Desktop Connection Client) sur Warn me, ou réglez-le sur Do not connect pour les postes d'administration, afin qu'une incohérence de certificat ne soit pas acceptée silencieusement.

Associé au durcissement de TLS et Schannel, cela donne à RDP un canal moderne et authentifié.

Étape 4 : restreindre qui peut se connecter, et d'où

Utilisateurs. Le droit utilisateur Allow log on through Remote Desktop Services (Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment) est accordé par défaut à Administrators et Remote Desktop Users. Définissez-le explicitement par tier de serveurs, sur un petit groupe d'administration. Ajoutez Deny log on through Remote Desktop Services pour les comptes locaux (Local account and member of Administrators group, SID S-1-5-114) et, sur les tiers inférieurs, pour les comptes Tier 0, comme décrit dans le modèle en tiers. Laissez vide le groupe local Remote Desktop Users sur les serveurs, sauf s'il est géré de façon centralisée.

Postes de travail. La plupart des postes utilisateurs n'ont aucun besoin d'accepter RDP. Laissez Allow users to connect remotely désactivé sur ces postes ; le support peut utiliser un outil d'assistance à distance à la place.

Réseaux. Limitez les règles de pare-feu entrantes à votre réseau d'administration ou à vos postes d'accès privilégié (PAW) :

Set-NetFirewallRule -DisplayGroup "Remote Desktop" `
  -RemoteAddress 10.10.50.0/24 -Profile Domain

Faites de même de façon centralisée via la stratégie de pare-feu décrite dans le guide du Pare-feu Windows, qui bloque aussi le RDP entre postes de travail.

Force brute. Windows 11 22H2 et versions ultérieures sont livrés avec une stratégie de verrouillage de compte par défaut (10 tentatives échouées en 10 minutes) pour les comptes locaux. Pour les comptes de domaine, c'est votre stratégie de verrouillage du domaine qui s'applique. Le verrouillage est un filet de sécurité, pas une défense pour un RDP exposé.

Étape 5 : journaliser l'activité RDP

Activez Audit Logon et Audit Other Logon/Logoff Events (succès et échec) dans la stratégie d'audit avancée ; le référentiel de stratégie d'audit couvre les deux. Alertez sur les ouvertures de session RDP de comptes à privilèges hors des PAW, sur le RDP de poste de travail à poste de travail et sur les rafales d'événements 4625.

Ce qui casse

• Changement de mot de passe à l'ouverture de session avec NLA : les utilisateurs dont le mot de passe a expiré ne peuvent pas se connecter tant qu'ils ne l'ont pas réinitialisé ailleurs. Proposez-leur une réinitialisation en libre-service ou un changement via Ctrl+Alt+Fin dans une session fonctionnelle.
• La suppression de la redirection du presse-papiers et des lecteurs agace les administrateurs qui déplacent des fichiers. Fournissez un vrai moyen de transfert de fichiers.
• Anciens clients légers qui ne prennent en charge ni NLA ni TLS 1.2.
• Les limites de durée de session mettent fin aux tâches interactives de longue durée. Exécutez-les en tâches planifiées ou en services, pas dans une session déconnectée.

Vérifier

Get-CimInstance -Namespace root\cimv2\TerminalServices -ClassName Win32_TSGeneralSetting `
  -Filter "TerminalName='RDP-Tcp'" |
  Select-Object UserAuthenticationRequired, SecurityLayer, MinEncryptionLevel, SSLCertificateSHA1Hash
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Get-NetFirewallAddressFilter

Attendez-vous à UserAuthenticationRequired = 1, SecurityLayer = 2, MinEncryptionLevel = 3, et à une empreinte de certificat correspondant à un certificat émis par la PKI dans le magasin personnel de l'ordinateur, et non à un certificat auto-signé. Connectez-vous depuis un PAW et vérifiez l'absence d'avertissement de certificat ; connectez-vous depuis un sous-réseau non administratif et vérifiez que la connexion expire.

Liste de contrôle

• Aucun RDP exposé sur Internet ; accès distant via RD Gateway ou VPN avec MFA
• NLA exigée par stratégie ; Encryption Oracle Remediation réglé sur Force Updated Clients
• Couche de sécurité TLS, niveau de chiffrement élevé, certificats PKI via un modèle
• RDP désactivé sur les postes de travail qui n'en ont pas besoin
• « Allow log on through Remote Desktop Services » limité aux groupes d'administration de chaque tier
• Ouverture de session RDP refusée aux comptes administrateurs locaux (S-1-5-114)
• Règles de pare-feu limitées aux réseaux d'administration
• Limites de durée de session et restrictions de redirection sur les serveurs
• Événements 4624 type 10, 1149 et LocalSessionManager collectés et assortis d'alertes

Ces paramètres protègent le serveur contre le réseau. Pour protéger l'administrateur contre un serveur compromis, poursuivez avec Restricted Admin et Remote Credential Guard.