Cifrando el servidor en seis pasos

Una práctica recomendable cuando se utilizan servidores es cifrar los datos del servidor, especialmente cuando éste se encuentra en un lugar poco protegido o cuya seguridad no controlamos (por ejemplo, la sala de café, el despacho de alguien, un CPD externo, etc.). Esto evita que la información almacenada pueda ser comprometida y expuesta, si alguien roba el equipo o extrae el disco para clonarlo.

Pero (siempre hay un pero), hay un pequeño problema cuando se realiza un cifrado completo mediante LVM y LUKS. Si el servidor necesita ser reiniciado (o falla, que también puede pasar) se necesita que alguien físicamente introduzca la clave de cifrado para arrancar de nuevo. Ni que decir tiene que esto puede ser un problema si no tenemos un 24×7 o acceso físico al servidor (o no queremos compartir la clave de cifrado con el personal 24×7).

Vamos a resolver este problema siguiendo unos sencillos pasos. Estos pasos que se ofrecen aquí son válidos para archlinux y distribuciones similares (manjaro, atergos, chakra, etc); en este caso se ha utilizado un manjaro linux para llevar a cabo las pruebas. Hay que tener en cuenta que arch y derivados utilizan durante el arranque mkinitcpio lo que les diferencia de otras distribuciones y significa que los pasos explicados en este post no valen para Debian u otras distros no basadas en arch linux. Para ellas existen otros métodos equivalentes.

Por supuesto, no está de más recordar que si alguien quiere probar estos pasos, debe hacerlo primero en un sistema de pruebas, y antes de hacerlo en producción garantizar que se dispone de una copia actualizada de los datos. Copia que también es recomendable que vaya cifrada, por supuesto. Sobra decir que no nos responsabilizamos de los daños que se puedan causar por imprudencia o desconocimiento. Los experimentos con gaseosa.

Pues al lío:

Paso 1

Instalar los paquetes de AUR (con yaourt):

  • mkinitcpio-netconf.
  • mkinitcpio-dropbear.
  • mkinitcpio-utils.

Paso 2

Insertar clave pública del cliente en el servidor.

sudo scp /etc/ssh/ssh_host_ecdsa_key.pub user@IP_server:/etc/dropbear/root_key

Paso 3

Modificar hooks de mkinitcpio.conf

sudo vim /etc/mkinitcpio.conf
HOOKS="base udev autodetect modconf block keymap lvm2 netconf dropbear encryptssh  filesystems keyboard fsck"

1

Dejar la línea HOOKS como aparece arriba. Este paso salió por prueba y error, por lo que si a alguien no le funciona por su configuración del sistema, es cuestión de modificar desde un chroot. y volver a regenerar el mkinitcpio.

Paso 4

Ejecutar mkinitcpio -p linux [especificar el kernel adecuado si es necesario].

Paso 5

Modificar grub para establecer la IP a mano (no tiene por qué ser necesario, en caso de que la reciba por DHCP).

Añadir en /etc/default/grub lo siguiente al final de la linea en la que aparece GRUB_CMDLINE_LINUX_DEFAULT: “ip=XX.XX.X.XX:::::eth0:none".

2

También puede establecerse por dhcp de esta forma:

3

Tan solo tener en cuenta la interfaz adecuada (eth0, eth1…). A partir de ahí se pueden autorizar los usuarios que se deseen añadiendo la clave pública en /etc/dropbear/root_key. Solo hay que tener en cuenta que se debe hacer el paso cuatro cada vez que se modifique el archivo de esta clave, o los usuarios no podrán acceder.

Paso 6

Conectar con el servidor e introducir la clave de desbloqueo de cifrado:

ssh root@XX.XXX.XXX.XX -i /etc/ssh/ssh_host_ecdsa_key (enviamos la clave privada no la pública, que acaba en .pub).

Entonces nos pedirá la contraseña de desbloqueo de cifrado del disco. La ponemos y la conexión se cerrará y se levantará el servidor. Con esto ya tenemos nuestro servidor a prueba de maleantes e indeseables.

Ni que decir tiene que si por alguna razón necesitáramos volver a arrancar el servidor, podríamos hacerlo desde cualquier equipo con acceso al servidor.

Comments

  1. Interesante articulo, pero me gustaria plantear la siguiente hipotesis, si tenemos el disco cifrado es porque no queremos que alguien que tenga acceso físico al equipo pueda acceder a la información. ¿Podrias ser que quien hubiera accedido fisicamente al equipo hubieran instalado un man-in-the-middle para obtener la clave cuando se la envias de manera remota?

  2. Hola Damia,

    entiendo que tu pregunta es, si podría alguien que se cuele en el CPD robar la clave haciendo un MitM entre el servidor y el acceso exterior; en ese caso en principio no podría puesto que la clave que se envía esta cifrada dado que se accede por SSH. Por ello no debería ser posible.

    Espero que esto responda a tu pregunta.

  3. Hola Javier:
    Lo que me refiero es que alguien que accediera al disco, dispondría de los certificados y podría preparar un mitm para cuando enviaras la clave.

  4. Creo que, aunque es improbable, sí que puede darse el caso. Es decir, al final lo que se está haciendo es crear una imagen inicial de Linux en /boot; esa imagen no está cifrada y es la encargada de levantar un “sistema básico” que prepara al “sistema final”; en caso contrario el sistema no podría arrancar. En dicha imagen están las claves publicas de los clientes y las claves del dropbear que está a la escucha.

    En el caso de que alguien entrara físicamente y montara el sistema “clonado” y además consiguiera que yo tuviera que rearrancar ese sistema, pues podría hacerse con la clave.

    En el caso de que se extrajeran las claves de la imagen.img también se podría sniffar el tráfico para conseguir dicha clave.

    Por tanto, aunque creo que no es fácil, si creo que es posible realizarse. De todas formas me parece interesante, así que intentaré probarlo :D.