Das RDP-Protokoll ist seit Jahren als notorisch unsicher verschrien, und in vielen Szenarien ist dieser Vorwurf nach wie vor gerechtfertigt. Dennoch bildet RDP in vielen Organisationen auch heute noch die Grundlage für die Verwaltung von Servern und für den Fernzugriff auf Unternehmensdesktops und -anwendungen. Die Verbreitung von RDP in der Windows-Welt ist so groß, dass jede Organisation, die Windows-Server betreibt, gut daran tut, eine Sicherheitsstrategie für RDP zu implementieren und entsprechende Maßnahmen umzusetzen.

Dabei muss die Absicherung auf zwei Ebenen stattfinden: Zum einen ist natürlich die Absicherung des Zugriffs auf wichtige Systeme mittels RDP in den meisten Umgebungen dringend notwendig. Dies betrifft sowohl den unberechtigten Zugriff als auch das Abhören der sensitiven Kommunikation zwischen Server und Client. Zum anderen ist es sehr wichtig, die für den Aufbau von RDP-Sitzungen verwendeten Anmeldedaten gegen Missbrauch zu schützen.

Wichtig: Wer darf was?
Wenn Sie die auf dem RDP-Protokoll basierenden "Remote Desktop Services" für die zentrale Bereitstellung Ihrer Anwendungen nutzen, so liegt es nahe, den Zugriff auf diese Dienste aus sämtlichen erforderlichen Netzwerksegmenten zu erlauben. In letzter Konsequenz werden das auch fremde Netze (beispielsweise mit Standleitungen verbundene Partnerunternehmen), VPN-Zugänge oder sogar das weltweite Internet sein. Hier sollten Sie eine Unterscheidung zwischen "eher sicheren" und "potenziell feindlichen" Netzen vornehmen.

Ortsfeste Clients innerhalb Ihrer eigenen Infrastruktur oder andere RDS-Ressourcen im gleichen Rechenzentrum können Sie in der Regel für den direkten RDP-Zugriff auf produktive Anwendungen freigeben. Internet- und idealerweise auch VPN-Clients benötigen zwingend Schutz durch ein Remote Desktop Gateway oder aber ein äquivalentes Dritthersteller-Produkt.

Sie sollten sich dabei nicht auf die Konfiguration Ihrer RDS-Bereitstellung verlassen, sondern den Zugriff auf RDP-Port 3389 (TCP und UDP) aus VPN-Netzen und anderen als unsicher angesehenen Segmenten in der Firewall sperren. Neben der verstärkten Sicherheit gibt Ihnen dies auch die Möglichkeit, in Ihrer Bereitstellung den Zugriffsweg "Remotedesktop gateway für lokale Adressen umgehen" zu verwenden. Die Bestimmung der "lokalen Adressen" beruht in diesem Fall nämlich nicht etwa auf der Kenntnis Ihrer Netzwerktopologie, sondern es wird als Erstes versucht, die Verbindung ohne das Gateway aufzubauen. Gelingt dies und ist der Zugang mit der oben zitierten Option konfiguriert, wird das Gateway komplett umgangen.

Server gesondert absichern
Anders ist es um den RDP-Zugriff auf Infrastrukturserver und besonders sensible Anwendungen bestellt. Hier müssen Sie sehr genau regeln, wer über RDP Verbindungen zu Servern aufbauen darf. Es ist aus Sicherheitssicht ein sehr guter Ansatz, zwischen Client- und Servernetzen ein Remote Desktop Gateway zu installieren und alle Verbindungen durch dieses zu leiten. Auf diese Weise können Sie beispielsweise die Vorabauthentifizierung am Gateway mit dem normalen Benutzerkonto des zugreifenden Administrators vornehmen und erst für die Authentifizierung gegenüber der gewünschten Zielressource das Admin-Konto des entsprechenden Tiers verwenden. Auch Multifaktor-Authentifizierung für den Serverzugriff können Sie am Remote Desktop Gateway umsetzen, basiert seine Funktionalität doch auf dem Microsoft Network Policy Server.

Wenn Sie eine solche "Sicherheitsschleuse" auf dem Weg zu Ihren Servernetzen planen, müssen Sie auch an die Möglichkeit denken, RDP-Verbindungen zwischen den Servern aufzubauen. Zwischen Servern, die einem Verbund (beispielsweise einem Cluster oder einer SQL-AG) angehören, kann dies zulässig und sogar gewünscht sein. Beliebige RDP-Verbindungen innerhalb der Servernetze können hingegen nicht im Sinne der Sicherheit Ihrer Umgebung sein. Nutzen Sie hier die Windows-Firewall, die Sie mittels Gruppenrichtlinien verbindlich konfigurieren sollten, um nur die wirklich gewünschten Verbindungen zuzulassen – im Extremfall nur die von den Adressen Ihrer Remotedesktop-Gateways.

Beachten Sie: Verbindungen vom Client zum RD-Gateway sind mit TLS und folglich mit einem Zertifikat abgesichert. Diesem muss der Client ohne weitere Rückfragen vertrauen, denn unterstützte RDP-Clients sehen keine Möglichkeit vor, das fehlende Vertrauen in das Zertifikat zu ignorieren oder das Vertrauen erst beim Verbindungsaufbau zu erklären.

Eine weniger wirkungsvolle Maßnahme als die rigorose Einschränkung der Kommunikationswege ist das bei einigen Administratoren beliebte "Verbiegen" des RDP-Netzwerkports. Diese Art von "security by obscurity" hindert moderne Vulnerability-Scanner nicht daran, zu erkennen, dass der angesprochene Server bereit ist, RDP-Verbindungen zu akzeptieren. Wenn Ihre IT-Managementprozesse robust genug sind, diese Einstellung netzwerkweit zu verwalten, können Sie abweichende RDP-Ports als eine zusätzliche Verschleierungsebene nutzen, um dem potenziellen Angreifer das Ausbreiten über RDP zu erschweren. Allerdings dürfte er auch ohne einen Scanner in der Lage sein, den geänderten Port zu ermitteln: in der Registry eines bereits angegriffenen Systems, in den Gruppenrichtlinien, mit denen Sie diese Registry-Einstellung erzwingen, sowie in den Gruppenrichtlinien für die Konfiguration der Windows-Firewall.

Eingeschränkte Benutzerauswahl
Die Einschränkung der Kommunikationsbeziehungen durch Netzwerksegmentierung, Firewalls und Remotedesktop-Gateways sind zweifelsohne die wirkungsvollste Schutzmaßnahme, um die RDP-Implementierung in Ihrer Umgebung verbindlich zu regeln. Nichtsdestotrotz sollten Sie ebenso verbindlich regeln, welche Benutzer sich remote an der Maschine anmelden können. Dies geschieht auf zwei Ebenen:

• Durch Systemrechte (Richtlinien "Anmelden über Remotedesktopdienste zulassen" und "Anmelden über Remotedesktopdienste verweigern") können Sie festlegen, welche Benutzer und Gruppen berechtigt sind, eine Remoteverbindung aufzubauen. Standardmäßig sind dies die lokalen Gruppen "Administratoren" und "Remotedesktop-Benutzer".
• Durch Mitgliedschaft in den berechtigten Gruppen (siehe oben). Im Auslieferungszustand sind Domänenadministratoren Mitglied in den lokalen Administratorengruppen. Somit könnte sich ein Domänen-Admin theoretisch an jedem Member-System anmelden und seine Anmeldedaten auf diese Weise unter Umständen dem CredentialKlau aussetzen.

Daher sollten Sie für Ihre Backendsysteme stets eine Richtlinie definieren, die die Berechtigung zur Remoteanmeldung verbindlich und möglichst eng regelt. Sofern in Ihrem Active Directory bereits "administratives Tiering" eingerichtet wurde, dürfen die besonders sensitiven Tier-0-Admins sich ohnehin nicht mehr an Clients und Anwendungsservern interaktiv anmelden, ganz gleich ob per RDP oder direkt an der Konsole. Doch sogar innerhalb eines Tiers ist es eine gute Idee, die Anmeldeberechtigungen zu segmentieren.

ln/Evgenij Smirnov

Im zweiten Teil der Workshopserie beschreiben wir, wie Sie die Möglichkeiten der User limitieren und die RDP-Kommunikation absichern. Im dritten und letzten Teil gehen wir darauf ein, wie Sie Credentials beim RDP-Zugriff schützen.