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.
(Bild: Shutterstock.com)
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.
Der Autor Jürgen Schmidt bereitet den Inhalt der kompletten Serie auch gezielt für Administratoren in einem heise-Security-Webinar auf: Homeoffice und Administration via Remote Desktop - das sollten Admins wissen
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.
Nicht ohne VPN
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.
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.
Zweifaktor-Authentifizierung
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.
Zertifikate
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.
(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.
Das RDP-Webinar
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)
