Sur quel port déplacer RDP ?

N'importe lequel de libre au-dessus de 10000 — 34519, 47820, ce qui est disponible. Évitez les ports revendiqués par des services connus, car les scanners les sondent spécifiquement, et évitez le 3390, la première chose qu'on essaie après 3389. Vérifiez avec Get-NetTCPConnection que rien n'écoute avant de vous engager.

Changer le port RDP casse-t-il les clients Bureau à distance ?

Non, mais chaque client doit désormais nommer le port : server:34519 dans le champ ordinateur, ou mstsc /v:server:34519. Les fichiers .rdp enregistrés et les gestionnaires de connexions gardent l'ancien port et échoueront tant qu'ils ne seront pas mis à jour. Les pare-feux d'entreprise qui autorisent le 3389 sortant peuvent bloquer purement le nouveau port, c'est la plainte la plus fréquente après le changement.

Est-il sûr d'exposer RDP sur un port non standard ?

C'est exactement aussi sûr que sur le 3389, avec moins de bruit de fond. Le port n'est pas un contrôle d'accès : le service s'identifie à sa poignée de main, et Shodan indexe en continu le RDP sur des ports non standard. La sécurité vient de ce qui traite les tentatives, pas de l'endroit où elles arrivent.

Faut-il changer le port ou simplement bloquer les IP attaquantes ?

Le blocage est la défense ; le changement de port est de l'hygiène qui rend votre journal lisible. Si vous ne faites qu'une chose, bloquez. Faire les deux vaut mieux que l'une ou l'autre : moins de tentatives arrivent, et celles qui arrivent sont arrêtées avant que Windows n'y consacre quoi que ce soit.

Changer le port RDP 3389 : ce que ça règle et ce que non

Sortir RDP de son port par défaut réduit énormément le volume d'attaques et ne protège de presque rien. Les deux moitiés méritent d'être comprises avant d'agir.

6 min de lectureMis à jour le 2026-08-26

Le résumé honnête

Déplacer RDP hors du 3389 réduira votre volume de connexions échouées d'environ 90% du jour au lendemain. Ce n'est pas non plus un contrôle de sécurité, et le traiter comme tel est la façon dont des serveurs se font compromettre par des administrateurs persuadés d'avoir terminé.

Les deux affirmations sont vraies parce qu'elles répondent à des questions différentes. La baisse de volume est réelle, mesurable et utile. La protection est proche de zéro face à quiconque passe trente secondes à regarder.

Faut-il le faire ? Généralement oui — comme réduction de bruit, en plus d'une défense, jamais à la place.

Ce que ça arrête vraiment

L'immense majorité du trafic d'attaque RDP vient de scanners non ciblés qui font une seule chose : se connecter au port 3389 sur de grandes plages d'adresses et essayer des mots de passe sur tout ce qui répond. Ils ne balaient pas les ports. Scanner 65 535 ports sur chaque adresse coûte des ordres de grandeur de plus que d'en vérifier un, et il y a assez de machines sur 3389 pour que ça n'en vaille pas la peine.

Passez au 34519 et vous sortez entièrement de cette population. La courbe s'effondre, le journal de sécurité cesse de tourner toutes les quelques heures, et retrouver un vrai événement dedans redevient possible.

Ce dernier point est sous-estimé. Un journal d'événements réellement lisible vaut de l'argent pendant un incident, et à trois mille échecs par jour vous n'en avez pas.

Ce que ça n'arrête pas

Quiconque balaie toute la plage de ports vous trouve en quelques minutes. RDP s'identifie trivialement à sa poignée de main quel que soit le port, donc un scanner qui parcourt tous les ports et prend l'empreinte de ce qui répond étiquettera correctement votre service du premier coup.

Shodan et Censys font exactement cela en continu, sur tout internet, et publient les résultats sous forme d'index interrogeable. Votre port RDP non standard s'y trouve, trouvable par n'importe qui, quelques jours après son ouverture.

Donc face à un bot non ciblé, changer le port fonctionne. Face à quelqu'un qui vous a choisi — un concurrent, un ancien employé, un opérateur de rançongiciel déroulant la liste des entreprises d'un secteur —, cela lui coûte quelques minutes. Et cela ne fait rien du tout contre les mots de passe faibles, un SMB exposé, un hôte non corrigé ou des identifiants ayant fuité ailleurs.

Il y a aussi un inconvénient actif : les ports exotiques cassent des choses. Les pare-feux d'entreprise qui autorisent le 3389 sortant bloqueront le 34519 sortant, et vous l'apprendrez d'un utilisateur incapable de travailler.

Comment changer sans se bloquer dehors

Le port vit dans le registre, et le pare-feu Windows doit en être informé avant que vous ne redémarriez le service — dans cet ordre, sinon vous vous déconnectez d'une machine que vous n'atteignez que par RDP.

Choisissez un port au-dessus de 10000 que rien n'utilise, vérifiez qu'il est libre, ouvrez-le, puis changez :

powershell

$NewPort = 34519

# 1. Confirmer que rien n'écoute déjà là.
Get-NetTCPConnection -LocalPort $NewPort -ErrorAction SilentlyContinue

# 2. L'ouvrir dans le pare-feu D'ABORD — avant que le service ne bouge.
New-NetFirewallRule -DisplayName "RDP-$NewPort" -Direction Inbound `
  -Protocol TCP -LocalPort $NewPort -Action Allow

# 3. Pointer Terminal Services sur le nouveau port.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber -Value $NewPort

# 4. Redémarrer le service (coupe votre session actuelle).
Restart-Service TermService -Force

Ensuite

Connectez-vous en indiquant explicitement le port — mstsc /v:server:34519 — et mettez à jour tout ce qui stockait l'ancien : fichiers RDP enregistrés, gestionnaires de connexions, vérifications de supervision, configurations de jump-host, la documentation de votre équipe. Puis supprimez ou restreignez l'ancienne règle d'autorisation 3389, sinon vous n'avez rien gagné.

Ne supprimez pas l'ancienne règle avant d'avoir confirmé que le nouveau port fonctionne depuis l'extérieur de votre réseau. Sur le LAN tout marche de toute façon, et c'est exactement ainsi qu'on se persuade que tout va bien.

Avec quoi le combiner

Changer de port réduit le bruit. Quelque chose doit encore traiter les tentatives qui arrivent — et après un changement de port, celles qui arrivent viennent de quelqu'un qui vous cherchait spécifiquement, c'est-à-dire précisément celles qui vous importent.

Cela signifie les trois mêmes choses qu'avant : surveiller les connexions échouées, bannir les sources qui franchissent un seuil, et ne jamais tomber sous son propre bannissement. RDP Protector détecte le vrai port RDP depuis le registre et les sockets en écoute au lieu de supposer 3389, donc un serveur déplacé est couvert sans rien configurer — et il reconstruit ses règles automatiquement si le port change à nouveau.

Changez le port pour un journal lisible. Gardez une défense pour le trafic qui vous trouve quand même.

FAQ

Sur quel port déplacer RDP ?: N'importe lequel de libre au-dessus de 10000 — 34519, 47820, ce qui est disponible. Évitez les ports revendiqués par des services connus, car les scanners les sondent spécifiquement, et évitez le 3390, la première chose qu'on essaie après 3389. Vérifiez avec Get-NetTCPConnection que rien n'écoute avant de vous engager.
Changer le port RDP casse-t-il les clients Bureau à distance ?: Non, mais chaque client doit désormais nommer le port : server:34519 dans le champ ordinateur, ou mstsc /v:server:34519. Les fichiers .rdp enregistrés et les gestionnaires de connexions gardent l'ancien port et échoueront tant qu'ils ne seront pas mis à jour. Les pare-feux d'entreprise qui autorisent le 3389 sortant peuvent bloquer purement le nouveau port, c'est la plainte la plus fréquente après le changement.
Est-il sûr d'exposer RDP sur un port non standard ?: C'est exactement aussi sûr que sur le 3389, avec moins de bruit de fond. Le port n'est pas un contrôle d'accès : le service s'identifie à sa poignée de main, et Shodan indexe en continu le RDP sur des ports non standard. La sécurité vient de ce qui traite les tentatives, pas de l'endroit où elles arrivent.
Faut-il changer le port ou simplement bloquer les IP attaquantes ?: Le blocage est la défense ; le changement de port est de l'hygiène qui rend votre journal lisible. Si vous ne faites qu'une chose, bloquez. Faire les deux vaut mieux que l'une ou l'autre : moins de tentatives arrivent, et celles qui arrivent sont arrêtées avant que Windows n'y consacre quoi que ce soit.