...consiste à créer sur une partition un fichier temporaire plein de zéros ou de données aléatoires, jusqu'à ce que le disque soit plein, écrasant ainsi sauvagement toutes les données qui pourraient s'y trouver encore (sans affecter les fichiers non-effacés qui s'y trouvent).

Bien que cette méthode ne soit pas infaillible,[1] elle garantit toutefois que les données ne seront pas récupérables sans d'extrêmement longues et coûteuses procédures : Celui qui n'a pas quelques centaines de milliers d'Euros à dépenser pour ça pourra faire ballon sur les données ainsi effacées de votre disque, et même pour celui qui a les moyens, la partie sera fine... Bref, la plupart des gens pourront dormir tranquilles.

Pour les autres, il existe des logiciels spécifiques, tels que shred ou secure delete (package secure-delete disponible sur Ubuntu et Debian), mais à mon avis ceux qui ont besoin de shred ont encore davantage besoin de rouler sur leur disque dur avec un bulldozer ;-) [2]

Comment procéder simplement, en console root : [3]

Créer avec "dd" sur un point de montage quelconque (prenons l'exemple de /home) un fichier qui bourrera la partition correspondante de zéros, puis effacer aussitôt celui-ci après avoir synchronisé le disque :

dd if=/dev/zero of=/home/bidon bs=1M; sync; rm -f /home/bidon

Et voilà !

(L'opération peut durer plusieurs dizaines de minutes sur un disque de plusieurs dizaines de Go)

On peut utiliser /dev/urandom à la place de /dev/zero pour écrire des données pseudo-aléatoires plutôt que des zéros : La protection sera légèrement meilleure, mais le temps d'exécution passera, pour un gros disques, à des heures, voire des jours... Tout dépend donc du temps dont on dispose ;-)

A noter que si l'on fait cela sur la partition racine "/" ou "/var" d'un serveur où d'une machine sur laquelle des "démons" tournent, le système risque de ne pas aimer du tout de se trouver temporairement à court d'espace disque au moment où le gros fichier bidon remplira presque entièrement celui-ci... Il est prudent d'arrêter les démons qui pourraient avoir soudainement besoin d'écrire des fichiers sur le disque, pendant la procédure.

N.B. :

  • Cette méthode laisse toujours quelques petits bouts de disque non effacés dans la structure même du filesystem, mais elle remplit cependant parfaitement la mission "d'effacer le plus gros", et de loin. La seule méthode pour effacer vraiment tout le disque serait de faire cela sur le disque entier, et non pas dans un fichier ; ce moyen serait donc destructif de tous les fichiers présents sur le disque.
  • Cette méthode ne permet pas d'effacer les vieilles données contenues dans le "file slack" : Il faut savoir que sur un disque, l'espace est alloué par blocs, typiquement de 4 Ko pour un filesystem ext3.
    • Chaque fichier se voit attribué un nombre entier de blocs. Ainsi, un fichier de 120 octets se voit atttribuer un bloc entier de 4 Ko, un fichier de 10 Ko se voit attribuer 3 blocs alors qu'il n'en utilise réellement que 2 1/2, etc.
    • L'espace non utilisé par un fichier auquel il a été attribué conserve les vieilles données (donc un bout de vieux fichier effacé), et les conserve perpétuellement (tant que le fichier auquel est alloué ce bloc "verrouille" cet espace).[4]
    • On considère statistiquement que chaque fichier présent sur le disque gaspille en moyenne un demi-bloc d'espace, soit 2 Ko.
    • Il est courant qu'une installation GNU/Linux complète comprenne plus de 150.000 fichiers, uniquement pour le système. Ces fichiers verrouillent donc (gaspillent), pour 150.000 fichiers, 300.000 Ko, soit environ 300 Mo d'espace inutilisé, qui en fait contient des données de vieux fichiers effacés (sauf si l'installation a été faite sur un disque vierge). On appelle ceci le "file slack".
    • Une méthode d'effacement comme celle présentée plus haut ne peut rien faire pour le file slack, et donc, ces morceaux de vieilles données restent potentiellement récupérables. Il faut cependant noter que :
      • Ces morceaux sont disséminés à travers tout le disque, Il est donc peu probable qu'on y trouve autre chose que de petits fragments de milliers de fichiers très difficiles à "recoller ensemble" pour en tirer un sens. Le manque de bol serait que s'y trouve un mot de passe important où une phrase suffisamment compromettante - quel que soit le sens qu'on donne à ce mot - par elle-même.
      • Comme ce sont des fins de blocs, on n'aura jamais le début d'un fichier (les premiers octets d'en-tête) Il sera donc difficile de déterminer la nature des morceaux de données ainsi récupérables - sauf si c'est du texte ASCII..
      • En pratique, la menace potentielle représentée par ce file slack est réelle, mais très modérée au regard du risque que présenterait la récupération de fichiers entiers.
    • Le seul moyen d'éliminer le file slack (sans utilitaire spécial) consisterait à copier tous les fichiers sur un autre support, puis effacer tout le disque avant de restaurer les fichiers sauvegardés à leur place initiale...

Pour éviter de devoir se poser la question de l'effacement réel des fichiers, le chiffrement complet du filesystem reste la solution de choix.

Addendum 15/05/2008 : Pour compléter cet article, je signale aux utilisateurs d'Ubuntu et Debian l'existence du package "secure-delete", qui installe les utilitaires suivants :

  • srm : Effacement "sécurisé" d'un fichier (ou d'une arborescence de répertoires complète).
  • sfill : Ecrasement "sécurisé" de l'ensemble de l'espace libre sur une partition (pour écrabouiller ce qu'il peut rester des fichiers précédemment effacés par des méthodes "non-sécurisées").
  • sswap : Effacement "sécurisé" du swap.
  • smem : Effacement "sécurisé" de la mémoire vive.

Les 3 premiers, agissant sur le disque, effectuent l'effacement selon les méthodes préconisées par Peter Gutmann au 6e Symposium de Sécurité Usenix, c'est-à-dire que par défaut ils effectuent 38 (!) écrasements successifs du contenu d'un fichier, dont 5 passes avec des valeurs aléatoires, puis 27 passes avec des valeurs spéciales successives déterminées par Gutmann, puis à nouveau 5 passes aléatoires.
Autant dire que si le temps d'exécution est supportable pour des fichiers de taille relativement modeste, un "sfill" par cette méthode d'un disque de plusieurs centaines de Go peut prendre des jours et des jours...

Il existe toutefois moyen de lancer ces outils en mode "plus rapide et moins sécurisé" (effectuant moins de passes).

Je doute personnellement un peu de l'intérêt de faire autant de passes dans la grande majorité des cas et avec la densité des disques modernes, les têtes servo et les méthodes d'enregistrement "orthogonal"... À moins que l'effacement d'un fichier donné soit d'importance absolument vitale et qu'on ne considère qu'on n'est jamais trop paranoïaque.

Et ces outils restent de toute manière hélas vulnérables aux limites indiquées dans la note [2].

Notes

[1] Elle ne protège notamment pas contre les effets-mémoire du support magnétique et les moyens de récupérer des données écrasées avec beaucoup d'efforts et de moyens nécessitant le démontage complet du disque - matériel spécialisé, microscope électronique à effet tunnel... Certains spécialistes doutent cependant qu'une quelconque récupération soit en pratique possible avec la densité d'information atteinte sur les disques actuels.

[2] Je doute très fortement de l'effectivité d'un quelconque logiciel d'écrasement physique "fichier par fichier" sur un filesystem journalisé moderne tel que l'on en recontre sous Linux (ext3, ReiserFS, XFS...), si ce logiciel opère au-dessus du niveau du filesystem. En effet, les données d'écrasement que l'on cherche à écrire par-dessus un fichier ont toutes les chances d'être effectivement écrites à un emplacement physique différent du disque, vouant à l'échec toute tentative d'écraser le contenu d'un fichier spécifique... Et ce sera encore plus vrai avec un système de fichier snapshotté pratiquant systématiquement la réécriture sur des blocs physiques différents (tel que WAFL). Seul le fait de remplir toute la partition de disque concernée peut alors garantir que tous les fichiers effacés seront effectivement écrasés.

[3] Quels que soient les droits de votre "utilisateur ordinaire" sur le point de montage concerné, seul root a par défaut le droit de remplir à 100% un filesystem donné. Un utilisateur ordinaire ne pourra pas dépasser 95% de l'espace libre, laissant ainsi au moins 5% d'espace non-effacé. Voir man tune2fs si l'on désire modifier ce pourcentage.

[4] On peut ainsi considérer qu'un nouveau fichier écrase une partie d'un ancien fichier, tout en préservant le reste de celui-ci...