Sauvegardes nomades sécurisées pour laptop

Pour qui utilise un Laptop comme ordinateur principal les sauvegardes sont toujours nécessaires, mais pas si évidentes. La solution “Cloud” est en fait le plus souvent un mirroir, et ce n’est donc une sauvegarde que en cas de perte de la machine principale, mais si un document est perdu sur la machine principale, il le sera aussi sur le mirroir.

Un sauvegarde doit donc être faite sur des disques externes USB chiffrés, connectés régulièrement, en suivant une programmation adéquate (daily-weekly …)

Il devrait y avoir (au moins) deux “lieux” avec chacun un disque de sauvegardes qui ne bouge pas. L’ordinateur se promenant de l’un à l’autre (typiquement, domicile et bureau). Au moins une sauvegarde serait alors à l’abri en cas d’incendie ou de vol. Cela pourrait toutefois être insuffisant face aux risques d’agressions militaires majeures, qui se produisent pourtant.

Jusqu’à présent et depuis plus de 10 ans, j’utilisais un desktop avec un disque dur de travail et un autre pour les sauvegardes, automatisé par cron et rsnapshot. Je n’avais à y penser que lorsque j’avais perdu quelquechose : je le retrouvais assez facilement, dans les répertoires correspondants aux dates d’il y a quelques jours, semaines ou mois, celon la situation. Bref, j’étais satisfait de ce système.

Je prend maintenant un laptop comme ordi principal. Mes besoins de sécurité augmentent donc : chiffrage de l’ordinateur pour les cas de perte ou de vol, et sauvegardes qui doivent nécessairement être hors de la machine ; idéalement en plusieurs lieux, genre bureau et domicile.

L’idée est donc de laisser un disque USB à ces endroits et, quand je vais les connecter, déclencher automatiquement un script qui fait automatiquement la sauvegarde adéquate. Ces disques que je vais laisser hors de mon contrôle direct doivent bien sur aussi être chiffrés, de façon à être ouverts automatiquement dans la procédure de sauvegarde, et aussi manuellement au cas ou je perdrais l’ordinateur.

Le shéma sera une cascade de scripts : - rsnapshot qui m’a toujours doné satisfaction - Crypshot pour gérer le chiffrement de la partition accueillant les sauvegardes, qui appellera rsnapshot - Backitup pour lancer les sauvegardes adéquates quand les disques externes sont connectés - La procédure ci dessous présente la configuration pour un “lieu” de sauvegarde, à “domicile”, il faut la refaire en l’adaptant légèrement pour mettre en place un deuxième “lieu” de sauvegarde, au “bureau”

Nous utiliserons les partitions “LUKS” pour leur (relative) simplicité et la possibilité de définir plusieurs “clés” (fichiers ou bonmots-de-passe) permettant le déchiffrement.

Avant de confier la manipulation de conteneurs LUKS à des scripts que nous devrons configurer, apprenons à les manipuler à la main.

• l’utilisation de partitions chiffrées est un risque supplémentaire pour les données ; celui de la perte d’accès, par perte des mots de passe, altération des entêtes du volume etc. Soyez responsable.
• Apprenez à manipulez vos partitions chiffrées vous mêmes à la main. Vous voulez être compétents pour être en mesure de les utiliser quand vous aurez besoin de vos backups et que la situation vous échappera un peu…
• Je réalise la plupart des opérations suivantes avec les outils graphiques de KDE. Je ne suis pas en mesure de donner les lignes de commande de façon suffisamment fiable pour une documentation publique. Suivez les étapes et faites attention à ce que vous faites.
• Toutes les commandes (ou presque) de ce tutoriel sont à passer en root (en utilisant sudo)

• Nous utilisons des scripts qui seront appelés en tant que root, mais que j’ai édité (plusieurs fois en mode essai-erreur) en tant qu’utilisateur. Il m’a fallu faire quelques ajustements au niveau des droits pour faire tout cela (commandes chown et chmod en sudo). [Par exemple, mettre “mon utilisateur” dans le groupe “root” et utiliser des droits de type “root.root 760” pour que root puisse exécuter les scripts, moi pouvoir les éditer, et rien pour les autres] Si vous n’êtes pas à l’aise avec ces manipulations, persévérez dans l’apprentissage de ces notions avant de configurer vos chiffrements

• dès la connexion du disque en USB plusieurs points de montage apparaissent :
  1. /dev/sdXx (genre sdc1) mais ce point de montage changera facilement si un autre USB est connecté avant, ou autre raison.
  2. Une série de liens symboliques vers ce premier point sont proposés dans /dev/disk classés par sous répertoire celon le type d’identification, par uuid ou label, pour les disques ou les partitions. Je préfères /dev/disk/by-partlabel/, plus visuel dans la préparation des commandes et des scripts, et les autres sont aussi fonctionnels.
  • Désormais nous utiliserons l’expression /dev/<target device> pour désigner celui que vous choisirez d’utiliser.
• lorsque une partition est déchiffrée avec une clé, sous le nom “monVolume”, elle apparait dans /dev/mapper/monVolume
• pour l’utiliser, il faudra la formater (une seule fois hein, sous peine de perdre les donées !) Utiliser ext4 typiquement, surtout pas vfat ou un autre format qui ne supporte pas les liens en durs, nécessaires à rsnapshot.
• puis la monter (dans /mnt/monVolume typiquement). Ce montage est persistant, tant que le volume n’a pas été démonté, par une commande, un script ou l’arrêt de l’ordinateur.

Ces opérations ne sont à faire que une seule fois, à la création du volume chiffré.

Ici ont fait bien attention à ne pas bousiller une partion qui nous est utile !! J’utilise pour ma part une partition unique sur un disque USB …mais vous faites bien ce que vous voulez.

Outils : gestionnaire de partitions KDE, $lsblk , viste des sous répertoire de /dev/disk. Comme indiqué plus haut, nous utiliserons ici l,expression /dev/<target device> pour désigner la partition à chiffrer.

Il est recommandé d’effacer vraiment la partition, au moins le système de fichiers. $ wipefs -a <target device>
Si vous éprouvez le besoin de supprimer aussi radicalement les anciennes données du disque (qui seront écrasées par les sauvegardes chiffrées) cat /dev/zero > <target device>. En mode parano, qui prendra du temps : cat /dev/urandom > <target-device>

Créer un conteneur LUKS :
Choisir un <Bonmot-de-passe> et le mémoriser, le mettre dans un coffre (à la banque, ou dans un bon gestionaire de mot de passe comme Keepasxc, mon choix). ensuite, lancer la commande :

 cryptsetup luksFormat <target device>

D’abord l’ouvrir une première fois

cryptsetup -v luksOpen /dev/<target device> monVolume

Ensuite, on pourra la formater sur /dev/mapper/monVolume. Ici l’expression MonVolume sera ce que vous voulez. Plus part, des scripts définiront cette valeur pour vous.

mke2fs -t ext4 -L monVolume /dev/mapper/monVolume

mkdir /mnt/monVolume 

• Ouvrir la partition chiffrée, le mot de passe sera demandé :

cryptsetup -v luksOpen /dev/<target device> monVolume

• Ouvrir la partition chiffrée, avec un fichier clé (voir plus bas):

cryptsetup -v luksOpen --key-file <chemin/Keyfile> /dev/<target device> monVolume

• Vérifier un mot de passe et son slot, sans ouvrir la partition :

cryptsetup -v luksOpen --test-passphrase /dev/<target device>

• Montage du mapper

mount -v /dev/mapper/monVolume /mnt/monVolume 

• Démontrer puis fermer la partition chiffrée

umount -v /dev/mapper/monVolume 
    # ou
umount -v /mnt/monVolume 

• Fermer la partition chiffrée

cryptsetup -v luksClose monVolume

Les scripts que l’on utilisera bientôt s’attendent à les trouver bien fermés.

Pour approfondissements, voir :

1. Un “keyfile” (qui peut être n’importe quel fichier) dans l’ordinateur pour automatiser la sauvegarde. Cette clé qui ne sera pas utilisable à qui disposerait du disque seulement : le voleur ou vous après la perte de l’ordinateur.
2. un “bon-mot de passe” que vous seul pourrez utiliser pour ouvrir le conteneur en dehors de la procédure automatisée.

Voir le nombre de clés enregistrées, et autres information de “header”

cryptsetup luksDump /dev/<target device>

Ajouter un “bon-mot de passe” à un conteneur

# cryptsetup luksAddKey  /dev/<target device> 
Enter any passphrase: (un mot de passe existant du volume)
Enter new passphrase for key slot: 
Verify passphrase: 

Ajouter une keyfile à un conteneur ayant dejà un “bon-mot de passe”

# cryptsetup luksAddKey  /dev/<target device> masterkeyfile
Enter any passphrase: (un mot de passe existant du volume)

On peut l’altérer volontairement pour rendre le conteneur illisible à qui que ce soit, il peut aussi y avoir un accident ! Attention, l’entête contient tous les slots de mots de passe et keyfiles. Le restaurer remettra donc ces slots à l’état du moment de la sauvegarde, réactivant d’anciens mots de passe éliminés. Cela peut être une bréche de sécurité si la sauvegarde de l’entête est (a été) accessible à un ancien collaborateur .

luksHeaderBackup /dev/<target device> –header-backup-file <file>

luksHeaderRestore /dev/<target device> –header-backup-file <file>

Faire des tests pour vérifier ce qui se passe au fur et à mesure…

Attention à la gestion des droits. Vous voudrez que vos scripts soient exécutables par root, pas par les autres utilisateurs en général. Vous voudrez pouvoir créer ou ajuster un script, pas forcément en tant que root avec la ligne de commande. Mes solutions ne seraient peut être pas les votres …

Voir la page dédiée rsnapshot

Attentions particulières : - rsnapshot utilise les liens en dur pour donner accès au mêmes fichiers à partir des différents répertoires datés de chaque sauvegarde. C’est ce qui fait le charme de sa facilité de retrouver des fichiers. Ne fonctionne par sur les partition “fat” - Mettre no_create_root 1 dans le fichier de configuration pour éviter que la sauvegarde ne remplisse le disque de l’ordinateur au cas ou un disque USB ne serait pas connecté au moment de la sauvegarde (en principe déjà prise en charge dans cryptshot). - Vous voudrez probablement tester votre configurration de rsnapshot avant de l’envoyer dans des volumes chiffrés. * Notez que lors de l’exécution des scripts suivants, nous utiliserons des fichiers de configuration spécifiques.

Cryptshot permet de déchiffrer la partition des sauvegardes pendant qu’elles doivent exécutées, typiquement avec rsnapshot.

Backitup permet de programmer l’exécution des sauvegardes de façon adaptée à l’intermitance de la connexion du disque USB de sauvegarde.

• Aller chercher les scripts ici : https://github.com/pigmonkey/cryptshot et ici : https://github.com/pigmonkey/backitup/blob/master/backitup.sh
• Les déposer dans un répertoire faisant partie du PATH, accessible par root, typiquement : /usr/local/bin .
  

• Les recopier en ajoutant l’extensio "*.origin)" pour sauvegarde et pouvoir ajuster les scripts eux mêmes.

• J’ai un moment été confus avec les “UUID” qui me semblaient changer, J’ai changé pour “PARTUUID” dans le script (en remplaçant toutes les occurences) qui me semblaient plus claires. C’est un fork probablement inutile ; faites comme vous voulez et soyez responsables !
• La configuration peut se faire dans le script, mais si vous voulez plusieurs sauvegardes, sur des disques usb différents (dans des lieux différents) avec chacun ses identifiants de partition <target device>, il faudra mettre les configurations correspondantes dans, typiquement, /usr/local/etc/cryptshot/[domicile/bureau].conf .
• Créer ses fichiers tout de suite avec les droits adéquats. Les remplir avec les variables du scrit, typiquement :

## indiquer la partition destinataire de la sauvegarde
UUID="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # pour la version originale du script
# PARTLABEL="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # pour ma version modifiée ...  
## Indiquer le fichier clé
KEYFILE="/chemin/votre fichier cle"  
## la base du point de montage
MOUNTROOT="/mnt/"
## option pour supprimer la trace du répertoire destinataire des sauvegardes à la fin du script
REMOVEMOUNT=1
## Indiquer la commande de sauvegarde. 
## On utilise ici un fichier de configuration spécifique par lieu de sauvegarde. ### En fait, seule la seule ligne qui doit obligatoirement changer est : snapshot_root /mnt/<target device>/rsnapshot/   
BACKUP="/usr/bin/rsnapshot -c /usr/local/etc/rsnapshot/domicile.conf"  

• Tester dans un terminal en utilisant le format de commande que l’on retrouvera plus tard dans le script. -c désigne le fichier de configuration avec les variables à utiliser (qui vont surcharger celles inscrites dans le script) . -i sera la variable passée à rsnapshot (ici Daily pour la sauvegarde quotidienne) /usr/local/bin/cryptshot.sh -c /usr/local/etc/cryptshot/domicile.conf -i daily
• Il y a différents paramètres à définir, et on peut avoir à tester la configuration quelques fois ; mes deux astuces
  • mettre set -x en début de script afin de voir les commandes qui passent quand on lance le script en console (retirer ensuite)
  • Cryptshot se lance avec le paramètre -i, l’argument est ensuite passé à rsanpshot. Pour les sauvegardes quotidienne on fera : -i daily pour les tests on pourra mettre -i configtest ou "-i -t daily" et regarder ce que le script renvoie dans la console.
  • Quand cette commande produit effectivement une sauvegarde adéquate sur disque USB, gardez là, et poursuivez la mise en place des autres scripts

Backiptup sera appelé par le script suivant et lancera le script précédent si sauvegarde mérite de tourner : si elle date de plus que le délai indiqué comme souhaitable.
Dans mon cas ces délais sont ceux de mon rsnapshot : daily, weekly et monthly

Tester dans un terminal en utilisant le format de commande que l’on retrouvera dans le script suivant :

  /usr/local/bin/backitup.sh -q -l /usr/local/etc/cryptshot/lastrun/domicile.daily -b "/usr/local/bin/cryptshot-domicile.sh -c /usr/local/etc/cryptshot/domicile.conf -i daily" -p DAILY

• -q demande “quiet” au script
  

• -l indique le fichier ou les dates des dernières sauvegardes sont enregistrés. Créer ce (ces, dans le script suivant nous verrons que nous en avons besoin de six) fichier(s) en faisant toujours attention aux droits.
• -p indique la fréquence souhaitée pour cette sauvegarde
• Quand cette commande produit effectivement une nouvelle sauvegarde quotidienne adéquate, gardez là, et poursuivez la mise en place des derniers scripts

• Créer le script adéquat ici dans /etc/cron.hourly/cryptshot-execute (avec droit d’exécution)
• Le remplir avec :

#!/bin/bash
## Pour voir le déroulement du script en console :
# set -x
## domicile
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/domicile.monthly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/domicile.conf -i monthly" -p MONTHLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/domicile.weekly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/domicile.conf -i weekly" -p WEEKLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/domicile.daily -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/domicile.conf -i daily" -p DAILY
## bureau
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bureau.monthly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bureau.conf -i monthly" -p MONTHLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bureau.weekly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bureau.conf -i weekly" -p WEEKLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bureau.daily -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bureau.conf -i daily" -p DAILY

Créer les fichiers correspondants dans /usr/local/etc/cryptshot/lastrun/

Pour répéter les tests il faudra probablement enlever (ou remplacer par 000) les fichiers daily du répertoire précédent.

Pour forcer la sauvegarde quotidienne, même si elle a déjà été faite plus tôt dans la journée … Créer (encore) un script : /usr/local/bin/force-cryptshop.sh et le remplir avec :

#!/bin/bash
## Pour voir le déroulement du script en console :
# set -x
 
echo '000' > /usr/local/etc/cryptshot/lastrun/domicile.daily
echo '000' > /usr/local/etc/cryptshot/lastrun/bureau.daily

/etc/cron.hourly/cryptshot-execute

On pourra l’appeler en ligne de commande, en phase de tests, et pour sauvegarder les derniers travaux de la journée juste avant de quitter le lieu correspondant.

Cela passe par la création d’une règle udev personnalisée. La règle simple ci dessous détectera toute nouvelle connexion sur un port usb, puis lancera le script de sauvegarde. Si le périphérique connecté est un des disques usb prévu pour la sauvegarde, elle aura lieu ; sinon le script ne trouvera rien a faire.

• Créer le fichier /etc/udev/rules.d/10-custom.rules en tant que root
• le peupler avec
  

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", RUN+="/etc/cron.hourly/cryptshot-execute"

• Redémarrer ou recharger les règles udev, puis "déclencher" (la redétection?) en utilisant la commande suivante :

sudo udevadm control --reload-rules && sudo udevadm trigger

• Tester en connectant un des disques de sauvegarde

Le fonctionnement peut être capricieux quand le disque est connecté au travers d'un hub thunderbolt. Connecter le disque directement sur un port USB de l'ordinateur.

Faire et automatiser des sauvegardes, c’est bien ; il faut aussi pouvoir les utiliser. Lorsque le disque USB est connecté, il apparait comme pouvant être moté dans l’espace utilisateur. Il faudra saisir le mot de passe pour l’ouvrir. Tout cela est bien, et nous permettra de consulter nos sauvegardes de n’importe quelle machine (non testé sous Windows ni MacOS); Sauf que …

Cela fout le bordel sur la machine qui fait les sauvegardes. - Lorsque l’on ouvre le volume en tant qu’utilisateur (typiquement dans /media/user/monvolume) le script cryptshot s’arrête en erreur. Le développeur me dit que ce serait trop insécure de permettre simultanément les accès utilisateur et l’ouverture pour une sauvegarde en cours, elle attendra le prochain hourly.
Lorsque l’on “détache” le disque USB, il n’apparait plus comme détecté par le system (les fichiers correspondants sous /dev/disk/*/… ne sont plus présents), alors le script ne peut plus tourner les sauvegardes non plus.

- Une solution est de déconnecter/reconnecter le disque USB. A défaut d’y penser, on pourrait se retrouver sans sauvegardes pendant quelques jour…

- Faire un (autre) script /usr/local/bin/Back-domicile-mount-sh avec :

#!/bin/bash
mkdir /mnt/Monvolume
cryptsetup luksOpen --key-file /chemin/de/la/cle.whatever /dev/disk/by-partlabel/Monvolume crypt-Monvolume
mount --options noatime /dev/mapper/crypt-Monvolume /mnt/Monvolume
read -p " $volume est monté, visiter /mnt puis appuyez sur Enter pour tout refermer"
umount /mnt/Monvolume
rmdir /mnt/monvolume
cryptsetup luksClose crypt-Monvolume

Toujours lancer en root, par sudo. Cette ouverture et ce montage ne “détache” pas le disque, et le script reste fonctionnel. Le risque est d'oublier la fenêtre de la console avec la fermeture du montage non faite.

- proposition par l’auteur du script dans les “issues” Continue the script when the volume is already luksOpened ? · Issue #8 · pigmonkey/cryptshot · GitHub - non testé

if [ -d /mnt/backupdrive ]; then
    rsnapshot -c /path/to/rsnapshot.conf daily
else
    cryptshot.sh -c /path/to/cryptshot.conf -i daily
fi

Il est prudent, dès lors qu'on utilise un ordinateur portable, de gérer ses sauvegardes, à plusieurs endroits et de façon chiffrée.

Merci aux auteurs et contributeurs rsnapshot, des scripts cryptshot et backitup pigmonkey pour leur patience et leur soutien. Les autres scripts proposés ici ont largement été inspirés par ces échanges.

sudo

rsnapshot

cryptsetup

GitHub - pigmonkey/cryptshot: Open and mount a LUKS volume before performing a backup with rsnaphot

GitHub - pigmonkey/backitup: Execute a user-specified command if a certain amount of time has passed.

FrequentlyAskedQuestions · Wiki · cryptsetup / cryptsetup · GitLab

10 Linux cryptsetup Examples for LUKS Key Management (How to Add, Remove, Change, Reset LUKS encryption Key)

Créer et utiliser une partition chiffrée avec LUKS sous Linux | Valérian REITHINGER

Comment utiliser Udev pour la détection et la gestion des périphériques sous Linux

Quoi sauvegarder
Sauvegarde (informatique)

sauvegarde

tutoriel sauvegarder son “home”

Incron, comme alternative à Udev (non testé)

Incron

Incron : exécuter des actions selon des événements | Commandes et Système | IT-Connect

Contributeurs principaux : LIVIER.