Ich habe oft die Meinung gelesen, dass es sehr unsicher ist, den RDP (Remote Desktop Protocol) Port im Internet offen zu lassen und dass man dies vermeiden sollte. Der Zugang zu RDP sollte entweder über ein VPN oder nur von bestimmten "weißen" IP-Adressen gewährt werden.
Ich verwalte mehrere Windows-Server für kleine Unternehmen, in denen ich die Aufgabe bekommen habe, den Remote-Zugang zu Windows-Servern für Buchhalter zu gewährleisten. Ein moderner Trend – Arbeiten von zu Hause aus. Ich habe schnell gemerkt, dass es unangemessen ist, den Buchhaltern mit einem 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 habe ich den einfachsten Weg gewählt – ich habe den RDP-Port nach außen weitergeleitet. Jetzt müssen die Buchhalter RDP starten und den Hostnamen (einschließlich Port), den Benutzernamen und das Passwort eingeben.
In diesem Artikel teile ich meine Erfahrungen (sowohl positive als auch weniger positive) und Empfehlungen.
Risiken
Was riskieren Sie, wenn Sie den RDP-Port öffnen?
1) Unautorisierter Zugriff auf sensible Daten
Wenn jemand das Passwort für RDP knackt, kann er auf Daten zugreifen, die Sie privat halten möchten: Kontostände, Bilanzdaten, Kundendaten, …
2) Datenverlust
Zum Beispiel infolge eines Ransomware-Angriffs.
Oder durch gezielte Maßnahmen eines Angreifers.
3) Verlust der Arbeitsstation
Mitarbeiter müssen arbeiten, während das System kompromittiert ist; es muss neu installiert, wiederhergestellt oder konfiguriert werden.
4) Kompromittierung des lokalen Netzwerks
Wenn ein Angreifer Zugriff auf einen Windows-Computer erhält, kann er bereits über diesen Computer auf Systeme zugreifen, die von außen, aus dem Internet, nicht erreichbar sind. Zum Beispiel auf Datei-Shares, Netzwerkkopierer usw.
Ich hatte einen Fall, bei dem ein Windows Server von Ransomware befallen wurde
und diese Ransomware zuerst die meisten Dateien auf Laufwerk C: verschlüsselte, bevor sie begann, Dateien auf dem NAS über das Netzwerk zu verschlüsseln. Da das NAS von Synology war und mit Snapshots konfiguriert war, konnte ich das 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 allein bietet keinen Schutz, hilft jedoch, die erforderlichen Maßnahmen zu bestimmen.
Hier sind einige Beobachtungen:
a) RDP wird durch Brute-Force-Angriffe angegriffen.
Auf einem meiner Server habe ich RDP nicht auf dem Standardport 3389, sondern auf 443 eingestellt – um mich angeblich als HTTPS zu tarnen. Es ist wahrscheinlich sinnvoll, den Standardport zu ändern, aber der Nutzen ist gering. Hier sind die Statistiken von diesem Server:
Es ist zu erkennen, dass es in einer Woche fast 400.000 fehlgeschlagene Versuche gab, sich über RDP einzuloggen.
Es gab Versuche von 55.001 IP-Adressen (einige IP-Adressen wurden bereits von mir blockiert).
Hier liegt der Schluss nahe, dass man fail2ban einsetzen sollte, aber
es gibt kein solches Tool für Windows.
Es gibt ein paar aufgegebene Projekte auf GitHub, die anscheinend das tun, aber ich habe sie nicht ausprobiert:
Es gibt auch kostenpflichtige Tools, die ich jedoch nicht betrachtet habe.
Wenn Sie ein Open-Source-Tool für diesen Zweck kennen, teilen Sie es bitte in den Kommentaren.
Update: In den Kommentaren wurde vorgeschlagen, dass Port 443 eine unglückliche Wahl ist, und es besser ist, hohe Ports (32000+) zu wählen, weil 443 häufiger gescannt wird und es kein Problem ist, RDP auf diesem Port zu erkennen.
Update: In den Kommentaren wurde vorgeschlagen, dass es ein solches Tool gibt:
b) Es gibt bestimmte Benutzernamen, die von Angreifern bevorzugt werden.
Es ist offensichtlich, dass die Versuche aus einem Wörterbuch mit verschiedenen Namen stammen.
Aber was mir aufgefallen ist: Eine erhebliche Anzahl der Versuche verwendet den Servernamen als Anmeldenamen. Empfehlung: Verwenden Sie nicht denselben Namen für den Computer und den Benutzer. Manchmal scheinen Angreifer versuchen, den Servernamen zu parsen: Zum Beispiel bei einem System mit dem Namen DESKTOP-DFTHD7C sind die meisten Zugriffsversuche unter dem Namen DFTHD7C.
Wenn Sie also einen Computer mit dem Namen DESKTOP-MARIA haben, werden wahrscheinlich viele Versuche unternommen, sich als Benutzer MARIA anzumelden.
Außerdem habe ich aus den Protokollen gesehen: Auf den meisten Systemen sind die meisten Zugriffsversuche mit dem Namen "administrator". Und das ist kein Zufall, denn in vielen Windows-Versionen existiert dieser Benutzer. Außerdem kann er nicht gelöscht werden. Das erleichtert es den Angreifern: Statt einen Benutzernamen und ein Passwort zu erraten, müssen sie nur das Passwort finden.
Übrigens hatte das System, das von einem Ransomware-Angriff betroffen war, den Benutzer Administrator und das Passwort Murmansk#9. Ich bin mir immer noch nicht sicher, wie dieses System gehackt wurde, denn ich habe mit dem Monitoring genau nach diesem Vorfall begonnen. Ich denke jedoch, dass ein Brute-Force-Angriff wahrscheinlich ist.
Wenn der Benutzer Administrator nicht gelöscht werden kann, was kann man dann tun? Man kann ihn umbenennen!
Empfehlungen aus diesem Punkt:
- verwenden Sie keinesfalls den Benutzernamen im Computernamen
- stellen Sie sicher, dass es auf dem System keinen Benutzer Administrator gibt
- verwenden Sie starke Passwörter
Auf diese Weise beobachte ich, wie mehrere Windows-Server unter meiner Kontrolle bereits seit etwa zwei Jahren Brute-Force-Angriffen ausgesetzt sind, jedoch ohne Erfolg.
Wie ich weiß, dass es erfolglos ist?
Weil auf den obigen Screenshots zu sehen ist, dass es erfolgreiche RDP-Anmeldeprotokolle gibt, die folgende Informationen enthalten:
- Von welcher IP
- Von welchem Computer (Hostname)
- Benutzername
- GeoIP-Informationen
Und ich schaue regelmäßig nach — keine Anomalien festgestellt.
Übrigens, wenn von einer bestimmten IP besonders hartnäckig Brute-Force-Angriffe stattfinden, kann man bestimmte IP-Adressen (oder Subnetze) so 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 BlockÜbrigens hat Elastic neben Winlogbeat auch , das die Dateien und Prozesse im System überwachen kann. Es gibt auch die SIEM (Security Information & Event Management) Anwendung in Kibana. Ich habe beides ausprobiert, aber wirklich nützliche Erkenntnisse habe ich nicht gewonnen – es scheint, dass Auditbeat für Linux-Systeme hilfreicher sein wird, während mir SIEM bisher nichts Verständliches gezeigt hat.
Hier sind einige abschließende Empfehlungen:
- Führen Sie regelmäßige automatische Backups durch.
- Installieren Sie rechtzeitig Sicherheitsupdates.
Bonus: Liste von 50 Benutzern, die häufig für RDP-Anmeldeversuche 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
OWNER
410
Quelle: habr.com
