Comment puis-je être sûr qu'un répertoire ou un fichier est réellement supprimé?


14

Je sais que la plupart des fichiers, lorsqu'ils sont supprimés, ne sont pas réellement supprimés du disque et peuvent être récupérés plus tard.

Comment puis-je m'assurer qu'un répertoire que j'avais supprimé sera réellement supprimé du disque? Existe-t-il des utilitaires pour cela?

J'utilise Debian Linux.


5
La réponse courte: vous ne pouvez pas! La réponse longue: détruisez physiquement le disque ou reformulez la question: combien d'efforts faudrait-il pour récupérer les données et quel serait le taux de réussite d'une telle tentative?
Marco

Réponses:


11

Chiffrez les données avant de les stocker. Pour effacer les données, essuyez la clé.

Si vous avez déjà écrit les données en texte brut, il est trop tard pour les effacer de manière simple. Il peut y avoir plusieurs copies des données qui traînent à divers endroits:

  • sur le système de fichiers si le fichier a été écrit plusieurs fois (écrasé ou remplacé);
  • sur le système de fichiers s'il a été réorganisé dans le cadre de la défragmentation;
  • dans le journal (cela devrait disparaître assez rapidement après la dernière écriture des données);
  • dans les sauvegardes;
  • dans les secteurs handicapés (en particulier sur SSD).

Pour se débarrasser des copies des données sur le système de fichiers, une méthode grossière consiste à remplir l'espace libre ( cat /dev/zero >somefileet à attendre qu'il s'arrête car le système de fichiers est plein). Cela écrasera tous les blocs complets.

De petites parties des données peuvent rester dans des blocs incomplets qui sont partiellement utilisés par d'autres fichiers. C'est particulièrement une préoccupation pour les noms de fichiers, qui peuvent rester dans des blocs qui stockent le contenu du répertoire. Pour vous débarrasser de tout, sauvegardez tous les fichiers, écrasez complètement le périphérique contenant le système de fichiers, puis restaurez les fichiers.

Les supports de stockage peuvent conserver des données dans des blocs qui ne sont plus utilisés. Sur les disques durs, cela signifie des blocs défectueux qui ont été réalloués; c'est un événement assez rare jusqu'à ce que le disque commence à s'user. Sur SSD, c'est un phénomène courant en raison du nivellement de l'usure. Dans les deux cas, la menace est très faible, car l'accès à ces données nécessite un attaquant quelque peu sophistiqué avec du matériel modérément cher et du temps à perdre. Si vous vous souciez de ces menaces, cryptez vos données et ne laissez pas votre clé traîner.

Notez que vous pouvez voir des conseils sur l'effacement des données en effectuant plusieurs passes ou en utilisant des données aléatoires au lieu de zéros («Gutmann wipe»). Oubliez cela: cela ne s'applique qu'aux disques durs des années 80 (et même alors, les données ne sont pas si bon marché à reconstruire et la reconstruction est plutôt peu fiable). L'écrasement avec des zéros est assez bon; faire plusieurs passes aléatoires est un conseil obsolète ou de l'huile de serpent. Voir Pourquoi l'écriture de zéros (ou de données aléatoires) sur un disque dur plusieurs fois est-elle meilleure que de le faire une seule fois?


12

Il existe un outil très populaire appelé shred. Il écrasera chaque fichier 25 fois avant d'être supprimé. C'est peut-être ce que vous cherchez.

L'utilisation de shred est assez simple

$ shred secret_archive.tar.gz

Notez cependant que sur les systèmes modernes, cela shredpeut être inefficace ou inutile si:

  • Vos programmes créent des fichiers temporaires que vous ne connaissez pas (comme beaucoup d'applications GUI)
  • Votre FS est basé sur la copie sur écriture (comme ZFS ou Btrfs)
  • Votre FS est basé sur le journal (comme NILFS)
  • Votre FS utilise la journalisation des données (comme JFS, ReiserFS, XFS, ext3 ou ext4 dans certaines configurations)
  • Votre FS utilise la compression
  • Votre FS alloue de nouvelles versions de fichiers à différents emplacements
  • Vous avez des instantanés ou des sauvegardes
  • Vous êtes sur un réseau FS
  • Vous utilisez un SSD avec des algorithmes de nivellement d'usure

D'autres options potentiellement plus sûres sont:

  • Chiffrement des données critiques
  • Écraser la partition entière ou le périphérique de stockage
  • Destruction physique de l'appareil

1
Selon ma page de manuel, cela shredfonctionne même avec ext3 (et je suppose que ext4 aussi) lors de l'utilisation des modes data = commandé (par défaut) et data = écriture différée . De plus, il existe une alternative simple: il suffit de créer un énorme fichier occupant tout l'espace restant du système de fichiers afin que votre fichier supprimé soit écrasé.
scai

Merci. Je viens de le réparer. journaling -> data jornaling
taffer

@scai, la méthode des fichiers volumineux ne fonctionnera pas nécessairement car les blocs du fichier ont peut-être déjà été réalloués et pas encore écrits (comme les données déchues, le dernier bloc de fichiers ou les répertoires ...)
Stéphane Chazelas

3
shredest l'huile de serpent: ce n'est pas mieux que head -c $(wc -c secret_archive.tar.gz)>! secret_archive.tar.gz`. L'utilisation de shred est toujours inutile, sauf si vous utilisez un disque dur des années 1980 ou du début des années 1990.
Gilles 'SO- arrête d'être méchant'

3
shred / bcwipe / etc. sont de l'huile de serpent au niveau du système de fichiers. Pour tout système de fichiers. En raison de la façon dont vous travaillez avec les fichiers: chaque fois que vous cliquez sur enregistrer, l'ancien fichier est supprimé (réside dans l'espace libre) et un nouveau fichier est créé. Vous ne pouvez pas le détruire si le système de fichiers l'a déjà oublié. - C'est différent au niveau de l'appareil ou au niveau de l'espace libre tout en écrasant. Shred est l'une des rares sources de données aléatoires rapides disponibles sous Linux / Unix. / dev / (u) aléatoire, il est sacrément lent pour être utilisable pour écraser de grandes quantités de données. - Donc, une seule passe de déchiquetage est OK pour l'appareil ou l'espace libre, mais pas pour un seul fichier
frostschutz
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.