SSH Tunneling - 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 un túnel SSH en una conexión FTP se centra únicamente en la protección de la conexión de control, es decir, del login/password de la sesión y de los comandos utilizados. Los ficheros se ç intercambiarán sin utilizar el túnel SSH. ~- Es necesario usar el modo pasivo ("pasive mode") para la conexión de datos o de lo contrario el servidor FTP tratará de conectar con la máquina remota que se encuentre al otro lado del túnel SSH (típicamente la propia máquina servidora) y no con la máquina cliente que realiza la petición. ~- Al usar el modo pasivo, la conexión de datos provendrá de una dirección IP distinta a la usada en la conexión de datos. Esto suele ser un problema para la gran mayoría de servidores FTP, ya que por defecto deniegan este hecho como medida de seguridad (para prevenir "hijacking" o "spoofing" en las conexiones). Deberemos, por lo tanto, configurar el servidor FTP para permitir esto. Debido a estos problemas de seguridad, y gracias a las nuevas prestaciones de la versión 2 de SSH, el SSH tunneling en conexiones FTP está siendo reemplazado por conexiones "sftp", que proporcionan protección tanto de datos como de comandos, sin necesidad de modificar el servidor FTP existente (realmente este último no es necesario, todo se realiza desde el servidor SSH). ||
|| Telnet || 23 || Realizar conexiones Telnet o rsh mediante túneles SSH no tiene ningún sentido, ya que SSH es ya el protocolo para shell remota de forma segura. En escenarios realmente extraños podría emplearse eventualmente para acceder, por ejemplo, desde un host de Internet a un servidor de una extranet que sólo tiene el puerto 23 abierto. En este caso podría establecerse una conexión SSH segura a un host en la frontera de la extranet con Internet, y de ahí realizar la comunicación al puerto 23 de forma insegura (suponiendo que el interior de la extranet no sea conflictivo). ||
|| SMTP || 25 || Ahora que a consecuencia del spam casi todos los servidores SMTP tienen unas políticas de "relay" muy severas, el SSH tunneling en conexiones SMTP puede aumentar la comodidad de muchos usuarios.
La práctica totalidad de servidores SMTP tienen a ellos mismos (localhost) como "relay" aceptado, por lo que si establecemos un conexión segura mediante un túnel SSH a ese servidor y enviamos nuestro correo saliente por el túnel, el servidor lo considerará como proviniente de localhost a pesar de que nos encontremos en un host lejano, por lo que no denegará el envío. ||
|| HTTP || 80 || Muchos servidores web tienen secciones privadas que están protegidas por una contraseña (en Apache tenemos los típicos ficheros .htaccess que protegen directorios del servidor web, por ejemplo). La debilidad de este tipo de protección es que la contraseña viaja por la red en texto plano si no nos aseguramos de usar medios de encriptación como pueda ser una conexión median SSL al puerto 443 del servidor. Las advertencias de los navegadores no son en vano, y no deberían tomarse a la ligera dentro de una LAN en la que pueda haber sniffers de red. Un túnel SSH protegería de forma sencilla que esas contraseñas puedan ser espiadas. ||
|| POP3 || 110 || Este protocolo (así como su antecesor POP2 en el puerto 109) es el candidato ideal a ser utilizado mediante un túnel SSH. Casi sin darnos cuenta, nuestros clientes de correo envían constantemente nuestro login y password al servidor de correo para sondear si hemos recibido nuevos mensajes. Todo este tráfico viaja en texto plano, por lo que puede ser capturado, analizado y la confidencialidad de nuestro correo podría verse afectada. Además, es posible que un eventual atacante que se hiciese con un usuario y clave de POP3, consiguiese entrar en servidor con ellos por otro protocolo.
Además de esto, POP3 puede ser totalmente reemplazado por scripts que usan de forma nativa SSH, como scpmail, appendmail o loopmail. ||
|| NNTP || 119 || De la misma manera que sucede con POP3, nuestros clientes de noticias también se autentican automáticamente, si bien es cierto que la mayoría de servidores de news permiten acceso anónimo. ||
|| SMB || 139 || Las transferencias de ficheros mediante este protocolo típico de plataformas Microsoft también puede ser un objetivo de los túneles SSH. Existen varios problemas al respecto: ~- La navegación dentro de directorios compartidos se realiza por UDP, por lo que no podremos realizarla a través del túnel SSH. ~- NETBIOS siempre utiliza el puerto 139 y no puede ser reemplazado por otro, por lo que necesitaremos privilegios de root para utilizar ese puerto (<1024). ~- Si queremos utilizar el puerto 139 para un túnel SSH, no podremos compartir ficheros de nuestra máquina al mismo tiempo. Deberemos elegir entre la conexión SSH y la conexión normal. Por todo ello, quizá convenga utilizar sftp y olvidarse de Samba para intercambios de ficheros. ||
|| IMAP || 143, 220 || IMAP admite el uso de túneles SSH de forma similar a POP3. Sin embargo, algunas de las posibilidades extra que ofrece IMAP con respecto a POP3, como pueda ser la organización de los mensajes en carpetas, pueden verse afectadas si no se utilizan los puertos originales para este protocolo (143 para IMAP2 o IMAP4 y 220 para IMAP3). Por ello, quizá necesitemos tener privilegios de root para hacer el port-forwarding para IMAP. ||
|| MySQL || 3306 || Nuestras conexiones remotas a Bases de Datos pueden también servirse de esta técnica. He elegido MySQL por ser bastante popular entre los programadores de entornos Linux, pero los túneles SSH pueden utilizarse para conectar con los múltiples tipos diferentes de Bases de Datos accesibles desde nuestros sistemas. ||
|| RPC (NIS, NFS...) || 111 || Holger Trapp programó un paquete denominado "sec_rpc" que utilizaba SSH para aumentar la seguridad de los protocolos basados en RPC (Remote Procedure Calls). Actualmente se ha mejorado bastante ese paquete y permite incluso túneles UDP con SSH versión 2. Este tipo de túneles son los que se usan para SNFS (Secure NFS), o NIS, protocolos históricamente inseguros, que se benefician de estos avances y consiguen perder su obsolescencia. ||
|| X11 || 6000 || En ocasiones nos preocupamos por la seguridad de nuestras conexiones mediante shells remotas, pero descuidamos la protección de los datos enviados por terminales gráficas. Si usamos SSH tunneling en conexiones X11 evitaremos desagradables sorpresas.
Para realizar el tunneling no es necesario fijar la variable de entorno "DISPLAY" de forma manual, el cliente ssh fija su valor automáticamente facilitándonos el proceso. ||

Tabla 1. Posibles aplicaciones de los túneles SSH.

Además de todas estas posibles aplicaciones, un protocolo nuevo empleado en redes inalámbricas se está beneficiando también de los túneles SSH. WEP es un protocolo de protección de datos en redes inalámbricas con un objetivo bastante modesto, proporcionar una protección similar a la de una conexión por cable (Wired Equivalent Protection). Recientemente, estudiantes de Berkeley han conseguido reventar el sistema criptográfico en el que se basa WEP y con el tiempo suficiente podría quebrantarse cualquier protección basada en WEP. Es por ello que los usuarios de redes de este tipo (wireless) está apostando por el fuerte cifrado que ofrece SSH para reforzar sus conexiones. Esto, en suma, deja una puerta abierta a la escalabilidad en este tipo de protocolos.




Antes de terminar, me gustaría comentaros dos curiosidades relacionadas con este tema. La primera es que eran parte de lo que hemos comentado en este artículo se puede utilizar en plataformas Microsoft gracias al empleo de la librería Cygwin, así que no tendremos que establecer configuraciones rocambolescas para utilizar SSH Tunneling en las máquinas con Sistemas Microsoft que podamos tener en nuestras redes. La segunda es que existen empresas que comercializan este servicio para todo tipo de protocolos. Lo que plantean es utilizar un conjunto de servidores que atienden conexiones ssh y las canalizan hacia los destinos reales. Realmente funcionan de intermediarios entre sus clientes y los servidores a los que quieren acceder sus clientes, proporcionando un canal seguro desde ellos a sus clientes, y "anonimizando" sus peticiones (todas las peticiones aparecerán como realizadas por los servidores de la empresa que proporciona este servicio y no por el cliente real).

En conclusión, el SSH Tunneling es una alternativa sencilla al empleo de protocolos de forma insegura, sin tener que hacer modificaciones en el propio protocolo. Además, esta técnica es aplicable a un amplio espectro de escenarios (como hemos podido comprobar) y es altamente escalable. Por todo ello recomiendo su empleo siempre que sea posible y aprovecho esta última línea para agradecer a los desarrolladores de OpenSSH todo el esfuerzo realizado ;-)

Este documento ha sido escrito por un miembro de e-GHOST, y su contenido es libre de ser reproducido en otros medios bajo las condiciones de la Licencia FDL (GNU Free Documentation License)∞.