Attaques par force brute contre RDP — Pourquoi RDP sur Internet est dangereux

Si vous avez déjà ouvert le port 3389 sur votre routeur parce que 'c'était plus simple' — ou parce que quelqu'un vous a demandé d'activer Remote Desktop rapidement — vous avez probablement ressenti l'inquiétude lorsque ce serveur ou poste a commencé à consigner des dizaines d'échecs de connexion venus de nulle part. Les conséquences sont réelles : identifiants compromis, rançongiciels et cycles de réponse aux incidents longs. Ce guide explique pourquoi un RDP exposé au public attire les attaques par force brute et, surtout, quelles alternatives et mesures d'atténuation pratiques vous devriez utiliser à la place.

Pourquoi exposer RDP à Internet est une manœuvre à haut risque

Remote Desktop Protocol (RDP) est pratique : Microsoft l'intègre à Windows, le client existe sur d'autres systèmes et de nombreux administrateurs s'en servent pour du dépannage ponctuel. Cette ubiquité en fait une cible de choix. Le protocole écoute couramment sur le port TCP 3389 par défaut, ce qui le rend trivial à trouver via des outils de scan massifs comme Masscan ou ZMap. Une fois découvert, des bots automatisés testent des listes d'utilisateurs et de mots de passe jusqu'à obtenir un accès.

Il y a deux problèmes liés quand RDP est directement joignable depuis Internet :

• Attaques d'identifiants — force brute et credential stuffing : les attaquants parcourent des mots de passe courants, des listes de credentials fuités et des wordlists contre des milliers d'IP en parallèle.
• Risque d'exploit/zero-day : des hôtes Windows mal configurés ou non patchés peuvent contenir des vulnérabilités liées à RDP (par exemple, CVE-2019-0708 "BlueKeep" affectait de plus anciennes implémentations RDP). Si RDP est exposé, des compromissions basées sur des exploits sont possibles en plus de l'abus d'identifiants.

En clair : un serveur RDP sur Internet est un phare. Les scripts et botnets le considèrent comme une cible facile, et de nombreuses compromissions commencent par les mêmes étapes latérales — connexion réussie, escalade, puis rançongiciel ou vol de données.

Comment les attaquants mènent les attaques par force brute contre RDP (vue d'ensemble)

Les attaquants combinent typiquement trois phases :

1. Découverte — scan de plages d'IP pour trouver des services RDP répondant sur le port 3389 (les outils de scan sont rapides et banals).
2. Tentatives d'authentification — des clients automatisés testent des noms d'utilisateur et des mots de passe. Ils utilisent des dictionnaires, des listes d'identifiants fuités et des stratégies de credential stuffing. Des outils comme Hydra, Ncrack ou des frameworks personnalisés de brute force RDP sont souvent employés ; les attaquants répartissent la charge via des proxies et des VPN pour éviter les throttles basés sur l'IP.
3. Actions post-authentification — une fois la session établie, les attaquants explorent la machine manuellement ou exécutent des scripts automatisés pour déployer un rançongiciel, créer une persistance ou récolter des identifiants pour se déplacer latéralement vers d'autres systèmes.

Network Level Authentication (NLA) augmente la difficulté car elle exige des identifiants avant d'établir une session RDP complète, mais ce n'est pas une solution miracle : NLA repose toujours sur des comptes et peut être contournée si un compte est faible, réutilisé ou déjà compromis ailleurs.

Signes que vous êtes ciblé — quoi surveiller maintenant

La détection précoce est essentielle. Voici des indicateurs concrets d'une attaque par force brute contre RDP :

• Beaucoup d'événements d'échec de connexion en peu de temps. Sur Windows, surveillez l'ID d'événement de sécurité 4625 (échec de connexion) et les occurrences répétées de 4624 (connexion réussie) provenant d'IP sources inattendues.
• Verrouillages inhabituels de comptes ou horodatages étranges pour les connexions (connexions en dehors des heures de bureau depuis des plages d'IP étrangères).
• Journaux de pare-feu montrant de nombreuses tentatives de connexion TCP vers le port 3389 depuis de nombreuses IP distinctes.
• Nouveaux comptes administrateurs locaux, services inattendus installés ou processus inconnus après une connexion réussie.

Contrôles rapides que vous pouvez lancer maintenant (PowerShell) :

Test-NetConnection -ComputerName YOUR_HOSTNAME_OR_IP -Port 3389

Et vérifiez les tentatives de connexion échouées récentes avec l'Event Viewer, ou exportez les événements via PowerShell/Get-WinEvent si vous automatisez la détection. Si vous observez des pics, considérez que des attaquants vous cherchent et agissez immédiatement.

Mesures de confinement immédiates si vous découvrez une activité de brute force

Si vous découvrez des tentatives actives de force brute ou suspectez une compromission, priorisez le confinement plutôt que la commodité :

1. Bloquez le trafic au pare-feu périmétrique. Coupez les connexions entrantes vers TCP/3389 à la frontière dès que possible.
2. Désactivez RDP sur les hôtes affectés pendant le triage : Système > Paramètres d'accès à distance > décochez "Allow remote connections" (Windows) — ou arrêtez le service Remote Desktop Services pour un confinement d'urgence.
3. Réinitialisez les identifiants des comptes impactés et de tous les comptes partageant des mots de passe. Préférez des phrases de passe longues et des mots de passe uniques par compte.
4. Activez une politique de verrouillage de compte : par exemple, verrouiller le compte après 5 tentatives échouées pendant 15 minutes. C'est une mesure défensive raisonnable qui ralentit les attaques automatisées sans générer trop d'appels au helpdesk.
5. Vérifiez la présence de persistance sur l'hôte : tâches planifiées, nouveaux autoruns, services suspects et indicateurs connus de rançongiciel. Si vous trouvez des signes de compromission, isolez l'hôte et suivez votre playbook de réponse aux incidents.

Ce sont des actions de triage — elles ne résoudront pas les causes profondes. Après le confinement, passez à la remédiation : patchs, rotation des identifiants et surveillance post-incident.

Alternatives plus sûres que l'exposition directe de RDP (options réelles, avantages et inconvénients)

Si votre objectif est l'administration distante sécurisée ou le télétravail, il existe de meilleures approches que l'ouverture du port 3389. Choisissez celle qui correspond à votre échelle et à votre modèle de menace.

1) VPN (site-à-site ou client) — le plus simple pour les petites/moyennes équipes

Avantages : RDP n'est joignable que via un tunnel chiffré. Vous pouvez restreindre l'accès via des ACL VPN et centraliser l'authentification. WireGuard et OpenVPN sont des choix courants ; OpenVPN est mature, WireGuard est plus simple et plus rapide.

Inconvénients : les VPN ajoutent de la charge de gestion et nécessitent une configuration cliente sécurisée et une gestion des certificats/clefs. Si les identifiants VPN sont faibles, vous avez toujours une surface d'attaque, donc combinez VPN avec MFA et monitoring.

2) RDP Gateway / RD Web Access

Utilisez RD Gateway de Microsoft pour exposer les sessions RDP via TLS (typiquement sur le port 443) et centraliser l'authentification. RD Gateway offre un meilleur contrôle des politiques et s'intègre à Azure AD dans les environnements hybrides pour le MFA.

Avantages : conçu pour RDP, bonne intégration avec l'authentification Windows et l'accès conditionnel.

Inconvénients : ajoute une infrastructure à gérer et à patcher ; une mauvaise configuration peut toujours vous exposer. Pour beaucoup d'équipes, un VPN reste plus simple.

3) Jump host ou bastion (accès géré)

Déployez un bastion/hôte de saut durci vers lequel les administrateurs se connectent d'abord, puis sautent vers les hôtes internes. Appliquez un MFA strict et la journalisation des sessions sur le bastion ; seul le bastion nécessite une IP publique.

Avantages : centralise l'accès et l'audit. Plus simple à surveiller et à verrouiller que de nombreux endpoints exposés. Les fournisseurs cloud proposent des services bastion gérés (Azure Bastion, AWS Systems Manager Session Manager) qui suppriment entièrement les ports entrants.

4) Logiciel d'accès distant (relay / auto-hébergé) — TeamViewer/AnyDesk/RustDesk/Tenvo

Les outils d'accès distant commerciaux utilisent la traversal NAT et des serveurs de relais, vous évitant d'ouvrir le 3389 sur votre pare-feu. Ils sont souvent la manière la plus rapide pour les utilisateurs non techniques d'obtenir un support distant sécurisé. Cela dit, ils impliquent un modèle de confiance différent : vous dépendez du fournisseur ou de l'infrastructure de relais.

Comparaison honnête : TeamViewer et AnyDesk sont très aboutis pour le support utilisateur et la gestion des sessions. Ils sont propriétaires et gérés dans le cloud, ce qui convient à de nombreux cas d'usage. Si vous devez éviter les relais tiers ou souhaitez le contrôle total, des options auto-hébergées comme RustDesk ou Tenvo sont de bonnes alternatives — elles permettent d'éviter le port forwarding tout en gardant l'infrastructure sous votre contrôle. Voir la page de téléchargement de Tenvo sur /download pour une option auto-hébergée et /pricing si vous avez besoin de relais hébergés ou d'un support commercial.

Si vous voulez explorer des approches qui évitent le port forwarding en détail, notre guide pour configurer l'accès à distance sans port forwarding est utile : /remote-desktop-without-port-forwarding. Pour des recommandations plus larges sur la sécurité du bureau à distance, voyez /remote-desktop-security.

Checklist pratique de durcissement — que faire ensuite (pas à pas)

Voici une checklist pratique et priorisée que vous pouvez appliquer aux postes et serveurs. Elle mélange des changements immédiats et des améliorations à moyen terme.

1. Fermez l'exposition : bloquez TCP/3389 au pare-feu périmétrique ou utilisez des listes d'IP autorisées pour que seules des plages IP de confiance puissent se connecter.
2. Si RDP doit rester joignable, activez Network Level Authentication (NLA) et SSL/TLS pour la gateway quand c'est possible.
3. Faites respecter des politiques de mot de passe robustes et utilisez des seuils de verrouillage de compte (suggestion : verrouiller après 5 échecs, durée 15 minutes — adaptez selon votre environnement).
4. Activez le MFA pour l'accès distant. Pour les machines jointes au domaine, intégrez Azure AD conditional access, ou placez un MFA tiers (Duo, Okta) devant votre gateway.
5. Patchtez les systèmes rapidement. Maintenez Windows à jour — de vieux CVE liés à RDP ont été critiques et largement exploités.
6. Utilisez une journalisation centralisée et des alertes. Surveillez les ID d'événement de sécurité 4624/4625 et vos journaux de pare-feu ; créez une alerte pour un fort taux d'échecs de connexion ou de nouvelles IP accédant à RDP.
7. Utilisez un jump host/bastion pour les tâches d'administration et restreignez qui peut RDP directement vers les systèmes de production.
8. Préférez des outils d'accès distant qui évitent le port-forwarding quand vous ne pouvez pas déployer un VPN. Si vous vous auto-hébergez, maintenez le relay ou le serveur patché et protégé par une authentification robuste.
9. Envisagez des outils d'intrusion-prevention et de verrouillage automatique pour Windows comme RdpGuard ou les solutions natives de votre suite de protection des endpoints.
10. Gérez les mots de passe administrateurs locaux avec Microsoft LAPS ou une solution de gestion des accès privilégiés (PAM) pour éviter les identifiants locaux partagés.

Quelle option choisir — guide rapide

Choisissez en fonction de la taille de l'environnement, de la posture de sécurité et de la capacité d'administration :

• Petites équipes / administrateur unique : utilisez une application d'accès distant réputée (relay ou auto-hébergée) ou un VPN client. Les outils basés sur un relais sont les plus simples pour les utilisateurs non techniques ; si vous voulez le contrôle, utilisez une option auto-hébergée comme Tenvo et déployez votre propre relais.
• Organisations moyennes : VPN site-à-site ou VPN client + MFA, combinés à un bastion pour les tâches d'administration.
• Grande entreprise : RD Gateway ou solutions bastion gérées cloud, combinées avec un accès conditionnel et un PAM pour les comptes privilégiés.

Une remarque honnête : si vous avez besoin de l'expérience la plus simple pour des membres de la famille non techniques, des outils commerciaux comme TeamViewer ou AnyDesk peuvent être moins contraignants que la configuration d'un VPN. Ils ont des compromis : commodité vs contrôle — et leur acceptabilité dépend de votre modèle de menace et de vos exigences de conformité.

Conclusion et étapes immédiates

Les attaques par force brute contre RDP sont prévisibles et évitables. La règle la plus importante : n'exposez pas RDP directement sur Internet à moins d'avoir une excellente raison et des contrôles compensatoires (MFA, IP source limitées, RD Gateway ou VPN, surveillance stricte). Si un serveur RDP est déjà accessible depuis Internet, bloquez-le maintenant et suivez la checklist de durcissement ci‑dessus.

Si vous cherchez un moyen pratique d'éviter le port-forwarding tout en gardant le contrôle de votre infrastructure, envisagez une solution d'accès distant auto-hébergée. Tenvo fournit un connecteur et des options de relais auto-hébergés — consultez /download pour l'essayer et /pricing pour des plans de relais hébergés si nécessaire. Et si vous élaborez un plan d'accès distant sécurisé, nos guides associés peuvent aider : /remote-desktop-without-port-forwarding et /remote-desktop-security.

N'attendez pas de voir ces pics 4625. Bouchez la faille, choisissez une alternative adaptée à votre échelle (VPN, RD Gateway, bastion ou une application d'accès distant contrôlée), et ajoutez MFA et monitoring. Si vous souhaitez de l'aide pour sélectionner et configurer l'option adaptée à votre environnement, téléchargez Tenvo sur /download pour expérimenter une approche auto-hébergée qui évite d'exposer RDP directement.