TCP port remote desktop : le port 3389 et sa gestion dans les réseaux d'entreprise

Le tcp port remote desktop revient tout le temps quand on parle de connexion à distance sur Windows. Par défaut il écoute sur le 3389, en TCP bien sûr, et de plus en plus souvent en UDP aussi pour gagner en fluidité. Dans un réseau d'entreprise, ce n'est pas juste un numéro : c'est la porte d'entrée que tout le monde connaît, que les scanners automatisés testent en continu et que les équipes réseau doivent maîtriser pour éviter les mauvaises surprises.

Le rôle du port 3389 dans une connexion RDP classique

Quand un client Remote Desktop se connecte à un poste ou un serveur, il commence par une poignée de main TCP sur ce port. Le protocole établit la session, négocie les paramètres, puis fait transiter l'écran, le clavier, la souris et tout le reste. Depuis RDP 8.0 environ, une partie du trafic peut basculer en UDP sur le même port 3389. L'idée est simple : l'UDP évite la retransmission des paquets perdus, ce qui rend la souris plus réactive et l'audio/vidéo moins saccadés quand le réseau est un peu chargé. Si l'UDP est bloqué quelque part, tout retombe en TCP sans drame, juste avec un peu plus de latence.

Dans les faits, sur un LAN propre, on sent rarement la différence. C'est surtout quand on traverse internet ou un WAN un peu bruyant que l'UDP apporte un vrai plus.

Pourquoi le tcp port remote desktop par défaut pose problème

Le 3389 est connu de tous les outils de scan depuis vingt ans. Les bots qui tournent sur internet tapent ce port en permanence, essaient des combos d'identifiants basiques et, quand ils tombent sur quelque chose de faible, c'est souvent la porte ouverte pour du ransomware ou du vol de données. Dans un contexte réseau d'entreprise, si vous avez fait un simple port forwarding du 3389 vers un serveur interne, vous héritez exactement du même bruit. Les logs pare-feu se remplissent vite et les tentatives de brute force arrivent par milliers chaque jour.

Changer le port ne rend pas le service invisible, mais ça supprime 95 % du bruit automatisé. Les attaquants qui font du scan large passent à côté, et vous gagnez du temps pour les vrais contrôles (NLA activé, MFA, restriction d'IP source, etc.).

Configurer le tcp port remote desktop sur Windows

La modification se fait via le registre. Vous allez dans regedit, vous descendez jusqu'à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, vous double-cliquez sur la valeur PortNumber, vous passez en décimal et vous entrez le nouveau numéro. Quelque chose au-dessus de 1024, de préférence assez haut pour ne pas rentrer en conflit avec d'autres services : 4455, 50001, 33900, peu importe tant que c'est libre sur la machine et que vous vous en souvenez.

Vous validez, vous fermez l'éditeur et vous redémarrez le poste ou le serveur. Ensuite il faut créer (ou modifier) la règle dans le Pare-feu Windows Defender : règle de trafic entrant, port TCP et UDP si vous voulez garder l'option UDP, autoriser la connexion. Sur les clients qui se connectent, il suffit d'ajouter :nouveauport après l'adresse IP ou le nom d'hôte dans la boîte de dialogue Connexion Bureau à distance. Rien de sorcier, mais il faut le faire partout où c'est nécessaire et documenter le changement.

Sur un domaine, le plus propre reste de passer par une GPO pour pousser la clé de registre et la règle pare-feu en une fois. Ça évite les oublis sur les machines qui arrivent plus tard.

Le port 3391 et son rôle avec la passerelle Bureau à distance

Quand vous mettez en place une RD Gateway (la passerelle officielle Microsoft), le trafic externe arrive en HTTPS sur le 443. C'est déjà beaucoup plus propre. Mais pour garder les avantages de l'UDP, la gateway peut négocier un canal UDP supplémentaire sur le port 3391. Le client et la passerelle parlent d'abord en TCP/443, puis basculent une partie du flux RDP en UDP sur 3391 si le réseau le permet. C'est configurable dans la console de gestion de la passerelle et ça demande d'ouvrir ce port en entrée sur le firewall qui protège la DMZ ou le serveur de passerelle.

Beaucoup d'équipes l'activent sans même s'en rendre compte au début, puis se demandent pourquoi les perf s'améliorent subitement. Dans un vrai réseau d'entreprise, c'est souvent la meilleure façon d'exposer du Remote Desktop sans laisser le 3389 en façade.

Règles pare-feu et NAT : ce qu'il faut vraiment ouvrir

Dans la plupart des cas, vous n'avez pas besoin d'ouvrir tout un tas de ports. Pour du RDP direct (ce que je déconseille fortement en frontal internet), il suffit du nouveau port TCP (et UDP si vous l'utilisez) en entrée, avec idéalement une restriction d'adresse source. Pour une RD Gateway, c'est le 443 TCP qui suffit pour la grande majorité des usages, plus le 3391 UDP si vous voulez le gain de performance.

Côté NAT/routeur, vous forwardez uniquement ce qui est nécessaire et vous journalisez. Sur les firewalls d'entreprise, pensez aussi aux règles sortantes : le serveur RDP n'a pas besoin de parler vers n'importe où sur internet. Limiter les flux sortants réduit la surface d'attaque si jamais la machine est compromise.

Les approches réseau qui évitent d'exposer le tcp port remote desktop

Honnêtement, la meilleure pratique en 2026 reste de ne pas exposer de RDP directement sur internet. Un VPN bien monté (WireGuard sur son port UDP dédié, ou OpenVPN) donne un tunnel chiffré et vous gardez le 3389 (ou votre port custom) uniquement accessible depuis le réseau VPN. C'est plus propre, plus auditable, et ça colle mieux avec les exigences de segmentation réseau.

La RD Gateway sur le 443 reste une excellente solution intermédiaire quand on veut éviter le VPN pour des utilisateurs nomades. Elle centralise l'authentification, permet le MFA facilement et garde le port web standard que tout le monde a déjà ouvert.

Pour les environnements plus modernes, beaucoup d'entreprises passent sur des solutions cloud type Azure Virtual Desktop ou des brokers tiers qui ne reposent plus du tout sur l'exposition d'un port RDP classique. Le trafic passe par des canaux sécurisés et le port 3389 reste cantonné au réseau interne, là où il est plus facile à contrôler.

Au bout du compte, le tcp port remote desktop n'est pas un problème en soi. C'est juste un service qui a besoin d'être pensé comme n'importe quel autre flux réseau : on choisit le port, on le restreint, on le monitore, et on préfère de loin le faire transiter derrière quelque chose de plus robuste qu'un simple forwarding. C'est comme ça qu'on garde des connexions à distance fiables sans transformer le pare-feu en passoire.