Bonjour,
Pour des raisons professionnelles, je vais beaucoup me déplacer les années qui viennent avec mon ordinateur portable. C'est pourquoi je voudrais remettre à plat la gestion de mon système informatique, pour être paré en cas de casse ou de vol de mon ordinateur.
J'utilise actuellement Linux Mint sur mon ordinateur portable, qui contient un petit SSD pour / et un disque dur 500Go pour /home. Quel est le meilleur moyen d'avoir ses données personnelles en sécurité en cas de vol? Est ce que lors de l'installation, cocher «chiffrer mon dossier personnel» est suffisant? Comment ça se passe lors d'une réinstallation, pour conserver le /home? Est-ce mieux de partitionner avec LVM, et utiliser Btrfs, plutôt qu'au format MBR avec Ext4?
J'ai un peu cherché de mon coté, j'ai surtout vu de la documentation pour faire une telle configuration à la main, et ça a l'air un peu compliqué. Il faut faire attention à ce que des informations ne fuitent pas dans la partie système qui n'est pas chiffrée (swap, syslog…). Je ne sais pas si c'est une conne idée de chiffrer le système entier (problèmes de performances? stabilité?). j'ai lu que le chiffrement en mode «bloc» pouvait user prématurément un SSD, car il ne serait plus capable de répartir les écritures sur sa surface, mais je pense que cette répartition se fait à un plus bas niveau…
Pour les sauvegardes, quelles solutions me conseillez-vous? J'ai toujours fait des sauvegardes occasionnelles à la main (avec cp ou rsync). Déja-Dup a l'air pas mal, mais j'ai aussi entendu parler de Borg… Je voudrais héberger les sauvegardes chiffrées sur un serveur Debian à la maison, sur lequel je configurerai également un serveur VPN.
Question subsidiaire: sur mon serveur, je pense également mettre des données en partage (comme un NAS). Cependant je ne suis pas fan de laisser des données en accès libre sur mon réseau. J'ai l'habitude de passer par sshfs pour transférer des données, mais les performances ne sont pas très bonnes… Est ce que Samba permet de chiffrer les données qui transitent sur le réseau (en plus de l'authentification)? Ou peut être devrais-je monter un partage Samba avec une surcouche ecryptfs?
Je ne suis pas très à l'aise avec le chiffrement, ayant un peu peur de ne pas réussir à me servir des sauvegardes quand j'en aurai besoin…
# Chiffrement du FS complet
Posté par Cyril Brulebois (site web personnel) . Évalué à 4.
Hello,
Je vais répondre principalement sur la partie chiffrement du FS : Chiffrer les données personnelles uniquement ne me semble pas suffisant.
Côté Debian, l'installateur propose de chiffrer l'intégralité du système, avec un partitionnement automatique s'appuyant sur LVM. Cela apporte une assez grande flexibilité pour personnaliser les points de montage/partitions une fois le système installé. Note : Pour le moment, la partie
/bootn'est pas chiffrée.Je n'ai pas vu de problème particulier avec le chiffrement sur SSD, alors que j'utilise cela sur tous mes laptops depuis 10+ ans.
Maintenant, je ne connais pas trop les spécificités des installateurs Ubuntu/Linux Mint, mais c'est normalement full disk encryption que j'aurais tendance à chercher dans la doc. Mais j'ai l'impression que ça n'est pas forcément trivial à obtenir :
Bonne continuation dans la recherche d'informations,
Cyril.
Debian Consultant @ DEBAMAX
[^] # Re: Chiffrement du FS complet
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Comme toi. Il faut tout chiffrer sauf /boot. Sous Debian, cela ne pose aucun soucis et pour le moment, on monte en version assez facilement (si second disque, parfois on change un truc dans la procédure de boot).
[^] # Re: Chiffrement du FS complet
Posté par ted (site web personnel) . Évalué à 1.
Niveau perf, est ce que ça se ressent? Le mot de passe est donc à entrer depuis Grub? Et si je veux réinstaller, je peux conserver la clé de chiffrement (ne pas formater mon home)?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Chiffrement du FS complet
Posté par Sytoka Modon (site web personnel) . Évalué à 2. Dernière modification le 30 juin 2018 à 10:50.
Franchement, entre les anciens disques à plateau et les SSH qu'on chiffre, je préfère un poste chiffré. De toute manière, la question ne se pose plus en terme de perf. C'est un portable (ou un ordinateur de bureau) professionnel -> chiffré !
Pour la ré-installation, tu peux toujours récupérer le HOME avant réinstallation. À vrai dire, je ne me souviens plus bien comment on fait. On ne réinstalle pas souvent. Mais on garde toujours une clef de recouvrement.
Et sinon oui, le /boot étant en clair, on donne une phrase de passe (et non un mot de passe) depuis grub.
[^] # Re: Chiffrement du FS complet
Posté par Cyril Brulebois (site web personnel) . Évalué à 1. Dernière modification le 30 juin 2018 à 18:11.
Non non, on n'a pas encore l'intégration dans grub, c'est donc depuis l'initramfs que la phrase de passe est demandée.
(Désolé, j'avais tapé mais pas validé validé ma réponse un peu plus complète, qui se retrouve donc après ton commentaire.)
Pour en savoir plus là-dessus, chercher le mot-clé cryptodisk. Un jour quelqu'un travaillera sur l'intégration de ce genre de choses…
Debian Consultant @ DEBAMAX
[^] # Re: Chiffrement du FS complet
Posté par Sytoka Modon (site web personnel) . Évalué à 2. Dernière modification le 30 juin 2018 à 20:52.
Oui, bien sur, l'initramfs ;-)
[^] # Re: Chiffrement du FS complet
Posté par Cyril Brulebois (site web personnel) . Évalué à 1.
Il y a quelques années (vers 2008-2009), sur des core 2 duo, on pouvait voir des différences avec/sans chiffrement. Je crois me souvenir de certains avançant des chiffres de l'ordre de 5 à 10 % de baisse de perf. J'avoue ne m'être pas trop posé la question de mesurer cela, les garanties apportées par le chiffrement me semblant bien plus importantes que d'éventuelles baisses de perf. Vu les SSD et les CPU qu'on a maintenant, ça me semble avoir encore plus gommé ce genre de différences.
Non, en l'état actuel des choses dans Debian, grub ne pose pas la question de la phrase de passe (on peut en définir plusieurs, au passage), c'est le composant cryptsetup embarqué dans l'initramfs (l'archive qui contient scripts, binaires, bibliothèques, modules, etc. aidant à démarrer) qui se charge de cela pour déverrouiller les périphériques de type bloc.
Je ne peux pas trop t'en dire plus pour la partie réinstallation. Je ne réinstalle jamais un système, donc je ne sais pas trop comment peut fonctionner la réutilisation d'un volume chiffré dans tel ou tel système d'installation.
Debian Consultant @ DEBAMAX
[^] # Re: Chiffrement du FS complet
Posté par Jean-Baptiste Faure . Évalué à 5.
Pourquoi ?
[^] # Re: Chiffrement du FS complet
Posté par Marc Quinton . Évalué à 2. Dernière modification le 29 juin 2018 à 18:36.
ha ben oui, et pourquoi ? plutot d'accord avec toi ; une allégation sans fondement scientifique ou technique ne vaut rien.
[^] # Re: Chiffrement du FS complet
Posté par Fabien (site web personnel) . Évalué à 1.
Peut être parce que l'on peut modifier ton système à ton insu.
La condition étant que l'attaquant puisse "t'emprunter" ton matériel discrètement, il reste intéressant de ne chiffrer que le /home pour protéger les données persos d'un vol matériel par exemple.
Pour une meilleure protection, il faut tout chiffrer, /boot y compris.
Il me semble que j'ai eu un Linux totalement chiffré, en dual boot avec un Windows.
Je faisais un rsync du /boot sur une clef USB et y installais grub.
Pour démarrer Linux, il suffisait de connecter la clef et de changer l'ordre du boot (je pouvais le faire sans modifier le bios).
Sans clef USB, l'ordi bootait sur Windows.
PS: pour la méthode du full encrypted, il faut prévoir une méthode de secours en cas de perte/dégradation/… de la clef USB.
Sauvegarder quelque part les mdp/clef de la/les partitions chiffrées quelque part semble un bon point de départ.
[^] # Re: Chiffrement du FS complet
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il y a plein de tmp a droite et à gauche avec des données dedans. Il y a /etc avec aussi des données sensibles…
Bref, cela ne coûte rien de tout chiffrer.
# Pratiquer
Posté par _kaos_ . Évalué à 6.
Salut,
Je rebondis sur un point
Il ne faut pas attendre d'en avoir besoin pour se servir des sauvegardes, il faut "simuler" une panne et s'en servir régulièrement.
C'est le meilleur moyen d'être :
Bien évidemment, ça prend un peu de temps, mais c'est pour la bonne cause ;)
Matricule 23415
# backup avec restic + rest-server
Posté par Marc Quinton . Évalué à 2.
pour ma part, j'ai expérimenté un service de backup, différentiel par block basé sur restic et coté serveur : restic-server sur un apache + let's encrypt.
dans le cadre d'une grande mobilité, ca me semble pas mal. A chacun de voir. Les données sont chiffrées sur le serveur. Via https+let's encrypt, accessible de partout, quand on a internet. Le fonctionnement en différentiel par bloc avec réduplication permet des perfos intéressantes, même avec des fichiers qui grossissent doucement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.