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
