staging.inyokaproject.org

Hallo,

Ich einen neuen Wiki-Eintrag verfasst, den ich nach der Korrektur gerne im Hauptartikel Daten sicher löschen verlinken möchte. Ich beschreibe darin, wie man den freien Festplattenspeicher überschreiben/löschen kann. Das ist eine Funktion, die meine Bekannten und ich häufig verwenden (unter Windows gibt es dafür das leicht zu bedienende "Eraser") und für die ich schon immer ein einfach zu bedienendes Ubuntu-Programm mit GUI vermisst habe. Zumindest gibt es einige Terminalmöglichkeiten, die ich in meinem Eintrag beschreibe.

Ich denke, der Eintrag ist wichtig, da ich mich bis jetzt immer wieder von neuem durch irgendwelche über Google gefundenen Forendiskussionen arbeiten musste.

Dies ist mein erster Eintrag hier im Wiki. Habt bitte Gnade, falls ich irgendwelche Layoutvorgaben nicht präzise umgesetzt habe. 😉

Unabhängig von allem anderen: Dir ist klar, dass einmaliges Überschreiben mit /dev/zero reicht vollkommen (das zeigen kryptoanalysen). Dieser Hinweis sollte im Artikel nicht fehlen.

Verstehe ich das richtig, dass mit den Methoden

• nur als "gelöscht markierte" Dateien und noch nicht beschriebene Festplattenbereiche überschrieben werden?

• andere Daten, die sich auf der Festplatte (der Partition) befinden, nicht angetastet (überschrieben) werden?

Oder geht es nur um das Überschreiben einer kompletten Partition (inkl. vorhandener Daten)?

@redknight: Nein, dass /dev/zero "reicht", wusste ich nicht. Ich habe /dev/urandom und /dev/random verwendet, da /dev/zero aus irgendeinem Grund bei mir nicht funktionierte. Der Eintrag kann gerne auf zero "umgemünzt" werden oder um deinen Kommentar ergänzt werden. Wichtig war mir nur, dass Suchende irgendeine Antwort finden. Hat zero einen Vorteil? Ist es möglicherweise schneller als urandom?

EDIT: Ich habe einen entsprechenden Hinweise hinzugefügt. Kennst du zufällig noch eine Quelle, auf die verwiesen werden kann bezüglich der Sicherheit von /dev/zero?

@kaputtnik: Ich kann den ersten Teil deiner Frage nicht "technisch tief" beantworten, aber ich gehe davon aus, dass es genau wie von dir angenommen funktioniert. Es geht nicht um das Überschreiben einer kompletten Partition. Dafür existiert bereits ein Wiki-Eintrag: Skripte/Gerät mit Pseudozufallszahlen überschreiben.

Etwas undiplomatisch geradeheraus gesagt: Mir kommt das als paranoides, esoterisches Gefummel vor.

Wenn man ernstlich befürchtet dass nach dem Löschen etwas gefunden wird, dann soll man die ganze Festplatte verschlüsseln. Das Ergebnis ist ein Bytemuster, dass von einem Muster, welches ein guter Zufallsgenerator generiert, nicht zu unterscheiden ist.

In diesem Falle ist jeder Löschvorgang unwiederbringlich, sofern man es schafft den Rechner auszuschalten, so dass die Verschlüsselung nicht aufgehoben ist, und solange man das Passwort für sich behält.

Das ist gewiss schneller, als im Notfall ein Löschen anzustoßen, dass Gigabytes überschreiben muss.

Das mehrfache Überschreiben ist dann der Punkt wo es esoterisch wird. Wenn es wirklich machbar wäre, auf dem Platz, der konventionell ein einzelnes Byte beherbergt, eine ganze Historie von 3, 4 oder 7, 23 und mehr Bytes zu speichern, dann würden die Festplattenhersteller nicht 2 TB sondern 46 TB-große Platten verkaufen.

Die Gutmannplatten waren zum Zeitpunkt seiner Untersuchung nicht mehr State of the art, und er konnte einzelne Bytes mit einer gewissen Wahrscheinlichkeit rekonstruieren. Wenn man jetzt auf der eigenen Platte nicht Bytes hat, wo jedes einzelne Byte schwer belastend oder hoch geheim ist, dann weiß eine neugierige Nase doch schon mal nicht, wo auf der Platte überhaupt die Information zu suchen ist, sofern diese einmal überschrieben wurde. Wer soll das in welcher Zeit mit Mikroskopen und was untersuchen? Wie lange dauert es 1 Million Bytes zu analysieren - geschweige 2, 7 oder 23 unterschiedliche Layer? Auf einer 1 TB-Platte hast Du 1 Million MB.

Im Prinzip ist es doch wurscht, ob ich mit Zufallszahlen oder "0" oder mit "1" überschreibe.

Aaron Pierce schrieb:

Ich kann den ersten Teil deiner Frage nicht "technisch tief" beantworten, aber ich gehe davon aus, es genau wie von dir angenommen funktioniert.

Hm, heißt das jetzt das Du das nicht ausprobiert hast?

Also nehmen wir an, das vorhandene Dateien erhalten bleiben... Gut ☺

Es geht nicht um das Überschreiben einer kompletten Partition. Dafür existiert bereits ein Wiki-Eintrag.

Ich verstehe nicht ganz, warum man gelöschte Dateien überschreiben sollte, wenn nicht gelöschte Dateien erhalten bleiben. Wenn ich die Datei Feundin_nackt.jpg lösche und dafür ein neues Bild Feundin_2_nackt.jpg anlege, ist das doch wurscht 😉 Im Laufe der Zeit werden die als gelöscht markierten Dateien ja eh mit neuen Daten überschrieben.

Aber egal: Es sollte auf jeden Fall etwas genauer erläutert werden.

Folgender Befehl füllt den freien Speicher mit einer Datei (Name: muelldatei) aus Pseudozufallszahlen im aktuellen Verzeichnis.

Was heißt hier „im aktuellen Verzeichnis“? Wenn ich den Befehl in ~/Bilder ausführe, wird nur dieses Verzeichnis überschrieben? Ich glaube kaum.

Nach vollständigem Füllen des Speichers sollte eine entsprechende Fehlermeldung erscheinen und die Datei sollte gelöscht werden.

Was für eine Fehlermeldung? Ich nehme an, so etwas wie "Datenträger ist voll"? Ist ein Löschen denn Problemlos möglich, wenn die Partition zu 100% voll ist? Bei einem einem eingehängten /home ist das sicherlich nicht ohne weiteres möglich. Zumindest gab es da neulich mal einen Thread dazu, wo ein löschen von einem vollen /root-Verzeichnis nicht ohne weiteres möglich war.

Das bringt mich zu der Frage, wie sich das generell bei Partitionen verhält, in denen ja durchaus während des Schreibvorgangs noch andere Dateien geschrieben werden könnten. zB.: Logdateien, Browsercache oder jemand versucht seine ultrawichtige Masterarbeit abzuspeichern.

Das Programm sfill implementiert die sehr sichere, lange dauernde und Festplatten-schädliche Gutmann-Methode.

Was heißt denn "Festplatten-schädliche" Methode? Hier wäre ein Link auf Gutmann-Methode schön, was aber die Schädlichkeit auch nicht erklärt.

@user_unknown: Der Wikieintrag wirbt nicht für mehrfaches Überschreiben. Vielmehr weist er bezüglich "sfill", welches standardmäßig die Gutmann-Methode implementiert, sogar daraufhin, dass auch mit "sfill" viel weniger Überschreibdurchgänge möglich sind.

@kaputtnik: Ich habe die Methode ausprobiert. Vorhandene Dateien bleiben erhalten. Eine kleine Menge des freien Speichers wird nicht überschrieben (entsprechender Hinweis eingefügt). Ich kann nicht "technisch tief" beantworten, ob nicht doch weitere Teile (und welche) des freien Speichers unüberschrieben bleiben.

"Im aktuellen Verzeichnis" bedeutet, dass die anwachsende "Mülldatei" in dem Verzeichnis angelegt wird, in welchem man sich im entsprechenden Terminal gerade befindet.

Die Fehlermeldung lautet "Auf dem Gerät ist kein Speicherplatz mehr verfügbar". Ich habe den Wikieintrag dementsprechend geändert. Die Datei dann zu löschen ist problemlos möglich.

Das Verhalten bei parallelen Speichervorgängen hängt vom Dateisystem der entsprechenden Partition ab.

Die Schädlichkeit der Gutmann-Methode besteht in der Abnutzung des Speichers durch die hohe Anzahl an Schreibvorgängen. Ich habe versucht in meinem Satz Vor- und Nachteile der Methode zu erwähnen.

Diesen Vorgang abhängig vom Sicherheitsbedürfnis mehrfach wiederholen.

... habe ich gelesen.

Zum Beispiel ermöglicht folgender Befehl nur zwei Überschreibdurchgänge

... wo doch einer reicht.

Aaron Pierce schrieb:

@redknight: Nein, dass /dev/zero "reicht", wusste ich nicht. Ich habe /dev/urandom und /dev/random verwendet, da /dev/zero aus irgendeinem Grund bei mir nicht funktionierte. Der Eintrag kann gerne auf zero "umgemünzt" werden oder um deinen Kommentar ergänzt werden.

Siehe unter anderem http://heise.de/-198816

Wichtig war mir nur, dass Suchende irgendeine Antwort finden.

Ein guter Ansatz.

Hat zero einen Vorteil? Ist es möglicherweise schneller als urandom?

Selbst gute Prozessoren liefern nicht deutlich mehr als 16 MiB/s an Pseudozufallszahlen (urandom wird immer noch von einem Algorithmus generiert und ist nicht echt zufällig). Echte Zufallszahlen kommen deutlich langsamer. zero kannst Du mit der Schreibgeschwindigkeit der Platte schreiben, was _deutlich_ mehr ist.

Teste selbst:

dd if=/dev/urandom of=/dev/null
dd if=/dev/zero of=/dev/null

und ca 30 sek laufen lassen.

user unknown schrieb:

Wenn man ernstlich befürchtet dass nach dem Löschen etwas gefunden wird, dann soll man die ganze Festplatte verschlüsseln. Das Ergebnis ist ein Bytemuster, dass von einem Muster, welches ein guter Zufallsgenerator generiert, nicht zu unterscheiden ist.

generell richtig und auch mein Standpunkt. Aber: Manchmal hat man nicht die Wahl. Zum Beispiel wenn man die Arbeit für andere erledigt, ein Gerät verkaufen will, etc

Hi.

redknight schrieb:

generell richtig und auch mein Standpunkt. Aber: Manchmal hat man nicht die Wahl. Zum Beispiel wenn man die Arbeit für andere erledigt, ein Gerät verkaufen will, etc

Jupp musste sowas auch schonmal machen, weil ich kein Bock hatte das Windows auf der Maschine neu zu installieren, aber wichtige Bankdaten etc löschen sollte. Aber ein Hinweis wäre gut, dass das nur eine Notlösung ist und man besser Verschlüsselung nutzen sollte.

Was mir im Artikel aufgefallen ist, es wird immer mit Userrechten gearbeitet. Bei ext* werden aber standardmäßig 5% für Root reserviert, mit etwas Pech sind also selbst nach mehrfachem überschreiben die kritischen Daten noch vorhanden.

Außerdem werden so auch keine Metadaten gelöscht, die Dateinamen sind also noch vorhanden. - Sollte erwähnt werden.

Aaron Pierce schrieb:

"Im aktuellen Verzeichnis" bedeutet, dass die anwachsende "Mülldatei" in dem Verzeichnis angelegt wird, in welchem man sich im entsprechenden Terminal gerade befindet.

Bitte schreibe das entsprechend im Artikel.

Die Fehlermeldung lautet "Auf dem Gerät ist kein Speicherplatz mehr verfügbar". Ich habe den Wikieintrag dementsprechend geändert. Die Datei dann zu löschen ist problemlos möglich.

Danke ☺

Das Verhalten bei parallelen Speichervorgängen hängt vom Dateisystem der entsprechenden Partition ab.

Ich wäre dafür, eine generelle Warnung einzufügen, das Schreibvorgänge auf dieser Partition während des Vorgangs vermieden werden sollten.

Die Schädlichkeit der Gutmann-Methode besteht in der Abnutzung des Speichers durch die hohe Anzahl an Schreibvorgängen. Ich habe versucht in meinem Satz Vor- und Nachteile der Methode zu erwähnen.

Den Leser hier im Regen stehen zu lassen finde ich nicht so gut. Lieber einen erklärenden Satz dazuschreiben.

stfischr schrieb:

Außerdem werden so auch keine Metadaten gelöscht, die Dateinamen sind also noch vorhanden. - Sollte erwähnt werden.

Das steht auch schon in Daten sicher löschen

IMHO kann man die drei Befehle von hier auch in den Artikel Daten sicher löschen packen. Die Einleitung ist eh fast gleich.

Nur mit '0' Überschreiben reicht, da stimme ich zu, wenn es um Daten löschen geht. Jetzt könnte man meinen "wozu brauche ich dann das Überschreiben mit Zufallszahlen?".

Vielleicht wäre es eine Überlegung wert hinzuzufügen, dass mit Zufallszahlen überschreiben z.B. dann Sinn macht, wenn man nicht möchte, dass freier Speicherplatz von verschlüsselten Daten unterscheidbar ist.

@user_unknown: Ich habe den Eintrag bezüglich sfill so geändert, dass der Befehl mit Optionen jetzt nur noch einen Überschreibdurchgang auslöst.

@redknight: Heute hat es mit den Nullen bei mir funktioniert. Diese Methode ist tatsächlich noch schneller als urandom. Ich habe urandom durch zero ersetzt und den Heise-Link nochmal in die Warnung gesetzt.

@stfischr: Ich habe eine Warnung eingefügt, dass generell eine Vollverschlüsselung der bessere Weg ist. Außerdem habe ich allen Befehlen ein sudo vorangestellt und die entsprechende Warnung um deinen Hinweis (der anscheinend sehr wichtig war) erweitert. Ich persönlich kenne mich bezüglich des reservierten Speichers nicht mit ext* aus. Bei Methode 1 und 2 habe ich daraufhingewiesen, dass Metadaten nicht gelöscht werden. Wenn ich die Manpage von sfill richtig verstehe, dann löscht sfill auch die Metadaten (sofern nicht per Option ausgeschaltet).

@kaputtnik: Die Erweiterung bezüglich des "aktuellen Verzeichnisses" habe ich eingefügt. Außerdem enthält die Warnung jetzt einen Satz zu weiteren Schreibvorgängen. Der Gutmann-Satz ist jetzt umformuliert. Bitte schau nochmal, ob das so verständlicher und sinnhafter ist. Generell bezüglich des Wikieintrags können die drei Einträge auch gerne in den Haupteintrag Daten sicher löschen übernommen werden. Ansonsten würde ich diesen Wikieintrag im Haupteintrag unter "Möglichkeiten" als 4. Unterpunkt auflisten.

@T-san: Verschlüsselte Daten sind meines Wissens nach als Dateien (mit Größe und Speicherort) aufgeführt. Gibt es eine Methode verschlüsselte Daten so anzulegen, dass sie nicht mit Metadaten als "normale" Dateien erscheinen? Falls ja, würden die im Wikieintrag aufgeführten Methoden diese verschlüsselten Daten dann nicht automatisch überschreiben?

Hallo,

IMHO kann man die drei Befehle von hier auch in den Artikel Daten sicher löschen packen

+1

Auch wenn der Artikel sehr kurz wäre, würde für sfill ein eigener Artikel besser sein.

Verstehe ich das richtig, dass die Befehle sudo cat ... und sudo dd ... 100% äquivalent sind? Wenn ja, warum müssen dann beide aufgeführt werden?

Gruß, noisefloor

@noisefloor: Ich verstehe das auch so, dass beide Befehle äquivalent sind. Ich habe beide eingetragen, da beide in Foren immer wieder auftauchen und mein Linuxwissen nicht groß genug ist, um zu wissen, ob nicht doch marginale Unterschiede existieren.