RPC seguro RDP: verificar el origen de la directiva

¿Qué es la verificación de RPC seguro RDP?

La verificación de RPC seguro RDP empieza con una distinción: una directiva que protege la interfaz de administración de Remote Desktop Services responde a una pregunta diferente del cifrado utilizado por una conexión de escritorio remoto. Un hallazgo de auditoría puede identificar valores de directiva recopilados que merecen una investigación. Cerrarlo exige pruebas del mismo servidor, con el origen y la aplicabilidad de cada ajuste registrados.

El resultado práctico es una revisión por host: qué equipo recibe la directiva RPC, de dónde procede su nivel de cifrado RDP nativo y qué sigue siendo desconocido sobre una conexión real. Mantenga esas conclusiones separadas. Una recopilación de todo el dominio puede contener dos valores tranquilizadores sin demostrar que alguno protege el servidor revisado.

Para las decisiones más amplias sobre autenticación y delegación de credenciales, consulte nuestra guía que distingue NLA, la capa de seguridad RDP y el modo Restricted Admin. Este procedimiento se centra en la directiva RPC de administración y en la procedencia del ajuste de cifrado.

Cómo funciona: administración, directiva y pruebas de conexión

La referencia de Microsoft del CSP de directivas RemoteDesktopServices describe RequireSecureRPCCommunication como una protección de la interfaz RPC utilizada para administrar y configurar RDS. Enabled exige solicitudes autenticadas y cifradas; Disabled permite clientes no seguros que no responden a la solicitud de seguridad; Not Configured permite comunicaciones no seguras. Su correspondencia ADMX indica fEncryptRPCTraffic en SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

La misma referencia establece que ClientConnectionEncryptionLevel se aplica al cifrado RDP nativo, no al cifrado SSL. Su nombre descriptivo es Set client connection encryption level. Ambas directivas se encuentran en Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.

Utilice tres categorías de pruebas en la revisión. Se trata de un método de revisión propuesto, no de un marco de cumplimiento de Microsoft:

Detección: verificar el mismo host RDS

Seleccione un destino Windows identificado y registre su nombre de host, sistema operativo, ámbito de directiva previsto, responsable de revisión y hora de recopilación. Repita la revisión para otros ámbitos en lugar de considerar un servidor representativo de todos los despliegues RDS. Los comandos siguientes son ejemplos basados en la documentación; no se probó ningún equipo Windows ni dominio real para este artículo.

Ejecute cada comando por separado en el destino con una cuenta autorizada para leer la configuración correspondiente. Conserve los errores y las salidas ausentes. Una lectura fallida es una carencia de pruebas, no un valor inseguro ni una comprobación satisfactoria.

Paso 1: establecer la aplicabilidad de las directivas de equipo

La referencia de Microsoft de gpresult documenta el RSoP de ámbito de equipo y las salidas de resumen, detalladas y HTML. Empiece con:

gpresult /scope computer /r

Debe obtener información de directivas de equipo y las GPO aplicadas. Un resumen aporta contexto; no resuelve la procedencia de cada ajuste individual. Recopile información detallada al comparar las directivas candidatas:

gpresult /scope computer /z

Adjunte a la revisión los detalles del ajuste correspondiente. Identifique qué GPO proporciona la directiva RPC y cuál proporciona la directiva de nivel de cifrado. Los dos ajustes pueden proceder legítimamente de GPO diferentes, siempre que ambos sean demostrablemente aplicables a este mismo host. Si el informe no permite determinar el origen que prevalece, deje esa parte de la revisión sin resolver.

Nuestra guía GPO de cuatro comprobaciones sobre valores de directiva, equipos destinatarios y protección real utiliza la misma distinción en el destino para LLMNR, WSUS, la protección LSA y el acceso al recurso compartido de directivas. Esos controles siguen siendo independientes de esta revisión RPC.

Paso 2: leer el valor de la directiva RPC de administración

Este comando aplica la sintaxis de reg query documentada por Microsoft a la correspondencia de registro del CSP:

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

Conserve la clave, el tipo de valor, los datos y el texto de error exactamente como se devuelvan. Para una revisión cuyo objetivo sea una directiva habilitada, contraste el valor del destino con el informe de directivas y la declaración GPO recopilada. El predicado de etc-collector acepta un valor recopilado de al menos 1; un valor inesperado superior a 1 debe seguir visible para la revisión en lugar de normalizarse a un booleano supuesto.

La ausencia de un valor no es la misma observación que una directiva explícitamente deshabilitada. Determine si la directiva estaba configurada y era aplicable antes de decidir qué cambiar. No sustituya las pruebas de la directiva de administración por las pruebas de cifrado de una conexión de escritorio.

Paso 3: leer la configuración de cifrado y su origen

Lea el valor de directiva por separado:

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

Después consulte los ajustes de Terminal Services del destino. El siguiente ejemplo combina la sintaxis documentada de Get-CimInstance con el espacio de nombres y la clase de la referencia de Microsoft de Win32_TSGeneralSetting:

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

Sin un parámetro de equipo remoto o de sesión CIM, el cmdlet lee el WMI local. Conserve los objetos devueltos e identifique el TerminalName pertinente; no utilice silenciosamente la primera instancia. Examine MinEncryptionLevel, PolicySourceMinEncryptionLevel, SecurityLayer y PolicySourceSecurityLayer.

La clase documenta los niveles de cifrado 1 Low, 2 Client Compatible, 3 High y 4 FIPS Compliant. Sus campos de origen de directiva utilizan 0 para la configuración del servidor, 1 para Group Policy y 2 para el valor predeterminado. Estos campos describen la procedencia, no una GPO concreta que prevalezca. Su propiedad SecurityLayer utiliza 1 para RDP nativo, 2 para Negotiate y 3 para SSL; no confunda esta escala de la propiedad con una escala del registro o de un método de asignación. La clase también documenta la privacidad de paquetes para las conexiones a su espacio de nombres. Conserve cualquier error del proveedor o de acceso sin debilitar la seguridad para obtener una salida.

Aquí, salida esperada significa propiedades de configuración con nombre que deben examinarse, no una transcripción inventada de una comprobación satisfactoria. Compare el nivel y el origen devueltos con el informe de directivas, conservando las discrepancias para investigarlas.

Paso 4: indicar qué se sabe sobre la conexión

La clase revisada describe la configuración de Terminal Services y los orígenes de directiva. No es una transcripción de una negociación TLS concreta. Registre el mecanismo indicado por la configuración por separado de cualquier prueba sobre una conexión real.

Antes de recopilar pruebas adicionales, decida qué puede observarse sin cambiar el servicio. Utilice pruebas de conexión existentes y autorizadas cuando estén disponibles; asócielas al servidor previsto, al cliente y a la hora. Indique si realmente establecen el uso de RDP nativo o TLS para ese intercambio. Este artículo no prescribe un identificador de evento no documentado, una afirmación sobre algoritmos de cifrado ni una receta universal de captura.

Si no hay pruebas específicas de la sesión, registre negociación de la conexión no demostrada. No reinicie RDS, no cambie su capa de seguridad ni cree una conexión experimental solo para que una lectura incompleta parezca concluyente. Planifique la validación adicional como una tarea operativa independiente y aprobada.

Remediación: decidir, aplicar y volver a comprobar por host (Remediation)

Resolver las pruebas antes de cambiar la directiva

Utilice las siguientes preguntas como puntos de decisión explícitos:

1. ¿Proceden ambos valores de GPO efectivamente aplicables a este mismo servidor RDS? Adjunte las pruebas de origen de cada uno, aunque las GPO sean diferentes.
2. ¿Qué mecanismo protege la conexión, RDP nativo o TLS, y qué pruebas pueden recopilarse sin modificar el servicio? Marque como desconocida cualquier negociación no observada.
3. ¿Qué conclusión debe conservarse si el identificador histórico o la etiqueta del catálogo difiere del código actual? Preserve el identificador para la trazabilidad y describa por separado la comprobación implementada.

Una revisión útil puede terminar con una tarea de pruebas sin resolver. Evite cerrarla con una conclusión de protección simplemente porque el colector deja de informar de un hallazgo. A la inversa, una carencia de recopilación de directivas por sí sola no demuestra que el servidor esté expuesto.

Aplicar el ajuste RPC de administración al ámbito previsto

Cuando la revisión establezca que se requiere RPC de administración seguro y que no está configurado como se pretende, utilice Require secure RPC communication = Enabled en la ruta de directiva documentada anteriormente. Identifique al propietario de la GPO, los equipos afectados y los clientes de administración antes del despliegue. Planifique la validación de compatibilidad y el acceso de recuperación para el ámbito piloto.

Una vez que el cambio haya llegado al destino, repita las lecturas de gpresult y fEncryptRPCTraffic mostradas en Detección. Adjunte pruebas antes y después, y registre cualquier fallo de un cliente de administración. Una declaración de directiva modificada sin pruebas del destino deja abierta la cuestión de la aplicabilidad.

Tratar el ajuste de cifrado nativo según su aplicabilidad

Cuando RDP nativo siga siendo pertinente, seleccione el nivel previsto mediante Set client connection encryption level, documentando la decisión de compatibilidad de los clientes. Trate la prueba >=3 del colector como el umbral de su implementación, no como un requisito universal de cumplimiento. Cuando SSL/TLS proteja la conexión, mantenga la aplicabilidad de la directiva nativa y la protección de la conexión como decisiones separadas.

Repita las lecturas de MinEncryptionLevel y CIM después de un cambio de directiva. Registre si cambió la configuración o la procedencia, si el origen coincide con el canal de administración previsto y qué cuestión sobre la conexión sigue necesitando pruebas. No cambie el nivel de cifrado únicamente para suprimir el hallazgo sin entender su aplicabilidad.

Conservar un registro de decisión que pueda revisarse

Para cada host, preserve el hallazgo original y la hora de recopilación; los nombres e identificadores de las GPO aplicables; la salida bruta del registro; la instancia de Terminal Services y los campos de origen de directiva; las pruebas de conexión o su ausencia; y el responsable, la justificación y el seguimiento de la decisión. Vincule las excepciones a un ámbito identificado y a una fecha de revisión. Distinga la remediación de configuración de la finalización de la validación de conexión.

Cómo detecta EtcSec este problema

La única comprobación del catálogo vinculada aquí es ANSSI_R79_RDP_NOT_HARDENED. En la implementación de etc-collector revisada en el commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, Detect() evalúa los RegistrySettings de las GPO recopiladas:

El proveedor lee los archivos de GPO de equipo de SYSVOL; el analizador Registry.pol asigna los dos valores DWORD de Terminal Services a los campos utilizados por esta comprobación. El detector los agrega entre las GPO recopiladas. No establece la directiva efectiva de un host RDS individual, no exige ambos valores en el mismo ámbito aplicable ni inspecciona las sesiones negociadas. Count 1 describe el hallazgo, no un número medido de servidores expuestos.

ANSSI_R79 es un identificador histórico. El código declara explícitamente que no mide R79 mientras mantiene el identificador sin cambios; el catálogo del blog revisado sigue mostrando una etiqueta antigua orientada al cliente. Mantenga esa discrepancia en el registro de revisión. No convierta la etiqueta en un veredicto de cumplimiento de ANSSI.

El texto explicativo del hallazgo menciona escenarios de degradación y MITM, pero su predicado no observa ni un ataque de red ni la negociación de una sesión. Este hallazgo no confirma MITM, compromiso ni una sesión de escritorio sin cifrar. Utilícelo para abrir la tarea de verificación del host y después conserve las pruebas y la decisión para cada cuestión de protección distinta.