Tengo una especie de conflicto con el Ingeniero Líder de Seguridad de mi empresa. Dice que Protocolo de escritorio remoto (RDP) no es lo suficientemente seguro y que deberíamos usar TeamViewer en su lugar. Utilizamos RDP no solo para acceder a los recursos locales dentro de nuestra red corporativa, sino también para acceder a los recursos (que ejecutan Windows 2012+) en el alojamiento en la nube.
En ambos escenarios, ¿qué tan seguro es usar RDP?
Creo que Teamviewer es un servicio de proxy para conexiones VNC tunnelled. Por lo tanto, la primera consideración de seguridad con respecto a ese servicio es que es MITM'ed por diseño . Ha habido sugerencias de que el servicio estaba comprometido hace un par de meses .
(Tenga en cuenta que aunque VNC utiliza cifrado, el intercambio completo no está, por defecto, encapsulado, pero es trivial configurar un túnel SSL / ssh / VPN).
La siguiente consideración es que significa instalar software de terceros en sus sistemas, pero luego, si está ejecutando una plataforma de Microsoft, entonces ya está ejecutando software de múltiples proveedores que probablemente no esté cubierto por su software de administración de parches; mantener el software actualizado es uno de los medios más efectivos para proteger sus sistemas.
Siempre que su conexión RDP esté usando SSL, debería ser al menos tan segura como Teamviewer, y en mi humilde opinión, mucho más.
Editar: Según los comentarios, parece que hay una combinación de opciones de configuración en la edición empresarial de TeamViewer, lo que podría reducir mis preocupaciones. Como nunca los he usado, no puedo darles una evaluación sobre ellos y qué tan bien funcionan. Según los comentarios, podría ser una solución defectuosa.
Soy un administrador de servidor (Windows y Linux) y bloquearía cualquier intento de instalar TeamViewer en los servidores por los siguientes motivos:
Para mí, hay demasiadas banderas rojas.
Nuestros servidores se encuentran en una subred aislada donde el firewall / switch solo permite puertos preconfigurados y permite a los usuarios conectarse con VPN a esta subred con su nombre de usuario / contraseña. Seguimos un enfoque de defensa en profundidad : solo ciertos grupos obtienen privilegios para conectarse a la VPN con su usuario. Dentro de la VPN, pueden usar RDP o SSH. Si hubiera una vulnerabilidad de seguridad en RDP, el atacante primero necesitaría acceso a VPN o LAN. Esto significaría que serían nuestro personal de TI (en el que una empresa debe confiar hasta cierto punto), tener acceso a VPN o acceso físico o piratear uno de los servidores. Acceso físico significa entrar en el centro de datos; Si esto sucede, hay mayores preocupaciones. Lo mismo ocurre con alguien del personal de TI que va postal. Si infringen uno de los servidores, también necesitarán una vulnerabilidad de escalada de privilegios para atacar porque son cuentas bloqueadas. Para el acceso VPN, necesitaría una vulnerabilidad en la VPN u obtener la cuenta de alguien con privilegios de VPN.
Y todo esto solo en el caso de que exista una vulnerabilidad de RDP. Lo más probable es que solo sea un atacante clasificado como una amenaza persistente avanzada ( APT ), es decir, alguien que usa técnicas sofisticadas para atacar tu sistema específico en un ataque sostenido, tendría un exploit de 0 días para RDP y es más probable que tal atacante podría usar métodos / vulnerabilidades más fáciles en otro software.
Además de las otras excelentes respuestas, TeamViewer ofrece menos seguridad física porque requiere que la pantalla esté desbloqueada para facilitar una sesión remota.
Es decir, cualquier persona que pase por el teclado y el monitor de una sesión administrada de forma remota puede observarlo y posiblemente controlar la sesión en caso de que el usuario remoto no esté prestando atención.
Tenga en cuenta que aparece posible para borrar la pantalla después de la instalación de un controlador de pantalla, sin embargo, esto debe hacerse en Cada conexión deja una ventana de oportunidad.
Además, ahora confía en la seguridad de la pantalla de TeamViewer en lugar de la seguridad de la pantalla de bloqueo de Windows; asegúrese de estar cómodo con eso.
Para empezar, no sé nada acerca de TeamViewer, así que no intentaré comentarlo.
Los servidores RDP históricos usaron "Seguridad RDP", que es de hecho un protocolo roto y vulnerable a MITM. No hagas eso Incluso 2003r2 puede hacer TLS para RDP, por lo que no hay una razón moderna por la que deba verse obligado a utilizar la seguridad RDP.
Los servidores modernos admitirán TLS, por lo que la seguridad de RDP está directamente relacionada con la seguridad de TLS. Con los ajustes de registro, puede imponer un subconjunto de TLS que le guste: forzar a 1.2, restringir a ciertas suites de cifrado, quizás otras cosas.
También, hay un ángulo específico de RDP aquí en que el servidor puede restringir las conexiones solo a aquellas que admiten la "Autenticación de nivel de red". NLA aún usa TLS, es solo un cambio de protocolo para realizar la autenticación antes en el intercambio. Creo que esto está destinado a proteger contra un ataque de denegación de servicio en el que los usuarios no autenticados intentan conectarse repetidamente sin autenticarse.
Si tuviera que descifrar y rastrear una RLS TLS Sesssion utilizando NLA, vería lo siguiente:
Suponiendo que está utilizando una versión moderna de RDP y la configura correctamente (por ejemplo, habilite NLA, ordene los certificados adecuados), el principal riesgo de exponerlo directamente a Internet tiende a ser el problema de exponer una autenticación de nombre de usuario / contraseña El sistema a Internet, es decir, permite que los atacantes intenten forzar con fuerza las Cuentas de Active Directory (suponiendo que se trata de un entorno de AD y no de un conjunto de servidores independientes).
Esto no es bueno, ya que terminas con un riesgo DoS con un bloqueo de cuenta establecido o un riesgo de acceso no autorizado sin un bloqueo de cuenta establecido (alguien siempre elegirá una contraseña débil o usará una que sea violada en otro lugar), así que si está exponiendo RDP directamente, recomendaría la autenticación de dos factores a los usuarios a los que se les permita el acceso a través de este mecanismo.
En cuanto a TeamViewer, no existe un riesgo de acceso directo, pero usted confía en ellos como organización y se ha señalado en otras respuestas que han tenido problemas de seguridad recientemente.
Ampliaré Daniel Bungert explicando los protocolos involucrados y por qué trabajan juntos. Habiendo escrito un proxy MitM para RDP, estoy muy familiarizado con el funcionamiento interno de la mayoría de los protocolos involucrados. (Más de lo que me gustaría ser ...)
Puede configurarlo para que solo opere a través de TLS. Esto ofrece una gran seguridad por derecho propio, cada mensaje se envuelve con el cifrado TLS. Hay políticas de grupo que puede administrar que establecerán los protocolos de cifrado TLS permitidos. Puede usar esto para especificar solo aquellos con longitudes de clave o algoritmos que considere adecuados. Estas son configuraciones generales de Windows y no rdp específicas. Su única preocupación sería que los usuarios acepten certificados incorrectos, en cuyo caso es posible un ataque MitM.
Sin embargo, puede configurarlo para que funcione solo con la autenticación NLA. Específicamente, esto usará CredSSP con NTLM. Esto evita MitM porque el certificado utilizado en la capa TLS se usa (junto con otras cosas) para cifrar la contraseña. Entonces ya no puede simplemente reenviar la contraseña cifrada porque el servicio rdp de destino no autenticará un hash generado con un certificado que no sea el suyo. La razón por la que funciona mi mitm es porque conocemos las contraseñas que se utilizan para conectarse al proxy, y con eso podemos extraer información y generar un nuevo hash para el servicio rdp de destino. Un proxy rdp malicioso no tendrá esa ventaja.
Por lo tanto, con TLS y NLA configurados, rdp está a salvo de los usuarios que pueden aceptar certificados erróneos. Esto contrarresta las preocupaciones de Overmind sobre los ataques de mitm.
Iría con algún tipo de VPN desde la computadora remota del usuario a un servidor de seguridad en el trabajo, y luego ejecutaría RDP sobre ese enlace cifrado.
El problema al dejar un puerto abierto es que eventualmente se encuentra, y tendrá intentos de inicio de sesión de fuerza bruta. O eso solo ralentizará su entorno o provocará el bloqueo de las cuentas, o encontrarán un nombre de usuario con una contraseña débil (siempre hay un usuario ...)
Puede explorar la autenticación de 2 factores con aplicaciones para teléfonos inteligentes, tokens de hardware o contraseñas de un solo uso preimpresas.
Recuerde, la seguridad es lo opuesto a la comodidad.
Esto comenzó como un comentario.
Es importante señalar la pregunta "Quién tiene la culpa". Si utiliza un servicio de terceros y ellos no pueden proporcionar, es su falta de proporcionar. Si usas algo en casa y falla, ahora es culpa de la casa. Tales distinciones tienen mucho peso. Puede que no signifique nada para la seguridad real, pero a veces eso puede quedar al margen.
Por ejemplo, si necesita obtener la certificación para un contrato, y esa certificación dice algo a los efectos de:
Debe usar métodos de administración remota seguros, no se permiten métodos de administración remota sin cifrar. Se permite la contratación con un tercero para prestar servicios. El cifrado debe ser foo fuerza y requisitos de la barra. Los servicios comunes que cumplen estos requisitos son LogMeIn y TeamViewer. Los servicios comunes que no cumplen con estos requisitos son GoToMyPC y VNC simple.
Entonces se podría tomar la decisión de usar Team Viewer.
Luego está el riesgo para el negocio. Se podría argumentar que Teamviewer tiene menos riesgo, porque está utilizando un servicio de buena fe que se supone que es seguro. Al mismo tiempo, RDP puede ser un riesgo mayor porque ahora está defendiendo el conocimiento de su equipo frente a la comprensión aleatoria de personas.
Al final, si bien esto no tiene ninguna conexión real con la seguridad real, es importante recordar que las empresas no hacen seguridad porque les hace dinero (normalmente). Lo hacen como mitigación de riesgos y porque tienen que seguir haciendo dinero. El uso de un servicio de terceros puede eliminar parte del riesgo para la empresa.
Como se mencionó, debe utilizar el cifrado RDP + si es posible. Pero, no he visto ninguna mención de medidas de seguridad básicas contra ataques (brutos o de otro tipo) en las respuestas proporcionadas.
CUALQUIER el software / puerto (s) que se deja abierto al público será escaneado / encontrado. Período. RDP o no. Encriptación o no. Si el acceso público no es necesario, ¿por qué permitirlo?
Crear y administrar una lista de 'permitidos' basada en Bloques de IP puede llevar mucho tiempo y ser una molestia (si muchos hosts acceden), pero no debe pasarse por alto. Ya sea 1 IP o cientos de IP de red separadas.
Usted mencionó un servidor basado en 'nube'. Entonces, por ejemplo, en AWS / ec2, uno debe usar un Grupo de seguridad EC2 para permitir algunas redes IP o de administración y negar el resto. La mayoría de los proveedores tienen métodos similares.
El punto es (y además de las respuestas proporcionadas): RDP sería mi elección, pero nada perfecto. Se vuelve aún más imperfecto si no está bloqueando redes no deseadas.
En RDP, puede realizar un ataque MiTM y luego todo el tráfico del servidor RDP al cliente RDP pasará por nuestro sistema MiTM. Por eso no se considera seguro.
En cuanto a Teamviewer, debes confiar en un tercero, que no es la opción que muchos elegirían.
En cuanto al mejor de los casos, debe configurar su propia VPN basada en certificados.
Lea otras preguntas en las etiquetas rdp windows-server