SSH Tunneling
Imagínate que durante tus vacaciones en el Caribe, tienes la suerte de alojarte en un hotel que ofrece a sus clientes conexión wifi. Imagínate también que, por el motivo que sea, esa red wifi no está cifrada (o que, simplemente, desconfías del cifrado WEP). Por último, imagínate que necesitas hacer uso de esa red para conectarte a internet, bien para leer el correo, para conectarte al Messenger o simplemente para navegar. Cualquiera con dos dedos de frente se pararía a pensar: "Ehh, ¿y si alguien está esnifando el tráfico wifi?".
Pues bien, hay una técnica (entre otras tantas) que nos permite protegernos frente a redes inseguras, siempre y cuando tengamos acceso a un servidor SSH (como una cadena es tan fuerte como el más débil de sus eslabones, la máquina que corre el servidor SSH debería estar conectada de forma segura al servicio de intenet al que queremos acceder. En la mayoría de los casos, esto significa que la máquina debe tener simplemente una conexión segura a internet). Ésta tecnica consiste en la redirección de puertos, que openSSH implementa mediante los parámetros -L y -R (el parámetro -D también sirve para esto, pero a mi parecer es mucho menos potente). Nosotros solo vamos a ver el uso de -L, pues -R tiene un uso bastante similar.
La forma general de usarlo es la siguiente:
$ ssh -L puerto-local:maquina-destino:puerto-destino usuario@ssh-server
tras lo cual, si no tenemos llaves SSH, nos pedirá la contraseña de usuario-remoto.
Con esto, lo que hacemos es decirle al protocolo openSSH: "ponte a escuchar en el puerto 'puerto-local' de mi máquina, y todos los paquetes que recibas en ese puerto, encríptalos y mándalos cifrados a la máquina 'ssh-server' (logueándome como 'usuario'), la cual se encargará de descifrar los paquetes y, a su vez, reenviarlos al puerto 'puerto-destino' de la máquina 'maquina-destino' ".
Si el nombre de usuario que tenemos en la máquina local es el mismo que el que tenemos en la máquina con servidor SSH, podemos omitir la parte 'usuario-remoto@', pues openSSH buscará un usuario con el mismo nombre que el del cliente SSH.
El redireccionamiento entre el servidor SSH y la máquina-destino se hace de forma insegura (sin cifrar); por ésto es necesario que la conexión entre estas dos máquinas sea lo más segura posible.
Llegados a este punto, se pueden dar dos casos:
1- Que la máquina que ofrece el servicio que queremos utilizar (mail server, IRC server, etc.) sea la misma que corre el servidor SSH.
2- Que el servidor SSH y el servicio en cuestión estén en máquinas distintas.
Pero viendo algunos ejemplos seguro que queda mucho más claro:
Para el primer caso:
Imaginemos que estando en una red LAN (la del curro, por ejemplo) tenemos salida a internet a través de un proxy que escucha en el puerto 8080 y cuya IP es 192.168.1.1, y que todos los PCs están interconectados mediante un hub. Además, da la casualidad de que el servidor proxy corre también un servidor de openSSH. La manera normal de navegar sería configurando nuestro Firefox para que se conecte a internet mediante el proxy (en 192.168.1.1) a través de su puerto 8080. Pero, mierda, cualquier jaquer con un sniffer podría espiarnos. Pues bien, podemos blindar nuestra navegación web (o por lo menos, la parte 'local') a prueba de mirones con la siguiente línea:
$ ssh -L 8080:localhost:8080 192.168.1.1
y cambiando la configuración de Firefox, para que en vez de conectarse a '192.168.1.1:8080' lo haga a 'localhost:8080'.
(En este caso hemos supuesto que los usuarios local y remoto son iguales).
En el segundo caso:
Supongamos que queremos acceder, desde cualquier lugar del mundo, al servidor de correo de la empresa en la que trabajamos, pero resulta que dicho servidor sólo acepta conexiones provenientes de la misma LAN en la que se encuentra. Supongamos también que el router (cuya IP en internet es 80.20.40.60) que conecta la LAN interna de la empresa con internet tiene instalado un servidor SSH. Pues bien, a través de dicho router, y gracias a openSSH, podemos acceder al servidor de correo (que por ejemplo está alojado bajo la IP 10.0.0.30 dentro de la LAN) de la siguiente forma:
$ ssh -L 10025:10.0.0.30:25 pepito@80.20.40.60
Ya sólo nos queda configurar nuestro cliente de correo para que se conecte a localhost:10025.
Y recuerda: sólo root puede redirigir los puertos que están por debajo del 1024 (puertos privilegiados).
Pues bien, hay una técnica (entre otras tantas) que nos permite protegernos frente a redes inseguras, siempre y cuando tengamos acceso a un servidor SSH (como una cadena es tan fuerte como el más débil de sus eslabones, la máquina que corre el servidor SSH debería estar conectada de forma segura al servicio de intenet al que queremos acceder. En la mayoría de los casos, esto significa que la máquina debe tener simplemente una conexión segura a internet). Ésta tecnica consiste en la redirección de puertos, que openSSH implementa mediante los parámetros -L y -R (el parámetro -D también sirve para esto, pero a mi parecer es mucho menos potente). Nosotros solo vamos a ver el uso de -L, pues -R tiene un uso bastante similar.
La forma general de usarlo es la siguiente:
$ ssh -L puerto-local:maquina-destino:puerto-destino usuario@ssh-server
tras lo cual, si no tenemos llaves SSH, nos pedirá la contraseña de usuario-remoto.
Con esto, lo que hacemos es decirle al protocolo openSSH: "ponte a escuchar en el puerto 'puerto-local' de mi máquina, y todos los paquetes que recibas en ese puerto, encríptalos y mándalos cifrados a la máquina 'ssh-server' (logueándome como 'usuario'), la cual se encargará de descifrar los paquetes y, a su vez, reenviarlos al puerto 'puerto-destino' de la máquina 'maquina-destino' ".
Si el nombre de usuario que tenemos en la máquina local es el mismo que el que tenemos en la máquina con servidor SSH, podemos omitir la parte 'usuario-remoto@', pues openSSH buscará un usuario con el mismo nombre que el del cliente SSH.
El redireccionamiento entre el servidor SSH y la máquina-destino se hace de forma insegura (sin cifrar); por ésto es necesario que la conexión entre estas dos máquinas sea lo más segura posible.
Llegados a este punto, se pueden dar dos casos:
1- Que la máquina que ofrece el servicio que queremos utilizar (mail server, IRC server, etc.) sea la misma que corre el servidor SSH.
2- Que el servidor SSH y el servicio en cuestión estén en máquinas distintas.
Pero viendo algunos ejemplos seguro que queda mucho más claro:
Para el primer caso:
Imaginemos que estando en una red LAN (la del curro, por ejemplo) tenemos salida a internet a través de un proxy que escucha en el puerto 8080 y cuya IP es 192.168.1.1, y que todos los PCs están interconectados mediante un hub. Además, da la casualidad de que el servidor proxy corre también un servidor de openSSH. La manera normal de navegar sería configurando nuestro Firefox para que se conecte a internet mediante el proxy (en 192.168.1.1) a través de su puerto 8080. Pero, mierda, cualquier jaquer con un sniffer podría espiarnos. Pues bien, podemos blindar nuestra navegación web (o por lo menos, la parte 'local') a prueba de mirones con la siguiente línea:
$ ssh -L 8080:localhost:8080 192.168.1.1
y cambiando la configuración de Firefox, para que en vez de conectarse a '192.168.1.1:8080' lo haga a 'localhost:8080'.
(En este caso hemos supuesto que los usuarios local y remoto son iguales).
En el segundo caso:
Supongamos que queremos acceder, desde cualquier lugar del mundo, al servidor de correo de la empresa en la que trabajamos, pero resulta que dicho servidor sólo acepta conexiones provenientes de la misma LAN en la que se encuentra. Supongamos también que el router (cuya IP en internet es 80.20.40.60) que conecta la LAN interna de la empresa con internet tiene instalado un servidor SSH. Pues bien, a través de dicho router, y gracias a openSSH, podemos acceder al servidor de correo (que por ejemplo está alojado bajo la IP 10.0.0.30 dentro de la LAN) de la siguiente forma:
$ ssh -L 10025:10.0.0.30:25 pepito@80.20.40.60
Ya sólo nos queda configurar nuestro cliente de correo para que se conecte a localhost:10025.
Y recuerda: sólo root puede redirigir los puertos que están por debajo del 1024 (puertos privilegiados).
