Hogar  |  Mapa  |  Indice  |  Busqueda

Convert to GutenPalm or to PalmDoc por Georges Tarbouriech <georges.t(at)linuxfocus.org> Sobre el autor: Georges es un usuario viejo de Unix (comercial o libre). Le interesa mucho la seguridad y quiere agradecer a la comunidad del software libre su estupendo trabajo en éste asunto. Taducido al español por: Georges Tarbouriech <georges.t(at)linuxfocus.org> Javier Palacios [proof read] <javier.pb(at)linuxfocus.org> Contenidos: ?Por qué usar ssh? SSH y VNC SSH y MySQL SSH y emulación de terminal A donde ir desde aquí? ¡Por fin, se acabó! Formulario de "talkback" para este artículo

A través del túnel

Resumen:

SSH, el "secure shell" es un producto comercial muy bueno. No obstante, hay varias versiones libres de ssh, clientes o servidores, disponibles para Unix (comercial o libre) o para otros SO. El más conocido es OpenSSH, disponible en http://www.openssh.org. Desde este sitio, pueden encontrar alternativas para sistemas Unix, Windows, Mac... Para productos tales como Windows, sólo encontrarán clientes libres.

En este artículo, presentamos unos ejemplos con la manera de usar ssh para que los datos de aplicaciones externas circulen por el "túnel" creado con ssh. VPN (Virtual Private Network) usa ssh, pero de otra manera mucho más elaborada que el tema que tocamos aquí. Otra solución sofisticada se llama VTun.

Podemos considerar este "tunneling" como una manera simple y fácil de encriptar los datos en una red heterogénea para que no se pueda interceptar. Y eso vale para redes locales o lejanas. Sin embargo, recuerden, ssh sólo encripta los datos, no puede asegurar la red en sí misma...
¡Han sido avisados!

?Por qué usar ssh?

SSH es un reemplazo de telnet o de rsh y rlogin, como ya lo hemos dicho en un artículo anterior. Incluso aunque se encontraron problemas de seguridad en ssh hace poco, sigue siendo una buena herramienta para encriptar los datos. A propósito, éste problema de seguridad concernía los passwords: ¡se recomienda usar passphrases y claro claves RSA! Usar ssh no dispensa de usar otras herramientas de seguridad tales como los tcpwrappers, por ejemplo.

Es muy fácil de interceptar datos circulando por una red con herramientas standard tales como tcpdump o snoop. Pueden probar ésto en una red en la cual dos máquinas comunican con telnet, por ejemplo. Desde una tercera máquina Linux, por ejemplo, arranquen tcpdump (como root, claro) y miren lo que pasa. ¡Pueden leer todos los datos! Claro, es demasiado rápido para leer en la pantalla, pero pueden redirigir la salida hacia un fichero, y leerlo tomando un café o fumando un cigarrillo. Si es cierto para los datos, también lo es para los passwords. Es decir, la puerta está muy abierta para los piratas. Les dan la llave para entrar en la casa. Imaginen si los datos que circulan son confidenciales... Si eres el sysadmin, tengo miedo a que tu jefe te sugiera encontrar otro empleo en cualquier otro lugar. Los comandos rsh, rcp, rlogin también son muy peligrosos, puesto que tampoco son encriptados. Si ssh es un buen reemplazo para rlogin o rsh, viene con scp, lo que también es un buen reemplazo para rcp. Es decir, si usan ssh no necesitan más los "remote commands" o telnet. O por lo menos no tendrían que usarlos.

Cómo instalar ssh, cómo generar las claves privadas y públicas... no entra en el tema de éste artículo. Encontrarán todo lo que necesitan en el arca o leyendo toda la documentación disponible en el Linux Documentation Project, por ejemplo. Puesto que usar una computadora hoy, casi siempre significa transferir datos de una manera u otra, ssh tendría que ser obligatorio... aunque es cosa tuya. Sin embargo, ssh puede hacer mucho más que reemplazar telnet o los "remote commands". Pueden usarlo para encriptar los datos circulando entre aplicaciones externas y claro entre diferentes SO. También puede comprimir estos datos. Muy a menudo se usa con protocolos tales como pop, ftp, http... sea por compresión o encriptación. Esto es muy útil, siendo un sysadmin, para conectar desde casa al trabajo o viceversa.

Siendo una aplicación cliente/servidor, ssh necesita ambos para funcionar: necesitan una máquina corriendo un servidor ssh y otra corriendo un cliente ssh (¡Han notado que listo soy!). ¿Por qué insistir en ésta evidencia? Puesto que hablamos de software libre, aparte de Unix, muchos SO no tienen servidores. Es decir, a veces no podrán hacer lo evidente, sino que tendrán que dar la vuelta al problema: la clave se llama "redirección". Más sobre ese asunto un poco más tarde. Esto significa que usando SO tales como Mac OS o Windows, no tendrán servidores libres. Tendrán que trabajar con clientes y no parece tan evidente. A ver con unos ejemplos.

SSH y VNC

Si no conocen VNC, le faltan una de las herramientas más estupenda nunca vista. Pueden echar un vistazo aquí para saber un poco más.
Si van a visitar el sitio de VNC en http://www.uk.research.att.com/vnc/docs.html encontrarán mucha documentación concerniendo el asunto del cual hablamos. Por ejemplo, encontrarán cómo usar VNC con ssh, desde un cliente ssh para Windows hacia un servidor ssh para Unix. Por eso no voy a reescribir el muy buen trabajo de Frank Stajano que es mucho mejor de lo que yo podría hacer. Entonces, a ver cómo puede funcionar eso. Primero, tienen que elegir un cliente ssh libre para Windows. En el ejemplo usaremos Teraterm Pro con su extensión Ttssh. Pueden encontrarlo a http://hp.vector.co.jp/authors/VA002416/teraterm.html. De hecho, se llama Ttssf, puesto que es una versión autorizada en Francia. Todo eso va cambiando, pero tienen que saber que muchos países todavía no aceptan encriptación. Visiten el URL siguiente para conocer la situación de la encriptación en su propio país: http://www2.epic.org/reports/crypto2000/countries.html.

Ahora, decimos que han arrancado un servidor ssh en una máquina Unix. En el mismo servidor, suponemos que pueden arrancar un servidor VNC (vncserver). Una vez que los dos servidores funcionan, conecten por ejemplo una máquina NT al servidor Unix usando Ttssh. Es decir, ya tienen una conexión encriptada entre ambas máquinas. Pero eso aún no permite tener un protocolo vncviewer (cliente vnc) encriptado desde el ordenador funcionando bajo NT. Para hacer eso necesitan decir a ssh que tiene que "redirigir" el buen puerto (¡ya hemos llegado!). El ordenador Unix corriendo el servidor vnc se llama "bandit" y usa el puerto 5901, porque es el "display" numero 1, el X display por defecto en ésta máquina siendo el 0. El uso normal sería mandar el comando "vncviewer bandit:1". Claro, esto funciona pero sin los datos encriptados. En vez de eso, usando el "shell" de NT (es decir el interfaz DOS...), hay que mandar el comando "/ssh-L5902:bandit:5901" sin espacio. Esto significa que crean un puerto local 5902. Ahora un comando "vncviewer localhost:2" empieza una conexión encriptada del protocolo VNC en la máquina NT. Se puede hacer lo mismo sin usar la linea de comando puesto que Ttssh tiene un interfáz gráfico. Podemos añadir que la sintaxis esa sólo concierne Ttssh. El comando en Unix sería: "ssh -L 5902:bandit:5901 bandit".

Claro, es un ejemplo muy basico: pueden hacer cosas más complicadas. Den un vistazo a la documentación disponible en el sitio de VNC, particularmente la de Frank Stajano.

SSH y MySQL

MySQL es probablemente una de las bases de datos más usadas, particularmente en Internet. De nuevo, hacer MySQL más seguro no entra en el objeto de éste artículo. Sin embargo, encriptar los datos circulando entre un servidor y un cliente MySQL mejora la seguridad de la conexión. SSH permite hacer eso, de la misma manera que lo hemos hecho con VNC, es decir "redirigiendo" el puerto. Vamos con un ejemplo en una intranet. El servidor MySQL es una máquina Linux y la mayoría de los clientes son máquinas NT. De nuevo, usamos el cliente Ttssh en las computadoras Windows.

El puerto por defecto de MySQL es 3306. Esta vez la "redirección" concierne el mismo puerto (3306). Pueden hacer una "redirección" local o distante. Un "forward" local parece a "/ssh-L3306:localhost:3306" en la máquina NT o "ssh -L 3306:localhost:3306" en la máquina Unix. Usar "localhost" permite mandar los datos por el interfáz loopback en vez del interfáz del "host". Un "forward" distante sería "/ssh-R3306:bandit:3306" para NT y "ssh -R 3306:bandit:3306" para Unix. Esto sólo concierne la propia conexión. Para el "login" en la base de datos necesitan el hostname y el username que tienen para el servidor MySQL, éste último siendo probablemente diferente del username que tienen para el login en el sistema. Den un vistazo a los man pages por la opción "-l". Claro, ésto funcionara si tienen un cliente MySQL en el ordenador NT. Si no tienen, necesitarán el uso de una aplicación ODBC, Sybase por ejemplo (o si no tienen miedo, la maravilla de "PequeñoFlojo" llamada Access). Es decir, tienen que arrancar ésta aplicación. Usen el piloto ODBC para crear un enlace hacia el servidor MySQL. Ahora pueden conectar al localhost, no el host del servidor MySQL , para entrar en el servidor MySQL. Ahora, los datos circulando entre el servidor y el cliente estan encriptados. Pueden averiguarlo con snoop o tcpdump.

Este ejemplo concierne una red local. Si quieren hacer lo mismo en WANs, será un poco más complejo, si por ejemplo se encuentran detrás de un firewall. Esto puede ser una manera de administrar a distancia desde casa si eres un sysadmin pero no sería tan bueno para entrar en un base de datos en un sitio web. Para eso tendrían que buscar algo más sofisticado, tal como VPN por ejemplo, pero esta es la idea. De todo modos, no crean que basta para la seguridad de un servidor que transfiere datos confidenciales como números de tarjetas de crédito. A propósito, ¿quién cree alguien que dice que tiene un servidor capaz de transferir éste tipo de datos sin riesgo? Personalmente, ¡¡no lo creo!!

SSH y emulación de terminal

Ya estamos usando emulación de terminal de modo que ¿qué significa esto?
Imaginamos que tienen una vieja aplicación en Cobol en un servidor Unix. De nuevo, los clientes son ordenadores bajo NT. Para conectar, necesitan una emulación de terminal algo más sofisticada que vt100, vt220 o vt320, puesto que tienen que obtener también el interfaz de usuario. Los acentos, las tablas... Definir una emulación standard (vt100, vt220...) en 8 bits no funcionará correctamente. Lo que se obtiene no se puede ni usar. Entonces, puesto que el producto es bastante antiguo, utilizan un software "antiguo" de emulación de terminal. Depués de una larga batalla para obtener la emulación correcta, encuentran que "ibm3151", por ejemplo, da un buen resultado. ¡Menos mal!

Pero, puesto que el software fue desarrollado hace años, no sabe nada de seguridad. ¡La conexión se establece con telnet! De hecho, los datos son confidenciales... ¿Entonces qué? Por lo menos, hay que encontrar una manera de encriptar los datos. Otra vez, ssh nos ayuda y, de nuevo, "There Is More Than One Way to Do It" (Hay más de una manera de hacerlo) ...
Sea redirigir telnet hacia puerto 22 (ssh), sea redirigir el puerto de la emulación. Pero... no creo que el servidor acepte que un usuario redirija el puerto telnet (23 por defecto): tienen que ser root para hacer eso (¡por lo menos lo espero!). Concerniendo la aplicación de terminal, puede ser utilizada por muchos usuarios al mismo tiempo, usando diferentes puertos para cada conexión. Por ejemplo: 10 usuarios = 10 puertos. Se vuelve un poco más complicado, no?

Primero, el servidor de aplicación tiene que correr el servidor ssh escuchando al puerto 22. Desde un cliente NT, hay que conectar al servidor de aplicación, ya sea usando Ttssh o usando la linea de comandos. Es decir, establecen una conexión encriptada entre el servidor y el cliente como un usuario especifico. Desde las opciones de Ttssh, redirigen el puerto local 50000 hacia el puerto 23 (telnet) del servidor distante. Usando la linea de comando sería algo así: "ssh-L50000:servername:23". Ahora pueden decir a la emulación de terminal que use el puerto 50000 en vez del 23, y los datos circulan por un canal seguro, lo que significa encriptado. Pueden averiguarlo con snoop o tcpdump. Claro que tendrán que hacer lo mismo por cada cliente autorizado a conectar a la aplicación, cambiando el número de puerto. Por ejemplo, podría ser 50001, 50002, etc.

Podrían preguntar: ¿por qué puertos tan altos? La respuesta es: ¡por muchas razones! La causa más importante es que pueden manipular puertos altos sin ser root. La segunda razón es que el puerto seleccionado no tiene que estar en uso en ambas máquinas. Por ejemplo: si el servidor funciona bajo Solaris, muchos puertos altos ya se usan por los servicios corriendo. Así el puerto 50000 y mayores tendrían que funcionar. Todo esto funcionará en muchos SO capaces de usar clientes ssh. Respecto a la manera de automatizar el proceso en las máquinas clientes, a ti te toca. No pueden pedir un usuario "normal" que haga todo eso antes de conectarse. Dejamos eso como ejercicio para los lectores...

A donde ir desde aquí?

Estos ejemplos enseñan las numerosas utilizaciones de ssh. Pueden hacer mucho más con muchas aplicaciones con ssh. Depende de lo que necesitan. No obstante, la "filosofía" es casi siempre la misma: redirección de puerto. Sin embargo, tengan cuidado si usan redirecciones más complejas. Por ejemplo, si redirigen hacia una tercera computadora, los datos circulando por la conexión del medio no serán encriptados. Otro problema concierne clientes Windows usando Ttssh. La conexión hacia puertos redirigidos depiende de las señas IP como los "remote" comandos, así permitiendo ataques de "spoofing". Por eso, la necesidad de usar otras herramientas con ssh, tales como tcpwrappers.

Busquen en la "literatura" sobre ssh, le enseñará mucho. Su imaginación hará el resto.

¡Por fin, se acabó!

La seguridad tendría que ser una preocupación para cada uno, ¡pero no lo es! ssh sólo es una de las herramientas de seguridad que pueden usar cada día. Es una buena herramienta si la consideran por lo que es, es decir una herramienta de encriptación o de compresión. En sí mismo, ssh casi no sirve para nada, puesto que no va a suprimir los numerosos "agujeros" que pueden tener en un ordenador o en una red. Hacer una máquina, una red, más seguros es una tarea de importancia y las herramientas no lo hacen todo, aunque sean muy buenas. Las tareas básicas son una obligación cuando se trata de seguridad. No olviden suprimir los servicios que no sirven, controlar los programas SUID root, desactivar los programas con riesgos... Hay mucho que hacer y nunca bastará. Pueden instalar todas las herramientas de seguridad disponibles, no servirá para nada si dejan una puerta abierta. Claro, es otra historia, pero no olviden lo evidente. Volviendo a ssh, podemos decir que es una herramienta sin la que no se puede vivir, si la usan correctamente y para lo que ha sido hecha. De nuevo, usenla con passphrases, claves RSA, no con passwords. Controlen los permisos de los ficheros en el directorio .ssh y los permisos del propio directorio. Y otra, otra vez, ¡por lo menos, usen tcpwrappers!

No obstante, recuerden que pueden mandar por el túnel ssh la mayoría de los protocolos existentes. Puede ser muy útil para que las conexiones sean un poco más seguras. Hay otro uso muy común de ssh del cual no hemos hablado: la redirección de sesiones X. Puesto que eso necesita tener X bajo diferentes SO, lo hemos olvidado intencionalmente. Sin embargo, el asunto es parte del tema. X no es muy seguro, y ssh puede mejorar las cosas. Para usos más sofisticados, ssh no bastará. Como ya lo hemos dicho, estudien VPNs o herramientas como VTun que ayudarán mucho.

Ultimo pero no menos importante: averiguen la situación de la encriptación para su propio país. Sería triste encontrarse en la carcel por ser un espía, sólo porque han usado un software prohibido. Es así...

De todo modos, ¡vivimos una época estupenda!  

Formulario de "talkback" para este artículo

2001-11-06, generated by lfparser version 2.21