Cloner un disque dur sous Ubuntu

aryliin

04 novembre 2019

Que ce soit suite à l'achat d'un nouveau disque, dans le but de faire une sauvegarde, ou pour tout autre raison, vous souhaitez copier à l'identique le contenu d'un disque dur ou d'une clef USB. Mais, comme on n'est jamais trop prudent, le mieux est de s'assurer de ne rien toucher à l'original. On vous montre comment faire avec Ubuntu.

Lors d’une expertise, lorsque nous devons mener une investigation sur une pièce d’un dossier, il est important de la conserver intacte.

Imaginez-vous… Vous ouvrez votre scellé, vous branchez le disque dur qui était dedans. Une fausse manipulation, et hop ! L’intégralité des pièces à conviction se retrouvent effacées ou écrasées.

Avant toute action, il est donc indispensable de copier les disques durs et autres clés USB, afin de pouvoir travailler sur ces copies l’esprit tranquille.

Nous allons vous montrer comment vous y prendre en utilisant Ubuntu.

Disque dur

Disque dur

Désactiver montage automatique

⚠️ Ne branchez votre disque tout de suite !

Comme le but est de toucher le moins possible à l’original, la première chose à faire est de désactiver le montage automatique. Cela évitera de modifier quoique ce soit sur le support.

Pour cela, on a besoin d’installer le paquet dconf-editor

sudo apt-get install dconf-editor

Lancer ensuite dconf-editor. Naviguez jusqu’à org.gnome.desktop.media-handling. De là, vous pouvez désactiver le montage automatique des media amovibles, en passant automount de I à O.

configuration via dconf-editor

configuration via dconf-editor

Repérer son disque

Vous êtes à présent sûr que votre disque ne va pas se monter tout seul, et qu’une mauvaise manipulation ne va pas pouvoir modifier quoique ce soit dessus. Vous pouvez donc brancher votre disque.

Éteignez votre PC, branchez votre disque, redémarrez.

Vous allez devoir repérer à quel périphérique correspond votre disque. Pour cela, on utilisefdisk1.

sudo fdisk -l

Les disques dur SATA et SSD sont dansdev/sd…, les disques IDE /dev/hd…. Servez-vous de vos connaissances sur votre disque dur pour le retrouver (en utilisant sa taille, l’OS installé…).

Par exemple : je cherche à repérer une clef USB de 32Go contenant mes données à investiguer…

Après avoir faire un fdisk, je repère deux périphériques intéressants, l’un dans /dev/sdaet l’autre dans dev/sdb. En observant les détails, je peux me rendre compte que le disque dur SSD de 240Go sur lequel tourne mon linux se trouve dans /dev/sda et que ma clef USB qui fait 32Gb se trouve dans /dev/sdb

On remarque en passant l‘affichage en Gibibytes2.

Disque /dev/sda : 223,6 GiB, 240057409536 octets, 468862128 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : ----

Périphérique Amorçage Début       Fin  Secteurs Taille Id Type
/dev/sda1    *         2048 468860927 468858880 223,6G 83 Linux

Disque /dev/sdb : 29,3 GiB, 31457280000 octets, 61440000 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : ----

Périphérique Amorçage Début      Fin Secteurs Taille Id Type
/dev/sdb1    *           64 61439999 61439936  29,3G  b W95 FAT32

Calculer la somme de contrôle

Afin de pouvoir vérifier si des données ont été modifiée, on va tout d’abord calculer la somme de contrôle3 du périphérique. La comparaison entre la somme de contrôle avant et après manipulation permettra de déterminer si des données ont été altérées.

Dans le Référentiel Général de Sécurité, on nous dit que si on doit utiliser une fonction de hachage, il faut que son empreinte soit de 200bits (puisqu’on est avant 2020). Mais comme chez les arsouyes, on est en avance sur notre temps, on utilise la recommandations pour après 2020, c’est à dire 256 bits4.

Toujours dans le RGS, SHA-256 est recommandée… Donc c’est cette fonction que l’on va utiliser. Ce qui tombe bien, car sur Ubuntu, sha256 est installé par défaut. On peut l’utiliser pour faire l’empreinte d’un périphérique en le couplant à dd5.

En mettant en entrée (if) votre périphérique et en envoyant la sortie sur sha256sum, on obtient l’empreinte SHA-256 du périphérique.

time sudo dd if=/dev/sdb |sha256sum 
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1773,13 s, 17,7 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655  -

real    29m33,203s
user    12m44,728s
sys 4m15,840s

En utilisant time, on peut se rendre compte que pour calculer l’empreinte de ma clef de 32Go, il a fallu 30 minutes environ. Bon à savoir lorsque l’on a un disque de 1To.

Copier le disque

On a branché le périphérique, en s’assurant qu’on ne pouvait pas faire de bêtises, on a fait une empreinte, il ne nous reste plus qu’à le cloner.

Pour cela, on utilise encore une fois dd.

On va utiliser la commande suivante :

sudo dd if=device of=fichier.iso conv=notrunc,noerror status=progress

où

```bash time sudo dd if=/dev/sdb of=clef.iso conv=notrunc,noerror status=progress 31444406272 bytes (31 GB, 29 GiB) copied, 1981 s, 15,9 MB/s 61440000+0 enregistrements lus 61440000+0 enregistrements écrits 31457280000 bytes (31 GB, 29 GiB) copied, 1981,74 s, 15,9 MB/s

real 33m4,898s user 1m36,367s sys 11m27,615s ```

Notez que ça m’a pris encore une demie heure…

Vérifier l’intégrité

Notre copie est faite, nous allons effectuer une nouvelle empreinte du périphérique, afin de vérifier que celui-ci n’a pas été altéré pendant la copie. Profitons-en également pour vérifier que la copie est bien conforme à l’originale.

On refait l’empreinte du périphérique. Même commande que tout à l’heure :

time sudo dd if=/dev/sdb |sha256sum 
[sudo] Mot de passe de arsouyes : 
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1755,58 s, 17,9 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655  -

real    29m18,712s
user    10m34,172s
sys 3m37,959s

Puis, on fait le SHA 256 de l‘iso (pour vérifier que la copie est bien conforme à l’original):

time sudo dd if=clef.iso |sha256sum
[sudo] Mot de passe de arsouyes : 
61440000+0 enregistrements lus
61440000+0 enregistrements écrits
31457280000 bytes (31 GB, 29 GiB) copied, 1111,31 s, 28,3 MB/s
e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655  -

real    18m34,487s
user    10m2,526s
sys 3m56,255s

Et enfin on compare les empreintes :

disque initial : e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655

copie iso : e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655

disque après copie : e3375bb22d59233757cbcb24d7f4ffa7b25eaff40e60e40f42f3a22435bf2655

Et bingo, les empreintes sont bien identiques. Une donnée altérée serait détectée par un sha256 différent. Si le SHA256 de votre copie iso est différent de celui de votre disque initial, je vous conseil de refaire la copie. Si le SHA256 de votre disque après copie est différent de celui avant copie, pas de bol, votre disque a été altéré, et il n’y a pas grand chose à faire, si ce n’est, se dire qu’on a bien fait de faire une copie de sauvegarde.

Vous pouvez aussi mettre l’empreinte initiale dans un fichier (par exemple Initial_CHECKSUM) et lancer l’empreinte de votre copie iso avec l’option -c

sudo dd if=device | sha256sum -c Initial_CHECKSUM

où device est soit votre fichier iso, soit votre périphérique (en fonction de ce que vous voulez faire).

Si l’empreinte est la même, vous aurez un joli petit OKen sortie, mais si l’empreinte diffère, vous obtiendrez un FAILED suivit de sha256sum: WARNING: 1 computed checksum did NOT match.

Et après

Maintenant que vous avez une copie toute belle de votre périphérique, vous allez pouvoir replacer votre original dans son petit sachet et refermer votre scellé.

Si vous n’êtes pas expert judiciaire et que vous n’avez pas à gérer de scellés, vous pouvez quand même être fier de ne rien avoir modifié sur votre disque original.

Backup de données chez OVH avec duplicity

11 février 2019 Il serait dommage de perdre nos données personnelles. Grâce aux serveurs de OVH et à duplicity, il est facile de mettre en place un système de sauvegarde automatique.

Récupération des données sauvegardées chez OVH avec duplicity

18 mars 2019 Les commandes utiles pour lister et récupérer ses fichers une fois que l'on a sauvegardé ses données dans le Public Cloud OVH avec duplicity.

Backup de dépôt gitlab

4 mars 2019 Afin de sauvegarder ses dépôts gitlab, il peut être utile de faire un miroir de son dépôt afin de conserver sur un serveur distant ses fichiers, mais également toutes les modifications

  1. https://doc.ubuntu-fr.org/fdisk↩

  2. https://en.wikipedia.org/wiki/Gibibyte↩

  3. https://fr.wikipedia.org/wiki/Somme_de_contr%C3%B4le↩

  4. Règle HASH-2 du RGS (https://www.ssi.gouv.fr/uploads/2015/01/RGS_v-2-0_B1.pdf)↩

  5. https://doc.ubuntu-fr.org/dd.↩