Audit RPC RDP : vérifier la source des stratégies

Qu’est-ce qu’un audit RPC RDP ?

Un audit RPC RDP commence par une distinction : une stratégie qui protège l’interface d’administration de Remote Desktop Services répond à une autre question que le chiffrement utilisé par une connexion de bureau à distance. Un constat d’audit peut repérer des valeurs de stratégie collectées qui méritent une investigation. Sa clôture exige des preuves concernant le même serveur, avec la source et l’applicabilité de chaque paramètre consignées.

Le livrable concret est une revue par hôte : quel ordinateur reçoit la stratégie RPC, d’où vient son niveau de chiffrement RDP natif et ce qui reste inconnu au sujet d’une connexion réelle. Gardez ces conclusions séparées. Une collecte à l’échelle du domaine peut contenir deux valeurs rassurantes sans montrer que l’une ou l’autre protège le serveur examiné.

Pour les décisions plus larges concernant l’authentification et la délégation des identifiants, consultez notre guide distinguant NLA, la couche de sécurité RDP et le mode Restricted Admin. Cette procédure porte sur la stratégie RPC d’administration et la provenance du paramètre de chiffrement.

Fonctionnement : administration, stratégie et preuves de connexion

La référence Microsoft du CSP de stratégie RemoteDesktopServices décrit RequireSecureRPCCommunication comme une protection de l’interface RPC utilisée pour administrer et configurer RDS. Enabled exige des requêtes authentifiées et chiffrées ; Disabled autorise les clients non sécurisés qui ne répondent pas à la demande de sécurité ; Not Configured autorise les communications non sécurisées. Son mappage ADMX indique fEncryptRPCTraffic sous SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

La même référence précise que ClientConnectionEncryptionLevel s’applique au chiffrement RDP natif, pas au chiffrement SSL. Son nom convivial est Set client connection encryption level. Les deux stratégies se trouvent sous Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.

Utilisez trois catégories de preuves dans la revue. Il s’agit d’une méthode de revue proposée, pas d’un cadre de conformité Microsoft :

Détection : vérifier le même hôte RDS

Choisissez une cible Windows identifiée et consignez son nom d’hôte, son système d’exploitation, le périmètre de stratégie visé, le responsable de la revue et l’heure de collecte. Répétez la revue pour les autres périmètres au lieu de considérer un serveur comme représentatif de tous les déploiements RDS. Les commandes ci-dessous sont des exemples fondés sur la documentation ; aucun terminal Windows ni domaine réel n’a été testé pour cet article.

Exécutez chaque commande séparément sur la cible avec un compte autorisé à lire la configuration concernée. Conservez les erreurs et les sorties manquantes. Une lecture qui échoue constitue une lacune dans les preuves, pas une valeur non sécurisée ni un contrôle réussi.

Étape 1 : établir l’applicabilité des stratégies ordinateur

La référence Microsoft de gpresult documente le RSoP au niveau ordinateur et les sorties récapitulatives, détaillées et HTML. Commencez par :

gpresult /scope computer /r

Vous devez obtenir les informations de stratégie ordinateur et les GPO appliquées. Un résumé apporte du contexte ; il ne résout pas la provenance de chaque paramètre individuel. Collectez les informations détaillées lorsque vous comparez les stratégies candidates :

gpresult /scope computer /z

Joignez les détails du paramètre concerné à la revue. Identifiez la GPO qui fournit la stratégie RPC et celle qui fournit la stratégie de niveau de chiffrement. Les deux paramètres peuvent légitimement provenir de GPO différentes, à condition que leur applicabilité à ce même hôte soit démontrée. Si le rapport ne permet pas d’établir la source qui prévaut, laissez cette partie de la revue non résolue.

Notre guide GPO en quatre contrôles sur les valeurs de stratégie, les ordinateurs destinataires et la protection réelle utilise la même distinction côté cible pour LLMNR, WSUS, la protection LSA et l’accès au partage des stratégies. Ces contrôles restent distincts de cette revue RPC.

Étape 2 : lire la valeur de stratégie RPC d’administration

Cette commande applique la syntaxe de reg query documentée par Microsoft au mappage de registre du CSP :

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

Conservez la clé, le type de valeur, les données et le texte d’erreur exactement tels qu’ils sont retournés. Pour une revue visant une stratégie activée, rapprochez la valeur de la cible du rapport de stratégie et de la déclaration GPO collectée. Le prédicat d’etc-collector accepte une valeur collectée d’au moins 1 ; une valeur inattendue supérieure à 1 doit rester visible pour la revue plutôt qu’être normalisée en un booléen supposé.

Une valeur absente n’est pas la même observation qu’une stratégie explicitement désactivée. Déterminez si la stratégie était configurée et applicable avant de décider quoi modifier. Ne remplacez pas les preuves de stratégie d’administration par les preuves de chiffrement d’une connexion de bureau.

Étape 3 : lire la configuration du chiffrement et sa source

Lisez séparément la valeur de stratégie :

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

Interrogez ensuite les paramètres Terminal Services de la cible. L’exemple suivant combine la syntaxe documentée de Get-CimInstance avec l’espace de noms et la classe de la référence Microsoft de Win32_TSGeneralSetting :

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

Sans paramètre d’ordinateur distant ni de session CIM, la cmdlet lit le WMI local. Conservez les objets retournés et identifiez le TerminalName pertinent ; n’utilisez pas silencieusement la première instance. Examinez MinEncryptionLevel, PolicySourceMinEncryptionLevel, SecurityLayer et PolicySourceSecurityLayer.

La classe documente les niveaux de chiffrement 1 Low, 2 Client Compatible, 3 High et 4 FIPS Compliant. Ses champs de source de stratégie utilisent 0 pour la configuration du serveur, 1 pour Group Policy et 2 pour la valeur par défaut. Ces champs décrivent la provenance, pas une GPO précise qui prévaut. Sa propriété SecurityLayer utilise 1 pour RDP natif, 2 pour Negotiate et 3 pour SSL ; ne confondez pas cette échelle de propriété avec celle d’un registre ou d’une méthode de définition. La classe documente également la confidentialité des paquets pour les connexions à son espace de noms. Conservez toute erreur de fournisseur ou d’accès sans affaiblir la sécurité pour obtenir une sortie.

La sortie attendue désigne ici des propriétés de configuration nommées à examiner, pas une transcription inventée d’un contrôle réussi. Comparez le niveau et la source retournés au rapport de stratégie, en conservant les divergences pour investigation.

Étape 4 : préciser ce qui est connu sur la connexion

La classe examinée décrit la configuration Terminal Services et les sources de stratégie. Elle ne constitue pas une transcription d’une négociation TLS particulière. Consignez le mécanisme indiqué par la configuration séparément des preuves concernant une connexion réelle.

Avant de collecter d’autres preuves, déterminez ce qui peut être observé sans modifier le service. Utilisez les preuves de connexion existantes et autorisées lorsqu’elles sont disponibles ; associez-les au serveur visé, au client et à l’heure. Précisez si elles établissent réellement l’utilisation de RDP natif ou de TLS pour cet échange. Cet article ne prescrit ni identifiant d’événement non documenté, ni affirmation sur un algorithme de chiffrement, ni méthode universelle de capture.

Si les preuves propres à la session ne sont pas disponibles, consignez négociation de la connexion non démontrée. Ne redémarrez pas RDS, ne modifiez pas sa couche de sécurité et ne créez pas de connexion expérimentale simplement pour rendre une lecture incomplète apparemment concluante. Planifiez une validation supplémentaire comme une tâche opérationnelle distincte et approuvée.

Remédiation : décider, appliquer et revérifier par hôte (Remediation)

Résoudre les questions de preuves avant de modifier la stratégie

Utilisez les questions suivantes comme points de décision explicites :

1. Les deux valeurs proviennent-elles de GPO effectivement applicables à ce même serveur RDS ? Joignez les preuves de source pour chacune, même si les GPO diffèrent.
2. Quel mécanisme protège la connexion, RDP natif ou TLS, et quelles preuves peuvent être collectées sans modifier le service ? Marquez toute négociation non observée comme inconnue.
3. Quelle conclusion conserver si l’identifiant historique ou le libellé du catalogue diffère du code actuel ? Préservez l’identifiant pour la traçabilité et décrivez séparément le contrôle implémenté.

Une revue utile peut se terminer par une tâche de preuve non résolue. Évitez de la clôturer avec une conclusion de protection simplement parce que le collecteur cesse de signaler un constat. À l’inverse, une lacune de collecte de stratégie ne suffit pas à établir que le serveur est exposé.

Appliquer le paramètre RPC d’administration au périmètre visé

Lorsque la revue établit qu’un RPC d’administration sécurisé est requis et n’est pas configuré comme prévu, utilisez Require secure RPC communication = Enabled dans le chemin de stratégie documenté plus haut. Identifiez le propriétaire de la GPO, les ordinateurs concernés et les clients d’administration avant le déploiement. Planifiez la validation de compatibilité et l’accès de récupération pour le périmètre pilote.

Après que la modification a atteint la cible, répétez les lectures gpresult et fEncryptRPCTraffic présentées dans la détection. Joignez les preuves avant/après et consignez toute défaillance d’un client d’administration. Une déclaration de stratégie modifiée sans preuve côté cible laisse la question de l’applicabilité ouverte.

Traiter le paramètre de chiffrement natif selon son applicabilité

Lorsque RDP natif reste pertinent, sélectionnez le niveau souhaité via Set client connection encryption level, en documentant la décision de compatibilité client. Considérez le test >=3 du collecteur comme le seuil de son implémentation, pas comme une exigence universelle de conformité. Lorsque SSL/TLS protège la connexion, gardez l’applicabilité de la stratégie native et la protection de la connexion comme deux décisions séparées.

Répétez les lectures MinEncryptionLevel et CIM après une modification de stratégie. Consignez si la configuration ou la provenance a changé, si la source correspond au canal de gestion prévu et quelle question sur la connexion nécessite encore des preuves. Ne modifiez pas le niveau de chiffrement uniquement pour supprimer le constat sans comprendre son applicabilité.

Conserver un dossier de décision vérifiable

Pour chaque hôte, conservez le constat initial et l’heure de collecte ; les noms et identifiants des GPO applicables ; la sortie brute du registre ; l’instance Terminal Services et les champs de source de stratégie ; les preuves de connexion ou leur absence ; ainsi que le responsable, la justification et le suivi de la décision. Rattachez les exceptions à un périmètre identifié et à une date de revue. Distinguez la remédiation de configuration de l’achèvement de la validation de connexion.

Comment EtcSec détecte ce problème

Le seul contrôle du catalogue rattaché ici est ANSSI_R79_RDP_NOT_HARDENED. Dans l’implémentation d’etc-collector examinée au commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, Detect() évalue les RegistrySettings des GPO collectées :

Le fournisseur lit les fichiers GPO ordinateur dans SYSVOL ; l’analyseur Registry.pol associe les deux valeurs DWORD de Terminal Services aux champs utilisés par ce contrôle. Le détecteur les agrège sur l’ensemble des GPO collectées. Il n’établit pas la stratégie effective d’un hôte RDS individuel, n’exige pas les deux valeurs dans le même périmètre applicable et n’inspecte pas les sessions négociées. Count 1 décrit le constat, pas un nombre mesuré de serveurs exposés.

ANSSI_R79 est un identifiant historique. Le code précise explicitement qu’il ne mesure pas R79 tout en conservant l’identifiant ; le catalogue du blog examiné affiche encore un ancien libellé orienté client. Gardez cette divergence dans le dossier de revue. Ne transformez pas ce tag en verdict de conformité ANSSI.

Le texte explicatif du constat mentionne des scénarios de rétrogradation et de MITM, mais son prédicat n’observe ni attaque réseau ni négociation de session. Ce constat ne confirme ni MITM, ni compromission, ni session de bureau non chiffrée. Utilisez-le pour ouvrir la tâche de vérification de l’hôte, puis conservez les preuves et la décision pour chaque question de protection distincte.