Question Comment effacer l'espace disque libre sous Linux?


Lorsqu'un fichier est supprimé, son contenu peut toujours être laissé dans le système de fichiers, sauf s'il est explicitement remplacé par quelque chose. le wipe commande peut effacer des fichiers en toute sécurité, mais ne semble pas permettre d'effacer l'espace disque non utilisé par aucun fichier.

Que dois-je utiliser pour y parvenir?


130
2017-08-06 23:48


origine


La seule solution sûre peut être d'enregistrer vos fichiers ailleurs, d'effacer toute la partition, de recréer le système de fichiers, puis de restaurer vos fichiers. J'ai couru photorec et a été choqué par combien de choses pourraient être récupérées même après avoir «effacé» l'espace libre. Une solution de compromis consiste à déplacer la limite gauche de votre partition de 6% de sa taille après avoir effacé l’espace apparemment libre. - user39559


Réponses:


Attention: Le matériel disque / SSD moderne et les systèmes de fichiers modernes peuvent stocker des données dans des endroits où vous ne pouvez pas les supprimer. Ce processus peut donc laisser des données sur le disque. Les seules méthodes sûres pour effacer les données sont la commande ATA Secure Erase (si elle est correctement implémentée) ou la destruction physique. Regarde aussi Comment puis-je effacer de manière fiable toutes les informations sur un disque dur?


99
2017-08-07 01:55



Il est difficile de localiser la page d'accueil "officielle" actuelle de secure-delete. Une version peut-être plus ancienne prétend qu'il n'y a pas de rapport de bogue, mais en même temps, il n'y a pas de système de suivi de bogue ouvert où je pourrais signaler un bogue que j'ai trouvé. La page d’accueil sécurisée-supprimer indique également qu’elle peut ne pas effacer tous les blocs de données inutilisés, en fonction du système de fichiers que vous utilisez, ce qui est vrai. - user39559
Avec les disques durs modernes (plus gros que 20 Go environ), il est totalement inutile d'effectuer plusieurs passes et d'attendre longtemps. Ainsi, l’installation d’outils spécialisés est également devenue inutile (ce qui peut expliquer pourquoi la méthode de suppression sécurisée n’a plus de page d’accueil). Faites-le simplement depuis la partition appropriée: cat /dev/zero >nosuchfile; rm nosuchfile. - mivk
@mivk: Pourquoi est-il inutile de faire plus d'un passage? Et pourquoi utiliser / dev / zero au lieu de / dev / random? Est-ce dû à des problèmes de vitesse? - naught101
Utiliser / dev / zero est beaucoup plus rapide. Si vous écrivez de l'espace libre à partir de / dev / random, le noyau doit générer toutes ces données aléatoires à la volée. C'est une façon amusante de regarder votre charge moyenne sauter au maximum ... - dafydd
La question de savoir si plusieurs lingettes sont nécessaires répond ici: Pourquoi écrire des zéros (ou des données aléatoires) sur un disque dur plusieurs fois mieux que de le faire une seule fois? - sleske


Le moyen le plus rapide, si vous n'avez besoin que d'un seul passage et que vous souhaitez simplement tout remplacer par des zéros, est:

cat /dev/zero > zero.file
sync
rm zero.file

(exécuté depuis un répertoire sur le système de fichiers que vous voulez effacer)
(la sync commande est une mesure de paranoïa qui garantit que toutes les données sont écrites sur le disque - un gestionnaire de cache intelligent peut trouver qu'il peut annuler les écritures pour tous les blocs en attente lorsque le fichier est dissocié)

Il y aura un moment pendant cette opération où il n'y aura plus d'espace libre sur le système de fichiers, ce qui peut prendre des dizaines de secondes si le fichier résultant est volumineux et fragmenté. Pour réduire le temps où l’espace libre est totalement nul:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file

Cela devrait suffire à empêcher quelqu'un de lire l'ancien contenu du fichier sans faire appel à une expertise judiciaire coûteuse. Pour une variante légèrement plus sûre, mais plus lente, remplacer /dev/zero avec /dev/urandom. Pour plus de paranoïa, exécutez plusieurs étapes avec /dev/urandom, mais si vous avez besoin de beaucoup d'efforts, le shred utilitaire du paquet coreutils est la voie à suivre:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file

Notez que dans ce qui précède, le petit fichier est déchiqueté avant de créer le plus grand, donc il peut être supprimé dès que le plus grand est terminé au lieu d'attendre qu'il soit déchiqueté, laissant le système de fichiers sans espace disponible. Le processus de déchiquetage avec prendre longue temps sur un gros fichier et à moins que vous essayez de cacher quelque chose de la NSA n'est pas vraiment nécessaire IMO.

Tout ce qui précède devrait fonctionner sur n'importe quel système de fichiers.

Limites de taille de fichier:

Comme le souligne DanMoulding dans un commentaire ci-dessous, cela peut poser des problèmes de taille de fichier sur certains systèmes de fichiers.

Pour FAT32 ce serait absolument être une préoccupation en raison de la limite de fichier 2GiB: la plupart des volumes sont plus grands que ceux-ci de nos jours (8TiB est la limite de taille de volume IIRC). Vous pouvez contourner ce problème en canalisant le grand cat /dev/zero sortie sortie par split pour générer plusieurs fichiers plus petits et ajuster les étapes de destruction et de suppression en conséquence.

Avec ext2 / 3/4, le problème est moins grave: avec le bloc 4K par défaut / commun, la limite de taille de fichier est 2TiB. énorme volume pour que cela soit un problème (la taille maximale du volume dans ces conditions est de 16 To).

Avec les btrfs (encore expérimentaux), la taille maximale des fichiers et des volumes est de 16EiB.

Sous NTFS, la longueur maximale du fichier est supérieure à la longueur maximale du volume dans certains cas.

Points de départ pour plus d'informations:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#Scalability

Périphériques Virtuels

Comme mentionné dans les commentaires récemment, il existe des considérations supplémentaires pour les périphériques virtuels:

  • Pour les disques virtuels à faible répartition, d'autres méthodes telles que celles utilisées par zerofree sera plus rapide (mais contrairement à cat et dd Ce n'est pas un outil standard sur lequel vous pouvez compter pour être disponible à peu près dans n'importe quel système d'exploitation unix).

  • Sachez que mettre à zéro un bloc sur un périphérique virtuel fragmenté peut ne pas effacer le bloc sur le sous-jacent physique device, en fait, j'irais même jusqu'à dire qu'il est peu probable que - le gestionnaire de disque virtuel ne fasse que rendre le bloc inutilisé afin qu'il puisse être attribué à autre chose plus tard.

  • Même pour les périphériques virtuels de taille fixe, vous ne pouvez pas contrôler où le périphérique vit physiquement pour pouvoir le déplacer à tout moment sur son emplacement actuel ou sur un nouvel ensemble de disques physiques. tous les emplacements précédents du bloc peuvent avoir résidé dans le passé.

  • Pour les problèmes ci-dessus sur les périphériques virtuels: à moins que vous ne contrôliez les hôtes et que vous ne puissiez effacer leur espace non alloué après avoir effacé les disques de la machine virtuelle ou déplacé le périphérique virtuel, vous ne pourrez plus rien faire après le fait. Le seul recours est d'utiliser le chiffrement intégral du disque dès le début Ainsi, rien de non crypté n'est écrit en premier lieu sur le support physique. Il peut toujours y avoir un appel pour un nettoyage de l'espace libre dans la VM, bien sûr. Notez également que FDE peut rendre les périphériques virtuels peu utiles, car la couche de virtualisation ne peut pas vraiment voir quels sont les blocs inutilisés. Si la couche de système de fichiers du système d'exploitation envoie des commandes de découpage au périphérique virtuel (comme s'il s'agissait d'un disque SSD) et que le contrôleur virtuel les interprète, cela peut résoudre ce problème. la discussion de cette question relève d’ailleurs (nous sommes déjà sur le point d’être hors sujet pour la question initiale, donc si cela a suscité votre intérêt, des questions d’expérimentation et / ou de suivi peuvent être en ordre).


65
2017-08-07 08:58



La simple réduction à zéro peut apparemment aussi se faire avec le secure-delete outils: utiliser sfill -llz réduit toute la procédure à une seule passe qui n'écrit que des "0". - foraidt
Cela prend du temps. Est-ce vraiment le moyen le plus rapide? J'imagine que l'écriture de données GB prendra toujours du temps ... - endolith
@endolith: si vous voulez vider l'espace libre sur un système de fichiers actif, vous ne pouvez pas contourner le besoin d'écrire autant de données via le système de fichiers. Les outils de suppression sécurisée proposés par fnord_ix peuvent être plus rapides, car ils sont optimisés pour ce type de tâche. - David Spillett
@endolith: à partir de la description de la page de manuel, je pense que la variante de zerofree n'est plus rapide que pour les disques virtuels faiblement alloués. pour confirmer que le bloc n'a pas de contenu. La montée en bulle pour un disque virtuel ne doit pas se produire non plus, car la plupart des pilotes de disques épars utilisent des zéros comme "ne pas allouer ce bloc". Aussi, cat et ddsont disponibles à peu près n'importe quel OS unix-like, car ils sont considérés comme des outils standard où zerofree n'est probablement pas sauf s'il a été explicitement ajouté. - David Spillett
@endolith: ayant dit ce qui précède, zerofree Cela fonctionnerait bien sûr, bien sûr, le "système de fichiers entier temporairement plein" chose mentionnée dans la page de manuel (presque mais pas tout à fait atténuée par le petit fichier Jiggery dans mes exemples) est une véritable préoccupation si vous faites cela sur un système actuellement actif, et zerofree serait en effet plus rapide dans l'instance spécifique pour laquelle il est optimisé: périphériques de blocs virtuels faiblement affectés. Bien que vous ne puissiez pas compter sur un effacement sur un périphérique virtuel à des fins de sécurité: la seule réponse vraie dans ce cas est le chiffrement intégral du périphérique dès le début. - David Spillett


ATTENTION

J'ai été choqué par le nombre de fichiers photorec pourrait récupérer de mon disque, même après avoir essuyé.

S'il y a plus de sécurité à remplir "l'espace libre" qu'une seule fois avec 0x00 ou 38 fois avec différentes normes cabalistiques, c'est plus une discussion académique. L’auteur du document de 1996 sur le déchiquetage a lui-même écrit épilogue en disant que cela est obsolète et inutile pour le matériel moderne. Il n'y a aucun cas documenté de données physiquement remplacées par des zéros et récupérées par la suite.

La vérité lien fragile dans cette procédure est la système de fichiers. Certains systèmes de fichiers réservent un espace pour une utilisation spéciale et ne sont pas disponibles sous forme d'espace libre. Mais vos données peuvent être là. Cela comprend des photos, des courriels personnels en clair, peu importe. Je viens de googler réservé + espace + ext4 et appris que 5% de mon home la partition était réservée. Je suppose que c'est là photorec trouvé tellement de mes affaires. Conclusion: la méthode de déchiquetage n'est pas la plus importante, même la méthode multi-passes laisse les données en place.

Tu peux essayer # tune2fs -m 0 /dev/sdn0 avant de le monter (Si ce sera la partition racine après le redémarrage, assurez-vous de l'exécuter -m 5 ou -m 1 après l'avoir démonté).

Mais encore, d’une manière ou d’une autre, il peut rester un peu de place.

Le seul moyen vraiment sûr consiste à effacer toute la partition, à créer à nouveau un système de fichiers, puis à restaurer vos fichiers à partir d'une sauvegarde.


Moyen rapide (recommandé)

Exécuter à partir d'un répertoire sur le système de fichiers que vous souhaitez effacer:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

Notes: le but du petit fichier est de réduire le temps où l’espace libre est complètement nul; le but de la synchronisation est de s'assurer que les données sont réellement écrites.

Cela devrait être suffisant pour la plupart des gens.

Manière lente (paranoïaque)

Il n'y a pas de cas documenté de données récupérées après le nettoyage ci-dessus. Cela serait coûteux et exigeant des ressources, si possible.

Cependant, si vous avez des raisons de penser que les agences secrètes dépenseraient beaucoup de ressources pour récupérer vos fichiers, cela devrait suffire:

dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file

Cela prend beaucoup plus de temps.

Attention. Si vous avez choisi la méthode paranoïaque, vous voudrez toujours faire le rapide, et ce n'est pas de la paranoïa. La présence de données purement aléatoires est facile et peu coûteuse à détecter, ce qui fait penser qu’il s’agit de données chiffrées. Vous pouvez mourir sous la torture pour ne pas avoir révélé la clé de déchiffrement.

Manière très lente (paranoïaque fou)

Même l'auteur de l'article de 1996 sur le déchiquetage a écrit un épilogue disant que cela était obsolète et inutile pour le matériel moderne.

Mais si vous avez encore beaucoup de temps libre et que cela ne vous dérange pas de gaspiller votre disque avec beaucoup de surcharge, le voici:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file

Remarque: cela équivaut essentiellement à utiliser l'outil de suppression sécurisée.


Avant le montage, cet article était une réécriture de David Spillett. La commande "cat" génère un message d'erreur, mais je ne peux pas écrire de commentaires sur les publications d'autres personnes.


39
2018-06-09 17:40



Vous pouvez commenter sous d'autres publications avec 50 points de réputation. - Gnoupi
le cat commande devrait donner une erreur "pas d'espace laissé" dans mes exemples, à la fin de son exécution. Vous pouvez cacher cela en redirigeant stderr vers /dev/null si c'est un problème. J'utilise habituellement pv plutôt que cat ou dd pour ce genre de chose, afin d'obtenir l'indication de progression utile. - David Spillett
...raises the suspicion that it is actually encrypted data. You may die under torture for not revealing the decryption key. Heh, c'est exactement ce que je pensais. Je suppose que cela signifie que je suis paranoïaque ... - Navin
/: write failed, filesystem is full sur FreeBSD - Alex G
La racine est toujours capable d'utiliser l'espace réservé. Donc, si vous faites votre remplissage zéro en tant que root, vous pourrez également remplir l'espace réservé de 5%; les tunefs sont inutiles. Il est encore concevable qu'il puisse y avoir des données dans d'autres parties du système de fichiers. - Nate Eldredge


Il y a un utilitaire ZeroFree au moins dans Ubuntu:

http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html

   zerofree — zero free blocks from ext2/3 file-systems

   zerofree  finds  the  unallocated, non-zeroed blocks in an ext2 or ext3
   filesystem (e.g. /dev/hda1) and fills them with zeroes. This is  useful
   if  the  device  on  which this file-system resides is a disk image. In
   this case, depending on the type of disk image, a secondary utility may
   be  able  to  reduce the size of the disk image after zerofree has been
   run.

   The usual way to achieve  the  same  result  (zeroing  the  unallocated
   blocks)  is to run dd (1) to create a file full of zeroes that takes up
   the entire free space on the drive, and then delete this file. This has
   many disadvantages, which zerofree alleviates:

      ·  it is slow;

      ·  it makes the disk image (temporarily) grow to its maximal extent;

      ·  it  (temporarily)  uses  all  free  space  on  the disk, so other
         concurrent write actions may fail.

   filesystem has to be unmounted or mounted  read-only  for  zerofree  to
   work.  It  will exit with an error message if the filesystem is mounted
   writable. To remount the  root  file-system  readonly,  you  can  first
   switch to single user runlevel (telinit 1) then use mount -o remount,ro
   filesystem.

Consultez également ce lien à propos de zerofree: Garder les images du système de fichiers rares - c'est de son auteur - Ron Yorston (9 août 2012)


24
2018-01-05 14:51



Il est important que le système de fichiers soit démonté ou monté en lecture seule pour que zerofree fonctionne. - AntonioK
Il serait bon d'inclure des informations sur la façon de procéder sur le système de fichiers racine. Je pense que cela ne fonctionnera pas, car vous devez démonter le système de fichiers tout en exécutant simultanément l’outil depuis ce système de fichiers. - Ant6n


Voici comment faire avec une interface graphique.

  1. Installer BleachBit
  2. Exécuter en tant que root en cliquant sur Applications - Outils système - BleachBit en tant qu'administrateur.
  3. Dans les préférences, indiquez les chemins que vous souhaitez. Généralement ça les devine bien. Vous souhaitez inclure un chemin accessible en écriture pour chaque partition. Il s'agit généralement de / home / nom d'utilisateur et / tmp, sauf s'il s'agit de la même partition. Dans ce cas, choisissez-en une.
  4. Cochez la case Système - Nettoyer l'espace disque libre.
  5. Cliquez sur Supprimer.

L'avancée de BleachBit sur dd (qui sinon est très agréable) est lorsque le disque est finalement plein, BleachBit crée de petits fichiers pour effacer les inodes (qui contiennent des métadonnées comme les noms de fichiers, etc.).


3
2017-11-06 12:40



Inspecter Le code python opensource de Bleachbit pour effacer l'espace libre d'un lecteur pour vous-même. - shadowbq


j'utilise dd pour allouer un ou plusieurs gros fichiers afin de remplir l’espace libre, utilisez un utilitaire de suppression sécurisé.

Pour allouer des fichiers avec dd essayez:

dd if=/dev/zero of=delete_me bs=1024 count=102400

Cela va générer un fichier nommé delete_me c'est une taille de 100 Mo. (Ici bs est la "taille de bloc" définie à 1k, et count est le nombre de blocs à allouer.)

Ensuite, utilisez votre utilitaire de suppression sécurisé préféré (j'ai utilisé shred) sur les fichiers ainsi créés.

Mais notez ceci: tamponner signifie même si vous faites la entier disque, vous ne pouvez pas tout obtenir absolument!


Ce lien recommande scrub pour effacer l'espace libre. Je n'ai pas essayé.


2
2017-08-07 01:04



Oh, si la mémoire me sert, j'ai essayé scrub une fois et il a corrompu le système de fichiers entier. Heureusement, j'ai eu le bon sens d'expérimenter d'abord sur un système de fichiers de test, PAS sur mes données réelles. - landroni


Essuyez un lecteur à toute vitesse.

Les instructions typiques pour le cryptage d'un lecteur de nos jours vous diront d'abord WIPE le lecteur.

La commande ci-dessous remplira votre lecteur avec le cryptogramme AES.

Utilisez un CD en direct si vous devez effacer votre lecteur de démarrage principal.

Ouvrez un terminal et élevez vos privilèges:

sudo bash

Laissez-nous énumérer tous les lecteurs sur le système pour être sûr:

cat /proc/partitions

REMARQUE: Remplacer /dev/sd{x} avec l'appareil que vous souhaitez effacer.

ATTENTION: Ce n'est pas pour les amateurs! Vous pourriez rendre votre système impossible à démarrer !!!

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sd{x}

Je suis abasourdi par la rapidité avec laquelle cela se passe.


2
2017-09-08 19:27





Vous avez probablement déjà le Paquet GNU coreutils installé sur votre système. Il fournit la commande déchiqueter.


2
2017-08-07 01:58



Shred ne nettoiera pas l'espace disque inutilisé sans le transformer en fichiers ... - dmckee


utilisez dd et mettez juste l’espace libre à zéro. C'est un mythe. Les données doivent être écrites plusieurs fois (il suffit de demander à Peter Guntmann) et les données aléatoires, par opposition à 1 alors les 0 impliquent une activité non naturelle. alors le résultat final est un lecteur propre avec moins de temps passé à écrire. En outre, les programmes de suppression sécurisés ne garantissent pas qu'ils écrasent même le fichier réel sur les systèmes de fichiers modernes (journalisés). faites-vous une faveur et obtenez photorec, scannez votre lecteur pour voir le désordre, essuyez-le avec 1 's et éventuellement avec des zéros pour le rendre intact. Si photorec trouve toujours des trucs, souvenez-vous qu'il est en train de scanner tout ce qui est disponible.

rappelez-vous que cia / fbi / nsa ne dispose pas d'une machine sophistiquée capable de lire l'état actuel de vos bits de support magnétique. c'était tout simplement un papier écrit il y a longtemps. un "quoi-si". il vous suffit d'effacer 1 fois.


1
2018-05-25 20:40



Il y a peu de choses intéressantes que vous avez dites, mais avez-vous réellement des sources pour sauvegarder ces informations? Il est difficile de croire que toute cette réécriture est inutile. Aussi, s'il vous plaît améliorer votre post, il est difficile de lire avec une ponctuation comme ça. - gronostaj
@gronostaj: La réclamation "il est un mythe de données doit être écrasée plusieurs fois" pour lecteurs modernes au moins a été prouvé par de multiples études. Tous les 30+ passages recommandés par Gutmann ne sont plus nécessaires, comme l'a reconnu l'auteur lui-même. - Karan


Vous pouvez effacer votre espace libre en utilisant un package de suppression sécurisé.

Dans ce paquet, vous pouvez trouver sfill Cet outil est conçu pour supprimer des données stockées sur des espaces disque disponibles sur des supports de manière sécurisée et qui ne peuvent pas être récupérées par des voleurs, des forces de l'ordre ou d'autres menaces.

Pour installer le package de suppression sécurisé sous Linux (Ubuntu), installez-le à l'aide de la commande suivante:

$ sudo apt-get install secure-delete

Alors à effacer vos données sans espace libre, essayez la commande suivante:

sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY

Où / YOUR_MOUNTPOINT / OR_DIRECTORY est votre point de montage (df -h, mount) ou répertoire pour effacer l'espace libre.

Lire le manua:

http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1.html


1
2017-07-04 21:22





Plus facile est d'utiliser frotter:

scrub -X dump

Cela va créer un dump dossier dans l'emplacement actuel et créer un fichier jusqu'à ce que le disque soit plein. Vous pouvez choisir un motif avec le -p option (nnsa|dod|bsi|old|fastold|gutmann).

Il n'est pas facile de faire installer scrub (voir les forums Ubuntu sur ce sujet), mais une fois l'installation terminée, vous disposez d'un outil vraiment SIMPLE et efficace.


1
2017-11-26 03:38



Si la mémoire me sert, j'ai essayé scrub une fois et il a corrompu le système de fichiers entier. Heureusement, j'ai eu le bon sens d'expérimenter d'abord sur un système de fichiers de test, PAS sur mes données réelles. - landroni
Je ne sais pas ce que vous avez fait ou ce qui s'est passé, mais scrub essentiellement créer un nouveau fichier jusqu'à ce qu'il remplisse le système de fichiers. Il ne joue pas avec les fichiers existants, il ne les supprime pas non plus (du moins pas la commande que j'ai donnée) ... - FMaz008
Effectivement. A essayé scrub -X dump_dir et il semble avoir bien fonctionné. BTW, l'installation sur Ubuntu 14.04 est très simple: apt-get install scrub. - landroni