InET 3x6: Encriptacion y Seguridad: SSH
Uno de nuestros principales intereses al emplear un medio de transmision de datos e informacion, es el poder confiar que lo que se transmita o difunda, llegue a quien tiene que llegar completamente, y no a otras terceras personas no deseadas. Internet (como creo que ya todos sabemos) no es una excepcion en este asunto de la seguridad al transmitir informacion. Por el contrario, una de las preocupaciones que han tenido muchos usuarios finales (y desarrolladores) es esa. Pero en el momento, existen muchos aspectos sobre la criptografia y metodos de encriptacion, pero quisiera centrarme en el ssh o Secure Shell (Shell Seguro) debido a la amplia utilidad que se le puede dar a esta herramienta.
Tal vez algunos de nosotros conozcamos el conjunto de herramientas 'r', de la Universidad de Berkeley. Entre estas, esta el rsh, o Remote Shell (Shell Remoto). Dichas herramientas, fueron de gran utilidad pues permitian el acceso remoto a una maquina sin tener que digitar claves cada vez que se deseaba entrar a un sistema. Como lo hacia telnet, que cada vez que necesitaba ingresar a una maquina, se debia entrar el nombre de usuario y contraseña. Estas utilidades 'r' lo hacian por medio de un metodo de autentificacion por medio de IPs, puertos, y usuarios confiables, que se almacenaba en un archivo del servidor. Pero poco a poco, esta utilidad se fue convirtiendo en la pesadilla de los administradores, pues los medios que usaba el rsh para la validacion eran faciles de 'spoofear'. Es decir, es facil hacer creer a un servidor que uno tiene una direccion IP diferente, o que uno es un usuario igualmente diferente. Ademas, se propensaba a emplear el infame '+ +' en el .rhosts , que permite (para aquellos que aun no lo sepan) a cualquier usuario, el acceder a esa cuenta desde cualquier maquina. Este fue de los primeros metodos que se utilizaban para tener acceso a una cuenta ajena, pues aunque se cambie de password, si todavia se tiene el .rhosts con acceso completo en el directorio hogar, cualquiera podia ingresar como usuario confiable, es decir, sin tener que digitar la contraseña. Pero no es eso de lo que queremos hablar en estos momentos. Para detener tales ataques, muchos administradores tomaron la alternativa facil (como lo siguen y seguiran haciendo muchos administradores mediocres que prefieren su comodidad a la de los usuarios): Detener el empleo del daemon que permitia el acceso a rsh. Tatu Ylonen creo ssh, que se basa en ciertos mecanismos criptograficos mas estrictos, que se acomodan a los standar propuestos en seguridad.
Ssh, se basa en los criptosistemas de llave publica, o tambien llamados asimetricos, como lo hace el conocidisimo (y controvertido) paquete criptografico PGP. Este sistema se basa en parejas de llaves, para las que se forman por dos numeros primos suficientemente grandes de modo que sea dificil su factorizacion. Cada persona tiene un par de llaves, una publica y una privada. La publica se distribuye ampliamente, mientras que la privada se deja estrictamente para uso personal. De esta manera, el emisor puede encriptar informacion usando la llave privada del receptor, pero solamente el receptor usando su llave privada puede leerlos. Es decir, ni siquiera el emisor puede desencriptar la informacion que el mismo envio al receptor. El sistema criptografico mas ampliamente usado con estos fines, es llamado RSA (son las siglas de Rivest-Shamir-Adelman), que es la union del Teorema de Euclides, y el Teorema de Fermat.
Para la autentificacion entre el emisor y receptor, se emplea el RSA. Cuando el servidor desea validar la identidad de quien trate de autentificarse como usuario valido, genera un numero o una cadena de caracteres aleatoria, lo encripta mediante la llave publica del usuario y la envia. Si el usuario es valido, tomara el mensaje encriptado, lo decodificara, y lo enviara de vuelta al servidor que a su vez comparara el resultado proveniente del cliente, y la cadena aleatoria que genero. Si coinciden, significa que el cliente si es usuario valido, y lo deja conectar. Esto de por si ya es una mejora en la seguridad, y soluciona los problemas que el rsh nos deja. Pero, no nos proporciona seguridad suficiente en la transmision de datos. Es decir, nos asegura que el cliente es confiable mas no asegura de que la informacion que pase en esa sesion sea secreta. Es decir, en caso de que se tuviera un 'sniffer' que buscara datos importantes como contraseñas y numeros de tarjetas de credito, no habria seguridad para que dicho sniffer fuera incapaz de robarse esa informacion. Pero el ssh tambien se preocupa por eso. Mediante el empleo de un sistema de encripcion simetrico o tradicional, tal como el DES, blowfish, IDEA, DES-triple, entre otros. Estos sistemas simetricos, se basan en que ambas partes deben conocer una unica clave privada, que sera usada para tanto codificar, como decodificar la informacion mediante un algoritmo o sistema criptografico como los arriba mencionados. La cadena de caracteres aleatoria empleada en la verificacion y autenticacion del cliente, es tambien usada como la llave privada que sera la encargada de encriptar la informacion que se transmita en la sesion. Como esto lo hace ssh de por si, el usuario nunca tendra la necesidad de conocer claves, simplemente cuando instale el programa tendra que crear su llave publica y privada. De esta manera, se cumple el objetivo de ssh: La verificacion de autenticidad, y encriptacion de los datos en una sesion. Generalmente, el puerto empleado por el daemon de ssh para aceptar conexiones, es el 22 aunque bien podria ser cualquier otro, para garantizar mas privacidad entre los usuarios confiables.
Aparte de la simple conexion similar a telnet segura, que es el principal objetivo de ssh, tambien existe otra muy importante y util. Por medio de ssh, es posible 'tunelizar' o encapsular otras conexiones TCP por medio de su protocolo seguro. Es decir, cualquier conexion que sea mandada a traves de ssh, sera segura pues estara encriptada. Como ejemplo, esta POP, IMAP, X, NNTP, Kerberos, Finger, etc.
Pero no todo es color de rosa en la seguridad de ssh. En las versiones anteriores a la 1.2.18, existian ciertos errores *interesantes* en el protocolo. Hasta la 1.2.12.92, existia un error de seguridad que permitia a los usuarios acceder a la llave privada del host. Con esto, se podia hacer creer a un cliente que uno es el servidor, y entablar intercambio de informacion secreta. Anteriores a la 1.2.17 permitian que un usuario, pudiera tener acceso a las credenciales de seguridad de otro usuario diferente. Ssh 1.2.13 corriendo en ciertas m'aquinas (Alpha OSF 1.3 y SCO C2), podria permitir que un usuario local tuviera privilegios de root. Ademas, existe cierta 'caracteristica' especial en el ssh actual. Ssh, me permite redireccionar puertos a otra maquina, u a otro puerto, cosa que solo podria hacer en circunstancias normales root. Es decir, un usuario local podria hacer redireccionamiento de puerto a una maquina diferente, simplemente redireccionando cualquier puerto. Todo esto, es por el bit de setuid que generalmente se hace al instalar con privilegios de root. Esto se hace de la siguiente manera.
En ñ/.ssh/config , se debe agregar esta linea:
LocalForward 80 remotehost:80
Y luego, ejecutar el comando de redireccionamiento de un puerto a una direccion remota:
$ ssh -L xx:host_remoto:xx host_remoto
donde xx es el numero del puerto no asignado que se desea redireccionar, y host_remoto es la maquina a la que sera direccionado el puerto. Voila !
Esta 'caracteristica' ya es conocida por los creadores de ssh, y dicen que es posible que la retiren en un lanzamiento futuro.
Ssh puede igualmente, ejecutar comandos no interactivos hacia una maquina remota, de la manera:
$ ssh -l login maquina (comando)
Donde (comando) puede ser cualquier, como su nombre lo indica, comando que se desea ejecutar. Para ilustrar la idea, tomemos como comando a /bin/bash . Ssh, lo ejecuta como proceso hijo, de manera que no salen en los registros que estamos 'loggeados', esto es repito, porque es un proceso hijo del ssh. Es decir, cuando hacemos
$ ssh -l login maquina /bin/bash
login@maquina's password:
finger
No one logged on.
ps -ux
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
login 1004 0.0 0.9 1252 620 ? S 03:17 0:00 /bin/bash
Y nos loggeamos correctamente al servidor, tienes a tu disposicion un shell que no aparece cuando realizas un finger, ni tampoco aparece en los wtmp ni utmp. Pero si la maquina tiene un administrador que haga ps en vez de finger, te podra ubicar facilmente, como vimos atras.
Ssh es una herramienta bastante util, y ademas tiene pequeñas caracteristicas interesantes, las anteriores era para que se dieran una idea de lo que puede hacer por ustedes.
