Comment effacer l'espace disque libre sous Linux?

Lorsqu'un fichier est supprimé, son contenu peut toujours rester dans le système de fichiers, à moins d'être explicitement remplacé par quelque chose d'autre. La wipecommande peut effacer des fichiers de manière sécurisée, mais ne semble pas permettre l'effacement de l'espace disque disponible qui n'est utilisé par aucun fichier.

Que devrais-je utiliser pour y parvenir?

Avertissement: Le matériel de disque / SSD moderne et les systèmes de fichiers modernes peuvent empêcher la suppression de données à 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 d’effacement des données sont la commande ATA Secure Erase (si elle est correctement implémentée) ou la destruction physique. Voir également Comment puis-je effacer de manière fiable toutes les informations d'un disque dur?

Vous pouvez utiliser une suite d'outils appelée secure-delete.

sudo apt-get install secure-delete

Cela a quatre outils:

srm- supprimer en toute sécurité un fichier existant
smem- supprimer en toute sécurité les traces d'un fichier de la mémoire vive
sfill- effacer tout l'espace marqué comme étant vide sur votre disque dur
sswap- effacer toutes les données de votre espace de permutation.

De la page de manuel de srm

srm est conçu pour supprimer les données sur des supports de manière sécurisée qui ne peuvent pas être récupérées par des voleurs, des forces de l'ordre ou d'autres menaces. L'algorithme d'effacement est basé sur le document "Suppression sécurisée des données de la mémoire magnétique et à l'état solide" présenté lors du 6e Symposium sur la sécurité Usenix par Peter Gutmann, l'un des principaux cryptographes civils.

Le processus de suppression sécurisée des données de srm se déroule comme suit:

• 1 passe avec 0xff
• 5 passes aléatoires. /dev/urandomest utilisé pour un RNG sécurisé, le cas échéant.
• 27 passages avec des valeurs spéciales définies par Peter Gutmann.
• 5 passes aléatoires. /dev/urandomest utilisé pour un RNG sécurisé, le cas échéant.
• Renommez le fichier en une valeur aléatoire
• Tronquer le fichier

Comme mesure de sécurité supplémentaire, le fichier est ouvert en mode O_SYNC et, après chaque passe, un fsync()appel est effectué. srmécrit des blocs de 32k dans un but de rapidité, remplissant les tampons des caches de disque pour les forcer à vider et écraser les anciennes données appartenant au fichier.

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

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

(exécutez depuis un répertoire du système de fichiers que vous souhaitez effacer)
_{(la synccommande est une mesure de paranoïa qui garantit que toutes les données sont écrites sur le disque. Un gestionnaire de cache intelligent peut donc décider qu'il peut annuler les écritures de tous les blocs en attente lorsque le fichier n'est pas lié. )}

Pendant cette opération, il y aura un temps pendant lequel il n'y aura plus aucun 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é, la suppression prend donc un certain temps. Pour réduire le temps où l'espace libre est complètement 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 le contenu de l'ancien fichier sans recourir à une opération judiciaire coûteuse. Pour une variante légèrement plus sûre, mais plus lente, remplacez /dev/zeropar /dev/urandom. Pour plus de paranoïa, exécutez plusieurs étapes avec /dev/urandom, bien que si vous avez besoin de tant d’effort, l’ shredutilitaire du paquet coreutils est la solution:

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. Il peut donc être supprimé dès que le plus gros est terminé au lieu d'attendre qu'il soit déchiqueté, ce qui laisse le système de fichiers avec zéro espace disponible pour le temps requis. Le processus de destruction prend beaucoup de temps sur un fichier volumineux et, à moins que vous n'essayiez de cacher quelque chose à la NSA, n'est pas vraiment nécessaire OMI.

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

Taille limite du fichier:

Comme le souligne DanMoulding dans un commentaire ci-dessous, des problèmes de taille de fichier peuvent apparaître sur certains systèmes de fichiers.

Pour le format FAT32, le nombre maximal de fichiers de 2 Go serait certainement une source de préoccupation: la plupart des volumes sont plus importants que cela de nos jours (8TiB est la limite de taille de volume IIRC). Vous pouvez contourner ce problème en canalisant la cat /dev/zerosortie volumineuse splitpour 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 taille maximale du fichier est de 2TiB. Vous devez donc disposer d’un volume énorme pour que cela soit un problème (taille maximale dans ces conditions). est 16TiB).

Avec le btrfs (encore expérimental), les tailles de fichier et de volume maximales sont de 16EiB.

Sous NTFS, la longueur maximale du fichier est parfois supérieure à la longueur maximale du volume.

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

Dispositifs 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 faiblement alloués, d'autres méthodes telles que celles utilisées par zerofreeseront plus rapides (bien catque ddce ne soit pas un outil standard sur lequel vous puissiez compter, il est disponible dans pratiquement tout système d'exploitation de type Unix-a-like).

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

• Même pour les périphériques virtuels de taille fixe, il se peut que vous n’ayez aucun contrôle sur l’emplacement physique du périphérique. Il est donc possible de le déplacer à tout moment autour de son emplacement actuel ou sur un nouvel ensemble de disques physiques. 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: sauf si vous contrôlez le ou les hôtes et que vous pouvez effacer de manière sécurisée leur espace non alloué après avoir effacé les disques de la machine virtuelle ou déplacé le périphérique virtuel, vous ne pouvez plus rien y faire après la fait. Le seul recours consiste à utiliser le chiffrement intégral du disque dès le débutil n'y a donc rien de non chiffré qui soit écrit sur le support physique en premier lieu. Il se peut qu’il y ait toujours un appel pour un effacement d’espace libre dans la VM. Notez également que FDE peut rendre beaucoup moins utiles les périphériques virtuels clairsemés, car la couche de virtualisation ne peut pas vraiment voir quels blocs sont inutilisés. Si la couche du système de fichiers du système d’exploitation envoie des commandes de rognage au périphérique virtuel (comme s’il s’agit d’un disque SSD), et que le contrôleur virtuel les interprète, cela peut résoudre le problème, mais je ne connais aucune circonstance où cela se produit réellement et plus largement. la discussion à ce sujet relève d’ailleurs (nous sommes déjà sur le point de quitter le sujet de la question initiale, aussi, si cela suscite votre intérêt, des questions d’expérimentation et / ou de suivi pourraient être utiles).

ATTENTION

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

La question de savoir s'il est plus sûr de ne remplir qu'une "fois" l'espace libre "une seule fois avec 0x00 ou 38 fois avec différentes normes cabalistiques est plutôt une discussion académique. L'auteur du premier article de 1996 sur le déchiquetage a lui-même écrit un épilogue affirmant qu'il était obsolète et inutile pour le matériel moderne. Il n’existe aucun cas documenté de données physiquement remplacées par des zéros, puis récupérées.

Le véritable lien fragile dans cette procédure est le système de fichiers . Certains systèmes de fichiers réservent de l'espace pour une utilisation spéciale et ne sont pas rendus disponibles en tant qu '"espace libre". Mais vos données peuvent être là . Cela inclut les photos, les e-mails personnels en clair, peu importe. Je viens de googler réservé + espace + ext4 et appris que 5% de ma homepartition était réservé. Je suppose que c’est là photorecque l’on a trouvé une grande partie de mes affaires. Conclusion: la méthode de déchiquetage n'est pas la plus importante, même la méthode multi-passes laisse toujours les données en place .

Vous pouvez essayer # tune2fs -m 0 /dev/sdn0avant de le monter. (S'il s'agit de la partition racine après le redémarrage, assurez-vous de l'exécuter -m 5ou -m 1de la démonter).

Néanmoins, d’une manière ou d’une autre, il peut rester de l’espace.

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

Moyen rapide (recommandé)

Exécuter à partir d'un répertoire du système de fichiers que vous souhaitez nettoyer:

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

Remarques: le but du petit fichier est de réduire le temps pendant lequel 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 suffire à la plupart des gens.

Façon lente (paranoïaque)

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

Cependant, si vous avez une raison de penser que des 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 procéder au nettoyage 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 et laisse penser qu'il s'agit en réalité de données cryptées. Vous pouvez mourir sous la torture pour ne pas avoir révélé la clé de déchiffrement.

Façon très lente (paranoïaque fou)

Même l'auteur du document phare de 1996 sur le déchiquetage a écrit un épilogue affirmant qu'il était obsolète et inutile pour le matériel moderne.

Mais si vous avez encore beaucoup de temps libre et que vous n'avez pas peur de gaspiller votre disque avec beaucoup de réécriture, voici ce qui se passe:

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 revient essentiellement à utiliser l'outil de suppression sécurisée.

Avant la modification, ce message é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.

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.

Vérifiez également ce lien sur zerofree: Garder les images de système de fichiers rares - c’est de son auteur - Ron Yorston (9 août 2012)

Voici comment le faire avec une interface graphique.

1. Installer BleachBit
2. Exécutez en tant que root en cliquant sur Applications - Outils système - BleachBit en tant qu’administrateur.
3. Dans les préférences, indiquez-lui les chemins que vous voulez. Généralement, il les devine bien. Vous souhaitez inclure un chemin d'accès en écriture pour chaque partition. Il s’agit généralement de / home / nom d’utilisateur et de / tmp, à moins qu’ils ne soient la même partition, auquel cas il suffit de choisir une.
4. Cochez la case Système - Nettoyer l’espace disque disponible.
5. Cliquez sur Supprimer.

L'avancée de BleachBit par rapport à dd (ce qui est par ailleurs très agréable) survient lorsque le disque est enfin plein. BleachBit crée de petits fichiers pour effacer les inodes (qui contiennent des métadonnées telles que les noms de fichiers, etc.).

J'utilise ddpour allouer un ou plusieurs gros fichiers afin de remplir l'espace libre, puis utiliser un utilitaire de suppression sécurisée.

Pour allouer des fichiers avec dd, essayez:

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

Cela générera un fichier nommé d’une delete_metaille de 100 Mo. (Voici bsla "taille de bloc" définie sur 1k et countle nombre de blocs à allouer.)

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

Mais NOTE CECI: la mise en mémoire tampon signifie que même si vous faites tout le disque, vous ne pouvez pas tout obtenir!

Ce lien recommande scrubde nettoyer l’espace libre. Je n'ai pas essayé.

Essuyez un lecteur à toute vitesse.

Les instructions habituelles pour chiffrer un lecteur vous diront d’abord d’essayer le lecteur.

La commande ci-dessous remplira votre lecteur avec le texte chiffré AES.

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

Ouvrez un terminal et élevez vos privilèges:

sudo bash

Laissez-nous la liste de tous les lecteurs sur le système pour être sûr:

cat /proc/partitions

REMARQUE: remplacez-le /dev/sd{x}par le périphérique que vous souhaitez nettoyer.

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 c'est.

Le paquet GNU coreutils est probablement déjà installé sur votre système. Il fournit la commande shred .

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

Dans ce package , vous pouvez trouver l' sfilloutil, qui est conçu pour supprimer les données qui se trouve sur l' espace disque disponible sur des supports de manière sécurisée qui ne peut pas être recouvrées par thiefs, application de la loi ou d' autres menaces.

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

$ sudo apt-get install secure-delete

Ensuite, pour effacer vos données sans espace disponible, 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 votre répertoire pour nettoyer l'espace disponible.

Lisez le manuel sur http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1.html

utilisez dd et mettez simplement à zéro l'espace libre. c'est un mythe que les données doivent être écrites plusieurs fois (il suffit de demander à Peter Guntmann) et les données aléatoires, par opposition à 1 puis 0 implique une activité non naturelle. alors le résultat final est un disque propre avec beaucoup moins de temps passé à écrire. En outre, les programmes de suppression sécurisés ne peuvent pas garantir qu'ils écrasent même le fichier réel sur les systèmes de fichiers modernes (journalisé). faites-vous une faveur et obtenez photorec, analysez votre lecteur pour voir le désordre, nettoyez-le avec des 1 et éventuellement avec des zéros pour le rendre intact. si photorec trouve toujours des éléments, rappelez-vous qu’il analyse tout ce qui est disponible. Répétez cette opération avec l’utilisateur root.

rappelez-vous, la cia / fbi / nsa ne dispose pas d’une machine sophistiquée capable de lire l’état réel de vos bits de support magnétique. ce n'était qu'un document écrit il y a longtemps. un "et si". il vous suffit d'essuyer 1 fois.

Plus facile est d'utiliser gommage :

scrub -X dump

Cela créera un dumpdossier à l’emplacement actuel et créera un fichier jusqu’à saturation du disque. Vous pouvez choisir un motif avec l' -poption ( nnsa|dod|bsi|old|fastold|gutmann).

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

Voici le script "sdelete.sh" que j'utilise. Voir les commentaires pour plus de détails.

# Install the secure-delete package (sfill command).

# To see progress type in new terminal:
# watch -n 1 df -hm

# Assuming that there is one partition (/dev/sda1). sfill writes to /.
# The second pass writes in current directory and synchronizes data.
# If you have a swap partition then disable it by editing /etc/fstab
# and use "sswap" or similar to wipe it out.

# Some filesystems such as ext4 reserve 5% of disk space
# for special use, for example for the /home directory.
# In such case sfill won't wipe out that free space. You
# can remove that reserved space with the tune2fs command.
# See http://superuser.com/a/150757
# and https://www.google.com/search?q=reserved+space+ext4+sfill

sudo tune2fs -m 0 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'

sudo sfill -vfllz /

# sfill with the -f (fast) option won't synchronize the data to
# make sure that all was actually written. Without the fast option
# it is way too slow, so doing another pass in some other way with
# synchronization. Unfortunately this does not seem to be perfect,
# as I've watched free space by running the "watch -n 1 df -hm"
# command and I could see that there was still some available space
# left (tested on a SSD drive).

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

sudo tune2fs -m 5 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'

J'ai trouvé une solution simple qui fonctionne sous Linux et MacOS. Déplacez-vous dans le dossier racine de votre disque et lancez cette commande:

for i in $(seq 1 //DISKSPACE//); do dd if=/dev/zero of=emptyfile${i} bs=1024 count=1048576; done; rm emptyfile*;

où // DISKSPACE // est la taille en Go de votre disque dur.

J'utilise parfois ce bash one-liner:

while :; do cat /dev/zero > zero.$RANDOM; done

Quand il commence à dire que le disque est plein, appuyez simplement sur Ctrl+ Cet supprimez les zero.*fichiers créés .

Cela fonctionne sur n'importe quel système, quelles que soient les limites de taille de fichier.
Ignorer les cat: write error: File too largeerreurs.

Ce n'est pas une réponse! Juste un commentaire pour ceux qui souhaitent utiliser pv... alors ne vous inquiétez pas du vote.

Sous Linux Mint 17.3, vous pouvez utiliser pv( vue du canal ) pour obtenir l’avancement de l’écriture. Par exemple:

# Install pv (pipe view)
sudo apt-get install pv

# Write huge file of approximate size of /dev/sdb, using urandom data:
pv --timer --average-rate --progress --numeric --eta --interval 5 --size "$(blockdev --getsize64 /dev/sda )" /dev/urandom >rand.file

L'avantage ici est que vous obtenez une barre de progression, un ETA et un débit de données constamment mis à jour. L'inconvénient est que cela est écrit sur une ligne et que le disque est plein (retourne une erreur), il disparaît. Cela est dû au fait que la taille complète est approximative, car le système d'exploitation utilisera probablement le disque pendant cette opération très longue, en particulier sur le volume du système d'exploitation.

Sur un très vieux disque dur, je reçois un débit de données d’environ 13 Mo / s en utilisant /dev/urandom, et d’environ 70 Mo / s en utilisant /dev/zero. Cela s’améliorera probablement davantage lorsqu’on utilise un brut ddou catnon pv.

Une fois que le fichier a disparu de l'enregistrement du système de fichiers, les données qui restent sur le disque dur sont une séquence sans signification de 1 et de 0. Si vous souhaitez remplacer cette séquence dépourvue de signification par une autre séquence dépourvue de sens, je peux conseiller certains produits commerciaux pour effacer des disques en toute sécurité, tels que arconis.