 Autor
|
Tema: SSH a traves de proxy. Corkscrew no sirve (Leído 15,276 veces)
|
warcry.
 Desconectado
Mensajes: 1.004
|
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.
|
|
|
|
|
En línea
|
HE SIDO BANEADO --- UN PLACER ---- SALUDOS
|
|
|
djbill
Desconectado
Mensajes: 9
|
Creo que los proxy son Bluecoat, pero no lo se seguro.
En mi organización los recursos no son un problema.
|
|
|
|
|
En línea
|
|
|
|
djbill
Desconectado
Mensajes: 9
|
Creo que los proxy son Bluecoat, pero no lo se seguro.
En la organización donde tengo el problema los recursos tienden a ilimitados.
|
|
|
|
|
En línea
|
|
|
|
warcry.
Desconectado
Mensajes: 1.004
|
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  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  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 wifiway ~ # curl -I https://google.es
HTTP/1.1 301 Moved Permanently
Location: https://www.google.es/
Content-Type: text/html; charset=UTF-8
Date: Tue, 29 May 2018 16:58:30 GMT
Expires: Thu, 28 Jun 2018 16:58:30 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alt-Svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="43,42,41,39,35"
wifiway ~ # curl -I http://google.es
HTTP/1.1 301 Moved Permanently
Location: http://www.google.es/
Content-Type: text/html; charset=UTF-8
Date: Tue, 29 May 2018 16:58:55 GMT
Expires: Thu, 28 Jun 2018 16:58:55 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 218
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
wifiway ~ #
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  |
|
|
|
|
En línea
|
HE SIDO BANEADO --- UN PLACER ---- SALUDOS
|
|
|
AXCESS
Desconectado
Mensajes: 179
|
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.
|
|
|
|
|
En línea
|
|
|
|
warcry.
Desconectado
Mensajes: 1.004
|
Todos los proxys no son iguales.
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. 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. 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. 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. 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 "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." 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. 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. 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 Cuando lo ejecuta Psiphon se inicia conectando automáticamente. Mientras se encuentra conectando, se muestra un icono girando. Puede seleccionar uno de los siguientes modos de túnel: VPN (L2TP sobre IPsec), SSH, o SSH+ (SSH con ofuscación, una capa aleatorizada sobre SSH para evitar la identificación por perfil del protocolo (fingerprinting)).
|
|
|
|
|
En línea
|
HE SIDO BANEADO --- UN PLACER ---- SALUDOS
|
|
|
AXCESS
Desconectado
Mensajes: 179
|
Me he perdido, yo no he hablado de proxys, he hablado de firewalls...
El perdido soy yo. Me he saltado ese detalle (se me fue la almendra) 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.
|
|
|
|
|
En línea
|
|
|
|
djbill
Desconectado
Mensajes: 9
|
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
|
|
|
|
|
En línea
|
|
|
|
djbill
Desconectado
Mensajes: 9
|
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.
|
|
|
|
|
En línea
|
|
|
|
warcry.
Desconectado
Mensajes: 1.004
|
Estuve viendo "TCP Over HTTP Tunnel", a ver si saco tiempo para probarlo.
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
|
|
|
|
|
En línea
|
HE SIDO BANEADO --- UN PLACER ---- SALUDOS
|
|
|
|
 |
