PDF de programación - ssh tunneling

SSH Tunneling

Pablo Garaizar Sagarminaga
[email protected]
SSH, una historia ajetreada...

Quizá ahora, cuando las miles de posibilidades que ofrece SSH han inundado nuestros
sistemas Linux, olvidemos la controversia que ha rodeado a SSH desde sus orígenes.

"Apuesto a que un montón de gente no sabe que ssh 1.2.12 tiene una bonita licencia", con
esta frase escrita en un foro de mensajes, el grupo OpenSSH se daba a conocer.

SSH 1.2.12 fue desarrollado por un programador finlandés, Tatu Ylönen, que publicó su
trabajo bajo una licencia libre. Pronto el éxito de su programa lo llevo a patentar la marca
registrada "SSH™" y crear una empresa con fines comerciales. Las siguientes versiones
dejaron de ser libres y se permitió su empleo únicamente para usos no comerciales. Los
desarrolladores de OpenBSD se dieron cuenta de que su sistema operativo, centrado en la
criptografía y seguridad, se quedaba "cojo" sin SSH. Además, las encuestas afirmaban que
lo primero que la mayoría de usuarios de OpenBSD añadía después de instalar el sistema era
SSH. Con estas ideas en la cabeza y bastante buenas intenciones, surgió el proyecto
OpenSSH, cuyo principal objetivo consistió en desarrollar una implementación totalmente
libre de SSH. Los primeros pasos de este proyecto estuvieron centrados en utilizar solamente
código libre y portable. Tanto es así que pusieron especial empeño en evitar problemas con
patentes y restricciones gubernamentales: la mayoría de los desarrolladores residían fuera de
Estados Unidos, a excepción de Niels Provos, un alemán afincado en Michigan, que cruzó la
frontera a Canadá para enviar su código desde una pequeña tienda local de informática en
Ontario (nada quería dejarse a la ligera).

Todos estos esfuerzos no fueron vistos con tan buenos ojos por el desarrollador inicial de
SSH, que veía como su proyecto comercial se iba al traste. Después de varias demandas
judiciales y muchas discusiones, OpenSSH pudo mantener el "SSH" en su nombre y seguir
con el trabajo que estaban realizando.

Figura 1. OpenSSH, una implementación libre de SSH.
¿Qué es un túnel SSH?

Esta bonita historia no debe hacernos olvidar que OpenSSH (SSH en lo sucesivo, para
acortar) es una herramienta indispensable en la administración de sistemas. La mayoría de los
protocolos que empleamos en nuestras comunicaciones están basados en diseños de hace
casi 30 años, cuando la seguridad en redes telemáticas no era un problema. Telnet, FTP,
POP3, protocolos de uso cotidiano, descuidan la seguridad y confidencialidad de los datos
que envían. De nada sirve proteger nuestros servidores, implantar una buena política de
contraseñas y actualizar las versiones de nuestros demonios, si luego cuando un usuario de
POP3, por ejemplo, quiere ver su correo electrónico desde la universidad, envía su usuario y
contraseña en texto plano por la red. Para evitar esto tenemos dos alternativas: bien elegir
protocolos que sean seguros, bien hacer seguros los protocolos inseguros. De las dos
opciones, la segunda permite reutilizar muchos más clientes y servidores ya programados,
ayuda a enmascarar la complejidad de la seguridad en la transmisión y es una solución
siempre escalable. Por todo esto, vamos a ver cómo convertir nuestros protocolos
tradicionales en protocolos seguros, y qué tiene que ver SSH en todo ello.

La idea en la que se basa este procedimiento es la de hacer un túnel por el cual viajarán los

datos de manera segura ("tunneling"). El símil con la vida real está bastante bien escogido:
imaginemos que la tasa de mortalidad de los diferentes medios de transporte fuese
equivalente a la posibilidad de que la seguridad de nuestros datos sea violada, y que el tren
representase un canal seguro y el automóvil un canal inseguro. El túnel del Canal de la
Mancha sería el ejemplo perfecto para ilustrar el concepto de "tunneling": cuando queremos
viajar a través de él con nuestro coche, tenemos que subirnos a un vagón para coches y
luego cruzar el túnel en tren. Hemos incrementado sensiblemente la seguridad del viaje,
porque la probabilidad de un accidente de tren es muchísimo menor que la de un accidente
de coche. Este mismo proceso es el que se da a la hora de establecer un túnel seguro en la
comunicación entre cliente y servidor. En cada uno de los extremos del túnel están las
aplicaciones estándar (un demonio POP3 estándar, nuestro cliente de correo favorito...) y la
comunicación se asegura haciendo uso de toda la potencia criptográfica de SSH. Para ello
tenemos que realizar un procedimiento similar al que supondría subir nuestro coche al tren,
establecer mediante SSH un reenvío de los datos gracias a una técnica denominada "port-
forwarding". SSH recoge los datos que el cliente quiere enviar y los reenvía por el túnel o
canal seguro, al otro lado del túnel se recogen los datos y se reenvían al servidor
conveniente:

Figura 2. Proceso de tunneling SSH.
De la teoría a la práctica

Veamos cómo llevar esto a cabo. La clave está en usar la opción "-L" de SSH, que se
encarga de todo el proceso de "port-forwarding". El siguiente ejemplo muestra cómo utilizar
el puerto 10110 de nuestra máquina para establecer una comunicación segura con el puerto
110 del servidor popmail.correo.net:

$ ssh -P -L 10110:popmail.correo.net:110

El símbolo de dólar obviamente no pertenece al comando, indica que lo ha realizado un
usuario sin privilegios de root. Esto es un punto importante: si queremos utilizar puertos
privilegiados por debajo de 1024 ("well-known ports"), deberemos tener privilegios de root
(por lo menos en un sistema con una configuración normal, alejado del "enfoque" de
seguridad de Windows98 o similares). Si no disponemos de dichos privilegios, tendremos
que optar por la alternativa de utilizar un puerto superior a 1024, como en el ejemplo. Una
manera fácil de no liarse con esto es sumar 10000 al número de puerto estándar, así el 110
sería el 10110 en nuestra máquina, el 10080 el 80, o el 16667 el 6667.

SSH da mucho más juego, éstas son algunas de las opciones que podremos incluir en
nuestras configuraciones y scripts:

-1 ó -2 : fuerza a utilizar la versión 1 o la versión 2 de SSH. -f : pasa a segundo plano la
ejecución de ssh (fork). Esta opción implica además la opción -n, en la que se impide leer de
la entrada estándar. -N : impide ejecutar comandos remotos. Muy útil cuando lo único que se
desea es "port-forwarding". -P : permite usar un puerto no privilegiado (>1024) para
conexiones salientes. Muy usado cuando estamos tras un router o firewall que no permite
conexiones a puertos privilegiados.

Para más información acerca de estas y otras opciones, ya sabéis, "man ssh" ;-)

Otros aspectos que deberemos tener en cuenta:

- Compatibilidad en cuanto a versiones de SSH. Bastantes clientes de SSH solamente
soportan la versión 1, sin embargo esta versión es vulnerable a diversos ataques, por lo que
es aconsejable utilizar la versión 2 convenientemente parcheada (openSSH-3.x.x con los
parches para corregir el bug "hang-on-exit" o el "exit-delay"). Aquí se plantea la típica
disyuntiva entre seguridad o compatibilidad.

- Para establecer una sesión SSH es necesario autenticación. Si utilizamos autenticación por
passphrase (además de las correspondientes claves RSA o métodos similares), deberemos
prever este hecho en nuestros scripts o nuestras sesiones interactivas o de lo contrario no
podremos establecer el túnel SSH.

- Las reglas de protección en ipchains o iptables. Si tenemos configuradas reglas para
bloquear las conexiones entrantes, necesitaremos establecer una excepción a esas reglas para
que funcione el "port-forwarding" en local, con algo parecido a esto:

# iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -i lo -j ACCEPT
# iptables -A OUTPUT -s 127.0.0.1 -d 127.0.0.1 -o lo -j ACCEPT

- Si vamos a utilizar puertos privilegiados en nuestra máquina local (con privilegios de root),
deberemos tener en cuenta que esos puertos no se hayan empleado para conexiones
entrantes. Si, por ejemplo, queremos hacer "port-forwarding" del puerto 110 para que
nuestros usuarios puedan acceder de manera segura a su servidor de correo, deberemos tener
cuidado ante un posible servidor POP3 escuchando el puerto 110 en nuestra máquina.
Revisad vuestras configuraciones de los demonios que están escuchando puertos y en
especial el fichero "/etc/inetd.conf".

- Si queremos establecer un túnel para cada conexión y destruirlo cuando ésta acabe,
podemos usar una nueva opción incluida en el último parche (-S) para fijar un tiempo de
espera o "delay" en el que se atenderán las conexiones SSH. Cuando ese tiempo expire, no
se atenderán más conexiones y el comando finalizará cuando todas la conexiones hayan
concluido (esto es importante, no termina cuando se consuma el tiempo fijado). Si
disponemos de una versión antigua de SSH, podemos hacer esto mismo de la siguiente
manera:

$ ssh -f -L 110:popmail.correo.net:110 [email protected] sleep
30

esto sería equivalente a:

$ ssh -f -S 30 -L 110:popmail.correo.net:110 [email protected]

Así estamos fijando un temporizador de 30 segundos para aceptar conexiones, finalizado el
cual se esperará únicamente a que las conexiones ya establecidas terminen.
Infinitas posibilidades

Una vez entendido el método general para crear un túnel SSH, vamos a ver la multitud de
aplicaciones posibles que tiene esta técnica:

Servicio
Puerto
Comentarios

FTP
21
Se han escrito ya varios textos acerca del SSH tunneling en servidores FTP ampliamente
usados en nuestras máquinas Linux como puedan ser ProFTPd o wu-ftpd, si estás interesado
en un demonio en particular, te recomendaría que buscaras información sobre él en
particular.
A nivel general, el SSH tunneling en FTP tiene algunos aspectos reseñables:

• Como bien sabemos, FTP tiene dos conexiones distintas: una para los comandos (control)
y otra para la transmisión de ficheros (datos). La manera estándar de hacer