Möglichkeiten der User limitieren
Ein Thema, das so alt ist wie Terminalserver selbst, sind die "Terminal-Server-Lockdown-Konfigurationen", also Settings, die die Handlungsmöglichkeiten des Benutzers auf dem Terminalserver oder in der VDI-Maschine einschränken. Es finden sich im Internet zahlreiche Bei träge und Anleitungen, die teilweise so weit gehen, den Terminaldesktop in einen "dummen Kiosk" zu verwandeln.

Falls Ihre Organisation ebenfalls die Position vertritt, dass es aus Sicherheitssicht notwendig ist, die Eingabeaufforderung zu sperren, das Startmenü zu leeren oder das Betriebssystemlaufwerk im Explorer auszublenden, können Sie dies auch in den modernen Windows-Versionen mittels Gruppenrichtlinien tun. Bedenken Sie dabei folgende Punkte:

• Wenn Sie für Terminalserver oder VDI die "Loopback-Verarbeitung" für die Gruppenrichtlinien aktiviert haben, wird sich Ihr Lockdown auf alle Nutzer auswirken, die sich an diesem Gerät anmelden – also auch auf die Verwalter der Bereitstellung.
• Deaktivieren Sie eine Funktion, die die Nutzer tatsächlich in ihrer täglichen Arbeit verwenden, werden die Anwender eher nach Wegen suchen, diese Gängelung zu umgehen, statt ein Ticket aufzumachen, damit die Funktion wieder aktiviert wird. Hier ist proaktive Kommunikation Ihrerseits gefragt.
• Der einzige wirkliche Schutz vor unerwünschten Änderungen am System sind die Benutzerrechte und der tatsächliche Zugriff auf die ausführbaren Dateien beziehungsweise die Berechtigung, diese zu starten. Durch das Ausblenden des Systemlaufwerks hindern Sie einen User nicht wirklich daran, Programme zu starten – durch NTFS-Leserechte oder AppLocker-Richtlinien dagegen schon.

RDP-Kommunikation absichern
Das RDP-Protokoll wurde entwickelt, um sensitive Informationen auszutauschen – vom Client zum Server werden Tastaturund Mauseingaben übertragen, vom Server zum Client die Ausgaben der aufgerufenen Anwendungen. Es überrascht daher wenig, dass sichere Kommunikation von Anfang an Bestandteil der Protokollspezifikation war. Leider hinkte die Entwicklung der verwendeten Verschlüsselungstechniken der allgemeinen Bedrohungslage hinterher, sodass die ursprüngliche RDPVerschlüsselung sowohl Man-In-The-Middle-Attacken als auch das Abhören von Informationen zuließ.

Mit Server 2008 erhielt RDP eine zusätzliche Verschlüsselungsschicht. Diese basiert auf dem Industriestandard TLS. Doch ist die native RDP-Verschlüsselung aus Kompatibilitätsgründen nach wie vor verfügbar, um auch älteren Clients den Verbindungsaufbau zu ermöglichen. Sie sollten in Ihrer Umgebung unbedingt überall den TLS-Standard für RDP erzwingen, um zu verhindern, dass ein Angreifer einen alten Client emuliert und eine RDP-Verbindung zur Verwendung eines unsicheren Protokolls veranlasst (Protocol Downgrade Attack).

Diese Einstellung können Sie ausschließlich auf der Serverseite vornehmen (wobei "Server" auch ein Client-Betriebssystem sein kann). Verwenden Sie dafür die Gruppenrichtlinie "Computer \ Administrative Vorlagen \ Remotedesktopdienste \ Remotedesktopsitzungs-Host \ Sicherheit \ Verwendung einer bestimmten Sicherheitsstufe erforderlich". In einer RDS-Bereitstellung mit einem Connection Broker können Sie die Verschlüsselungsstufe zudem in den Eigenschaften von Sitzungssammlungen einstellen.

Lassen Sie sich nicht von dem Verweis auf "TLS 1.0" sowohl in der Gruppenrichtlinie als auch in den Eigenschaften der Session Collection verunsichern – RDP baut in Sachen TLS auf das kryptographische Subsystem von Windows auf und handelt die höchste TLS-Version aus, die sowohl beim Server als auch beim Client Unterstützung findet. Dieser Sachverhalt ist im Microsoft-Troubleshooting beschrieben. Stellen Sie deshalb sicher, dass die Channel-Konfiguration Ihrer Server veraltete TLS-Dialekte wie SSL nicht zulässt.

Jede TLS-Verschlüsselung beruht auf Zertifikaten. Beim Aufbau der ersten eingehenden Verbindung mit TLS-Verschlüsselung erzeugt die RDP-Schnittstelle des Servers im Zertifikatsspeicher "Remotedesktop" ein selbstsigniertes Serverzertifikat mit sechs Monaten Laufzeit. Diesem Zertifikat wird natürlich nicht vertraut, weshalb Sie das fehlende Vertrauen entweder ignorieren oder dieses Zertifikat als vertrauenswürdig markieren können.

In diesem Fall besteht das Risiko, Opfer einer Man-In-The-Middle-Attacke zu werden. Falls Sie eine eigene PKI betreiben, können und sollten Sie für Ihre RDPVerbindungen Zertifikate einsetzen, die aus Ihrer internen, vertrauten PKI stammen. Dafür stehen Ihnen zwei Möglichkeiten zur Verfügung:

Entweder stellen Sie ein Serverzertifikat für jeden Server aus und spielen Sie es in den Computer-Store des Servers ein. Notieren Sie sich den SHA1-Fingerabdruck dieses Zertifikats. Führen Sie anschließend mit Administratorrechten den folgenden PowerShell-Befehl aus:

$ts = Get-WMIObject -Class "Win32_TSGeneralSetting" -Namespace "root\cimv2\TerminalServices"

Set-WmiInstance -InputObject $ts -Arguments @{"SSLCertificate SHA1Hash"="SHA1-Fingerabdruck."}

Oder Sie erzeugen in Ihrer PKI eine Zertifikatsvorlage für ein Serverzertifikat mit einer zusätzlichen Anwendungsrichtlinie namens "Remote Desktop Authentication", die auf die OID "1.3.6.1.4.1.311. 54.1.2" hört. Diese Richtlinie müssen Sie in der Regel selbst erstellen. Achten Sie dabei auf die exakte Schreibung des Namens. Erzeugen Sie nun eine Gruppenrichtlinie, die den Wert "Computer \ Administrative Vorlagen \ Remotedesktopdienste \ Remotedesktopsitzungs-Host \ Sicherheit \ Zertifikatsvorlage für Serverauthentifizierung" auf den Namen (nicht Anzeigenamen!) der Zertifikatsvorlage setzt.

Beide Wege sind in der Tech-Community von Microsoft genauer beschrieben. Der erste Ansatz erlaubt es, Zertifikate aus einer beliebigen PKI zu verwenden, auch wenn das Beantragen, Ausstellen und Installieren der Zertifikate manuell erfolgen muss. Der zweite Ansatz lässt sich am besten mit Autoenrollment kombinieren und sorgt dafür, dass alle Server, die Mitglied in Ihrem Active Directory sind, automatisch mit korrekten Zertifikaten für RDP versehen werden. Sie müssen Ihre IT-Mitarbeiter natürlich darauf hinweisen, dass Zertifikatswarnungen beim RDP-Zugriff ernst zu nehmen sind.

Sonderfall: Vertrauen in Signatur
Ein Sonderfall des Vertrauens in Zertifikate im Kontext von RDS ist das Vertrauen in die Integrität der Verknüpfungen, die der RDP-Client aus dem Web Access oder aus dem Startmenü aufrufen soll. Hier geht es nicht um die Absicherung des Transports wie bei TLS, sondern um das Vertrauen in die Signatur. Die Ressourcenverknüpfungen (RDP-Dateien) werden durch den Connection Broker signiert und beinhalten sämtliche Clientkonfigurationen, die Sie in den Eigenschaften der Session Collection eingestellt haben, beispielsweise zur Datei- oder Druckerumleitung. Obwohl dieses Zertifikat in der Regel aus einer bereits vertrauten Quelle stammt, fällt bei Code- und Dokumentensignierung die Prüfung etwas schärfer aus und erfordert das explizite Vertrauen in das Endpunktzertifikat als Herausgeber.

Dieses Vertrauen können Sie auf zwei Arten herstellen: Entweder Sie setzen auf einem Client den Haken bei "Remoteverbindungen von diesem Herausgeber nicht mehr anfordern" und exportieren anschließend den Registrierungsschlüssel "HKEY_CURRENT_USER \ Software \ Microsoft \ Terminal Server Client \ PublisherBypassList" vom Client. Verteilen Sie den entsprechenden Wert auf alle Clients und die Nutzer werden nicht mehr nach einer Bestätigung gefragt.

Alternativ verteilen Sie den SHA1-Fingerabdruck des Zertifikats über die Gruppenrichtlinie "Computer \ Administrative Vorlagen \ Remotedesktopdienste \ Remotedesktopsitzungs-Client \ SHA1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige RDP-Herausgeber darstellen".

Diese Policy wird durch den Registrierungspfad "HKEY_CURRENT_ USER \ Software \ Policies \ Microsoft \ Windows NT \ Terminal Services \ TrustedCertThumbprints" abgebildet. Sie können ihn auch direkt verteilen, beispielsweise an Nicht-Domänen-Clients. In beiden Fällen müssen Sie die Einstellung jedes Mal neu ausrollen, wenn das Zertifikat auf dem Connection Broker sich ändert.

ln/Evgenij Smirnov

Im dritten und letzten Teil der Workshopserie gehen wir darauf ein, wie Sie Credentials beim RDP-Zugriff absichern. Im ersten Teil haben wir veranschaulicht, warum gerade Server beim Remotezugriff besonders zu schützen sind.