Lorsqu'un fichier est supprimé, son contenu peut toujours être laissé dans le système de fichiers, à moins qu'il ne soit explicitement écrasé par autre chose. La commande wipe peut effacer des fichiers en toute sécurité, mais ne semble pas permettre d'effacer l'espace disque libre non utilisé par des fichiers.
Que dois-je utiliser pour y parvenir ?
Attention: Le matériel moderne des disques/SSD et les systèmes de fichiers modernes peuvent éjecter des données dans des endroits où vous ne pouvez pas les supprimer, ce processus peut donc encore laisser des données sur le disque. Les seuls moyens sûrs d'effacer des données sont la commande ATA Secure Erase (si elle est correctement mise en œuvre), 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”. Cette suite comprend quatre outils :
srm - effacer de manière sécurisée un fichier existant
smem - effacer de manière sécurisée les traces d'un fichier de la mémoire vive
sfill - effacer tout l'espace marqué comme vide sur votre disque dur
sswap - effacer toutes les données de votre espace d'échange.
De la page de manuel de srm
srm est conçu pour supprimer de manière sécurisée les données sur des supports qui ne peuvent pas être récupérés par des voleurs, des forces de l'ordre ou d'autres menaces. L'algorithme d'effacement est basé sur le document “Secure Deletion of Data from Magnetic and Solid-State Memory” présenté au 6ème symposium Usenix sur la sécurité par Peter Gutmann, l'un des principaux cryptographes civils.
Le processus d'effacement sécurisé des données de srm se déroule comme suit :
- 1 passage avec 0xff
- 5 passages aléatoires.
/dev/urandomest utilisé pour un RNG sécurisé si disponible.- 27 passages avec des valeurs spéciales définies par Peter Gutmann. Comme mesure de sécurité supplémentaire, le fichier est ouvert en mode O_SYNC et après chaque passage, un appel de
/dev/urandomest effectué.fsync()écrit des blocs de 32k pour des raisons de vitesse, en remplissant les tampons des caches disques pour les forcer à vider et en écrasant les anciennes données qui appartenaient au fichier.
Le moyen le plus rapide, si vous n'avez besoin que d'un seul passage et que vous voulez tout remplacer par des zéros, est : (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 pourrait se rendre compte qu'il peut annuler les écritures pour tous les blocs en attente lorsque le fichier est déconnecté)
Il y aura un moment au cours de cette opération où il n'y aura plus du tout d'espace libre sur le système de fichiers, ce qui peut prendre des dizaines de secondes si le fichier résultant est grand et fragmenté et prend donc du temps à supprimer. Pour réduire le temps pendant lequel l'espace libre est complètement nul :
cat /dev/zero > zero.file
sync
rm zero.file
Cela devrait suffire pour empêcher quelqu'un de lire le contenu de l'ancien fichier sans une opération de police scientifique coûteuse. […] Pour plus de paranoïa, exécutez plusieurs étapes avec /dev/zero, bien que si vous avez besoin de tant d'efforts, l'utilitaire /dev/urandom du paquet coreutils est la solution :
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
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 de devoir attendre qu'il soit déchiqueté, laissant le système de fichiers avec zéro espace libre pendant le temps que cela prend. Le processus de destruction prend un temps considérable pour un fichier volumineux et, à moins que vous n'essayiez de cacher quelque chose à la NSA, il n'est pas vraiment nécessaire.
Tout ce qui précède devrait fonctionner sur n'importe quel système de fichiers. […] […] […] […] […] […] […] […] […] […] […]
J'ai été choqué par le nombre de fichiers photorec que j'ai pu récupérer sur mon disque, même après l'avoir effacé.
La question de savoir s'il est plus sûr de remplir l’“espace libre” une seule fois avec 0x00 ou 38 fois avec des normes cabalistiques différentes est plus une discussion académique. L'auteur du document de référence de 1996 sur le déchiquetage a lui-même écrit un épilogue disant que c'est obsolète et inutile pour le matériel moderne. Il n'existe aucun cas documenté de données remplacées physiquement par des zéros et récupérées par la suite.
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 un usage spécial, et il n'est pas mis à disposition en tant qu’“espace libre”. Mais vos données peuvent s'y trouver. Cela inclut les photos, les courriels personnels en texte clair, etc. Je viens de googler “reserved+space+ext4” et j'ai appris que 5% de ma partition home était réservée. 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-pass laisse toujours les données en place.
Vous pouvez essayer # tune2fs -m 0 /dev/sdn0 avant de le monter. (Si c'est la partition racine après le redémarrage, assurez-vous d'exécuter -m 5 ou -m 1 après l'avoir démonté).
Mais quand même, d'une manière ou d'une autre, il peut rester un peu d'espace.
La seule façon vraiment sûre est d'effacer toute la partition, de créer à nouveau un système de fichiers, puis de restaurer vos fichiers à partir d'une sauvegarde.
Fast way (recommended)
Run from a directory on the filesystem you want to wipe :
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. Il n'existe aucun cas documenté de récupération de données après le nettoyage ci-dessus. Cela serait coûteux et demanderait beaucoup de ressources, voire pas du tout.
Pourtant, si vous avez une raison 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 voie de la paranoïa, après cela, vous voudrez toujours faire le 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 fait soupçonner qu'il s'agit en fait de données cryptées. Vous pouvez mourir sous la torture pour ne pas avoir révélé la clé de décryptage.
Très lent (paranoïaque fou)
Même l'auteur de l'article fondateur de 1996 sur le déchiquetage a écrit un épilogue disant que c'est 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 en l'écrasant, voici ce qu'il en est :
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
Note : cela équivaut essentiellement à utiliser l'outil de suppression sécurisée.
Avant la rédaction, ce billet était une réécriture de celui de David Spillett. La commande “cat” produit un message d'erreur, mais je ne peux pas écrire de commentaires sur les messages des autres.
Il y a une utilité gratuite 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 la gratuité : Conserver des images de système de fichiers rares - c'est de son auteur - Ron Yorston (9 août 2012)
Essuyez un lecteur à sa vitesse maximale.
Les instructions typiques pour chiffrer un lecteur de nos jours vous diront d'abord d'EFFACER le lecteur.
La commande ci-dessous remplira votre lecteur avec du texte chiffré AES.
Utilisez un CD live si vous avez besoin d'effacer votre lecteur de démarrage principal. Ouvrez un terminal et augmentez vos privilèges :
sudo bash
Laissez-nous dresser la liste de tous les lecteurs du système pour être sûr :
cat /proc/partitions
NOTE : Remplacez /dev/sd{x} par le lecteur que vous souhaitez effacer.
ATTENTION : Ceci n'est pas pour les amateurs ! Vous pourriez rendre votre système non amorçable ! !!
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 stupéfait de la rapidité de cette opération.
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é.
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” fixée à 1k, et count est le nombre de blocs à allouer).
Utilisez ensuite votre utilitaire de suppression sécurisée préféré (j'ai utilisé shred ) sur les fichiers ainsi créés.
Mais NOTEZ CECI: la mise en mémoire tampon signifie que même si vous faites le disque global, vous ne pouvez pas obtenir absolument tout !
Ce lien recommande scrub pour l'effacement de l'espace libre. Je n'ai pas encore essayé.
Vous pouvez effacer votre espace libre en utilisant le paquet de suppression sécurisée.
Dans ce paquet, vous trouverez l'outil sfill, qui est conçu pour supprimer les données qui se trouvent sur l'espace disque disponible 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 paquet de suppression sécurisée sous Linux (Ubuntu), installez le par la commande suivante :
$ sudo apt-get install secure-delete
Puis pour effacer vos données sans espace libre, essayez la commande suivante :
sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY
Où /VOTREPOINT DE MONTAGE/OU VOTRERÉPERTOIRE est votre point de montage (df -h, mount) ou répertoire pour effacer l'espace libre.
Lisez le manuel sur http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1 .html
Vous avez probablement déjà installé le GNU coreutils package sur votre système. Il fournit la commande shred .
Il est plus facile d'utiliser scrub :
scrub -X dump
Cela créera un dossier dump à l'emplacement actuel et créera un fichier jusqu'à ce que le disque soit plein. Vous pouvez choisir un modèle avec l'option -p (nnsa|dod|bsi|old|fastold|gutmann).
Il n'est pas facile de faire installer le scrub voir les Forums Ubuntu à ce sujet ), mais une fois l'installation terminée, vous avez un outil vraiment SIMPLE et efficace en 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 sur Linux et sur 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 l'espace libre à zéro. c'est un mythe que les données doivent être réécrites plusieurs fois (demandez à peter guntmann) et les données aléatoires, par opposition aux 1 puis aux 0, impliquent une activité non naturelle. 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 vrai fichier sur les systèmes de fichiers modernes (journalisés). faites-vous une faveur et récupérez photorec, scannez votre disque pour voir le désordre, effacez-le avec des 1 et éventuellement des zéros pour qu'il ait l'air intact. si photorec trouve encore des choses, rappelez-vous qu'il scanne tout ce qui est disponible, alors refaites-le avec soin avec l'utilisateur root.
rappelez-vous, la cia/fbi/nsa n'a pas de machine sophistiquée qui peut lire l'état réel des bits de votre support magnétique. ce n'était qu'un document écrit il y a longtemps. un “what-if”. vous n'avez besoin de l'effacer qu'une seule fois.
Ce n'est pas une réponse ! Juste un commentaire pour ceux qui souhaitent utiliser pv…alors ne vous embêtez pas à voter.
Sur Linux Mint 17.3 vous pouvez utiliser pv (pipe view) 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, l'ETA et un taux de données continuellement mis à jour. L'inconvénient est qu'elle est écrite sur une ligne et que lorsque le disque est plein (renvoyant une erreur), elle disparaît. Cela se produit parce que la taille totale est approximative puisque le système d'exploitation utilisera probablement le disque pendant cette très longue opération, en particulier sur le volume du système d'exploitation.
Sur un très vieux disque dur, j'obtiens 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éliorerait probablement encore en utilisant un dd brut ou un cat, et non un pv.
J'utilise parfois cette ligne de base :
while :; do cat /dev/zero > zero.$RANDOM; done
Quand il commence à dire que le disque est plein, il suffit d'appuyer sur Ctrl+C et de supprimer les fichiers zero.* créés.
Cela fonctionne sur tout système, quelle que soit la taille du fichier.
Ignore toutes les erreurs cat: write error: File too large.
Une fois que le fichier a été supprimé du système de fichiers, les données qui restent sur le disque dur sont une séquence de 1 et de 0 sans signification. Si vous cherchez à remplacer cette séquence insignifiante par une autre séquence insignifiante, je peux vous conseiller certains produits commerciaux pour effacer les disques en toute sécurité, comme arconis.