Sicheres Löschen eines kopflosen Remote-Linux-Servers

Ich bin kurz davor, meine langjährige Beziehung zu meinem Hosting-Provider zu beenden, aber ich möchte die Box sicher löschen, bevor ich das tue. Dies ist ein dedizierter Server, auf dem Debian auf einem einzelnen EXT3-Laufwerk ausgeführt wird, und obwohl ich Root-Zugriff habe, kann ich keine alternativen Medien booten, da sie irgendwo kopflos in einem Rack sind.

Ich benötige nicht mehrere Durchgänge, möchte aber wenn möglich freien Speicherplatz löschen. Grundsätzlich möchte ich weggehen und sicherstellen, dass ich keine meiner persönlichen Daten hinterlasse. Ich mache mir Sorgen, dass die Box abstürzen könnte, bevor das Löschen / Synchronisieren des Dateisystems abgeschlossen ist, wenn ich sie nur startesrm -R -s /

Ich bin erfolgreich durchgekommen, rm -rf --no-preserve-root /ohne dass das System zuerst abgestürzt ist und ohne dass etwas auf dem Laufwerk zurückgeblieben ist.

Das CentOS-Installationsprogramm (Anaconda), das mit den PXE-Images geliefert wird, enthält einen VNC-Server. Sie können also Ihre Grub-Konfiguration so ändern, dass das CentOS-Installationsprogramm gebootet wird. Dabei werden die Antworten auf die Fragen des Pre-Stage-2-Installationsprogramms in der Grub-Zeile weitergegeben und anschließend VNC neu gestartet an den Installateur.

Wenn mir mein Speicher nun richtig dient, sollten Sie in diesem Installationsprogramm in der Lage sein, auf eine Shell zuzugreifen, von der aus Sie auf die Festplatte zugreifen und diese zerstören können.

Kopieren Sie die Dateien vmlinuz und initrd aus dem PXE-Verzeichnis in der CentOS-Distribution ( http://mirror.centos.org/centos/5/os/i386/images/pxeboot/ ) nach / boot und ändern Sie Ihre Grub-Konfiguration:

Standardwert 0
Zeitüberschreitung 5
Titel CentOS
root (hd0,0)
kernel /boot/vmlinuz.cent.pxe vnc vncpassword = PASSWORT headless ip = IP-Netzmaske = 255.255.255.0 gateway = GATEWAYIP dns = 8.8.8.8 ksdevice = eth0 method = http: //mirror.centos.org/centos/5/os / i386 / lang = de_DE keymap = us
initrd /boot/initrd.img.cent.pxe

Im Übrigen sollte jedes anständige Hosting-Unternehmen bereit sein, Ihre Festplatten für Sie zu zerstören.

Bevor Sie das Betriebssystem zerstören, können Sie alle sensiblen und nicht gefüllten Elemente entfernen (mit dd if = / dev / zero of = justabigfile).

Und ich glaube, die meisten Systeme überleben eine dd zu einem laufenden System lange genug, um die gesamte Festplatte zu überschreiben. Es gibt natürlich keinen Weg zurück, wenn nicht.

Meine Lösung beinhaltet einen mehrstufigen Ansatz, der einige der oben genannten Schritte ausführt, aber auch eine Chroot im RAM, die es dd ermöglichen sollte, das vollständige Löschen der Festplatte abzuschließen.

Löschen Sie zuerst alle Ihre vertraulichen Daten und lassen Sie die erforderlichen Dateien für die Ausführung des Betriebssystems. Führen Sie dann Folgendes aus (nicht in einem Skript, sondern nur einen Befehl nach dem anderen):

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

Das sollte sich darum kümmern!

Sie können einfach dddie gesamte Partition / Festplatte auf einem laufenden Server ohne Sorgen überschreiben. Wir verwenden es häufig bei der Arbeit (wenn der Kunde nicht für die Zerstörung sicherer physischer Datenträger zahlen möchte).

Sie löschen die Daten tatsächlich, ohne dass das gemountete Dateisystem dies merkt, sodass das Dateisystem ausfällt, wenn seine Metadaten verloren gehen. Das Betriebssystem selbst beginnt zu "kollabieren". Was sich jedoch bereits im Cache befindet, funktioniert immer noch. So können Sie den Fortschritt über die Remote-Konsole oder KVM überwachen (habe es nicht über ssh versucht). Das System läuft auch nach Abschluss des ddVorgangs weiter, es wird jedoch kein Befehl ausgeführt, und wahrscheinlich sind alle Dämonen bereits tot.

Ich benutze diese Befehle: dd if=/dev/zero of=/dev/sda bs=1M & und dann kill -HUP %1, um den Fortschritt zu überwachen (dd druckt die aktuelle Geschwindigkeit und die Menge der geschriebenen Daten aus). Das Einstellen der Blockgröße ( bs) ist sehr wichtig, um die Schreibgeschwindigkeit für die Festplattenfolge zu erreichen dd.

Jedes Mal ddwar es möglich, die Festplatte bis zum Ende zu löschen und ich konnte den killBefehl (Shell eingebaut) bis zum Ende ausgeben . Wenn Sie einen Software-Raid haben, können Sie entweder das mdGerät selbst oder jedes Komponentengerät einzeln löschen.

Das ATA-Protokoll verfügt über einen "Secure Erase" -Befehl, der, wie der Name schon sagt, die gesamte Festplatte sicher löschen soll.

Weitere Informationen finden Sie im Wiki-Artikel zum Kernel. Beachten Sie jedoch die Warnungen oben:

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

Sie könnten versuchen, zufällige Daten wie folgt auf Ihre Festplatte zu schreiben:

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

Ist sicherer als / dev / zero, weil es zufällige Daten schreibt, aber es ist auch VIEL langsamer.

Wofür auch immer Sie sich entscheiden, wechseln Sie zu einem anderen Anbieter und testen Sie ihn.

Holen Sie sich eine ähnliche Instanz auf AWS (oder gcloud oder ...) und versuchen Sie es dort, behalten Sie die Festplatte bei und hängen Sie sie dann als zusätzlichen Speicher an eine andere Instanz an und scannen Sie sie. dd if = sdb | hd

Fast alle Ihre sensiblen Materialien sollten in sein

/home
/opt
/var
/etc
/usr

Es sind die Konfigurationsdateien mit eingebetteten Passwörtern, die die meisten Leute stören. Wenn Sie wissen, was sie sind, durchsuchen Sie das gesamte Dateisystem, um sie auszurotten.

rm löscht Dateien, aber ein Hex-Editor liest die Festplatte weiterhin. Also danach null. Schau dir Shred an. Du solltest ein Protokoll deiner Konfigurationsdateien haben und wo sie für DR-Zwecke sind, oder? Vergessen Sie Crontab-Dateien nicht, wenn Sie darin beispielsweise Passwörter haben.

Die CentOS-Installation oder eine beliebige Ramdisk-Lösung ist fehlerfrei. Der Kernel wird sich im Speicher befinden, Sie benötigen dd und einige Bin-Inhalte. Wenn Sie jedoch im Wiederherstellungsmodus neu starten, verfügen Sie möglicherweise nicht über ein Netzwerk oder SSH und schneiden sich ab.

NB Kedare hat eine gute Idee, und wenn Sie beim nächsten Neustart (RAM-Disk) von RAM aus starten, ist es sehr schwierig, Schreibvorgänge von / dev / zero wiederherzustellen hängt davon ab?