Que se passe-t-il lorsque j'utilise 'dd' pour écraser le disque à partir duquel Ubuntu s'exécute?

Que se passerait-il si j'utilisais

sudo dd if=/dev/zero of=/dev/sda

à partir d'une installation Ubuntu exécutée à partir de /dev/sda ?

Je l'ai essayé dans une machine virtuelle et il semble avoir correctement effacé le disque. Est-ce que ce sera le cas à chaque fois? Est-ce un moyen sûr de "nettoyer" une installation Ubuntu et toutes les données?

Ma question est quelque peu inspirée par:

1. Comment désinstaller Ubuntu d'un ordinateur?
2. Comment «rm -rf /» peut-il supprimer tous les fichiers du système? .

En fait, le système de fichiers est toujours monté et certaines écritures sont mises en mémoire tampon, ce qui signifie qu'elles sont toujours dans la mémoire RAM en attente d'être écrites sur le disque. Disons que ddtout écrase correctement, et juste derrière, les tampons sont vidés et certaines données potentiellement sensibles sont réécrites sur le disque. Donc non, ce n'est pas un moyen sûr d'essuyer un disque.

Vous pouvez éviter ce problème en remontant d'abord en mode lecture seule le système de fichiers racine et tout autre système de fichiers qui se trouvent sur le disque (ou en les démontant complètement, mais vous ne pourrez pas le faire avec le système de fichiers racine), puis, non plus d'écritures devraient être autorisées sur les systèmes de fichiers (donc pas de tampons à vider), donc votre commande devrait être sûre maintenant, même si c'est toujours une mauvaise idée en cas de panique car cela prend beaucoup de temps.

Si vous voulez avoir une sorte de fonction de suppression de panique, je suggère de crypter votre disque avec LUKS (le programme d'installation d'Ubuntu peut le faire), puis de suivre ma réponse sur Security Stack Exchange . Cela implique d'essuyer le cryptheader qui ne fait que 2 Mo et qui prend moins d'une seconde à remplacer. Redémarrez ensuite le système et les clés de chiffrement du disque disparaîtront de la mémoire, sans aucun moyen de les restaurer car le cryptheader lui-même a également disparu.

J'ai sacrifié une machine virtuelle en utilisant une utilisation légèrement plus avancée d' ddemprunt et légèrement modifiée des pages Arch Wiki .

Installez d'abord un joli compteur de progression:

sudo apt-get install pv

Et puis exécutez la ddcommande «améliorée»

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null \
| base64)" -nosalt </dev/zero \
| pv -bartpes "$(sudo blockdev --getsize64 /dev/sda)" \
| sudo dd bs=64K of=/dev/sda

Cela laissera le disque rempli de texte chiffré AES. Un nettoyage de disque complet et sécurisé? Probablement mieux que votre propre ddexemple, mais rien n'est complètement sûr ou garanti ...

Et tu me dois une VM :)

Références:

• Arch: essuyez le disque en toute sécurité
• Arch: dd - Exemple avancé

Réponse courte: cela fera à peu près ce que vous voulez et puis rien ne fonctionnera. Utiliser ddvous opérez à un niveau inférieur au système de fichiers, ce qui signifie que les contraintes qui s'y appliqueraient ne sont plus pertinentes (cela ne signifie pas que le noyau ne pouvait pas vous empêcher de le faire - mais ce n'est pas le cas). Certains contenus du système de fichiers sont déjà en mémoire, par exemple le noyau et le ddprogramme lui-même, et certains seront en cache. Il est possible que si le système est en mode multi-utilisateur, certains fichiers puissent être réécrits dden cours, en supposant qu'ils ont réellement changé, et si vous êtes sous pression mémoire, certaines pages de celui-ci peuvent également être échangées (ils doivent être chiffrés et donc inutilisables après le redémarrage).

La plupart des commandes que vous émettriez après cela - y compris reboot- ne seraient pas dans le cache et ne fonctionneraient donc pas. Donc, si vous êtes en mode mono-utilisateur, cela fonctionnera extrêmement bien, si vous êtes en mode multi-utilisateur, cela effacera la grande majorité des données. Idéalement, vous devriez le faire démarré à partir d'un autre support (même en s'arrêtant peut-être sur l'initrd) pour être sûr de la provenance de toutes les écritures.

Si vous voulez un effacement sécurisé, cela ne fera pas l'affaire car il restera encore quelques traces des données d'origine si vous les mettez à zéro. En règle générale, vous voudriez jusqu'à trois écritures aléatoires, ce qui signifierait copier à partir /dev/urandomde /dev/zero- beaucoup plus lent mais plus sûr. Certains peuvent suggérer que vous utilisiez /dev/randoml'appareil pour les données aléatoires «pures» - pas de pseudo-aléatoire - mais à cette fin, les chances que quelqu'un parvienne à casser la graine PRNG et à masquer avec succès les données sont essentiellement négligeables.

Si vous êtes vraiment paranoïaque, vous devez jeter le dispositif de stockage dans un four pour qu'il se démagnétise / se décharge.

Comme il l'a fait dans votre machine virtuelle, il essuiera le disque et rendra votre système inutilisable.

Cependant, si vous avez une sorte de «suppression de panique» à l'esprit, cela ddpourrait ne pas être assez rapide pour cela et je ne suis pas sûr qu'il existe des commandes ou des programmes plus rapides qui le fournissent dans ce cas.

Cela devrait fonctionner, le processus en cours se déroule dans Ram et n'a pas besoin du disque. J'utiliserais de toute façon un système en direct à partir d'un CD ou d'une clé USB. Il existe même dban, un linux en direct spécialisé pour l'effacement des disques.

L'écrasement de votre disque avec des zéros est une sauvegarde, mais si vous êtes suffisamment paranoïaque ou avez des règles légales, vous pouvez écraser plusieurs fois avec des données aléatoires.

Soyez prudent lorsque vous utilisez l'écrasement SSD ne garantit pas la suppression de toutes les données en raison du niveau d'usure.

Si vous utilisez le chiffrement complet du disque (luks), vous n'avez pas besoin de supprimer le disque complet, la suppression de l'en-tête luks suffit.