Nettoyez en toute sécurité un serveur Linux distant sans tête

18

Je suis sur le point de mettre fin à ma relation avec mon fournisseur d'hébergement depuis de nombreuses années, mais j'aimerais bien nettoyer la boîte avant de le faire. Il s'agit d'un serveur dédié exécutant Debian sur un seul lecteur EXT3 et bien que j'aie un accès root, je ne peux pas démarrer un média alternatif car il est sans tête dans un rack quelque part.

Je n'ai pas besoin de plusieurs passes, mais j'aimerais effacer l'espace libre si possible. Fondamentalement, je voudrais m'éloigner et m'assurer de ne laisser aucune de mes données personnelles derrière. Je crains que la boîte ne se bloque avant d'avoir fini d'essuyer / synchroniser le système de fichiers si je lancesrm -R -s /

— notpeter
source

à mon humble avis, utilisez le dd (en bas)

— Some Linux Nerd

4

J'ai réussi à passer au travers rm -rf --no-preserve-root /sans que le système ne tombe en panne en premier, et sans rien laisser sur le disque.

— Fahad Sadah
source

J'ai exécuté srm sur mes répertoires de données, puis rm -rf --no-preserve-root /via SSH pour nettoyer le reste. Il a jeté quelques erreurs dans / dev ands puis terminé; Je ne savais pas trop quoi faire à l'invite bash. Sans / bin / ls ou / sbin / shutdown, je n'ai pas pu confirmer le succès. Twas anticlimactic; J'étais mentalement préparé à ce qu'il plante, pas à une session de noyau zombie et sshd.

— notpeter

7

Ce n'est pas sûr. Les données ne sont pas effacées et la suppression est toujours possible. Mieux vaut ddplutôt sur le disque.

— qris

10

Le programme d'installation CentOS (anaconda) fourni avec les images PXE comprend un serveur VNC, vous pouvez donc modifier votre configuration grub pour démarrer le programme d'installation CentOS, en passant les réponses aux questions du programme d'installation pré-étape 2 sur la ligne grub, redémarrer puis VNC à l'installateur.

Maintenant, si ma mémoire est bonne, à partir de ce programme d'installation, vous devriez pouvoir déposer dans un shell, à partir duquel vous pouvez accéder et détruire le disque.

Copiez les fichiers vmlinuz et initrd depuis le répertoire PXE dans la distribution CentOS ( http://mirror.centos.org/centos/5/os/i386/images/pxeboot/ ) vers / boot et modifiez votre configuration grub:

par défaut 0
délai d'expiration 5
titre CentOS
racine (hd0,0)
kernel /boot/vmlinuz.cent.pxe vnc vncpassword = MOT DE PASSE ip sans tête = masque de réseau IP = 255.255.255.0 passerelle = GATEWAYIP dns = 8.8.8.8 ksdevice = méthode eth0 = http: //mirror.centos.org/centos/5/os / i386 / lang = en_US keymap = us
initrd /boot/initrd.img.cent.pxe

Soit dit en passant, toute société d'hébergement décente devrait être prête à détruire vos disques pour vous.

— Stephen Nelson-Smith
source

3

Ce n'est pas une «société d'hébergement décente», d'où mon besoin de quitter et d'essuyer mes disques.

— notpeter

Je n'ai pas utilisé cette méthode, mais utiliser GRUB pour démarrer une image de secours minimale préconfigurée pour activer vnc (ou même simplement SSH) est totalement faisable. Si vous vous trompez, vous vous retrouvez potentiellement avec un système qui nécessite une intervention manuelle pour redémarrer correctement, donc vaut probablement la peine d'être testé sur une machine virtuelle en premier.

— notpeter

1

Un mot sur l'ordre dans lequel les choses sont essuyées pourrait être utile. En essuyant d'abord toutes les partitions sauf celle qui contient /boot, vous pourrez recommencer au cas où la machine serait redémarrée au milieu du processus. S'il /bootse trouve sur la /partition, on peut supprimer tous les fichiers à l'extérieur de /bootet essuyer l'espace libre avant de finalement essuyer la partition entière. Cela minimiserait la quantité de données restantes sur le disque au cas où il serait redémarré une fois que vous auriez tellement essuyé, que vous ne seriez plus en mesure de le démarrer.

— kasperd

7

Avant de détruire le système d'exploitation, vous pouvez supprimer tout élément sensible et zéro (en utilisant dd if = / dev / zero of = justabigfile).

Et je crois que la plupart des systèmes survivront un DD à un système en cours d'exécution assez longtemps pour écraser le disque entier. Il n'y a aucun moyen de revenir si ce n'est pas le cas, bien sûr.

— Joris
source

4

Si vous supprimez tous les fichiers qui vous préoccupent avant de le faire, swapoff votre partition de swap, essuyez la partition de swap (en utilisant wipe ou dd), alors ce qui précède devrait être assez sûr. Vous devrez le faire en tant que root pour dépasser les 5% réservés pour root, et vous pourriez ne pas effacer tous les noms de fichiers, mais les données devraient avoir disparu.

— Slartibartfast

6

Ma solution implique une approche en plusieurs étapes faisant certaines des choses ci-dessus, mais impliquant également un chroot dans le ram qui devrait permettre à dd de finir de vider complètement le disque.

Supprimez d'abord toutes vos données sensibles, en laissant les fichiers nécessaires à l'exécution du système d'exploitation. Ensuite, faites cela (pas dans un script, faites-le une commande à la fois):

mkdir /root/tmpfs/
mount -t tmpfs tmpfs /root/tmpfs/
debootstrap --variant=buildd --arch amd64 precise /root/tmpfs/
mkdir /root/tmpfs/mainroot
mount --bind / /root/tmpfs/mainroot
mount --bind /dev /root/tmpfs/dev
chroot /root/tmpfs/

# fill mainroot partition to wipe previously deleted data files
dd if=/dev/zero of=/mainroot/root/bigfile; rm /mainroot/root/bigfile
# now clobber the entire partition, probably won't be able to stay connected to ssh after starting this
# obviously change '/dev/md1' to the device that needs cleared
nohup dd if=/dev/zero of=/dev/md1 >/dev/null 2>&1

Cela devrai prendre soin de ça!

— moparisthebest
source

1

Vous pouvez simplement utiliser ddpour écraser toute la partition / le disque sur un serveur en cours d'exécution sans aucun souci. Nous l'utilisons beaucoup au travail (lorsque le client ne veut pas payer pour la destruction d'un disque physique sécurisé).

En fait, vous effacez les données sans que le système de fichiers monté le sache, donc le système de fichiers commencera à paniquer lorsque ses métadonnées seront perdues, puis le système d'exploitation lui-même commencera à "s'effondrer". Cependant, ce qui est déjà dans le cache fonctionne toujours. Vous pouvez donc suivre la progression via une console distante ou KVM (ne pas l'essayer via ssh). Le système continue de fonctionner même après la ddfin, mais aucune commande ne fonctionnera et tous les démons sont probablement déjà morts.

J'utilise ces commandes: dd if=/dev/zero of=/dev/sda bs=1M & puis kill -HUP %1pour suivre la progression (dd imprimera la vitesse actuelle et la quantité de données écrites). Le réglage de la taille de bloc ( bs) est très important pour atteindre la vitesse d'écriture séquentielle du disque dur avec dd.

Chaque fois dd, j'ai pu effacer le disque jusqu'à sa fin et j'ai pu lancer la killcommande (shell intégré) jusqu'à la fin. Si vous avez un raid logiciel, vous pouvez effacer le mdpériphérique lui-même ou chaque périphérique composant individuellement.

— Marki555
source

Mon collègue l'a fait et xwindows n'a pas réussi à planter, devrait être exactement ce dont le demandeur a besoin.

— Certains Linux Nerd

1

Le protocole ATA dispose d'une commande «d'effacement sécurisé» qui, comme son nom l'indique, doit effacer en toute sécurité le disque dur entier.

Voir l'article wiki du noyau pour plus de détails, mais attention aux avertissements en haut:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

— Vladimir Panteleev
source

Mise à jour 2018: j'ai utilisé cela à plusieurs reprises avec succès pour effacer les serveurs à distance, même s'ils sont en cours d'exécution sur le système de fichiers en cours d'effacement. Étant donné que le programme émet simplement une commande ATA et attend une réponse, aucun code n'a besoin d'être exécuté sur le CPU pendant le processus de nettoyage.

— Vladimir Panteleev

0

Vous pouvez essayer d'écrire des données aléatoires sur votre disque comme ceci:

dd if=/dev/urandom of=/dev/sda

Est plus sûr que d'utiliser / dev / zero car il écrit des données aléatoires, mais c'est aussi BEAUCOUP plus lent.

— Kedare
source

En tant que personne qui ne sait pas mieux, pourquoi les gens votent-ils contre cela? N'est-ce pas une bonne pratique?

— Canadian Luke REINSTATE MONICA

@CanadianLuke La question concerne l'effacement sécurisé d'un serveur déjà en cours d'exécution. Vous ne pouvez pas écrire sur un lecteur monté comme celui-ci, cela ne fonctionnera donc pas.

— longneck

@longneck Merci. Pour une raison quelconque, je pensais que root pouvait faire ça ... Bien que je n'ai jamais essayé, je vais donc vous croire sur parole. Merci d'avoir expliqué

— Canadian Luke REINSTATE MONICA

@longneck ya you can, a ajouté le commentaire ci-dessus mais j'ai fait faire un collègue vraiment paranoïaque. En fait, vous pouvez débrancher complètement votre disque dur et linux continuera à tout exécuter en mémoire sans rien de plus qu'un tas de messages d'erreur d'application.

— Certains Linux Nerd

0

Quoi que vous choisissiez de faire, contactez un autre fournisseur et testez-le.

Obtenez une instance similaire sur AWS (ou gcloud ou ...) et essayez-la là, en gardant le disque, puis en l'attachant à une autre instance en tant que stockage supplémentaire et en l'analysant. dd if = sdb | HD

Presque tous vos documents sensibles devraient être en

/home
/opt
/var
/etc
/usr

Ce sont les fichiers de configuration avec des mots de passe intégrés qui dérangent la plupart des gens. Si vous savez ce qu'ils sont, recherchez tout le système de fichiers pour les éliminer.

rm supprimera les fichiers, mais un éditeur hexadécimal lira toujours le disque. Donc zéro après. Jetez un oeil à déchiqueter. Vous devriez avoir un journal de vos fichiers de configuration et où ils sont à des fins de DR, non? N'oubliez pas les fichiers crontab si vous en avez, par exemple.

L'installation de CentOS ou toute autre solution de disque virtuel est saine. Le noyau sera en mémoire, vous avez besoin de dd et de contenu bin. Mais si vous redémarrez en mode de récupération, il se peut que vous n'ayez pas de réseau ou SSH et que vous vous coupiez.

NB Kedare a une bonne idée, et si vous exécutez depuis ram lors de votre prochain redémarrage (ramdisk), cela est possible, il est très difficile de récupérer à partir des écritures / dev / zero pour commencer, donc cela n'ajoute pas vraiment de valeur à moins que votre vie en dépend?

— mckenzm
source