Realizar copias de seguridad remotas con llaves SSH de propósito único (2 – el camino inverso)

Introducción.

Después de encontrar una forma muy interesante de hacer las copias de seguridad mediante el uso de llaves de propósito único mi mente inquieta se ha quedado pensando acerca de la factibilidad de hacer lo mismo pero en sentido contrario y de la posible utilidad para el mismo problema: el método mas simple, seguro y fácil de implementar para hacer las copias de seguridad.

En el artículo anterior se configuró al servidor para que confiara en el cliente que portara el par de llaves adecuado, esta confianza le permitiría al servidor ejecutar un único comando y retornar la información resultante al cliente el cual podría tomar el flujo binario de bytes y crear con él un archivo.  En este caso, cualquiera que tuviera posesión de los archivos de la llave y la passphrase (si las llaves se crearon con ella) podrían ejecutar el comando único, en otras palabras, obtener la copia de seguridad del servidor.  En términos generales esto no debe suceder, no debe ser un riesgo ya que supuestamente las llaves se encuentran bien resguardadas, sin embargo estamos analizando el peor escenario.

Ahora, cómo sería el caso contrario en el que el antes cliente (quien almacena las copias de seguridad) confiara en el servidor (a quien se le va a hacer la copia de seguridad) y recibiera todos los archivos que este le envía y los almacenara en el sistema de archivos.  Es posible implementarlo ?  En caso de comprometerse la pareja de llaves, cuál sería el peor escenario ?

Como lo veo hasta el momento, el atacante estaría posibilitado a subir todos los archivos que quisiera llenando la partición del sistema de archivos (ataque por denegación de servicio – DOS) e interfiriendo con el uso normal del sistema.  Podría además sobreescribir (dependiendo de como se cree el script local) los archivos sobre los cuales cuenta con suficientes permisos.  Estos efectos se minimizarían con el uso de un usuario específico para las copias de seguridad, la asignación de una cuota de disco, la implementación de un buen script en el cliente y un contínuo seguimiento al éxito de las copias de seguridad.  En términos generales es aún mas promisorio que la primera versión (directa).  Vale la pena explorar esta aproximación.

Desde el punto de vista funcional hay una diferencia que debe tenerse en cuenta, la primera aproximación es útil inclusive para realizar las copias de seguridad desde equipos que no siempre están activos o en línea, ya que puede realizarse por demanda; mientras que la segunda aproximación analizada a continuación, requiere que ambos equipos estén en línea al mismo tiempo ya que el procedimiento probablemente se inicie por un proceso cron en el servidor.

Crear la llave de propósito único.

Para la creación de la llave de propósito único se siguen los mismos pasos realizados durante la experimentación con la versión directa, con la diferencia que ahora el servidor es el equipo donde se almacenan las copias de seguridad y el cliente es el equipo que contiene la información a la cual se le desea hacer copia de seguridad.  De esta manera, las llaves (demokey y demokey.pub en el ejemplo) se crearían en el servidor web (por ejemplo) y se crearía el archivo ~/.ssh/authorized_keys2 con el contenido apropiado en el servidor de copias de seguridad.

Crear el script para recibir las copias de seguridad.

Del lado del servidor de copias de seguridad (donde se almacenarán) se crea a manera de ejemplo la siguiente configuración.

Una ruta donde se almacenarán las copias de seguridad.

$ mkdir -p /u/backups/datos

$ chown -R bkpuser /u/backups

$ chmod -R 700 /u/backups

Se crea un script para recibir los archivos con las copias de seguridad y almacenarlos en la ubicación creada anteriormente.

$ vi /u/backups/recibir.sh

# Fecha de creación de la copia de seguridad.
FECHA=`date +%Y%m%d`
# Hora de creación de la copia de seguridad.
HORA=`date +%H%M%S`
# Ubicación donde se almacenan las copias de seguridad.
DIRECTORIO=/u/backups/datos
# Nombre del archivo donde se almacenará la copia de seguridad.
ARCHIVO=”backup-${DATE}-${TIME}.data”

# Almacenar la información de la copia de seguridad.
cat > $DIRECTORIO/$ARCHIVO

# Reportar al cliente el nombre del archivo utilizado.
echo $ARCHIVO

$ chmod +x /u/backups/recibir.sh

Finalmente se configura la llave (authorized_keys2) para que invoque a recibir.sh como su propósito único.

$ vi ~/.ssh/authorized_keys2

(modificar la llave específica)
from=”*.jorgeivanmeza.com,10.20.*” command=”/u/backups/recibir.sh“,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.

Realizar una copia de seguridad.

Para iniciar una copia de seguridad desde el servidor de aplicaciones (servidor web por ejemplo) sólo es necesario ejecutar el siguiente comando.

$ tar zcvf – /ruta/a/resguardar 2> /dev/null | ssh bkpuser@mi-servidor


backup-20100927-205847.data

En el ejemplo anterior se realizó la copia de seguridad de los directorios bajo /ruta/a/resguardar y se guardó en mi-servidor en un archivo llamado backup-20100927-205847.data.  Esta última información puede resultar útil para guardar el registro de los archivos de copias de seguridad generados.  Otra alternativa mas elegante sería utilizar llaves de propósito único para cada servidor al cual se le va a hacer copia de seguridad de forma que se pueda especificar claramente que archivo corresponde a que servidor.

Leave a Reply

Your email address will not be published. Required fields are marked *