Servidor dedicado en el entorno de la nube - Inicio de sesión remoto SSL vs VPN dedicada

3

Gracias por tomarse su tiempo para analizar esta pregunta.

Fondo

Tengo mi sitio web alojado en un servidor dedicado en la nube. El servidor es una máquina con Windows 2008 R2. Para publicar archivos FTP en el servidor. Para el mantenimiento general, me conecto de forma remota a los servidores utilizando un RDP sobre SSL (¡Mi contraseña es segura!). También tengo una VPN dedicada entre mis instalaciones y este servidor.

El problema

¿Qué tan seguro es su caja estándar de Win 2008 en Internet con RDP habilitado? Estoy seguro de que, en teoría, podría ser brutal forzado.

Preguntas

  • ¿Qué tan seguro es el servidor siempre que el proveedor de alojamiento realice la parcheando etc?
  • ¿Es seguro RDP?
  • Podría restringir el servidor para que solo acepte sesiones RDP de la VPN dedicada en su lugar, pero esto sin duda reducirá la flexibilidad de los administradores que acceden al servidor desde varias ubicaciones.
  • Además, el RDP a través de esta VPN que hemos implementado es muy lento.

Enigma

Asegurar esta máquina al permitir solo las conexiones entrantes desde la VPN dedicada suena como la forma más segura de hacerlo. Simplemente no quiero perder la flexibilidad de conectar desde múltiples ubicaciones.

    
pregunta Intrigue 16.03.2012 - 02:42
fuente

3 respuestas

1

El riesgo de mantener ese puerto abierto se demostró con el reciente boletín de seguridad MS12-020. El exploit aquí ataca al servicio en sí que es muy serio. RDP ha resistido bien los ataques hasta el momento porque una vez que inicia sesión tiene una sesión nueva iniciada bajo ese usuario. Una contraseña segura suele ser suficiente.

Pero en este caso, el servicio en sí fue atacado, lo que le da al código de explotación un acceso muy privilegiado. Así que restringiría las direcciones IP tanto como sea posible. Si eso no funciona, al menos usar un puerto no estándar ayudaría.

Es posible que desee considerar el uso de OpenSSH o OpenVPN como métodos de acceso alternativos.

    
respondido por el Mark Burnett 30.03.2012 - 11:13
fuente
1
  

Simplemente no quiero perder la flexibilidad de conectar desde múltiples ubicaciones.

La solicitud de flexibilidad generalmente limita la seguridad. Especialmente si pretendes acceder desde múltiples ubicaciones. Sin embargo, no soy un experto en RDP y VPN, pero también podría tener en cuenta los certificados del lado del cliente.

  

¿Qué tan seguro es el servidor siempre que el proveedor de alojamiento realice el parcheo, etc.?

Depende ya que, en general, un proveedor de alojamiento está interesado en no tener malas relaciones públicas debido a los agujeros de seguridad. Sin embargo, muchos problemas de seguridad son causados por una mala configuración. Aún hoy, una cantidad asombrosa de proveedores no configuran correctamente sus sistemas.

  

¿Es seguro RDP?

Como dije, no conozco bien RDP. Pero en general yo diría lo anterior (mala configuración). Wikipedia reclama algunos problemas .

  

Además, el RDP a través de esta VPN que hemos implementado es muy lento

Esta no es una pregunta real, sin embargo, esto no es muy sorprendente. La seguridad se logra a menudo mediante el uso de criptografía fuerte. Esta criptografía puede aumentar el tráfico y el esfuerzo de cálculo.

    
respondido por el mkind 19.09.2012 - 10:43
fuente
1

RDP es un protocolo de larga data que ha pasado por muchas versiones. Las versiones recientes del protocolo encapsulan un túnel SSL / TLS a través del cual se realizan los intercambios reales (RDP tiene su propio formato de envío paquetes, y, dentro de ese formato, se envían registros SSL). Esto debería ser seguro siempre y cuando la capa de autenticación (es decir, el inicio de sesión basado en contraseña) sea segura (lo que significa "una contraseña lo suficientemente aleatoria") y el Servicio de escritorio remoto en la máquina no se puede explotar de manera remota agujeros Desafortunadamente, el código RDS puede tener, como cualquier otro software, desbordamientos de búfer y debilidades similares, como se demostró .

Microsoft tiene su propia "solución" para eso, llamada Servicios de Terminal Server Puerta de enlace . Es un servidor adicional que escucha en el puerto 443 las conexiones SSL / TLS entrantes; TSG autentica al cliente (con una contraseña o un certificado) y luego reenvía los paquetes de estilo RDP al servidor que ejecuta los Servicios de Escritorio Remoto. Hay bastantes capas aquí:

  • conexión SSL / TLS del cliente al TSG.
  • En esos túneles SSL / TLS, algunos paquetes de estilo RDP, se envían al servidor que ejecuta RDS.
  • En estos paquetes, los registros SSL / TLS para el túnel SSL / TLS del cliente al servidor RDS.
  • En ese túnel SSL / TLS, los paquetes RDP reales que codifican las pulsaciones del teclado, los clics del mouse y las actualizaciones de pantalla.

¿Cuáles son los beneficios del TSG? Principalmente, este es un nuevo servidor que es supuestamente más simple y con un historial de implementación más corto, luego teóricamente con menos errores; lo más probable es que el código externo SSL / TLS (el que se ejecuta por el TSG) sea el mismo código que el utilizado por IIS para servir los sitios web de HTTPS, y la implementación que debe ser razonablemente sólida ya que tiene Amplia exposición a internet y sigue vivo. Además, TSG escucha en el puerto 443, lo que facilita la tarea de los clientes en entornos con cortafuegos restrictivos (el puerto 443 es uno de los puertos con más probabilidades de estar autorizado para las conexiones salientes).

Desde el punto de vista de Microsoft, TSG tiene la ventaja adicional de ser otro servidor y software específico, por lo que son licencias adicionales. No estoy seguro de que pueda poner TSG y el RDS de destino en la misma máquina (el Servicio de escritorio remoto tiende a no permitir las conexiones de "localhost").

    
respondido por el Thomas Pornin 19.09.2012 - 15:11
fuente

Lea otras preguntas en las etiquetas