Comment effacer l'espace disque libre sous Linux ?

Avertissement : Le matériel de disque/SSD moderne et les systèmes de fichiers modernes peuvent écumer des données dans des endroits où vous ne pouvez pas les supprimer, de sorte que ce processus peut toujours laisser des données sur le disque. Les seuls moyens sûrs d'effacer les données sont la commande ATA Secure Erase (si elle est correctement implémentée), ou 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 suppression sécurisée.

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 ram
sfill - essuyez tout l'espace marqué comme vide sur votre disque dur
sswap - effacez toutes les données de votre espace d'échange.

À partir 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, les forces de l'ordre ou d'autres menaces. L'algorithme d'effacement est basé sur l'article "Secure Deletion of Data from Magnetic and Solid-State Memory" présenté au 6e Usenix Security Symposium par Peter Gutmann, l'un des principaux cryptographes civils.

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

1 passage avec 0xff

5 passes aléatoires. /dev/urandom est utilisé pour un RNG sécurisé si disponible.

27 passes avec des valeurs spéciales définies par Peter Gutmann.

5 passes aléatoires. /dev/urandom est utilisé pour un RNG sécurisé si disponible.

Renommer le fichier en une valeur aléatoire

Tronquer le fichier

Par mesure de sécurité supplémentaire, le fichier est ouvert en mode O_SYNC et après chaque passage un fsync() l'appel est fait. srm écrit des blocs de 32 ko à des fins de vitesse, en remplissant les tampons des caches de disque pour les forcer à vider et à écraser les anciennes données qui appartenaient au fichier.

Le moyen le plus rapide, si vous n'avez besoin que d'une seule passe et que vous voulez simplement tout remplacer par des zéros, est :

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

(exécuté à partir d'un répertoire sur le système de fichiers que vous souhaitez effacer)
_{(le 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 qu'il peut annuler les écritures pour tous les blocs en attente lorsque le fichier n'est pas lié)}

Il y aura un moment au cours de 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é et prend donc un certain temps à supprimer. Pour réduire le temps pendant lequel 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 être suffisant pour empêcher quelqu'un de lire le contenu de l'ancien fichier sans une opération médico-légale coûteuse. Pour une variante légèrement plus sécurisée, mais plus lente, remplacez /dev/zero avec /dev/urandom . Pour plus de paranoïa, exécutez plusieurs étapes avec /dev/urandom , mais si vous avez besoin de tant d'efforts, le shred l'utilitaire 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 grand est terminé au lieu d'avoir à attendre qu'il soit déchiqueté, laissant le système de fichiers avec zéro espace libre pour le temps qui prend. Le processus de déchiquetage prend long temps sur un fichier volumineux et à moins que vous n'essayiez de cacher quelque chose à la NSA, ce n'est pas vraiment nécessaire à l'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, cela peut avoir des problèmes avec les limites de taille de fichier sur certains systèmes de fichiers.

Pour FAT32, ce serait certainement être une préoccupation en raison de la limite de fichier de 2 Go :la plupart des volumes sont plus grands que cela de nos jours (8 Tio est la limite de taille de volume IIRC). Vous pouvez contourner ce problème en reliant le grand cat /dev/zero sortie sortie via 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, c'est moins un problème :avec le bloc 4K par défaut/commun, la limite de taille de fichier est de 2 Tio, vous devez donc avoir un énorme volume pour que cela soit un problème (la taille maximale du volume dans ces conditions est de 16 Tio).

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

Sous NTFS, la longueur maximale du fichier est même 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

Appareils virtuels

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

Pour les disques virtuels peu alloués, d'autres méthodes telles que celles utilisées par zerofree sera plus rapide (bien que contrairement à cat et dd ce n'est pas un outil standard sur lequel vous pouvez compter pour être disponible dans à peu près n'importe quel système d'exploitation de type Unix).
Sachez que la remise à zéro d'un bloc sur un périphérique virtuel clairsemé peut ne pas effacer le bloc sur le physique sous-jacent périphérique, en fait, j'irais jusqu'à dire qu'il est peu probable - le gestionnaire de disque virtuel fera simplement en sorte que le bloc ne soit plus utilisé afin qu'il puisse être alloué à autre chose plus tard.
Même pour les périphériques virtuels de taille fixe, vous pouvez n'avoir aucun contrôle sur l'emplacement physique du périphérique, de sorte qu'il peut être déplacé autour de son emplacement actuel ou sur un nouvel ensemble de disques physiques à tout moment et le maximum que vous pouvez effacer est l'emplacement actuel, pas tous les emplacements précédents où le bloc a pu résider dans le passé.
Pour les problèmes ci-dessus sur les périphériques virtuels :à moins que vous ne contrôliez le ou les hôtes et que vous puissiez effectuer un nettoyage sécurisé de 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 rien faire à ce sujet après le fait. Le seul recours est d'utiliser le chiffrement intégral du disque dès le début donc rien de non chiffré n'est écrit sur le support physique en premier lieu. Bien sûr, il peut toujours y avoir un appel pour un nettoyage de l'espace libre dans la machine virtuelle. Notez également que FDE peut rendre les périphériques virtuels clairsemés beaucoup moins utiles 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 découpage au périphérique virtuel (comme s'il s'agissait d'un SSD) et que le contrôleur virtuel les interprète, cela peut résoudre ce problème, mais je ne connais aucune circonstance où cela se produit réellement et un plus large la discussion à ce sujet est un sujet pour ailleurs (nous sommes déjà sur le point d'être hors sujet pour la question d'origine, donc si cela a piqué votre intérêt, des questions d'expérimentation et/ou de suivi peuvent être de mise).

AVERTISSEMENT

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

Qu'il y ait plus de sécurité à remplir "l'espace libre" seulement 1 fois avec 0x00 ou 38 fois avec différentes normes cabalistiques est plus une discussion académique. L'auteur de l'article fondateur de 1996 sur le déchiquetage a écrit lui-même 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 vrai 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 e-mails personnels en texte brut, peu importe. Je viens de chercher sur Google réservé+espace+ext4 et j'ai appris que 5 % de mon home partition était réservée. Je suppose que c'est là que 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 toujours les données en place .

Vous pouvez essayer # tune2fs -m 0 /dev/sdn0 avant de le monter. (Si ce sera 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 encore, d'une manière ou d'une autre, il peut rester de la place.

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

Voie rapide (recommandé)

Exécutez à 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

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.

Voie 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.

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.

Avertissement. Si vous avez choisi la voie paranoïaque, après cela, vous voudriez toujours faire le balayage 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 supposer 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échiffrement.

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

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 avec beaucoup d'écrasements, voilà :

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

Avant le montage, ce billet était une réécriture de celui de David Spillett. La commande "chat" produit un message d'erreur, mais je ne peux pas écrire de commentaires sur les publications d'autres personnes.