SSH plausiblemente deniable, ¿tiene sentido?

Question

SSH plausiblemente deniable, ¿tiene sentido?

#1 de Tom Leek (10 votos)
#2 de tylerl (1 votos)

4

Mi colega me acaba de decir que no puede hacer conexiones salientes de SSH en sus redes corporativas, así que le aconsejé que configurara un servidor en el puerto 443 y funcionó. Entonces comencé a pensar que el administrador podría detectar que en realidad se trata de una conexión SSH mediante la inspección profunda de paquetes y / o al servidor, pero creo que encontré una manera de hacerla más difícil que no implique la ofuscación de protocolo (lo cual no hago). no me gusta, porque rompería masilla).

Aunque es obvio que si no cambias el protocolo, tu conexión permanecerá en los registros, pero pensé que el administrador podría sentirse confundido si pudiera demostrarle que en realidad hay un sitio web de HTTPS en el puerto y servidor realmente no habla SSH. Para hacer el truco, pensé en un proxy que envuelve el puerto y siempre permite las solicitudes SSL, pero permite SSH solo después de un intento de inicio de sesión seguro a través de HTTPS. Como aún no conozco los protocolos de SSL ni de SSH, ¿puede pensar en alguna razón por la que esto no funcione? Si no, ¿crees que podría ser convincente / útil?

tls ssh

pregunta d33tah 02.10.2013 - 13:19

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls ssh

PCI DSS: solo una función primaria por servidor ¿PHP tiene una API XSS?

score 10 · Answer 1

Técnicamente , los primeros bytes de una conexión SSL, y el primer byte de una conexión SSH, difieren. Básicamente, con SSL, el cliente habla primero, y el primer byte tiene un valor 22 (0x16) para el registro que contiene su ClientHello (consulte el estándar ). Con SSH, el cliente y el servidor hablan simultáneamente, pero el servidor puede esperar a que el cliente hable primero y envían sus "pancartas" que comienzan con "SSH" (consulte the standard ), por lo que el primer byte del cliente será 83 (0x53, para una ASCII "S").

Por lo tanto, podría escribir algún software de servidor que escuche en el puerto 443, busque el primer byte y, dependiendo de ese byte, redirija a un servidor SSH o SSL local. Los dos protocolos se pueden multiplexar en el mismo puerto de esa manera (solía hacerlo para SSL vs RDP). Sin embargo, por supuesto, todavía habrá tráfico SSH en el zócalo cuando hagas SSH, por lo que las cosas de inspección de paquetes aún verán "patrones similares a SSH".

Lo mismo se aplica a tu idea. Incluso si primero realiza un diálogo completo basado en SSL, en el momento en que cambia a SSH en el mismo zócalo, los inspectores de paquetes pueden detectarlo. Si realmente quieres evadirlos, tienes que hacer la cosa SSL completamente : comenzar con SSL, luego hacer el SSH dentro del túnel SSL. Básicamente, ejecute un VPN basado en SSL . Desde el exterior, solo será SSL todo el tiempo; En el interior, paquetes IP arbitrarios, que pueden transmitir algo de SSH o cualquier otra cosa, en realidad.

(Tenga en cuenta que el cifrado SSL no oculta el tamaño del paquete , y el tráfico SSH incluye una gran cantidad de paquetes pequeños que implican un patrón de tráfico distinto al de "Web normal". su intento de evadir las políticas locales. ¡La delincuencia no es un oficio fácil!)

score 1 · Answer 2

Una solución simple es configurar un proxy HTTP (a través de HTTPS, técnicamente), y luego configurar su cliente SSH para conectarse a través de ese proxy. Putty admite esto explícitamente en la interfaz, mientras que otros clientes pueden realizar trabajos adicionales.

Entre bambalinas, su cliente realizará una solicitud de HTTPS a su servidor proxy (que podría ser también su servidor SSH) y emitirá un comando CONECTAR en lugar de un GET o POST. En lo que respecta al proxy de la organización, HTTPS es completamente opaco, pero tampoco inesperado.

La diferencia principal entre el tráfico proxy HTTPS y el tráfico GET / POST estándar a través de HTTPS es que el tráfico proxy suele ser bidireccional de manera más interactiva. Es decir, usted envía unos pocos bytes, yo envío unos pocos bytes, y adelante y atrás. Por lo general, el tráfico HTTP, por otra parte, implica que cada sitio se turne para enviar la solicitud completa o la respuesta completa. Pero dentro de la encapsulación de proxy, SSH no se distingue fácilmente de ningún otro protocolo interactivo sin una muestra estadísticamente significativa y un análisis cuidadoso de la sincronización.

Además, puede ejecutar un proxy HTTPS en un servidor web normal , compartiendo la dirección, el puerto y el certificado SSL con el sitio en vivo existente, lo que significa que la única "pistola humeante" es para hablar es el volumen de tráfico y los patrones de tiempo.