![[Photo of the Author]](../../common/images/Georges-Tarbouriech.jpg)
original in en Georges Tarbouriech
en to es Georges Tarbouriech
es to es Javier Palacios
Georges es un usuario viejo de Unix (comercial o libre). Le interesa mucho la
seguridad y quiere agradecer a la comunidad del software libre por su estupendo
trabajo en éste asunto.
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 éste sitio,
pueden encontrar alternativas para sistemas Unix, Windos, Mac... Concerniendo
productos tales como Windos, sólo encontrarán clientes libres.
En éste artículo, presentamos unos ejemplos en 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, mucha más
elaborada que el tema que tocamos aquí. Otra solución sofisticada
se llama VTun.
Entonces, podemos considerar éste "tunneling" como una manera simple y
fácil de encriptar los datos en una red heterogénea para que no se
pueda interceptar. Claro, éso vale para redes locales o lejanas. Sin embargo,
recuerden, ssh sólo encripta los datos, no puede asegurar la red en
si mismo...
Han sido avisados !
SSH es un reemplazo de telnet o de rsh, rlogin, como ya lo hemos dicho en un
artículo anterior.
Incluso si algunos problemas de seguridad fueron encontrados en ssh hace poco,
queda una buena herramienta para encriptar los datos. A propósito, éste
problema de seguridad concernía los passwords : se recomenda usar passphrases y
claro claves RSA ! Usar ssh no dispensa de usar a 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, así podiendo leerlo tomando un café
o fumando un cigarillo. Si se averigua para los datos, también es verdad para
los passwords : es decir, la puerta está abierta muy grande para los
piratas. Les dan la llave para entrar en la casa.
Sólo fijense si los datos circulando son confidenciales... Si eres el
sysadmin, tengo miedo a que tu jefe te pide 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 bueno reemplazo para rlogin o rsh, viene con scp, lo
que también es un bueno 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 publicas...
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
the 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... bueno, a ti te
toca. 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, a
parte de Unix, muchos SO no tienen servidores. Es decir, a veces no
podrán hacer lo evidente, tendrán que dar la vuelta al problema :
la clave se llama "redirección". Más sobre el asunto ese un poco
más tarde. Esto significa que usando SO tales como Mac OS o Windos, no
tendrán servidores libres. Tendrán que trabajar con clientes y no
parece tan evidente. A ver con unos ejemplos.
Si no conocen VNC, le faltan una de las herramientas más estupenda nunca
vista. Pueden dar 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 Windos hacia un servidor ssh para Unix. Por eso no voy a reescribir el
muy buen trabajo de Frank Stajano puesto que es mucho mejor que lo que
podría hacer.
Entonces, a ver cómo puede funcionar eso.
Primero, tienen que elegir un cliente ssh libre para Windos. 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 interfáz 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.
MySQL es probablemente uno de los bases de datos
más usados, particularmente en el 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 a decir que nuestro ejemplo concierne un 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 Windos.
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 conexión propia. Para el "login" en el base
de datos, claro que 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. Por eso tendrían que buscar
algo más sofisticado, tal como VPN por ejemplo, pero ésto es la idea.
De todo modos, no crean que basta para la seguridad de un servidor de base de
datos transferiendo datos confidenciales tales como numeros de tarjetas de
credito ! Y, a propósito, quién cree alguién diciendo que tiene un
servidor capaz de transferir éste tipo de datos sin riesgo ? Personalmente, no
lo creo !!!
Qué significa eso puesto que ya usamos emulación de terminal ?
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 el propio interfáz de usuario. Los
acentos, las tablas... Definir una emulación standard (vt100, vt220...)
en 8 bits no funcionará correctamente. Lo que se obtiene ni no se puede
usar. Entonces, puesto que es un producto bastante antiguo, usan un software
"antiguo" de emulación de terminal.
Depués de una larga batalla para obtener la buena emulación, encuentran
que "ibm3151", por ejemplo, da el mejor resultado. Menos mal !
Pero, puesto que el software ha sido 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.
De nuevo, "There Is More Than One Way to Do It"...
Sea se redirige telnet hacia puerto 22 (ssh), sea se redirige el puerto de la
emulación. Pero... no creo que el servidor aceptará que un usuario
redirige 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, así usando diferentes
puertos para cada conexión, por ejemplo, 10 usuarios = 10 puertos.
Vuelve un poco más complicado, no ?
Bueno, 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 sea
usando Ttssh sea usando la linea de comando. Es decir, establecen una
conexión encriptada entre el servidor y el cliente como 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 de usar el puerto 50000 en vez del 23. Ahora los
datos circulan por un canal seguro, lo que significa encriptado. Pueden
averiguarlo con snoop o tcpdump.
Claro, 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 contesta es : por muchas
razones !
En serio, 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 según los servicios corriendo. Así
el puerto 50000 y más tendría que funcionar.
Claro, todo eso funcionará por muchos SO capaces de usar clientes ssh.
Concerniendo la manera de automatizar el proceso en las máquinas
clientes, a ti te toca. No pueden pedir un usuario "normal" de hacer todo eso
antes de conectarse. Entonces, dejamos eso como ejercicio para los lectores...
Estos ejemplos enseñan las numerosas utilizaciones de ssh. Pueden hacer
mucho más con muchas aplicaciones con ssh. Depiende 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 Windos 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.
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 si 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, incluso si son 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, deactivar 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 de detrás
abierta. Claro, es otra historia, pero no olviden lo evidente.
Volviendo a ssh, podemos decir que es una herramienta no se puede vivir sin
ella, si la usan correctamente y por lo que ha sido hecha. De nuevo, usenla con
passphrases, claves RSA, no con passwords. Controlen las permisiones de los
ficheros en el directorio .ssh y claro las permisiones del propio directorio.
Y otra, otra vez, por lo menos, usen tcpwrappers !
No obstante, recuerden, pueden mandar por el túnel ssh la mayoría
de los protocolos existante. Puede ser muy útil para que las conexiones
se encuentren 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 hace
parte del subjeto. X no es tan seguro, ssh puede mejorar las cosas.
Por usos más sofisticados, ssh no bastará. Como ya lo hemos dicho,
estudien VPNs o herramientas como VTun, ayudarán mucho.
Ultimo pero no lo menos, 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 !