Windows-RDS mit dem Remote Desktop Gateway absichern

Die meisten Windows-Server-Administratoren haben sicherlich an irgendeinem Punkt bereits mit den Remote Desktop Services (RDS) gearbeitet. Der Grund liegt auf der Hand: Windows-RDS ist eine kostengünstige Lösung, um für User Anwendungen und Desktops remote bereitzustellen. Darüber hinaus ist sie einfach zu realisieren: Jeder Windows-Server lässt sich mit nur wenigen Mausklicks in einen RDS-Server verwandeln.

Obwohl der Remote Desktop Session Host (RDSH) den Kern von RDS bildet, ist das Remote Desktop Gateway (RDG) ein ebenso wichtiger Rollendienst, da er sichere Benutzersitzungen zwischen nicht vertrauenswürdigen Netzwerken und/oder dem Internet ermöglicht.

Wenn also das RDG solch ein praktisches Tool ist, um Windows-RDS-Anwendungen ins Internet zu bringen, warum nutzen ihn nicht mehr IT-Abteilungen? Eine Hürde liegt im fehlenden Verständnis der unterschiedlichen Möglichkeiten, mit denen sich ein RDG in eine demilitarisierte Zone (DMZ) und/oder ein internes LAN integrieren lässt. Erschwert wird das Ganze noch durch eine Reihe von falschen Vorstellungen, aufgrund derer das RDG weniger sicher erscheint, als es in Wahrheit ist.

Der Unterschied liegt im Netzwerkdesign.

Es gibt vier deutlich verschiedene Designs, um das RDG in eine bestehende DMZ zu integrieren. Eines davon stellt die derzeit in der Branche favorisierte Best Practice dar. Bei jedem dieser Designs können Sie davon ausgehen, dass der RDG-Rollendienst auf einem eigenen Server installiert wird, der ausschließlich für RDG-Dienste verwendet wird. 

Und obwohl der Begriff „Internet" gebraucht wird, um das Netz außerhalb des LAN zu beschreiben, kann er für jedes externe und nicht vertrauenswürdige Netzwerk stehen (zum Beispiel ein Extranet).

Design Nr. 1: Keine DMZ, RDG im LAN

Das häufigste RDG-Design ist gleichzeitig das einfachste. Darin wird keine DMZ benötigt, weil sich das RDG innerhalb des internen LAN befindet und vollständige Netzwerkkonnektivität zu seinem RDSH besitzt. In diesem Design wird der TCP-Port 443 der Firewall zwischen dem Internet und dem RDG geöffnet. Außerdem werden die DNS-Records korrekt aktualisiert, sodass der Fully Qualified Domain Name (FQDN) des RDG entweder über das LAN oder das Internet aufgelöst werden kann.

Dieses Design ist zwar recht einfach, bietet dafür aber nicht die Art von Netzwerktrennung und Schutz, die die meisten Sicherheitsrichtlinien vorschreiben. So verlangt der Großteil dieser Richtlinien, dass der Netzwerk-Traffic vom Internet über einen DMZ-Proxy-Server geleitet wird, bevor er das interne LAN erreicht. Dieses Design erfüllt diese Anforderung nicht.

Design Nr. 2: RDG in der DMZ, kein Abbilden des internen Active Directory

Um der für die meisten Unternehmensnetzwerke obligatorischen Proxy-Anforderung nachzukommen, verlegt das zweite Design das RDG in eine DMZ. Von seiner dortigen Position aus muss zuerst TCP-Port 443 zwischen dem Internet und dem RDG geöffnet werden, anschließend TCP-Port 3389 zwischen dem RDG und dem internen LAN.

Zwar trennt dieses Design das RDG vom internen LAN, allerdings wird auf diese Weise das interne Active Directory nicht nach außen abgebildet. Da zwischen der DMZ und dem internen LAN nur der TCP-Port 3389 für das Remote Desktop Protocol geöffnet ist, muss der Server, auf dem das RDG läuft, im Arbeitsgruppenmodus betrieben werden.

Beachten Sie, dass diese Verwendung des Arbeitsgruppenmodus nur ab Windows Server 2008 R2 möglich ist. Ältere Betriebssystemversionen setzten voraus, dass das RDG ein in die Domain eingebundener Server war. Bedenken Sie auch, dass bei der Nutzung dieses Designs Anwender, die eine Verbindung aufbauen wollen, zwei unterschiedliche Benutzernamen und Passwörter benötigen. Der erste Account wird als lokaler User auf dem RDG verwaltet, während der zweite zur internen Domain-Anmeldung dient.

Design Nr. 3: RDG in der DMZ, Abbilden des internen Active Directory

Dass User bei zwei verschiedenen Benutzernamen und Passwörtern den Überblick behalten, ist meist zu viel verlangt. Ebenso groß ist der administrative Aufwand, sie auf dem RDG-Server zu verwalten. Aus diesem Grund ist in den meisten Umgebungen ein Single Sign-on (SSO) erwünscht, und zwar bei der gesamten Verbindung vom Remote-Gerät, über das RDG bis hin zur RDSH-Anwendung.

Eine Methode, Single Sign-on zu erreichen, führt über einen in die Domain eingebundenen RDG-Server. Problematisch hierbei ist der große Bereich an Netzwerkports, der erforderlich ist, um eine Windows-Domain in eine DMZ zu erweitern. Die schiere Anzahl der notwendigen Ports ist oft der begrenzende Faktor, um Design Nr. 3 zu implementieren. Der RDS-Team-Blog dokumentiert diese Ports.

Der Prozess, um dieses Design umzusetzen, ist äußerst komplex. Damit der Artikel nicht zur Verwirrung beiträgt, nennen wir an dieser Stelle nur kurz drei High-Level-Optionen, mit denen sich Design Nr. 3 implementieren lässt:

Die erste Option öffnet genügend Netzwerkports zwischen dem RDG und einem internen Domain-Controller, damit Erstgenannter seine Mitgliedschaft in der Domain erhält.

Um diese Konfiguration weiter zu sichern, platziert die zweite Option stattdessen einen Read-Only Domain-Controller (RODC) in der DMZ. Der RODC wird über eine ausreichende Anzahl an Netzwerkports mit einem internen DC verbunden, um die Domain-Mitgliedschaft zu erhalten, und der RDG verwendet den RODC für die Authentifizierung.

Die dritte Option versucht, eine weitere Trennung vorzunehmen. Dazu nutzt sie eine separate Domain und einen Domain-Controller in der DMZ, der in eine Gesamtstruktur-Vertrauensstellung mit der internen Domain eingebunden ist. Dann werden zwischen dem DMZ-DC und einem internen DC genug Ports geöffnet, um die Authentifizierung durch diese Gesamtstruktur-Vertrauensstellung zu unterstützen.

Option Nr. 4: Reverse Proxy in der DMZ, RDG im LAN

Falls Option Nr. 3 wie zusätzlicher Aufwand erscheint, stimmt das. Außerdem öffnet sie Firewall-Ports, die laut Empfehlung der meisten Sicherheitsexperten lieber geschlossen bleiben sollten. Aus diesem Grund gilt Option Nr. 4 – für diejenigen, die es sich leisten können – in der Branche momentan als Best Practice.

Option Nr. 4 fügt dem in Option Nr. 1 vorgestellten Netzwerkdesign eine weitere Komponente hinzu. Diese zusätzliche Komponente sieht vor, einen Reverse-Proxy-Server in der DMZ unterzubringen, wobei der Netzwerk-Traffic über den Proxy geleitet wird, bevor er zum RDG innerhalb des LAN geroutet wird. Der Reverse-Proxy-Server kann Microsofts Forefront Threat Management Gateway oder Unified Access Gateway sein oder eine der Reverse-Proxy-Lösungen von Drittherstellern, die die RDG-Integration unterstützen.

Als Reverse Proxy kann jede dieser Lösungen als SSL-Bridging-Gerät fungieren, um HTTPS-Anfragen zu empfangen und zwischen dem Internet und dem internen LAN weiterzuleiten. Netzwerkpakete landen zunächst beim Reverse Proxy, werden auf schädlichen Code untersucht und neu zusammengesetzt, bevor sie an interne Server gesendet werden. Dieser Vorgang ermöglicht es einem in die Domain eingebundenen RDG im internen LAN, mithilfe von internen Domain-Anmeldeinformationen Benutzersitzungen zu authentifizieren und an weitere Proxies weiterzuleiten. Damit erreicht man Single Sign-on.