Port 3389 ouvert sur internet : ce qui se passe vraiment

Chronique de ce qui atteint un serveur Windows dès que RDP devient joignable publiquement, comment vérifier si le vôtre l'est, et quoi faire.

7 min de lecture

Ce que « exposé » veut dire concrètement

Un serveur dont le port TCP 3389 est joignable depuis n'importe quelle adresse d'internet n'est pas discret. Il est répertorié. Des services de balayage indexent l'espace IPv4 en continu — Shodan et Censys publient des résultats consultables — et le nombre de machines Windows répondant sur 3389 à un instant donné se compte en millions.

L'exposition n'est donc pas une probabilité, c'est un calendrier. Votre adresse n'a pas besoin d'être découverte par quelqu'un en particulier ; elle figure déjà sur une liste, et cette liste est achetée, partagée et re-balayée par tous ceux qui mènent des attaques par identifiants.

La conséquence pratique : un serveur fraîchement exposé n'a aucune période calme. Il n'existe pas de fenêtre pendant laquelle laisser les réglages par défaut et s'occuper du durcissement la semaine prochaine.

La première semaine, heure par heure

Le schéma est assez constant pour être prédit. Voici les ordres de grandeur à attendre sur un Windows Server neuf, RDP ouvert et sans protection :

  • Première heure — la première tentative de connexion d'un scanner. Souvent en quelques minutes, car les scanners de masse balaient en continu plutôt que selon un horaire.
  • Premier jour — de quelques dizaines à quelques centaines de connexions échouées. Les noms de comptes viennent d'une liste standard : Administrator, admin, user, test, sql, backup, scanner.
  • Première semaine — quelques milliers par jour, régulièrement, jour et nuit. Plusieurs botnets distincts vous ont désormais, et ils ne se coordonnent pas, donc les volumes s'additionnent.
  • Premier mois — souvent des dizaines de milliers. Le journal de sécurité tourne assez vite pour que les anciens événements disparaissent avant que quiconque les lise.
  • Ensuite — le rythme se stabilise. Il ne décroît pas : aucun mécanisme ne permet aux bots de conclure que vous ne valez pas la tentative.

Ce qu'ils tentent réellement

Deux techniques différentes produisent le même profil de trafic, et les distinguer compte parce que les défenses diffèrent.

Le brute-force classique s'acharne sur un compte — généralement Administrator — et déroule une liste de mots de passe. Il est bruyant, il déclenche les politiques de verrouillage, et il échoue contre tout mot de passe absent de la liste.

Le password spraying inverse la logique : un mot de passe courant essayé une fois contre de nombreux noms de comptes, puis une pause, puis le mot de passe suivant. Il reste sous les seuils de verrouillage par conception, et c'est la technique qui réussit réellement : dans toute organisation comptant assez de comptes, quelqu'un utilise le mot de passe de saison.

Les deux sont visibles dans le même flux 4625, et les deux sont arrêtés par la même chose : bloquer la source avant qu'elle n'épuise la liste. Aucune n'est arrêtée par une politique de verrouillage — le spraying est conçu pour la contourner, et le brute-force la transforme en panne que vous vous infligez.

Vérifier si vous êtes exposé

Faites-le depuis l'extérieur de votre propre réseau. Dans le LAN tout répond, ce qui ne prouve rien. Depuis une autre machine sur une autre connexion :

powershell
# Depuis une machine hors de votre réseau, vers l'IP publique du serveur :
Test-NetConnection -ComputerName 203.0.113.10 -Port 3389

# Sur le serveur lui-même : ce qui écoute, et sur quelle interface
Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -in 3389,3390 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# Et quelles règles de pare-feu laissent actuellement entrer RDP :
Get-NetFirewallRule -Direction Inbound -Enabled True -Action Allow |
  Where-Object { ($_ | Get-NetFirewallPortFilter).LocalPort -contains 3389 } |
  Select-Object DisplayName, Profile

Fermer, par ordre de préférence

Classé selon la part de risque que chaque option retire réellement :

  • Ne pas l'exposer du tout. Atteindre le serveur via un VPN, une passerelle RD ou un bastion. Cela supprime l'exposition au lieu de la gérer, et tout ce qui suit est un compromis par rapport à cela.
  • Restreindre la source. Si l'ensemble des adresses légitimes est petit et stable — plages du bureau, sortie VPN, jump host —, n'autorisez qu'elles dans le pare-feu et rejetez le reste. Excellent quand ça convient, et ça cesse de convenir dès que quelqu'un se déplace.
  • Bannir automatiquement les sources attaquantes. Surveiller le flux d'échecs et bloquer au pare-feu, par sous-réseau et définitivement, tout ce qui franchit un seuil. C'est la réponse quand le service doit rester joignable depuis des adresses arbitraires.
  • Quitter le 3389. Réduit d'environ 90% le volume non ciblé et ne protège de rien qui vous cherche spécifiquement. Utile comme réduction de bruit en plus d'un des points ci-dessus, jamais en remplacement.

S'il doit rester ouvert

Beaucoup de serveurs ne peuvent pas passer derrière un VPN — prestataires, machines appartenant à des clients, équipes se connectant de partout. Si c'est votre cas, l'exposition est un fait acquis et le travail consiste à la rendre survivable.

Activez Network Level Authentication pour qu'aucune session ne soit créée pour un client non authentifié. Exigez des mots de passe longs et l'authentification multifacteur sur chaque compte pouvant se connecter à distance. Renommez ou désactivez le compte Administrator intégré, premier nom de toutes les listes. Gardez l'hôte à jour : RDP a déjà connu des vulnérabilités exploitables avant authentification, et en connaîtra d'autres.

Ajoutez ensuite ce que Windows ne fournit pas : quelque chose qui surveille le flux d'échecs et le convertit en règles de pare-feu. C'est exactement ce que fait RDP Protector — bannissements par sous-réseau, blocages permanents qui survivent aux redémarrages, et une liste blanche contenant votre propre adresse avant tout blocage. Un serveur est gratuit à vie, ce qui suffit à voir vos vrais chiffres plutôt que de les estimer.

FAQ

En combien de temps un serveur RDP exposé est-il trouvé ?
Généralement dans l'heure suivant l'ouverture du port, souvent en quelques minutes. Les scanners de masse parcourent l'espace IPv4 en continu, la découverte ne dépend donc pas de l'intérêt de qui que ce soit pour vous : votre adresse figure déjà sur des listes constamment re-balayées. Il n'existe aucune période calme permettant de repousser le durcissement.
Est-il parfois sûr d'exposer RDP directement sur internet ?
On peut le rendre acceptable, pas sûr au sens de sans risque. S'il le faut, combinez Network Level Authentication, authentification multifacteur, mots de passe longs et uniques, compte Administrator intégré désactivé ou renommé, correctifs à jour, et bannissement automatique au pare-feu des sources qui échouent de façon répétée. L'absence de l'un de ces éléments augmente sensiblement le risque.
Comment vérifier si mon port RDP est ouvert depuis internet ?
Testez depuis l'extérieur de votre réseau — Test-NetConnection -ComputerName <ip-publique> -Port 3389 depuis une autre connexion. Tester dans le LAN ne prouve rien, car le trafic interne contourne le périmètre. Sur le serveur, Get-NetTCPConnection indique si le service écoute sur 0.0.0.0, c'est-à-dire sur toutes les interfaces y compris publique.
Quelle différence entre brute-force et password spraying ?
Le brute-force martèle un compte avec de nombreux mots de passe ; le spraying essaie lentement un mot de passe courant contre de nombreux comptes, pour rester sous les seuils de verrouillage. C'est le spraying qui tend à réussir, et c'est précisément la technique que les politiques de verrouillage n'arrêtent pas. Les deux apparaissent comme l'événement 4625 et les deux sont stoppés en bloquant la source au pare-feu.

Voyez ce qui atteint réellement votre serveur

L'agent montre le volume réel de tentatives sur votre propre machine quelques minutes après l'installation. Un serveur gratuit à vie, sans carte.