Linux: LUKS y múltiples discos duros

Tengo un sistema Debian Linux (amd64) instalado en un dispositivo encriptado del sistema RAID-1 (LVM en LUKS) y tendré un RAID-6 de> = 4 discos donde pondré mis datos (LUKS y tal vez LVM).

Creo que la idea básica es desbloquear la partición cifrada del sistema (en el arranque local o mediante ssh) y almacenar un archivo de claves en / etc / crypttab para la partición cifrada RAID-6. ¿Eso plantea un riesgo de seguridad? Quiero decir ... es bastante inútil si alguien puede ingresar a mi sistema de manera local / remota y creo que hay muchos servicios que se ejecutan en servidores que son vulnerables al "rooting" (por ejemplo, SSH). ¿Existe una alternativa (además de desbloquear la partición a través de SSH que puede ser un problema ya que, por ejemplo, las operaciones de copia de seguridad comienzan incluso antes de que se monte la partición de datos).

En otra máquina, usaré varios discos con LUKS + greyhole (sin RAID-6) para copias de seguridad y será un verdadero dolor desbloquear 10 discos ingresando 10 veces la misma contraseña ...

— usuario51166
fuente

Si alguien puede entrar en su sistema y convertirse en root, no necesita obtener la clave de su partición encriptada. No tiene sentido protegerlo de la raíz (y no es posible sin un hardware especial como un TPM o ejecutándose en una máquina virtual).

— Gilles 'SO- deja de ser malvado'

Disculpe ? Incluso si soy root, tengo que dar el archivo de clave / frase de contraseña para desbloquear particiones LUKS. Supongo que quiere decir que si alguien se convierte en root, tiene acceso completo a mis datos cifrados. Desafortunadamente, eso es simplemente cierto porque una vez que se monta la partición encriptada, no hay diferencia si está encriptada o no. ¿Cuál sería la ventaja de una máquina virtual entonces? Entonces, ¿por qué debería ayudar la encriptación? ¿Es la única solución para negar el acceso a la raíz a través de SSH y servicios similares? Pero aún así, si un hacker ingresa al sistema como un usuario normal, generalmente tiene acceso de lectura a cada archivo, ¿no es así?

— user51166

Exactamente, si alguien es root en su sistema, tiene acceso a todo. Una VM puede significar que tienen acceso a todo en la VM. El único uso del cifrado es si alguien roba su hardware.

— Gilles 'SO- deja de ser malvado'

Sí, bueno ... en ese caso podemos argumentar que la única forma casi segura de almacenar datos es en una computadora encriptada desconectada de toda la red e integrada en el edificio. Entonces, cualquiera podría venir con un teclado y robar sus datos sin reiniciar su sistema. También podría aislar mis sistemas de Internet, ya que será un servidor de respaldo, por lo tanto, el acceso LAN es todo lo que necesita. Por otra parte ... si se usa una VPN o una de las máquinas LAN se infecta, la máquina de respaldo también quedaría expuesta. ¿Qué harías para resolver estos problemas?

— user51166

ver también unix.stackexchange.com/a/110102/50601

— Tim Abell

Respuestas:

Puede usar /lib/cryptsetup/scripts/decrypt_deriveden su crypttabpara usar automáticamente la clave de un disco para otro.

El decrypt_derived script es parte del paquete cryptsetup de Debian.

Pequeño ejemplo para agregar la clave de sda6crypt a sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

Como hoy en día es muy difícil eliminar realmente un archivo, asegúrese de que / path / to / mykeyfile esté en una unidad cifrada ( sda6cryptsería, en mi ejemplo, una buena solución).

En general, puede agregar una capa de seguridad adicional utilizando el cifrado del sistema de archivos de espacio de usuario, por ejemplo, a través de encfs.

— jofel
fuente

De esa manera no debería necesitar almacenar el archivo de claves en el disco. Eso estaría bien. Sin embargo, ¿cree que vale la pena (es decir, almacenar el archivo de claves en el dispositivo raíz encriptado es "lo suficientemente seguro")? Estoy pidiendo una opinión ya que tengo algunas dudas. Gracias por la sugerencia.

— user51166

La solución decrypt_derivedtiene la única ventaja de que no hay un archivo de clave. Si alguien puede obtener acceso de root, normalmente se pierde de todos modos. Leer un archivo clave podría ser un poco más fácil para un intruso que ejecutar un script. Para obtener más seguridad, puede fortalecer su sistema utilizando, por ejemplo, TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity, ... pero esto requiere esfuerzos adicionales. Y la pregunta de si vale la pena es más importante. No olvide tener una copia de seguridad de la clave o una clave separada para el caso de que la unidad se bloquee de donde se deriva / almacena la clave.

— jofel

Planeaba usar grsecurity o software similar también (no al principio, pero cuando tenga tiempo lo aseguraré). Estoy pensando en usar solo contraseñas y no archivos de clave si es posible. Bueno, la contraseña se almacenará en la RAM, así que supongo que también puedes discutir sobre eso.

— user51166

No hay una buena manera de eliminar un archivo de clave en ninguna parte, salvo sobrescribir todo el sistema de archivos (y tal vez ni siquiera si el disco falla). Un sistema de archivos de diario no empeora las cosas notablemente.

— Gilles 'SO- deja de ser malvado'

@Gilles Como no soy un experto en la eliminación segura de archivos, edité mi respuesta. Recomiendo ahora almacenar el archivo de claves en la unidad cifrada.

— jofel

Basado en la respuesta de jofels, aquí está el mismo ejemplo pero sin tener que almacenar la clave en un archivo. La clave se pasa en una tubería con nombre, que no almacena nada en el disco.

Puede usar /lib/cryptsetup/scripts/decrypt_derivedsu crypttab para usar automáticamente la clave de un disco para otro. El decrypt_derivedscript es parte del paquete cryptsetup de Debian.

Ejemplo modificado para agregar la clave de sda6crypt a sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

La keyscriptopción solo funciona si crypttabes procesada por las herramientas de configuración de cifrado originales de Debian, la reimplementación systemd actualmente no es compatible. Si su sistema usa systemd (que es la mayoría de los sistemas), necesita la initramfsopción de forzar el procesamiento en el initrd por las herramientas cryptsetup, antes de que se inicie systemd.

— JanKanis
fuente