¿El acceso indirecto a una computadora es tan malo como directo?

6

Estoy implementando un sistema ERP basado en la web para un cliente, de modo que tanto el servidor como las máquinas cliente estarán dentro de la intranet del cliente. Se me recomendó que no permitiera que la máquina del servidor se conecte a Internet, pero los clientes no tendrán esta restricción. Sin embargo, necesito acceso a ambos para proporcionar soporte, así que estoy planeando usar TeamViewer para acceder al cliente (para ayudar a los usuarios directamente a solicitud) y SSH desde la máquina cliente a la máquina del servidor (para realizar actualizaciones, por ejemplo).

[my machine] ---TeamViewer---> [customer's client] ---SSH---> [customer's server]

Mi pregunta es: ¿esta configuración es tan mala como acceder al servidor directamente a través de SSH? Veo algunas ventajas en la conexión indirecta (solo será accesible cuando el empleado de un cliente abra TeamViewer, estará sentado allí viendo todo lo que sucede e incluso puede escribir las contraseñas para mí, para que no se transmitan a través de Internet alguna vez), pero me pregunto si hay inconvenientes que no puedo prever.

Si ambos enfoques son igualmente seguros (in), solo permitiré SSH directo al servidor, ya que es más simple. Y si, por cualquier motivo, esta configuración indirecta hace que todo menos sea seguro, puedo dar un paso más y recomendar al cliente que bloquee el acceso de SSH desde las máquinas donde está instalado TeamViewer.

Actualizar : viendo las respuestas / comentarios a continuación, creo que necesito aclararme un poco. Mi objetivo aquí es hacer que el servidor sea más seguro que los clientes. La configuración exacta es responsabilidad de mi cliente, no de la mía, pero ya que estoy implementando mi producto en su red, y necesito acceder a él de manera remota para proporcionar mantenimiento, tengo que asesorarlos sobre las ventajas y desventajas de cada configuración. Les preocupa que un servidor con acceso a Internet sea más vulnerable que solo uno (directamente) accesible desde su red interna, pero sospeché (y los comentarios a continuación lo confirman) que no siempre es así.

No puedo asegurar adecuadamente a los clientes, estarán ejecutando una variedad de programas fuera de mi control, incluido un escritorio remoto obligatorio, TeamViewer u otro, por lo que la opción "natural" sería rechazar las conexiones SSH entre los clientes y el servidor. OTOH, un cliente comprometido no le da acceso automáticamente al servidor, ya que aún tendría que autenticarse (por ejemplo, utilizando la autenticación de clave y almacenando la clave fuera de línea, en una unidad flash USB). Pero estoy de acuerdo en que no es una buena idea.

Otra opción sería configurar un cliente muy seguro y usarlo como un proxy para el servidor (no permitir que todos los demás). Sin embargo, mi pregunta original vuelve a aparecer: ¿no tiene sentido hacerlo, en lugar de tener un servidor orientado a Internet?

    
pregunta mgibsonbr 31.01.2012 - 04:16
fuente

1 respuesta

6

Si el cliente del cliente es crítico para la seguridad, no configure TeamView para conectarse. Si el incumplimiento de la intranet del cliente pone en mayor riesgo el servidor del cliente, no utilice el TeamView.

Una lectura rápida muestra que TeamView puede usar UPnP (Plug and Play universal).

Hay * 29 CVE * s (¡Se enumeran las vulnerabilidades y exposiciones comunes para uPnP!

Si no sabe exactamente cómo funciona la autenticación y el enrutamiento de un producto, no lo use para actividades o infraestructura críticas para la seguridad.

Cualquier cosa que sea más compleja tiene el riesgo de tener más errores, problemas y vulnerabilidades. Entonces cuando mencionaste que ssh era más simple tenías la idea correcta.

Si está usando ssh para acceder a la infraestructura crítica de seguridad, use la autenticación de clave en lugar de la autenticación de contraseña.

    
respondido por el this.josh 31.01.2012 - 07:34
fuente

Lea otras preguntas en las etiquetas