Ich habe oft die Meinung gelesen, dass das Offenhalten eines RDP-Ports (Remote Desktop Protocol) zum Internet sehr unsicher ist und nicht getan werden sollte. Sie müssen den Zugriff auf RDP jedoch entweder über ein VPN oder nur von bestimmten „weißen“ IP-Adressen aus ermöglichen.
Ich verwalte mehrere Windows-Server für kleine Unternehmen, bei denen ich damit beauftragt wurde, Buchhaltern Fernzugriff auf Windows Server bereitzustellen. Das ist der moderne Trend – Arbeiten von zu Hause aus. Ziemlich schnell wurde mir klar, dass es eine undankbare Aufgabe ist, VPN-Buchhalter zu quälen, und dass das Sammeln aller IPs für die Whitelist nicht funktionieren wird, weil die IP-Adressen der Leute dynamisch sind.
Daher habe ich den einfachsten Weg gewählt – den RDP-Port nach außen weitergeleitet. Um Zugriff zu erhalten, müssen Buchhalter nun RDP ausführen und den Hostnamen (einschließlich Port), den Benutzernamen und das Passwort eingeben.
In diesem Artikel werde ich meine Erfahrungen (positiv und nicht so positiv) und Empfehlungen teilen.
Risiken
Was riskieren Sie, wenn Sie den RDP-Port öffnen?
1) Unbefugter Zugriff auf sensible Daten
Wenn jemand das RDP-Passwort errät, kann er an Daten gelangen, die Sie geheim halten möchten: Kontostatus, Guthaben, Kundendaten, ...
2) Datenverlust
Zum Beispiel als Folge eines Ransomware-Virus.
Oder eine vorsätzliche Aktion eines Angreifers.
3) Verlust des Arbeitsplatzes
Die Arbeiter müssen arbeiten, aber das System ist kompromittiert und muss neu installiert/wiederhergestellt/konfiguriert werden.
4) Kompromittierung des lokalen Netzwerks
Wenn sich ein Angreifer Zugriff auf einen Windows-Computer verschafft hat, kann er von diesem Computer aus auf Systeme zugreifen, die von außen, also aus dem Internet, nicht zugänglich sind. Zum Beispiel an Dateifreigaben, an Netzwerkdrucker usw.
Ich hatte einen Fall, in dem Windows Server eine Ransomware entdeckte
und diese Ransomware verschlüsselte zunächst die meisten Dateien auf dem Laufwerk C: und begann dann mit der Verschlüsselung der Dateien auf dem NAS über das Netzwerk. Da es sich bei dem NAS um Synology handelte und Snapshots konfiguriert waren, habe ich das NAS in 5 Minuten wiederhergestellt und Windows Server von Grund auf neu installiert.
Beobachtungen und Empfehlungen
Ich überwache Windows-Server mit , die Protokolle an ElasticSearch senden. Kibana verfügt über mehrere Visualisierungen und ich habe auch ein benutzerdefiniertes Dashboard eingerichtet.
Die Überwachung selbst schützt nicht, hilft aber dabei, die notwendigen Maßnahmen festzulegen.
Hier einige Beobachtungen:
a) RDP wird brutal erzwungen.
Auf einem der Server habe ich RDP nicht auf dem Standardport 3389, sondern auf 443 installiert – nun, ich tarne mich als HTTPS. Es lohnt sich wahrscheinlich, den Standard-Port zu ändern, aber das bringt nicht viel. Hier sind die Statistiken von diesem Server:
Es ist ersichtlich, dass es in einer Woche fast 400 erfolglose Anmeldeversuche über RDP gab.
Es ist ersichtlich, dass es Anmeldeversuche von 55 IP-Adressen gab (einige IP-Adressen wurden von mir bereits blockiert).
Dies legt direkt die Schlussfolgerung nahe, dass Sie fail2ban festlegen müssen, aber
Für Windows gibt es kein solches Dienstprogramm.
Es gibt ein paar aufgegebene Projekte auf Github, die das zu tun scheinen, aber ich habe noch nicht einmal versucht, sie zu installieren:
Es gibt auch kostenpflichtige Nebenkosten, die ich aber nicht in Betracht gezogen habe.
Wenn Sie ein Open-Source-Dienstprogramm für diesen Zweck kennen, teilen Sie es bitte in den Kommentaren mit.
Aktualisierung: In den Kommentaren wurde darauf hingewiesen, dass Port 443 eine schlechte Wahl ist und dass es besser ist, Ports mit hohen Ports (32000+) zu wählen, da 443 häufiger gescannt wird und die Erkennung von RDP auf diesem Port kein Problem darstellt.
b) Es gibt bestimmte Benutzernamen, die Angreifer bevorzugen
Es ist zu erkennen, dass die Suche in einem Wörterbuch mit unterschiedlichen Namen durchgeführt wird.
Aber Folgendes ist mir aufgefallen: Bei einer erheblichen Anzahl von Versuchen wird der Servername als Login verwendet. Empfehlung: Verwenden Sie nicht denselben Namen für Computer und Benutzer. Darüber hinaus sieht es manchmal so aus, als würden sie versuchen, den Servernamen irgendwie zu analysieren: Beispielsweise erfolgen bei einem System mit dem Namen DESKTOP-DFTHD7C die meisten Anmeldeversuche mit dem Namen DFTHD7C:
Wenn Sie also einen DESKTOP-MARIA-Computer haben, werden Sie wahrscheinlich versuchen, sich als MARIA-Benutzer anzumelden.
Eine weitere Sache, die mir anhand der Protokolle aufgefallen ist: Auf den meisten Systemen erfolgen die meisten Anmeldeversuche mit dem Namen „Administrator“. Und das nicht ohne Grund, denn in vielen Windows-Versionen existiert dieser Benutzer. Darüber hinaus kann es nicht gelöscht werden. Dies vereinfacht die Aufgabe für Angreifer: Anstatt einen Namen und ein Passwort zu erraten, müssen Sie nur noch das Passwort erraten.
Das System, das die Ransomware abfing, hatte übrigens den Benutzer Administrator und das Passwort Murmansk#9. Ich bin mir immer noch nicht sicher, wie dieses System gehackt wurde, da ich direkt nach diesem Vorfall mit der Überwachung begonnen habe, aber ich halte das für wahrscheinlich.
Wenn also der Administratorbenutzer nicht gelöscht werden kann, was sollten Sie dann tun? Sie können es umbenennen!
Empfehlungen aus diesem Absatz:
- Verwenden Sie den Benutzernamen nicht im Computernamen
- Stellen Sie sicher, dass es keinen Administrator-Benutzer auf dem System gibt
- Verwenden Sie starke Passwörter
Ich beobachte also schon seit einigen Jahren, wie auf mehreren von mir kontrollierten Windows-Servern Brute-Force-Angriffe durchgeführt werden, allerdings ohne Erfolg.
Woran erkenne ich, dass es nicht erfolgreich ist?
Denn in den Screenshots oben sieht man, dass es Protokolle erfolgreicher RDP-Aufrufe gibt, die die Informationen enthalten:
- von welcher IP
- von welchem Rechner (Hostname)
- Benutzername
- GeoIP-Informationen
Und ich schaue dort regelmäßig nach – es wurden keine Auffälligkeiten festgestellt.
Übrigens, wenn eine bestimmte IP besonders hart brutal erzwungen wird, dann können Sie einzelne IPs (oder Subnetze) wie folgt in PowerShell blockieren:
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 BlockDas hat übrigens neben Winlogbeat auch Elastic , das Dateien und Prozesse auf dem System überwachen kann. Es gibt auch eine SIEM-Anwendung (Security Information & Event Management) in Kibana. Ich habe beides ausprobiert, aber keinen großen Nutzen gesehen – es sieht so aus, als ob Auditbeat für Linux-Systeme nützlicher sein wird, und SIEM hat mir noch nichts Verständliches gezeigt.
Nun, abschließende Empfehlungen:
- Machen Sie regelmäßig automatische Backups.
- Installieren Sie Sicherheitsupdates rechtzeitig
Bonus: Liste der 50 Benutzer, die am häufigsten für RDP-Anmeldeversuche verwendet wurden
„Benutzername: Absteigend“
Zu Zählen
dfthd7c (Hostname)
842941
winsrv1 (Hostname)
266525
ADMINISTRATOR
180678
Administratoren.
163842
Administrator
53541
Michael
23101
Server
21983
steve
21936
John
21927
Paul
21913
Rezeption
21909
Mikrofon
21899
Büro
21888
Scanner
21887
Scan
21867
David
21865
chris
21860
Eigentümer
21855
Manager
21852
administrateur
21841
brian
21839
Verwalter
21837
Kennzeichen
21824
Personal
21806
ADMINISTRATOR
12748
ROOT
7772
VERWALTER
7325
SUPPORT
5577
UNTERSTÜTZUNG
5418
USER
4558
Administrator
2832
TESTEN
1928
MySql
1664
Administrator
1652
GUEST
1322
USER1
1179
SCANNER
1121
SCAN
1032
ADMINISTRATOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
REZEPTION
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
EIGENTÜMER
410
Source: habr.com