Restringir el inicio de sesión a través de escritorio remoto RDP a usuarios Administradores y permitirlo solamente a usuarios específicos

Por defecto para poder usar los Servicios de escritorio remoto RDP Remote Desktop Protocol necesitamos un usuario, ya sea local en la máquina remota o de dominio, que tenga permisos para poder conectarse. Para ello dicho usuario debe ser miembro del grupo "Administradores locales" o bien del grupo "Usuarios de escritorio remoto".

Agregar o quitar usuarios o grupos a través de las Propiedades del sistemas (sysdm.cpl) sería lo mismo que hacerlo a través del propio grupo local "Usuarios de escritorio remoto" que podemos encontrar en la consola lusrmgr.msc.

Figura 1: Administradores locales tienen acceso RDP.

El problema surge cuando necesitamos que en una máquina remota puedan acceder únicamente determinados usuarios pero que las cuentas de usuario miembros del grupo Administradores locales no puedan iniciar sesión a través de RDP.

Evitar el Principio de localidad (Movimiento lateral)

En muchas empresas, por razones principalmente administrativas, es habitual encontrase al usuario Administrador (cuenta integrada) habilitado o simplemente la creación de un nuevo usuario que pertenezca al grupo Administradores locales de la máquina. Suele establecerse la misma contraseña para este usuario en todos las máquinas de la organización lo que se conoce como "Principio de localidad" permitiendo con esto la posibilidad de movimientos laterales de un equipo a otro en un contexto privilegiado y facilitando la capacidad de acceso a través de los Servicios de escritorio remoto a otras máquinas que tengan configurado el mismo usuario y contraseña.

Hardening - Restringir el acceso RDP a los Administradores locales

Para aplicar un poco de hardening y establecer unas buenas prácticas ante esta situación. Añadimos los usuarios específicos ya sean locales o formen parte de un dominio al grupo de "Usuarios de escritorio remoto".

Figura 2: Añadir usuarios de forma nominal al grupo local de Usuarios de escritorio remoto.

Establecemos y modificamos una GPO ya sea nivel local o de de dominio en la consola editor de directivas gpedit.msc o gpmc.msc.

Configuración del equipo > Configuración de Windows > Configuración de seguridad > Asignación de derechos de usuario > "Permitir inicio de sesión a través de Servicios de escritorio remoto"

Quitamos o eliminamos el grupo de usuarios "Administradores". En el caso de un dominio se podría establecer un grupo integrado tipo "Opers. de cuentas" o crear uno específico de dominio el cual también pertenezca al grupo Administradores locales de la máquina (esto se podría realizar de forma masiva mediante una GPO a nivel de dominio). También tendremos la posibilidad de elevarnos a un contexto privilegiado haciendo uso del UAC (User Account Control) ejecutando los procesos como Administrador (Ctrl+Shift) u otro usuario que sea miembro del grupo Administradores locales.

De ese modo no se degradaría la posibilidad de seguir administrando las máquinas e iniciar sesión a través de los servicios de escritorio remoto únicamente para aquellas cuentas de usuario que lo necesiten por su operativa de mantenimiento. Minimizando así el riesgo del principio de localidad comentado anteriormente.

Figura 3: GPO - Limitando el acceso a grupos o usuarios a través de Servicios de escritorio remoto.

En la siguiente captura se puede ver como se denegó el acceso a través de RDP a un usuario adminadrian que es miembro del grupo de "Usuarios" y "Administradores" locales de la máquina que, por defecto tendría acceso al inicio de sesión a través de RDP ya que pertenece al grupo de Administradores locales, independientemente de si pertenece o no al grupo específico "Usuarios de escritorio remoto".

Figura 4: Inicio de sesión denegado a través de escritorio remoto para un usuario privilegiado.

Registro del error en el inicio sesión para el usuario local adminadrian correspondiente al evento con ID: 4625.

Figura 5: Evento con ID 4625 - Error de una cuenta al iniciar sesión.

Saludos!

Solución al problema de licencias de conexiones RDP entre Windows Server 2016 y Windows Mobile (RDM), Windows CE o versiones antiguas RDP 5.x / 6.x

Actualmente RDP (Remote Desktop Protocol) está en versión 10.x y versiones más actualizadas que incluyen importantes mejoras de seguridad. Mejoras como una mayor longitud de clave generada por el servidor de licencias RDS 4096 bits con un algoritmo de seguridad SHA256 soportando SSL/TLS y NLA (Network Level Authentication).

Versiones iguales o inferiores a RDP 6.x no soportan las características anteriores. El límite de longitud para las claves es de 2048 bits con algoritmo de seguridad SHA1 (Secure Hash Algorithm 1).

Esta clave se genera en base al método de activación de licencias del administrador de licencias de Escritorio remoto. Si el método empleado es "Web Browser" (Explorador Web) las claves de licencias, se pueden generar un requisitos más bajos que si lo activásemos con otro método, con una longitud de 2048 bits SHA1.

Si aún no tenemos activado el servidor de administración de licencias de Escritorio remoto y queremos tener la compatibilidad entre versiones más antiguas y actuales para establecer conexiones RDP. Seleccionamos la opción de activar por el método de conexión Web Browser.

En caso de que ya tengamos activado el servidor de licencias procederemos del siguiente modo.

En el servidor Windows Server 2016 que recibirá la conexión RDP desde el dispositivo Windows Mobile o Windows CE comprobamos que NLA esté desactivado.

Figura 1: Desactivar NLA (Autenticación a nivel de red) en Windows Server 2016.

⚠️ Hay que tener en cuenta que desactivar NLA implica riesgos de seguridad
Seth: Ataques MITM a conexiones RDP y mitigación

Añadir un rol de instalación de Servicios de Escritorio remoto para VDI (Virtual Desktop Infraestructure).

Figura 2: Añadir rol de instalación de RDS.

En este paso podría ser "Implementación estándar" o "Inicio rápidio".

Figura 3: Implementación estándar para el rol RDS.

Para este escenario será implementación de escritorio basada en sesión.

Figura 4: Implementación de escritorio basada en sesión.

Una vez agregados los servicios RDS. Creamos una colección y no dirigimos a ella.

Figura 5: Colección de host de sesión de Escritorio remoto.

Dentro de las tareas de colección de RDS configuramos las opciones de seguridad para conexiones RDP.

• Nivel de seguridad de protocolo de Escritorio remoto (RDP).
• Nivel de cifrado: Bajo.
• Deshabilitamos NLA.

Figura 6: Configuración de opciones de seguridad para conexiones RDP.

Como comentaba al principio, si elegimos un método de conexión basada en Explorador Web. No es necesario realizar ninguna otra acción y las conexión RDP entre Windows Mobile o Windows CE y Windows Server 2012/2016 estarán funcionales.

De igual modo, seleccionamos el método de conexión por Explorador Web o Web Browser y aceptamos.

Figura 7: Selección del método de conexión "Web Browser". 

Eliminamos los tipos de claves REG_BINARY correspondientes a las claves de certificado X509 del método anterior de licencias RDS. En el registro del servidor de administrador de licencias de Escritorio remoto.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM

• Certificate
• X509 Certificate
• X509 Certificate ID 
• X509 Certificate2

Figura 8: Eliminación de claves de licencias generadas por el administrador de licencias de Escritorio remoto.

¿Por qué eliminar estas claves de certificados del registro? 

Entre versiones de RDP actuales la longitud de clave de certificados es de 4096 bits con un algoritmo de seguridad SHA256, estas claves se generan en la primera instancia de conexión entre un acuerdo entre el nivel de seguridad compatible entre las dos máquinas que establecen la conexión RDP.

El equipo del usuario que mantiene la conexión con el servidor al que se conecta establece la longitud y algoritmo de esta clave, si el equipo que se conecta usa una versión de protocolo reciente no habrá problemas, pero si el equipo cliente se trata de un sistema Windows Mobile o similar este no podrá conectarse debido a que el servidor administrador de licencias no puede generar claves de una longitud y algoritmo inferior a los requisitos mínimos que establece el método de conexión (figura 7), por ese motivo el método de conexión Web Browser tiene unos requisitos menos restrictivos y puede generar claves de longitud más corta y cifrados de menor nivel.

Conexión establecida

Como equipo cliente para este ejemplo usaré un Windows XP SP1 que dispone de versión RDP v5.x (funcionaría igual para Windows Mobile, Windows CE o similares con versiones RDP v5.x o v6.x).

Vemos como la conexión RDP se estableció correctamente. En ese momento Windows XP SP1 estableció el acuerdo de certificados X509 de conexión. Si añadimos la desactivación de NLA y el nivel de cifrado más bajo sin SSL/TLS, la conexión es posible.

Figura 9: Conexión RDP establecida entre versioens RDP antiguas y Windows Server 2016.

Saludos!

Especificar servidores de licencias y modo de licencias CAL de Servicios de Escritorio Remoto (RDS)

Este ejemplo sería aplicable para un entorno en la que disponemos de varios Windows Server. Uno de ellos será el que tendrá el rol instalado de Administrador de licencias de Servicios de Escritorio remoto (RDS - Remote Desktop Services) en el que instalaremos licencias CAL (Client Access Licenses) ya sean por usuario o por dispositivo.

En este caso habrá 5 licencias CAL por usuario para RDS.

Figura 1: Administrador de licencias de Escritorio remoto.

En lo que se centrará esta entrada no será en como activar el servidor de licencias e instalar las licencias CAL para RDS. Sino en como especificamos al resto de servidores que, dependiendo de cada caso, también permitirán conexiones de Escritorio remoto, acepten estas conexiones según el número de licencias CAL disponibles.

Si solo aplicamos esto a la misma máquina que es el administrador de licencias no será necesario nada de esto. 

En caso de una máquina sea el administrador de licencias de Escritorio remoto y queramos que ciertos usuarios se conecten a otro servidor, habrá que especificar en ese otro servidor quien está suministrando las licencias RDS y de que modo se tratan las licencias (por usuario o por dispositivo). 

En el caso de que tengamos más de una máquina que admita conexiones por Escritorio remoto es recomendable emplear objetos de directivas de grupo GPO (Group Policy Object) de AD (Active Directory).

Por lo que mostraré como hacerlo mediante la instalación de roles RDS y como hacerlo por medio de una GPO.

Método 1: Instalación de roles RDS para VDI (Virtual Desktop Infrastructure)

Agregamos un rol para instalar servicios de Escritorio remoto para VDI.

Figura 2: Instalación de roles RDS para VDI.

Una vez tenemos instalado servicios de Escritorio remoto, en la sección de información general > Administrador de licencias > "Seleccionar el modo de licencias de Escritorio remoto".

Figura 3: Selección del modo de licencias de Escritorio remoto.

En la sección de "Administración de licencias de Escritorio remoto". Establecemos (en este caso) que el modo de licencias CAL será "Por usuario" y que el servidor que proporcionará las licencias será otro. Se podrían agregar varios en caso de haberlos y definir su preferencia, subiendo y bajando su posición en la lista.

Figura 4: Selección del servidor de licencias y el modo de licencias CAL (por usuario o por dispositivo).

Método 2: Creanción de una GPO de Active Directory

Previamente se debería crear una OU (Organizational Unit) en Active Directory e incluir dentro de esta los equipos a los que vincularemos la GPO (aunque esto dependerá de la organización jerárquica de cada sitio). 

Abrimos el "Administrador de directivas de grupo" (gpmc.msc) de cualquier controlador de dominio, preferiblemente el DC (Domain controller) primario. Creamos una nueva GPO ya vinculada para la la OU donde estarán las máquinas a las que nos conectaremos por Escritorio remoto.

Editamos la GPO y nos situaremos en el siguiente path jerárquico.

Configuración del equipo > Plantillas administrativas > Componentes de Windows > Servicios de Escritorio remoto > Host de sesión de Escritorio remoto > Licencias

Habilitaremos el estado de dos objetos de directiva.

Figura 5: GPO - Licencias CAL para RDS en host de sesión de Escritorio remoto.

Habilitamos: "Usar los servidores de licencias de Escritorio remoto especificados". Especificando el servidor/es administrador de licencias que se usará.

Figura 6: GPO - "Usar los servidores de licncias de Escritorio remoto especificados".

Habilitamos: "Establecer el modo de licencia de Escritorio remoto". Especificamos si se trata de licencias CAL por usuario o por dispositivo (en este caso sería por usuario).

Figura 7: GPO - Establecer el modo de licencia de Escritorio remoto.

Aceptamos y cerramos el editor de directivas de grupo. Finalmente podemos abrir una cmd de los servidores a los que les estaría afectando esta directiva y actualizar las políticas con un: gpupdate /force. Puede que nos solicité cerrar sesión y volver iniciarla. 

Para comprobamos la aplicación de directivas, desde un cmd con un gpresult /r o simplemente rsop (RSoP - Resultant Set of Policy).

Saludos!

Cambiar puerto de conexión de Escritorio remoto RDP

RDP (Remote Desktop Protocol) protocolo desarrollado por Microsoft para el proceso de conexiones por escritorio remoto (Terminal Services) a otras máquinas ya sea en LAN o WAN.

Este protocolo trabaja bajo el puerto por defecto 3389 TCP y UDP. Por regla general cuando abrimos una ventana de conexiones de escritorio remoto (mstsc.exe) en el campo en el que indicamos el nombre de equipo o dirección IP (local o externa) y no especificamos nada más, este establece la conexión RDP por defecto por el puerto 3389 TCP.

Si queremos llegar a cambiar este puerto por defecto tendríamos que hacer principalmente dos configuraciones manuales, las cuales serían cambiar un valor del registro de Windows y permitir en el Firewall de Windows las conexiones entrantes por el nuevo puerto establecido.

Pero para verificar todo empecemos por el principio comprobando las configuraciones para permitir conexiones remotas.

En propiedades del sistema > Acceso remoto verificamos que tengamos marcado "Permitir las conexiones remotas a este equipo" y que por seguridad tengamos marcado el checkbox de permitir autenticación a nivel de red (NTLM).

Comprobamos que los usuarios permitidos para establecer este tipo de conexiones está permitido o simplemente seleccionamos aquellos usuarios que queramos permitir conexión remota al equipo y que estos tengas una password con la que poder autenticarse sobre NTLM, estos usuarios no tienen por que ser administradores.

Figura 1: Configuración de escritorio remoto en sysdm.cpl.

Comprobamos que el servicio RDCS (Remote Desktop Connection Service) está iniciado. Será el encargado de gestionar a nivel de sistema la conexión remota.

Figura 2: Servicio RDCS iniciado.

Comprobamos que el propio servicio de Terminal Services (TermService) está iniciado. Será el encargado de permitir la conexión.

Figura 3: Servicio TermService iniciado.

Por último comprobamos el WFAS (Windows Firewall Advanced System) y vemos que una vez que habilitamos opción de permitir conexiones y que el servicio está iniciado, este ya incluye estas tres reglas por defecto en el Firewall, vemos que por defecto usan tanto el protocolo TCP como UDL para el puerto de conexión 3389.

Estas reglas a priori no se pueden modificar ya que vienen definidas por por el sistema.

Figura 4: Reglas por defecto para RDP por conexión del puerto 3389.

Llegamos a la parte que realmente hace título a este artículo, como cambiar el puerto por defecto 3389 a otro puerto que deseemos.

Abrimos un registro de Windows y nos vamos al siguiente path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Buscamos el valor DWORD "PortNumber", lo abrimos e introducimos el valor en hexadecimal correspondiente al valor decimal que queramos dar al nuevo puerto. Aunque cambiemos a base decimal, tendremos que guardar el valor DWORD como hexadecimal.

En este caso modifiqué el puerto por defecto 3389 por el 60500 (en hexadecimal: ec54).

Figura 5: Cambiando el puerto de conexión por defecto de escritorio remoto.

Una vez lo cambiemos tendremos que permitir la entrada del nuevo puerto modificado. Esto lo haremos en modo avanzado del Firewall y agregando nuevas reglas de entrada de conexión tanto para protocolo TCP como para UDP para el mismo puerto. De modo que quede como puerto específico el puerto modificado, en mi caso, continuando el ejemplo el puerto 60500.

Figura 6: Agregamos el nuevo puerto de entrada en el Firewall.

Para usar esta conexión de forma local en nuestra red interna sería suficiente, pero si queremos hacerlo a través de una conexión de otra red, tendremos usar un DNS dinámico (DDNS).

Con nuestro DDNS ya configurado, tendremos que acceder al router que tengamos y en la sección NAT (NAT Forwarding) para la redirección de puertos, tendremos que abrir tanto para protocolos TCP y UDP el nuevo puerto establecido, continuando el ejemplo anterior, serían el 60500.

La redirección de puerto se suelen definir por primer y último puerto externo y primer y último puerto interno e indicar la dirección IP local a la que va redireccionada los puertos.

De modo que por ejemplo, si lo preferimos podemos indicar a nuestro router que abra el puerto externo 55555 y que después nos redirija al puerto interno de nuestro equipo 60500.

Figura 7: NAT Forwarding en router.

La visualización del router que se muestra en las capturas anteriores es solo un ejemplo de mi router SOHO ya que la interfaz gráfica de cada router suele ser distinta de uno a otro.

Para comprobar que el puerto está realmente abierto entre el router y el firewall de nuestro equipo local y queremos saber si es accesible desde otra red externa, lo comprobamos con algún escaneador de puertos online.

Figura 8: Escaneando el puerto 60500 en estado: abierto.

Para conectarnos usando RDP por un puerto específico establecido, simplemente introducimos la dirección IP interna/externa o DDNS seguido de : (dos puntos) y el número de puerto en cuestión.

Figura 9: Conexión por escritorio remoto con un puerto específico.

Por último podemos ver el resultado de este ejemplo en la siguiente captura. Observando que el puerto de conexión es el 60500 y el cliente lo estableció con uno aleatorio (65445). Con netstat podemos ver el PID y el servicio establecido para la conexión TermService.

Figura 10: Ejemplo de conexión establecida cliente/servidor con puerto RDP modificado.

Conclusiones

Para cambiar el puerto de Terminal Service simplemente nos bastaría con cambiar la clave de registro correspondiente (figura 5) y a continuación abrir ese determinado puerto para TCP/UDP en la configuración avanzada del Firewall de Windows (figura 6).

Saludos!