Foro de elhacker.net

Buenas tardes, en este primer mensaje me gustaría empezar fuerte ;D

Escenario: Organización con puestos de cliente Windows 7 plataformados y sin privilegios de administrador. Navegación hacia internet a traves de proxy autenticado.

Antecedentes: Para evitar el filtrado del proxy venía utilizando BitviseSSH que me permitía establecer una conexión SSH a traves del Proxy HTTP con destino un servidor SSH en el puerto 443 y a su vez levantar un proxy SOCKSv5 local que podía configurar en mi Firefox portable.
Ahora esto lo han capado e independientemente de la IP de destino ya no es posible establecer SSH a traves del proxy (Anteriormente solo iban capando direcciones IP)

He probado Corkscrew pero el proxy sigue denegando la conexión SSH.

Pregunta: ¿Qué opciones tengo para poder saltarme el filtrado del proxy HTTP de la organización?

Muchas gracias anticipadas.

pero puedes navegar por https?

si puedes navegar por ejemplo a https://google.es, entonces no es problema del puerto

me explico, si puedes navegar vía https, lo que habrán hecho es una white list, lo normal de este tipo de proxy es una black list, osea se van metiendo las paginas web o las ip,s no deseadas y el proxy las bloquea.

al hacer una white list es al contrario, se van metiendo las web y las ip,s permitidas y el resto del mundo lo bloquean.

si no tienes posibilidad de navegar por https, es que han bloqueado el puerto 443, por lo que tienes que mirar que puertos están permitidos, si esta permitido el 8080, pues tendrás que migrar a ese puerto, si solo esta permitido el 80, pues tendrás que migrar al 80, lo que pasa que en esos puertos va a ser muy fácil que te pillen, porque en el momento que admin detecte trafico cifrado por puertos de trafico sin cifrar se va a dar cuenta en seguida y bloqueara las ip,s de destino

Buenas tardes, efectivamente puedo navegar por HTTPS (Puerto 443)

Cuando lanzo la conexion con el Bitvise me devuelve el siguiente error:

Y cuando lo lanzo desde Corkscrew en MobaXterm devuelve:

He probado con diferentes servidores SSH y todos devuelven el mismo error por lo que deduzco que están realizando una inspección de los paquetes y descubren que es SSH sobre HTTP

no lo creo, ese error lo he tenido esta mañana

me he conectado con teamviwer a mi servidor, lo he reiniciado y a funcionar, durante toda la mañana me ha estado dando por culo el mismo error, porque el windows me cerraba el servidor pero al final lo que he hecho es iniciar el servidor ssh con privilegios de administrador y he estado funcionando ya sin problemas.

no creo que sea problema del proxy, es de tu servidor.

si lo tienes sobre windows, como yo, es posible que alguna actualización nos este jodiendo, por que es muy raro que me haya pasado a mi lo mismo esta mañana


eso es imposible, es trafico cifrado sobre https (443) que es trafico cifrado, luego no es trafico cifrado sobre http, eso si se darían cuenta si utilizaras el puerto 80 y utilizaras trafico cifrado, pero lo que va por el puerto 443 es cifrado, si o si

El servidor SSH principal corre en Linux, el secundario en otra linea en un OpenWRT y los demás que he probado los he montado en Azure y en AWS en diferentes regiones.

Respecto a inspeccionar los paquetes es totalmente viable ya que lo que estoy haciendo es poner a escuchar un servidor SSH en el puerto 443, pero los paquetes que viajan por ahí no van cifrados, esa decir, se saben que son de tipo SSH. El mero hecho de utilizar el puerto 443 no significa que la comunicación esté cifrada, el cifrado te lo facilita el protocolo de comunicación.
Lo que inpeccionan es la cabecera que empieza por SSH y entonces cortan la comunicación. Si vieran una sesión WEB TLS standard lo dejarían pasar seguramente.

Un saludo.

hasta ahí, de acuerdo


si eres tan amable ponme unas capturas de eso que dices porque yo no lo tengo tan claro

donde va eso que dices en el datagrama ?

(http://4.bp.blogspot.com/-j6fmdl6ZGYU/Tl3qrAEb7LI/AAAAAAAAAJU/YbwjVXXBf2M/s1600/Datagrama+IP.+IP+Datagram.jpg)

Buenas, aquí te adjunto una captura de Wireshark: https://drive.google.com/open?id=0BxLUQ-gTRfN0MGpUMG13cXZBTkE

Como puedes ver antes de establecer la comunicación tanto el cliente como el servidor se presentan y esos pueden ser los bytes de Datos por los que el proxy HTTP puede descartarme la conexion.

estoy mirando la captura

tengo del 1 al 22

donde dices exactamente que se ve lo del ssh ?

En los paquetes 4 y 6 en el campo "Data" puedes observar las cadenas de texto plano que delatan que se trata de una conexión SSH.

vale ya lo vi

el paquete 4  es la negociación que hace el bitvise SSH Client

y el paquete 6 y 7 es método de autenticacion.

es una cosa particular de bitvise, pero ya me has dejado con la mosca detrás de la oreja para ver que pasa desde una shell

edito: no creo que el proxy este filtrando conexiones por la interpretacion de paquetes, prueba a montar un servidor web en el puerto 80 y conectarte a traves del proxy http a una pagina de prueba, igual lo que tienes es bloqueada la ip,

Perdon por el repost.

Pues tienes razón, en que el datagrama (la parte de datos) en el inicio de la negociación va en claro y desde la shell anuncia


luego otro paquete de OnlyDo 2

y dos mas de rsa, sha, etc

Lo que sigue sin cuadrarme es que un proxy llegue a la capa de datos para ver que datos tiene el datagrama a la hora de filtrar, no me cuadra, tendría que tener unos recursos impresionantes si cada petición tiene que acceder a la parte de datos interpretarlos y decidir si pasa o no pasa.

luego esta en que son 4 paquetes, a partir de ahí todo el contenido va cifrado, no se si existe un proxy capaz de eso. Yo no lo conozco.

Creo que los proxy son Bluecoat, pero no lo se seguro.

En mi organización los recursos no son un problema.

Bueno resucito este tema, porque la semana pasada me he encontrado un firewall de esos que no permiten el tunel ssh por el 443

Osea que estamos ante un firewall DPI (Deep Packet Inspection) y por tanto puede filtrar por protocolos/tipos de archivos específicos, como SOAP o XML (por ejemplo en entornos transaccionales).

Bien, 4 días después de joderme el tunel ssh, y de darle vueltas al tarro, me lo he vuelto a saltar  ;D

obviamente no con un tunel ssh. No he probado si un tunel dns seria efectivo, pero dado que es un método sumamente lento a la hora de navegar, no me planteo utilizarlo.

Bueno, desplegando mi medios en la red del proxy pude constatar que el firewall en primera instancia te da acceso, y que pasado un tiempo al no encontrar lo que busca, bloquea la conexión.

Por eso en Bitvise da error, puede con suerte negociar la clave pero enseguida se corta la conexión.

En un principio pensé que era porque detectaba la negociación ssh que hemos comentado en los anteriores post que va en claro, y utilice métodos de ofuscación tanto del propio bitvise en sus versiones mas recientes, como de otros programas, y nada vuelta la burra al trigo.

Entonces decidí intentar una conexión tcp pura y dura, sin cifrar, y pude constatar que la conexión se establecía perfectamente en un inicio, pero enseguida bloqueaba el trafico saliente, la verdad que con el entrante no probé. Durante esa conexión tcp recibí una bonita llamada de identificación de servicio, entiendo que seria un IPS escaneandome  :xD

pues entonces la cosa estaba clara,el firewall permite el trafico http/https mientras que el resto de conexiones tcp eran bloqueadas en milisegundos.

Pues que tiene el trafico http?

las cabeceras


Tanto si el trafico es http, como si el trafico es https, las cabeceras van en claro con un bonito HTTP, la verdad que es una regla bastante eficiente para un firewall, en vez de buscar una serie de protocolos, solo buscan la cabecera del paquete http si esta, pasa, si no esta, bloqueo de conexión.

luego el resultado esta claro, tienes que utilizar http/https si o si, ahora ya solo falta montarte tu tunel http  ;)

Todos los proxys no son iguales.
Digo esto porque los dos casos, me da la impresión que son diferentes.
A considerar para experimentar.
Cuando el tunel ssh (que es el básico), a través de Bitvise, Putty, etc. es bloqueado; pudiera funcionar (depende del proxy); una simple VPN por TCP / Puerto 443.
Variante: ofuscación en el tráfico con Psiphon. Para proxys de menor valía: Latern
Variante: Tor desproxy + port 443 de entrada a tor + tsocks. Para proxys de menor valía: obfs3 ó un puente proporcionado de este tipo.
Reitero esto depende del firewall que tenga el proxy y el bloqueo que se implemente.
Con un túnel DNS, funciona, pero debe contar con 5 Mb de ancho de banda al menos, sino envejece.
La música cambia si hay servidores DNS dedicados con firewall independientes. Estos proxys son en extremo costosos, pero muy efectivos. Solo se ven a nivel de Transnacionales o gubernamental. Son muy difíciles de saltar (no imposible). Pudiera funcionar Psiphon ó un túnel DNS (otro método que me reservo; pero el que busca encuentra…).

Parece ser el caso del usuario djbill.

"Lo que sigue sin cuadrarme es que un proxy llegue a la capa de datos para ver que datos tiene el datagrama a la hora de filtrar, no me cuadra, tendría que tener unos recursos impresionantes si cada petición tiene que acceder a la parte de datos interpretarlos y decidir si pasa o no pasa."

A probar: usar Psiphon y sobre él una VPN ligera, si el ancho de banda lo permite.

Warcry:

Con una VPN "buena" por TCP/ 443 debe ir en ruedas. Si lo vuelven a “apretar” con Psiphon  volvería al negocio.
Haga saber si hubo problemas.
Buenos deseos.

Me he perdido, yo no he hablado de proxys, he hablado de firewalls, supongo que tu entiendes que el proxy ya tiene un firewall incorporado.


Puede que los casos sean diferentes, y para @djbill una simple ofuscación o vpn sea suficiente en mi caso el firewall bloquea cualquier conexión tcp.


El tunel dns y la ofuscación podrían funcionarle, pero las ultimas versiones de bitvise cuentan con un ofuscador y dice que no se conecta, no se si lo hace con una version antigua o con una moderna de bitvise, obviamente con el servidor de bitvise para que desofusque a la salida


obviamente revisar todo el trafico consume muchos recursos, el buscar en la secuencia inicial una cabecera y si existe, mantiene la conexión y si no existe, la bloquea, pues como he comentado en el post anterior es una solución muy eficiente.


ya te he comentado que el firewall bloquea la conexión de paquetes que no tengan cabecera HTTP y la vpn no tiene esa cabecera y Psiphon no deja de ser otro ofuscador mas ;)

El perdido soy yo.
Me he saltado ese detalle (se me fue la almendra)  :xD
Mis disculpas. Estaba más centrado en lo del proxy.

Le asiste la razón.
Agradecido que haya sido paciente y gentil.
De cualquier modo ha sido interesante.
Un cordial saludo.

Buenas tardes,

Las últimas pruebas las realicé con "Bitvise SSH Client 7.27" y conectando contra un servidor OpenSSH "openssh-server_6.7p1-5+deb8u4_amd64.deb"

Mañana probaré Psiphon

Buenos días, he probado "Psiphon" y nada, no hay manera de conectarse.

Estuve viendo "TCP Over HTTP Tunnel", a ver si saco tiempo para probarlo.

Un saludo.

muy bueno y sencillo, ya me he montado la maqueta, y lo he hecho funcionar sin problemas

el lunes si tengo un rato lo pruebo en el la red firewal DPI

Que cosa… esto es más adictivo que el Bacardi con cola del puticlub. :xD
Me han embullado.
Me voy a montar uno a ver como va… nunca se sabe cuándo hará falta. ;D

Si realmente es Blue Coat (o las nuevas versiones de symantec) tu única posibilidad es scramblesuit o obfs4 y será algo 'fugaz', vamos que en cualquier momento te dejará de funcionar como ya pasó con obfs3 shadowsocks...etc

Suerte

toy navegando hasta la cocina  ;D ;D ;D

Problema del programita este es que no admite conexion a proxies y te da fallo de autenticación.  :-\

pero nada que no se pueda arreglar con un poquito de ingenio  :P


ahora en la configuracion de TCP over http el server ponemos el 127.0.0.1 y puerto el 444 y a funcionar.

como tanto el tcp over http y el ncat no necesitan instalacion pues tampoco tenemos que ser administrador  ;-) ;-) ;-)

edito: lo que noto es la navegacion un tanto lenta, con tanto tunnel unido a mis particularidades para que no me pillen  :silbar:

la navegacion es funcional, lo malo son los videos del youtube que como le metas resolución, se jo.dió el tema

No sé si será el mismo programa (intuyo que sí...).
En mi caso, buscando un tutorial que me sirviera de guía, pues nunca he hecho este tipo de túnel, me topé con uno muy bueno y con un gestor de conectividad para Windows.

(https://s6.postimg.cc/er2jbnayp/TCP_over_HTTP_Tunnel.jpg) (https://postimages.org/)

A través de él se establece el túnel y combinado con Bitvise, se configura el servidor VPS.
Por arriba me lo he leído y descargado, mis impresiones son que se ve bueno, sencillo. No he podido probarlo, y ya de paso probaré unos servicios VPS nuevos, que me recomendaron. Mi objetivo es implementarlo en una laptop con Windows, y después voy para Debian.
Les diré como me fue, en cuanto tenga un respiro. Me guiaré por warcry.

Buenos deseos.

Si es la version actual del TCP over HTTP, que incorpora un cliente ssh y proxy socks.

yo lo probe cuando hice la maqueta y me daba errores de conexion, no llegaba a cortarmela pero me salian ventanas en windows un tanto molestas.

No se si es por mi configuracion que no es un elace directo puro entre cliente ssh y servidor ssh o bien es que da problemas ese cliente.

Para mis necesidades esta claro, ncat para conectarme al proxy y validarme, TCPoHTTP para eludir las restricciones del firewall DPI y bitvise para crear el tunel ssh y el proxy socks

a ver si nos cuenta @djbill si le ha servido el invento

Warcry:

Logré montar el túnel.
Tuve contrariedades, no por la implementación, pero sí por el VPS que usé, que no estuvo a la altura. La navegación… muy lenta. Otro aspecto a notar fue que no tuve que usar el ncat. De todos modos, fue un acercamiento, no es definitivo; y debo volver a intentarlo, pues probaré unos servidores específicos, los cuales intuyo, que son los adecuados. Esto me lo sugiere, el experimento que hice a través de otra vía. Le pongo el link en privado, por si se anima a probarlo. En aras de intercambiar experiencias (si le funcionó [se ajusta a su firewall]; si le fue mejor o peor que con el túnel que hizo, etc.). En mi caso me fue “notablemente mejor”. Sospecho que es por los servidores. Aún no es definitivo, y le reitero, en la semana entrante debo volver a intentarlo.
El tiempo se me fue, y ni tan siquiera pude “levantar” el túnel DNS con iodine en Windows, para comparar. Me daba error. En cambio, sí “corrió” en el Kali. Debo ver que es lo que tengo, de las muchas cosas, que da el conflicto. Existe una realidad: estos túneles siempre son lentos, no es muy relevante el método. Según criterios, y ya menos mi experiencia, el más lento debe ser por DNS. Es una de las cosas que intento corroborar.

Si se anima y no lo considera un atrevimiento…

(https://s6.postimg.cc/b4nzquwgx/Prueba.jpg) (https://postimages.org/)

Sabrá qué hacer. De más contar con su discreción, por posible abuso. Confío que entenderá. Y si no le es útil para el caso… pues será para otro. Es mi intensión corresponderle con algún aporte de interés.
No use su proxy y sí los que se le ofrecen (01 y 03).
Si lo considera inapropiado, inconveniente, u algún otro factor negativo, lo entendería y no habría disgustos, créame. De por sí le estoy agradecido por la inspiración y guía.
 
Si va de aventurero, hágame saber la experiencia y pormenores.

Buenos deseos.

Me alegro que te funcionara.

No me gusta utilizar servicios de terceros, porque la navegación no es "anónima", lo pongo entre comillas ya que el ISP lo ve todo y lo sabe todo de ti, simplemente con monitorizar las peticiones dns ya saben hasta la marca de tus calzoncillos y si te gustan los travelos.

Pero no me queda mas remedio que pasar por ellos  :(

Así que el túnel lo hago a un servidor que gestiono yo; lo del ncat es porque la red donde esta el firewall DPI tiene un proxy y hay que validarse contra el si quieres salir al exterior.

La verdad que nunca he montado un tunel dns, pero con la gente con la que hablado dicen que es la muerte a pellizcos, igual un día monto una maqueta en casa a ver que tal va.

he estado indagando un poco sobre la información que me has pasado por mp, y como he comentado antes no utilizo servicios de terceros, pero si tengo tiempo y me animo a probar te comento los resultados.

y ahora ha echar una partidita al tyranny que es sábado  ;D

Depende mucho de la red donde se haga (ancho de banda, saturación de clientes, si tiene servidores DNS privados o públicos, etc.)

Eso sí... brinca y alto: portales cautivos y demás. Es bastante lento, no le voy a engañar, pero es gratis  ;), y con acceso "casi" ilimitado.