JAP (JonDo Anon Proxy)

Dada la época en la que estamos y viendo como están las cosas, cada vez es más personas están interesadas en preservar su anonimato en su navegación (no vamos entrar en detalle del por qué). 

Todos conocemos TOR (The Onion Project) al igual que conocemos, en cierto modo, que no toda la información que pasa por TOR vaya cifrada, no voy a entrar en explicar como funciona la red TOR ya que doy la doy por sabida (No obstante os recomiendo este post en el que está muy bien explicada).

Si bien, al menos los que hemos usado TOR por una u otra razón, hemos podido ver que, en ocasiones, es excesivamente lento (aunque eso se puede solventar en cierto y ya os hablaré de cómo hacerlo en otro post).

Hace unos días encontré una alternativa a TOR y cuyo funcionamiento se basa en las mismas bases de TOR, es decir, se establece una red entre varios nodos y se transmite la información.

Vale vale no has decubierto la pólvora, y dónde está la diferencia, que más vale malo conocido…pues veámoslas: 

• Velocidad: los servidores están optimizados, así obtienen mayor rendimiento que su homólogo TOR.
• Seguridad: los nodos son ofrecidos por instituciones independientes las cuales, previamente, firman una declaración pública en las que aseguran que NO almacenan ningún tipo de información sobre el tráfico que reciben y envían (digamos que de forma legal están atados de manos) Así funciona JAP:

(si queréis más detalle y una comparativa TOR vs JAP lo podéis leer aqui)

Aquí los nodos se llaman mix providers, las rutas mix cascades y podemos seleccionar desde su configurador la ruta más rápida y/o más segura.

Podremos comprobar que la velocidad de navegación con JAP aumenta con respecto a TOR, que como comenté anteriormente, puede ser lento y pesado.

Pero…no todo lo que reluce es oro, aunque es gratuito, en JAP para obtener una velocidad y seguridad idónea, tendremos que contratar un servicio de pago llamado JonDonym cuyo precio oscila desde los 5€ hasta los 100€ los cuales se facturan por volumen. Podéis ver los precios aquí, no obstante, y para los más vagos :), os dejo una pequeña comparativa de la versión free y la de pago más básica.

También, y al igual que TOR, cuenta con un addon para firefox, el cuál podemos descargar e instalar una vez hemos completado el proceso de instalación, dicho addon se llama JonDoFox y sería el equivalente a TorButton, pero con la diferencia de que éste automáticamente nos creará un nuevo perfil en Firefox

y nos configurará el navegador para funcionar con JAP, trabajo que nos ahorraremos, y es más, y se me olvidaba comentarlo, en el mismo instalador se da la posibilida de realizar un test de anonimato con nuestro navegador actual.

El aspecto final de JAP funcionando es el siguiente:

[+] Sitio Web del proyecto: http://anon.inf.tu-dresden.de/index_en.html

[+] Descargas: http://anon.inf.tu-dresden.de/download_en.html

Bueno, ya tenéis una alternativa a la red TOR la cual os recomiendo probar, en las pruebas que yo he realizado (y sin cuenta Premium) los resultados han sido bastante buenos, ahora os toca probar a vosotros :)

------------------------------

Contribución gracias a Jesus D. Angosto (@jdangosto)

Leer más...

A la caza del proxy abierto

Hacía pocos días que notaba que el led de la unidad ONT HG 850G, que me conecta a Internet a través de fibra óptica, parpadeaba más de lo normal.

Por las horas a las que suelo acostarme, puede darse el caso que el servidor de casa esté buscando actualizaciones, haciendo backups, etc, etc,… En otro momento de mi vida quizá diría que el Emule está echando humo y me iría a la cama contento. Al día siguiente tendría muchos capítulos de series descargadas. Sin embargo, actualmente, que cuando necesito algo, lo descargo bajo demanda, me pareció que algo no iba bien.

Cierto es también que, al disponer de una conexión de fibra óptica, la velocidad de descarga de cualquier cosa es tan rápida, que no te das cuenta que hay "algo" comiéndose la línea.

Así pues, me dispuse a investigar qué es lo que estaba pasando en la máquina y esto que os cuento es lo que encontré:

• En primer lugar, mediante iptraf, podía ver que el interfaz ppp0 (recordad que quité el router de Telefónica y la IP pública la tiene directamente mi máquina), estaba consumiendo entre 1 y 2 MB de ancho de banda de forma continua.

• Mediante un "tcpdump -n -i ppp0", pude ver que casi toda la actividad de red estaba encaminada al puerto 8088. Las direcciones IP origen procedían de diferentes partes del Mundo, aunque sobre todo, desde China.

• Mediante un "netstat -tanp|grep -i 8088" ví que se trataba del proceso Apache público.

• Analizando la configuración de mi propio servidor apache público, ví que el puerto 8088 era un Virtualhost que utilizo a modo de proxy inverso para recibir las peticiones que envía el dispositivo GC101 del coche para indicar la posición detectada vía GPS. Y… he aquí la madre del cordero. La configuración que tenía era:

ProxyRequests On
ServerName miserver.com 

Order deny,allow
Allow from all
ProxyPass /to_be_proxified http://IP_tomcat:Puerto_tomcat/gps
ProxyPassReverse /to_be_proxified http://IP_tomcat:Puerto_tomcat/gps
CustomLog logs/micustomlog combined

Según lo ví… dije WTF!!! casi 4 años trabajando con proxies inversos, y voy y configuro el que es para mi propio uso sin cuidado alguno.

¿Qué estaba sucediendo?

• Apache está escuchando en la IP Pública  en el puerto 8088 y, la intención es reenviar ciertas peticiones (las que lleguen a /to_be_proxified), a otro servidor web, actuando como un proxy.

• Sin embargo, la configuración está muy mal hecha… Por culpa de las prisas fundamentalmente, tomé como referencia un bloque Virtualhost de otro servidor web interno que sí que utilizo como proxy saliente.

• Esta configuración, y sobre todo la línea "ProxyRequests On" lo que permite es que, cualquier máquina que utilice como proxy HTTP la IP pública y el puerto 8088, podrá utilizar mi conexión como "proxy anonimizador".

• Este Virtualhost además tiene definido que almacene logs de las peticiones en el fichero logs/micustomlog. Mirando dicho fichero (que por cierto ya iba en dos días por los 4 GB), veía peticiones de lo más variopintas.

• Si apagaba el servicio Apache, el ancho de banda dejaba de consumirse en los términos anteriores. Estaba claro, este era el problema.

¿Y desde cuándo llevaré yo siendo el objeto de la navegación de vaya usted a saber quién?

Analizando los logs de "micustomlog" ví que afortunadamente esto sólo estaba pasando desde hace un par de días. Fue sencillo puesto que las entradas en dicho fichero son siempre del mismo tipo:

"GET /to_be_proxified/Data?imei=123456789012345&rmc=$GPRMC,blah,V,bleh,N,bloh,W,0.00,xyz,12345,,*00,123.4,AUTO HTTP/1.1" 200 2 "-" "-"

En el momento en que empieza a haber cosas que se salgan de ese patrón, es que alguien ha hecho hit.
Así pues, llega un punto de log se ve lo siguiente:

222.215.230.175 - - [09/Nov/2011:06:36:06 +0100] "GET http://www.graduateszone.com/proxyheader.php HTTP/1.0" 200 5 58 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
222.208.183.218 - - [09/Nov/2011:06:36:32 +0100] "GET http://proxyjudge2.proxyfire.net/fastenv HTTP/1.1" 200 401 " -" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Después, 5 minutos de tranquilidad. A partir de ahí una fiesta de logs con peticiones desde múltiples direcciones IP con destinos de lo más variopintos.

Siguiendo con el análisis, como se puede ver en el extracto del fichero, la segunda entrada del log es http://proxyjudge2.proxyfire.net/fastenv.

Proxyfire, es una herramienta que se define como Cazador de Proxies.

He descargado la herramienta y examinado un poco el contenido. Os aseguro que no tiene desperdicio. Páginas con proxies abiertos, rangos de direcciones IP a escanear, un fichero especialmente interesante llamado "avoid_ip_ranges.txt" que, como podéis imaginar, es un bonito listado de IPs de organizaciones gubernamentales como la NASA, Agencias de Defensa, servidores controlados por el FBI… vamos un sueño recopilado en un único fichero! La primera línea de dicho archivo ya dice explícitamente: "IP Ranges you should not scan".

Durante su ejecución, aparte de permitirte navegar por sitios de dudosa catadura y echar la culpa a otro, Proxyfire dedica una parte de su tiempo a buscar diferentes máquinas mal configuradas por Internet, con proxies abiertos al Mundo. Cuando encuentra una, "llama a casa" y la añade a una lista global, que es descargada periódicamente los usuarios.

Disponen de una versión libre (con sus limitaciones) y una "Profesional". Dios me libre de saber qué tipo de "profesional" necesita pagar por esta herramienta.

En fin, que una vez solucionado el problema de configuración, aún de vez en cuando veo en el log diferentes intentos de peticiones a otros lugares.


Mis dudas y conclusiones

• Aunque los usuarios de este tipo de herramienta, efectivamente anonimizan la IP de sus accesos, al no ser precisamente yo un "proxy anónimo", sino que tengo loggeados los 2 días que tuve las "piernas abiertas", podría darse el caso que si quisiese registrar de una forma más detallada las peticiones que pasan a través de mí, lograría ser un honeypot interesante.

• He leído diversas fuentes que ponen en tela de juicio la seguridad y anonimato que ofrece la conocida red TOR. Sin embargo, en este caso, tu máquina no forma parte de ninguna red ni obtiene un certificado TLS. Con esta herramienta, tú utilizas directamente un proxy abierto de los de la lista, que se supone que no guarda logs, para visitar todo el contenido que desees, haciendo culpable a otro de tus fechorías.

• Señor Juez: si mi dirección IP hubiese roto algo en esos días, mientras servía de pasarela a un montón de chinos que intentan bypassear el Gran Cortafuegos Chino, según las direcciones IP que he extraido de los logs ¿de quién es la culpa?

• Nunca, nunca, nunca publiquéis, con prisas o haciendo muchas cosas a la vez, un servicio a Internet. Ojo con los Copy-Paste, aunque sean de algo que habéis hecho previamente. En mi caso, por reutilizar la configuración de un servicio interno sin demasiado cuidado, abrí una puerta a Internet para que los chinos naveguen sin censura, desde mi IP, utilizando Proxyfire.

Leer más...

Tor en Android con Orbot, proxy incluido y sin root

Ya vimos como hacerlo en iPhone, y ahora es el turno de Android. Hay muchos, muchos artículos en Internet que dan la noticia "Orbot, por fin Tor en Android", pero no he encontrado ninguno en el que se recoja de forma convincente la configuración necesaria. En la mayoría se recurre a programas que necesitan un dispositivo "rooteado" para poder configurar el proxy local y enrutar las conexiones a través de Tor.

Para quien no lo sepa, Orbot es la implementación oficial de Tor para Android. En el propio asistente de configuración de Orbot podemos, si tenemos el dispositivo rooteado, darle al programa la capacidad para que gestione la configuración y que ésta sea bastante más completa.

Lo que vamos a ver no necesitará root ni programas externos, y podremos enrutar toda la navegación a través de Tor. Es importante comentar que sólo lo he probado mediante Wi-Fi, ya que no dispongo de 3G. La versión de Android es la 2.2 Froyo.

En primer lugar iniciamos Orbot, que nos abrirá dos puertos locales. El 8118 con un proxy HTTP y el 9050 con un proxy SOCKS.

Para continuar abrimos la configuración de Wi-Fi, una vez ahí pulsamos la tecla de Menú y vamos a la configuración avanzada para configurar el proxy de la siguiente manera.

Abrimos el navegador estándar de Android para verificar que navegamos a través de la red Tor ...

¡Y ya está hecho!

Hay que tener cuidado ya que parece que no todas las aplicaciones hacen caso de la configuración de red general. Si probamos navegar a través de Opera Mini o Dolphin (por cierto, excelente navegador) no nos enrutan vía Tor. Captura de ejemplo en Dolphin:

Si bien la configuración del proxy de la red está un poco escondida, una vez encontrada no tiene mayor dificultad.

Leer más...

Nueva versión de OWASP Zed Attack Proxy 1.1.0

Tras la muerte y descontinuidad de Paros Proxy, (los programadores se quisieron volcar en otra herramienta, antes que continuar la que tenían), programa de interceptación de peticiones HTTP que incluía un pequeño motor de detección de vulnerabilidades, apareció Zed Attack Proxy (también conocido como ZAP), hospedado como proyecto de OWASP. También contábamos con Andiparos, pero seguramente tanto Andiparos como ZAP formarán parte del mismo proyecto muy pronto. En esta ocasión, y para la nueva versión, Andiparos ha aportado la versión para la plataforma MacOS X.

Un ligero cambio de diseño (no es lo más importante), mejora de sus funcionalidades extras como son el filtrado de peticiones, enumeración de recursos y análisis de vulnerabilidades...realmente lo más importante es que porfin alguien haya rescatado el proyecto Paros Proxy y lo mantenga, además de aceptar nuevas ideas.

Y por ello, este Diciembre nos ha traido una nueva versión de ZAP, la 1.1.0, que incluye los siguientes cambios o aporta estas nuevas funcionalidades que comentamos a continuación (puedes consultar todas en este enlace):

• Aceptación como proyecto OWASP, con todo lo que ello conlleva (es una gran noticia, sobretodo por la comunidad que hay detrás y que seguro puede aportar nuevas ideas)
• Fuerza bruta para enumeración de recursos, basadandose en el otro proyecto de OWASP Dirbuster.
• Soporte de smartcards, cada vez más webs soportan estos dispositivos como medio de autenticación, algo que nos alegra.
• Posibilidad de escaneo de puertos desde el propio programa.
• Soporte de nuevos lenguajes, incluye el español.

Nuevas pestañas que muestran las nuevas funcionalidades.

Estamos seguros de que con la llegada de este proyecto a formar parte de la comunidad OWASP, poco a poco conoceremos más funcionalidades que se vayan añadiendo, y que harán que esta herramienta no se conozca únicamente como se le conocía al Paros, el simple proxy para modificar peticiones escrito en Java.

[+] Página del proyecto Zed Attack Proxy en Google Code y en la wiki de OWASP.
[+] Novedades de Zed Attack Proxy 1.1.0
[+] Descarga ZAP 1.1.0 para Windows, Linux y MacOS X

Leer más...

Las debilidades de El Gran Cortafuegos Chino desde dentro

Ya se ha hablado mucho del 'Great Firewall' chino, desde su descripción hasta fallos en el sistema, pasando por algunos detalles técnicos.

Sin embargo es un tema que sigue presente, y cada cierto tiempo sale la noticia de que han bloqueado otro servicio más.

Quería ponerme en la piel de los afectados por el firewall, y la forma más asequible de hacerme una idea era ponerme detrás de un proxy chino al que le afecten las restricciones. Vamos a ver qué nos encontramos.

El primer paso es encontrar un proxy chino para navegar a través de él, una tarea fácil.

Una vez preparados y habiendo probado que todo funciona bien, nuestra ardua tarea será intentar conectarnos a Wikileaks, uno de los puntos calientes del firewall (en cuanto a censura se refiere). A partir de ahora deberíamos ser como cualquier ciudadano de China, por lo menos a nivel de conexión (sin "plugins" en nuestro sistema). Puede que la experiencia no sea exactamente la misma, pero podemos hacernos una idea bastante aproximada. Es importante entender que todo lo que hagamos a partir de ahora será pasando por China, sujetos a las restricciones que están impuestas por el firewall chino.

Como esperábamos, en un principio no podemos entrar a Wikileaks, el navegador nos da a entender que el sitio no está disponible (conexión reseteada). Vamos a ver que está pasando por debajo:

El navegador envía la petición al proxy para visualizar Wikileaks, pero el proxy resetea la conexión constantemente. Después de esto se aplica un baneo de unos minutos, en el que todas las peticiones serán reseteadas de igual forma. Parece que el bloqueo se basa en esto, resetear la conexión por el lado del cliente y bloquear las próximas peticiones durante unos minutos (¿a modo de castigo?).

A partir de aquí, mediante diferentes métodos vamos a intentar conectarnos a nuestro objetivo que, no lo olvidemos, es Wikileaks. Vamos a empezar con las soluciones más potentes para después llegar a "trucos" muy simples.

1.- Lo primero que vamos a intentar es llegar a Wikileaks a través de un proxy web al que nos conectaremos mediante HTTPS para que el tráfico no sea legible.

Parece que nuestra primera prueba ha funcionado, ¡hemos conseguido saltarnos la restricción por primera vez!

2.- Vamos a hacer una segunda prueba usando el mismo método pero esta vez sin HTTPS y en otro proxy web diferente, a ver si el firewall detecta ahora el "engaño".

Volvemos a pasar sin problemas.

Según parece, en cuanto al uso de proxies web lo importante es que el host donde está alojado no esté en la lista negra. Es conviene usar HTTPS para que en un análisis de tráfico manual, o mediante la búsqueda de "palabras prohibidas" no nos detecten.

3.- Vamos a probar otra cosa. Wikileaks nos ofrece muchos Cover Domains, nombres alternativos para poder entrar en caso de que nos bloqueen el acceso al sitio original. Vamos a intentar entrar a través de alguno de estos nombres alternativos. Después de probar un par ...

Si intentamos entrar desde el dominio sunshinepress.org se nos permite el acceso, sin ningún tipo de restricción.

4.- Lo último que vamos a probar es algo muy sencillo. Vamos a visitar Wikileaks a través de su dirección IP, de forma que no tengamos que resolver su nombre DNS. Las IPs son 88.80.17.21 y 88.80.17.18, vamos a ver que sucede.

Como podemos ver, no nos resetean la conexión en China (nos responen ACK a la petición), y podemos visitar Wikileaks sin problemas.

Métodos tan sencillos como estos permiten sobrepasar las medidas que pretende implantar El Gran Cortafuegos Chino, sin contar con otros más complejos y efectivos como son el uso de Tor, SSH, VPNs ...

Resumen del artículo:

1. Nos conectamos a un proxy chino para que nos afecten las restricciones del firewall. Desde aquí hasta el final siempre estará el proxy chino por debajo.
2. Hacemos una peticion web a pelo a http://wikileaks.org/ -> Denegada (RST).
3. A través de proxy web con HTTPS -> Ok.
4. A través de proxy web sin HTTPS, es decir, con HTTP -> Ok.
5. Conectamos a través de un Cover Domain de Wikileaks -> Ok.
6. Conectamos directamente a las IPs de Wikileaks, sin DNS -> Ok.

----

Añadiendo un pequeño adjunto a este artículo, me gustaría decir una cosa. Seguro que alguien ya se ha dado cuenta, como podéis ver no estoy publicando este artículo desde Colaboraciones, sino desde una cuenta propia. Esto quiere decir que a partir de aquí, ¡formo parte del equipo de Security By Default como editor! Empiezo con muchas ganas (al igual que cuando enviaba colaboraciones), y me gustaría agradecer a SbD el brindarme su confianza. Espero poder aportar mi granito de arena :)

Leer más...

Montando nuestro propio proxy web

Seguro que todos hemos usado alguna vez un proxy a través de una web, caracterizados por ser cómodos y funcionar bien. Sin embargo muchas veces para poder usar el servicio plenamente hay que pasar por caja, además de que estamos haciendo uso de algo que nosotros no administramos, por lo que no sabemos si nos están monitorizando, ni qué datos se guardan. La solución a todo esto es montarnos nuestro propio proxy web, y lo podemos hacer programándolo nosotros mismos o usando alguno ya hecho.

PHProxy es un proxy web de código abierto escrito en PHP, y aunque el proyecto está inactivo desde 2007, han surgido otros proyectos que lo mantienen actualizado y lo han mejorado, al final de la entrada están los enlaces.

Tienen la ventaja de que se pueden montar en casi cualquier alojamiento que soporte PHP, incluidos los gratuitos. Una vez subido el funcionamiento es muy sencillo, y hay a nuestra disposición bastantes opciones de navegación y de ofuscación / codificación.

Además, si nuestro servidor admite HTTPS podemos cifrar el tráfico en ese tramo, lo que nos añade una capa de privacidad muy interesante.

Todos los proyectos son muy personalizables, y tienen más opciones que se pueden administrar de forma muy sencilla modificando el código fuente. Si quereis probarlo sin instalarlo, a poco que busqueis en google encontrareis varias páginas donde está disponible (muchas veces personalizado, y/o con publicidad).

Enlaces a los proyectos:

[+] PHProxy

[+] phpr0xy

[+] a2freedom

Artículo por Alberto Ortega Llamas.

Leer más...

Haciendo el Ciber Houdini

Harry Houdini fue un famoso mago que se granjeo fama a base de realizar actuaciones en las que, el plato fuerte, eran los trucos de escapismo por el cual el simpático mago conseguía zafarse de tanques de agua, gruesas cadenas y toda suerte de esposas y candados que pretendían retenerle.

En muchas ocasiones, por diversas circunstancias, el entorno en el que estamos conectados tiene el acceso al exterior restringido mediante un Proxy http, a priori, este Proxy restringe el uso de ciertos protocolos y en otros casos nos obliga a usar versiones web de esos protocolos (por ejemplo, mensajería instantánea). Adicionalmente, es posible que el Proxy tenga restricciones sobre el tipo de paginas web “aceptables”, por no hablar de la falta de privacidad que supone navegar teniendo la certeza de que toda nuestra navegación se esta registrando con todo lujo de detalles.

Desde SBD vamos a proponer un sistema para poder “escapar” de todo lo expuesto anteriormente y conseguir acceso ilimitado con privacidad adicional.
Para ello necesitamos unos cuantos requerimientos tanto en el entorno como en las herramientas. Para poder poner en practica esta técnica necesitamos:

• Una maquina con conexión permanente a Internet (vale un ADSL)

• Que esa maquina sea unívocamente localizable (ya sea mediante una IP fija o una dirección IP dinámica accesible a través de un nombre DNS fijo conseguido a través de DynDNS

• Un host que ejecute alguna versión de Linux o *BSD accesible a través de la dirección anterior con el puerto 443 disponible

Una vez tengamos esos requisitos, procedemos a instalar el software necesario para poder “saltar”.
En la maquina Linux / *BSD necesitamos instalar un servidor OpenSSH (sería extraño que no formara parte del software base) y un software de tipo Proxy-Socks llamado Nylon . Este software debería compilar correctamente en cualquier sistema Unix.
Todo eso es para la parte “servidor”, en la parte cliente (basada en windows) únicamente necesitamos tener disponible el software Putty

Configuración Servidor

Asumiendo que ya tenemos instalado el servidor OpenSSH y Nylon, vamos a configurar primero el servidor OpenSSH para que escuche en el puerto 443. El motivo de hacer esto es porque para realizar una conexión “limpia” a través de un Proxy http solo se puede realizar empleando el método CONNECT y la mayoría de los proxys tienen restringida esa funcionalidad para que se realice contra puertos 443.

Editamos /etc/ssh/sshd_config y añadimos Port 443 para que escuche también en ese puerto, re-iniciamos el servicio y comprobamos que al ejecutar telnet localhost 443 aparece el banner de OpenSSH

$ telnet localhost 443
Trying 127.0.0.1...
Connected to localhost
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3

El siguiente paso es configurar el Proxy Nylon que será el que nos permita hacer uso de cualquier aplicación que implemente conectividad a proxys socks (MSN Messenger, firefox, Explorer …)
La forma de configurar el Proxy es ejecutarlo de la siguiente forma:

/usr/local/bin/nylon -s -a 127.0.0.1 -i lo

Ejecutándolo de esta forma, el proxy únicamente es accesible en la dirección local (no podría usarse directamente desde Internet, evitando que algún amigo-de-lo-ajeno lo empleé para hacer el mal) Lo interesante es que añadas a tu rc.local (si usas Redhat/Fedora/Centos) o /etc/init.d/bootmisc.sh (Si usas un sistema basado en Debian) la ejecución de Nylon para hacer que, en futuros re-inicios, el proxy esté disponible.
El ultimo paso que hay que hacer es crear una cuenta en el sistema para conectarnos, valdría cualquier cuenta con login habilitado pero por motivos de higiene es recomendable crear una cuenta nueva, por ejemplo, salto:
#adduser salto
#passwd salto
Con esto quedaría configurado nuestro servidor de salto, ahora veamos la configuración de la parte cliente basada en Putty.

Configuración cliente

Primero de todo debemos crear una nueva sesión en putty a la que llamaremos “salto” y en ella configuramos la maquina donde tenemos ejecutando OpenSSH y Nylon


El siguiente paso es configurar el proxy interno HTTP del lugar en el que nos encontremos, tenemos que especificar el host, el puerto, nuestro usuario y contraseña


El siguiente punto es crear el túnel inverso por SSH para poder acceder a Nylon, para ello configuramos Putty de la siguiente forma:



pulsamos “add” y la configuración queda de la siguiente forma:


Una vez realizada la configuración, la salvamos


El último paso es pulsar “Open” y acceder a nuestra maquina de salto, si todo funciona como es debido, en nuestra maquina cliente tendremos abierto el puerto 1080 que a su vez estará conectado con el puerto 1080 (donde escucha Nylon) de nuestra maquina de salto. Lo ultimo que nos queda es re-configurar nuestras aplicaciones para que usen un proxy socks en la dirección 127.0.0.1 puerto 1080


Feliz navegación !

Leer más...