Realizar copias de seguridad remotas con llaves SSH de propósito único

Introducción.

Es muy común que se deban desarrollar actividades en los servidores así como el subir y descargar archivos necesarios para o producto de estas actividades.  Un caso muy especial de este tipo de necesidades es la realización de copias de seguridad.

Del lado del servidor se acostumbra (si no se opta por una solución mas elaborada) crear scripts (1 y 2) que crean las copias empaquetadas de los archivos los cuales deben ser resguardados.  Generalmente la ejecución de esta tarea se realiza periódica y automáticamente a través de un proceso cron del sistema operativo.  Queda pendiente el problema de transferir esta información desde el servidor hasta el equipo local de manera segura y en lo posible automatizada.

La mejor opción para el transporte de los archivos es utilizar un método seguro basado en SSH, sin embargo el uso de contraseñas entorpece el desarrollo ya que estas dificultan la implementación y se constituyen como un riesgo ya que estas deben estar disponibles de manera legible en el cliente para ejecutar la utilidad de transferencia de archivos (como scp).

Gracias a la flexibilidad del protocolo SSH, es posible obviar la autenticación por contraseñas y utilizar un método basado en llaves, a través del cual se autoriza en el servidor el acceso directo a los usuarios que tengan su llave registrada en él.  De esta forma el usuario puede acceder a los datos de la cuenta y transmitirlos si es necesario.  La llave privada envuelta en esta configuración se cifra con una passphrase para mayor seguridad.  Esto hace que sea necesario introducirla, al menos una vez por sesión, antes de poder realizar satisfactoriamente la autenticación basada en llaves.

Esta situación va en contra de los requerimientos de la automatización ya que sería necesaria la intervención humana para realizar las copias de seguridad, al menos al inicio de esta.  Por suerte es posible eliminar la necesidad de esta passphrase de la llave privada, sin embargo se incurre en un significativo riesgo de seguridad (especialmente en servidores compartidos) ya que quien se apodere de los archivos de la llave, tendrá acceso total a la cuenta del usuario en el servidor remoto.

La solución final a este dilema es la utilización del esquema basado en llaves que he mencionado anteriormente pero utilizando llaves que tengan un fin único y específico, es decir, las llaves no permitirán el acceso total a la cuenta en el servidor sino que permitirán solamente la ejecución de una instrucción específica y previamente determinada, de esta manera no será tan crítica la eliminación de la passphrase.

Crear la llave de propósito único.

Generar la pareja de llaves.

$ ssh-keygen -t dsa -f ~/.ssh/demokey

Generating public/private dsa key pair.
Enter passphrase (empty for no passphrase):      [ENTER]   [1]
Enter same passphrase again:                     [ENTER]
[1]
Your identification has been saved in /home/jimezam/.ssh/demokey.
Your public key has been saved in /home/jimezam/.ssh/demokey.pub.
The key fingerprint is:
77:71:75:7e:d2:7a:f3:af:3f:77:cf:2d:77:6a:79:f3 jimezam@jimezam-ultra
The key’s randomart image is:
+–[ DSA 1024]—-+
|                o|
|               +.|
|            . o +|
|             o o.|
|        S . . …|
|         . .   .o|
|               ..|
|              ++O|
|             .oBE|
+—————–+

Especifique una passphrase vacía cuando se le solicite [1] para evitar que se le solicite nuevamente cada vez que vaya a ser utilizada la llave.  Tenga en cuenta el impacto de seguridad que esto pueda traer a su sistema.

Verifique la existencia de los archivos generados los cuales deberán ser similares a los siguientes.

$ ls -l ~/.ssh/

-rw——- 1 jimezam jimezam  668 2010-09-23 00:56 demokey
-rw-r–r– 1 jimezam jimezam  611 2010-09-23 00:56 demokey.pub

Especificar el propósito único de la llave.

Cree una copia de la llave pública recién generada.

$ cp ~/.ssh/demokey.pub tempkey

Esta tendrá un contenido similar al siguiente.

$ cat tempkey

ssh-dss AAAAB3Nza…(mas caracteres)… jimezam@mi-cliente

Modifíquelo de la siguiente manera.

$ vi tempkey

command=echo I’m `/usr/bin/whoami` on `/bin/hostname`,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nza…(mas caracteres)… jimezam@mi-cliente

Transmitir la llave de propósito único al servidor.

$ cat tempkey | ssh jimezam@mi-servidor ‘sh -c “cat – >>~/.ssh/authorized_keys2″‘

Por seguridad remueva la copia de la llave de propósito único después de haberla transmitido al servidor.

$ rm tempkey

Verificar el funcionamiento de la llave de propósito único.

La prueba se realiza intentando acceder al servidor utilizando SSH y la cuenta del usuario que posee la llave de propósito único.

$ ssh jimezam@mi-servidor

I’m jimezam on mi-servidor
Connection to mi-servidor closed.

Modificar el propósito único de la llave.

Siendo la precondición del artículo la necesidad de realizar copias de seguridad del servidor remoto, se va a modificar el propósito de la llave a crear un tar que contenga los archivos importantes y que será posteriormente transmitido al cliente a través de SSH.  La complejidad de este comando depende de los requerimientos que se tengan, sin embargo el ejemplo a continuación servirá como lineamientos básicos para su elaboración.

Como fácilmente se podrá concluír el comando es referenciado por la sección command al comienzo de la línea de la llave de propósito único.  Este comando puede ser especificado desde el cliente en el contenido de la llave si no se ha transmitido aún al servidor o podrá ser manipulado desde el servidor en el archivo ~/.ssh/authorized_keys2.

$ vi ~/.ssh/authorized_keys2

(modificar la llave específica)
from=”*.jorgeivanmeza.com,10.20.*command=”tar zcf – ~/tmp 2> /dev/null“,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss AAAAB3Nza…(mas caracteres)… jimezam@mi-cliente

El modificador from permite limitar desde cuales ubicaciones es posible utilizar la llave privada para acceder a la funcionalidad de las copias de seguridad.  En este caso sólo es posible acceder a través de SSH utilizando esta llave de propósito único desde cualquier equipo del dominio jorgeivanmeza.com o desde cualquier equipo de la subred 10.20.xxx.xxx.

En este caso particular, la llave de propósito único crea un tar de un directorio específico (~/tmp) y envía su flujo de bytes a través de la conexión SSH.

Obtener el archivo de la copia de seguridad.

Del lado del cliente el proceso inverso consiste en abrir una conexión SSH con el servidor utilizando la cuenta a la cual pertenece la llave de propósito único y obtener el archivo enviado a través de un flujo binario.

$ ssh -T -i ~/.ssh/demokey jimezam@mi-servidor | cat > miCopiaDeSeguridad.tgz

El parámetro -i es opcional y permite especificar el archivo con la identidad (llave privada) que se va a utilizar, mientras que el parámetro -T es necesario para transmitir un flujo binario de información.

Finalmente después de la ejecución anterior, en el cliente local se encuentra el archivo miCopiaDeSeguridad.tgz con la copia de seguridad del directorio ~/tmp del servidor.

Agradecimientos.

Gracias a Paul Keck por ayudarme a encontrar la dirección correcta para solucionar el problema del flujo binario de información (-T).

Enlaces.

Establecer una conexión web segura con un sitio web sin HTTPS a través de un tunel SSH con GNU/Linux

Introducción.

A pesar de que el hosting donde se almacena mi blog no cuenta con certificados SSL para poder implementar HTTPS siempre me había preguntado si era posible realizar conexiones seguras con ese servidor específico para realizar ciertas transacciones, es decir, me importaba especialmente mi acceso de administrador cuando debía ingresar mi nombre de usuario y contraseña para autenticarme ya que mediante el HTTP estas viajan planas (sin cifrado).

Ya que por estos días he vuelto a escribir acerca del protocolo SSH, me doy por fin la tarea de detallar este procedimiento, que a través de un túnel SSH con el servidor permite establecer conexiones seguras y temporales con el mismo.

Precondiciones.

  • El servidor cuenta, además del servicio HTTP, con el servicio de SSH.
  • El usuario cuenta con una cuenta de usuario y contraseña válidas para acceder al servidor a través de SSH.
  • La conexión se considera segura hasta el servidor que se contacta (el hosting del blog en mi caso), si se acceden sitios mas allá de él la transmisión será insergura.
  • El cliente cuenta con un navegador web que permita configurar su proxy.  Se recomienda utilizar Firefox.

Procedimiento.

Establecer el túnel seguro.

En esta etapa inicial se crea un túnel SSH entre el equipo cliente y el servidor (que almacena el blog).

$ ssh -fND 4711 usuario@mi.blog.com

El túnel se conecta del lado del cliente mediante el puerto 4711 (definido por el usuario).  La instrucción ssh es enviada automáticamente a background después de realizarse la autenticación (normalmente basada en nombre de usuario y contraseña).  Si desea evitar este comportamiento, remueva el parámetro -f de la instrucción.

Configurar a Firefox para utilizar el túnel.

Es necesario indicarle a Firefox que enrrute el tráfico de información a través del túnel recién creado.  Para hacer esto es necesario acceder a las preferencias de red mediante los menúes Edit > Preferences y allí activar la sección Advanced (parte superior) y presionar el botón Settings en la pestaña Network (parte media).

Configuración de conexión de Firefox

En el diálogo de configuración de conexiones seleccione la opción Manual proxy configuration y especifique la dirección 127.0.0.1 como SOCKS Host y 4711 como Port.  Este último valor deberá coincidir con el utilizado durante el establecimiento del túnel.

Una alternativa mas flexible a esta es el uso de FoxyProxy, un plugin para Firefox que permite manipular sus proxies de una forma mas eficiente.  Presione CTRL+F2 para acceder a la configuración de este plugin, presione el botón Add New Proxy e ingrese la información del túnel.

FoxyProxy plugin, Proxy Settings

Configurar a Firefox para incluír las peticiones de DNS a través del túnel (opcional).

Hasta este punto la comunicación entre el cliente y el servidor, a pesar de que se realiza utilizando el protocolo HTTP, se realiza de manera cifrada ya que se hace utilizando el túnel SSH.  Por fuera de esta comunicación quedan las solicitudes para resolver nombres a través del servicio DNS que hace el cliente antes de transmitir la información a través del túnel.  Esto probablemente no sea un riesgo significativo de seguridad pero enrrutarlas a través del túnel confiere un poco mas de privacidad, al menos a nivel de la LAN ya que no será posible identificar localmente esta información mediante el uso de un sniffer.

Por suerte Firefox permite configurarse para incluír las peticiones al DNS a través de un proxy SOCKS, el cual en este caso es el túnel SSH.  Para hacer esto es necesario acceder al siguiente URL en el navegador: about:config.

Opciones de configuración de Firefox relacionadas con proxies.

Finalmente ubique la variable network.proxy.socks_remote_dns y modifique su valor a true.

Si utiliza FoxyProxy puede realizar esta configuración por proxy ingresando a la configuración del proxy elegido (Proxy Settings) y seleccionando la casilla de verificación Perform remote DNS lookups on hostnames loading through this proxy en la pestaña General.

Finalizar el túnel.

Para terminar la existencia del túnel simplemente finalice la aplicación de ssh, ya sea terminando la aplicación con CTRL+C (si no estaba en background) o matando su proceso mediante el comando kill.

Recuerde ajustar nuevamente el proxy activo en Firefox para continuar utilizando el tipo de conexión habitual en su equipo.

Autenticación basada en llaves para SSH

Introducción.

A diario utilizamos el protocolo SSH para establecer conexiones seguras entre servidores y acceder a shells remotos, montar sistemas de archivos remotos y crear túneles entre muchas otras facilidades.  Habitualmente nos autenticamos ante el servidor remoto utilizando contraseñas, es decir, para indicarle quienes somos le enviamos nuestro nombre de usuario y para garantizarle al servidor que efectivamente somos quienes decirmos ser, el enviamos nuestra contraseña, la cual es secreta y sólo el servidor y nosotros la conocemos.

Este es el método de autenticación mas utilizado y viene por defecto con la instalación del servicio SSH, sin embargo no es muy práctico cuando es necesario interactuar en múltiples ocasiones con múltiples servidores ya que será necesario ingresar la contraseña para autenticarnos múltiples veces.  Una solución a este problema es el uso de llaves (privada y pública) para autenticarnos con el servidor remoto.

El procedimiento es simple, el cliente crea su propio par de llaves y le envía al servidor remoto su llave pública.  En el servidor se agrega esta llave recibida a la lista de llaves autorizadas para su conexión.

La próxima vez que el usuario (que cuenta con sus llaves) intenta acceder al servidor a su cuenta (que cuenta con su llave pública autorizada), este último utilizará el método basado en llaves para autenticarlo con el cual no será necesario que ingrese su contraseña nuevamente.

En este punto es necesario hacer una aclaración, la idea fundamental es la de evitar la necesidad de especificar la contraseña del usuario frecuentemente, sin embargo la llave privada del usuario viene por defecto encriptada con una passphrase, la cual debe especificarse cada vez que el usuario la va a utilizar.

La diferencia de uso entre la contraseña y la passphrase es que esta última puede ser recordada mediante agentes SSH los cuales almacenan las passphrases la primera vez que se utilizan y la proveen automáticamente en las veces subsecuentes, es decir, en una sesión de trabajo sólo será necesario escribir una única vez la passphrase específica de una llave para la autenticación basada en estas.

Existen distintos agentes SSH como ssh-agent (incluído con OpenSSH), GNUPG Agent que tiene emulación para OpenSSH, keychain y GNOME Keyring entre otros.  En mi caso utilizo GNOME así que utilizo el Keyring que viene con él por defecto.

Configuración.

Crear las llaves en el cliente.

En el cliente se inicia creando la pareja de llaves, pública y privada.

$ ssh-keygen -b 1024 -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key (/home/jimezam/.ssh/id_dsa):   [1]
Enter passphrase (empty for no passphrase):                        [2]
Enter same passphrase again:                                       [3]
Your identification has been saved in /home/jimezam/.ssh/id_dsa.
Your public key has been saved in /home/jimezam/.ssh/id_dsa.pub.
The key fingerprint is:
55:32:22:01:1f:b3:5c:f1:44:28:49:55:93:55:f9:1f jimezam@micliente
The key’s randomart image is:
+–[ DSA 1024]—-+
|        ..*=*=+++|
|         o.Ooo.=.|
|          =  .=  |
|         .     . |
|        S       .|
|                E|
|                .|
|                 |
|                 |
+—————–+

Se recomienda utilizar la ubicación sugerida por defecto [1] para el almacenamiento de las llaves.  En este punto [2] debe especificarse el passphrase (concepto que se introdujo en la sección anterior) para cifrar la llave privada, es necesario que recuerde muy bien la cadena de texto que utilizó ya que debe ser utilizada durante su confirmación [3] y una vez por sesión cada vez que vaya a realizar la autenticación basada en llaves con otro servidor.

Terminado este procedimiento se deberá tener dos archivos nuevos con las llaves recién generadas: id_dsa.pub es la llave pública y id_dsa es la llave privada.

$ file ~/.ssh/id_dsa.pub

id_dsa.pub: OpenSSH DSA public key

$ file ~/.ssh/id_dsa

id_dsa: PEM DSA private key

Transmitir la llave pública al servidor.

El siguiente paso es el de transmitir la llave pública del usuario en el cliente al servidor.

$ scp ~/.ssh/id_dsa.pub jimezam@miservidor:

Autorizar en el servidor la llave pública enviada desde el cliente.

Se autoriza la llave pública enviada desde el cliente para que el servidor confíe en ella la próxima vez que el primero intente autenticarse.  Para esto se realiza una conexión remotoa con el servidor.

$ ssh jimezam@miservidor

Ya en el servidor se ejecutan los siguientes comandos.

$ mkdir ~/.ssh

$ chmod go-w ~/.ssh

$ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys

$ rm ~/id_dsa.pub

$ chmod 600 ~/.ssh/authorized_keys

Utilización.

La próxima vez que el usuario (con las llaves) intenta acceder a través de SSH al servidor (que confía en la llave pública) el agente SSH que esté utilizando (en mi caso GNOME) le solicitará una única vez el passphrase de la llave privada [2] y de allí en adelante autenticará de manera transparente las demás sesiones que abra el usuario.

$ ssh jimezam@miservidor

GNOME Keyring solicitando una passphrase

Enlaces.

para que confíe en ella la próxima vez que el primero intente autenticarse.

Agilizar las conexiones con SSH

Introducción.

Revisando información acerca del protocolo SSH encontré en el Wiki de ArchLinux unos tips muy interesantes para agilizar las conexiones con los servidores remotos.  A continuación incluyo una reseña de estas sugerencias.

Limitar los algoritmos de cifrado.

No estoy muy seguro cuan buena opción en términos de seguridad sea hacer esto sin embargo es una opción.  La idea es limitar los algoritmos que usa el protocolo para utilizar sólo aquellos que demandan menos recursos de CPU y por ende son mas rápidos.  En este caso se sugiere utilizar ArcFour y Blowfish-CBC.

Para hacer esto en la conexión actual únicamente se debe realizar la conexión de la siguiente manera.

$ ssh -c arcfour,blowfish-cbc usuario@servidor

Si se desea realizar este cambio permanentemente es necesario modificar la configuración del cliente SSH.

$ sudo vi /etc/ssh/ssh_config

Ciphers arcfour,blowfish-cbc

Activar la compresión.

Para hacer esto en la conexión actual únicamente se debe realizar la conexión de la siguiente manera.

$ ssh -C usuario@servidor

Si se desea realizar este cambio permanentemente es necesario modificar la configuración del cliente SSH.

$ sudo vi /etc/ssh/ssh_config

Compression yes

Desactivar la comprobación de IPV6.

Para hacer esto en la conexión actual únicamente se debe realizar la conexión de la siguiente manera.

$ ssh -4 usuario@servidor

Si se desea realizar este cambio permanentemente es necesario modificar la configuración del cliente SSH.

$ sudo vi /etc/ssh/ssh_config

AddressFamily inet

Mantener viva la conexión.

Cuando se trabaja con varias sesiones remotas es frecuente que estas se desactiven por falta de uso (timeout) lo cual es bastante molesto ya que es necesario volver a conectar para continuar con el trabajo.  Esto sucede por razones de seguridad ya que intenta bloquear las conexiones que han sido abiertas y probablemente han sido abandonadas y así impedir que personas no autorizadas puedan acceder al shell, así como optimizar los recursos utilizados por parte de los usuarios.

La idea en este caso es configurar las conexiones de forma que se adecúen a los tiempos de espera que se presentan en el uso del administrador.  En mi caso utilizo los siguientes valores.

$ sudo vi /etc/ssh/ssh_config

ServerAliveInterval 60
ServerAliveCountMax 10

El primer valor  (ServerAliveInterval) le indica al cliente que envíe cada cierto tiempo (magnitud en segundos) paquetes al servidor para indicarle que la conexión continúa con vida.  El segundo valor (ServerAliveCountMax) indica el número de mensajes de vida que pueden ser enviados por el cliente sin recibir respuesta del servidor antes de abortar la comunicación automáticamente.

Crear alias para los servidores.

Esta opción es muy practica cuando se deben realizar conexiones con múltiples servidores y cada una de ellas con características muy específicas, permite establecer parámetros de conexión determinados y nombrarlos bajo un alias para permitir realizar conexiones rápidas con ellos.

La información de los alias de las conexiones es independiente para cada uno de los usuarios del sistema.  Es posible utilizar las opciones válidas del archivo /etc/ssh/ssh_config para establecer los parámetros de configuración de cada una de las conexiones.

$ vi ~/.ssh/config

Host servidor1
HostName 123.123.123.123
Port 12345
User jimezam
Host servidorweb
HostName mi.servidorweb.com
User jimezam
CheckHostIP no
Cipher blowfish

Una vez que se han establecido los alias es posible realizar las conexiones SSH referenciándolos.

$ ssh servidorweb

Crear las sesiones SSH a través de una única conexión.

Esta es la sugerencia que mas me pareció interesante ya que hasta el momento no la conocía.  Permite indicarle al cliente de SSH que envíe las sesiones a través de una única conexión, es decir, la primera vez que se realiza una sesión con un servidor y un usuario específicos el procedimiento de conexión se realiza normalmente, sin embargo las sesiones siguientes en iguales condiciones reutilizan la conexión vigente así que ya no es necesario realizar la autenticación de nuevo.

La configuración de esta opción puede realizarse en el archivo /etc/ssh/ssh_config si se desea que aplique a todos los usuarios del sistema o en ~/.ssh/config si se desea que sólo aplique a un usuario específico.

ControlMaster auto
ControlPath ~/.ssh/socket-%r@%h:%p

Enlaces.

Ejecutar aplicaciones X remotas a través de SSH en GNU/Linux

Introducción.

Otra característica muy práctica que es permite el protocolo SSH (OpenSSL) es la ejecución remota de aplicaciones X.  Esto es, la facilidad de ejecutar aplicaciones gráficas (X) en servidores remotos y recibir su contexto gráfico (ventana) en el escritorio remoto de la misma manera como se ejecutan las aplicaciones locales.  Sobra decir que la comunicación cliente/servidor a través de la cual viajan las peticiones y respuestas de la aplicación se realiza a través de una conexión encriptada así que es posible hacerlo sobre un medio inseguro como Internet.

Hace un par de años había explicado como hacerlo bajo Windows, esta vez voy a documentar como hacerlo bajo GNU/Linux Ubuntu 10.04 (aunque en términos generales aplica para cualquier distribución) donde es aún mas natural.

Requerimientos.

  • Tanto el cliente como el servidor deberán estar ejecutando servidores de ventanas X.
  • El servidor cuenta con el servicio de SSH.
  • El cliente cuenta con un cliente para SSH.
  • El usuario en el cliente tiene una cuenta de usuario con acceso de SSH en el servidor.

Configuración.

En el servidor.

Las siguientes opciones son necesarias en la configuración del servicio SSH en el servidor.

$ sudo vi /etc/ssh/sshd_config

AllowAgentForwarding yes
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes

Después de realizadas las modificaciones en la configuración del servicio es necesario reiniciarlo para que estas sean tenidas en cuenta.

$ sudo /etc/init.d/sshd restart

En el cliente.

No es necesaria ninguna modificación.

Implementación.

Desde el cliente inicie una sesión SSH con el servidor remoto.

$ ssh -X jimezam@mi.servidor.com

jimezam@mi.servidor.com’s password: ******

Nótese el uso del parámetro -X (en mayúscula!) el cual permite la transmisión del protocolo X a través de la conexión segura.

-X      Enables X11 forwarding.  This can also be specified on a per-host
basis in a configuration file.

X11 forwarding should be enabled with caution .  Users with the
ability to bypass file permissions on the remote host (for the
user’s X authorization database) can access the local X11 display
through the forwarded connection.  An attacker may then be able
to perform activities such as keystroke monitoring.

For this reason, X11 forwarding is subjected to X11 SECURITY
extension restrictions by default.  Please refer to the ssh -Y
option and the ForwardX11Trusted directive in ssh_config(5) for
more information.

En el shell de la sesión simplemente invoque las aplicaciones (remotas) que desee ejecutar, estas aparecerán en el escritorio local con su mismo look-and-feel.

Ejecución de aplicaciones remotas a través de SSH

En el ejemplo anterior, el servidor remoto (parte izquierda) sirve remotamente las aplicaciones ejecutadas que se muestran como ventanas locales (parte derecha).  En este caso se ejecutaron xclock, xeyes y xterm.

El servidor se utiliza XFCE como manejador de ventanas (azules) mientras que el cliente utiliza GNOME (negras), nótese como las aplicaciones remotas, enunciadas en el párrafo anterior, aparecen en ventanas negras adaptándose al manejador de ventanas local.

Enlaces.

Curso de clusters en la Universidad Autónoma de Manizales, julio de 2010

Durante tres días de la última semana del mes de junio estuve dictando un curso práctico acerca de la instalación, configuración y uso de un cluster utilizando Condor y software libre como parte de la difusión de los conocimientos que he adquirido durante el desarrollo del proyecto GridUAM.

Al curso asistieron 18 participantes quienes representaban a las principales instituciones educativas y de investigación del eje cafetero que están interesadas en la computación de alto desempeño.

Los temas tratados durante el curso fueron los siguientes.

  1. Introducción al proyecto y conceptual.
  2. Instalación del cluster.
    1. Instalación del sistema operativo Scientific Linux 5.5.
    2. Preparación básica del nodo cabeza y de los nodos trabajadores.
    3. Configuración del servicio de SSH.
    4. Configuración del servicio de NFS.
    5. Configuración de las cuentas de usuario.
  3. Instalación de Condor en el nodo cabeza y en los nodos trabajadores.
  4. Pruebas y uso básico del cluster.
  5. Universos del cluster.
    1. Vanilla.
    2. Standard.
    3. Java.
  6. Seguridad del cluster con firewall y host.allow/deny.

Se realizó también un práctica adicional que consistió en el cambio del hostname de los nodos, analizándolo desde la perspectiva de su implicación en la configuración del cluster. La práctica final que consistía en la instalación individual de nodos en máquinas virtuales basadas en VirtualBox no pudo completarse satisfactoriamente debido a problemas con el hardware con que disponíamos en las salas de cómputo.

Participantes del curso de clusters y grids en julio de 2010 en la Universidad Autónoma de Manizales

Durante los tres días siguientes al curso de clusters contamos con la presencia del ingeniero Cesar Orlando Diaz quien en representación del proyecto Grid Colombia, complementó la jornada al dictarnos un curso práctico acerca de la conformación de la grid basada en los clusters que habíamos preparado previamente.

En este segundo curso se trataron los siguientes temas.

  1. Introducción conceptual.
  2. Instalación del cliente de la grid.
  3. Tipos de certificados requeridos.
  4. Instalación y configuración del computer element (CE).
  5. Instalación y configuración del grid user management system (GUMS).
Participantes del curso de clusters y grids en julio de 2010 en la Universidad Autónoma de Manizales

En lo personal quiero agradecer a los participantes del curso por la asistencia al evento y felicitarlos por contar con la visión necesaria para aprovechar estas nuevas tecnologías, ya presentes en nuestra región: redes académicas de alta velocidad, computación de alto desempeño y mallas computacionales, a su quehacer diario, encontrando mejores formas de hacer las cosas, innovando y mejorando el progreso de nuestra región.

Los contenidos del curso y en general, del proyecto GridUAM pueden ser consultados en su Wiki, el cual está en constante complemento y actualización. De igual manera recomiendo que sea consultado el Wiki de GridColombia para conocer mas información acerca de este proyecto.


Tomado de Curso de clusters en la Universidad Autónoma de Manizales, julio de 2010 del proyecto GridUAM.

Crear un tunel SSH para la conexión a un servidor MySQL detrás de un firewall con Windows utilizando Putty

Introducción.

De manera análoga a como se realizó el tunel SSH utilizando Linux, también es posible implementarlo en Windows gracias al uso de herramientas de terceros como Putty.

Para la verificación de la conexión a la base de datos en lugar de la herramienta básica de línea de comando (que también debe funcionar normalmente) se utilizará MySQL Workbench que es la herramienta de administración gráfica que provee el motor de bases de datos.

Implementación de la solución.

Crear la especificación del tunel en Putty.

Este paso sólo es necesario realizarlo una única vez mientras se configura el perfil en Putty, en ocasiones posteriores sólo será necesario invocarlo.

Ejecute Putty.exe.

Session en Putty.exe
Session en Putty.exe

En la Session (lado izquierdo) especifique la siguiente información.

1. Nombre del servidor SSH.  desarrollo.com para este ejemplo.

2. Puerto del servicio SSH.  Es el puerto 22 por defecto.  Elija además el tipo de conexión (Connection type) SSH.

3. Especifique un nombre para almacenar la sesión (Saved Sessions).  MiTunel para este ejemplo.

4. Presione el botón guardar (Save) para almacenar la configuración recién especificada.

Connection > SSH en Putty.exe
Connection > SSH en Putty.exe

En las opciones de Connection > SSH elija la casilla de verificación Don’t start a shell para evitar que se cree una consola de comandos interactiva ya que sólo se desea crear el tunel.

Connection > SSH > Tunnels en Putty.exe
Connection > SSH > Tunnels en Putty.exe

Determine la información relacionada con los lados del tunel.

5. Especifique el puerto local desde el cual se iniciará el tunel.  3307 en este caso.

6. Especifique el destino y su puerto donde terminará el tunel.  localhost:3306 para este ejemplo.

Presione el botón agregar (Add) para almacenar los extremos del tunel.

Finalmente almacena la configuración establecida regresando a la sección de Session y presionando el botón de guardar (Save).

Establecer un tunel previamente especificado.

Esto se puede hacer de dos maneras, una desde la interfaz gráfica de Putty seleccionando MiTunel en la lista de las sesiones guardadas (Saved Sessions), presionando el botón cargar (Load) y abriendo la sesión presionando el botón (Open).

Una segunda alternativa es desde la línea de comando ejecutando la siguiente instrucción.

C:rutaaputty.exe -load MiTunel

En ambos casos el resultado es el mismo, aparecerá una ventana de login para realizar la autenticación con el servidor remoto (6).

Autenticación de usuario con SSH.
Autenticación de usuario con SSH.

Realizar la conexión a MySQL a través del tunel SSH.

Como se mencionó inicialmente para la verificación de la conexión se utilizará MySQL Workbench.

Connect to database
Connect to database

Debe tenerse muy en cuenta que gracias al tunel recién creado, la aplicación cliente de la base de datos interpretará que el motor de base de datos se encuentra ubicado localmente (9) y que su puerto es el 3307 (10) -ver 5 y 6-.

Crear un tunel SSH para la conexión a un servidor MySQL detrás de un firewall con Linux Debian 5

Introducción.

Este es el panorama del esquema de red de la oficina del grupo de desarrollo.

Esquema de la red
Esquema de la red

Un servidor (centro) alberga los proyectos web (Apache) de los cuales el grupo de desarrollo manipula sus archivos (SSH + Samba), así como sus bases de datos (MySQL).  El servidor cuenta con dos interfaces de red las cuales separan físicamente el acceso de la red privada (eth1) de la red pública o Internet (eth0).

Los desarrolladores utilizan los clientes desde la red privada para la cual no hay ningún tipo de filtro en el servidor y pueden acceder a la totalidad de sus servicios.  Desde el exterior, el servidor implementa un firewall que sólo permite la consulta web de los proyectos y el acceso al SSH.  Como fácilmente se concluye, el firewall de la interfaz pública (eth0) filtra explícitamente el acceso a los servicios de MySQL y Samba que son considerados como inseguros.

El problema.

Se requiere ahora que los desarrolladores puedan acceder al servidor desde sus clientes a través de Internet.

El problema se divide en dos aproximaciones.

  1. Manipular el software, el código y los datos remotamente.
  2. Manipular el software y el código localmente, y los datos remotamente.

La solución.

Manipular el software, el código y los datos remotamente (1).

Este es el caso mas simple.  Como los aplicativos son web se acceden a través de un navegador, su código es manipulado a través de SSHFS (ver instrucciones para Linux y Windows) y sus datos son manipulados a través de la web con PHPMyAdmin.

Manipular el software y el código localmente y los datos remotamente (2).

Este caso es mas elaborado que el anterior ya que el software y el código reside localmente porque lo es muy fácil de manipular, sin embargo los datos (la base de datos MySQL) de los proyectos continúan viviendo en el servidor de desarrollo.

Dado que el puerto de acceso a MySQL se encuentra filtrado para el exterior por razones de seguridad es inicialmente imposible conectarse a la base de datos desde el cliente a través de Internet.  La solución es crear un tunel SSH desde el cliente remoto hasta el servidor a través del medio inseguro (Internet) y desde allí, ahora un lugar seguro, realizar la conexión con el puerto de la base de datos que en este caso reside en el mismo servidor.

Implementación de la solución (2).

Por razones que serán obvias, es necesario que los usuarios remotos cuenten con cuentas (nombre de usuario/contraseña) en el sistema operativo del servidor de desarrollo y que estas estén habilitadas para acceder al mismo a través de SSH.

Las siguientes acciones se realizan desde el cliente remoto.

Establecer el tunel SSH entre el cliente remoto y el servidor de desarrollo.

$ ssh desarrollador@desarrollo.com -L 3307:localhost:3306 -N -f

Con la instrucción anterior estamos creando un tunel entre el cliente remoto y el servidor desarrollo.com con el usuario desarrollador y utilizando al protocolo SSH.  Se le está indicando además que el tunel se deberá establecer entre el puerto 3307 local y el puerto 3306 del servidor remoto, en este caso el mismo localhost.  Es muy importante tener en cuenta que la referencia de este último servidor remoto se realiza previa conexión a desarrollo.com, es decir que su acceso se hace desde este y no directamente desde el cliente que inicia la conexión del tunel ejecutando el comando.

Otro aspecto interesante a tener en cuenta es que los puertos utilizados no necesariamente deben ser diferentes ya que uno es local (3307 en este ejemplo) y el otro es remoto (3306 el estándar de MySQL), sin embargo en el caso de que ya se cuente con una instalación local de MySQL (utilizando el puerto 3306) será entonces necesario utilizarlos diferentes como se ha planeado en este artículo.

Realizar la conexión a MySQL a través del tunel SSH.

Después de establecido el tunel entre cliente y servidor la conexión se realiza directamente con el puerto local (3307) del cliente remoto como si el servicio se estuviera ejecutando en la misma máquina cliente, el tunel se encarga de transmitir la información encriptada y realizar las conversiones necesarias a cada uno de los lados.

$ mysql -h 127.0.0.1 -u bd_usuario -p -P 3307 bd_nombre

Tenga en cuenta que el inicio de conexión (connect) a una base de datos toma cierto tiempo ya que el motor de bases de datos realiza una carga previa de los nombres de las tablas y de los campos de estas.  Si desea evitar esta precarga de información puede utilizar el parámetro -A en la invocación al cliente de MySQL (mysql).

Scripts de conexión.

A pesar de que el procedimiento es -extremadamente- simple, he creado un par de scripts para facilitar y automatizar el proceso de creación del puente SSH y de conexión a la base de datos a través de línea de comando.

Los scripts pueden ser descargados de aqui y configurados utilizando cualquier editor de texto.  tunssh_connection se encarga de establecer la conexión del túnel SSH mientras que tunssh_mysql realiza la conexión a la base de datos MySQL remota a través del túnel SSH.

Enlaces.

Problemas de autenticación/autorización de un 3Com OfficeConnect Wireless Router

Introducción.

El viernes pasado mientras aprendía acerca de Team Software Process se me ocurrió echar una mirada para intentar encontrar la dirección del filtro de contenido de la red que en la que estaba que la hacía prácticamente inútil bloqueando la mayoría de los sitios web de interés general.

Un traceroute de los sitios bloqueados no me mostró la ubicación que quería, sólo permitía llegar hasta el enrrutador inalámbrico que me estaba permitiendo acceder a la red LAN.  Decepcionado terminé saludándolo para darme cuenta de un problema de seguridad que ocultaba.

Conociendo al dispositivo.

Inicialmente no me dijo mucho, sólo que aparentemente era un dispositivo 3Com (o al menos su interfaz de red lo era).

$ sudo nmap -sA -O 192.168.2.1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-16 08:10 COT
All 1000 scanned ports on 192.168.2.1 are unfiltered
MAC Address:
00:FF:C1:4D:FF:EE (3com Europe)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

Posteriormente lo confirmé al ver que el dispositivo 3Com ejecutaba aparentemente una versión de Linux con el kernel 2.6 lo cual es relativamente reciente.

$ sudo nmap -sS -O 192.168.2.1

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-16 08:09 COT
Interesting ports on 192.168.2.1:
Not shown: 998 closed ports
PORT   STATE SERVICE
53/tcp open  domain
80/tcp open  http
MAC Address: 00:FF:C1:4D:FF:EE (3com Europe)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.22

Network Distance: 1 hop

También se hizo evidente que el dispositivo permitía su administración a través de web (puerto 80).

Accediendo a el dispositivo utilizando un navegador web encontré que era finalmente un 3Com OfficeConnect Wireless 11g.  Sabiendo esto investigué un poco si había problemas conocidos con este dispositivo.

La vulnerabilidad.

Resulta que estos dispositivos manejan incorrectamente la autenticación/autorización de su módulo web de administración, protegiendo correctamente a las páginas pero permitiendo el acceso directo a los CGIs.  Esto unido a que el método de copia de seguridad de la configuración del router genera un archivo (config.bin) con esta información y lo almacena en su memoria interna para que el administrador lo descargue, termina convirtiéndose en un grave problema de seguridad.

El archivo puede descargarse mediante un CGI llamado SaveCfgFile así que para obtenerlo sólo es necesario acceder a él mediante un navegador web.

http://192.168.2.1/SaveCfgFile.cgi

El archivo contiene toda la configuración del enrrutador, incluyendo su información de red y contraseñas de administración!


httpd_username=admin
httpd_password=admin

mradius_username=admin
mradius_password=admin
mradius_secret=mradius1218
mradius_port=1812

http_username=admin
login_password=admin
http_passwd=admin

Conclusiones.

Esta vulnerabilidad fue reportada a 3Com por Luca Carettoni de ikkisoft.com en diciembre de 2008 y fue conocida por el público en general en febrero del 2009.

Supongo que desde hace tanto tiempo para acá 3Com ya ha solucionado esta vulnerabilidad y se encuentra disponible una actualización del firmware que la soluciona.

Debe tenerse especial cuidado en los dispositivos que tengan la opción de Remote Administration activa ya que esta vulnerabilidad podrá ser explotada desde Internet.

Enlaces.

Instalar Chromium Browser en Linux Ubuntu 9.10

Actualización.

Ubuntu 10.x.

Este procedimiento continúa vigente si cambios para las versiones 10.04 y 10.10 de Ubuntu.

Introducción.

Chromium Browser (Chrome) es el navegador web de Google que desde hace un tiempo puede ser descargado y utilizado en la plataforma Windows.  Desafortunadamente aún no hay una versión (release) oficial para la plataforma Linux, sin embargo es posible instalarlo en Ubuntu mediante un PPA de frecuente actualización.

Instalación.

Agregar el repositorio.

$ sudo add-apt-repository ppa:chromium-daily/ppa

Instalar los paquetes.

$ sudo aptitude update

$ sudo aptitude install chromium-browser chromium-codecs-ffmpeg

Ejecución.

screenshot_007

Ejecutar la aplicación desde el menú de programas a través de la siguiente ruta.

Applications > Internet > Chromium Web Browser.

O desde la línea de comando como se muestra a continuación.

$ /usr/bin/chromium-browser &

Enlaces.