La última versión RDP utilizó NLA, CredSSP y TLS para asegurar el proceso de autenticación. Suena como seguro pero en realidad lo hace lo suficientemente seguro. Sabía que la versión anterior de RDP es una vulnerabilidad a los ataques de intermediarios, ¿se está eliminando este ataque?
Con la última versión es posible integrar seguridad ssl / tls y mecanismos de autenticación de dos factores. Si la conexión se utiliza para conectarse a un portal de servicios de escritorio remoto (es decir, una puerta de enlace de RD), se puede aplicar la autenticación a nivel de red. Con una infraestructura adecuadamente planificada e implementada con una infraestructura de clave pública, es posible fortalecer la seguridad. NLA proporciona más apoyo para fortalecer la seguridad. También es posible utilizar métodos de autenticación de 3 factores. Como regla general, cada mecanismo depende del perfil de seguridad actual y la superficie de ataque. Depende de las capacidades, implementaciones y mejoras continuas. Por lo tanto, con solo usar la última versión, todavía no puede garantizar la seguridad si no cumple con sus estándares.
Nota: Todavía podría haber otros problemas, como vulnerabilidades con certificados y el método CRL, exportación de pkey, etc. (si existen).
Las versiones recientes de RDP admiten SSL / TLS . El propio RDP tiene su propio formato para transferir paquetes de datos; dentro de estos paquetes, clientes y servidores suficientemente recientes pueden transportar los registros TLS que codificarán un túnel al que se enviarán los datos reales (incluida la autenticación). Esto es razonablemente seguro, en la medida en que el cliente y el servidor no obstaculizan la implementación o hacen mal uso de los certificados (consulte esta respuesta para una discusión sobre el tema).
Además, el uso de TLS es opcional y está sujeto a negociación entre el cliente y el servidor; Posiblemente, un atacante que intente un ataque de hombre en el medio podría alterar los primeros paquetes, por lo que como para simular una falta de soporte de TLS en ambos lados, lo que lleva a una conexión sin TLS. Depende de la implementación del cliente detectar esta ocurrencia y abortar la conexión (o generar una advertencia y dejar que el usuario aborte).
Se agregó soporte TLS en RDP 5.2. Las implementaciones gratuitas de código abierto del protocolo RDP generalmente no lo admiten.
Otra forma de proteger una sesión RDP mediante TLS es Gateway de escritorio remoto (anteriormente conocido como Terminal Services Gateway) que encapsula todo en un túnel SSL / TLS. Esto es acumulativo con otras características de RDP, por lo que puede terminar con TLS-in-RDP-in-TLS. La puerta de enlace es un servicio específico disponible desde Windows Server 2008, y solo el cliente de Microsoft parece admitirlo (según Wikipedia, ni siquiera el puerto MacOS del cliente de Microsoft puede usarlo).
Lea otras preguntas en las etiquetas authentication windows rdp