Soporte SOCKS con SSH. O cómo navegar de forma ‘más segura’

socks.pngssh cada vez me sorprende más. Las posibilidades que ofrece son inmensas, es com una navaja suiza de las comunicaciones. Al principio sólo lo usas para conexiones seguras. Luego le vas sacando punta con el uso de claves públicas, más tarde te enteras de la posibilidad de port forwarding, luego de la posibilidad de montar por ssh en local un directorio remoto, y ahora del soporte de port forwarding dinámico, es decir, del soporte SOCKS, que la Wikipedia define como: » protocolo de Internet que permite a las aplicaciones Cliente-servidor usar de manera transparente los servicios de un firewall de red. SOCKS es una abreviación de ‘SOCKetS'».

¿Y traducido al castellano? 🙂 Veámoslo con un caso práctico. En la facultad, tienes una conexión a Internet buena, pero no te fías de posibles intrusos, sniffers y demás. Y quieres actualizar tu blog a través de una conexión http (lo ideal sería https, pero…) sin que tu password vaya a caer al saco de los passwords capturados. Te gustaría enviar la información web cifrada SIEMPRE, independientemente de si usas http o https (al menos, te gustaría enviarla cifrada hasta un punto seguro, a partir del cual, te fías más y desde el que no te «molesta» tanto que vaya sin cifrar). Además, has leído que, si dispones de acceso ssh a algún servidor, puedes usarlo como trampolín (la información viajará cifrada hasta ese servidor y a partir de ahí, se usará como puente hacia la web que quieras acceder. La respuesta será recogida por el servidor ssh y éste nos la devolverá cifrada).

Bien, éste es el procedimiento: vamos a configurar un servidor SOCKS con ssh. Para ello:


$ ssh -l usuario -f -N -D 1082 servidor.com sleep 7200 <--- tenemos acceso ssh a servidor.com Ahora, en Firefox, abrimos Editar/Preferencias/Avanzado/Red/Configuración/ Seleccionamos Configuración manual del Proxy y en la casilla "Servidor SOCKS" ponemos: localhost En la casilla puerto, ponemos: 1082 (el mismo que hayamos elegido en el comando ssh anterior, no tiene por qué ser 1081) Pulsamos Aceptar y Cerrar. Ya puedes navegar de forma "algo más segura" 🙂 (¡y usando la IP del servidor SSH !) Esto último puede tener muchos e interesantes usos... Nota: -f es para hacer fork del proceso. -N es para evitar que se ejecuten comandos en la sesión ssh abierta. sleep 7200 es un comando cualquiera que no hace nada (para poder usar -f hay que dar un comando inicial a ejecutar. A partir de ahí el proceso se quedará residente en segundo plano.)

6 comentarios en «Soporte SOCKS con SSH. O cómo navegar de forma ‘más segura’»

  1. Lei hace tiempo que haciendo esto, las peticiones dns aun las hace el navegador a traves del servidor dns configurado en la maquina en vez de a traves del proxy socks, con lo cual aunque no puedan ver lo que ves, ni tus passwords, si pueden saber a que servidores te conectas, asi que si vas a pornoeneltrabajo.com o cualquier otra cosa que no quieras que sepan que haces, sigues teniendo un problema.

    Alguien puede confirmar esto? como solucionarlo?

  2. elui: ¡muy buena pregunta! Se me pasó este DNS leak y tienes razón, Firefox, por defecto tiene esta fuga de información no ‘sockificada’ por las consultas DNS . *PERO* buscando en el sabio, he encontrado esta joyita: abre la url especial de configuración: about:config en Firefox. Busca: network.proxy.socks_remote_dns
    Pásala de false a true. Magia!

    Que conste que esta técnica no debe usarse para webs como la que citas 😉

  3. En mi caso (debian testing) no hace falta poner el «sleep 7200», parece que el -N funciona como debe.

    Mis sorpresas con el ssh han sido justo en el orden que las mencionas… que haría yo sin ssh (y sin putty)

  4. Hola
    He seguido paso por paso este excelente feature y va muy bien, pero ando preocupado por el tema de que las urls siguen viendose. Como comentais, con el parametro network.proxy.socks_remote_dns, pero…….
    Com ese parametro a true no me funciona, y en la consola, donde creo el tunel, sale esto:
    channel 2: open failed: administratively prohibited: open failed
    channel 4: open failed: administratively prohibited: open failed
    channel 6: open failed: administratively prohibited: open failed

    Leyendo por ahi, decia que posiblemente el parametro AllowTcpForwarding estaba a «no» en el sshd.config. Lo he cambiado, restart al servidor ssh, pero nada, sigue sin funcionarme.

    Es algun parametro del tunel que no hago bien? Os ha pasado esto?

    Yo uso este comando => ssh -N -l user_remoto -D 6565 ip_maquina_remota

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.