Es wird häufig die Meinung vertreten, dass es sehr unsicher ist, den RDP (Remote Desktop Protocol) Port im Internet offen zu lassen, und man dies vermeiden sollte. Stattdessen sollte der Zugang zum RDP entweder über VPN oder nur von bestimmten "weißen" IP-Adressen gewährt werden.
Ich verwalte mehrere Windows Server für kleine Unternehmen, die mich beauftragt haben, den Remote-Zugriff auf den Windows Server für Buchhalter zu ermöglichen. Das ist der moderne Trend – Arbeiten von zu Hause. Schnell wurde mir klar, dass es undankbar ist, die Buchhalter mit VPN zu quälen, und dass es nicht möglich ist, alle IPs für die Whitelist zu sammeln, da die IP-Adressen der Leute dynamisch sind.
Deshalb bin ich den einfachsten Weg gegangen – ich habe den RDP Port nach außen weitergeleitet. Jetzt müssen die Buchhalter nur RDP starten und den Hostnamen (einschließlich Port), den Benutzernamen und das Passwort eingeben.
In diesem Artikel teile ich meine Erfahrungen (positive und weniger positive) sowie Empfehlungen.
Risiken
Welche Risiken haben Sie, wenn Sie den RDP-Port öffnen?
1) Unbefugter Zugang zu sensiblen Daten
Wenn jemand das Passwort für RDP errät, könnte er Zugang zu Daten erhalten, die Sie privat halten möchten: Kontostände, Salden, Kundendaten, …
2) Datenverlust
Zum Beispiel durch die Arbeit eines Ransomware-Virus.
Oder durch gezielte Handlungen eines Angreifers.
3) Verlust der Arbeitsstation
Die Mitarbeiter müssen arbeiten, aber das System ist kompromittiert, es muss neu installiert / wiederhergestellt / konfiguriert werden.
4) Kompromittierung des lokalen Netzwerks
Wenn ein Angreifer Zugriff auf einen Windows-Computer erhält, hat er von diesem Computer aus Zugang zu Systemen, die von außen, aus dem Internet, nicht zugänglich sind. Zum Beispiel zu Datei-Servern, Netzwerkkopierern und so weiter.
Ich hatte einen Fall, in dem ein Windows Server Ransomware erwischt hat
und diese Ransomware zuerst die meisten Dateien auf dem Laufwerk C: verschlüsselte und dann begann, Dateien auf dem NAS über das Netzwerk zu verschlüsseln. Da die NAS von Synology war und mit Snapshots eingerichtet war, konnte ich die NAS in 5 Minuten wiederherstellen, während ich den Windows Server von Grund auf neu installieren musste.
Beobachtungen und Empfehlungen
Ich überwache Windows Server mit Hilfe von , die Protokolle an ElasticSearch senden. In Kibana gibt es mehrere Visualisierungen, und ich habe mir noch ein benutzerdefiniertes Dashboard eingerichtet.
Die Überwachung selbst bietet keinen Schutz, hilft aber, die notwendigen Maßnahmen zu bestimmen.
Hier sind einige Beobachtungen:
a) RDP wird mit Brute-Force-Attacken angegriffen.
Auf einem der Server habe ich RDP nicht auf den Standardport 3389, sondern auf 443 gesetzt - quasi um mich als HTTPS zu tarnen. Es lohnt sich, den Port vom Standard zu ändern, aber viel bringt das nicht. Hier ist die Statistik von diesem Server:
Es ist zu sehen, dass es in der Woche fast 400.000 erfolglose Versuche gab, sich über RDP einzuloggen.
Es ist ersichtlich, dass die Versuche von 55.001 IP-Adressen ausgegangen sind (einige IP-Adressen waren bereits von mir blockiert).
Hier drängt sich der Schluss auf, dass man fail2ban installieren sollte, aber
es gibt kein solches Tool für Windows.
Es gibt ein paar verwaiste Projekte auf GitHub, die das anscheinend tun, aber ich habe sie nicht ausprobiert:
Es gibt auch kostenpflichtige Tools, aber ich habe sie nicht in Betracht gezogen.
Wenn Sie ein offenes Tool für diesen Zweck wissen, teilen Sie es bitte in den Kommentaren.
Update: In den Kommentaren wurde angemerkt, dass der Port 443 eine unglückliche Wahl ist und man besser hohe Ports (32000+) wählen sollte, da 443 häufiger gescannt wird, und es kein Problem ist, RDP auf diesem Port zu erkennen.
Update: In den Kommentaren wurde darauf hingewiesen, dass es ein solches Tool gibt:
b) Es gibt bestimmte Benutzernamen, die Angreifer bevorzugen
Es ist ersichtlich, dass ein Wörterbuch mit verschiedenen Namen durchprobiert wird.
Aber was mir aufgefallen ist: Eine erhebliche Anzahl der Versuche nutzt den Namen des Servers als Login. Empfehlung: Verwenden Sie nicht denselben Namen für den Computer und für den Benutzer. Manchmal scheinen Angreifer den Servernamen irgendwie zu parsen: Zum Beispiel gab es für ein System mit dem Namen DESKTOP-DFTHD7C die meisten Versuche mit dem Namen DFTHD7C:
Entsprechend, wenn Sie einen Computer mit dem Namen DESKTOP-MARIA haben, werden wahrscheinlich Versuche unternommen, sich als Benutzer MARIA einzuloggen.
Außerdem habe ich in den Protokollen bemerkt: Bei den meisten Systemen sind die meisten Versuche, sich einzuloggen, mit dem Namen "administrator". Und das ist nicht ohne Grund, denn in vielen Windows-Versionen existiert dieser Benutzer. Darüber hinaus kann er nicht gelöscht werden. Das erleichtert es den Angreifern: Statt den Namen und das Passwort zu erraten, müssen sie nur das Passwort erraten.
Übrigens hatte das System, das ich mit einem Ransomware-Angriff erwischt habe, den Benutzer Administrator und das Passwort Murmansk#9. Ich bin mir immer noch nicht sicher, wie dieses System gehackt wurde, da ich mit dem Monitoring gerade nach diesem Vorfall begonnen habe, aber ich denke, dass ein Brute-Force-Angriff wahrscheinlich ist.
Wenn man den Benutzer Administrator nicht löschen kann, was kann man dann tun? Man kann ihn umbenennen!
Empfehlungen aus diesem Punkt:
- Verwenden Sie nicht den Benutzernamen im Computernamen.
- Stellen Sie sicher, dass es auf dem System keinen Benutzer mit dem Namen Administrator gibt.
- Verwenden Sie sichere Passwörter.
So beobachte ich, dass mehrere Windows-Server unter meinem Management seit etwa zwei Jahren bruteforced werden, und zwar ohne Erfolg.
Woher ich weiß, dass es erfolglos ist?
Weil auf den obigen Screenshots zu sehen ist, dass es Protokolle erfolgreicher RDP-Zugriffe gibt, die Informationen enthalten:
- von welcher IP
- von welchem Computer (Hostname)
- Benutzername
- GeoIP-Informationen
Und ich schaue regelmäßig dort nach – keine Anomalien wurden festgestellt.
Übrigens, wenn von einer bestimmten IP besonders intensiv bruteforced wird, können Sie einzelne IPs (oder Subnetze) in PowerShell so 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 BlockÜbrigens hat Elastic, neben Winlogbeat, auch , das Dateien und Prozesse auf dem System überwachen kann. Außerdem gibt es eine SIEM (Security Information & Event Management) Anwendung in Kibana. Ich habe beides ausprobiert, aber keinen großartigen Nutzen gesehen – scheinbar ist Auditbeat nützlicher für Linux-Systeme, während SIEM mir bisher nichts Sinnvolles gezeigt hat.
Nun zu den abschließenden Empfehlungen:
- Führen Sie regelmäßig automatische Backups durch.
- Installieren Sie Sicherheitsupdates zeitnah.
Bonus: Liste von 50 Benutzern, die am häufigsten für RDP-Zugriffsversuche verwendet wurden.
"user.name: Absteigend"
Anzahl
dfthd7c (Hostname)
842941
winsrv1 (Hostname)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
reception
21909
mike
21899
office
21888
scanner
21887
scan
21867
david
21865
chris
21860
owner
21855
manager
21852
administrateur
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
USER
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
Häufig habe ich die Meinung gelesen, dass es sehr unsicher ist, den RDP (Remote Desktop Protocol) Port im Internet offen zu halten, und man das nicht tun sollte.
410
Quelle: habr.com
