¿Puede un atacante "simular" una dirección IP privada?

En resumen no. Debido a que SSH se ejecuta en TCP (aunque hay una versión UDP, esto es inusual) se requiere un protocolo TCP para iniciar la autenticación del protocolo SSH y su siguiente comunicación. Una dirección privada no cruzará su enrutador perimetral hacia y desde la Internet pública, por lo que cualquier suplantación de una dirección interna a medida que ingresa (suponiendo que no haya ninguna suplantación de identidad en el enrutador o firewall, lo cual es una medida de seguridad común) dará lugar a la terminación de SSH el servidor intenta responder a esa dirección interna y nunca volverá a la Internet pública ni a la computadora del atacante. No se puede establecer conexión.

Antes de que el atacante pueda enviar datos al servidor SSH, debe completar un protocolo de enlace TCP. Esto significa que el atacante tiene que adivinar un número de secuencia de 32 bits. (Si se usan cookies SYN, las posibilidades del atacante pueden mejorar .)

Suponiendo que su servidor genere buenos números de secuencia, esto reducirá significativamente la capacidad de los atacantes para atacar su servidor SSH utilizando una dirección IP del cliente falsificada.

Pero tal vez no confíe en su servidor para generar buenos números de secuencia, o tal vez piense que 32 bits de seguridad no son suficientes. Es posible que aún quieras saber qué pasaría una vez que el atacante haya adivinado un número de secuencia correcto.

En primer lugar, notamos que el atacante podrá averiguar si un número de secuencia acertado era correcto o no. Una estimación correcta hará que se abra una conexión, por lo que contará hacia el límite especificado usando MaxStartups . El atacante puede intentar abrir otra conexión utilizando una dirección no falsificada para averiguar si se ha alcanzado ese límite. Puede mantener su servidor justo por debajo de ese límite en todo momento, de modo que una conexión exitosa con una dirección falsificada siempre tomaría la última conexión disponible.

Sin el truco para notar un número de secuencia acertado, el atacante habría tenido que enviar conjeturas de contraseña en la persiana sin saber si la conexión a la que se enviaron existe. Eso podría haber ralentizado al atacante en un factor de 2³².

Pero a pesar de que un atacante puede obtener comentarios para indicar si un número de secuencia se adivinó correctamente, existen otros obstáculos que impiden el adivinar la contraseña en una conexión TCP falsificada.

Durante el intercambio de claves, tanto el cliente como el servidor elegirán un valor aleatorio para enviar a través de la conexión. Estos valores aleatorios influyen en la clave de sesión. Esto significa que un atacante que trabaja a ciegas (porque no ve las respuestas enviadas desde el servidor a la IP falsificada) no sabrá la clave de la sesión.

La falta de conocimiento sobre la clave de sesión significa que el atacante tendrá que adivinar un código de autenticación de mensaje. Esto es esencialmente equivalente a realizar un ataque MITM en una conexión legítima. Además, el atacante debe enviar la contraseña cifrada para que el servidor la descifre. Dado que el atacante no sabe la clave de cifrado en uso, no sabrá qué contraseñas ha intentado.

La ventana de tiempo para que el atacante complete el ataque solo dura hasta que la dirección IP falsificada haya respondido con un paquete TCP RST. Debido a que el tiempo de ida y vuelta entre el atacante y el servidor probablemente será mayor que el tiempo de ida y vuelta entre el servidor y las direcciones locales, esto podría evitar que el atacante utilice cualquier tipo de información, incluida la verificación del número de secuencia acertado.

Puede darle al atacante una ventana más larga para completar el ataque instalando un firewall que impida que SYN ACK llegue a la dirección IP falsificada o evitando que el RST llegue al servidor. Sin embargo, esto no hace que el ataque sea mucho más factible.

La respuesta es sí, es posible. Sin embargo, hay algunas limitaciones significativas. Mediante el uso de suplantación de IP, podría ser posible establecer una conexión que podría usarse para entregar una carga útil al objetivo, pero no será posible establecer una verdadera conexión TCP bidireccional. En términos simples, el atacante puede hacer que la máquina de destino responda, pero no recibirán las respuestas, ya que no serán enrutadas (es por esto que la falsificación de IP se usa más comúnmente con UDP en lugar de conexiones de tipo TCP). Sin embargo, el atacante puede simular la recepción de los paquetes y enviar paquetes de confirmación falsos y desde allí llegar al punto en el que potencialmente pueden entregar una carga útil. Teóricamente, esta carga útil podría usarse para configurar un troyano en el objetivo que luego llama al sistema C & C de los atacantes, estableciendo una conexión en su sistema interno.

Si bien esto es posible, es un truco difícil y puede que no sea posible en todos los sistemas, ya que ha habido cambios en la forma en que varias plataformas manejan las conexiones TCP, lo que dificulta que el atacante simule los paquetes ACK. Dadas todas las revelaciones recientes sobre la falta de seguridad en los enrutadores, el ataque mucho más probable sería comprometer su enrutador y configurar el reenvío de puertos o usar UPnP para engañar a su sistema para que inicie una conexión externa, etc.