SSH a IP en lugar de a un nombre de host completo: ¿esto reduce el riesgo de MITM?

Navega tus respuestas
2

Estoy aplicando la administración de la configuración a un VPS alojado por una compañía de alojamiento de VPS. Cambiar la empresa de alojamiento no es una opción, desafortunadamente.

Este VPS tiene las siguientes propiedades:

  1. cuando se crea una nueva imagen o se vuelve a crear una imagen, genera un nuevo par de claves público / privado SSH aleatorio;
  2. ni la interfaz web de la empresa de alojamiento de VPS, ni la API de la empresa de alojamiento de VPS, proporcionan una manera de reemplazar ese par de claves por un par de claves conocido;
  3. ni la interfaz web de la empresa de alojamiento de VPS, ni la API de la empresa de alojamiento de VPS, proporcionan una manera de obtener la huella digital de la clave pública de ese par de claves;
  4. el host VPS no tiene registros DNS firmados (por ejemplo, DNSSEC);
  5. la interfaz web de la empresa de alojamiento de VPS y la API do permiten recuperar la dirección IP del VPS;
  6. la interfaz web y la API de la empresa de alojamiento de VPS do utilizan TLS y tienen un certificado válido de una CA decente;
  7. la interfaz web de la empresa de alojamiento de VPS sí permite que se cargue la clave pública de un cliente SSH, después de lo cual cada vez que se vuelva a crear la imagen del VPS, agregará esa clave pública a una cuenta específica .ssh/authorized_keys archivo.

El primer punto anterior es normalmente algo bueno, pero junto con los dos puntos siguientes, significa que es imposible para la herramienta de administración de la configuración cuando intenta iniciar sesión en el VPS a través de SSH por primera vez después de Se ha vuelto a crear una imagen del SPV para asegurarnos de que la conexión se esté realizando en el medio. En otras palabras, la herramienta de administración de la configuración puede, en el mejor de los casos, usar trust-on-first-use ("TOFU") Enfoque.

Normalmente, utilizaría el nombre de host completo de un VPS como identificador del VPS en la herramienta de administración de la configuración, y evitaría la necesidad de TOFU obteniendo por separado la huella digital de la clave pública SSH del VPS fuera de banda (por ejemplo, a través de una API segura) . Sin embargo, con este VPS en particular, el último paso no es posible.

Como tal, la conexión a través del nombre de host totalmente calificado parece correr el riesgo de un ataque MITM, por ejemplo. a través de falsificación de DNS , aprovechando el hecho de que la herramienta de gestión de la configuración tendría que ser TOFU.

Me parece que la opción más segura aquí sería obtener la dirección IP del SPV de la API a través de HTTPS, y tener la herramienta de administración de configuración SSH para eso. Al menos esto evitaría el riesgo de suplantación de DNS.

(Además, aprovechar el punto 7 anterior significará que incluso si un servidor malicioso se hace pasar por el VPS, al menos el servidor malicioso no obtendrá la contraseña o la clave privada del cliente).

¿Estoy en lo cierto acerca de esto? ¿Hay otros riesgos, o mejores soluciones, que estoy pasando por alto?

    
pregunta sampablokuper 26.01.2018 - 22:20
fuente

1 respuesta

2

En general, usar la API de la compañía de VPS es una buena idea, dada su confiabilidad adecuada y también los recursos suficientes para implementar y mantener eso de su lado. Después de todo, la funcionalidad de administración de claves SSH puede agregarse a dicha API tarde o temprano (tal vez incluso a petición de la función, ¿quién sabe?).

Sin embargo, el envenenamiento de la memoria caché del DNS solo es, por decirlo suavemente, un ataque raro y complejo. Y en su caso particular, también hay una ventana de ataque bastante corta (entre un VPS se crea y se asigna un FQDN, y el primer intento de inicio de sesión), que requiere una sincronización perfecta o un conocimiento interno (o ambos) del lado de un atacante . Además, en la mayoría de los casos, los servidores virtuales tienen asignados FQDN más bien aleatorios y oscuros, y un atacante también debe adivinarlo.

A continuación, lo más probable es que los servidores DNS de la compañía de VPS recuperen el FQDN de su VPS desde un archivo de configuración local o una base de datos de algún tipo. Asumiendo que; si su ISP y todos los ISP de tránsito entre su resolutor y la red de la compañía VPS no están realizando ningún ataque MitM malvado; si puede usar los servidores DNS de la compañía de VPS directamente para resolver el FQDN de un VPS recién creado; entonces el único lugar en la red donde el envenenamiento de caché de DNS podría aplicarse teóricamente es a su resolutor. Por lo tanto, dada la naturaleza del ataque de envenenamiento de DNS en la actualidad, sería bastante fácil detectar y mitigar correctamente un intento de envenenamiento de DNS.

Además, si su modelo de amenaza incluye ataques de ese tipo, tenga en cuenta que el enrutamiento de Internet no es más seguro que el DNS . Por lo tanto, podría ser una buena idea configurar un VPS dedicado en la misma ubicación donde se asignarán todos los servidores virtuales posteriores, de modo que el primer uso de un VPS recién creado sea desde una máquina en el mismo segmento de red, eliminando una posibilidad de secuestrar la dirección IP asignada.

La suplantación de identidad de ARP también puede ser perjudicial aproximadamente de la misma manera, aunque depende en gran medida de la arquitectura de red virtual respectiva.

A pesar de todo eso, como he señalado, esos ataques son bastante hipotéticos para un servicio promedio orientado a Internet. Su experiencia puede ser diferente; sin embargo, es mejor que me centre en la supervisión y los informes adecuados para garantizar que, en caso de que ocurra algo así, lo sepan tan pronto como sea posible.

    
respondido por el ximaera 27.01.2018 - 15:18
fuente

Lea otras preguntas en las etiquetas

¿Es posible tener máquinas diferentes para el mismo dominio, con certificados diferentes? ¿Cómo puede Google Chrome actualizarse en C: \ Archivos de programa?