Effacez en toute sécurité un serveur Linux entier avec lui-même

J'ai un accès ssh à distance et un accès root. Je n'ai pas d'accès physique. Je ne cherche pas de solutions impliquant le démarrage dans quoi que ce soit, je veux le faire à partir de ce qui est en cours d'exécution.

Le système d'exploitation est SL6. Existe-t-il un moyen de charger tout ce dont vous avez besoin dans la RAM et d'utiliser dd ou similaire pour effacer en toute sécurité le disque entier? Évidemment, cela entraînera une boîte qui ne fonctionnera pas à la fin, mon résultat escompté.

Il semble que cela devrait être possible.

Deux ajouts plus intéressants:

Être capable de ssh, d'exécuter l'écran, d'exécuter la commande dd et de se détacher. Connectez-vous une semaine plus tard une fois l'opération terminée. :)
D'une manière ou d'une autre, vous avez une barre de progression?

Mise à jour : je vais maintenant avec l'option chroot. En cours:

mkdir /dev/shm/ramdisk/ && cd ramdisk && mkdir bin lib64 && cd /lib64 && cp ld-linux-x86-64.so.2 libc.so.6 libdl.so.2 libpthread.so.0 librt.so.1 libtinfo.so.5 /dev/shm/ramdisk/lib64 && cd /bin && cp bash dd /dev/shm/ramdisk/bin && cd /dev/shm/ramdisk && chroot .

Ce qui fonctionne (!) Mais j'ai toujours besoin de / dev / zero et / dev / sda. Des idées là-bas?

Mise à jour 2012-07-20:

mkdir /dev/shm/ramdisk/ && cd /dev/shm/ramdisk && mkdir bin lib64 && cd /lib64 && cp ld-linux-x86-64.so.2 libc.so.6 libdl.so.2 libpthread.so.0 librt.so.1 libtinfo.so.5 /dev/shm/ramdisk/lib64 && cd /bin && cp bash dd /dev/shm/ramdisk/bin && mkdir /dev/shm/ramdisk/dev && cd /dev/shm/ramdisk/dev && cp -a /dev/zero . && cp -a /dev/sda . && cd .. && chroot . dd if=/dev/zero of=/dev/sda bs=1M

Ce qui semble faire quelque chose, mais j'aimerais avoir une sorte d'indicateur de progression si possible, ainsi qu'un moyen de détacher puis d'établir une nouvelle connexion ssh plus tard.

linux security dd secure-delete

— pantalon de chat
source

Essayez-le;) Finalement dans une VM d'abord.

— Frederik Nielsen

Lorsque vous dites que le démarrage n'est pas une option, dites-vous que toucher la console / insérer le support n'est pas une option, ou que la machine ne peut pas être redémarrée du tout? Parce que vous pourriez potentiellement ajouter une image livecd sur votre disque. Lorsque le système redémarre, il démarre l'image livecd, se charge en mémoire et démarre un serveur SSH.

— Zoredache

En effet, je n'ai aucun accès physique. En tout cas, je connais la solution live cd, donc je suis intéressé à apprendre une autre solution, en particulier avec les conditions posées par ce problème. Merci!!

— pantalon pour chat

Spéculation pure: je me demande si chrootentrer dans un RAMdisk peut aider à cela. Deuxième spéculation: partitionnez une partie du disque, réécrivez grub et redémarrez.

— Hyppy

Il n'y a qu'une seule option sécurisée , si la confidentialité des données est vraiment un problème: vous devez détruire le disque. Les options normales sont: 1) démagnétiseur, 2) ponceuse à disque, 3) marteau perforateur. Si vous pouvez redémarrer, il existe une option pour exécuter certains outils de nettoyage de disque au niveau DoD, mais vous avez éliminé les redémarrages en option.

— Mike Pennington

Réponses:

Créez une image dans un disque virtuel contenant tous les outils dont vous avez besoin pour faire exploser le système, puis pivot_rootexécutez l'outil, c'est parti. Faisant pivoter hors d'un système complet n'est pas trivial, mais il peut être fait si vous savez ce que vous faites.

— womble
source

C'est une bonne idée. Alors la question devient alors: quel est le strict minimum pour moi de jeter dans un disque RAM pour être en mesure d'accomplir cela? Permettez-moi d'essayer de comprendre cela par moi-même, puis je commenterai ici ou publierai un nouveau fil si je ne peux pas le comprendre. Merci!

— pantalon de chat

je l'ai fait plusieurs fois en exécutant

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

pas de préparations supplémentaires. ça a marché. le système fonctionnait bien pendant des jours après la fin de dd [réponse aux pings, transmission des paquets].

— pQd
source

Un seul passage avec / dev / zero ne serait pas très sécurisé selon la sécurité dont l'OP en a besoin.

— Aaron Copley

Je viens d'essayer cela, et le résultat a été une panique du noyau. J'ai une dizaine de machines supplémentaires sur lesquelles je peux essayer. Que dois-je essayer ensuite?

— pantalon pour chat

Avez-vous des partitions spécifiques avec des données confidentielles? Vous pouvez essayer de les sabler d'abord avant de faire quoi que ce soit qui pourrait faire tomber la boîte.

— cjc

J'avais l'impression que le fait d'avoir besoin de plus d'un passage est une idée fausse courante. anti-forensics.com/disk-wiping-one-pass-is-enough Je pense qu'il est difficile de récupérer des données après un seul passage avec / dev / zero, et jusqu'à présent, personne n'a pu le faire.

— pantalon pour chat

@catpants: verrouillez les fichiers nécessaires en mémoire avec vmtouch puis exécutez tout ce dont vous avez besoin.

— womble

Suggestion: utilisez un chiffon plutôt que dd - il prend en charge un essuyage sécurisé à plusieurs passes.

Autre suggestion: arrêtez autant de services et supprimez autant de packages que possible. Supprimez toutes les données dont vous n'avez pas besoin, ainsi que tous vos anciens fichiers journaux et données. Remplissez autant que possible l'espace libre résultant avec un seul fichier, puis exécutez le nettoyage sur ce fichier. Ne supprimez pas ce fichier. Cela permettra de nettoyer la majeure partie du disque avant de rendre le système inutilisable.

L'idée de ramdisk chroot serait alors nécessaire pour vous aider à surmonter tous les drames en revenant dans la boîte, mais vous voudrez probablement arrêter le système autant que possible avant de faire l'effacement final, car la journalisation et d'autres démons qui écrivent sur le disque pourrait signifier que les données réelles sont écrites sur des blocs de données libres pendant l'effacement, avant que la structure du système de fichiers ne soit complètement corrompue.

— Paul Gear
source