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 commande wipe peut effacer de manière sécurisée des fichiers, mais ne semble pas permettre d'effacer de l'espace disque disponible qui n'est utilisé par aucun fichier.
Que devrais-je utiliser pour y parvenir?
Warning: _ Le matériel disque/SSD moderne et les systèmes de fichiers modernes peuvent perdre des données à des emplacements où vous ne pouvez pas les supprimer. Ce processus peut donc laisser des données sur le disque. Les méthodes sécurisées d’effacement des données sont la commande ATA Secure Erase (si elle est correctement implémentée) ou la destruction physique. Voir aussi 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 - efface de manière sécurisée un fichier existantsmem - supprime en toute sécurité les traces d'un fichier de la RAMsfill - efface tout l’espace marqué comme étant vide sur votre disque dursswap - efface toutes les données de votre espace de permutation.
De la page de manuel de srm
srm est conçu pour supprimer des 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 appel
fsync()est effectué.srmécrit des blocs de 32k dans un but de rapidité, de remplissage des tampons des caches de disque afin de les forcer à vider et d’é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écuté depuis un répertoire sur le système de fichiers que vous voulez effacer)
(la commande sync est une mesure de paranoïa qui garantit que toutes les données sont écrites sur le disque - un gestionnaire de cache intelligent peut déterminer s'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écurisée mais plus lente, remplacez /dev/zero par /dev/urandom. Pour plus de paranoïa, exécutez plusieurs étapes avec /dev/urandom. Toutefois, si vous avez besoin de beaucoup d’effort, l’utilitaire shred du package 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 avec prendre un longtime sur un fichier volumineux et sauf si vous essayez 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.
Limites de taille de 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 FAT32, il serait certainementune source d'inquiétude en raison de la limite de fichier de 2 Go: la plupart des volumes sont plus importants qu'aujourd'hui (8TiB correspond à la limite de taille de volume IIRC). Vous pouvez contourner ce problème en lançant la sortie cat /dev/zerosplit 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 taille maximale du fichier est de 2TiB. Vous devez donc avoir un énormevolume pour que cela soit un problème (volume maximum). la taille 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
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 peu alloués, d'autres méthodes telles que celles utilisées par
zerofreeseront plus rapides (bien que, contrairement àcatetdd, ce ne soit pas un outil standard sur lequel vous pouvez compter pour être disponible dans à peu près n'importe quel système d'exploitation semblable à celui de Unix).Sachez que la remise à zéro d'un bloc sur un périphérique virtuel fragmenté peut ne pas effacer le bloc sur le physiquepériphérique sous-jacent, en fait, j'irais même jusqu'à dire que ce n'est probablement pas le cas - le gestionnaire de disque virtuel créera simplement le bloc comme n'étant 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 ne puissiez pas contrôler 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. Le maximum que vous pouvez effacer correspond à l’emplacement actuel. 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 contrôliez le ou les hôtes et que vous puissiez effacer de manière sécurisée leur espace non alloué, après avoir nettoyé les disques du VM ou déplacé le périphérique virtuel, vous ne peut faire à ce sujet après le fait. Le seul recours consiste à utiliser le chiffrement intégral du disque dès le départafin que rien ne soit non chiffré ne soit écrit sur le support physique en premier lieu. Un effacement de l'espace libre peut toujours être demandé dans la VMRemarquez é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'agissait d'un SSD) , et le contrôleur virtuel les interprète, alors cela peut résoudre le problème, mais je ne connais aucune circonstance dans laquelle cela se produit réellement et une discussion plus large à ce sujet relève d’ailleurs (nous sommes déjà sur le point d’être hors sujet pour le question originale, donc si cela suscite votre intérêt, des questions d’expérimentation et/ou de suivi peuvent être utiles).
ATTENTION
J'ai été choqué par le nombre de fichiers photorec que je pouvais 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 l’espace libre qu’une 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 écrit lui-même un épilogue affirmant qu'il est 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 vrai 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 courriels personnels en texte brut, peu importe. Je viens de googler réservé + espace + ext4 et appris que 5% de ma partition home était réservé. Je suppose que c’est là que photorec 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/sdn0 avant de le monter. (S'il s'agit de la partition racine après le redémarrage, assurez-vous d'exécuter -m 5 ou -m 1 après l'avoir démontée).
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 un système de fichiers à nouveau, puis de restaurer vos fichiers à partir d’une sauvegarde.
Voie 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: l'objectif du petit fichier est de réduire le temps où l'espace libre est totalement 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’existe 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.
Manière 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, 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.
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 - il provient de son auteur - Ron Yorston (9 août 2012)
Voici comment le faire avec une interface graphique.
- Installer BleachBit
- Exécutez en tant que root en cliquant sur Applications - Outils système - BleachBit en tant qu’administrateur.
- 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. Généralement, il s’agit de/home/nomutilisateur et/tmp, à moins qu’ils ne soient la même partition, auquel cas il suffit de choisir une.
- Cochez la case Système - Nettoyer l’espace disque disponible.
- 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.).
Vous pouvez effacer votre espace libre en utilisant un package de suppression sécurisée.
Dans ce paquet, vous pouvez trouver l'outil sfill, conçu pour supprimer de manière sécurisée les données stockées sur des disques disponibles sur des supports, 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ée sous Linux (Ubuntu), installez-le à l'aide de la commande suivante:
$ Sudo apt-get install secure-delete
Puis pour erase vos données pas d’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 votre répertoire pour vider l'espace libre.
Lisez le manuel à http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1.html
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 /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.
J'utilise dd pour allouer un ou plusieurs gros fichiers afin de remplir l'espace libre, puis j'utilise 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é delete_me d’une taille de 100 Mo. (Ici, bs est la "taille de bloc" définie sur 1k, et count est le nombre de blocs à allouer.)
Ensuite, utilisez votre utilitaire de suppression sécurisé préféré (je me sers de shred ) sur les fichiers ainsi créés.
Mais NOTE THIS: buffering signifie que même si vous faites le disque entier, vous ne pouvez pas tout obtenir!
This link recommend scrub pour l’effacement de l’espace libre. Je n'ai pas essayé.
Le paquet GNU coreutils est probablement déjà installé sur votre système. Il fournit la commande shred .
Plus facile est d'utiliser gommage :
scrub -X dump
Cela créera un dossier dump à l’emplacement actuel et créera un fichier jusqu’à saturation du disque. Vous pouvez choisir un motif avec l'option -p (nnsa|dod|bsi|old|fastold|gutmann).
Il n’est pas facile de faire installer scrub ( voir les forums Ubuntu à ce sujet ), mais une fois l’installation terminée, vous disposez d’un outil vraiment SIMPLE et efficace.
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.
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 aux 1 puis aux 0, ce qui 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 l’opération avec précaution 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.
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'
Ce n'est pas une réponse! Juste un commentaire pour ceux qui souhaitent utiliser pv... alors ne vous fatiguez pas à voter.
Sur Linux Mint 17.3 vous pouvez utiliser pv ( pipe view ) pour obtenir la progression 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 lorsque 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 d'environ 13 Mo/s en utilisant /dev/urandom et d'environ 70 Mo/s en utilisant /dev/zero. Cela améliorerait probablement davantage si vous utilisiez une variable dd ou cat, et non pv.
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+C et supprimez les fichiers zero.* créés.
Cela fonctionne sur n'importe quel système, quelles que soient les limites de taille de fichier.
Ignore toutes les erreurs cat: write error: File too large.