Hay momentos donde necesitamos tener plena seguridad de que los datos que son transmitidos desde nuestra máquina hacia internet no son leídos por terceros (¡eso sería siempre!), cómo cuando vamos a un café con wireless disponible ó un congreso lleno de ávidos “hackers” todos con sus sniffers llenando sus logs de contraseñas de terceros y luego aparecen los blogs de “hackers éticos” “defaceados” (ñ_ñ). En fin, necesitamos seguridad, y no todo lo que usamos se encuentra bajo SSL, ó no sabes que tiene la opción, por ejemplo, ¡levante la mano quien usa twitter con https!. Hay otras situaciones molestas como cuando un maldito proxy nos filtra contenido, no podemos ver todos los sitios ó usar todos los servicios que necesitamos, o simplemente nos cierran puertos que necesitamos, como el sagrado IRC.
Bien, para todos estos males existen los túneles SSH, quienes realizan una conexión segura, encriptada, y desde un servidor remoto, por lo que nuestro origen queda anónimo. Todo lo que necesitas es una máquina en una red externa (típicamente un servidor) en la que tengamos acceso ssh. Según la necesidad, podemos requerir de 3 diferentes esquemas:
- Estás tras un proxy y no te deja salir a todas las redes o te filtra sitios que realmente necesitas. ¡Tú necesitas Dynamic application-level port forwading!
- Te cerraron los puertos y necesitas acceder a algún servicio del servidor A con el puerto XX. ¡Tú necesitas Local Port forwarding!
- Estás tras un router, con ip privada y necesitas que alguien entre a algún servicio de tu máquina sea HTTP, SSH, FTP, etc. ¡Tú necesitas Reverse Port Forwarding! (también llamado Remote port forwarding)
1. Dynamic application-level port forwarding
El esquema mas sencillo, funciona como un proxy para cualquier aplicación para cualquier servicio, SMTP, HTTP, POP, IMAP, etc. Bajo este esquema, puedes redireccionar todo el tráfico de un puerto local hacia un servidor remoto a través de otro servidor “de redirección” para cualquier tipo de aplicación que trabaje con protocolo Socks, aunque en la mayoría de los casos si no lo soporta puedes forzarlo con una utilidad que veremos mas adelante. En pocas palabras, haces que un servidor B baje por ti el contenido del servidor A y lo reenvíe a tu máquina local.
El escenario es el siguiente, tienes tu maquina “local” restringida, y tienes acceso a “shell.server.tld” y quieres usar la conexión abierta de “shell.server.tld” para que te reenvíe todo hacia “local”, esto lo hacemos mediante:
fulanito@local $ ssh -N -D 8888 shell.server.tld
La opción -N es para que no lanze ningún comando al hacer la conexión, solo establezca el tunel. Puedes añadir -f para que además se vaya a background. Y claro añade las opciones que necesites como -pPuerto -lUser, etc. para realizar la conexión ssh.
Y listo!, ahora vamos al Firefox (¿que?, ¿que no usas firefox? ¿en que mundo vives? osea jelou!) y en Edit->Preferences->Advanced->Network->Settings , seleccionamos “Manual proxy configuration” y en la entrada de text de “Socks Host” metemos 127.0.0.1 puerto 8888, desde luego puedes cambiar el puerto por otro aquí y en el comando ssh. ¡Presto! ahora ve a tu firefox y abre, digamos, http://www.whatismyip.org/, verás como ya estás saliendo desde la ip del servidor “shell.server.tld”
Si estas usando algún programa que no soporte Socks, puedes instalar “tsocks” y configurar en /etc/tsocks.conf la conexión. Por ejemplo hasta el final del archivo yo tengo:
server = 127.0.0.1
server_type = 5
server_port = 8888
Ahora, abre el tunel con el comando antes descrito, y posteriormente corre tu programa anteponiendo “tsocks”, por ejemplo:
fulanito@local $ tsocks opera
Et voilá!. Está de mas decir que puedes abrir mas de una conexión y usar varios navegadores saliendo por diferentes IP’s. Muy útil cuando andas mmm digamos, analizando un sitio de forma anónima ;-).
Local Port forwarding
Ahora sí vamos a forwardear puertos de verdad, El anterior esquema es a nivel aplicación, SSH entiende que debe servir de proxy para lo que le pida la aplicación, si pides la página de google por socks, ssh entiende que tiene que conectarse a google y reenviar el contenido a tu máquina local a través de un tercer servidor, y dinámicamente cambia del servidor de google al de yahoo, o hotmail, o facebook, etc. En este esquema de Local Port forwarding (y también el Remote/reverse port forwading) SSH simplemente reenvía todo lo que mandes a un puerto local hacia un servidor destino a través de un servidor donde tienes shell. Es decir, sólo puedes redirigir el tráfico hacia un sólo servidor. Usemos el vano ejemplo del IRC, no se porque siempre nos bloquean el puerto IRC (6667) así que tenemos el escenario:
Estamos en maquina “local”, tenemos acceso shell a “shell.server.tld” y queremos conectarnos a irc.freenode.net. Lo que tenemos que hacer es lo siguiente:
fulanito@local $ ssh -N -L 3337:irc.freenode.net:6667 shell.server.tld
Y listo, tenemos un tunel desde nuestra máquina en el puerto 3337 a irc.freenode.net:6667 a través de shell.server.tld. Ahora todo lo que nos queda hacer es:
fulanito@local $ irssi -c localhost -p 3337
Y irssi nos mostrará el MOTD (Message Of The Day) de freenode, tal y como si nos estuvieramos conectando directamente desde shell.server.tld.
Y claro, podemos usar el tunel para diversos servicios:
- Para conectar a un proxy externo:
fulanito@local $ ssh -N -L 1080:proxy.server.com:8080 shell.server.tld - Para conectarse a un servidor POP:
fulanito@local $ ssh -N -L 1110:pop.server.com:110 shell.server.tld - Para conectarnos al webserver de una máquina de la chamba:
fulanito@casa $ ssh -N -L 8080:maquinadelachamba:80 maquina-con-ip-externa-de-la-chamba.dyndns.com
Con este ejemplo aprovecho para mencionar un pequeño detalle: cuando especificamos “-L puerto:hostdestino:puerto shell.server.tld”, ponemos a “hostdestino” tal y como “shell.server.tld2 lo vé, es decir, si “shell.server.tld” puede ver a maquinas con ip’s privadas dentro de su red, podremos especificar en -L una ip privada, por ejemplo: “ssh -N -L 8080:192.168.1.100:80 189.10.20.30
Reverse/Remote Port forwarding
Este esquema es quizás el más divertido y confuso de los tres, basicamente es lo mismo que -L pero “en inversa”, expliquemos.
Con -L le dices a ssh que reenvíe el tráfico que vaya a un puerto local hacia uno remoto, con -R le dices a ssh que reenvíe el tráfico que llegué a un puerto remoto hacia uno local. ¿Para que nos sirve algo así?, pongamos dos escenarios:
1. El Soporte Técnico.
Tienes un problema con tu linux/mac os x/unix/whatever, y quieres que un amigo se conecte a tu máquina para ayudarte y estas detrás de un router, con ip privada, y sin privilegios para poder abrir un puerto en el router que redirija el tráfico a tu máquina. Solución, abres un tunel “reverso”:
fulanito@local $ ssh -N -R 2200:localhost:22 shell.server.tld
Lo cual quiere decir: “abre un tunel desde shell.server.tld en el puerto 2200 que reenvíe el tráfico hacia mi máquina (localhost) en el puerto 22”. Y ahora le dices a tu amigo que se conecte a shell.server.tld y desde ahí el tiene que correr:
sutanito@shell $ ssh -p2200 localhost
Y se reenviará la conexión hasta tu máquina, en otras palabras, podrá conectarse a tu máquina desde otra, pero sólo mientras mantienes abierto el tunel. Por default, todos los túneles escuchan sólo a la interfaz loopback, es decir, solo aceptan conexiones desde la misma máquina en donde se está abriendo el tunel, es por ello que tu amigo debe primero entrar a shell.server.tld y luego conectarse a “localhost”. Existe la posibilidad de que tu amigo se conecte directamente a shell.server.tld:2200 desde su máquina, eso lo veremos en el siguiente ejemplo:
2. Publicar un servicio.
Ahora, digamos que estas en un starbucks, o algo así. Y necesitas enseñar lo que tienes en tu webserver local a un cliente, como ya establecimos, no puedes abrirte un puerto para que el cliente mire hasta tu máquina con ip privada. Solución, abres un tunel “reverso”:
fulanito@local $ ssh -N -R 8888:localhost:80 shell.server.tld
Y listo, el túnel leerá la página de tu máquina y la servirá a través de shell.server.tld:8888, entonces le das a tu cliente la dirección http://shell.server.tld:8888/
Pero como decíamos en el anterior ejemplo, los túneles solo atienden a “localhost” por lo que para que tú cliente pueda acceder directo a shell.server.tld:8888, debemos agregar una opción al final del archivo /etc/ssh/sshd_config:
GatewayPorts yes
Y listo ahora los túneles escucharán en cualquier interfaz.
Nota:
Ten en mente siempre, la información viajará encriptada solamente desde tu máquina local hacia el servidor donde estás estableciendo el tunel, de acuerdo a nuestros ejemplos, la información viajará encriptada desde local <=> shell.server.tld, pero desde shell.server.tld <–> irc.freenode.net (u otro destino final) no estará encriptada. En el 99% de los casos esto servirá para mantener tus datos seguros.
Y bien, espero me haya sabido explicar, si creen que algo está demasiado confuso por favor, exprésenlo en un comentario. Si tienen mas ideas de como usar los túneles SSH, ó tienen una anécdota sobre alguna vez que tuvieron que ingeniárselas para resolver un problema usando túneles SSH, por favor, compártanla.
NaCl U 2