{"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 sehr unsicher ist, den RDP (Remote Desktop Protocol) Port im Internet offen zu halten. Der Zugriff auf RDP sollte entweder \u00fcber VPN oder nur von bestimmten \"wei\u00dfen\" IP-Adressen gew\u00e4hrt werden.<\/p>\n

<\/p>\n

Ich verwalte mehrere Windows-Server f\u00fcr kleine Unternehmen, in denen ich die Aufgabe bekommen habe, den Remote-Zugang zu Windows-Servern f\u00fcr Buchhalter zu gew\u00e4hrleisten. Ein moderner Trend \u2013 Arbeiten von zu Hause aus. Ich habe schnell gemerkt, dass es unangemessen ist, den Buchhaltern mit einem 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 habe ich den einfachsten Weg gew\u00e4hlt \u2013 ich habe den RDP-Port nach au\u00dfen weitergeleitet. Jetzt m\u00fcssen die Buchhalter 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 (sowohl positive als auch weniger positive) und Empfehlungen.<\/p>\n

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

Risiken<\/h3>\n

<\/p>\n

Was riskieren Sie, wenn Sie den RDP-Port \u00f6ffnen?<\/p>\n

<\/p>\n

1) Unautorisierter Zugriff auf sensible Daten<\/b>
\nWenn jemand das Passwort f\u00fcr RDP knackt, kann er auf Daten zugreifen, die Sie privat halten m\u00f6chten: Kontost\u00e4nde, Salden, Kundendaten, ...<\/p>\n

<\/p>\n

2) Datenverlust<\/b>
\nZum Beispiel infolge eines Ransomware-Angriffs.
\nOder durch gezielte Ma\u00dfnahmen eines Angreifers.<\/p>\n

<\/p>\n

3) Verlust der Arbeitsstation<\/b>
\nMitarbeiter m\u00fcssen arbeiten, w\u00e4hrend das System kompromittiert ist; es muss neu installiert, wiederhergestellt oder konfiguriert werden.<\/p>\n

<\/p>\n

4) Kompromittierung des lokalen Netzwerks<\/b>
\nWenn ein Angreifer Zugriff auf einen Windows-Computer erh\u00e4lt, kann er bereits \u00fcber diesen Computer auf Systeme zugreifen, die von au\u00dfen, aus dem Internet, nicht erreichbar sind. Zum Beispiel auf Datei-Shares, Netzwerkkopierer usw.<\/p>\n

\nIch hatte einen Fall, bei dem ein Windows Server von Ransomware befallen wurde<\/b><\/p>\n

und diese Ransomware zuerst die meisten Dateien auf Laufwerk C: verschl\u00fcsselte, bevor sie begann, Dateien auf dem NAS \u00fcber das Netzwerk zu verschl\u00fcsseln. Da das NAS von Synology war und mit Snapshots konfiguriert war, konnte ich das 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 allein bietet keinen Schutz, hilft jedoch, die erforderlichen Ma\u00dfnahmen zu bestimmen.<\/p>\n

<\/p>\n

Hier sind einige Beobachtungen:
\na) RDP wird durch Brute-Force-Angriffe angegriffen.<\/b>
\nAuf einem meiner Server habe ich RDP nicht auf dem Standardport 3389, sondern auf 443 eingestellt \u2013 um mich angeblich als HTTPS zu tarnen. Es ist wahrscheinlich sinnvoll, den Standardport zu \u00e4ndern, aber der Nutzen ist gering. Hier sind die Statistiken von diesem Server:<\/p>\n

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

Es ist zu erkennen, dass es in einer Woche fast 400.000 fehlgeschlagene Versuche gab, sich \u00fcber RDP einzuloggen.
\nEs gab Versuche von 55.001 IP-Adressen (einige IP-Adressen wurden bereits von mir blockiert).<\/p>\n

<\/p>\n

Hier liegt der Schluss nahe, dass man fail2ban einsetzen sollte, aber <\/p>\n

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

Es gibt ein paar aufgegebene Projekte auf GitHub, die anscheinend das 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, die ich jedoch nicht betrachtet habe.<\/p>\n

<\/p>\n

Wenn Sie ein Open-Source-Tool f\u00fcr diesen Zweck kennen, teilen Sie es bitte in den Kommentaren.<\/p>\n

<\/p>\n

Update<\/strong>: In den Kommentaren wurde vorgeschlagen, dass Port 443 eine ungl\u00fcckliche Wahl ist, und es besser ist, hohe Ports (32000+) zu w\u00e4hlen, weil 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 vorgeschlagen, dass es ein solches Tool gibt:
\nhttps:\/\/github.com\/digitalruby\/ipban<\/a><\/noindex><\/p>\n

<\/p>\n

b) Es gibt bestimmte Benutzernamen, die von Angreifern bevorzugt werden.<\/b>
\nEs ist offensichtlich, dass die Versuche aus einem W\u00f6rterbuch mit verschiedenen Namen stammen.
\nAber was mir aufgefallen ist: Eine erhebliche Anzahl der Versuche verwendet den Servernamen als Anmeldenamen. Empfehlung: Verwenden Sie nicht denselben Namen f\u00fcr 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.<\/p>\n

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

Wenn Sie also einen Computer mit dem Namen DESKTOP-MARIA haben, werden wahrscheinlich viele Versuche unternommen, sich als Benutzer MARIA anzumelden.<\/p>\n

<\/p>\n

Dar\u00fcber hinaus habe ich aus den Logs bemerkt, dass die meisten Zugriffsversuche mit dem Namen \"administrator\" erfolgen. Und das ist nicht \u00fcberraschend, da dieser Benutzer in vielen Windows-Versionen existiert. Dar\u00fcber hinaus kann er nicht gel\u00f6scht werden. Das vereinfacht die Aufgabe f\u00fcr Angreifer: Statt einen Benutzernamen und ein Passwort zu erraten, muss nur das Passwort gefunden werden.
\n\u00dcbrigens 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.
\nWenn der Benutzer Administrator nicht gel\u00f6scht werden kann, was kann man dann tun? Man kann ihn umbenennen!<\/p>\n

<\/p>\n

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

<\/p>\n