Combien de connexions RDP échouées est-ce normal ?

Sur un serveur non exposé à internet, presque zéro — quelques-unes par semaine venant de gens qui se trompent de mot de passe. Sur un serveur dont le RDP est joignable depuis n'importe quelle adresse, quelques milliers par jour n'a rien de remarquable et ne dit rien sur vous en particulier : c'est le niveau de fond du balayage mondial. Ce qui compte est la tendance et la répartition des sources, pas le chiffre brut.

Changer le port RDP arrête-t-il les attaques brute-force ?

Cela arrête les scanners non ciblés qui ne sondent que le 3389, ce qui représente en pratique l'essentiel du volume — souvent plus de 90% de tentatives en moins. Cela n'arrête rien qui balaie toute la plage de ports, et des services comme Shodan indexent en continu le RDP sur des ports non standard. Voyez-le comme une réduction de bruit, pas comme une protection.

Faut-il activer le verrouillage de compte contre le brute-force ?

Pas comme défense principale sur un serveur exposé à internet. Le verrouillage repose sur le nom du compte, et les attaquants choisissent librement ce nom : n'importe qui peut donc verrouiller votre compte Administrator à la demande depuis n'importe quelle adresse. Bloquez au niveau réseau, et gardez le verrouillage avec un seuil modéré sur les comptes interactifs si vous y tenez.

Bannir tout un sous-réseau /24, n'est-ce pas trop agressif ?

Pour une plage qui vient de vous envoyer des centaines de connexions échouées, rarement. Le trafic d'attaque vient de plages d'hébergement et de VPS où les adresses voisines appartiennent au même opérateur ; les particuliers ne partagent presque jamais un /24 avec un scanner. Avec une liste blanche pour vos bureaux et sorties VPN, le taux de faux positifs est proche de zéro.

À quoi ressemble vraiment une attaque brute-force RDP

Anatomie de l'attaque qui frappe tout serveur Windows exposé sur internet : qui la mène, ce qu'elle coûte, pourquoi les conseils habituels ne marchent qu'à moitié et ce qui l'arrête.

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

L'attaque, en clair

Une attaque brute-force RDP n'est pas une opération ciblée contre vous. C'est un produit de masse : quelqu'un loue un botnet, lui donne une liste de plages d'adresses IP et lui fait tenter une connexion sur chaque machine qui répond sur le port 3389. La liste de mots de passe est courte et ennuyeuse — Administrator avec Password1, admin avec admin, le nom de l'entreprise suivi de l'année en cours. Le bot ignore et se moque de ce que fait votre serveur.

Ce qui rend l'attaque incessante, c'est l'économie. Une connexion réussie vaut de l'argent réel sur le marché des accès pour rançongiciels, et le coût d'une tentative est proche de zéro. Les bots ne s'arrêtent donc jamais. Mettez un Windows Server neuf sur une IP publique avec RDP ouvert : la première tentative échouée arrive généralement en moins d'une heure, et une semaine plus tard vous en avez quelques milliers par jour, régulièrement.

Le volume est l'élément essentiel. Un humain qui devine votre mot de passe est une anecdote ; cent mille tentatives par mois depuis des adresses tournantes est un phénomène météorologique. Les défenses qui supposent la première ne servent à rien contre le second.

Comment savoir si cela vous arrive

Windows enregistre chaque connexion échouée sous l'ID d'événement 4625 dans le journal de sécurité. Ouvrez l'Observateur d'événements, allez dans Journaux Windows → Sécurité et filtrez sur 4625. Sur un serveur tranquille vous verrez une poignée d'entrées de gens qui se sont trompés de mot de passe. Sous attaque, vous verrez un mur.

Le signe n'est pas le nombre en soi, c'est la forme. Un utilisateur qui se trompe produit deux ou trois échecs depuis une adresse, sur un compte qui existe, puis s'arrête. Un bot produit une longue série contre des noms de comptes qui n'ont jamais existé sur votre machine — admin, sql, backup, test, scanner, user1 — depuis des adresses de plages d'hébergement que vous n'avez jamais croisées, à un rythme régulier toute la nuit.

Cette commande donne les adresses sources les plus actives des dernières 24 heures :

powershell

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Pourquoi les conseils habituels ne marchent qu'à moitié

Toute liste de durcissement commence par « utilisez un mot de passe fort ». C'est juste et c'est insuffisant. Un mot de passe fort signifie que les bots ne le devineront pas — mais ils continueront d'essayer indéfiniment, et chaque tentative vous coûte un thread, une ligne de journal d'audit et une part de CPU. Les serveurs sous attaque continue ralentissent de façon mesurable, et le journal de sécurité tourne si vite que l'événement dont vous aviez besoin a disparu.

La ligne suivante est généralement « activez la stratégie de verrouillage de compte ». Méfiance. Le verrouillage compte les échecs par compte, et les bots devinent les noms de comptes depuis une liste. Verrouillez Administrator après cinq échecs et un attaquant qui n'avait aucune chance de deviner le mot de passe peut désormais désactiver ce compte à volonté, depuis n'importe où, indéfiniment. Vous avez transformé une nuisance en déni de service contre vous-même.

Network Level Authentication aide réellement : le client doit s'authentifier avant qu'une session ne soit créée, ce qui supprime une classe entière d'exploits pré-authentification et réduit le coût de chaque tentative. Activez-le. Il ne réduit pas le rythme des tentatives.

Un VPN devant RDP est la réponse la plus solide disponible et celle que la plupart des organisations ne peuvent pas réellement adopter : cela signifie que chaque prestataire, chaque téléphone, chaque connexion d'urgence à trois heures du matin passe par une infrastructure supplémentaire qu'il faut aussi maintenir et payer. Si vous le pouvez, faites-le. La plupart des serveurs attaqués en ce moment appartiennent à ceux qui ne le peuvent pas.

Ce qui réduit réellement les tentatives

Une seule chose change le volume : refuser de parler à la source. Tout le reste négocie avec elle.

Cela veut dire surveiller le flux d'échecs et, dès qu'une adresse franchit un seuil, l'ajouter à une règle de pare-feu qui jette ses paquets avant que Windows n'y consacre quoi que ce soit. C'est ce que fait fail2ban sous Linux, et il n'existe pas d'équivalent intégré à Windows — d'où le nombre d'administrateurs qui finissent par écrire un script PowerShell planifié.

Trois détails séparent une défense qui tient d'une défense qui fuit :

Bannir le sous-réseau, pas l'adresse. Les bots vivent sur des plages d'hébergement. Bloquez 203.0.113.47 et .48 démarre une heure plus tard. Bloquer le /24 met fin à toute la série d'un coup — et des utilisateurs légitimes ne partagent presque jamais un /24 avec un scanner.
Bannir définitivement, et survivre aux redémarrages. Un bannissement d'une heure signifie que le même botnet revient ce soir. La règle doit vivre dans le pare-feu, pas en mémoire.
Se mettre soi-même en liste blanche d'abord, avant d'activer quoi que ce soit d'autre. La façon la plus fréquente de tout casser est un administrateur qui bloque sa propre IP de bureau sur un serveur qu'il n'atteint que par RDP.

Regrouper les règles, sinon le pare-feu devient le goulot

Un détail qui n'apparaît qu'en production : le pare-feu Windows gère bien mieux quelques grandes règles que des milliers de petites. Les scripts qui appellent New-NetFirewallRule pour chaque adresse bannie fonctionnent parfaitement pendant quinze jours puis mettent des minutes à s'évaluer, parce que le jeu de règles a atteint cinq chiffres.

La solution est de garder une seule règle dont on réécrit la liste d'adresses, plutôt qu'une règle par attaquant. Une petite décision de conception qui détermine si la défense fonctionne encore dans six mois.

Obtenir la même chose sans écrire le script

RDP Protector, c'est cette logique empaquetée dans un agent Windows signé. Il lit le même flux 4625 que vous liriez, décide localement — il continue donc de fonctionner si le réseau tombe — et maintient une unique règle de pare-feu consolidée contenant toutes les plages bannies.

À l'installation, il détecte les ports RDP, FTP et MS SQL réels depuis le registre et les sockets en écoute, donc un serveur déplacé du 3389 est couvert sans configuration, et il met en liste blanche l'adresse depuis laquelle vous êtes connecté avant de bloquer quoi que ce soit.

Ce que vous ne pouvez pas construire seul, c'est la réputation partagée : une adresse qui a attaqué un autre client est déjà bloquée chez vous avant de vous atteindre. Un serveur est gratuit à vie, ce qui suffit à observer un vrai flux d'attaques sur votre propre machine et à décider sur preuves.

FAQ

Combien de connexions RDP échouées est-ce normal ?: Sur un serveur non exposé à internet, presque zéro — quelques-unes par semaine venant de gens qui se trompent de mot de passe. Sur un serveur dont le RDP est joignable depuis n'importe quelle adresse, quelques milliers par jour n'a rien de remarquable et ne dit rien sur vous en particulier : c'est le niveau de fond du balayage mondial. Ce qui compte est la tendance et la répartition des sources, pas le chiffre brut.
Changer le port RDP arrête-t-il les attaques brute-force ?: Cela arrête les scanners non ciblés qui ne sondent que le 3389, ce qui représente en pratique l'essentiel du volume — souvent plus de 90% de tentatives en moins. Cela n'arrête rien qui balaie toute la plage de ports, et des services comme Shodan indexent en continu le RDP sur des ports non standard. Voyez-le comme une réduction de bruit, pas comme une protection.
Faut-il activer le verrouillage de compte contre le brute-force ?: Pas comme défense principale sur un serveur exposé à internet. Le verrouillage repose sur le nom du compte, et les attaquants choisissent librement ce nom : n'importe qui peut donc verrouiller votre compte Administrator à la demande depuis n'importe quelle adresse. Bloquez au niveau réseau, et gardez le verrouillage avec un seuil modéré sur les comptes interactifs si vous y tenez.
Bannir tout un sous-réseau /24, n'est-ce pas trop agressif ?: Pour une plage qui vient de vous envoyer des centaines de connexions échouées, rarement. Le trafic d'attaque vient de plages d'hébergement et de VPS où les adresses voisines appartiennent au même opérateur ; les particuliers ne partagent presque jamais un /24 avec un scanner. Avec une liste blanche pour vos bureaux et sorties VPN, le taux de faux positifs est proche de zéro.