{"id":41229,"date":"2020-02-06T20:43:00","date_gmt":"2020-02-06T17:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/opasno-li-derzhat-otkrytym-rdp-v-internete"},"modified":"2020-02-06T20:43:00","modified_gmt":"2020-02-06T17:43:00","slug":"opasno-li-derzhat-otkrytym-rdp-v-internete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/opasno-li-derzhat-otkrytym-rdp-v-internete","title":{"rendered":"Ist es gef\u00e4hrlich, RDP im Internet offen zu halten?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Es wird oft die Meinung ge\u00e4u\u00dfert, dass es gef\u00e4hrlich ist, den RDP (Remote Desktop Protocol) Port im Internet offen zu halten, und dass man das nicht tun sollte. Stattdessen sollte der Zugang zu RDP entweder \u00fcber ein VPN erfolgen oder nur von bestimmten \"wei\u00dfen\" IP-Adressen aus gew\u00e4hrt werden.<\/p>\n

<\/p>\n

Ich verwalte mehrere Windows Server f\u00fcr kleine Unternehmen, die mich beauftragt haben, den Remote-Zugriff auf den Windows Server f\u00fcr Buchhalter zu erm\u00f6glichen. Das ist der moderne Trend \u2013 Arbeiten von zu Hause. Schnell wurde mir klar, dass es undankbar ist, die Buchhalter mit VPN zu qu\u00e4len, und dass es nicht m\u00f6glich ist, alle IPs f\u00fcr die Whitelist zu sammeln, da die IP-Adressen der Leute dynamisch sind.<\/p>\n

<\/p>\n

Deshalb bin ich den einfachsten Weg gegangen \u2013 ich habe den RDP Port nach au\u00dfen weitergeleitet. Jetzt m\u00fcssen die Buchhalter nur RDP starten und den Hostnamen (einschlie\u00dflich Port), den Benutzernamen und das Passwort eingeben.<\/p>\n

<\/p>\n

In diesem Artikel teile ich meine Erfahrungen (positive und weniger positive) sowie Empfehlungen.<\/p>\n

<\/a><\/noindex><\/p>\n

Risiken<\/h3>\n

<\/p>\n

Welche Risiken haben Sie, wenn Sie den RDP-Port \u00f6ffnen?<\/p>\n

<\/p>\n

1) Unbefugter Zugang zu sensiblen Daten<\/b>
\nWenn jemand das Passwort f\u00fcr RDP err\u00e4t, kann er auf Daten zugreifen, die Sie privat halten m\u00f6chten: Kontost\u00e4nde, Salden, Kundendaten, \u2026<\/p>\n

<\/p>\n

2) Datenverlust<\/b>
\nZum Beispiel durch die Arbeit eines Ransomware-Virus.
\nOder durch gezielte Handlungen eines Angreifers.<\/p>\n

<\/p>\n

3) Verlust der Arbeitsstation<\/b>
\nDie Mitarbeiter m\u00fcssen arbeiten, aber das System ist kompromittiert, es muss neu installiert \/ wiederhergestellt \/ konfiguriert werden.<\/p>\n

<\/p>\n

4) Kompromittierung des lokalen Netzwerks<\/b>
\nWenn ein Angreifer Zugriff auf einen Windows-Computer erh\u00e4lt, hat er von diesem Computer aus Zugang zu Systemen, die von au\u00dfen, aus dem Internet, nicht zug\u00e4nglich sind. Zum Beispiel zu Datei-Servern, Netzwerkkopierern und so weiter.<\/p>\n

\nIch hatte einen Fall, in dem ein Windows Server Ransomware erwischt hat<\/b><\/p>\n

und diese Ransomware zuerst die meisten Dateien auf dem Laufwerk C: verschl\u00fcsselte und dann begann, Dateien auf dem NAS \u00fcber das Netzwerk zu verschl\u00fcsseln. Da die NAS von Synology war und mit Snapshots eingerichtet war, konnte ich die NAS in 5 Minuten wiederherstellen, w\u00e4hrend ich den Windows Server von Grund auf neu installieren musste.<\/p>\n

<\/p>\n

Beobachtungen und Empfehlungen<\/h3>\n

<\/p>\n

Ich \u00fcberwache Windows Server mit Hilfe von Winlogbeat<\/a><\/noindex>, die Protokolle an ElasticSearch senden. In Kibana gibt es mehrere Visualisierungen, und ich habe mir noch ein benutzerdefiniertes Dashboard eingerichtet.
\nDie \u00dcberwachung selbst bietet keinen Schutz, hilft aber, die notwendigen Ma\u00dfnahmen zu bestimmen.<\/p>\n

<\/p>\n

Hier sind einige Beobachtungen:
\na) RDP wird mit Brute-Force-Attacken angegriffen.<\/b>
\nAuf 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 \u00e4ndern, aber viel bringt das nicht. Hier ist die Statistik von diesem Server:<\/p>\n

\n\"Ist<\/p>\n

Es ist zu sehen, dass es in der Woche fast 400.000 erfolglose Versuche gab, sich \u00fcber RDP einzuloggen.
\nEs ist ersichtlich, dass die Versuche von 55.001 IP-Adressen ausgegangen sind (einige IP-Adressen waren bereits von mir blockiert).<\/p>\n

<\/p>\n

Hier dr\u00e4ngt sich der Schluss auf, dass man fail2ban installieren sollte, aber <\/p>\n

\nF\u00fcr Windows gibt es ein solches Tool nicht.<\/b><\/p>\n

Es gibt ein paar verwaiste Projekte auf GitHub, die das anscheinend tun, aber ich habe sie nicht ausprobiert:
\nhttps:\/\/github.com\/glasnt\/wail2ban<\/a><\/noindex>
\nhttps:\/\/github.com\/EvanAnderson\/ts_block<\/a><\/noindex><\/p>\n

<\/p>\n

Es gibt auch kostenpflichtige Tools, aber ich habe sie nicht in Betracht gezogen.<\/p>\n

<\/p>\n

Wenn Sie ein offenes Tool f\u00fcr diesen Zweck wissen, teilen Sie es bitte in den Kommentaren.<\/p>\n

<\/p>\n

Update<\/strong>: In den Kommentaren wurde angemerkt, dass der Port 443 eine ungl\u00fcckliche Wahl ist und man besser hohe Ports (32000+) w\u00e4hlen sollte, da 443 h\u00e4ufiger gescannt wird, und es kein Problem ist, RDP auf diesem Port zu erkennen.<\/p>\n

<\/p>\n

Update:<\/strong> In den Kommentaren wurde darauf hingewiesen, dass es ein solches Tool gibt:
\nhttps:\/\/github.com\/digitalruby\/ipban<\/a><\/noindex><\/p>\n

<\/p>\n

b) Es gibt bestimmte Benutzernamen, die Angreifer bevorzugen<\/b>
\nEs ist ersichtlich, dass ein W\u00f6rterbuch mit verschiedenen Namen durchprobiert wird.
\nAber was mir aufgefallen ist: Eine erhebliche Anzahl der Versuche nutzt den Namen des Servers als Login. Empfehlung: Verwenden Sie nicht denselben Namen f\u00fcr den Computer und f\u00fcr den Benutzer. Manchmal scheinen Angreifer den Servernamen irgendwie zu parsen: Zum Beispiel gab es f\u00fcr ein System mit dem Namen DESKTOP-DFTHD7C die meisten Versuche mit dem Namen DFTHD7C:<\/p>\n

\n\"Ist<\/p>\n

Entsprechend, wenn Sie einen Computer mit dem Namen DESKTOP-MARIA haben, werden wahrscheinlich Versuche unternommen, sich als Benutzer MARIA einzuloggen.<\/p>\n

<\/p>\n

Au\u00dferdem habe ich aus den Logs festgestellt: In den meisten Systemen sind die meisten Zugangsversuche mit dem Namen \"administrator\". Und das ist kein Zufall, denn in vielen Versionen von Windows existiert dieser Benutzer. Dar\u00fcber hinaus kann er nicht gel\u00f6scht werden. Das erleichtert es Angreifern: Statt Benutzernamen und Passwort zu erraten, muss nur das Passwort erraten werden.
\n\u00dcbrigens 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.
\nWenn man den Benutzer Administrator nicht l\u00f6schen kann, was kann man dann tun? Man kann ihn umbenennen!<\/p>\n

<\/p>\n

Empfehlungen aus diesem Punkt: <\/p>\n

<\/p>\n