Sécurité RDP : 9 étapes de durcissement avant d’ouvrir le port 3389

Règles de base : ce que « sécuriser RDP » signifie réellement

« Sécuriser RDP » ce n’est pas « changer le port » ou « bloquer la Chine ». Sécuriser RDP signifie :

• Vous contrôlez qui peut atteindre le service (chemin réseau, pas des impressions).
• Vous contrôlez qui peut s’authentifier (MFA, périmètre des comptes, pas de comptes admin partagés).
• Vous contrôlez ce qu’ils peuvent faire après la connexion (principe du moindre privilège, JIT quand possible).
• Vous pouvez détecter et réagir (logs, alertes, traces judiciaires pour forensique).
• Vous pouvez récupérer (sauvegardes, logs immuables, playbooks de reconstruction).

RDP n’est pas spécial. C’est juste un protocole d’administration à distance avec une longue traîne de paramètres hérités, une énorme base installée et l’habitude d’être exposé
en cas d’urgence. Cela le rend dangereux sur le plan opérationnel : il est activé sous stress, par des personnes fatiguées, et ensuite il reste activé.

Une citation à garder sous les yeux (idée paraphrasée) : L’espoir n’est pas une stratégie — souvent attribuée aux responsables opérations en fiabilité.
Qu’on en retrouve ou non un auteur unique, l’idée est claire : construisez des contrôles que vous pouvez vérifier, pas des intentions que vous ne pouvez pas.

Faits intéressants et courte histoire des abus de RDP

Un peu de contexte aide à faire les bons compromis et à ignorer les mauvais conseils :

1. RDP existe depuis la fin des années 1990 (ère Windows NT Terminal Server). Il est plus ancien que beaucoup de programmes de sécurité « modernes ».
2. Le port 3389 est l’un des ports les plus scannés sur Internet, car c’est une cible interactive à haute valeur et facile à identifier.
3. Network Level Authentication (NLA) a déplacé l’authentification plus tôt dans le processus de connexion, réduisant l’abus de ressources et certains risques pré-auth.
4. « Changer le port RDP » n’est pas un contrôle. Cela réduit le bruit, pas le risque. Les scanners le trouvent de toute façon via la détection de service.
5. Le credential stuffing a empiré la situation : mots de passe fuités + RDP exposé = connexions « légitimes » qui paraissent normales si vous n’avez pas de baseline.
6. BlueKeep (CVE-2019-0708) a rappelé que RDP a eu des failles de type ver. La discipline de patch est importante même si vous « ne l’utilisez qu’en interne ».
7. Les passerelles RDP existent pour une raison : centraliser la politique, le MFA et les logs plutôt que de répandre 3389 exposé partout.
8. TLS compte pour RDP. Une négociation mal configurée (ou des paramètres anciens) peut rétrograder silencieusement la sécurité et provoquer des comportements clients étranges.
9. Les attaquants n’ont pas besoin d’être admins au départ. Beaucoup d’intrusions par ransomware commencent par une session RDP à faible privilège qui s’élève ensuite via des outils et des déplacements latéraux.

Blague #1 : Ouvrir le 3389 sur Internet sans contrôles, c’est comme laisser votre voiture en marche avec les clés dessus — sauf que votre voiture contient aussi la paie.

Les 9 étapes de durcissement (à faire avant que 3389 soit actif)

Tâches pratiques avec commandes, sorties et décisions (12+)

Voici de vraies tâches opérateur. Beaucoup proviennent d’un jump host Linux ou d’un nœud de supervision parce que c’est là que vous pouvez sonder en toute sécurité.
Pour la configuration côté Windows, la vérification se fait souvent « vue de l’extérieur ».

Task 1: Confirmer l’exposition de 3389 depuis l’endroit d’où viennent réellement les attaquants

cr0x@server:~$ nc -vz rdp01.corp.example 3389
Connection to rdp01.corp.example 3389 port [tcp/ms-wbt-server] succeeded!

Ce que cela signifie : Le port est joignable depuis votre emplacement réseau actuel.

Décision : Si c’est depuis un réseau public et que vous n’aviez pas l’intention d’exposer, corrigez le firewall/NSG en périphérie maintenant. Si l’exposition est intentionnelle, passez à la validation des contrôles.

Task 2: Identifier si le service est bien RDP (et pas « quelque chose sur 3389 »)

cr0x@server:~$ nmap -Pn -p 3389 -sV --script rdp-enum-encryption rdp01.corp.example
Starting Nmap 7.94 ( https://nmap.org ) at 2026-02-05 12:02 UTC
Nmap scan report for rdp01.corp.example (203.0.113.10)
PORT     STATE SERVICE       VERSION
3389/tcp open  ms-wbt-server Microsoft Terminal Services
| rdp-enum-encryption:
|   Security layer
|     CredSSP (NLA): SUCCESS
|     TLS: SUCCESS
|     RDP: SUCCESS
|   RDP Encryption level: Client Compatible
|_  TLS Encryption: 1.2
Service detection performed. Please report any incorrect results.
Nmap done: 1 IP address (1 host up) scanned in 9.71 seconds

Ce que cela signifie : NLA et TLS sont supportés ; le niveau de chiffrement « Client Compatible » peut autoriser des options plus faibles selon les clients/politiques.

Décision : Si TLS est absent ou si NLA échoue, n’exposez pas. Si TLS est en 1.0/1.1, corrigez la politique. Envisagez d’imposer un chiffrement supérieur et de restreindre les clients legacy.

Task 3: Vérifier si une passerelle est en amont (vous voulez que ce soit le cas)

cr0x@server:~$ nmap -Pn -p 443 -sV rdg01.corp.example
Starting Nmap 7.94 ( https://nmap.org ) at 2026-02-05 12:04 UTC
Nmap scan report for rdg01.corp.example (203.0.113.20)
PORT    STATE SERVICE  VERSION
443/tcp open  ssl/http Microsoft IIS httpd 10.0
Service detection performed. Please report any incorrect results.
Nmap done: 1 IP address (1 host up) scanned in 8.11 seconds

Ce que cela signifie : RD Gateway utilise typiquement HTTPS via IIS. Voir IIS sur le port 443 est un bon signe, pas une preuve.

Décision : Privilégiez « RDP uniquement via gateway/VPN ». Si vous ne pouvez pas confirmer le chemin via la passerelle, supposez que les gens la contourneront et exposeront 3389 directement.

Task 4: Valider la santé du certificat TLS (expiration et chaîne)

cr0x@server:~$ echo | openssl s_client -connect rdg01.corp.example:443 -servername rdg01.corp.example 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = rdg01.corp.example
issuer=CN = Corp Issuing CA 01
notBefore=Jan 10 00:00:00 2026 GMT
notAfter=Apr 10 23:59:59 2026 GMT

Ce que cela signifie : Le certificat est valide maintenant et expirera bientôt.

Décision : Si l’expiration est dans votre fenêtre opérationnelle (par exemple 14–30 jours selon la politique), planifiez le renouvellement et mettez à jour la surveillance. Si l’émetteur est inattendu, investiguez un MITM/proxy ou une mauvaise configuration.

Task 5: Vérifier quelles versions/chiffres TLS la passerelle négociera

cr0x@server:~$ nmap -Pn -p 443 --script ssl-enum-ciphers rdg01.corp.example
Starting Nmap 7.94 ( https://nmap.org ) at 2026-02-05 12:06 UTC
Nmap scan report for rdg01.corp.example (203.0.113.20)
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|   TLSv1.3:
|     ciphers:
|       TLS_AES_256_GCM_SHA384 - A
|       TLS_AES_128_GCM_SHA256 - A
|_  least strength: A
Nmap done: 1 IP address (1 host up) scanned in 12.44 seconds

Ce que cela signifie : TLS moderne uniquement, chiffrements forts. C’est ce que vous voulez pour une couche d’accès exposée sur Internet.

Décision : Si TLSv1.0/1.1 apparaît, désactivez-les sauf si vous supportez intentionnellement des clients musée (et si c’est le cas, isolez-les).

Task 6: Confirmer la politique du pare-feu depuis un hôte Linux (vérification locale)

cr0x@server:~$ sudo iptables -S | sed -n '1,20p'
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -s 198.51.100.0/24 --dport 443 -j ACCEPT
-A INPUT -p tcp --dport 22 -j ACCEPT

Ce que cela signifie : Politique par défaut : drop inbound ; seules des sources spécifiques peuvent atteindre le 443 ; 22 ouvert (espérons restreint ailleurs).

Décision : Assurez-vous que 3389 n’est pas ouvert largement sur un edge ou le pare-feu de l’hôte. Si SSH est ouvert, imposez l’auth par clé et des restrictions de source aussi — les attaquants ne se soucient pas de la porte que vous avez laissée déverrouillée.

Task 7: Détecter des tentatives de brute-force dans les logs de la passerelle (agrégateur Linux)

cr0x@server:~$ sudo zgrep -h "failed" /var/log/rdg/rdg-*.log | tail -n 5
2026-02-05T11:58:12Z auth failed user=administrator src=203.0.113.77 reason=bad_password
2026-02-05T11:58:13Z auth failed user=administrator src=203.0.113.77 reason=bad_password
2026-02-05T11:58:14Z auth failed user=administrator src=203.0.113.77 reason=bad_password
2026-02-05T11:58:15Z auth failed user=administrator src=203.0.113.77 reason=bad_password
2026-02-05T11:58:16Z auth failed user=administrator src=203.0.113.77 reason=bad_password

Ce que cela signifie : Échecs répétés depuis une IP : modèle classique de brute-force.

Décision : Bloquez la source en périphérie (temporairement) et assurez-vous que le MFA est imposé. Vérifiez aussi si « administrator » est un compte activé ; si oui, c’est un signe de mauvaise politique.

Task 8: Vérifier le rythme des sources suspectes et décider s’il s’agit d’une pulvérisation

cr0x@server:~$ sudo awk '{print $7}' /var/log/rdg/rdg-2026-02-05.log | sort | uniq -c | sort -nr | head
  842 src=203.0.113.77
  190 src=203.0.113.88
   74 src=198.51.100.19
   12 src=192.0.2.44

Ce que cela signifie : Un petit ensemble de sources représente la majorité des tentatives.

Décision : Appliquez des bans automatisés pour les principaux contrevenants, puis recherchez des pulvérisations distribuées à faible débit sur de nombreuses IP (cela nécessite MFA et détection plus intelligente, pas seulement du blocage).

Task 9: Confirmer la synchronisation horaire (les échecs Kerberos/NLA ne sont pas toujours des « attaques »)

cr0x@server:~$ timedatectl
               Local time: Wed 2026-02-05 12:10:31 UTC
           Universal time: Wed 2026-02-05 12:10:31 UTC
                 RTC time: Wed 2026-02-05 12:10:31 UTC
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : Cet hôte est synchronisé dans le temps. Bon point de base pour corréler les logs et pour les protocoles d’authentification.

Décision : Si « System clock synchronized: no », corrigez le NTP. Si les clients/serveurs Windows dérivent, NLA et Kerberos peuvent échouer de façons qui ressemblent à des problèmes d’identifiants.

Task 10: Vérifier la cohérence DNS et reverse DNS (impacte la politique et les logs)

cr0x@server:~$ dig +short rdp01.corp.example
203.0.113.10

cr0x@server:~$ dig +short -x 203.0.113.10
rdp01.corp.example.

Ce que cela signifie : Forward et reverse correspondent. Cela facilite des logs propres et certains moteurs de politique.

Décision : Si le reverse est manquant ou erroné, corrigez-le. Vous ne voulez pas que l’équipe IR se dispute sur l’identité d’un hôte pendant une intrusion.

Task 11: Valider que seules les réseaux attendus peuvent atteindre le service (depuis plusieurs points de vue)

cr0x@server:~$ for ip in 203.0.113.10 203.0.113.11; do echo "== $ip =="; nc -w2 -vz $ip 3389; done
== 203.0.113.10 ==
Connection to 203.0.113.10 3389 port [tcp/ms-wbt-server] succeeded!
== 203.0.113.11 ==
nc: connect to 203.0.113.11 port 3389 (tcp) timed out: Operation now in progress

Ce que cela signifie : Un hôte est exposé ; l’autre ne l’est pas. Cette différence peut être intentionnelle ou accidentelle.

Décision : Si les schémas d’exposition ne correspondent pas à votre conception, arrêtez-vous et réconciliez les règles de firewall/NSG. L’exposition incohérente crée des « chemins d’administration fantômes ».

Task 12: Inspecter les connexions actives (repérer des sources inattendues)

cr0x@server:~$ sudo ss -ntp | grep ':3389' | head
ESTAB 0 0 10.0.10.21:3389 10.0.50.14:52144 users:(("TermService",pid=1460,fd=320))
ESTAB 0 0 10.0.10.21:3389 10.0.70.55:50812 users:(("TermService",pid=1460,fd=329))

Ce que cela signifie : Deux sessions actives. Si ces sous-réseaux sources ne sont pas vos réseaux admin, vous pourriez avoir un déplacement latéral.

Décision : Vérifiez ces IP client par rapport aux travaux enregistrés et à votre liste blanche. Si inconnues, isolez l’hôte et enquêtez immédiatement sur les logs d’authentification.

Task 13: Confirmer que votre SIEM/collecteur reçoit ce que vous pensez

cr0x@server:~$ sudo journalctl -u rsyslog --since "10 minutes ago" | tail -n 6
Feb 05 12:03:18 log01 rsyslogd[912]: action 'action-1-builtin:omfwd' resumed
Feb 05 12:03:19 log01 rsyslogd[912]: imuxsock begins to listen for messages
Feb 05 12:03:20 log01 rsyslogd[912]: message repeated 12 times: [action 'action-1-builtin:omfwd' resumed]
Feb 05 12:06:21 log01 rsyslogd[912]: omfwd: remote server at 10.0.1.50 port 6514 is up
Feb 05 12:06:22 log01 rsyslogd[912]: action 'action-1-builtin:omfwd' resumed
Feb 05 12:10:02 log01 rsyslogd[912]: rsyslogd was HUPed

Ce que cela signifie : Le forwarding est en place. C’est une vérification du transport, pas du contenu.

Décision : Si le forwarding flirte ou redevient instable, vous n’avez pas de piste d’audit fiable. Réparez la stabilité du transport avant de déclarer le service « prêt ».

Task 14: Vérification rapide de la posture vulnérable de l’endpoint exposé (sanity check)

cr0x@server:~$ nmap -Pn -p 3389 --script rdp-vuln-ms12-020 rdp01.corp.example
Starting Nmap 7.94 ( https://nmap.org ) at 2026-02-05 12:12 UTC
Nmap scan report for rdp01.corp.example (203.0.113.10)
PORT     STATE SERVICE
3389/tcp open  ms-wbt-server
| rdp-vuln-ms12-020:
|   VULNERABLE:
|   Remote Desktop Protocol Server Man-in-the-Middle Weakness
|     State: NOT VULNERABLE
|_    IDs:  CVE:CVE-2012-0002
Nmap done: 1 IP address (1 host up) scanned in 10.03 seconds

Ce que cela signifie : Ce contrôle d’une ancienne vulnération signale « non vulnérable ». Bien, mais ce n’est pas une évaluation complète.

Décision : Si des checks vuln RDP signalent un problème, stoppez l’exposition et patchez. Si propre, continuez — mais traitez le patching comme continu, pas comme une porte unique.

Blague #2 : « Nous n’ouvrirons 3389 que pour une heure » est le type d’optimisme de planification généralement réservé aux migrations de base de données.

Playbook de diagnostic rapide (trouver le goulot en quelques minutes)

Quand RDP « ne fonctionne pas », les gens arguent en cercle : pare-feu vs. identifiants vs. certificat vs. « Windows qui est Windows ».
N’entrez pas dans la dispute. Triez avec une séquence qui réduit l’incertitude rapidement.

Premier : puis-je atteindre le port depuis le même réseau que l’utilisateur ?

• Vérification : Test de connexion TCP sur 3389 (ou sur 443 si vous utilisez RDG).
• Signal : Refus immédiat vs. timeout vs. succès.
• Interprétation :
  • Timeout signifie généralement chemin réseau/pare-feu/NSG/routage.
  • Refus suggère que l’hôte est joignable mais que le service n’écoute pas (ou rejet local du pare-feu).
  • Succès signifie que vous êtes dans la phase d’auth/TLS/politique.

Second : utilisons-nous le chemin d’accès prévu (VPN/RDG) ou y a-t-il un contournement ?

• Vérification : Le client se connecte-t-il à un FQDN de passerelle sur le 443, ou directement au serveur sur 3389 ?
• Signal : Les logs existent sur la passerelle vs. seulement sur l’endpoint.
• Décision : Si un contournement existe, fermez-le. Vos contrôles ne servent à rien si les utilisateurs contournent leur chemin.

Troisième : est-ce de l’authentification, de l’autorisation ou de la politique ?

• Vérification : Échecs de connexion dans les logs de sécurité ; erreurs NLA/CredSSP ; appartenance aux groupes « Remote Desktop Users ».
• Signal : Mots de passe mauvais répétés vs. « utilisateur non autorisé » vs. échecs de challenge MFA.
• Décision : Réparez la plus petite chose qui fasse respecter la politique : corriger l’appartenance à un groupe ; imposer le MFA ; supprimer les anciennes exceptions.

Quatrième : est-ce une friction TLS/certificat ?

• Vérification : Résultats de la poignée de main TLS et validité de la chaîne de certificats sur la passerelle.
• Signal : Invite client concernant l’identité, échecs de handshake, ou fallback silencieux vers des modes non sécurisés.
• Décision : Remplacez/renouvelez le certificat, corrigez la chaîne, désactivez les TLS legacy. N’apprenez pas aux utilisateurs à ignorer les avertissements.

Cinquième : est-ce de la performance (CPU, mémoire, disque, stockage de profils, perte réseau) ?

• Vérification : Saturation CPU de l’hôte, IO disque, lenteur des conteneurs de profil/FSLogix/profil itinérant ; perte de paquets et problèmes MTU sur VPN.
• Décision : Si c’est la perf, ne desserrez pas la sécurité pour « faire fonctionner ». Ajoutez de la capacité, réparez le stockage ou ajustez la taille des session hosts.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit #1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait une politique : « RDP n’est ouvert qu’interne ». L’équipe y croyait, car le diagramme le disait et la description de la règle firewall le disait.
Puis ils ont acquis une autre unité. Lors de la fusion des réseaux, un ingénieur a créé un NAT temporaire pour permettre à des contractants d’atteindre un serveur applicatif legacy.
La règle NAT incluait le 3389 parce que les contractants « avaient besoin de dépanner ».

La mauvaise hypothèse n’était pas le NAT lui-même ; c’était la croyance que « interne » signifie « sûr ». Ce serveur legacy était joint au domaine et avait un compte administrateur local
avec un mot de passe réutilisé sur plusieurs serveurs. Pas malveillant. Juste une habitude provenant du processus d’imageage.

Une semaine plus tard, la SIEM a commencé à afficher des connexions réussies à des heures étranges. La première réponse a été d’imputer cela à une tâche planifiée mal configurée.
La seconde réponse a été de réinitialiser le mot de passe du compte vu dans les logs. Cela a aidé — brièvement — parce que l’attaquant avait déjà pivoté ailleurs.

Ce qui a finalement mis fin à l’intrusion n’a pas été une règle de détection brillante. Ce fut une hygiène réseau ennuyeuse : ils ont découvert le NAT, l’ont supprimé, et imposé « RDP uniquement via VPN ».
Puis ils ont fait tourner les mots de passe admin locaux et réduit les droits RDP. Le postmortem fut douloureux mais utile : un contrôle qui n’existe que dans la tête de quelqu’un n’est pas un contrôle.

Leçon opérationnelle : validez la joignabilité depuis l’extérieur de votre réseau core chaque fois, surtout après des changements « temporaires ». Le temporaire est l’endroit où les incidents grandissent.

Mini-récit #2 : L’optimisation qui a mal tourné

Une autre organisation cherchait à réduire les tickets helpdesk. Les utilisateurs se plaignaient que se connecter via RD Gateway ajoutait « une connexion en plus » et parfois de la latence.
Un ingénieur a proposé une optimisation : autoriser le RDP direct vers un ensemble de jump servers depuis Internet, mais restreint par une politique de mot de passe stricte et un verrouillage de compte.
« Ça ira — ce sont seulement quelques hôtes. »

Au début, ça a marché. Le temps de connexion s’est amélioré, les tickets ont diminué, tout le monde se sentait malin. Puis le brute-force a commencé. Ça commence toujours.
Les attaquants ont frappé les jump servers avec des password sprays sur de nombreux noms d’utilisateurs. La politique de verrouillage s’est déclenchée pour des utilisateurs légitimes aussi.
Soudainement le helpdesk n’était plus sur « comment je me connecte », mais sur « je suis verrouillé avant mon début de service ».

Le contrecoup n’était pas seulement la douleur utilisateur. La politique de verrouillage est devenue un levier de déni de service : les attaquants pouvaient verrouiller des comptes à haute valeur à la demande,
créant une pression pour affaiblir la politique. L’organisation a fait ce que beaucoup font sous pression : augmenter les seuils et ajouter des exceptions.
Les exceptions se sont multipliées.

La correction a été d’annuler l’« optimisation » et de déplacer l’authentification vers une couche capable de gérer le bruit Internet :
VPN avec MFA plus accès conditionnel, puis RDP uniquement depuis ce réseau privé. La performance s’est améliorée — parce qu’ils ont cessé de brûler des cycles sur des tentatives d’auth junk.

Leçon : si votre optimisation nécessite d’exposer une authentification interactive sur Internet, ce n’est pas une optimisation. C’est un transfert de responsabilité vers votre rotation on-call.

Mini-récit #3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise liée au secteur de la santé avait une règle stricte : aucune exposition directe RDP, jamais. Tous les accès passaient par RD Gateway avec MFA, et les logs étaient centralisés
sur un système que les administrateurs ne pouvaient pas altérer. La politique était impopulaire car elle ajoutait de la friction, et les ingénieurs aiment la friction à peu près autant que le travail non planifié.

Un après-midi, une alerte s’est déclenchée : nombre inhabituel d’échecs de challenges MFA pour un utilisateur spécifique, suivi d’une connexion réussie depuis une nouvelle IP source et un nouvel appareil.
Le SOC a marqué cela et a paginé l’équipe on-call. L’on-call a vérifié les logs de la passerelle, corrélé avec les logs d’identité, et a vu la chronologie exacte.
Il n’y avait pas de conjecture. L’utilisateur a admis avoir approuvé une notification push qu’il n’avait pas initiée.

Parce que RDP n’était accessible que via la passerelle, le confinement a été immédiat : désactiver l’utilisateur, révoquer les sessions, et bloquer la source.
Ils disposaient aussi d’une liste propre des hôtes internes consultés parce que la passerelle appliquait des autorisations par hôte.
Pas de chasse frénétique d’endpoint. Pas de « on pense qu’ils ont peut-être touché le serveur X ». Ils savaient.

Ils ont reconstruit un poste par mesure de précaution, fait tourner quelques secrets, et ont repris leur activité. Pas de ransomware. Pas de déplacement latéral.
Le design « ennuyeux » — point d’étranglement central, MFA, logs immuables — a fait exactement ce qu’il devait faire : transformer un incident bordélique en une réunion courte.

Leçon : le meilleur contrôle de sécurité est celui qui fonctionne encore quand tout le monde est fatigué et pressé.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : « RDP fonctionne en interne mais pas en externe »

Cause racine : Le firewall/NSG de périphérie bloque 3389, ou le NAT pointe vers le mauvais hôte, ou routage asymétrique sur VPN.

Correction : Vérifiez depuis le réseau de l’utilisateur avec des tests de connexion TCP ; auditez les règles edge ; évitez d’exposer 3389 et utilisez VPN/RDG.

2) Symptom : « Les utilisateurs reçoivent des invites d’identifiants à répétition, puis ça échoue »

Cause racine : Problèmes de négociation NLA/CredSSP, dérive horaire, ou utilisateur non autorisé pour les droits RDP.

Correction : Assurez-vous que NLA est activé et supporté ; corrigez le NTP ; confirmez que l’utilisateur est dans le bon groupe AD et que le GPO autorise la connexion RDP.

3) Symptom : « La connexion réussit mais l’écran est noir / la session freeze »

Cause racine : Pression sur les ressources de l’hôte (CPU/disque), latence du conteneur de profil, ou problèmes GPU/drivers sur les session hosts.

Correction : Vérifiez CPU/disque ; réparez la latence du stockage ; limitez les fonctionnalités de redirection ; scalez les session hosts ; ne « résolvez » pas cela en désactivant des couches de sécurité.

4) Symptom : « Avertissement de certificat à chaque fois »

Cause racine : Certificat auto-signé ou CN/SAN non correspondant sur RDG ou l’endpoint.

Correction : Utilisez un certificat émis par une CA de confiance ; assurez-vous que les noms correspondent ; surveillez l’expiration ; apprenez aux utilisateurs que les avertissements sont sérieux.

5) Symptom : « Les comptes se verrouillent constamment »

Cause racine : Brute force côté Internet ou password spray, souvent ciblant des noms intégrés comme Administrator.

Correction : Arrêtez l’exposition directe ; imposez le MFA ; bannissez les sources abusives ; envisagez de renommer/désactiver l’admin intégré quand approprié et utilisez des mots de passe admin locaux uniques.

6) Symptom : « On ne sait pas qui s’est connecté après un incident »

Cause racine : Logs non activés, non centralisés, ou écrasés/effacés.

Correction : Activez l’audit ; forwardez les logs vers un système en écriture seule ou restreint ; augmentez la rétention des logs ; alertez sur les événements de vidage/effacement de logs.

7) Symptom : « RDP est ouvert ‘temporairement’ mais personne n’en est propriétaire »

Cause racine : Lacune dans le change management ; accès d’urgence sans mécanisme d’expiration.

Correction : Utilisez des règles firewall temporelles ; imposez des approbations ; ajoutez des contrôles automatisés qui échouent des builds ou alertent quand 3389 est exposé.

8) Symptom : « On a changé le port et on s’est quand même fait attaquer »

Cause racine : Malentendu de sécurité par l’obscurité ; la détection de service le trouve de toute façon.

Correction : Traitez le changement de port comme une réduction du bruit seulement ; implémentez des contrôles réels : VPN/RDG, MFA, listes autorisées, journalisation et patching.

Listes de contrôle / plan étape par étape

Plan étape par étape (ordre sûr pour la production)

1. Décidez du modèle d’accès : VPN ou RD Gateway (préféré) vs. exposition directe (à éviter).
2. Définissez les réseaux administratifs : seules les plages sources autorisées à atteindre RDP ou la passerelle.
3. Implémentez des contrôles réseau : règles edge + pare-feu hôte ; pas de « Any → 3389 » large.
4. Activez/exigez NLA et validez avec des sondes externes.
5. Imposez le MFA à la couche d’accès (VPN/RDG) sans exceptions permanentes.
6. Réduisez la portée des connexions : groupes AD ; retirez les admin permanents quand possible ; comptes séparés.
7. Durcissez les fonctionnalités de redirection : presse-papiers/lecteurs/imprimantes selon le besoin, pas par défaut.
8. Patchez tout dans la chaîne : OS endpoint, gateway, VPN et composants d’identité.
9. Centralisez les logs et créez des règles d’alerte initiales pour brute force, nouvelles sources, connexions privilégiées.
10. Testez depuis l’extérieur : joignabilité du port, santé TLS et flux de connexion réels.
11. Documentez la responsabilité : qui approuve l’accès, qui fait tourner les certificats, qui répond aux alertes.
12. Définissez une boucle d’expiration/attestation : si 3389 est exposé quelque part, il doit être re-justifié régulièrement ou fermé automatiquement.

Checklist pré-vol (avant d’ouvrir quoi que ce soit)

• RDP n’est pas accessible depuis l’internet public sauf s’il existe une exception signée avec une date de fin.
• La passerelle/VPN impose le MFA pour tout accès interactif.
• Les règles firewall sont basées sur des listes autorisées et sont revues.
• NLA est activé et testé.
• L’administrateur local n’est pas utilisé pour l’accès de routine ; les mots de passe admin locaux sont uniques par hôte.
• La chaîne de certificats est valide ; la surveillance d’expiration existe.
• Les logs sont centralisés ; la rétention correspond à votre réalité en réponse aux incidents.
• La personne on-call sait où regarder en premier (logs de passerelle, logs d’auth, logs firewall).

Checklist de contrôle des changements (quand quelqu’un demande « ouvrez vite »)

• Quelle plage IP/source exacte demande l’accès ?
• Pourquoi ne peuvent-ils pas utiliser la passerelle/VPN ?
• Quelle est l’heure d’expiration pour la règle ?
• Quels logs prouvent ce qui s’est passé pendant la fenêtre ?
• Qui est responsable de supprimer l’exposition ?

FAQ

1) Changer le port RDP de 3389 vers autre chose vaut-il la peine ?

C’est utile uniquement comme réduction du bruit, pas comme sécurité. Cela peut diminuer les scans opportunistes, mais toute détection de service le trouvera toujours.
Si vous le faites, appliquez quand même VPN/RDG, MFA et listes autorisées.

2) Puis-je exposer RDP directement sur Internet de manière sécurisée si j’ai des mots de passe forts ?

Vous pouvez réduire le risque, mais vous opérez toujours un point d’authentification interactif exposé sur Internet. Les mots de passe forts aident, mais des mots de passe fuités existent,
et le password spraying ne se préoccupe pas de la « force » si le mot de passe est réutilisé. Utilisez le MFA et placez-le derrière une passerelle/VPN quand c’est possible.

3) Quelle est l’architecture « bonne » la plus simple pour les petites équipes ?

VPN avec MFA + RDP seulement sur des sous-réseaux privés. Si vous avez besoin d’autorisation par application et d’un meilleur audit, ajoutez RD Gateway.
Les petites équipes bénéficient d’un point d’étranglement central car vous n’avez pas le temps de durcir parfaitement 200 endpoints individuels.

4) NLA me protège-t-il complètement des vulnérabilités RDP ?

Non. Il réduit l’exposition et peut atténuer certains chemins pré-auth, mais il ne remplace pas le patching ni les contrôles réseau.
Considérez-le comme une base nécessaire, pas comme un bouclier absolu.

5) Dois-je désactiver la redirection du presse-papiers et des lecteurs ?

Sur les systèmes hautement sensibles, oui par défaut. Sur les jump boxes administratives générales, envisagez d’autoriser le presse-papiers mais de bloquer la redirection de lecteurs.
Décidez en fonction du risque d’exfiltration des données et des besoins opérationnels, et documentez la justification.

6) Comment arrêter les attaques brute force si je dois exposer quelque chose ?

N’exposez pas 3389 ; exposez plutôt une passerelle sur 443 avec MFA. Si malgré tout vous avez une exposition, implémentez des listes autorisées, des bans automatisés/limitation du débit,
et alertez sur les pics d’échecs. Enfin, désactivez ou restreignez les noms d’utilisateurs à haute valeur et exigez le MFA.

7) Pourquoi le verrouillage de compte rend parfois les choses pires ?

Les verrouillages peuvent être weaponisés pour du déni de service : les attaquants peuvent verrouiller des comptes clés volontairement.
Le MFA et les contrôles en couche d’accès réduisent le besoin de réglages agressifs de verrouillage sur des endpoints exposés.

8) Quels logs importent le plus pour les enquêtes RDP ?

Succès et échecs de connexion (avec le type de logon), logs RDP/TerminalServices, logs d’authentification de la passerelle, et logs des dispositifs de sécurité réseau.
Centralisez-les quelque part que les attaquants ne peuvent pas effacer triviellement, et assurez la synchronisation horaire entre systèmes.

9) Les administrateurs doivent-ils utiliser leur compte quotidien pour RDP ?

Non. Utilisez des comptes séparés : un compte standard pour email/navigation et un compte administrateur pour les accès privilégiés.
Cela réduit le risque qu’un identifiant pêché devienne une clé maître RDP.

Étapes suivantes

Si vous ne retenez que trois choses : n’exposez pas 3389 quand vous pouvez l’éviter, imposez le MFA à une couche d’accès centralisée, et journalisez de manière à survivre à un incident.
Tout le reste n’est que réglage.

Actions pratiques que vous pouvez faire cette semaine :

1. Inventoriez chaque hôte accessible sur 3389 depuis l’extérieur de vos réseaux admin ; fermez ce que vous pouvez.
2. Installez ou standardisez un VPN / RD Gateway avec MFA et supervision des certificats.
3. Créez une alerte : « N échecs de connexion par minute vers RDP/RDG », et routez-la vers une personne capable de bloquer rapidement des sources.
4. Réduisez les droits RDP : définissez qui peut se connecter où, puis appliquez via GPO et révisez mensuellement.
5. Lancez une campagne d’expiration pour les règles firewall « temporaires » ; supprimez celles qui n’ont pas de propriétaire.

N’ouvrez le port 3389 qu’après avoir mis en place les garde-fous. Sinon vous n’autorisez pas le travail à distance — vous planifiez une réponse à incident.