Remote Desktop via RDP: Best Practices (4/4)

Ob man RDP überhaupt sicher betreiben kann, ist eine akademische Frage. Klar ist, dass man die damit verbundenen Risiken deutlich reduzieren kann – und sollte.

Lesezeit: 3 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 46 Beitr?ge

(Bild: Shutterstock.com)

Von

Diese Serie zum Remote Desktop Protocol (RDP) soll vor allem Admins für die damit verbundenen Gefahren sensibilisieren und ihnen helfen, sich davor zu schützen. Der vorige Teil demonstrierte, wie man RDP auf Sicherheitsprobleme testet. Im letzten Teil geht es darum, die mit dem Einsatz von RDP verbunden Gefahren so gering wie m?glich zu halten.

Weitere Folgen der Serie zum Remote Desktop Protocol

Das folgende gibt eine kompakte übersicht über empfehlenswerte Ma?nahmen zur Absicherung des Betriebs von RDP. Ich bitte um Nachsicht, dass ich nicht en Detail beschreibe, wie man diese im Einzelfall dann konkret umsetzt. Das h?ngt im Zweifelsfall sehr stark von den jeweiligen Voraussetzungen ab und würde den Rahmen dieser RDP-Serie sprengen.

Die wichtigste Schutzma?nahme ist es, RDP erst gar nicht nach au?en zu exponieren, sondern lediglich im lokalen Netz einzusetzen. Wer von au?en ran muss, bekommt eine VPN-Verbindung ins LAN. Das verhindert viele der in den voran gegangenen Folgen geschilderten Angriffe (wenn auch l?ngst nicht alle). Wer eine solche Policy intern durchsetzen konnte, sollte sie nicht leichtfertig aufgeben.

Hintergrund dieser Empfehlung ist die Tatsache, dass es sehr leicht ist, RDP unsicher zu betreiben; ein sicherer Betrieb ist jedoch schwer und keineswegs trivial. Und selbst wenn man alles tut, einen RDP-Zugang bestm?glich abzusichern, bleiben Risiken wie ein Downgrade-Angriff auf den Client und m?gliche Denial-of-Service-Attacken – von bisher nicht bekannten Sicherheitslücken im teilweise steinalten Code ganz zu schweigen.

Doch in der Realit?t gibt es oftmals Situationen, in denen man letztlich doch gezwungen ist, RDP-Zugriff aus dem Internet zu erm?glichen. Die n?chstbeste Option ist dann ein zentrales Gateway. Damit kann man das Risiko auf ein System konzentrieren und dieses zumindest optimal absichern. Microsoft bietet dazu MS Remote Desktop Services (RDS), das sich jedoch eher an gr??ere Installationen mit dominanter Microsoft-Infrastruktur richtet.

Guacamole setzt auf HTML5 und fungiert als Gateway für RDP, VNC und SSH im Browser,

Eine m?gliche Alternative insbesondere für kleinere Firmen ist das auf HTML5 aufsetzende Open-Source-Projekt Apache Guacamole, das auch gleich VNC und SSH unterstützt (Anm des Red.: ich habe damit bislang keine Erfahrung. Wer damit konkrete Praxiserfahrungen hat, kann sich gerne mal bei mir melden, um diese zu teilen).

Egal ob direktes RDP oder via Gateway sollte man den Zugang m?glichst stark beschr?nken. Also wo sinnvoll m?glich etwa auf einer Firewall die zugriffsberechtigten IP-Adressen reglementieren. Au?erdem sollte man die Zahl der Benutzer mit RDP-Zugang so gering wie m?glich halten. So sind etwa in vielen Installationen die lokalen Administratoren in der Gruppe der RDP Users, ben?tigt diesen Zugriff aber gar nicht (schneller Check: net localgroup Remotedesktopbenutzer).

Der Standard-Tipp den RDP-Zugang etwa durch Port Forwarding auf einer vorgelagerten Firewall auf einen ungew?hnlichen TCP-Port zu verlegen, hilft nicht mehr sonderlich viel. Berichten von Admins zufolge verzeichnen solche RDP-Zug?nge bereits kurze Zeit nach der Freigabe systematische Login-Versuche von unbekannten IP-Adressen. RDP-Dienste auf exotischen Ports werden also systematisch gesucht und auch gefunden.

Für alle Remotedesktopbenutzer sollte man eine m?glichst starke Authentifizierung verlangen. Lange und komplexe Passw?rter sind da bestenfalls die zweite Wahl. Eigentlich will man da eine Multi-Faktor-Authentifizierung, die auch den Missbrauch von erschnüffelten Credentials verhindern kann. Bew?hrt haben sich da im praktischen Einsatz Smartcards. Das gilt auch beim Einsatz im LAN/VPN; noch mehr aber, wenn man RDP ins Internet freigeben muss.

Darüber hinaus will man eigentlich die Zahl der fehlgeschlagenen Login-Versuche beschr?nken. Bei einem ins Internet exponierten RDP-Zugang dürfte dies jedoch die Nutzbarkeit stark beeintr?chtigen, weil die bald vorbeikommenden RDP-Brute-Forcer das Limit schnell erreichen und somit den Account dauerhaft blockieren (Denial of Service).

Bei den einzelnen RDP-Systemen sollte man systematisch testen, dass sie nur über vorgeschaltete Network Level Authentication (NLA) zu erreichen sind und für diese Authentifizierung auch CredSSP einfordern. Alles andere bietet unn?tige Angriffsfl?che. Am besten stellt man dies durch entsprechende Gruppenrichtlinien firmenweit sicher (Computer\Policies\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security). Ein System das noch Standard RDP Security erlaubt, ist eine nicht entschuldbare Fahrl?ssigkeit.

Solche Warnungen zur Vertrauenswürdigkeit der Gegenstelle darf man nicht unbeachtet wegklicken.

Ein problematisches Thema sind die TLS-Zertifikate, die in den allermeisten F?llen nur selbstsigniert sind und h?ufige Zertifikatswarnungen erzeugen. Die beste Abhilfe ist es, das mit einer eigenen Firmen-PKI zu ?ndern – also etwa Microsofts Active Directory Certificate Services zu nutzen. Wenn das etwa in kleinen Betrieben nicht umsetzbar ist, hilft folgender Trick zumindest ein wenig:

Bei der ersten Zertifikatswarnung stellt man explizit sicher, dass man mit dem richtigen System spricht (etwa durch den Fingerabdruck des Schlüssels). Dann setzt man das H?kchen bei "Nicht erneut nach Verbindungen mit diesem Computer fragen". Damit speichert das System den Fingerabdruck dieses RDP-Servers und wird für diese Kombination von System-Name und Zertifikat keine Warnungen mehr pr?sentieren. Das muss man allerdings für jeden konkret genutzten Namen (DNS, Domain, IP) und auf jedem Client-System wiederholen. Und wenn sich das Zertifikat ?ndert, geht es von vorne los.

Bei Warnungen zur Vertrauenswürdigkeit der Gegenstelle sollte man keinesfalls unbedacht auf "Verbinden" klicken und alle Nutzer von RDP sollten da entsprechend geschult werden. Denn sonst landen unter Umst?nden die Zugangsdaten bei einem Angreifer, der sich in die Position eines Man in the Middle gebracht hat. War das dann etwa der Dom?nen Administrator ist der Super-GAU perfekt und das komplette Windows-Netz ist kompromittiert. Sie werden dann in vielen F?llen recht bald eine deftige L?segeldforderung bekommen.

Wer seinen RDP-Server so ins Netz stellt, handelt grob fahrl?ssig.

(Bild:?Screenshot)

Abschlie?end sei noch etwas erw?hnt, was eigentlich eine Selbstverst?ndlichkeit sein sollte: Benutzen Sie RDP nur auf Systemen, die erstens vom Hersteller noch unterstützt werden und die zweitens immer m?glichst zeitnah mit Sicherheits-Updates versorgt werden. Man mag es nicht glauben – aber auch hier in Deutschland finden sich erschreckend viele Systeme, die zwar aus dem Internet via RDP erreichbar sind, aber nicht einmal diese grundlegenden Sicherheitsanforderungen erfüllen. Um es ganz klar zu sagen: Das ist grob fahrl?ssig und nicht mehr zu entschuldigen.

Falls Ihnen das ein oder andere in diesem Artikel nicht ganz klar wurde, sind die Chancen gut, dass es in einem der vorhergehenden Teile erkl?rt wurde. Darüber hinaus bereitet der Autor der Serie, Jürgen Schmidt, den kompletten Inhalt auch gezielt für Administratoren in einem heise-Security-Webinar auf: Homeoffice und Administration via Remote Desktop - das sollten Admins wissen.

(ju)

汤姆叔叔影院