Cifrar discos y particiones en LINUX, LVM, VG, LV

[Burt]

Buenas, en uno de mis PC quiero cifrar o encriptar el disco SSD entero. Es un PC que uso a modo de pruebas para trastear o por si el principal queda inutilizado por alguna razón, así que si pierdo algo no sería una drama.

El tema es que en este segundo PC ya tengo un par de distros de Linux (KDE neon y Kubuntu) y un Windows 11 instalado y para hacer una prueba me gustaría cifrar el disco desde Linux, PERO sin que se me formateara el disco, ¿esto es posible?. Con Veracrypt desde Windows creo que es posible, pero las herramientas que he encontrado en Linux, por ejemplo, LUKS, si no estoy equivocado, formatean todo el disco y quisiera evitarlo.

Un saludo.

[UltimaNeurona]

Buenas, en uno de mis PC quiero cifrar o encriptar el disco SSD entero. Es un PC que uso a modo de pruebas para trastear o por si el principal queda inutilizado por alguna razón, así que si pierdo algo no sería una drama.

El tema es que en este segundo PC ya tengo un par de distros de Linux (KDE neon y Kubuntu) y un Windows 11 instalado y para hacer una prueba me gustaría cifrar el disco desde Linux, PERO sin que se me formateara el disco, ¿esto es posible?. Con Veracrypt desde Windows creo que es posible, pero las herramientas que he encontrado en Linux, por ejemplo, LUKS, si no estoy equivocado, formatean todo el disco y quisiera evitarlo.

Un saludo.

Hola Burt.

Si bien lo que comentas pudiera ser posible, es un escenario bastante complejo que implica demasiadas variables por lo que es bastante posible que algo salga mal y pierdas todos los datos.

Habria que tener en cuenta la configuracion establecida en el arranque del sistema, particionado, bootloader, etc.

+ Equipo con sistema Bios/Legacy/CSM: El MBR se almacena en los primeros 512 bytes del disco y luego vendrian las particiones (sin tener en cuenta configuraciones exoticas en linux como el uso gpt en sistemas bios que requiere una particion extra de 1M tipo Bios boot).

Edit: Elimino de la linea anterior lo ultimo que decira "Ubuntu por ejemplo hace uso de esta caracteristica, utiliza gpt tanto en bios como en uefi". No recordaba bien, pero al menos en 20.04 como vemos en el proximo post en sistema bios el instalador crea el esquema mbr en el disco y no gpt.

El MBR contiene entre otras cosas la tabla de particiones y el cargador de arranque (como por ejemplo grub). Una vez que carga el bootloader, este, tiene diferentes entradas (en multi boot) que apuntan a una u otra particion para arrancar un sistema operativo.

Tendrias que hacer cada cosa por un lado.
Windows hace al menos dos particiones, la del sistema operativo y la del sistema. Solo encripta con bitlocker la del sistema operativo. Podrias probar a encriptar la particion de windows con bitlocker.
Posteriormente ajustar el grub para decirle que esta particion de windows ahora esta encriptada ya que desde linux, dm-crypt permite mapear unidades bitlocker para abrirlas, pero para dar formato mediante su herramienta cryptsetup usa LUKS (por defecto), plain, loopAES o Truecrypt.
cryptsetup permite encriptar una particion plana previa sin perder datos pero implica bastante pasos como:

* reducir el sistema de archivos para que entre la cabecera luks
* El cargador de arranque grub no soporta luks2, por lo que tendrias que encriptar con luks1 la particion raiz si /boot no es una particion independiente (es decir, que esta dentro de / ) o con luks2 la particion raiz / y con luks1 la particion para boot si esta fuera del raiz.
* extender de nuevo el sistema de archivos
* configurar el cargador de arranque para que detecte las particiones encriptadas donde esta el initramfs y las imagenes del kernel.
* reconstruir el initramfs y alguna cosa seguramente más que ahora no recuerdo.

+Equipo uefi: uso general de esquema gpt (si esta windows por el medio, siempre gpt). Requiere particion ESP en el disco que comparten todos los sistemas instalados y que no se puede encriptar, luego estarian el resto de particiones.
Este sistema la ventaja que tiene es que pulsando en el arranque f11 o f12 tendras las etiquetas de la particion ESP correspondientes a los sistemas instalados y te olvidas de batallar con grub.
Un esquema de este tipo podria ser:

* disco /dev/sda
particion ESP /dev/sda1 con Windows , neon, kubuntu
particion raiz /dev/sda2 (dentro estaria boot que tiene que leer el grub y por tanto solo podria ser luks1)
particion raiz /dev/sda3
...

Como ves tu situacion es demasiado compleja, habria que determinar tipo de arranque, saber como estan las particiones, tienes triple boot. Hacer todo esto es para problemas, estoy seguro.

Con un sistema ya inicializado lo mas comodo es cifrar a nivel de sistema de archivos, no de bloque. Con efs en windows o fscrypt en linux para ext4 podras hacerlo.
O si tienes espacio libre en el disco, hacer una nueva particion por ejemplo /dev/sdaX, cifrarla y montarla desde el SO.

En resumen, si bien es posible aplicar cifrado a nivel de discos con sistemas de archivos planos tanto en windows como en linux (opcion cryptsetup reencrypt), hacer todo esto sobre discos de sistema con cargadores de arranque se vuelve extremadamente sensible.

Es recomendable aplicar el cifrado completo a discos nuevos y posteriormente abrirlos en el sisma operativo o realizar el cifrado en el momento de la instalacion del sistema en linux para que todo lo que hemos visto anteriormente ( posibilidad de particion boot o no, configuracion grub, initramfs, kernel) quede listo sin tener que hacerlo manualmente.

Un saludo

[Burt]

Gracias @UltimaNeurona por tus minuciosas y documentadas explicaciones! Pues ya veo que el escenario que planteo es complejo.

Mi idea era hacer pruebas en el equipo secundario (también UEFI) para que cuando lo tuviera claro implantarlo en mi equipo principal (dual boot con KDE neon+ Windows 10 Pro), pero viendo el percal, no lo haré.

Más adelante, mi idea es adquirir un disco adicional para, en este equipo principal, tener dos instalaciones independientes, un disco para Linux y otro para Windows. Como dices, en Linux permite hacer la encriptación durante la instalación y así lo haría. En Windows, podría hacerlo via Bitlocker u otro programa. En fin, que esperaré a que me decida a tener dos discos y a reinstalar los S.O.

Una pregunta más. Si tengo instalado un S.O. de Linux, al iniciar el PC, ¿que aparecerá antes, la pantalla para desencriptar el disco o el GRUB? y una vez seleccionado el S.O. o las opciones de Revocery o lo que sea, posteriormente tendré que meter la contraseña para desencriptar?. Es decir, primero desencripto el disco y luego aparece el Grub o primero aparece la pantalla del Grub y luego meto la clave para desencriptar el disco?
Lo pregunto porque estos días he sabido que desde el Grub puede cambiarse la contraseña de usuario y de root sin conocer la original previamente. De hecho, yo mismo he hecho la prueba y la he cambiado sin problemas tecleando 'E' cuando aparece el GRUB y editando el arranque. Me parece una barbaridad, si alguien con conocimientos te roba el equipo o accede a éste físicamente, podría entrar en tu sistema sin problemas. Sé que al Grub puede ponérsele una contraseña, pero si el disco está encriptado previamente, es un paso que podría saltarme, el de ponerle contraseña al Grub

Un saludo.

[UltimaNeurona]

Denada compañero.

Escenario disco de sistema sin encriptar
Como el disco de sistema de cada equipo ya tiene hecho su particionado, sistemas operativos instalados y sus sistemas de archivos, lo mas aconsejable seria una de las siguientes opciones o incluso la combinacion de ambas:

1. Sin agregar una nueva unidad de almacenamiento: Cifrar a nivel del sistema de archivos. Por ejemplo se puede tener un directorio cifrado y meter dentro de este todos los datos importantes.

- Windows oferece de forma nativa encriptar archivos con efs y acceder a los mismos mediante certificado. Una vez que este certificado se instala en el sistema operativo windows, podremos acceder a los datos cifrados de la unidad.
La pega de esta opcion deriva de este certificado, y es que para poder leer el contenido cifrado necesitas tenerlo instalado en tu equipo asi como en cualquier otro que sea de confianza.

Por tanto, si el certificado esta instalado en un equipo windows C: y conjutamente tambien los datos cifrados residen aqui (por ejemplo en c:\users\usuario\crypt) y se llevan el disco entero con el certificado ya instalado, podrian arrancar en otro ordenador booteando directamente desde este disco y hacer bypass de la cuenta de usuario y tendrian acceso a todo.

Lo ideal con este metodo seria alojar los datos cifrados en una carpeta de un medio de almacenamiento externo como un pen o disco duro. El certificado reside en C: mientras que los datos estan en otra unidad.
No es mi preferido porque tienes que estar instalando tu certificado en otros equipos windows y una vez instalado para acceder a los datos no te pide password. Personalmente tampoco lo usaria porque si tenemos un medio externo, es mejor tratarlo como veremos en el punto 2, es decir como una unidad extra de almacenamiento cifrandola a nivel de bloque.

- En sistemas linux podemos usar fscrypt. Este metodo usa passphrase para acceder a los archivos cifrados. A mi me gusta mas porque cuando quieres abrir la carpeta encriptada te pide contraseña y no te fuerza a tener los datos en medio externo como hemos visto anteriormente.

2. Agregar una segunda unidad para almacenamiento en el equipo principal y convertirla en tu baul personal encriptandola a nivel de bloque.
Puedes agregar por ejemplo un segundo disco duro, cifrarlo completamente a nivel de dispositivo y copiar en el todos tus datos. Tanto bitlocker como dmcrypt-cryptsetup pediran contraseña para desbloquear esta unidad.

A modo de ejemplo podemos crear un archivo de 1GB, encriptarlo y tratarlo como un contenedor que podemos montar como unidad mas en el sistema:

# Crear un archivo de 1GB
root@:~# truncate -s1G test

# Encriptamos con cryptsetup
root@:~# cryptsetup luksFormat test
WARNING!
========
Sobrescribirá los datos en test de forma irrevocable.

Are you sure? (Type uppercase yes): YES
Introduzca una contraseña para test:
Verificar frase de paso:

# Abrimos el contenedor con cryptsetup para que dm-crypt (el mapeador de dispositivos encriptados) cree el dispositivo
root@:~# cryptsetup open test contenedor
Introduzca una contraseña para test:

# Comprobamos que dm-crypt ha creado el dispositivo
root@:~# ls -lah /dev/mapper/contenedor
/dev/mapper/contender -> ../dm-3

# Lo formateamos por ejemplo en ext4 para poder montarlo y alojar archivos
root@:~# mkfs.ext4 /dev/mapper/contenedor

# lo montamos en un directorio
root@:~# mkdir /root/montaje
root@:~# mount /dev/mapper/contenedor /root/montaje/

# Comprobamos montaje
root@:~# lsblk
loop14 1G 0 loop
└─contenedor 1008M 0 crypt /root/montaje

root@:~# blkid | grep -i contenedor
/dev/mapper/contenedor: TYPE="ext4"

root@:~# mount | grep -i contenedor
/dev/mapper/contenedor on /root/montaje type ext4 (rw,relatime)

# Lo utilizamos por ejemplo para almacenar nuestra db de passw en con la generacion aleatoria del nucleo /dev/random
root@:~# for i in {1..10}; do < /dev/random tr -dc A-Za-z0-9 | head -c20 >> /root/montaje/pass.db | echo >> /root/montaje/pass.db | echo >> /root/montaje/pass.db | echo >> /root/montaje/pass.db; done

Esta linea en bash realiza secuencialmente lo siguiente: Crea un archivo en /root/montaje llamado pass.db . Vuelca a ese archivo 10 veces el comando tr pipeado con head. El comando tr cogera caracteres de la A-Z a-z y de 0-9 y head cogera el numero de caracteres, en este caso 20. Los echos son espacios. El resultado es un archivo pass.db con 10 lineas, y cada una de estas lineas contendra 20 caracteres aleatorios A-Za-z0-9

root@:~/montaje# cat /root/montaje/pass.db
9ZnQQeyqUlG7btS3Q4NU


O combinar ambos metodos: En el disco de sistema A que no esta encriptado instalamos el certificado y los datos los guardamos en el disco B que tiene cifrado de bloque. De esta forma tienes ambas cosas, al conectar el disco B lo tienes que abrir con la contraseña, y ademas, los archivos almacenados en el tambien requieren certificado.


Escenario disco de sistema encriptado:

Tras instalar windows podemos cifrar el disco de sistema con bitlocker.
Para facilitar las cosas, el comportamiento por defecto de bitlocker en equipos uefi que cuentan con tpm, es almacenar las claves en este chip. Debido a esto, al encender el ordenador el disco duro se desbloquea automaticamente y no te pide contraseña. Es decir, al encender llegaras hasta la pantalla de logueo como habitualmente sin notar nada.

Este comportamiento se puede cambiar en windows mediante politicas de grupo para que bitlocker no use solo tpm sino tpm+pin, tpm+key o tpm+key+pin. Lo ideal es requerir autenticacion adicional durante el arranque. Si roban el equipo y no pide pin, el ordenador encenderia hasta la pantalla de logueo. Auqnue aqui el bypass del usuario es mas complejo ya que tpm y secure boot se encarga de estas cosas, por ejemplo no dejandote arrancar desde un usb. Contramedidas de seguridad en bitlocker.

Pre-boot authentication with BitLocker is a policy setting that requires the use of either user input, such as a PIN, a startup key, or both to authenticate prior to making the contents of the system drive accessible. The Group Policy setting is Require additional authentication at startup and the corresponding setting in the BitLocker CSP is SystemDrivesRequireStartupAuthentication.


En cuanto a linux, aqui te respondo lo que preguntas. Si ciframos el disco al instalar:

Una pregunta más. Si tengo instalado un S.O. de Linux, al iniciar el PC, ¿que aparecerá antes, la pantalla para desencriptar el disco o el GRUB? y una vez seleccionado el S.O. o las opciones de Revocery o lo que sea, posteriormente tendré que meter la contraseña para desencriptar?. Es decir, primero desencripto el disco y luego aparece el Grub o primero aparece la pantalla del Grub y luego meto la clave para desencriptar el disco?
Lo pregunto porque estos días he sabido que desde el Grub puede cambiarse la contraseña de usuario y de root sin conocer la original previamente. De hecho, yo mismo he hecho la prueba y la he cambiado sin problemas tecleando 'E' cuando aparece el GRUB y editando el arranque. Me parece una barbaridad, si alguien con conocimientos te roba el equipo o accede a éste físicamente, podría entrar en tu sistema sin problemas. Sé que al Grub puede ponérsele una contraseña, pero si el disco está encriptado previamente, es un paso que podría saltarme, el de ponerle contraseña al Grub

Lo primero que aparece es el grub:

-Si el disco esta completamente encriptado, es decir, solo tenemos una particion encriptada en la que vive / (ademas de la esp pero esa no se encripta): Te pedira la password dos veces, una para que grub acceda a /boot en el estadio inicial para poder leer el directorio y otra vez cuando el initramfs tome el control de la particion /

-Si solo esta encriptado el sistema raiz y /boot es una particion a parte solo la pedira una vez cuando initramfs monte el sistema raiz.

Este comportamiento se puede automatizar para que pida la contraseña una sola vez y es lo que suelen hacer las distribuciones al instalaras o el instalador te pone /boot en una particion a parte sin encriptar.

Tambien es posible que no veas el grub. Por ejemplo tengo ubuntu 20.04 en un portatil: Instalacion de serie con disco encriptado. No se ve el menu del grub al arrancar, si quieres verlo hay que presionar ESC. Y las particione que tengo (bios):

root@:~# lsblk
sda
├─sda1 part /boot/efi
├─sda2 part
├─sda5 part /boot
└─sda6 part
└─sda6_crypt 253:0 0 147,8G 0 crypt

root@:~# fdisk -l /dev/sda
Tipo de etiqueta de disco: dos <-- MBR al ser sistema bios.

Dispositivo Inicio Comienzo Final Sectores Tamaño Id Tipo
/dev/sda1 * 2048 1050623 1048576 512M b W95 FAT32
/dev/sda2 1052670 312580095 311527426 148,6G 5 Extendida
/dev/sda5 1052672 2549759 1497088 731M 83 Linux
/dev/sda6 2551808 312580095 310028288 147,9G 83 Linux

Fijate que ubuntu aun siendo un sistema bios te crea la particion ESP y la monta /boot/efi. Esto esta muy bien pensado, te la hace de antemano por si cambias el tipo de arranque en la bios a uefi. De esta forma puedes arrancar el sistema con un live cd para instalar el grub efi en la particion esp /boot/efi y ya podrias arrancar en uefi y no reinstalar todo el sistema.

Tambien vemos que el instalador te hace una particion sda5 y monta ahi /boot. Esta particion no esta encriptada y por tanto, al arrancar solo me pide la password de desbloqueo una vez.
El resto del disco es una particion extendida sda6 y dentro una particion logica luks crypt

root@:~# blkid /dev/sda6
/dev/sda6: TYPE="crypto_LUKS"

Al estar el disco encriptado, cuando llegues al grub, si pulsas "e" o inicio avanzado para cargar el recovery tambien te pedira la contraseña de desbloqueo para poder montar la particion.

La shell del usuario root en el modo recuperacion no tiene password pero se la puedes poner. Una vez arranques en esta consola y obtengas la shell, teclea passwd y establece una. Prueba de nuevo y veras como te la pide.

Este modo esta pensado asi, sin password, un modo en el que tenemos acceso fisico al equipo y hemos olvidado el password de root. Normalmente no se hace fde (full disk encryption) sino que instalas el sistema de forma tradicional que ocupa unos pocos GB y luego ya tendras a parte una particion o disco encriptado montado por ejemplo en /datos o /backups y para montar esa particion o disco se necesita password.


Como te digo se soluciona poniendole password al usuario root y como bien dices encriptando el disco, poniendole al grub contraseña. O una combinacion de todo.

Un saludo!.

[Burt]

Menudo master...xD, hasta me sabe mal, gracias!. Tú te debes dedicar a esto profesionalmente o algo, porque tela...xD

He estado haciendo pruebas y voy a seguir haciéndolo.

Cosas curiosas; tanto Ubuntu como Kubuntu te permiten hacer una instalación cifrada, pero si quieres hacer la instalación manual, como yo la suelo hacer, no te hace la encriptación, la hace solo cuando dicha instalación se hace de manera automática. Yo suelo crear una partición para EFI, otra para Swap, para root y para home. No entiendo porque no lo permite su instalador. En cambio, KDE neon, que no dejar de ser un Ubuntu, su instalador te permite cifrar las particiones cuando las generas de manera manual. De esta manera, la particón EFI no la encripta, pero sí la de Swap, root y home, me parece la manera perfecta.

También he probado esto con Linuxmint. En este caso, cuando has acabado de crear las particiones manualmente y en la parte donde debes configurar el usuario y contraseña, te permite setear que cifre tu carpeta personal, es decir, home, pero solo esa, nI swap ni root. Curioso el caso de Linumint porque mientras en los otros sistemas, aún habiéndolos encriptado, si accedes a ellos desde un UsbLive, por ejemplo, puedes acceder a sus carpetas introduciendo la contraseña o passphrase, pero esto no puede hacerse para Linuxmint. Si intentas acceder a sus carpetas cifradas lo único que sale es un mensaje de error y te dice que si quieres mandarla a la Papelera. Por cierto, durante la instalación de Linuxmint, como digo, puedes cifrar tu carpeta de usuario, pero no sale la opción de ponerle passphrase a esa encriptación. Es por eso que quizás no puedes acceder a ella desde otros sistemas.

Como digo, no entiendo la razón por la que algunos sistemas no permiten la encriptación durante la instalación haciendo particiones manuales y solo permite el cifrado si es dejando que el propio instalador lo haga todo, pero bueno...

Ahora lo que haré es experimentar con sistemas ya instalados, pero cifrando solo las carpetas de usuarios o /home.

Un saludo.

P.D. me centro básicamente en Linux porque ya desde hace más de un año es casi el único sistema que uso.

[UltimaNeurona]

Denada Burt!


En ubuntu 22.04 al menos si que se puede. Estando en uefi una vez lanzas el instalador:

- Como indicas, en el modo guiado avanzado no hay problema. Nos deja usar lvm/zfs con o sin encriptacion pero no podemos customizar particiones.
Si se elige lvm con ecnriptacion lo que hace es crear un particion ESP, una particion /boot sin cifrar, una particion swap encriptada (como volumen logico lvm) y una particion raiz encriptada (como volumen logico lvm).


- En el modo manual: He lanzado una vm para probar con 27GB de disco y al llegar al particionado:

· Te presenta el disco, creas tabla de particiones y aparece el espacio libre del mismo.

· En este espacio libre creamos particion primaria de 1024MB al principio disco -> Use as EFI -> la crea como sda1 . Esta no te deja cambiar el punto de montaje ni aparece la opcion de formatear.

· Al crear la anterior particion aparece Gap de 1MB de espacio libre al principio del disco supongo por si en un futuro necesitamos en ese espacio meter una particion tipo bios boot/grub para arranque BIOS.

· Creamos particion primaria de 1024MB principio disco -> Use as ext4 -> montar en /boot -> sda2 -> Aqui montamos boot en una particion a parte sin encriptar. Supongo que el instalador utilice el encriptado luks2 y si dejamos boot dentro de / o la encriptamos con luks2 no arrancara el grub, por lo tanto la dejamos en una particion a parte sin encriptar.

· Creamos particion primaria de 20000MB al principio del disco -> phisycal encryption -> rellenar pass -> aparece como sda3 -> dispositivo /dev/mapper/sda3_crypt -> click encima -> change -> ext4 -> formatear > mount /

· Creamos particion primaria 5000MB principio del disco -> phisycal encryption -> rellenar pass -> aparece como sda4 -> dispositivo > /dev/mapper/sda4_crypt -> click encima -> change -> ext4 -> formatear -> mount /home


El layout por tanto es: sda1 ( esp ) | sda2 ( /boot ) | sda3 -> /device/mapper/sda3_crypt ( / ) | sda4 -> /device/mapper/sda4_crypt ( /home ).
Hasta aqui bien, le doy a siguiente, instalar, y:




Para llegar a este punto, donde dice que va a formatear sda3_crypt (montada en /), sda4_crypt (montada en /home) y partition sda2 (montada en /boot) he tenido que volver atras un par de veces porque no me salian esas 3 a formatear. A veces me decia que iba a formatear la esp y sda3_crypt, pero faltaba sda2 y sda4_crypt, etc.

Como digo, he tenido que volver atras y seleccionar de nuevo los device mappers y boot, darle a change -> deseleccionar formateo -> aceptar -> volver a darle a change y elegir formatear otra vez. De esta al darle a siguiente han aparecido estas 3 de la captura. Aunque nos sigue faltando la ESP, pero esta como va por defecto en fat32 y normalmente en /boot/efi montada no me preocupo mucho, ademas, cuando la creas al principio tampoco permite marcarla para formatear.

Le he dado siguiente asi tal cual la foto.

Cuando ha acabado de instalar, antes de reiniciar -> Ctrl+Alt+F2 para tener consola virtual. Login con usuario ubuntu (no lleva pass) y en la shell sudo -i para obtener shell de root. Un blkid muestra que todo esta ok y formateado, incluido la ESP.
Vuelvo al instalador grafico con Alt+F1 y Reinicio:

Meto pass ->

En estas imagenes anteriores podemos relacionar lo que comentabamos en el otro post. Al estar /boot sin cifrar, solo hay que meter la password 1 vez para desbloquear la unidad.


Ya en el escritorio vemos que todo en orden: Todas las particiones montadas.




Como ves es un poco tedioso si eligimos la forma manual para tener varias particiones como /root /home /boot etc, pero si que deja hacerlo.

Al final cada distribucion tiene su metodo e instalador. Unos instaladores dejan hacer unas cosas, otros permiten otras, es la segmentacion de tener tanta distribucion.
Otra opcion seria utilizar la version server que es mas flexible. Esta te deja configurar raid, lvm, encriptacion, hacer diferentes particiones y posteriormente instalar un desktop al gusto.

Curioso lo de mint, si, que solo deje cifrar home y que no pueda abrirse desde un live. Habria que investigar que tipo de encriptacion utiliza, seguro que desde la shell se podria hacer algo.

A mi personalmente me gusta ubuntu server para servicios y en lo personal void linux (raices españolas) que es increible. Tiene una instalacion base (plana, cifrada, lvm, etc, lo que necesites) lanzando algunos comandos de consola y te deja un entorno que consume 100mb y construyes a partir de ahi, ademas de su excelente gestor de paquetes xbps y el administrador runit.

Un saludo y larga vida a linux!

[Burt]

Espectacular!. @UltimaNeurona

He podido reproducir exactamente lo que has hecho en una VM. El tema es que no había visto esa opción para encriptar durante las particiones manuales en Ubuntu, queda algo escondido, en KDE neon es más visible.
Pues estoy muy contento, ahora ya sé como encriptar durante una instalación limpia y sé como encriptar al menos /home una vez hecha dicha instalación. Todo probado con éxito.

Por cierto, yo también he tenido que darle unas cuantas veces para atrás para que pillara sda3_crypt, sda4_crypt y partition sda2, no va fino eso.

Pues lo dicho, muchas gracias, me has aclarado muchas cosas y conceptos.

Estoy un poco preocupado con la seguridad porque el municipio donde vivo, que siempre ha sido bastante tranquilo, están habiendo útlimamente bastantes robos o intentos en domicilios y si se me llevaran el equipo y sacaran los discos duros podrían ver lo que hay dentro. No es que haya nada muy comprometido, pero tema de cuentas corrientes y tal prefiero que no rule por el mundo.

El siguiente paso será cómo protejo unos discos del NAS desde los cuales hago backup hacia un HDD que tengo en el PC. Tendré que encriptar todo eso y ver como se comporta el backup que tengo programado, que igual al dejar el disco de destino también encriptado el NAS no puede acceder a él.

Un saludo.

P.D.: para encriptar /home una vez hecha la instalación he utilizado este tutorial https://www.linuxuprising.com/2018/0...in-ubuntu.html

[UltimaNeurona]

Me alegro Burt, un placer intercambiar opiniones.
Es importante que estemos al dia con este tipo de cosas en estos tiempos, como comentabamos en el hilo de la gestion de contraseñas en el subforo de seguridad. Hemos visto como en unos pocos pasos se puede tener el sistema seguro.

En el caso particular de ubuntu hay que batallar algo con el instalador aunque seguramente podriamos tratar el disco previamente en el entorno live para personalizarlo a nuestro gusto (crear y formatear las particiones). Posteriormente, cuando lancemos la instalacion y lleguemos al punto del particionado, ya estarian todas las particiones listas a falta de asignar el punto de montaje. Lo probare en una vm a ver que tal.

Te iba a preguntar por el metodo que habias utilizado para encriptar a nivel de sistema de archivos pero veo que ya lo has agregado en tu post. Solo un apunte, ese tutorial utiliza eCryptfs.

eCryptfs utiliza un sistema de archivos apilado que es menos eficiente, metodos de cifrado mas antiguos , requiere privilegios de administrador y lo mas importante es que ya no se desarrolla activamente. Echale un ojo a fscrypt que te ponia en el otro post y pruebalo, ya que este utiliza el el cifrado nativo del kernel el cual esta incorporado en el sistema de archivos ext4.

Podriamos darle una vuelta a ver como tienes montado el sistema del NAS, si es comercial o casero, el sistema que utiliza a ve rsi le sacamos punta.

Un saludo!

[Burt]

eCryptfs utiliza un sistema de archivos apilado que es menos eficiente, metodos de cifrado mas antiguos , requiere privilegios de administrador y lo mas importante es que ya no se desarrolla activamente. Echale un ojo a fscrypt que te ponia en el otro post y pruebalo, ya que este utiliza el el cifrado nativo del kernel el cual esta incorporado en el sistema de archivos ext4.

Podriamos darle una vuelta a ver como tienes montado el sistema del NAS, si es comercial o casero, el sistema que utiliza a ve rsi le sacamos punta.

Un saludo!

Vale, a ver si más adelante miro lo de Fscrypt, porque lo que he probado hasta ahora ha sido sobre mi PC de pruebas así que puedo hacerle lo que quiera sin riesgo y en VMs.

Lo que tengo montado en casa es lo siguiente:
Tengo un NAS Synology DS212j con dos HDD, uno de 3TB y otro de 1TB. Del HDD de 3TB hago un backup (incremental, creo que se llama, en los que solo se copian los datos que hayan cambiado) hacia un HDD de 3TB (dedicado exclusívamente a este menerster) que tengo en el PC. Como digo, solo refleja los cambios que he realizado en el NAS. Cuando descargo algo o tengo un documento que guardar, lo primero que hago es copiarlo al NAS, y luego ya tengo programado el backup hacia el PC. Quizás sería mejor hacerlo al revés, del PC hacia el NAS, pero de esta manera en el NAS lo tengo disponible en seguida para conectarme desde otro dispositivo en casa o fuera de mi red (tengo una cuenta DDNS).
Luego tengo otro backup programado del HDD de 3TB del NAS al otro disco de 1TB del mismo NAS, pero solo de unas carpetas determinadas para mi especialmente importantes, así tengo eso por triplicado, en dos discos del NAS y una tercera copia en el PC.

Ahora todavía lo tengo programado para hacer el backup con rsync copy del NAS a Windows (ahí tengo instalado DeltaCopy), con lo cual, como Windows hay muchos días que ni lo abro, ese backup no se realiza, pero bueno, tengo pensado formatear el HDD de backups del PC para realizar dichos backups a través de Linux con el daemon Rsync. Para ello probé este tutorial Utilizando rsync como un servicio y me funcionó perfectamente .

Como exponía anteriormente, si encripto el disco de 3TB del PC, no estoy seguro de que el NAS pueda acceder a él para realizar las copias. También quiero cifrar los dos discos del NAS, así que tendré que ir trasladando toda la información de un sitio a otro y volver a hacer copias para no perder nada.

Un saludo.

[UltimaNeurona]

Hola de nuevo Burt.

Estos dias he aprovechado para intentar replicar lo que hemos venido hablando sobre un pc secundario que tenia pendiente de actualizar. Este equipo lo utilizo a modo de nas, servidor de aplicaciones y virtualizacion.

Tambien es un buen debate el de los nas. Si bien los nas comerciales actuales son estupendos productos y las marcas cuentan con un abanico amplisimo de modelos donde elegir y que cubren todas las necesidades, siempre me hago una serie de preguntas de lo que ocurriria con los datos ante un supuesto fallo que afecte principalmente a la placa base.

¿Que ocurre si se rompe la placa base del nas o alguno de los componentes de la misma?, ¿Que ocurre si el hardware del equipo malfunciona a este nivel?, en este escenario ¿que hago con los discos y los preciados datos que contienen?.

Seguramente tocaria acudir al SAT de la marca para que hagan el diagnostico del aparato, y en funcion de este, realizar una posible reparacion si es viable o directamente tener que adquirir un nuevo nas igual o equivalente al que teniamos. Esto al fin y al cabo se arregla con dinero, pero a nosotros nos preocupan nuestros datos y vienen mas preguntas:

¿Cuanto tiempo voy a tener el nas inmovilizado en el sat?. Si la reparacion no es viable y el modelo de nas que tengo esta descatalogado ¿puedo adquirir otro modelo mas moderno que seguramente requiera de una version actual del sistema operativo del nas, pinchar los discos del anterior nas que contienen el sistema operativo viejo y echara a funcionar? ¿arrancara? , si esto no es viable ¿que hago con los discos que tengo y con todos los datos?.

Pues o tenemos backup del nas en otros medios facilmente accesibles, lo cual es muy recomendable por si aparecen estos problemas o empieza el periplo de como acceder a esos datos en los discos del nas.

Todo esto es una suposicion, pero no es raro que ocurra. En este sentido no me moveria de synology, ya que por su forma logica de tratar los discos permite, si cumplimos ciertas premisas, mover los discos a un pc con linux, montarlos y cruzar los dedos para poder acceder al volumen de datos sin perder nada: How can I use a PC to recover data when my Synology NAS malfunctions?

Por estas cosas prefiero un pc clonico con un SO al gusto para dar este tipo de servicios a nivel del hogar (aunque hay muy buenas soluciones open source tipo truenas o unraid).
Por un lado, un equipo generalista nos permite la flexibilidad de que si se rompe el hardware es sencillo de sustituir en poco tiempo, y por otro, podemos elegir las capas logicas para distribuir los discos fisicos. Si tenemos los discos con una simple capa dm-crypt (luks) y encima de esta el sistema de archivos, podemos mover los discos de un equipo a otro sin ningun problema y abrirlos con cualquier distribucion, ya sea en live cd o en otro equipo con linux instalado.

Volviendo al tema, cuando monte este equipo hace unos años elegi un esquema de distribucion fisica y logica de los discos algo pesado y complejo:

- Contaba con dos discos duros mecanicos, el disco /dev/sda y el disco /dev/sdb. Ambos discos fisicos conformaban un dispositivo en espejo md-raid 1 (multidevice) que te proporciona tolerancia al fallo, duplicacion en tiempo real de los datos y uptime del equipo.
Si se rompe uno de los discos, el equipo sigue funcionando (raid en modo degradado), se sustituye el disco problematico y entonces el raid comenzara la reconstruccion del dispositivo de md. Todo esto en teoria, porque para que raid funcione se necesita de discos adecuados con ciertas caracteristicas.
- Encima del raid1 tenia lvm para la gestion de los volumenes logicos (similar a hacer particiones pero mucho mas flexible).
- Encima de los volumenes logicos tenia los sistemas de archivos.



Esto mismo pero en vez de tener un raid5, lo tenia en raid1 con dos discos.

El principal problema de este esquema es la gestion y administracion del raid. Cada poco tiempo hay que comprobar consistencia del espejo, tener mucho cuidado con los apagones durante las escrituras o fenomeno de write hole (sai obligatorio). Ante el desastre no sabes muy bien como van a responder los discos que quedan sanos por adecuados que sean, si van a soportar la reconstruccion del dispositivo md, etc. Esto hacia que tuviera que tener otro backup del nas si o si.
De aqui la famosa frase de "raid no es un backup" sino un sistema que nos proporciona proteccion frente al fallo de un disco.

Por todo ello llevaba tiempo queriendo instalar en este equipo un disco nuevo independiente para el SO + otro disco independiente para backups. De esta forma me he deshecho del raid, ya que no necesito duplicidad en tiempo real ni uptime 100% para el sistema.
Simplemente este equipo tiene que estar operativo cuando haga falta volcar los backups o para utilizar diferentes aplicaciones via docker, virtualizacion, etc. Tambien de esta forma me ahorro el backup "obligatorio" del raid por si al romperse un disco del mismo este quedara degradado sin poder reconstruirse.
De esta manera, este equipo con un disco independiente del so + disco independiente para backups ahora es ya es un backup más del resto de equipos de la casa, sin raid por el medio y sus posibles dolores de cabeza.

He aprovechado y lo he actualizado un poco. Le he puesto un disco M.2 nvme de 500GB + 8GB de ram. Como so ubuntu 22.04 desktop en vez de la version servidor. Por aquello de tener el escritorio listo por si hiciera falta.
En vez de utilizar al instalador, he probado lo de hacerlo todo manualmente ya que nos da mayor flexibilidad en cuanto al particionado.

1 - BIOS del sistema configurada en modo UEFI.

2 - Por tanto, arrancamos con el live-usb de ubuntu en modo uefi.

3 - Cuando sale la pantalla de bienvenida elegimos "Try Ubuntu".

4 - Abrimos la terminal y ejecutamos sudo -i para obtener shell de root.

5 - Un lsblk o fdisk -l nos muestra el nuevo disco nvme. Lo llamaremos a modo de ejemplo /dev/nvme

6 - Continuando en la terminal, utilizaremos la aplicacion gdisk para la gestion del particionado gpt del disco:

gdisk /dev/nvme y desde dentro de la aplicacion (tiene un menu en texto muy intuitivo) he creado 3 particiones:
nvme1 - 1G - tipo EF00 EFI System Partition - Esta particion se utilizara para albergar la particion ESP necesaria para el arranque uefi y para el grub.
nvme2 - 2G - tipo 8300 Linux - Esta particion se utilizara para albergar /boot donde residiran las imagenes del nucleo e initramfs necesarias para grub. La dejare sin encriptar, pero se puede cifrar con luks1 que es compatible con grub.
nvme3 - Resto - tipo 8309 LUKS - Esta particion ocupa todo el resto del espacio libre. Se utilizara para crear en ella el dispositivo DM-Crypt con cryptsetup. Posteriormente sobre el dispositivo DM creado, aplicaremos LVM y sobre este, crearemos los volumenes logicos que necesitemos para los sistemas de archivos raiz, home, etc.

7 - Formateamos la particion /dev/nvme1 en fat32, formato de archivos necesario para la ESP: mkfs.vfat -F 32 /dev/nvme1
La formateamos previamente para no tener problemas con el instalador. Esta particion es unica en un disco de sistema uefi. Para el instalador, al estar ya creada y formateada, no te la toca y te la respeta tal cual.

8 - Encriptamos la particion /dev/nvme3 para crear el dispositivo dm-crypt y establecemos la contraseña: cryptsetup luksFormat /dev/nvme3

9 - Abrimos el dispositivo dm-crypt recien creado para que sea reconocido por el mapeador de dispositivos dm en /dev/mapper : cryptsetup open /dev/nvme3 luks (aqui le damos el nombre que queramos, yo lo he llamado luks).
Con esto, el dispositivo creado y abierto estara localizado en /dev/mapper/luks

10 - Como comentabamos, sobre el dispositivo DM creado, aplicaremos una capa logica de gestion de volumenes, en este caso LVM (logical volume manager). LVM ofrece un flexibilidad y administracion muy buena.
Ahora mismo tenemos una particion nvme3, que tiene dentro un dispositivo dm que ocupa toda la particion, unos 400 y pico de GBs. Con lvm podemos redistribuir como queramos este espacio, creando diferentes volumenes logicos (LV) a nuestro antojo, aumentandolos o reduciendolos de tamaño, permite crear instantaneas para revertir el sistema y muchas mas opciones interesantes.
Con esto evitamos tener una particion root o home de X GB y que mañana se nos quede pequeña. Tendriamos que lidiar con alineamientos, tener espacio libre en el disco para extender la particion, resizes y otros problemas que pueden probocar desastres varios.

Como hemos dicho, primero aplicaremos lvm sobre el dispositivo dm /dev/mapper/luks. En LVM se distinguen 3 capas:

- PV: Es el dispositivo fisico que utilizaremos para lvm, es decir /dev/mapper/luks y se le llama PV (physical volume). Para crearlo: pvcreate /dev/mapper/luks
- VG: Este volumen fisico anterior albergara el grupo lvm y se le llama VG (volume group). Creamos el grupo dentro del PV: vgcreate sysvg /dev/mapper/luks (sysvg es el nomgre del grupo).
- LV: Finalmente dentro de este grupo VG creamos los volumenes logicos LV (logical volume) al gusto donde albergaremos los sistema de archivos : Creare solo un LV para el sistema de archivos raiz y posteriormente desde dentro del sistema otro para swap.
+ lvcreate -L 100G -n rootlv sysvg -> Con este comando se crea un volumen logico (lvcreate) llamado rootlv (opcion -n) con un tamaño de 100GB (opcion -L) dentro del grupo sysvg.

El resto del espacio queda libre dentro del VG sysvg para ir creando posteriormente los lv´s que necesitemos o agrandar el lv rootlv creado previamente.
Los lv creados van a /dev/mapper/sysvg-rootlv o /dev/sysvg/rootlv Se puede utilizar cualquiera de las dos ubicaciones.

Encima de este lv creariamos el sistema de archivos, por ejemplo ext4 con mkfs.ext4 /dev/mapper/sysvg-rootlv y ya lo podriamos montar donde quisieramos y utilizarlo. En este caso no crearemos el sistema de archivos puesto que le mostraremos el lv sin formatear al instalador para que el lo formatee. (sino te dice que ya existe un sistema de archivos previo y que lo va a sobreescribir).

Por tanto y en resumen:
Disco fisico.
Particion para ESP (Efi system partition).
Particion para boot.
Particion para Dispositivo DM-crypt luks -> PV -> VG -> LV´s -> Sistema de archivos.



El asunto de crear manualmente el lvm, como bien pensaras es innecesario, puesto que el instalador ya ofrece la opcion de "instalar en lvm con encriptacion". El tema es que el instalador te crea un lv unico que ocupa todo el espacio del vg, es decir un lv de 400GB y no te deja ni un solo MB libre para poder hacer otros lv´s o snapshots (para hacer instantaneas tiene que haber espacio libre en el vg), por tanto, posteriormente a la instalacion si queremos crear otros lvs o hacer instantaneas habria que reducir primero el lv que te crea el instalador para tener espacio libre.

LVM tiene muchisimas mas bondades, agrandamiento de vg´s sumando discos, transferir PVs de un disco a otro para hace replicas, etc, etc. Una lectura que me gusto mucho: Un pingüino en mi servidor, LVM.

11 - Podemos salir de la consola con exit y lanzar el instalador.

12 - En la pantalla del particionado:
/dev/nvme1 la montamos como EFI System Partition.
/dev/nvme2 la montamos como ext4 en /boot y formatear.
/dev/mapper/sysvg-rootlv lo montamos en / y formatear.

13 - Instalamos.

14 - Cuando acabe la instalacion, no reiniciamos, hacemos clic en continuar probando.
Si reiniciamos en este estadio el equipo no arrancara puesto que al instalador le hemos dicho que el raiz va a /dev/mapper/sysvg-rootlv y para el es un dispositivo mas con un sistema de archivos al uso, no sabe que por debajo esta el dispositivo encriptado puesto que no hemos usado la opcion phisycal encryption que comentabamos en post pasados, ya que esta es para crear el dispositivo encriptado y ya lo hemos creado con cryptsetup luksFormat previamente.

15 - Abrimos la consola y sudo -i

16 - Haremos un chroot para montar la instalacion recien hecha y actuar sobre ella, de esta forma informaremos al sistema del dispositivo encriptado para que lo monte en el arranque.
+ Montamos el sistema raiz: mount /dev/mapper/sysvg-rootlv /target
+ Montamos la estructura chroot: for DIR in proc sys dev /etc/resolv.conf; do mount --rbind /$DIR /target/$DIR; done
+ Entramos al chroot: chroot /target
+ Ahora estamos dentro del sistema de archivoz raiz que contiene la instalacion recien hecha. Montamos el resto de los dispositivos con: mount -a

+ Obtenemos el uuid de la particion encriptada con: blkid, la que diga UUID="xxxxxx-xxxx-....." TYPE="crypto_LUKS"
+ Creamos /etc/crypttab para indicar los dispositivos de bloque encriptados del sistema (es como /etc/fstab pero para este tipo de dispositivos) que queremos montar en el boot y agregamos el uuid anterior:
luks UUID="xxxxxx-xxxx-....." none luks
+ Si hemos encriptado la particion nvme2 que contiene /boot con luks1, agregamos en /etc/default/grub GRUB_ENABLE_CRYPTODISK=y

+ Si no vamos a utilizar hibernacion editamos /etc/initramfs-tools/initramfs.conf y agregamos RESUME=none
+ Actualizamos el initramfs con update-initramfs -u -k all
+ Actualizamos el grub con update-grub
+ Salimos del chroot con ctrl+d o exit
+ Desmontamos todo: umount -R /target
+ poweroff y quitamos el usb.
+ Arrancar de nuevo

Y todo queda listo (reutilizo la pa imagen del post anterior, ahora diria please unlock disk luks):



La swap la cree posteriormente con:
lvcreate -L 4G -n swaplv sysvg
mkswap /dev/mapper/sysvg-swaplv
edit /etc/fstab y agregar /dev/mapper/sysvg-swaplv none swap rw,noatime,discard 0 0
update-initramfs -u -k all

La cosa queda tal que: lsblk

nvme0n1 465,8G disk
├─nvme0n1p1 1G part /boot/efi
├─nvme0n1p2 2G part /boot
└─nvme0n1p3 462,8G part
... └─luks 462,7G crypt
..... ├─sysvg-rootlv 100G lvm /
..... │
..... └─sysvg-swaplv 4G lvm [SWAP]


df -h -x tmpfs

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/sysvg-rootlv 98G 21G 73G 23% /
/dev/nvme0n1p2 2,0G 286M 1,6G 16% /boot
/dev/nvme0n1p1 1022M 6,1M 1016M 1% /boot/efi

Un saludo!!