J'ai souvent lu l'opinion selon laquelle garder un port RDP (Remote Desktop Protocol) ouvert à Internet est très dangereux et ne devrait pas être fait. Mais vous devez donner accès à RDP soit via un VPN, soit uniquement à partir de certaines adresses IP « blanches ».
J'administre plusieurs serveurs Windows pour de petites entreprises où j'ai été chargé de fournir un accès à distance à Windows Server aux comptables. C'est la tendance moderne : le travail à domicile. Assez rapidement, j'ai réalisé que tourmenter les comptables VPN est une tâche ingrate et que collecter toutes les adresses IP pour la liste blanche ne fonctionnera pas, car les adresses IP des gens sont dynamiques.
Par conséquent, j'ai choisi la voie la plus simple : transférer le port RDP vers l'extérieur. Pour y accéder, les comptables doivent désormais exécuter RDP et saisir 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 positive) et mes recommandations.
Risques
Que risquez-vous en ouvrant le port RDP ?
1) Accès non autorisé aux données sensibles
Si quelqu'un devine le mot de passe RDP, il pourra obtenir les données que vous souhaitez garder privées : statut du compte, soldes, données clients, ...
2) Perte de données
Par exemple, à la suite d’un virus ransomware.
Ou une action délibérée d’un attaquant.
3) Perte de poste de travail
Les travailleurs doivent travailler, mais le système est compromis et doit être réinstallé/restauré/configuré.
4) Compromission du réseau local
Si un attaquant a accédé à un ordinateur Windows, alors depuis cet ordinateur, il pourra accéder à des systèmes inaccessibles de l'extérieur, depuis Internet. Par exemple, vers des partages de fichiers, vers des imprimantes réseau, etc.
J'ai eu un cas où Windows Server a attrapé un ransomware
et ce ransomware a d'abord chiffré la plupart des fichiers du lecteur C:, puis a commencé à chiffrer les fichiers du NAS sur le réseau. Comme le NAS était Synology, avec des instantanés configurés, j'ai restauré le NAS en 5 minutes et réinstallé Windows Server à partir de zéro.
Observations et recommandations
Je surveille les serveurs Windows en utilisant , qui envoie des journaux à ElasticSearch. Kibana propose plusieurs visualisations et j'ai également mis en place un tableau de bord personnalisé.
La surveillance en elle-même ne protège pas, mais elle aide à déterminer les mesures nécessaires.
Voici quelques observations :
a) RDP sera forcé brutalement.
Sur l'un des serveurs, j'ai installé RDP non pas sur le port standard 3389, mais sur 443 - eh bien, je vais me déguiser en HTTPS. Cela vaut probablement la peine de changer le port du port standard, mais cela ne servira pas à grand-chose. Voici les statistiques de ce serveur :
On peut constater qu'en une semaine, il y a eu près de 400 000 tentatives infructueuses de connexion via RDP.
On peut voir qu'il y a eu des tentatives de connexion à partir de 55 001 adresses IP (certaines adresses IP ont déjà été bloquées par moi).
Cela suggère directement la conclusion selon laquelle vous devez définir fail2ban, mais
Il n'existe pas de tel utilitaire pour Windows.
Il y a quelques projets abandonnés sur Github qui semblent faire cela, mais je n'ai même pas essayé de les installer :
Il existe également des services publics payants, mais je ne les ai pas pris en compte.
Si vous connaissez un utilitaire open source à cet effet, partagez-le dans les commentaires.
Mises à jour: Les commentaires suggèrent que le port 443 est un mauvais choix et qu'il est préférable de choisir des ports élevés (32000 443+), car XNUMX est analysé plus souvent et la reconnaissance de RDP sur ce port n'est pas un problème.
b) Il existe certains noms d'utilisateur que les attaquants préfèrent
On constate que la recherche s'effectue dans un dictionnaire avec des noms différents.
Mais voici ce que j'ai remarqué : un nombre important de tentatives utilisent le nom du serveur comme identifiant. Recommandation : N'utilisez pas le même nom pour l'ordinateur et l'utilisateur. De plus, il semble parfois qu'ils essaient d'analyser le nom du serveur d'une manière ou d'une autre : par exemple, pour un système portant le nom DESKTOP-DFTHD7C, la plupart des tentatives de connexion portent le nom DFTHD7C :
Par conséquent, si vous possédez un ordinateur DESKTOP-MARIA, vous essaierez probablement de vous connecter en tant qu'utilisateur MARIA.
Une autre chose que j'ai remarquée dans les journaux : sur la plupart des systèmes, la plupart des tentatives de connexion portent le nom « administrateur ». Et ce n’est pas sans raison, car dans de nombreuses versions de Windows, cet utilisateur existe. De plus, il ne peut pas être supprimé. Cela simplifie la tâche des attaquants : au lieu de deviner un nom et un mot de passe, il vous suffit de deviner le mot de passe.
À propos, le système qui a détecté le ransomware avait l'utilisateur Administrateur et le mot de passe Murmansk#9. Je ne sais toujours pas comment ce système a été piraté, car j’ai commencé à le surveiller juste après cet incident, mais je pense qu’il s’agit probablement d’un excès.
Donc, si l’utilisateur administrateur ne peut pas être supprimé, que devez-vous faire ? Vous pouvez le renommer !
Recommandations de ce paragraphe :
- n'utilisez pas le nom d'utilisateur dans le nom de l'ordinateur
- assurez-vous qu'il n'y a pas d'utilisateur administrateur sur le système
- utilisez des mots de passe forts
Ainsi, j'ai observé plusieurs serveurs Windows sous mon contrôle être forcés par force brute depuis environ quelques années maintenant, et sans succès.
Comment savoir si c'est un échec ?
Parce que dans les captures d'écran ci-dessus, vous pouvez voir qu'il existe des journaux d'appels RDP réussis, qui contiennent les informations :
- à partir de quelle IP
- à partir de quel ordinateur (nom d'hôte)
- имя пользователя
- Informations géoIP
Et j'y vérifie régulièrement - aucune anomalie n'a été trouvée.
À propos, si une adresse IP particulière est particulièrement brutalement forcée, vous pouvez bloquer des adresses IP individuelles (ou des sous-réseaux) comme ceci 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, Elastic, en plus de Winlogbeat, a également , qui peut surveiller les fichiers et les processus sur le système. Il existe également une application SIEM (Security Information & Event Management) dans Kibana. J'ai essayé les deux, mais je n'ai pas vu beaucoup d'avantages - il semble qu'Auditbeat sera plus utile pour les systèmes Linux, et SIEM ne m'a encore rien montré d'intelligible.
Eh bien, dernières recommandations :
- Effectuez des sauvegardes automatiques régulières.
- installer les mises à jour de sécurité en temps opportun
Bonus : liste des 50 utilisateurs les plus souvent utilisés pour les tentatives de connexion RDP
"nom d'utilisateur : décroissant"
que vous avez
dfthd7c (nom d'hôte)
842941
winsrv1 (nom d'hôte)
266525
ADMINISTRATEUR
180678
administrateur
163842
Administrateur
53541
Michael
23101
serveur
21983
steve
21936
Jean
21927
paul
21913
réception
21909
micro
21899
familial
21888
scanner
21887
balayage
21867
david
21865
chris
21860
propriétaire
21855
manager
21852
administrateur
21841
brian
21839
administrateur
21837
marque
21824
D'USINE
21806
ADMIN
12748
TRAITEMENT
7772
ADMINISTRATEUR
7325
SUPPORT
5577
SUPPORT
5418
UTILISATEUR
4558
admin
2832
TEST
1928
MySql
1664
Administrateur
1652
CLIENT
1322
USER1
1179
SCANNER
1121
SCAN
1032
ADMINISTRATEUR
842
ADMIN1
525
SAUVEGARDE
518
Mon Administrateur SQL
518
ACCUEIL
490
USER2
466
TEMP
452
ADMINSQL
450
USER3
441
1
422
DIRECTRICE
418
PROPRIÉTAIRE
410
Source: habr.com