Il n'est pas rare que j'entende dire que laisser le port RDP (Remote Desktop Protocol) ouvert sur Internet est très dangereux et qu'il ne faut pas le faire. Il est préférable de fournir l'accès RDP soit via un VPN, soit uniquement à partir d'adresses IP "blanches" spécifiques.
J'administre plusieurs serveurs Windows pour de petites entreprises, dont la tâche m'a été confiée de fournir un accès à distance aux serveurs Windows pour les comptables. C'est une tendance moderne — le travail à domicile. J'ai rapidement compris que faire subir un VPN aux comptables est une entreprise ingrate, et qu'il est impossible de rassembler toutes les IP pour une liste blanche, car les adresses IP des gens sont dynamiques.
C'est pourquoi j'ai opté pour la solution la plus simple — j'ai ouvert le port RDP à l'extérieur. Désormais, pour accéder, les comptables doivent lancer RDP et entrer le nom d'hôte (y compris le port), le nom d'utilisateur et le mot de passe.
Dans cet article, je partagerai mon expérience (positive et moins bonne) et mes recommandations.
Risques
Quels sont les risques d'ouvrir le port RDP ?
1) Accès non autorisé à des données sensibles
Si quelqu'un devine le mot de passe RDP, il pourra accéder aux informations que vous souhaitez garder privées : l'état des comptes, les soldes, les données des clients, …
2) Perte de données
Par exemple, à la suite de l'action d'un virus de type ransomware.
Ou d'une action ciblée d'un cybercriminel.
3) Perte de station de travail
Les employés doivent travailler, mais le système est compromis, il faut réinstaller / restaurer / configurer.
4) Compromission du réseau local
Si un cybercriminel a accédé à un ordinateur Windows, il pourra accéder à des systèmes non accessibles de l'extérieur, d'Internet. Par exemple, aux partages de fichiers, aux imprimantes réseau, etc.
J'ai eu un cas où un serveur Windows a été infecté par un ransomware
et ce ransomware a d'abord chiffré la plupart des fichiers sur le disque C:, puis a commencé à chiffrer les fichiers sur le NAS via le réseau. Étant donné que le NAS était un Synology, avec des snapshots configurés, j'ai pu restaurer le NAS en 5 minutes, alors que je devais réinstaller le serveur Windows depuis le début.
Observations et recommandations
Je surveille les serveurs Windows avec , qui envoient des logs vers ElasticSearch. Dans Kibana, il y a plusieurs visualisations, et j'ai également configuré un tableau de bord personnalisé.
La surveillance en elle-même ne protège pas, mais aide à déterminer les mesures nécessaires.
Voici quelques observations :
a) RDP sera soumis à des attaques par force brute.
Sur l'un des serveurs, j'ai configuré RDP sur un port non standard, 443 — comme si je me cachais sous HTTPS. Changer le port par rapport au standard semble raisonnable, mais cela n'apporte pas tant de bénéfices. Voici les statistiques de ce serveur :
On peut voir qu'il y a eu près de 400 000 tentatives échouées d'accès RDP en une semaine.
On remarque que les tentatives proviennent de 55 001 adresses IP différentes (certaines adresses IP ont déjà été bloquées par mes soins).
Il en ressort clairement qu'il faudrait mettre en place fail2ban, mais
il n'existe pas de tels outils pour Windows.
Il existe quelques projets abandonnés sur GitHub qui semblent faire cela, mais je n'ai même pas essayé de les installer :
Il y a aussi des outils payants, mais je ne les ai pas pris en compte.
Si vous connaissez un outil libre pour cet objectif, n'hésitez pas à le partager dans les commentaires.
Mise à jour: Dans les commentaires, on m'a suggéré que le port 443 n'était pas un bon choix, et qu'il vaut mieux choisir des ports élevés (32000+), parce que 443 est scanné plus fréquemment, et reconnaître RDP sur ce port n'est pas un problème.
Mise à jour : Dans les commentaires, on m'a aussi dit qu'il existe un tel outil :
b) Il y a certains noms d'utilisateur que les attaquants préfèrent
On constate que le brute force se fait par un dictionnaire contenant divers noms.
Mais ce que j'ai remarqué : un nombre significatif de tentatives utilise le nom du serveur comme identifiant. Recommandation : ne pas utiliser le même nom pour l'ordinateur et l'utilisateur. En fait, parfois, il semble que le nom du serveur soit analysé : par exemple, pour un système nommé DESKTOP-DFTHD7C, il y a eu le plus de tentatives avec le nom DFTHD7C :
Ainsi, si vous avez un ordinateur nommé DESKTOP-MARIA, il y aura probablement des tentatives de connexion avec l'utilisateur MARIA.
Encore une chose que j'ai remarquée dans les journaux : sur la plupart des systèmes, la majorité des tentatives d'accès se font avec le nom "administrator". Ce n'est pas anodin, car dans de nombreuses versions de Windows, cet utilisateur existe. De plus, il est impossible de le supprimer. Cela facilite la tâche aux attaquants : plutôt que de devoir deviner le nom et le mot de passe, ils n'ont besoin que de deviner le mot de passe.
À propos, le système qui a été infecté par le ransomware avait l'utilisateur Administrator et le mot de passe Murmansk#9. Je ne suis toujours pas sûr de la manière dont ce système a été piraté, car j'ai commencé à surveiller juste après cet incident, mais je pense que le brute force est probable.
Donc, si l'utilisateur Administrator ne peut pas être supprimé, que faire ? On peut le renommer !
Recommandations de ce point :
- n'utilisez pas le nom d'utilisateur dans le nom de l'ordinateur
- assurez-vous qu'il n'y a pas d'utilisateur Administrator dans le système
- utilisez des mots de passe fiables
Voilà comment j'observe plusieurs Windows Server sous mon contrôle être brute-forcés depuis environ deux ans, sans succès.
Comment je le sais, qu'il n'y a pas de succès ?
Parce que dans les captures d'écran ci-dessus, il est visible qu'il y a des journaux d'accès réussis par RDP, contenant les informations suivantes :
- de quelle adresse IP
- de quel ordinateur (hostname)
- nom d'utilisateur
- informations GeoIP
Et je les surveille régulièrement — aucune anomalie détectée.
Au fait, si un certain IP est particulièrement persistant dans le brute-force, vous pouvez bloquer des IP (ou sous-réseaux) spécifiques de cette façon dans PowerShell :
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockÀ propos, chez Elastic, en plus de Winlogbeat, il y a aussi , qui peut surveiller les fichiers et les processus sur le système. Il y a aussi une application SIEM (Security Information & Event Management) dans Kibana. J'ai essayé les deux, mais je n'ai pas vu beaucoup d'utilité — il semble qu'Auditbeat sera plus utile pour les systèmes Linux, et le SIEM ne m'a rien montré de clair pour l'instant.
Et enfin, quelques recommandations :
- effectuez des sauvegardes automatiques régulières.
- installez les mises à jour de sécurité à temps
Bonus : liste de 50 utilisateurs qui ont été utilisés le plus fréquemment pour des tentatives de connexion par RDP
"user.name: Descending"
Count
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
serveur
21983
steve
21936
john
21927
paul
21913
reception
21909
mike
21899
office
21888
scanner
21887
scan
21867
david
21865
chris
21860
propriétaire
21855
manager
21852
L'administrateur des
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
UTILISATEUR
4558
admin
2832
TEST
1928
MySql
1664
Admin
1652
GUEST
1322
USER1
1179
SCANNER
1121
SCAN
1032
ADMINISTRATEUR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPTION
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
Il est fréquent de lire que laisser le port RDP (Remote Desktop Protocol) ouvert sur Internet est très dangereux, et qu'il ne faut pas le faire.
410
Source : habr.com
