Otro título sugerido: Como hacerle la vida imposible a tu sysadmin – parte 2
Si no leyeron el artículo anterior: Como hacerle la vida imposible a tu sysadmin deberían empezar por ahí para entender de que estoy hablando. Para los cortos de tiempo resumo brevemente:
Por un lado: Tenés acceso a una PC que remotamente corre Linux, puede ser un servidor que administres o la PC de tu casa, da lo mismo. No hace falta disponer de privilegios de super-usuario en la PC remota. Esta PC remota corre un servidor SSH que te permite login remoto.
Por el otro: La persona que administra la red de tu trabajo te tiene impedido, no te permite chatear, usar Facebook o Twitter, no podés navegar por ciertas páginas o usar ciertos servicios.
Otra posibilidad: Estas conectado desde una red «pública» en un bar, aeropuerto o simplemente robándole internet el vecino y no tenés ninguna manera de saber quien podría estar olfateando los paquetes de datos que van y vienen, sobre todo ahora, que herramientas como Firesheep hacen que un ataque man-in-the-middle que siempre fue cosa reservada para unos pocos elegidos sea coser y cantar.
También podrías usar este sistema (o un buen tunel SSH por cada servicio a rutear haciendo las veces de Socks Proxy con todas las incomodidades que conllevaría) si estás conectado desde un enlace poco fiable en donde la pérdida de paquetes está fuera de discusión.
O si ninguna de las anteriores te convence: Simplemente por que nunca se es lo suficientemente paranoico, otro mini tutorial: Como encriptar TODO el tráfico que genera tu PC y rutearlo remotamente para evitar cualquiera de los escenarios anteriores.
¿Y por que no simplemente una VPN o un tunel SSH pensarán ustedes? Por todo lo siguiente:
- No necesitas instalar una VPN en ambas puntas.
- No necesitas privilegios administrativos en el servidor.
- El servidor no necesariamente tiene que correr Linux.
- Ni siquiera Hamachi es lo suficientemente simple en comparación.
- Nunca vas a perder paquetes, la sesión SSH puede que pierda paquetes, inconveniente que TCP se encargará de solventar por vos con lo que tu conexión se vuelve mucho mas confiable.
- No necesitás instalar nada en ninguno de los dos extremos, solo el interprete de comandos Python (Si llegaste hasta acá, sabés de que estoy hablando y obviamente tenés Python instalado).
- Si quisieras routear mas de un servicio por medio de un tunel SSH deberías establecer una sesión SSH por cada uno de ellos y hacer uso de la tabla nat de iptables para redirigir paquetes, muy complicado de implementar cuando lo único que necesitás es una conexión fiable y encriptada y la necesitás ya mismo.
Ahora si, a los bifes:
Toda la magia radica en una maravillosa pieza de software escrita en Python por un tal Avery Pennarun que ha sido dada en llamar sshuttle (que conveniente) que se encarga de crear un tunel SSH a modo de proxy transparente y reenviar todo el tráfico que generan todas tus aplicaciones –salvo por las peticiones a los servidores de DNS, seguramente pensando en un relay local con caché, pero inclusive esto último también se puede enviar por el tunel llegado el caso– hasta un script también basado en Python que sshutlle se encargó previamente de subir y poner a correr en el servidor remoto. Este script es el que recibe el tráfico y lo reenvía de ida y vuelta. Todo lo anterior a su vez gracias a un par de reglas de redirección basadas en iptables con lo cual ni haría falta que te lo especifique pero va por las dudas, los requisitos:
- Git
- Python
- Iptables
Complicadísimo, ¿No?
Salvo contadas excepciones, lo mas probable es que el Linux desde el que me estás leyendo ya venga con todo lo anterior preinstalado de serie así que ni te molestes. Si por otro lado, usás Windows, he aquí otra excusa mas de entre las tantas para tener siempre un Linux a mano.
¿Como se usa?
Mas facil, imposible: Primero, descargar sshuttle en cualquier lugar en donde te quede cómodo, se creará el directorio sshuttle automáticamente, como siempre:
git clone git://github.com/apenwarr/sshuttle
Habéndote posicionado en el directorio sshuttle –como root– lo ejecutás:
./sshuttle -r <usuario>@<servidor>:<puerto> 0/0
Y eso es todo. Para configuraciones mas complejas basta con ejecutar ./sshuttle para hacerse de la ayuda en pantalla.
El 0/0 del final no es mas que la abreviatura de 0.0.0.0/0 y hace referencia a subred desde la cual se considerará tráfico como permitido para transitar el túnel, esto es útil cuando por ejemplo la PC que establece el túnel es además el router de toda una subred con lo que podés cambiar el número de IP WAN de toda tu red en un santiamén para saltear las restricciones de algún servidor de descargas mal habido. Restringir el tráfico solo a una porción de tu subred puede servirte también para esos casos en que no confiás en todos tus usuarios.
Que les sea leve.
Pinta buenisimo, pero si no entendí mal, la pc en la que estás sentado navegando necesitaría correr Linux, lo cual no sería un drama si es tu propia notebook, pero si se complica si querés usar este método desde un locutorio por ejemplo… o la pc de una facultad/oficina/etc, en ese caso, mejor sería el metodo 1, no?
Saludos!!
Si Coski, ¿No tenés Linux en tu notebook? 😀
EL método 1 es mucho mas facil de implementar pero no todos los programas te permiten usar un proxy como intermediario y ahí es en donde entra en juego el «método 2».
¡Saludos!
El problema es q no tengo notebook! 😛
En mi desktop si tengo linux obviamente, y tu método 1 lo usé alguna q otra vez al estar en un locutorio/ciber, o en la facu…
Cuando pueda llegar a una notebook, obviamente voy a tener listo este método!
saludos!
Jeje, bueno, ya llegará el glorioso dia en que te vuelvas portatil, ahi sí que te va a venir bien el asunto este.
¡Saludos!