RDP sichere RPC Pruefung: Richtlinienquelle bestätigen

Was ist die RDP sichere RPC Pruefung?

Die RDP sichere RPC Pruefung beginnt mit einer Unterscheidung: Eine Richtlinie zum Schutz der Verwaltungsschnittstelle von Remote Desktop Services beantwortet eine andere Frage als die Verschlüsselung einer Remotedesktopverbindung. Ein Auditbefund kann erfasste Richtlinienwerte aufzeigen, die untersucht werden sollten. Um ihn abzuschließen, sind Nachweise für denselben Server erforderlich, in denen Quelle und Anwendbarkeit jeder Einstellung festgehalten werden.

Das praktische Ergebnis ist eine Prüfung des Hosts: Welcher Computer erhält die RPC-Richtlinie, woher stammt sein nativer RDP-Verschlüsselungsgrad und was bleibt über eine tatsächliche Verbindung unbekannt? Halten Sie diese Schlussfolgerungen getrennt. Eine domänenweite Erfassung kann zwei beruhigende Werte enthalten, ohne zu zeigen, dass einer davon den geprüften Server schützt.

Zu den übergeordneten Entscheidungen über Authentifizierung und die Delegierung von Anmeldeinformationen lesen Sie unseren Leitfaden zur Unterscheidung von NLA, RDP-Sicherheitsschicht und Restricted Admin-Modus. Dieses Verfahren konzentriert sich auf die Richtlinie für administrative RPC-Aufrufe und die Herkunft der Verschlüsselungseinstellung.

Funktionsweise: Verwaltung, Richtlinien und Verbindungsnachweise

Microsofts Referenz zum RemoteDesktopServices Policy CSP beschreibt RequireSecureRPCCommunication als Schutz der RPC-Schnittstelle, über die RDS verwaltet und konfiguriert wird. Enabled verlangt authentifizierte, verschlüsselte Anforderungen; Disabled erlaubt ungesicherte Clients, die nicht auf die Sicherheitsanforderung reagieren; Not Configured erlaubt ungesicherte Kommunikation. Die ADMX-Zuordnung nennt fEncryptRPCTraffic unter SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

Dieselbe Referenz besagt, dass ClientConnectionEncryptionLevel für native RDP-Verschlüsselung gilt, nicht für SSL-Verschlüsselung. Der Anzeigename lautet Set client connection encryption level. Beide Richtlinien befinden sich unter Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.

Verwenden Sie bei der Prüfung drei Kategorien von Nachweisen. Dies ist eine vorgeschlagene Prüfmethode, kein Compliance-Rahmenwerk von Microsoft:

Erkennung: Denselben RDS-Host prüfen

Wählen Sie ein identifiziertes Windows-Ziel und dokumentieren Sie Hostname, Betriebssystem, vorgesehenen Richtlinienbereich, prüfende Person und Erfassungszeitpunkt. Wiederholen Sie die Prüfung für weitere Bereiche, statt einen Server als repräsentativ für jede RDS-Bereitstellung zu behandeln. Die folgenden Befehle sind Beispiele auf Grundlage der Dokumentation; für diesen Artikel wurden weder ein Windows-Endpunkt noch eine reale Domäne getestet.

Führen Sie jeden Befehl einzeln auf dem Ziel mit einem Konto aus, das die betreffende Konfiguration lesen darf. Bewahren Sie Fehler und fehlende Ausgaben auf. Ein fehlgeschlagener Lesezugriff ist eine Nachweislücke, kein unsicherer Wert und keine erfolgreiche Kontrolle.

Schritt 1: Anwendbarkeit der Computerrichtlinien feststellen

Microsofts gpresult-Referenz dokumentiert RSoP für den Computerbereich sowie zusammengefasste, ausführliche und HTML-Ausgaben. Beginnen Sie mit:

gpresult /scope computer /r

Erwarten Sie Informationen zu Computerrichtlinien und angewendeten GPOs. Eine Zusammenfassung liefert Kontext; sie klärt nicht die Herkunft jeder einzelnen Einstellung. Erfassen Sie detaillierte Informationen, wenn Sie mögliche Richtlinien vergleichen:

gpresult /scope computer /z

Fügen Sie die relevanten Einstellungsdetails der Prüfung bei. Identifizieren Sie, welche GPO die RPC-Richtlinie und welche die Richtlinie zum Verschlüsselungsgrad bereitstellt. Die beiden Einstellungen dürfen aus unterschiedlichen GPOs stammen, sofern beide nachweislich auf denselben Host anwendbar sind. Kann der Bericht die maßgebliche Quelle nicht klären, bleibt dieser Teil der Prüfung offen.

Unser GPO-Leitfaden mit vier Prüfungen zu Richtlinienwerten, empfangenden Computern und tatsächlichem Schutz verwendet dieselbe Unterscheidung auf dem Zielsystem für LLMNR, WSUS, LSA-Schutz und den Zugriff auf Richtlinienfreigaben. Diese Kontrollen bleiben von dieser RPC-Prüfung getrennt.

Schritt 2: Wert der Richtlinie für administrative RPC-Aufrufe lesen

Dieser Befehl setzt Microsofts dokumentierte reg query-Syntax mit der Registrierungszuordnung des CSP um:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fEncryptRPCTraffic

Bewahren Sie Schlüssel, Werttyp, Daten und Fehlertext exakt wie ausgegeben auf. Bei einer Prüfung, die eine aktivierte Richtlinie zum Ziel hat, gleichen Sie den Zielwert mit dem Richtlinienbericht und der erfassten GPO-Deklaration ab. Das Prädikat von etc-collector akzeptiert einen erfassten Wert von mindestens 1; ein überraschender Wert über 1 sollte für die Prüfung sichtbar bleiben, statt zu einem angenommenen booleschen Wert normalisiert zu werden.

Ein fehlender Wert ist nicht dieselbe Beobachtung wie eine ausdrücklich deaktivierte Richtlinie. Stellen Sie fest, ob die Richtlinie konfiguriert und anwendbar war, bevor Sie entscheiden, was geändert werden soll. Ersetzen Sie den Nachweis zur administrativen Richtlinie nicht durch Verschlüsselungsnachweise einer Desktopverbindung.

Schritt 3: Verschlüsselungskonfiguration und ihre Quelle lesen

Lesen Sie den Richtlinienwert separat:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v MinEncryptionLevel

Fragen Sie anschließend die Terminaleinstellungen des Ziels ab. Das folgende Beispiel kombiniert die dokumentierte Get-CimInstance-Syntax mit dem Namespace und der Klasse aus Microsofts Win32_TSGeneralSetting-Referenz:

Get-CimInstance -Namespace root/CIMV2/TerminalServices -ClassName Win32_TSGeneralSetting

Ohne Parameter für einen Remotecomputer oder eine CIM-Sitzung liest das Cmdlet die lokale WMI. Bewahren Sie die zurückgegebenen Objekte auf und identifizieren Sie den relevanten TerminalName; verwenden Sie nicht stillschweigend die erste Instanz. Prüfen Sie MinEncryptionLevel, PolicySourceMinEncryptionLevel, SecurityLayer und PolicySourceSecurityLayer.

Die Klasse dokumentiert die Verschlüsselungsgrade 1 Low, 2 Client Compatible, 3 High und 4 FIPS Compliant. Ihre Felder zur Richtlinienquelle verwenden 0 für Serverkonfiguration, 1 für Group Policy und 2 für Standard. Diese Felder beschreiben die Herkunft, keine bestimmte maßgebliche GPO. Die Eigenschaft SecurityLayer verwendet 1 für natives RDP, 2 für Negotiate und 3 für SSL; verwechseln Sie diese Eigenschaftsskala nicht mit einer Registrierungs- oder Setter-Skala. Die Klasse dokumentiert außerdem Paketvertraulichkeit für Verbindungen zu ihrem Namespace. Bewahren Sie einen Provider- oder Zugriffsfehler auf, ohne die Sicherheit zu schwächen, um eine Ausgabe zu erhalten.

Die erwartete Ausgabe bezeichnet hier benannte Konfigurationseigenschaften, die zu prüfen sind, kein erfundenes Protokoll einer bestandenen Kontrolle. Vergleichen Sie den zurückgegebenen Grad und die Quelle mit dem Richtlinienbericht und halten Sie Abweichungen für die Untersuchung fest.

Schritt 4: Den Kenntnisstand zur Verbindung festhalten

Die geprüfte Klasse beschreibt Terminalkonfiguration und Richtlinienquellen. Sie ist kein Protokoll eines bestimmten TLS-Handshakes. Dokumentieren Sie den durch die Konfiguration angezeigten Mechanismus getrennt von Nachweisen zu einer realen Verbindung.

Entscheiden Sie vor der Erfassung zusätzlicher Nachweise, was sich ohne Änderung des Dienstes beobachten lässt. Verwenden Sie vorhandene, autorisierte Verbindungsnachweise, soweit verfügbar; ordnen Sie sie dem vorgesehenen Server, Client und Zeitpunkt zu. Geben Sie an, ob sie tatsächlich natives RDP oder TLS für diesen Austausch belegen. Dieser Artikel schreibt weder eine undokumentierte Ereignis-ID noch eine Aussage zu Chiffren oder ein universelles Aufzeichnungsverfahren vor.

Falls sitzungsspezifische Nachweise fehlen, dokumentieren Sie Aushandlung der Verbindung nicht nachgewiesen. Starten Sie RDS nicht neu, ändern Sie seine Sicherheitsschicht nicht und erstellen Sie keine experimentelle Verbindung, nur um einen unvollständigen Lesezugriff abschließend erscheinen zu lassen. Planen Sie zusätzliche Validierung als separate genehmigte betriebliche Aufgabe.

Behebung: Pro Host entscheiden, umsetzen und erneut prüfen (Remediation)

Nachweise vor Richtlinienänderungen klären

Verwenden Sie die folgenden Fragen als ausdrückliche Entscheidungspunkte:

1. Stammen beide Werte aus GPOs, die tatsächlich auf denselben RDS-Server anwendbar sind? Fügen Sie den Quellennachweis für jeden Wert bei, auch wenn die GPOs unterschiedlich sind.
2. Welcher Mechanismus schützt die Verbindung, natives RDP oder TLS, und welche Nachweise lassen sich ohne Änderung des Dienstes erfassen? Kennzeichnen Sie jede nicht beobachtete Aushandlung als unbekannt.
3. Welche Schlussfolgerung soll erhalten bleiben, wenn der historische Bezeichner oder die Katalogbezeichnung vom aktuellen Code abweicht? Bewahren Sie den Bezeichner zur Nachverfolgbarkeit auf und beschreiben Sie die implementierte Kontrolle separat.

Eine nützliche Prüfung kann mit einer offenen Nachweisaufgabe enden. Schließen Sie sie nicht als geschützt ab, nur weil der Collector keinen Befund mehr meldet. Umgekehrt belegt eine Lücke in der Richtlinienerfassung allein nicht, dass der Server exponiert ist.

Die administrative RPC-Einstellung auf den vorgesehenen Bereich anwenden

Wenn die Prüfung ergibt, dass sichere administrative RPC-Aufrufe erforderlich und nicht wie vorgesehen konfiguriert sind, verwenden Sie Require secure RPC communication = Enabled im oben dokumentierten Richtlinienpfad. Identifizieren Sie vor der Einführung den GPO-Verantwortlichen, betroffene Computer und Verwaltungsclients. Planen Sie die Kompatibilitätsvalidierung und den Wiederherstellungszugriff für den Pilotbereich.

Nachdem die Änderung das Ziel erreicht hat, wiederholen Sie die unter Erkennung gezeigten Lesezugriffe mit gpresult und fEncryptRPCTraffic. Fügen Sie Vorher-/Nachher-Nachweise bei und dokumentieren Sie jeden Ausfall eines Verwaltungsclients. Eine geänderte Richtliniendeklaration ohne Zielnachweis lässt die Frage der Anwendbarkeit offen.

Die native Verschlüsselungseinstellung nach ihrer Anwendbarkeit behandeln

Wo natives RDP weiterhin relevant ist, wählen Sie den vorgesehenen Grad über Set client connection encryption level und dokumentieren Sie die Entscheidung zur Clientkompatibilität. Behandeln Sie den Test >=3 des Collectors als dessen Implementierungsschwelle, nicht als universelle Compliance-Anforderung. Wo SSL/TLS die Verbindung schützt, bleiben die Anwendbarkeit der nativen Richtlinie und der Verbindungsschutz getrennte Entscheidungen.

Wiederholen Sie nach einer Richtlinienänderung die Lesezugriffe auf MinEncryptionLevel und CIM. Dokumentieren Sie, ob sich Konfiguration oder Herkunft geändert haben, ob die Quelle dem vorgesehenen Verwaltungskanal entspricht und welche Verbindungsfrage noch Nachweise benötigt. Ändern Sie den Verschlüsselungsgrad nicht ausschließlich zur Unterdrückung des Befunds, ohne seine Anwendbarkeit zu verstehen.

Einen überprüfbaren Entscheidungsnachweis aufbewahren

Bewahren Sie für jeden Host den ursprünglichen Befund und Erfassungszeitpunkt auf; Namen und Bezeichner anwendbarer GPOs; rohe Registrierungsausgaben; Terminalinstanz und Felder zur Richtlinienquelle; Verbindungsnachweise oder deren Fehlen; sowie Verantwortlichen, Begründung und Folgemaßnahmen zur Entscheidung. Verknüpfen Sie Ausnahmen mit einem identifizierten Bereich und einem Prüftermin. Unterscheiden Sie die Behebung der Konfiguration vom Abschluss der Verbindungsvalidierung.

Wie EtcSec dies erkennt

Die einzige hier zugeordnete Katalogkontrolle ist ANSSI_R79_RDP_NOT_HARDENED. In der bei Commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d geprüften Implementierung von etc-collector wertet Detect() erfasste GPO-RegistrySettings aus:

Der Provider liest Computer-GPO-Dateien aus SYSVOL; der Registry.pol-Parser ordnet die beiden Terminal Services-DWORD-Werte den Feldern zu, die diese Kontrolle verwendet. Der Detektor aggregiert sie über die erfassten GPOs hinweg. Er stellt weder die wirksame Richtlinie für einen einzelnen RDS-Host fest, noch verlangt er beide Werte im selben anwendbaren Bereich, noch prüft er ausgehandelte Sitzungen. Count 1 beschreibt den Befund, keine gemessene Anzahl exponierter Server.

ANSSI_R79 ist ein historischer Bezeichner. Der Code schließt ausdrücklich aus, R79 zu messen, lässt den Bezeichner aber unverändert; der geprüfte Blogkatalog zeigt weiterhin eine ältere clientbezogene Bezeichnung. Halten Sie diese Abweichung im Prüfprotokoll fest. Machen Sie aus dem Tag kein Urteil über ANSSI-Konformität.

Der Erläuterungstext des Befunds nennt Downgrade- und MITM-Szenarien, doch sein Prädikat beobachtet weder einen Netzwerkangriff noch die Sitzungsaushandlung. Dieser Befund bestätigt weder MITM noch eine Kompromittierung oder eine unverschlüsselte Desktopsitzung. Verwenden Sie ihn, um die Hostprüfung zu eröffnen, und bewahren Sie anschließend die Nachweise und die Entscheidung für jede einzelne Schutzfrage auf.