¿Por qué usar SSH y VPN en combinación?

Mi empleador me exige que primero inicie sesión en una VPN, y solo entonces puedo SSH en los servidores. Pero, dada la seguridad de SSH, ¿es una exageración de VPN?

¿De qué sirve una VPN en términos de seguridad si ya estoy usando SSH ?

El razonamiento detrás de su configuración actual es probablemente una combinación de las siguientes tres razones.

La VPN es una solución de seguridad para fuera de la red de su empresa (Ver # 1 a continuación) . Sin embargo, SSH podría ser una segunda capa de seguridad fuera de la red de su empresa ... pero su objetivo principal es asegurar el tráfico dentro de la red de su empresa (consulte el # 2 a continuación) . La VPN también es necesaria si el dispositivo en el que está intentando ingresar SSH está utilizando una dirección privada en la red de su empresa (consulte el # 3 a continuación) .

1. VPN crea el túnel a la red de su empresa a través del cual usted transfiere datos. Por lo tanto, nadie que vea el tráfico entre usted y la red de su empresa puede ver realmente lo que está enviando. Todo lo que ven es el túnel. Esto evita que las personas que están fuera de la red de la empresa intercepten su tráfico de una manera útil.

2. SSH es una forma cifrada de conectarse a dispositivos en su red (a diferencia de Telnet, que es texto claro). Las compañías a menudo requieren conexiones SSH incluso en una red de la compañía por razones de seguridad. Si instalé malware en un dispositivo de red y usted hace un telnet en ese dispositivo (incluso si atraviesa un túnel VPN, ya que el túnel VPN generalmente termina en el perímetro de la red de una empresa), puedo ver su nombre de usuario y contraseña. Si está utilizando SSH, entonces no puedo.

3. Si su empresa está utilizando el direccionamiento privado para la red interna, entonces el dispositivo al que se está conectando puede no ser enrutable a través de Internet. Conectarse a través de un túnel VPN sería como si estuvieras conectado directamente en la oficina, por lo tanto, utilizarías el enrutamiento interno de la red de la compañía que no sería accesible fuera de la red de la compañía.

SSH es un objetivo extremadamente popular para los intentos de fuerza bruta. Si tiene un servidor SSH directamente en Internet, en cuestión de minutos verá intentos de inicio de sesión con todo tipo de nombres de usuario (y contraseñas), a menudo miles por día, incluso en servidores pequeños e insignificantes.

Ahora es posible fortalecer los servidores SSH (los tres mecanismos principales requieren una clave SSH, denegando el acceso raíz a SSH y, si es posible, restringiendo las direcciones IP que incluso pueden conectarse). Aún así, la mejor manera de fortalecer un servidor SSH es ni siquiera tenerlo disponible en Internet.

¿Por qué eso importa? Después de todo, SSH es fundamentalmente seguro, ¿verdad? Bueno, sí, pero es tan seguro como lo hacen los usuarios, y su empleador puede estar preocupado por las contraseñas débiles y el robo de claves SSH.

Agregar una VPN agrega una capa adicional de defensa que se controla a nivel corporativo, en lugar de a nivel de servidor individual como lo es SSH.

En general, recomendaría a su empleador que implemente algunas buenas prácticas de seguridad aquí. A expensas de la conveniencia, por supuesto (la seguridad generalmente viene a expensas de la conveniencia).

La VPN le permite conectarse a la red privada de su empleador y adquirir una dirección IP de esa red privada. Una vez que está conectado a la VPN, es como si estuviera usando una de las computadoras dentro de la compañía, incluso si se encuentra físicamente en el otro lado del mundo.

Lo más probable es que su empleador requiera que se conecte a través de VPN primero porque los servidores no son accesibles desde Internet (es decir, no tienen una dirección IP pública), lo cual es una buena idea. La VPN agrega otra capa de seguridad, ya que si los servidores fueran accesibles públicamente a través de SSH, serían vulnerables a una variedad de ataques.

SSH es un protocolo de encriptación utilizado para varias cosas. Cifrar el tráfico en un túnel VPN es uno de ellos. Su tráfico se cifra mediante SSH, pero luego debe estar envuelto en paquetes IP válidos (túnel) para atravesar una red como Internet. Este túnel es la VPN.

Básicamente, su empleador bloquea el tráfico de la red externa, por seguridad, a menos que ese tráfico llegue a través de una VPN que controla el empleador. Una VPN puede o no cifrar el contenido del túnel. El uso de SSH cifrará el tráfico transportado en el túnel VPN.

Necesita la VPN para ingresar a la red local.

Entonces no necesita asegurar su conexión a servidores individuales, ya que estará encriptada por el enlace VPN.

Sin embargo, ¿de qué otra forma te conectarías con ellos? SSH es el protocolo de acceso a la consola de facto para servidores remotos; instalar y configurar uno no seguro sería una sobrecarga de administración adicional y disminuiría la seguridad dentro de la red local (lo que puede o no ser un problema).

No lo olvide, no todos, incluso dentro de la empresa, tendrán acceso total a todos los servidores, y la capacidad de utilizar el cifrado basado en claves incluso dentro de la red local le permite a su administrador de red asegurarse de manera fácil y segura de que solo las personas que aparentemente saben lo que hacen están haciendo, incluso dentro de la empresa, se les permite tocar el servidor.

También puede conducir capas de seguridad adicionales a través de la VPN. Tales como verificaciones de criterios del dispositivo, autenticación de 2 factores, etc.

El razonamiento típico es que desea reducir la exposición y los posibles vectores de ataque en la medida de lo posible.

Si comienza con la premisa de que se requieren tanto SSH como VPN (para sus propios fines), entonces tener ambos enfrentados externamente significa que los atacantes tienen dos rutas potenciales hacia su entorno. Si hace que SSH sea solo local, agrega una capa adicional a la seguridad del servidor. Considere los siguientes escenarios:

1. SSH + VPN externamente. El atacante solo necesita comprometer SSH para comprometer el servidor.

2. SSH externo. Funcionalmente igual que el escenario anterior.

3. VPN externa (SSH interna). Se duplica en seguridad. El atacante debe atravesar ambos antes de que puedan hacer algo al servidor.

Tenga en cuenta que, junto con el hecho de que VPN sería necesario para otras funciones, y puede estar mejor configurado para acceso externo y es obvio.

Me arriesgaría a que la respuesta sea simplemente que NAT está involucrado y (como muchos otros han dicho) exponer el servidor objetivo final al mundo invita a otro punto de ataque. A menos que esté haciendo grandes transferencias de datos a granel con claves grandes, SSH generalmente no se interpone en el camino. El cuello de botella casi siempre será la red. (¡Casi! = Siempre).

Si tiene la 'suerte' de tener IPv6, es probable que no sea tan problemático, pero con IPv4 y el espacio de direcciones limitado disponible, NAT es (IMO) en última instancia, lo que creo que está detrás de esta 'política' más que cualquier otra seguridad 'accidental' o 'intencional'.

Según mi entendimiento actual, SSH, porque simplemente usa un intercambio de claves tcp para verificar que un usuario cliente tenga las credenciales correctas para acceder a la ID de usuario en el servidor, es susceptible a ataques de hombre en el medio donde un ISP o un enrutador comprometido podría interceptar la solicitud de protocolo de enlace y actuar como el que envía la autenticación, secuestrando la conexión. Esto permite que los comandos se inyecten en la secuencia y luego se filtre la salida antes de que llegue al cliente auténtico inicial, ocultando así al hombre en la inyección intermedia de comandos arbitrarios en el shell ssh del servidor.

Sin embargo, por un túnel VPN permite algo que ssh no permite. Una clave de cifrado simétrica adicional previamente acordada. Esto significa que el tráfico entre las dos máquinas no es susceptible a un hombre en el medio del ataque porque el tráfico, si se intercepta y reenvía en nombre del cliente auténtico para controlar la capa de cifrado SSL, no podría pasar la clave de cifrado vpn requisitos porque el tercero no tendría la capacidad de falsificar las claves vpn de la misma manera que sería capaz de controlar un reenvío de intermediario de la conexión ssh tcp ssl.

Por lo tanto, ssh no es lo suficientemente bueno como para detener a un hombre en el medio de un ISP o un enrutador comprometido que un cliente debe atravesar para conectarse al servidor.