Wie lösche ich freien Speicherplatz in Linux?

srm wurde entwickelt, um Daten auf Datenträgern auf sichere Weise zu löschen, die nicht von Dieben, Strafverfolgungsbehörden oder anderen Bedrohungen wiederhergestellt werden können. Der Wipe-Algorithmus basiert auf dem Paper „Secure Deletion of Data from Magnetic and Solid-State Memory“, das auf dem 6. Usenix Security Symposium von Peter Gutmann, einem der führenden zivilen Kryptographen, präsentiert wurde.

Der sichere Datenlöschprozess von srm läuft folgendermaßen ab:

• 1 Durchlauf mit 0xff
• 5 zufällige Durchgänge. /dev/urandom wird für einen sicheren RNG verwendet, sofern verfügbar.
• 27 Pässe mit speziellen Werten definiert von Peter Gutmann.
• 5 zufällige Durchgänge. /dev/urandom wird für einen sicheren RNG verwendet, sofern verfügbar.
• Benennen Sie die Datei in einen zufälligen Wert um
• Kürzen Sie die Datei

Als zusätzliche Sicherheitsmaßnahme wird die Datei im O_SYNC-Modus geöffnet und nach jedem Durchlauf ein fsync() Anruf erfolgt. srm schreibt 32.000 Blöcke aus Geschwindigkeitsgründen, füllt Puffer von Disk-Caches, um sie zum Leeren zu zwingen, und überschreibt alte Daten, die zu der Datei gehörten.

Der schnellste Weg, wenn Sie nur einen einzigen Durchgang benötigen und einfach alles durch Nullen ersetzen möchten, ist:

cat /dev/zero > zero.file
sync
rm zero.file

(aus einem Verzeichnis auf dem Dateisystem ausführen, das Sie löschen möchten)
_{(der sync Befehl ist eine Paranoia-Maßnahme, die sicherstellt, dass alle Daten auf die Festplatte geschrieben werden - ein intelligenter Cache-Manager könnte herausfinden, dass er Schreibvorgänge für alle anstehenden Blöcke abbrechen kann, wenn die Datei nicht verknüpft ist)}

Während dieses Vorgangs gibt es eine Zeit, in der überhaupt kein freier Speicherplatz auf dem Dateisystem vorhanden ist, was mehrere zehn Sekunden dauern kann, wenn die resultierende Datei groß und fragmentiert ist und das Löschen eine Weile dauert. So reduzieren Sie die Zeit, in der der freie Speicherplatz vollständig Null ist:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file

Dies sollte ausreichen, um jemanden daran zu hindern, die alten Dateiinhalte ohne eine teure forensische Operation zu lesen. Für eine etwas sicherere, aber langsamere Variante ersetzen Sie /dev/zero mit /dev/urandom . Für mehr Paranoia führen Sie mehrere Schritte mit /dev/urandom aus , aber wenn Sie so viel Aufwand brauchen, die shred Dienstprogramm aus dem Coreutils-Paket ist der richtige Weg:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file

Beachten Sie, dass die kleine Datei oben geschreddert wird, bevor die größere erstellt wird, sodass sie entfernt werden kann, sobald die größere fertig ist, anstatt warten zu müssen, bis sie geschreddert ist, wodurch das Dateisystem für die benötigte Zeit keinen freien Speicherplatz hat. Der Shred-Vorgang dauert lang Zeit für eine große Datei und es sei denn, Sie versuchen, etwas vor der NSA zu verbergen, ist meiner Meinung nach nicht wirklich notwendig.

All dies sollte auf jedem Dateisystem funktionieren.

Dateigrößenbeschränkungen:

Wie DanMoulding in einem Kommentar weiter unten anmerkt, kann dies auf einigen Dateisystemen zu Problemen mit Dateigrößenbeschränkungen führen.

Für FAT32 wäre es auf jeden Fall aufgrund des Dateilimits von 2 GiB bedenklich sein:Die meisten Volumes sind heutzutage größer als dieses (8 TiB ist das Volume-Größenlimit IIRC). Sie können dies umgehen, indem Sie die große cat /dev/zero verrohren Ausgabeausgabe durch split um mehrere kleinere Dateien zu generieren und die Schredder- und Löschstufen entsprechend anzupassen.

Bei ext2/3/4 ist dies weniger problematisch:Mit dem standardmäßigen/allgemeinen 4K-Block beträgt die Dateigrößenbeschränkung 2 TiB, sodass Sie eine riesige haben müssten Volumen, damit dies ein Problem darstellt (die maximale Volumengröße unter diesen Bedingungen beträgt 16 TiB).

Mit dem (noch experimentellen) btrfs betragen sowohl die maximale Datei- als auch die Volumengröße gewaltige 16EiB.

Unter NTFS ist die maximale Dateilänge in manchen Fällen sogar größer als die maximale Datenträgerlänge.

Anlaufstellen für weitere Informationen:
http://en.wikipedia.org/wiki/Ext3#Size_limits
http://en.wikipedia.org/wiki/Btrfs
http://en.wikipedia.org/wiki/Ntfs#Scalability

Virtuelle Geräte

Wie kürzlich in den Kommentaren erwähnt, gibt es zusätzliche Überlegungen für virtuelle Geräte:

• Für spärlich zugewiesene virtuelle Laufwerke andere Methoden wie die von zerofree verwendeten wird schneller sein (allerdings im Gegensatz zu cat und dd dies ist kein Standardtool, auf das Sie sich verlassen können, dass es in so ziemlich jedem Unix-ähnlichen Betriebssystem verfügbar ist).

• Beachten Sie, dass das Nullsetzen eines Blocks auf einem virtuellen Gerät mit geringer Dichte möglicherweise nicht den Block auf dem zugrunde liegenden physischen löscht Ich würde sogar so weit gehen zu sagen, dass dies unwahrscheinlich ist - der Virtual Disk Manager wird den Block einfach als nicht mehr verwendet markieren, damit er später etwas anderem zugewiesen werden kann.

• Selbst bei virtuellen Geräten mit fester Größe haben Sie möglicherweise keine Kontrolle darüber, wo sich das Gerät physisch befindet, sodass es jederzeit an seinem aktuellen Standort oder auf einen neuen Satz physischer Festplatten verschoben werden kann, und Sie können höchstens den aktuellen Standort löschen, nicht alle früheren Orte, an denen sich der Block möglicherweise in der Vergangenheit befunden hat.

• Für die oben genannten Probleme auf virtuellen Geräten:Wenn Sie nicht die Hosts steuern und deren nicht zugeordneten Speicherplatz nach dem Löschen der Festplatten in der VM oder dem Verschieben des virtuellen Geräts sicher löschen können, können Sie danach nichts dagegen tun Tatsache. Die einzige Möglichkeit besteht darin, von Anfang an die Festplattenverschlüsselung zu verwenden also wird überhaupt nichts unverschlüsselt auf das physische Medium geschrieben. Es kann natürlich immer noch die Forderung nach einer Löschung des freien Speicherplatzes innerhalb der VM bestehen. Beachten Sie auch, dass FDE spärliche virtuelle Geräte viel weniger nützlich machen kann, da die Virtualisierungsebene nicht wirklich erkennen kann, welche Blöcke nicht verwendet werden. Wenn die Dateisystemebene des Betriebssystems Trimmbefehle an das virtuelle Gerät sendet (als ob es sich um eine SSD handelt) und der virtuelle Controller diese interpretiert, kann dies das Problem lösen, aber ich kenne keine Umstände, unter denen dies tatsächlich passiert, und eine breitere Eine Diskussion darüber ist eine Angelegenheit für einen anderen Ort (wir nähern uns bereits dem Thema der ursprünglichen Frage, wenn dies also Ihr Interesse geweckt hat, können einige Experimente und / oder Folgefragen angebracht sein).

WARNUNG

Ich war schockiert darüber, wie viele Dateien Photorec selbst nach dem Löschen von meiner Festplatte abrufen konnte.

Ob es mehr Sicherheit bringt, den „Freiraum“ nur 1 Mal mit 0x00 oder 38 Mal mit unterschiedlichen kabbalistischen Maßstäben zu füllen, ist eher eine akademische Diskussion. Der Autor des wegweisenden Papiers zum Thema Schreddern aus dem Jahr 1996 schrieb selbst einen Epilog, in dem er sagte, dass dies für moderne Hardware veraltet und unnötig sei. Es gibt keinen dokumentierten Fall, in dem Daten physisch durch Nullen ersetzt und anschließend wiederhergestellt wurden.

Die wahre fragile Verbindung in diesem Verfahren ist das Dateisystem . Einige Dateisysteme reservieren Speicherplatz für spezielle Zwecke und werden nicht als "freier Speicherplatz" zur Verfügung gestellt. Aber Ihre Daten könnten dort sein . Dazu gehören Fotos, persönliche Klartext-E-Mails, was auch immer. Ich habe gerade reserviert+Leerzeichen+ext4 gegoogelt und festgestellt, dass 5 % meiner home Partition wurde reserviert. Ich denke, hier ist photorec habe so viel von meinen Sachen gefunden. Fazit:Die Shredder-Methode ist nicht die wichtigste, auch die Multi-Pass-Methode lässt noch Daten an Ort und Stelle .

Sie können es mit # tune2fs -m 0 /dev/sdn0 versuchen bevor Sie es montieren. (Wenn dies nach dem Neustart die Root-Partition sein wird, stellen Sie sicher, dass Sie -m 5 ausführen oder -m 1 nach dem Unmounten).

Aber auf die eine oder andere Weise kann noch etwas Platz übrig sein.

Der einzige wirklich sichere Weg besteht darin, die gesamte Partition zu löschen, ein Dateisystem erneut zu erstellen und dann Ihre Dateien aus einem Backup wiederherzustellen.

Schneller Weg (empfohlen)

Führen Sie es von einem Verzeichnis auf dem Dateisystem aus, das Sie löschen möchten:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

Hinweise:Der Zweck der kleinen Datei besteht darin, die Zeit zu verkürzen, in der der freie Speicherplatz vollständig Null ist; Der Zweck der Synchronisierung besteht darin, sicherzustellen, dass die Daten tatsächlich geschrieben werden.

Dies sollte für die meisten Leute ausreichen.

Langsamer Weg (paranoid)

Es gibt keinen dokumentierten Fall, in dem Daten nach der oben genannten Bereinigung wiederhergestellt wurden. Es wäre teuer und ressourcenintensiv, wenn überhaupt möglich.

Wenn Sie jedoch Grund zu der Annahme haben, dass Geheimdienste eine Menge Ressourcen aufwenden würden, um Ihre Dateien wiederherzustellen, sollte dies ausreichen:

dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file

Es dauert viel länger.

Warnung. Wenn Sie den paranoiden Weg gewählt haben, möchten Sie danach immer noch schnell wischen, und das ist keine Paranoia. Das Vorhandensein von rein zufälligen Daten ist einfach und kostengünstig zu erkennen und weckt den Verdacht, dass es sich tatsächlich um verschlüsselte Daten handelt. Sie können unter Folter sterben, weil Sie den Entschlüsselungsschlüssel nicht preisgegeben haben.

Sehr langsamer Weg (verrückt paranoid)

Sogar der Autor des bahnbrechenden Artikels über Schreddern aus dem Jahr 1996 schrieb einen Epilog, in dem er sagte, dass dies veraltet und für moderne Hardware unnötig sei.

Aber wenn Sie noch viel Freizeit haben und es Ihnen nichts ausmacht, Ihre Festplatte mit viel Überschreiben zu verschwenden, los geht's:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file

Hinweis:Dies entspricht im Wesentlichen der Verwendung des Tools zum sicheren Löschen.

Vor der Bearbeitung war dieser Beitrag eine Neufassung von David Spilletts. Der "cat"-Befehl erzeugt eine Fehlermeldung, aber ich kann keine Kommentare zu den Beiträgen anderer Leute schreiben.