Chiffrez votre disque

Les problèmes de sécurité augmentant, chiffrer ses disques devient une norme et une nécessité.

Nous allons voir dans ce tutoriel comment chiffrer des disques.

11 commentaires

Article lu fois.

L'auteur

Chrtophe

L'article

Publié le 8 janvier 2023

Version PDF Version hors-ligne

ePub, Azw et Mobi

1. Introduction▲

Les problèmes de sécurité augmentant, chiffrer ses disques devient une norme et une nécessité. Windows chiffre maintenant par défaut les systèmes connectés à un compte Active Directory ou la dernière version de Windows en cas de présence d’un TPM et du Secure Boot.

La tendance ira probablement vers un chiffrement automatique par défaut.

1-1. Cadre des tests▲

Les tests ont été effectués avec des machines virtuelles VirtualBox. Le Live-cd Linux utilisé pour les essais est Ubuntu 18,04.

Les tests KVM ont été effectués depuis une VM PROXMOX.

Nous utiliserons le terme de « BIOS » en lieu et place d’« UEFI » : son successeur, celui-ci étant entré dans le langage courant.

Le mot « volume » qui sera utilisé par la suite désigne une zone de stockage munie d’un système de fichiers. Il s’agit en général d’une partition d’un disque, mais peut être par exemple un partage réseau (on parlera plutôt dans ce cas de volume réseau). Vous pouvez considérer un volume comme un disque logique.

2. Windows▲

2-1. BitLocker▲

BitLocker est le système de chiffrement natif de Microsoft, disponible dans les versions Windows professionnelles. Les versions familiales peuvent ouvrir un volume chiffré avec BitLocker (tant que vous avez la clé de déchiffrement), mais ne peuvent pas chiffrer un volume.

Les versions familiales (10/11) permettent le « chiffrement des périphériques » (un BitLocker lite) sous réserve d’avoir un TPM et l’UEFI. La fonction sera disponible dans les paramètres→Mise à jour et sécurité→chiffrement de périphérique. Si vous ne voyez pas la fonctionnalité, cela signifie que votre machine n’a pas les prérequis.

Les volumes chiffrés par ce biais apparaîtront comme chiffrés avec BitLocker

2-1-1. activation de BitLocker▲

Pour activer BitLocker, il suffit de cliquer avec le bouton de droite sur le volume concerné

Si vous ne voyez pas la fonction, c’est que votre système n’intègre pas BitLocker.

Il vous sera demandé où sauvegarder la clé de récupération :

Cette clé ne vous sera pas demandée à chaque démarrage, celle-ci étant stockée dans le TPM, mais vous sera nécessaire en cas de montage du disque sur une autre machine ou en cas de changement de carte mère.

Il est donc important de la garder précieusement et à plusieurs endroits sous peine de risque de perte d’accès aux données.

Vous pourrez réobtenir la clé en cliquant sur le volume chiffré avec le bouton droit de la souris->gérer BitLocker→sauvegarder la clé.

Une fois la clé imprimée ou enregistrée dans un fichier, le bouton « Suivant » s’activera.

Il vous sera ensuite demandé si vous souhaitez chiffrer tout le disque ou uniquement l’espace occupé.

La différence étant que seul l’espace actuellement occupé sera chiffré lors de l’activation du chiffrement, si vous optez pour le chiffrement uniquement de l’espace occupé. Une fois BitLocker activé, les données sont chiffrées à la volée.

Pour un système neuf, le choix de ne chiffrer que l’espace utilisé est pertinent. Dans le cadre du chiffrement d’un poste déjà utilisé, il vaudra donc mieux chiffrer tout le lecteur.

Il vous sera ensuite demandé de choisir le mode de chiffrement. Comme indiqué, le mode de chiffrement ayant changé à partir de Windows 10 version 1511, le nouveau format est incompatible avec l’ancien mode.

Puis il vous est demandé si vous voulez exécuter la vérification du système BitLocker, ce que je recommanderais.

Après quoi une notification indique que le chiffrement commencera après redémarrage.

Vous pourrez ensuite visualiser l’avancée du chiffrement en cliquant sur l’icône bitlocker :

La fenêtre de progression s’affichera :

En cas de redémarrage, le processus continuera où il en était. Vous pouvez donc sans problème redémarrer ou éteindre la machine si le chiffrement n’est pas terminé.

Une fois celui-ci terminé, en ouvrant l’explorateur de fichiers, vous pourrez voir que le lecteur est chiffré, un cadenas apparaissant au niveau de l’icône du disque :

Au niveau BitLocker, chaque volume est autonome. Chaque volume devra être chiffré.

Les volumes amovibles sont chiffrés avec la fonctionnalité « BitLocker To Go ». Le processus sera identique, il vous sera demandé si vous souhaitez chiffrer le volume avec un mot de passe ou avec une carte à puce.

2-1-2. Désactiver le chiffrement▲

Si vous souhaitez désactiver le chiffrement, il faudra cliquer avec le bouton de droite sur l’icône du disque et sélectionner gérer BitLocker :

Ce qui ouvrira la fenêtre suivante :

2-1-3. boot sur média Windows▲

Dans le cadre de mes tests, le boot utilisant un ISO Windows 10 avec ouverture d’un terminal (shift-F10) fait apparaître le volume verrouillé. Si vous tapez la commande dir pour afficher le contenu du volume, un message d’erreur apparaît indiquant le verrouillage du volume :

La commande manage-bde -status c : affichera l’état du disque :

Pour déverrouiller le volume, il faut saisir la commande suivante :

Sélectionnez

manage-bde -unlock c : -recoverypassword <clé>

ou « clé » correspond à la clé imprimée lors du chiffrement du volume. Une fois la clé entrée, le volume est accessible :

Si la clé est stockée sur une clé USB, la commande sera :

Sélectionnez

manage-bde -unlock c : -recoverykey "chemin_acces_au_fichier"

Rappel : le déverrouillage du volume comme montré ci-dessus ne sera nécessaire qu’en cas de changement de carte mère ou de montage du disque dans une autre machine (pas d’accès au TPM d’origine).

2-1-4. boot sous Linux ubuntu 18.04▲

Dans gparted, la partition apparaît bien au format BitLocker :

Pour accéder à cette partition, nous allons utiliser le paquet dislocker

Sélectionnez

apt install dislocker

Une fois dislocker installé, il faudra lancer la commande de déchiffrement (partition BitLocker dans sda3 dans l’exemple) :

Sélectionnez

mkdir /media/dislocker
mkdir /media/dislocker-mount
dislocker /dev/sda3 -p<clé> /media/bitlocker

Cette commande va présenter un fichier dislocker-file qu’il va falloir monter en loopback :

Sélectionnez

mount -o loop /media/dislocker-file /media/dislocker-mount

2-1-5. BitLocker sans TPM▲

Vous pourrez monter un volume externe BitLocker si vous avez le mot de passe et la clé de sécurité.

Pour le disque du système. Il est possible également d’utiliser BitLocker sous Windows 10, les versions antérieures n’ont pas été testées.

Sous Windows 11, la question ne se pose pas, le TPM étant un prérequis pour installer celui-ci.

Par contre, par défaut, vous aurez le message d’erreur suivant :

Pour pouvoir utiliser BitLocker, il vous faudra aller dans la gestion des stratégies de groupe (gpedit) et activer « Configuration ordinateur → Modèles d'administration → Composants Windows → Chiffrement de lecteur BitLocker → Lecteurs de système d'exploitation → Exiger une authentification supplémentaire au démarrage » :

2-2. Veracrypt▲

Veracrypt est un logiciel libre fork de Truecrypt. Celui-ci permet de créer des volumes chiffrés dans des fichiers (des conteneurs) et de créer des volumes chiffrés et éventuellement cachés. Il permet également de chiffrer un disque complet, aspect que nous allons traiter. Veracrypt n’utilise pas TPM.

2-2-1. chiffrement▲

Une fois le logiciel installé et démarré, vous aurez l’écran suivant :

Celui-ci vous proposant par défaut de sélectionner un fichier de volume crypté pour l’affecter à une lettre ou de créer un volume.

Pour accéder à la fonctionnalité nous intéressant (le chiffrement complet du disque), il va falloir aller dans le menu système pour sélectionner « chiffrer la partition/le disque système » :

Vous obtiendrez la fenêtre suivante :

Nous utiliserons le mode normal de chiffrement.

Il vous sera ensuite demandé si vous souhaitez chiffrer l’intégralité du disque ou uniquement la partition système Windows :

Puis il vous sera demandé s’il y a un seul ou plusieurs systèmes. Dans notre cas de figure, la présence d’un seul système a été testée.

Enfin ; il faut choisir les options de chiffrement :

Vous aurez le choix entre les algorithmes suivants :

AES
Serpent
Twofish
Camelia

Si vous n’êtes pas en mesure de choisir l’algorithme , sélectionnez AES, le plus connu.

Le mot de passe vous sera ensuite demandé :

Pour la saisie du mot de passe, Veracrypt passe en clavier anglais pour compatibilité avec le gestionnaire d’amorce en anglais

Il vous faudra, sur l’écran suivant, faire des mouvements avec la souris de façon à générer des valeurs aléatoires. Pour générer suffisamment de valeurs aléatoires, les mouvements devront être effectués tant que la barre de progression ne devient pas verte.

Tant que la barre de progression ne devient pas verte, la valeur aléatoire ne sera pas considérée comme sécurisée.

En cliquant sur la case « Afficher le nombre aléatoire », la valeur sera affichée, mais connaître cette valeur n’a pas vraiment d’intérêt.

Vous aurez ensuite l’écran de notification des clés :

L’étape suivante sera la génération d’un disque de secours. Celui-ci sera important pour pouvoir déchiffer le disque en cas de crash système :

La génération de l’ISO est quasi instantanée, celui-ci faisant 1,7 Mo.

Il vous sera ensuite demandé de choisir le mode de nettoyage.

Sur le même principe que pour l’effacement sécurisé des données, vous pourrez appliquer plusieurs passes pour empêcher la récupération de données non chiffrées (vous pourrez faire 1, 3, 7 ou 35 passes).

Un test vous sera ensuite proposé. Celui-ci va installer le gestionnaire d’amorce Veracrypt et vérifier que votre mot de passe est valide avant de chiffrer les données. Un reboot sera nécessaire.

Au reboot, vous aurez l’écran suivant :

Une fois le mot de passe entré, vous aurez l’écran suivant :

À la réouverture de la session, vous pourrez déclencher le chiffrement :

Chiffrement en cours :

Vous serez notifié à la fin du cryptage :

2-2-2. Veracrypt rescue disk▲

En cas de boot sur l’ISO Veracrypt Rescue disk, vous aurez l’écran suivant :

Des options supplémentaires seront proposées en appuyant sur la touche F8 :

le déchiffrement de la partition ;
la restauration du chargeur d’amorce (boot loader) ;
la restauration de la clé ;
la restauration du boot loader d’origine.

2-2-3. Utilisation depuis live-cd linux▲

Depuis Linux, la partition sera vue comme une partition inconnue :

Pour télécharger Veracrypt, il vous faudra suivre le lien suivant: : https://www.veracrypt.fr/en/Downloads.html.

En mode graphique, il vous faudra charger le fichier .deb correspondant à votre distribution Linux.

Pour notre cas Ubuntu 18.04, le dépôt universe doit être activé dans le fichier /etc/apt/sources.list.

L’installation se fera en double-cliquant sur le fichier .deb :

Une fois l’installation effectuée, l’écran sera le même qu’avec la version Windows :

Les seules différences étant les emplacements (les connecteurs). Sous Windows apparaissent les lettres de volumes (A-Z), sous Linux il s’agit de numéros.

Pour monter votre volume, vous sélectionnez l’emplacement 1, puis cliquez sur « périphérique » :

Vous aurez alors l’écran suivant qui vous permettra de sélectionner le volume à monter :

Une fois le nom de volume affiché, il vous restera à cliquer sur « monter » :

vous aurez ensuite la demande le mot de passe :

Il vous faudra cliquer sur l’icône « Options » et cocher la case : « Mount partition using system encryption » sous peine d’avoir un message d’erreur :

Comme déjà précisé, le mot de passe doit être saisi en clavier anglais (qwerty), celui-ci étant créé de cette façon pour raison de compatibilité avec le gestionnaire d’amorce.

Comme vous pouvez le voir ci-dessous, le volume est monté dans /media/veracrypt1.

Le montage peut être fait en ligne de commande avec la commande veracrypt une fois les paquets installés.

Exemple :

Sélectionnez

veracrypt --text --mount devsdX /mnt --password le_mot_de_passe --protect-hidden no --slot 1 --verbose

Avec :

--text : pour indiquer de ne pas utiliser l’interface graphique ;
--protect-hidden no : le volume n’est pas un volume caché ;
--slot 1 : position dans les emplacements de volume.

3. Linux▲

3-1. luks▲

LUKS, pour Linux Unified Key Setup, est un système de chiffrement inclus dans le noyau. Nous le piloterons avec cryptsetup.

3-1-1. Chiffrement d’un volume (offline)▲

La première étape va consister à réduire la taille de la partition afin d’y libérer 32 Mo pour l’outil de conversion vers LUKS.

Vous ne pourrez pas effectuer cette procédure sur un système en cours d’utilisation. Les manipulations seront donc effectuées après démarrage sur un live-cd. Le système sera de ce fait immobilisé le temps de la procédure.

Il faut commencer par vérifier le système de fichiers, étape prérequise pour que resize2fs, la commande permettant de redimensionner une partition, accepte de modifier celui-ci. Dans notre cas de figure, la partition contenant le système est sda2.

Sélectionnez

e2fsck -f /dev/sda2
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: 20195/448800 files (0.2% non-contiguous), 255147/1792000 blocks

Il va vous falloir calculer le nouveau nombre de blocs de la partition afin de le passer à la commande resize2fs.

Tout d’abord le nombre de blocs à libérer :

Pour obtenir la taille d’un bloc dans la partition :

Sélectionnez

dumpe2fs /dev/sda2 | grep "Block size"
dumpe2fs 1.44.1 (24-Mar-2018)
Block size:               4096

il faudra donc libérer 32x1024x1024 = 33 554 432 / 4096 = 8192 blocs

Nous avons le nombre de blocs dans le retour de la commande e2fsck : 1 792 000, ceci représentant une taille de partition de 7 Go (dans ma VM)

la nouvelle taille afin de libérer les 32 Mo sera donc de :

1 792 000 – 8192 = 1 783 808

Sélectionnez

~# resize2fs /dev/sda2 1783808
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/sda2 to 1783808 (4k) blocks.
The filesystem on /dev/sda2 is now 1783808 (4k) blocks long.

Vous utiliserez ensuite un produit nommé luksipc permettant de chiffrer un volume non monté à la volée.

En cas d’interruption de la commande, le volume sera partiellement chiffré. Vous pourrez reprendre le processus avec l’option --resume. Sans sauvegarde fiable avant intervention, vous prenez un très gros risque.

Installation de luksipc :

Sélectionnez

apt install lukspic

Il faut utiliser ensuite la commande pour chiffrer la partition :

Sélectionnez

luksipc -d /dev/sda2
WARNING! luksipc will perform the following actions:
   => Normal LUKSification of plain device /dev/sda2
   -> luksFormat will be performed on /dev/sda2

Please confirm you have completed the checklist:
    [1] You have resized the contained filesystem(s) appropriately
    [2] You have unmounted any contained filesystem(s)
    [3] You will ensure secure storage of the keyfile that will be generated at /root/initial_keyfile.bin
    [4] Power conditions are satisfied (i.e. your laptop is not running off battery)
    [5] You have a backup of all important data on /dev/sda2

    /dev/sda2: 7000 MiB = 6.8 GiB
    Chunk size: 10485760 bytes = 10.0 MiB
    Keyfile: /root/initial_keyfile.bin
    LUKS format parameters: None given

Are all these conditions satisfied, then answer uppercase yes: YES

Il vous faudra à ce niveau valider l’opération en tapant « YES » en majuscules.

Sélectionnez

[I]: Created raw device alias: /dev/sda2 -> /dev/mapper/alias_luksipc_raw_f380a6df
[I]: Size of reading device /dev/sda2 is 7340032000 bytes (7000 MiB + 0 bytes)
[I]: Backing up physical disk /dev/sda2 header to backup file header_backup.img
[I]: Performing luksFormat of /dev/sda2
[I]: Performing luksOpen of /dev/sda2 (opening as mapper name luksipc_e6a97476)
[I]: Size of luksOpened writing device is 7337934848 bytes (6998 MiB + 0 bytes)
[I]: Write disk smaller than read disk by 2097152 bytes (2048 kiB + 0 bytes, occupied by LUKS header)
[I]: Starting copying of data, read offset 10485760, write offset 0
[I]:  0:00:   8.6%       600 MiB / 6998 MiB   119.4 MiB/s   Left:    6398 MiB  0:00 h:m
[I]:  0:00:  16.6%      1160 MiB / 6998 MiB   115.1 MiB/s   Left:    5838 MiB  0:00 h:m
[I]:  0:00:  24.3%      1700 MiB / 6998 MiB   112.5 MiB/s   Left:    5298 MiB  0:00 h:m
[I]:  0:00:  31.7%      2220 MiB / 6998 MiB   110.0 MiB/s   Left:    4778 MiB  0:00 h:m
[I]:  0:00:  39.9%      2790 MiB / 6998 MiB   110.5 MiB/s   Left:    4208 MiB  0:00 h:m
[I]:  0:00:  47.3%      3310 MiB / 6998 MiB   109.0 MiB/s   Left:    3688 MiB  0:00 h:m
[I]:  0:00:  54.4%      3810 MiB / 6998 MiB   107.7 MiB/s   Left:    3188 MiB  0:00 h:m
[I]:  0:00:  60.6%      4240 MiB / 6998 MiB   104.9 MiB/s   Left:    2758 MiB  0:00 h:m
[I]:  0:00:  66.0%      4620 MiB / 6998 MiB   101.5 MiB/s   Left:    2378 MiB  0:00 h:m
[I]:  0:00:  73.3%      5130 MiB / 6998 MiB   101.3 MiB/s   Left:    1868 MiB  0:00 h:m
[I]:  0:00:  80.2%      5610 MiB / 6998 MiB   100.7 MiB/s   Left:    1388 MiB  0:00 h:m
[I]:  0:01:  87.0%      6090 MiB / 6998 MiB   100.2 MiB/s   Left:     908 MiB  0:00 h:m
[I]:  0:01:  94.2%      6590 MiB / 6998 MiB   100.0 MiB/s   Left:     408 MiB  0:00 h:m
[I]: Disk copy completed successfully.
[I]: Synchronizing disk...
[I]: Synchronizing of disk finished.

À ce stade, la partition est chiffrée et il vous faudra le fichier /root/initial_keyfile.bin pour la déchiffrer. Ce fichier est directement créé par luksipc. La perte de celui-ci empêchera le déchiffrement.

Une partition chiffrée avec LUKS peut contenir 8 clés.

Vous allez en générer une à partir de ce fichier de façon à pouvoir déchiffrer le volume avec une passphrase. Il faut passer en paramètre le fichier de clé automatiquement généré lors de l’étape précédente :

Sélectionnez

cryptsetup luksAddKey /dev/sda2 --key-file=/root/initial_keyfile.bin
Enter new passphrase for key slot:
Verify passphrase:

Vous pouvez voir les deux clés enregistrées avec la commande luksdump :

Sélectionnez

cryptsetup luksDump /dev/sda2
LUKS header information for /dev/sda2

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        256
MK digest:      f4 a8 b7 9f 93 de 49 0c 58 c2 18 7b 19 71 72 c9 89 00 cd 7c
MK salt:        f9 b6 46 c2 f7 d9 71 08 1f 21 79 07 01 db 8a 3f
                ef 17 34 91 9d 4b 65 9e cb 0b 52 3f 24 b7 33 b6
MK iterations:  95255
UUID:           17c95356-7597-4d6f-a3c5-5a89359ad375

Key Slot 0: ENABLED
        Iterations:             1524092
        Salt:                   f0 b1 0f 0a ee 86 19 0f d7 c7 4b 11 84 0d e2 30
                                2b 5f 17 28 e7 ad 3e 4f 5c 18 83 5d 9f fa 52 0a
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             1438374
        Salt:                   e3 70 bb 21 f3 cf 03 e6 8e 15 79 32 35 f1 91 61
                                76 d3 db 4a 56 0c 41 09 8e d7 24 7a a8 d3 cd 5e
        Key material offset:    264
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Vous supprimez la première clé générée automatiquement, la passphrase vous sera demandée :

Sélectionnez

cryptsetup luksKillSlot /dev/sda2 0
Enter any remaining passphrase:

le 0 correspondant à la première entrée

un luksdump vous permettra de voir que le premier emplacement de clé est vide :

Sélectionnez

cryptsetup luksDump /dev/sda2
LUKS header information for /dev/sda2

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        256
MK digest:      f4 a8 b7 9f 93 de 49 0c 58 c2 18 7b 19 71 72 c9 89 00 cd 7c
MK salt:        f9 b6 46 c2 f7 d9 71 08 1f 21 79 07 01 db 8a 3f
                ef 17 34 91 9d 4b 65 9e cb 0b 52 3f 24 b7 33 b6
MK iterations:  95255
UUID:           17c95356-7597-4d6f-a3c5-5a89359ad375

Key Slot 0: DISABLED
Key Slot 1: ENABLED
        Iterations:             1438374
        Salt:                   e3 70 bb 21 f3 cf 03 e6 8e 15 79 32 35 f1 91 61
                                76 d3 db 4a 56 0c 41 09 8e d7 24 7a a8 d3 cd 5e
        Key material offset:    264
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

À ce stade, vous n’avez plus besoin du fichier initial keyfile.bin.

Vous allez maintenant ouvrir le conteneur LUKS :

Sélectionnez

cryptsetup luksOpen /dev/sda2 rootfs
Enter passphrase for /dev/sda2:

Le device sera visible dans le dossier /dev/mapper :

Sélectionnez

ls /dev/mapper/ -l
total 0
crw------- 1 root root 10, 236 Oct 23 07:53 control
lrwxrwxrwx 1 root root       7 Oct 23 08:24 rootfs -> ../dm-0

Vous commencez par réagrandir la partition.

Sans indication de taille, la partition sera agrandie au maximum possible :

Sélectionnez

resize2fs /dev/mapper/rootfs
resize2fs 1.44.1 (24-Mar-2018)
Resizing the filesystem on /dev/mapper/rootfs to 1791488 (4k) blocks.
The filesystem on /dev/mapper/rootfs is now 1791488 (4k) blocks long.

Il faut à ce stade intervenir sur la pseudo partition LUKS, pas directement sur la partition sda2.

Vous pouvez ensuite monter la partition :

Sélectionnez

mount /dev/mapper/rootfs /mnt

Puis entrer dans le système avec un chroot :

Sélectionnez

cd /mnt
mount --bind /proc proc
mount --bind /sys sys
mount --bind /dev dev
chroot .

Vous modifiez le fichier /etc/default/grub pour y ajouter le support des volumes chiffrés :

Sélectionnez

GRUB_ENABLE_CRYPTODISK=y

de façon à ne pas avoir à saisir les UUID, j’ai utilisé les commandes suivantes :

Sélectionnez

blkid | grep /dev/sda2 >> /etc/default/grub 
blkid | grep /dev/mapper >> /etc/default/grub

ce qui donnera en fin de fichier :

Sélectionnez

/dev/sda2: UUID="597de1b8-8fa3-4811-88f6-2ebb4b66ea7b" TYPE="crypto_LUKS" PARTU$
/dev/mapper/rootfs: UUID="a039418f-a67a-4f1b-8ded-74f0863ee33b" TYPE="ext4"

que vous modifierez de la façon suivante :

Sélectionnez

cryptdevice=UUID=597de1b8-8fa3-4811-88f6-2ebb4b66ea7b
root=UUID=a039418f-a67a-4f1b-8ded-74f0863ee33b

et enfin :

Sélectionnez

cryptdevice=UUID=597de1b8-8fa3-4811-88f6-2ebb4b66ea7b root=UUID=a039418f-a67a-4f1b-8ded-74f0863ee33b

puis :

Sélectionnez

GRUB_CMDLINE_LINUX="cryptdevice=UUID=597de1b8-8fa3-4811-88f6-2ebb4b66ea7b root=UUID=a039418f-a67a-4f1b-8ded-74f0863ee33b"

Vous mettrez ensuite à jour grub :

Sélectionnez

mount /dev/sda1 /boot/efi
update-grub
grub-install

Rappel : les UUID sont uniques, vous aurez donc d’autres valeurs dans votre cas de figure.

il va ensuite vous falloir modifier les fichiers /etc/crypttab et /etc/fstab.

Pour le fichier /etc/crypttab, il faut ajouter l’entrée suivante :

Sélectionnez

 <nom volume>        UUID=<id_patition_luks>       none       luks

vous appliquerez la même méthode que précédemment :

Sélectionnez

blkid | grep /dev/sda2 >> /etc/crypttab

ce qui donnera dans mon cas l’entrée suivante :

Sélectionnez

/dev/sda2: UUID="597de1b8-8fa3-4811-88f6-2ebb4b66ea7b" TYPE="crypto_LUKS" PARTU$

que je remplace par :

Sélectionnez

rootfs UUID=597de1b8-8fa3-4811-88f6-2ebb4b66ea7b    none    luks

modification de /etc/fstab :

Sélectionnez

blkid | grep /dev/mapper >> /etc/fstab

le fichier /etc/fstab contiendra :

Sélectionnez

# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/sda2       /       ext4    defaults,rw     0       1
/dev/sda3       none    swap    sw      0       1

/dev/mapper/rootfs: UUID="a039418f-a67a-4f1b-8ded-74f0863ee33b" TYPE="ext4"

Je modifie la dernière ligne par :

Sélectionnez

UUID=a039418f-a67a-4f1b-8ded-74f0863ee33b    /    ext4    defaults,rw    0    1

qui remplacera la ligne contenant /dev/sda2.

Fichier final :

Sélectionnez

# UNCONFIGURED FSTAB FOR BASE SYSTEM
/dev/mapper/rootfs: UUID="a039418f-a67a-4f1b-8ded-74f0863ee33b" TYPE="ext4"
/dev/sda3       none    swap    sw      0       1

Il faut ensuite mettre à jour l’initramfs :

Sélectionnez

update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.19.0-21-amd64

Puis quitter le chroot :

Sélectionnez

exit

Et démonter le volume crypté :

Sélectionnez

umount dev sys proc
cd /
umount /mnt
cryptsetup closeLuks rootfs

Au reboot, il vous sera demandé la passphrase du volume :

Ne soyez pas surpris, vous aurez l’impression que rien ne se passe pendant quelques secondes après la saisie du mot de passe.

Vous aurez ensuite l’écran GRUB normal :

Le mot de passe vous sera redemandé à la sortie de l’initramfs :

Pour pallier ceci, vous allez enregistrer un fichier de clé qui sera utilisé par le système.

Sélectionnez

mkdir /etc/luks
dd if=/dev/urandom of=/etc/luks/boot_os.keyfile bs=4096 count=1
1+0 enregistrements lus
1+0 enregistrements écrits
4096 octets (4,1 kB, 4,0 KiB) copiés, 0,000503747 s, 8,1 MB/s

Vous mettez ensuite le fichier en lecture seule uniquement pour root :

Sélectionnez

chmod 0400 /etc/luks
chmod 0400 /etc/luks/boot_os.keyfile

Et vous enregistrez la clé dans le volume :

Sélectionnez

cryptsetup luksAddKey /dev/sda2 /etc/luks/boot_os.keyfile
Entrez une phrase secrète existante :

Puis vous modifiez le fichier /etc/crypttab pour y ajouter le fichier de clé, en remplaçant la ligne :

Sélectionnez

rootfs UUID=597de1b8-8fa3-4811-88f6-2ebb4b66ea7b        none    luks

par :

Sélectionnez

rootfs UUID=597de1b8-8fa3-4811-88f6-2ebb4b66ea7b        /etc/luks/boot_os.keyfile    luks,discard

Vous modifiez la valeur de KEYFILE_PATTERN dans le le fichier /etc/cryptsetup-initramfs/conf-hook :

Sélectionnez

echo "KEYFILE_PATTERN=/etc/luks/*.keyfile" >> /etc/cryptsetup-initramfs/conf-hook

ensuite le UMASK dans le fichier initramfs.conf :

Sélectionnez

echo "UMASK=0077" >> /etc/initramfs-tools/initramfs.conf

et enfin les modifications dans l’initramfs :

Sélectionnez

update-initramfs -u -k all

Après reboot, la passphrase ne vous sera demandée qu’au boot.

Modification du swap :

À ce stade, la partition swap est toujours en clair, vous allez également la chiffrer.

Pour commencer, commentez la ligne concernant le swap dans /etc/fstab (l’arrêt par swapoff ne suffisant pas), puis rebootez (non indispensable, mais par sécurité).

écrasez d’abord le contenu du swap (dans sda3) :

Sélectionnez

dd if=/dev/urandom of=/dev/sda3 status=progress
137781760 octets (138 MB, 131 MiB) copiés, 6 s, 23,0 MB/s

Créez ensuite le volume LUKS pour le swap :

Sélectionnez

cryptsetup luksFormat /dev/sda3

WARNING!
========
Cette action écrasera définitivement les données sur /dev/sda3.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète pour /dev/sda3 :
Vérifiez la phrase secrète :

Puis intégrez le fichier de signature :

Sélectionnez

cryptsetup luksAddKey /dev/sda3 /etc/luks/boot_os.keyfile
Entrez une phrase secrète existante :

J’ai utilisé la même clé que pour la partition /. Il aurait tout à fait été possible d’en créer une spécifique au swap.

Ouvrez le volume LUKS :

Sélectionnez

cryptsetup luksOpen /dev/sda3 swap
Saisissez la phrase secrète pour /dev/sda3 :

Créez le swap dans le volume LUKS :

Sélectionnez

mkswap /dev/mapper/swap
Setting up swapspace version 1, size = 974 MiB (1021308928 bytes)
no label, UUID=ad3de9a9-b445-47e1-937a-23d3c64ed880

Récupérez l’UUID de la partition /dev/sda3 et recopiez-le dans /etc/crypttab

le fichier contiendra :

Sélectionnez

# <target name> <source device>         <key file>      <options>
rootfs UUID=597de1b8-8fa3-4811-88f6-2ebb4b66ea7b        /etc/luks/boot_os.keyfile    luks,discard
swap UUID=731c20ee-f2de-4be4-904c-4628a12d223b    /etc/luks/boot_os.keyfile    luks,discard

Appliquez le même principe pour fstab, ce qui donnera :

Sélectionnez

# UNCONFIGURED FSTAB FOR BASE SYSTEM
UUID=a039418f-a67a-4f1b-8ded-74f0863ee33b       /       ext4    defaults,rw     0       1
#/dev/sda3      none    swap    sw      0       1
UUID=f183a15e-9fc7-4476-8230-dee1341baefb    none    swap    sw    0    1

3-2. Veracrypt▲

La version Linux de Veracrypt ne permet pas le chiffrement de la partition système en cours contrairement à la version Windows, vous ne pourrez donc pas l’utiliser sans faire une installation de base. Il reste possible de l’utiliser pour créer des conteneurs montés dans des points de montage. Cet aspect n’a pas été étudié.

4. MacOS▲

MacOS est fourni avec un système de chiffrement nommé Filevault. Sur les anciennes versions, seules les données utilisateur étaient chiffrées dans une image dmg, ce n’est plus actuellement le cas.

FileVault fonctionne un peu comme BitLocker, avec une puce cryptographique avec fonctionnement semblable au TPM pour les machines les plus récentes.

Pour chiffrer votre disque avec filevault, il va vous falloir aller dans le menu pomme→préférences système :

Dans les préférences, allez dans l’onglet sécurité et confidentialité :

Onglet filevault, il faudra cliquer sur le cadenas :

Il vous sera alors demandé un nom d’utilisateur avec les droits administrateur ainsi que le mot de passe :

Vous pourrez ensuite cliquer sur « activer filevault » :

Vous pourrez alors soit utiliser votre compte icloud, soit une clé de sécurité qui vous sera communiquée pour déverrouiller le disque :

Une fois le choix effectué, le disque sera chiffré en tache de fond. Dès l’allumage de la machine, vous devrez saisir votre mot de passe.

En cas de multi-utilisateurs, seuls les comptes approuvés par un compte administrateur pourront démarrer la machine.

4-1. Veracrypt▲

Tout comme pour Linux, vous pouvez utiliser Veracrypt avec MacOS, sauf pour chiffrer le disque de démarrage.

L’utilitaire de disque permet de créer des images disque .dmg chiffrées ce qui enlève l’intérêt d’utiliser Veracrypt avec MacOS.

L’intérêt de Veracrypt reste pour l’utilisation alternative d’un volume externe chiffré entre environnement Apple et Windows/Linux.

5. Sauvegarde/restauration de volumes chiffrés▲

La sauvegarde à chaud, c’est-à-dire depuis le système d’exploitation en fonctionnement, sera transparente pour les logiciels de sauvegarde. Attention aux fichiers ou bases de données ouvertes que votre logiciel doit pouvoir gérer (certains produits nécessitent des modules complémentaires).

Pour faire une sauvegarde à froid, c’est-à-dire système d’exploitation non démarré ou disque monté sur un autre poste, la règle sera la même que pour la restauration : le média utilisé pour effectuer la sauvegarde devra intégrer le support du chiffrement utilisé et vous devrez avoir la clé de restauration pour déverrouiller le volume chiffré.

La sauvegarde se fera en clair, sauf si votre logiciel de sauvegarde permet son chiffrement ou si vous sauvegardez sur un volume chiffré.

Il existe des clés USB et disques durs intégrant un système de chiffrement matériel. Pour pouvoir monter le volume chiffré, vous aurez besoin dans ce cas du logiciel permettant le montage du volume, à moins d’avoir un équipement avec un clavier intégré pour la saisie d’un mot de passe ou ayant un capteur d’empreinte.

La restauration ne devrait pas être chiffrée, à votre charge de réactiver le chiffrement une fois celle-ci effectuée.

5-1. Test avec la sauvegarde Windows▲

Je vais présenter ici la restauration sur une autre machine d’une sauvegarde effectuée avec la sauvegarde d’images système Windows (accessible dans le panneau de configuration dans l’ historique des fichiers ou sauvegarde Windows 7)sur un volume BitLocker.

Au démarrage de Windows, il faudra sélectionner « réparer l’ordinateur » :

puis sélectionner « Dépannage »

puis « récupération système » :

Windows a détecté un volume BitLocker qu’il ne connaît pas. Il vous demandera de saisir la clé de récupération :

Une fois la clé entrée, la procédure continuera comme pour un volume non chiffré.

Pour Veracrypt, la sauvegarde Windows ne reconnaît pas un volume chiffré comme disque exploitable, il n’est donc pas possible d’effectuer une sauvegarde dessus.

Le principe sera le même avec un disque de récupération Windows.

5-2. Test avec Acronis Cyber Protect Home Office▲

J’ai effectué un test avec Acronis Cyber Protect Home Office, anciennement Acronis True image installé sur un poste.

Le logiciel permet de chiffrer la sauvegarde :

J’ai effectué un test en stockant la sauvegarde sur un volume chiffré avec BitLocker. Afin de pouvoir effectuer une restauration depuis le média d’Acronis, j’ai dû quitter le logiciel et monter le volume chiffré avec la commande manage-bde vue au chapitre 2.1.3boot sur média Windows, puis relancer le logiciel pour enfin effectuer la restauration.

Dans le cas d’un chiffrement avec Veracrypt, toujours depuis le média Acronis, j’aurais dû lancer la version portable stockée sur une clé USB, puis enfin lancer Acronis.

5-3. Test avec Macrium Reflect▲

Seul l’aspect création d’image disque a été vu ici, pas l’aspect création de clone que permet Macrium Reflect.

Ci-dessous la copie d’écran de la préparation d’une image de sauvegarde, stockée sur E:, volume chiffré par BitLocker.

Le logiciel avertit :

En cliquant sur « options avancées », il vous est possible d’accéder à l’option de chiffrement en entrant un mot de passe.

Cette option n’est cependant disponible qu’avec la version payante.

La génération d’un média bootable Macrium intègre les clés des volumes déverrouillés permettant son accès en mode restauration à froid. Cela ne vous affranchira pas de garder les clés ailleurs.

Pour générer ce support, il vous faudra aller dans le menu autre taches → disque de secours

6. smartphones/tablettes▲

Les applications tierces liées au chiffrage disponibles dans les stores respectifs sont des outils de cloud.

6-1. Android▲

Test effectué depuis une VM Virtualbox sous Android x86 Nougat.

Une fois le système installé, démarrer sur un livecd Ubuntu permet de voir que les données utilisateur telles que les fichiers téléchargés sont stockées dans /data/media/0.

En cas de plusieurs utilisateurs, un nouveau dossier sera créé dans le dossier média. La création d’un second utilisateur a dans le cadre de mon test créé un dossier nommé 10.

Sur un smartphone Android (ou une tablette), les données seraient accessibles en montant le téléphone en mode USB, en montant la carte flash pour la partie stockée sur la zone de stockage externe du téléphone ou en passant l’appareil en mode debug.

Pour chiffrer le disque, il faut aller dans les paramètres de l’appareil :

partie sécurité, localisation :

Puis chiffrement et identifiants :

et enfin chiffrer la tablette (ou le téléphone) :

6-2. Iphone▲

Les données sur les Iphones sont chiffrées directement par l’appareil.

7. Machines virtuelles▲

Dans le cadre d’utilisation de machines virtuelle, il est tout à fait possible de gérer le chiffrement au niveau de la VM directement.

Il ne faudra pas dans ce cas activer le chiffrement directement dans la VM, le double chiffrement entraînant dans ce cas des pertes de performances pouvant être significatives.

Cette opération s’effectuera à chaud ou à froid (c’est-à-dire VM arrêtée ou en cours de fonctionnement) selon les possibilités de l’hyperviseur.

7-1. VirtualBox▲

Pour cela, il vous faudra aller dans la configuration de la machine virtuelle concernée : icône stockage->onglet chiffrement de disque.

Il vous faudra cocher « activer le chiffrement de disque », puis entrer le mot de passe et sélectionner le « chiffre » de chiffrement.

Le chiffrement se déclenchera :

Lors du lancement de la VM, le mot de passe du disque vous sera demandé :

la clé de chiffrement est incluse dans le fichier de définition de la VM .vbox. Sans ce fichier, vous ne pourrez pas accéder au contenu des données. Pour copier la VM, prenez son dossier complet.

7-2. VMWare workstation▲

Seule la version payante VMWare Workstation Pro permet le chiffrement. Pour cela, il faudra aller dans les réglages de la VM, onglet options :

Le mot de passe vous sera ensuite demandé :

Chiffrement de l’image disque de la machine en cours :

Au prochain démarrage de VMWare, le mot de passe vous sera demandé :

L’image disque ainsi que le fichier de description de VM (fichier .vmx) seront chiffrés.

Il faudra également récupérer tout le dossier de la VM pour pouvoir accéder aux données chiffrées.

7-3. Hyper-V▲

Hyper-V fournit deux types de machines virtuelles, les machines de 1^re génération et celles de 2^e génération.

Les machines de 1^re génération sont plutôt dédiées aux anciens systèmes.

Les machines de 2^e génération apportent :

le support UEFI ;
le démarrage sécurisé (Secure Boot) ;
l’utilisation du format d’image disque VHDX au lieu de VHD, permettant de dépasser une taille de 2 To et apportant une meilleure sécurité.

Le chiffrement des machines virtuelles Hyper-V s’appuie sur BitLocker.

7-3-1. Machine de 1re génération▲

Sur les machines de 1^re génération, il vous faudra ajouter un lecteur de stockage, qui contiendra la clé de chiffrement :

7-3-2. Machine de 2e génération▲

Sur les machines de 2^e génération, le TPM de l’hôte sera utilisé pour la clé BitLocker. Ci-dessous l’écran de configuration de la sécurité sur une VM de seconde génération

7-3-3. Host Guardian Service (Windows Server)▲

Le host guardian service est un rôle sur Windows Server générant la sécurité des machines virtuelles. Il est prévu pour des clusters Hyper-V.

Les VM protégées par ce service se nommeront des « Shielded VM ». Ce service apporte plus que le simple chiffrement des disques virtuels et dépasse le cadre de ce tutoriel.

Plus d’informations sur Host Guardian Service.

7-4. KVM▲

KVM,l’hyperviseur intégré au noyau Linux, s’appuie sur les formats d’image disque de Qemu pour le stockage de données.

Le format natif de Qemu est le qcow2, mais il peut gérer du format raw, vmdk format 3 et 4 (de VMWare), et vdi format 1.1 (de VirtualBox), ainsi que le vhd (Hyper-V).

KVM est également capable de stocker ses données dans un volume LVM ou dans un pool ZFS, qui peuvent dans ces deux cas être cryptés.

Dans tous les cas de figure, il sera nécessaire d’avoir la même quantité d’espace que l’image source afin de pouvoir faire sa conversion et une fois celle-ci effective, supprimer l’image source non chiffrée.

Dans le cas d’un fichier qcow, la conversion devra être effectuée à froid, dans le cas d’utilisation de LVM, elle pourra être faite à chaud.

7-4-1. Fichier qcow2▲

Pour chiffrer un fichier qcow2, il va falloir en créer un nouveau de la même taille que celui d’origine. Comme déjà précisé, l’opération devra être effectuée à froid (c’est-à-dire VM éteinte).

Exemple avec un fichier qcow, analyse du fichier qcow2 concerné avec la commande qemu-img (disque vm-100-disk-0.qcow2):

Sélectionnez

qemu-img info vm-100-disk-0.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 32 GiB (34359738368 bytes)
disk size: 178 MiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false

Afin de le convertir vers un format chiffré, nous allons commencer par créer un fichier chiffré de la même taille :

Sélectionnez

qemu-img create --object secret,id=sec0,data=mot_de_passe -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 vm-100-disk-0-encrypted.qcow2 32G
Formatting 'vm-100-disk-0-encrypted.qcow2', fmt=qcow2 encrypt.format=luks encrypt.key-secret=sec0 cluster_size=65536 extended_l2=off compression_type=zlib size=34359738368 lazy_refcounts=off refcount_bits=16

Avec en options :

--object secret,id=sec0,data=mot_de_passe : place le mot de passe inclus dans data dans l’id sec0
-f : first image format, le format à utiliser (en cas de second argument nécessaire, pour une conversion par exemple -F indiquera le second format), qcow2 dans notre cas de figure
-o : indique une suite d’options
- encrypt.format=luks : indique l’utilisation du format LUKS pour le chiffrage
- encrypt.key-secret=sec0 : indique d’utiliser l’id sec0 comme clé (précédemment fournie)
- vm-100-disk-0-encrypted.qcow2 ; le nom du fichier destination
- 32G : l taille de l’image virtuelle (taille dynamique limitée à 32 go)

Nous allons ensuite recopier les données du fichier image source non crypté vers le fichier image crypté :

Sélectionnez

qemu-img convert --object secret,id=sec0,data=mot_de_passe --image-opts driver=qcow2,file.filename=vm-100-disk-0.qcow2 --target-image-opts driver=qcow2,encrypt.key-secret=sec0,file.filename=vm-100-disk-0-encrypted.qcow2 -n -p
    (100.00/100%)

Restera à modifier la commande de lancement de la machine virtuelle de façon à lui fournir le mot de passe en plus du fichier image disque.

7-4-2. Images disque dans volume logique LVM▲

Comme déjà évoqué, KVM peut créer des disques virtuels dans des volumes logiques LVM.

Principe de fonctionnement de LVM :

LVM va regrouper des volumes physiques PV dans des volume Group VG.

Depuis ces Volume GROUP, on pourra créer des volumes logiques :

Image non disponible

Dans le cas de figure qui sera étudié, nous serons dans le cas suivant :

Image non disponible

la VM de test créée utilise un disque en LVM nommé pve-vm—100--disk--0.

Il est visible ici :

Sélectionnez

ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Nov  4 20:54 control
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data -> ../dm-5
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data_tdata -> ../dm-3
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data_tmeta -> ../dm-2
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data-tpool -> ../dm-4
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-root -> ../dm-1
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-swap -> ../dm-0
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-vm--100--disk--0 -> ../dm-6

pve-root est le volume LVM contenant le /, pve-swap comme son nom l’indique, correspond au swap, pve-pool correspond au pool (pool : ensemble de ressources réutilisables), et enfin l’image disque de notre VM : pve-vm—100—disk-0, incluse dans pve-pool.

La commande pvs fournit des informations sur les volumes physiques :

Sélectionnez

pvs
  PV         VG  Fmt  Attr PSize   PFree
  /dev/sda3  pve lvm2 a--  <24.50g 3.00g

Nous pouvons voir que notre partition sda3 fait partie d’un Volume Group nommé pve.

La commande vgs permet d’afficher les informations sur les Volume Group :

Sélectionnez

vgs
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1   4   0 wz--n- <24.50g 3.00g

Nous pouvons voir pour notre unique VG un seul disque (PV), contenant 4 volumes logiques (LV).

La commande lvs nous permet de lister les volumes logiques :

Sélectionnez

lvs
  LV            VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve twi-aotz-- <10.50g             7.37   1.60                  
  root          pve -wi-ao----   6.00g                                          
  swap          pve -wi-ao----   3.00g                                          
  vm-100-disk-0 pve Vwi-aotz--  32.00g data        2.42

Dans notre cas de figure, nous allons intégrer notre « physical volume » dans un volume chiffré LUKS :

Image non disponible

Dans l’exemple utilisé, je suis parti sur une distribution PROXMOX, utilisant KVM et intégrant l’utilisation d’LVM.

Nous allons commencer par la création d’une partition sur un second disque. Nous faisons abstraction de l’installation du disque supplémentaire ne pouvant être faite à chaud que si le matériel le permet.

Sélectionnez

cfdisk /dev/sdb

Vous pourrez avoir besoin d’installer cryptsetup, le gestionnaire de chiffrement LUKS, si celui-ci n’est pas disponible sur votre installation :

Sélectionnez

apt update
apt install cryptsetup

Création d’un volume chiffré sur la nouvelle partition :

Sélectionnez

cryptsetup luksFormat --type luks2 /dev/sdb1

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sdb1:
Verify passphrase:

Nous ouvrons ensuite le volume LUKS en lui attribuant le nom de crypt-data-tmp :

Sélectionnez

cryptsetup luksOpen /dev/sdb1 crypt-data-tmp
Enter passphrase for /dev/sdb1:

il va y avoir un petit délai avant que le shell rende la main, délai correspondant au déchiffrement, ne soyez donc pas surpris.

Nous pourrons ensuite le voir dans /dev/mapper :

Sélectionnez

ls /dev/mapper/ -l
total 0
crw------- 1 root root 10, 236 Nov  4 20:54 control
lrwxrwxrwx 1 root root       7 Nov  5 03:30 crypt-data-tmp -> ../dm-7
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data -> ../dm-5
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data_tdata -> ../dm-3
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data_tmeta -> ../dm-2
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-data-tpool -> ../dm-4
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-root -> ../dm-1
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-swap -> ../dm-0
lrwxrwxrwx 1 root root       7 Nov  4 20:54 pve-vm--100--disk--0 -> ../dm-6

Nous initialisons ensuite notre volume LUKS pour pouvoir l’utiliser avec LVM :

Sélectionnez

pvcreate /dev/mapper/crypt-data-tmp
  Physical volume "/dev/mapper/crypt-data-tmp" successfully created.

L’affichage de la commande pvs fait apparaître nos deux disques LVM. Nous voyons également qu’aucun VG n’est affecté à crypt-data-tmp.

Sélectionnez

pvs
  PV                     VG  Fmt  Attr PSize   PFree
  /dev/mapper/crypt-data-tmp     lvm2 ---   24.98g 24.98g
  /dev/sda3              pve lvm2 a--  <24.50g  3.00g

Nous intégrons ensuite crypt-data-tmp au volume group :

Sélectionnez

vgextend pve /dev/mapper/crypt-data-tmp
  Volume group "pve" successfully extended

Retour de la commande pvs :

Sélectionnez

pvs
  PV                     VG  Fmt  Attr PSize   PFree
  /dev/mapper/crypt-data-tmp pve lvm2 a--   24.98g 24.98g
  /dev/sda3              pve lvm2 a--  <24.50g  3.00g

Nous déplaçons maintenant le contenu du VG contenu dans /dev/sda3 vers /dev/mapper/crypt-data-tmp :

Sélectionnez

pvmove /dev/sda3 /dev/mapper/crypt-data-tmp
  /dev/sda3: Moved: 0.22%
  /dev/sda3: Moved: 6.85%
  /dev/sda3: Moved: 13.85%
  /dev/sda3: Moved: 13.96%
  /dev/sda3: Moved: 18.17%
  /dev/sda3: Moved: 22.84%
  /dev/sda3: Moved: 27.64%
  /dev/sda3: Moved: 32.95%
  /dev/sda3: Moved: 37.54%
  /dev/sda3: Moved: 41.87%
  /dev/sda3: Moved: 46.90%
  /dev/sda3: Moved: 50.77%
  /dev/sda3: Moved: 53.06%
  /dev/sda3: Moved: 56.41%
  /dev/sda3: Moved: 59.95%
  /dev/sda3: Moved: 65.85%
  /dev/sda3: Moved: 71.03%
  /dev/sda3: Moved: 77.21%
  /dev/sda3: Moved: 83.50%
  /dev/sda3: Moved: 89.57%
  /dev/sda3: Moved: 90.70%
  /dev/sda3: Moved: 95.35%
  /dev/sda3: Moved: 100.00%

Le fait de déplacer le Volume Group va bien entendu déplacer les volumes logiques qu’il contient.

En cas d’interruption, le volume sera dans un état incohérent au niveau du démarrage et donc inutilisable en l’état, ceci probablement comme suite à la configuration du fichier cryptab, non effectuée, que nous verrons un peu plus tard. Un reboot provoquera un passage de GRUB en mode rescue :

Si vous n’êtes pas dans ce cas de figure, vous pouvez continuer à la partie « suite de la procédure ».

Il est possible de résoudre le problème en démarrant sur un live cd/live USB et en appliquant les commandes suivantes.

Il faudra commencer par ouvrir le volume crypté :

Sélectionnez

cryptsetup luksOpen /dev/sdb1 crypt-data-tmp
Enter passphrase for /dev/sdb1:

En listant les volumes présents dans /dev/mapper, vous pourrez apercevoir un volume pve-pvmove0 correspondant aux traces du volume en cours de transfert :

Sélectionnez

s /dev/mapper/
control         pve-data_tdata  pve-lvol0_pmspare  pve-root
crypt-data-tmp  pve-data_tmeta  pve-pvmove0        pve-swap

Nous entrons en chroot dans le système planté. Ceci est possible, car le volume est accessible si crypt-data-tmp est ouvert, une partie des données se trouvant sur /dev/sda3 l’autre sur crypt-data-tmp.

Sélectionnez

root@ubuntu:~# mount /dev/mapper/pve-root /mnt
root@ubuntu:~# cd /mnt 
root@ubuntu:/mnt# mount --bind /proc proc
root@ubuntu:/mnt# mount --bind /sys sys
root@ubuntu:/mnt# mount --bind /dev dev
root@ubuntu:/mnt# chroot .

Une fois dans le chroot, nous relançons la procédure en rappelant pvmove sans paramètres :

Sélectionnez

root@ubuntu:/# pvmove
  /run/lvm/lvmpolld.socket: connect failed: No such file or directory
  WARNING: Failed to connect to lvmpolld. Proceeding with polling without using lvmpolld.
  WARNING: Check global/use_lvmpolld in lvm.conf or the lvmpolld daemon state.
  /dev/sda3: Moved: 13.96%
  /dev/sda3: Moved: 18.48%
…

Une fois le processus terminé, vous pourrez continuer la procédure normale indiquée ci-dessous depuis le chroot.

Suite de la procédure :

Une fois le transfert abouti, nous pouvons sortir le disque d’origine du VG :

Sélectionnez

vgreduce pve /dev/sda3
  Removed "/dev/sda3" from volume group "pve"

Sélectionnez

pvs
  PV                     VG  Fmt  Attr PSize   PFree
  /dev/mapper/crypt-data-tmp pve lvm2 a--   24.98g   3.48g
  /dev/sda3                  lvm2 ---  <24.50g <24.50g

La commande ci-dessus permet de voir /dev/sda3 ne fait plus partie du VG pve.

Reste à effacer le label LVM de l’ancien volume :

Sélectionnez

pvremove /dev/sda3
  Labels on physical volume "/dev/sda3" successfully wiped.

À ce stade, /dev/sda3 ne sera plus considéré comme un disque physique utilisé par LVM.

Le volume LVM ne sera plus bootable en l’état, il va nous falloir modifier le fichier /etc/crypttab, ce que nous ferons une fois les données de nouveau déplacées sur le disque d’origine.

Nous supprimons maintenant la partition contenant originellement les données :/dev/sda3 :

Nous créons une partition de 512 Mo dans laquelle nous placerons le volume /boot et une autre avec le reste du disque pour le nouveau volume crypté :

GRUB ne gère pas correctement le format luks2. Pour pallier cette difficulté et pouvoir quand même bénéficier de luks2 pour la partie données, nous allons créer une partition luks1 pour le /boot (qui contiendra le noyau et l’initramfs) et une partition luks2 pour le reste du volume.

Création du volume chiffré luks1 pour le boot :

Sélectionnez

cryptsetup luksFormat --type luks1 /dev/sda3

WARNING!
========
This will overwrite data on /dev/sda3 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda3:
Verify passphrase:

Nous ouvrons ensuite le volume chiffré (avec dans mon cas le nom crypt-boot) :

Sélectionnez

cryptsetup luksOpen /dev/sda3 crypt-boot
Enter passphrase for /dev/sda3:

Création du système de fichiers :

Sélectionnez

mkfs.ext4 /dev/mapper/crypt-boot
mke2fs 1.46.2 (28-Feb-2021)
Creating filesystem with 202752 1k blocks and 50800 inodes
Filesystem UUID: eb7aeea2-7454-495a-aea8-a8e20fd06069
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Nous nous occupons ensuite du déplacement des données de /boot vers la nouvelle partition chiffrée.

première étape, le montage de la partition dans un point de montage temporaire, nous utiliserons /mnt :

Sélectionnez

mount /dev/mapper/crypt-boot /mnt

Avant la copie du contenu de /boot, Nous démontons la partition UEFI qui y est montée dans le sous-dossier /boot/efi :

Sélectionnez

umount /boot/efi

Nous déplaçons ensuite le contenu de /boot dans le point de montage /mnt :

Sélectionnez

mv /boot/* /mnt

puis démontons /mnt :

Sélectionnez

umount /mnt

Afin que /boot soit monté depuis la nouvelle partition, nous ajoutons ensuite la ligne suivante dans le fichier /etc/fstab :

Sélectionnez

/dev/mapper/crypt-boot  /boot   ext4    defaults,rw     0       1

Si dans votre cas de figure, /boot se trouve déjà dans un point de montage dans votre fichier fstab, il vous faudra modifier cette entrée.

Nous appelons ensuite la commande suivante :

Sélectionnez

mount -a

qui va du coup monter la nouvelle partition /boot et remonter la partition UEFI dans /boot/efi.

Déplacement du volume LVM de sdb2 vers sda4 :

Nous appliquons la méthode déjà effectuée pour déplacer les LVM du volume nouvellement chiffré sur le disque secondaire/externe vers la nouvelle partition du disque interne.

Sélectionnez

~# cryptsetup luksFormat --type luks2 /dev/sda4
~# cryptsetup luksOpen /dev/sda4 crypt-data
~# pvcreate /dev/mapper/crypt-data
~# vgextend pve /dev/mapper/crypt-data
~# pvmove /dev/mapper/crypt-data-tmp /dev/mapper/crypt-data
~# vgreduce pve /dev/mapper/crypt-data-tmp
~# pvremove /dev/mapper/crypt-data-tmp

Nous allons maintenant intégrer les entrées correspondant aux volumes chiffrés dans le fichier /etc/crypttab.

Celui-ci va contenir les entrées sous le format suivant :

Sélectionnez

# <target name> <source device>         <key file>      <options>

Il va nous falloir récupérer les UUID des partitions chiffrées. Pour cela, nous allons utiliser la commande blkid, filtrer l’entrée voulue avec grep, puis intégrer le résultat dans le fichier crypttab :

Sélectionnez

blkid | grep sda3 >> /etc/crypttab
blkid | grep sda4 >> /etc/crypttab

ce qui nous donnera :

Sélectionnez

# <target name> <source device>         <key file>      <options>
/dev/sda3: UUID="f455efb3-e5a5-485c-95e8-9545576df084" TYPE="crypto_LUKS" PARTUUID="bcf8ed72-5691-914f-bf60-708e19415519"
/dev/sda4: UUID="ebda5ade-238c-46fe-b4cc-28f5cf745fc1" TYPE="crypto_LUKS" PARTUUID="42c5378b-a7ea-954d-b06a-34fe4e46607d"

que nous modifierons en :

Sélectionnez

# <target name> <source device>         <key file>      <options>
crypt-boot UUID=f455efb3-e5a5-485c-95e8-9545576df084    none    luks,discard
crypt-data UUID=ebda5ade-238c-46fe-b4cc-28f5cf745fc1    none    luks,discard

Nous mettons ensuite à jour l’initramfs :

Sélectionnez

update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.15.30-2-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..
No /etc/kernel/proxmox-boot-uuids found, skipping ESP sync.

Nous ajoutons la ligne GRUB_ENABLE_CRYPTODISK=y au fichier /etc/default/grub afin que GRUB puisse gérer la partition chiffrée :

Sélectionnez

echo GRUB_ENABLE_CRYPTODISK=y >> /etc/default/grub

Nous effectuons ensuite la mise à jour de GRUB :

Sélectionnez

~#update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.15.30-2-pve
Found initrd image: /boot/initrd.img-5.15.30-2-pve
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
Adding boot menu entry for EFI firmware configuration
done

suivi de :

Sélectionnez

~# grub-install
Installing for x86_64-efi platform.
Installation finished. No error reported.

Le démarrage sera alors opérationnel avec GRUB se chargeant depuis le disque interne, accédant à la partition de boot chiffrée, accédant elle-même au / chiffré sur le second disque.

Au reboot, GRUB nous demandera le mot de passe (de la partition /boot) :

Rappel : vous aurez un certain délai avant une réponse.

En cas d’erreur de saisie du mot de passe, vous passerez en mode rescue :

Une fois le bon code entré, vous aurez l’écran GRUB normal.

Pendant la suite du chargement, vous sera demandée la clé pour déverrouiller le volume crypt-data :

Vous sera également redemandé le mot de passe de la partition de boot :

création de fichiers de clé :

Afin de ne pas avoir à saisir de mots de passe après celui de GRUB, nous allons créer des fichiers de déverrouillage par clé. Celle déverrouillant le / devant être intégrée à l’initramfs, nous la placerons dans /boot. Ces clés étant dans des volumes cryptés, cela ne posera pas de problème de sécurité.

Les volumes pourront toujours être déverrouillés avec les mots de passe précédemment enregistrés.

Création d’un fichier de données aléatoires qui servira de clé :

Sélectionnez

# dd if=/dev/urandom of=/boot/root.key bs=1024 count=4
4+0 records in
4+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000505154 s, 8.1 MB/s

Attribution des droits lecture seule :

Sélectionnez

~# chmod 0400 /boot/root.key

ajout du fichier de clé dans le volume crypté :

Sélectionnez

~# cryptsetup luksAddKey /dev/sda4 /boot/root.key
Enter any existing passphrase:

modification du fichier /etc/crypttab :

Nous remplaçons l’entrée :

Sélectionnez

crypt-data UUID=ebda5ade-238c-46fe-b4cc-28f5cf745fc1    none    luks

par :

Sélectionnez

crypt-data UUID=ebda5ade-238c-46fe-b4cc-28f5cf745fc1    /boot/root.key  luks,keyscript=/bin/cat

Le fait de passer en script /bin/cat fera en sorte que la commande cat dans l’initramfs passe le fichier /boot/root.key en paramètre à cryptsetup.

Il nous reste à créer un fichier de hook déclenchant l’intégration du fichier root.key dans l’initramfs.

création du fichier /etc/initramfs-tools/hooks/keyfile (le nom de fichier keyfile étant choisi arbitrairement):

Sélectionnez

#!/bin/sh
mkdir -p "${DESTDIR}/boot"
cp /boot/root.key "${DESTDIR}/boot/"

nous rendons le script exécutable :

Sélectionnez

~# chmod +x /etc/initramfs-tools/hooks/keyfile

nous mettons à jour l’initramfs :

Sélectionnez

~# update-initramfs -u -k all

Vous pourrez constater l’intégration du fichier root.key dans le dossier /boot de l’initramfs avec la commande :

Sélectionnez

lsinitramfs <chemin/nom_fichier initramfs>

Le fichier est donc accessible du point de vue de l’initramfs par le chemin /boot/root.key tout comme du point de vue du système complètement chargé, celui-ci étant dans le ramdisk initramfs avant le pivot_root, puis dans l’arborescence / ensuite.

Au prochain redémarrage, après GRUB, il ne vous sera demandé que le mot de passe du volume boot :

Création du fichier de clé pour /boot :

Nous pourrons stocker le fichier de clé sur la partition root. Nous le ferons dans le dossier /etc/keys :

Sélectionnez

~# mkdir /etc/keys
~# dd if=/dev/urandom of=/etc/keys/boot.key bs=1024 count=4
4+0 records in
4+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000674576 s, 6.1 MB/s

Nous appliquons les droits en lecture seule :

Sélectionnez

~# chmod 0400 /etc/keys
~# chmod 0400 /etc/keys/boot.key

Nous intégrons la clé au volume :

Sélectionnez

~# cryptsetup luksAddKey /dev/sda3 /etc/keys/boot.key
Enter any existing passphrase:

Nous ajoutons la clé dans /etc/crypttab :

Sélectionnez

crypt-boot UUID=f455efb3-e5a5-485c-95e8-9545576df084    /etc/keys/boot.key     luks

Au reboot, vous n’aurez plus qu’à entrer la clé au lancement de GRUB.

7-4-2-1. Exploitation du disque secondaire pour du RAID 1▲

Vu que la méthode exposée implique l’utilisation au moins temporaire d’un disque secondaire, pourquoi ne pas le conserver et l’utiliser en mode RAID 1 logiciel ?

Ceci est tout à fait possible. Dans ce cas, les volumes LUKS, dont celui affecté au root, imbriqueront eux-mêmes des volumes LVM, qui seront eux-mêmes imbriqués dans des volumes RAID 1 logiciels via mdadm.

Cette méthode, en plus de la sécurisation RAID, apportera l’écrasement des données en clair pour les deux disques.

Ceci devra être fait dès le départ. Voici la procédure avec le rajout de la couche RAID.

Nous aurons donc besoin du paquet mdadm en plus de cryptsetup. Le processus sera relativement similaire en plus de l’ajout de la couche RAID.

Création de la table de partition sur le disque secondaire, en sélectionnant le type de partition « Linux RAID » au lieu de partition « Linux LVM »(sauf pour la partition UEFI) :

Nous créons une partition pour l’UEFI, une partition pour le /boot et la partition de root.

Création du volume RAID pour la partition de boot :

Sélectionnez

mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 --metadata=1.0 missing /dev/sdb2
mdadm: size set to 524224K
mdadm: array /dev/md1 started.

Avec en paramètres :

--create : pour la création bien entendu
– verbose : pour le mode bavard
/dev/md1: le second pseudo-volume RAID
--level=1 : indique le mode RAID 1 (mirroring)
--raid-devices=2 : le volume RAID aura deux partitions physiques
--metadata=1.0 : force l’utilisation du format 1.0 des métadonnées pour que celles-ci soient placées en fin de partitions, option nécessaire à GRUB
missing première partition du volume RAID (missing signifiant absent lors de la création du volume RAID)
/dev/sdb2 : seconde partition du volume

Nous gardons /dev/md0 pour la création d’un RAID pour l’UEFI que nous verrons un peu plus tard.

Nous venons ici de déclarer un RAID utilisant /dev/sdb2 en mode dégradé, le but étant d’intégrer les volumes du disque d’origine hébergeant actuellement le système, une fois le contenu déplacé dessus.

Nous formatons ce volume RAID avec Luks :

Sélectionnez

~#  cryptsetup luksFormat --type luks1 /dev/md1

le montons :

Sélectionnez

~# cryptsetup luksOpen /dev/md1 crypt-boot

La procédure sera la même que celle vue précédemment à savoir :

formatage de la partition ;
montage et copie des données de /boot dedans ;
démontage et modification du fstab.

création du volume RAID pour le root :

Sélectionnez

~# mdadm --create --verbose /dev/md2 --level=1 --raid-devices=2 missing /dev/sdb3
mdadm: array /dev/md2 started.

Nous devrons ensuite :

formater le volume au format LUKS ;
ouvrir le volume ;
l’intégrer au VG ;
déplacer le contenu du VG dessus ;
sortir l’ancien disque du VG.

mise à jour du fichier de configuration mdadm :

Sélectionnez

~# mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Mise à jour du fichier /etc/crypttab : comme précédemment en utilisant les UUID des volumes mdadm, pas des partitions directement.

mise à jour de GRUB : ne pas oublier l’ajout de l’entrée GRUB_ENABLE_CRYPTODISK=y

Lors de celle-ci, vous aurez des messages d’erreur de type :

Sélectionnez

/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..

idem pour grub-install

Une fois l‘opération effectuée, GRUB se lance depuis le disque d’origine puis charge le système depuis le second disque contenant le RAID dégradé.

Nous allons créer les partitions sur le disque d’origine pour l’intégrer au RAID :

table avant manipulation :

Table après mise à jour :

Nous intégrons maintenant nos nouvelles partitions écrasant le disque d’origine au RAID :

Sélectionnez

~# mdadm /dev/md1 --add /dev/sda3
mdadm: added /dev/sda3
~# mdadm /dev/md2 --add /dev/sda4
mdadm: added /dev/sda4

Nous pouvons voir l’état de progression de la mise à jour du RAID en affichant le contenu du fichier /proc/mdstat :

Sélectionnez

~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda4[2] sdb3[1]
      15718336 blocks super 1.2 [2/1] [_U]
      [===>.................]  recovery = 15.5% (2451904/15718336) finish=4.1min speed=53448K/sec

md1 : active raid1 sda3[2] sdb2[1]
      524224 blocks super 1.0 [2/2] [UU]

Une fois le RAID synchronisé, voici ce qui vous sera retourné :

Sélectionnez

~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda4[2] sdb3[1]
      15718336 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda3[2] sdb2[1]
      524224 blocks super 1.0 [2/2] [UU]

Gestion du boot :

À cause de GRUB, il n’est normalement pas possible d’intégrer une partition UEFI en RAID.

Voici la procédure utilisée pour pouvoir le faire.

Nous commençons par créer notre RAID pour l’UEFI en mode dégradé sur la partition du second disque :

Sélectionnez

~# mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 --metadata=1.0 missing /dev/sdb1
mdadm: size set to 204736K
mdadm: array /dev/md0 started.

L’option –metadata=1.0 permet de forcer l’utilisation du format de métadonnées 1.0 qui va écrire celles-ci en fin de partition, ce qui sera transparent pour GRUB et l’UEFI.

Si vous utilisez d’autres systèmes d’exploitation sur le disque, ce qui vu la configuration est peu probable, une modification de la partition UEFI faite par celui-ci ne sera pas vue par le RAID logiciel. Vous vous trouverez dans une situation indéterminée sur le contenu de celui-ci après manipulation.

Nous continuons avec le formatage de la partition UEFI en FAT32 avec le même UUID que la partition d’origine :

Sélectionnez

~# mkfs.vfat -F32 -i 32B8F118 /dev/md0
 mkfs.fat 4.2 (2021-01-31)

La valeur 32B8F118 correspond à l’UUID de la partition UEFI en cours sans le tiret (qu’il ne faut pas mettre), UUID que nous avons récupéré avec la commande :

Sélectionnez

~# blkid | grep sda2

Nous montons cette nouvelle partition dans /mnt :

Sélectionnez

~# mount /dev/md0 /mnt

recopions le contenu de la partition UEFI d’origine vers la seconde :

Sélectionnez

~# rsync -av /boot/efi/* /mnt/

Nous démontons ensuite les deux partitions UEFI :

Sélectionnez

~# umount /mnt /boot/efi

nous intégrons maintenant la partition UEFI d’origine au RAID md0 :

Sélectionnez

~# mdadm /dev/md0 --add /dev/sda2
mdadm: added /dev/sda2

Une petite vérification de l’état de synchronisation avant de continuer :

Sélectionnez

~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda2[2] sdb1[1]
      204736 blocks super 1.0 [2/2] [UU]

md2 : active raid1 sdb3[1] sda4[2]
      24099840 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sdb2[1] sda3[2]
      524224 blocks super 1.0 [2/2] [UU]

unused devices: <none>

Nous remontons ensuite la partition UEFI avec :

Sélectionnez

~# mount -a

Rappel : dans l’entrée fstab, le point de montage se fait avec l’UUID :

Sélectionnez

UUID=32B8-F118 /boot/efi vfat defaults 0 1

Avant création du RAID, l’appel à la commande mount retournait pour /boot/efi :

Sélectionnez

/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Après création du RAID et remontage avec mount -a, la commande mount nous retourne pour /boot/efi :

Sélectionnez

/dev/md0 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Le RAID est bien pris en compte.

Nous mettons à jour le fichier mdadm.conf :

Sélectionnez

~# mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Si vous l’aviez déjà fait, il faut modifier les entrées précédentes.

Nous allons ensuite ajouter une entrée UEFI pour le second disque et refaire l’entrée pour le premier avec la commande efibootmgr.

Ajout de l’entrée pour le second disque :

Sélectionnez

~# efibootmgr -v -c -L 'raid-linux-2' -l '\EFI\proxmox\grubx64.efi' -d /dev/sdb -p 1
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0006,0005,0000,0001,0002,0003,0004
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376         PciRoot(0x0)/Pci(0x1f,0x1)/Ata(1,0,0)N.....YM....R,Y.
Boot0002* UEFI VBOX HARDDISK VB4367cd18-2eed7edc        PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)N.....YM....R,Y.
Boot0003* UEFI VBOX HARDDISK VB4fdb8429-03b95200        PciRoot(0x0)/Pci(0x1f,0x2)/Sata(1,65535,0)N.....YM....R,Y.
Boot0004* EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0005* proxmox       HD(2,GPT,5980e14c-c773-4da4-8715-f5f0a4919f3e,0x800,0x100000)/File(\EFI\proxmox\grubx64.efi)
Boot0006* raid-linux-2  HD(1,GPT,7fcdcf82-8945-b840-9b41-cde034897e95,0x800,0x64000)/File(\EFI\proxmox\grubx64.efi)

Avec en paramètres :

-v : pour Verbose, mode bavard ;
-c : create ;
L : label, j’utilise dans ce cas le label « raid-linux-2 » ;
-l : spécifie le chemin du fichier EFI : dans mon cas grubx64.efi dans le dossier « proxmox », à adapter à votre situation ;
-d : pour le disque, sdb représentant le second disque ;
-p : pour le numéro de partition.

Nous pouvons voir que l’entrée à été ajoutée sous le numéro 0006 et qu’il s’agit de la première entrée dans l’ordre de boot (ligne boot order).

À ce stade, en cas de reboot, l’UEFI lancera GRUB depuis le second disque.

Nous supprimons l’entrée d’origine numéro 0005 nommée « proxmox » dans mon cas.

Sélectionnez

~# efibootmgr --delete-bootnum --bootnum 5
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0006,0000,0001,0002,0003,0004
Boot0000* UiApp
Boot0001* UEFI VBOX CD-ROM VB2-01700376
Boot0002* UEFI VBOX HARDDISK VB4367cd18-2eed7edc
Boot0003* UEFI VBOX HARDDISK VB4fdb8429-03b95200
Boot0004* EFI Internal Shell
Boot0006* raid-linux-2

Nous recréons l’entrée en la nommant « raid-linux-1 » :

Sélectionnez

~# efibootmgr -v -c -L 'raid-linux-1' -l '\EFI\proxmox\grubx64.efi' -d /dev/sda -p 2

Avec cet ajout, le prochain reboot se fera sur le premier disque comme à l’origine.

En entrant dans le BIOS UEFI, dans mon cas VirtualBox, nous pouvons voir les deux entrées créées :

En regardant à gauche la valeur de Device Path pour les deux entrées, nous pouvons constater que les deux sont différentes.

7-4-2-2. Perte d’un disque▲

Nous allons simuler la perte du premier disque.

Disque perdu, le boot au niveau de GRUB sera transparent.

Nous aurons des messages d’erreur :

mais le démarrage aboutira.

Si nous consultons l’état des RAID logiciels :

Sélectionnez

~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : active raid1 sda1[1]
      204736 blocks super 1.0 [2/1] [_U]

md1 : active raid1 sda2[1]
      524224 blocks super 1.0 [2/1] [_U]

md2 : active raid1 sda3[1]
      24099840 blocks super 1.2 [2/1] [_U]

unused devices: <none>

Nous pouvons constater qu’il sont en mode dégradé. Nous voyons également que les partitions visibles sont sur sda, bien que le disque survivant soit le second, donc normalement sdb. Nous pouvons voir que notre RAID md0 a été renommé en md127.

Après ajout d’un nouveau disque, le disque fonctionnel apparaît de nouveau en sdb :

Sélectionnez

cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md126 : active raid1 sdb1[1]
      204736 blocks super 1.0 [2/1] [_U]

md127 : inactive sda1[2](S)
      204784 blocks super 1.0

md1 : active raid1 sda2[2] sdb2[1]
      524224 blocks super 1.0 [2/2] [UU]

md2 : active raid1 sdb3[1]
      24099840 blocks super 1.2 [2/1] [_U]

unused devices: <none>

La remise en service sera très simple. Il faudra sur le nouveau disque créer une nouvelle table de partition identique à celle utilisée, puis intégrer les nouvelles partitions au RAID.

8. Utilisation avec le cloud▲

Avec une utilisation Cloud, il est possible que le chiffrement des disques soit natif.

Dans le cas contraire, vous serez dans les conditions exposées ci-dessous.

8-1. VPS▲

Un VPS (Virtual Private Server pour serveur virtuel privé) est un serveur qui est mis à votre disposition par votre hébergeur. L’accès à celui-ci se fera :

depuis une interface Web au travers de solutions de type cPanel (pour une citer que lui) ;
par un accès SSH.

Dans le cas d’un accès uniquement via une interface web, votre interaction avec le VPS sera limitée, vous n’aurez accès qu’aux fonctionnalités implémentées.

Dans le cas d’un accès SSH, il vous faut garder à l’esprit que vous n’êtes pas devant un écran, et que la moindre manipulation vous faisant perdre l’accès SSH peut interrompre une opération critique vous obligeant à relancer l’installation. Dans ce cas de figure, les hébergeurs fournissent en général un mode rescue (en général un netboot sur une image système de base avec accès à vos disques), celui-ci vous permettant de chrooter dans le système à modifier.

8-2. Services cloud type Amazon AWS, Microsoft Azure▲

Avec ce genre de services, il vous est fourni un accès SSH (ou RDS avec Windows). Vous pouvez donc appliquer les méthodes vues en gardant à l’esprit que n’avez qu’un accès SSH, et que sa perte peut vous empêcher de continuer une procédure interrompue nécessitant l’usage du mode rescue.

Ce genre de services intègre en général le chiffrage des volumes.

9. Conclusion▲

Le chiffrement des disques accroît la confidentialité des données sensibles dont la divulgation pourrait provoquer un préjudice majeur.
Il protège très efficacement contre l’accès notamment physique au disque, par exemple en cas de perte ou de vol. C’est un complément devenant indispensable au(x) mot(s) de passe (du compte ou du bios).
Le chiffrement est une option disponible sur la plupart des systèmes d’exploitation. Nous avons vu Bitlocker, disponible sur Windows, LUKS sous Linux, et Filevault sous MacOS. Pour être activé, il peut nécessiter des prérequis logiciels (comme une version pro de Windows pour Bitlocker) ou matérielle (TPM).

Il existe également des logiciels tiers de chiffrement, nous avons vu Veracrypt.

La contrepartie de la sécurité obtenue est le risque de perdre ses données en cas de perte totale de la clé (d’où l’importance d’avoir plusieurs sauvegarde de la clé de récupération pour Bitlocker ou de ne pas perdre le mot de passe) avec du coup une perte totale d’accès aux données, et de rendre éventuellement une réparation plus complexe, le chiffrement rendant plus difficile une maintenance sur un système de fichiers.

Il est à noter qu’un chiffrement ne vous protégera pas d’une intrusion due à une faille de sécurité du système d’exploitation, d’un virus ou tout simplement d’un accès à une session laissée ouverte.

Je préconiserais de ne pas placer la sauvegarde sur un volume chiffré, mais d'utiliser le chiffrement inclus dans le logiciel de sauvegarde (demandant la saisie d'un mot de passe) ou éventuellement d’utiliser un disque externe à chiffrement matériel (vous demandant également un mot de passe).

9-1. Remerciements▲

Je remercie Gaby277 pour sa relecture technique.

Je remercie également escartefigue pour sa relecture orthographique.

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2023 Chrtophe. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.