staging.inyokaproject.org

Was man eventuell noch erwähnen könnte: nautilus-wipe, eine Erweiterung für Nautilus, mit der man Dateien grafisch sicher löschen kann. Dabei wird auf das im Paket secure-delete enthaltene srm zurückgegriffen, quasi eine sichere Variante von rm.

Erwähnenswert wäre auch, daß 'sicher löschen' auf einer SSD keine sicher vernichtete Daten sondern nur Abnutzung verursacht, da die SSD intern die Daten 'irgendwo' speichert, um eine gleichmäßige Abnutzung zu gewährleisten.

FERNmann0 schrieb:

Was man eventuell noch erwähnen könnte: nautilus-wipe, eine Erweiterung für Nautilus, mit der man Dateien grafisch sicher löschen kann. Dabei wird auf das im Paket secure-delete enthaltene srm zurückgegriffen, quasi eine sichere Variante von rm.

nautilus-wipe ist im Artikel Nautilus ab Oneiric enthalten. Interessant waere ein Hinweis oder ein eigener Artikel zu secure-delete (der dann u.U. verlinkt werden koennte).

posti schrieb:

Erwähnenswert wäre auch, daß 'sicher löschen' auf einer SSD keine sicher vernichtete Daten sondern nur Abnutzung verursacht, da die SSD intern die Daten 'irgendwo' speichert, um eine gleichmäßige Abnutzung zu gewährleisten.

Dann fuege bitte eine Hinweisbox in den Artikel ein.

FERNmann0 schrieb:

nautilus-wipe, eine Erweiterung für Nautilus, mit der man Dateien grafisch sicher löschen kann.

Wenn man sich dabei im Klaren ist, daß im besten Fall nur die aktuell bekannte Kopie der Datei überschrieben wird. Wenn es z.B. ein Office-Dokument ist und du mehr als einmal gespeichert machst (oder die Office-Software eine Auto-Backup-Funktion hat), dann hast du möglicherweise bei jedem Speichervorgang eine neue Kopie des Dokuments erstellt. Dann nur die letzte bekannte Fassung zu überschreiben bringt dann nicht allzu viel. Um die Kopien zu erwischen muss man dann auch noch den gesamten freien Speicher überschreiben, was auch nicht ohne Tücken ist (dank Root-Reserve und anderen Dateisystem-Eigenheiten).

posti schrieb:

Erwähnenswert wäre auch, daß 'sicher löschen' auf einer SSD keine sicher vernichtete Daten sondern nur Abnutzung verursacht, da die SSD intern die Daten 'irgendwo' speichert, um eine gleichmäßige Abnutzung zu gewährleisten.

Na ja, jeder Schreibvorgang überschreibt und löscht damit auch was. Wenn du die SSD mit Zufallsdaten vollschreibst dann sind die nicht "irgendwo" sondern in den Speicherbausteinen der SSD und das was vorher dort war ist dann weg und damit gelöscht. Das Problem ist dann die zusätzliche Sektorreserve an die man softwareseitig so nicht herankommt, die dann nicht überschrieben ist. Da muss man sich dann auf eine etwaige Secure-Erase-Funktion der SSD selber verlassen. Nur ist das dann quasi eine Black Box und damit eine Vertrauensfrage ob man der SSD glaubt daß sie wirklich sicher gelöscht hat... wenn du selber überschreibst weißt du wenigstens daß nur noch die Reserve übrig sein kann und nichts weiter.

Der Artikel ist im Moment auf Baustelle auf mich gesetzt; ich hatte mich bereiterklärt ihn zu überarbeiten muß aber ehrlich zugeben daß mir das zwischenzeitlich entfallen ist. Mea culpa. 😳

Hi,

Artikel ist wieder im Wiki. Falls jemand die geplante Seitenstruktur übernehmen möchte, kann er diese Revision (raw-Format) anschauen (das animierter Bild lasse ich mal als Anhang).

Gruss Lasall

Hi. Wie ich hier beschrieben habe, ist das mehrfache Überschreiben von Daten erwiesenermassen Unsinn. Will man eine gesamte Festplatte sicher löschen, reicht 1x Überschreiben mit 0 (ausnullen). Einzelne Dateien sicher löschen, ist im Zeitalter von Journaling-Dateisystemen und SSDs so nicht möglich.

Ich würde also den Artikel entsprechend umschreiben, so dass zum Löschen von magnetischen Festplatten dd vorgeschlagen wird und zum Löschen von SSDs das Neusetzen der Verschlüsselung (bereits im Wiki beschrieben).

Statt des Löschens von einzelnen Dateien sollte, so dies sicherheitsrelevant ist, Verschlüsselung eingesetzt werden. Verzichtet man alternativ bei ext3/ext4 auf das Journaling, wird übrigens automatisch sicher gelöscht, da ext3/4 Dateien beim Löschen ausnullen.

mniess schrieb:

Verzichtet man alternativ bei ext3/ext4 auf das Journaling, wird übrigens automatisch sicher gelöscht, da ext3/4 Dateien beim Löschen ausnullen.

Das würde mich wundern, denn das Dateisytem würde dadurch unerträglich langsam werden.

Und selbst wenn man mit shred o.ä. eine Datei inplace überschreibt, ist das immer noch nicht sicher, da auch ohne Journal praktisch immer mehrere Kopien einer Datei vorhanden sind (neue Kopie jedes Mal wenn man Speichern drückt). Datei löschen und dann den gesamten freien Speicher nullen (inkl. Root-Reserve) ist einigermaßen sicher, dauert aber (bei viel freiem Speicher) entsprechend lang.

Der einzig halbwegs sinnvolle verbleibende Einsatzzweck von shred ist, ein Device mit Zufallsdaten zu überschreiben, z.B. als Vorbereitung für eine anschließende Verschlüsselung. Die Alternativen (/dev/(u)random, oder cryptodevice nullen) sind langsamer oder weniger sicher. Und sonst gibts kaum ein anderes Programm im Linux-Standardumfang das als Pseudozufallsdatenquelle herhalten kann...

Um wirklich 140% sicher zu gehen gehört neben dem Überschreibevorgang eigentlich auch noch ein Auslesevorgang dazu, um zu bestätigen, daß die Daten auch tatsächlich überschrieben worden sind. Und da sind Nullen dann nachteilhaft, da ein Festplattendefekt denkbar ist bei dem Nullen gelesen werden obwohl Nutzdaten gespeichert sind. Bei SSDs ist das sogar ein Feature (TRIM der gesamten SSD ⇒ es werden nur noch Nullen gelesen obwohl gar keine Daten überschrieben worden sind). Man müsste also (reproduzierbare) Zufallsdaten schreiben und anschließend wieder auslesen - badblocks -t random geht in diese Richtung.

frostschutz schrieb:

Das würde mich wundern, denn das Dateisytem würde dadurch unerträglich langsam werden.

Löschen unter ext3/4 ist ja auch vergleichsweise langsam. Aber ich hatte das tatsächlich falsch in Erinnerung. Es werden nur die inodes ausgenullt. Der Rest, den du geschrieben hast deckt sich ansonsten 1:1 mit dem was ich geschrieben habe. Einzelne Dateien sicher überschreiben ist Quatsch. Einzig Verschlüsselung hilft.

mniess schrieb:

Einzelne Dateien sicher überschreiben ist Quatsch. Einzig Verschlüsselung hilft.

Naja, jein, Verschlüsselung hilft in Bezug auf einzelne Dateien eigentlich gar nix. Du musst den Schlüssel wegwerfen was letztendlich einem Überschreiben gleichkommt - und Überschreiben ist sicherer da es da keinen Schlüssel mehr gibt der geknackt werden könnte (mit Schraubschlüssel a la XKCD). Verschlüsselung ist eigentlich primär dann interessant wenn man nicht überschreiben kann, etwa wegen defekter Platte oder weil SSDs eben eine Reserve haben.

Wenn wir aber realistisch sind werden viele Nutzer kein ganzes Dateisystem wegwerfen / überschreiben wollen wegen einer einzelnen Datei, und da ist unter den Umständen eben die sicherste Methode, den freien Speicher zu überschreiben. Das ist dann eben nur 99% sicher statt 100% sicher, aber Quatsch ist es deswegen nicht, da es die 0% von rm und die 1% von shred um Längen schlägt. ☺

Ich glaube wir reden hier aneinander vorbei. Der Artikel, so wie er jetzt da steht ist nicht sinnvoll. Punkt. Was gerade sinnvoll ist, darüber können wir hier ja diskutieren und entspr. einen neuen Artikel gestalten. Mir ging es darum, dass mehrfach Daten überschreiben erwiesenermassen keinen Mehrgewinn bringt. Die Punkte, die du und ich anbringen, sollten eben so im Artikel stehen. Wer meint er hat öfter mal sehr wichtige Dateien auf dem Rechner, an die keiner ran soll, der sollte sich Vollverschlüsselung überlegen. Wer nur regelmässig bestimmte Dateien loswerden will, falls das Finanzamt mal den Rechner einsackt, für den könnte free-space wipe (mit nullen) interessant sein (oder gleich wieder auf eine registerkasse umsteigen). Aber mit shred eine einzelne Datei löschen oder die gesamte Festplatte 38fach überschreiben ist einfach Unsinn. Das sollte der Artikel wiederspiegeln, da sind wir uns doch einig oder nicht?

Du darfst den Artikel gerne überarbeiten, habe ich gar nichts dagegen, zumal ich da eh nichts zu sagen habe, ich wollte es ja selber schonmal machen und hab dann doch nicht die Zeit dazu gefunden 😇

Vielleicht kann das hier zur Orientierung dienen http://en.gentoo-wiki.com/wiki/Secure_deletion aber da fehlen auch ein paar Punkte (SSD usw.) und der Artikel klingt erstaunlich blöd wenn man versucht es 1:1 zu übersetzen.

Ich hab in dem Gentoo-Wiki-Artikel halt versucht ein Spagat zu schlagen, nämlich einmal zu vermitteln wie Dateien überhaupt gespeichert sind (wer das nicht versteht der kann auch nicht beurteilen, wie sicher eine Methode ist), was mir nur leidlich gelungen ist, und zum anderen eben verschiedene Ansätze zum Überschreiben und deren Vor-/Nachteile vorzustellen.

Verschlüsselung ist ein sehr weitläufiges Thema, ist die große Frage inwieweit das im Artikel überhaupt behandelt werden sollte, dafür gibts schließlich auch eigene Wikiseiten. Man kann da auch auf die Nase fallen, ein cryptsetup luksFormat löscht eben noch keine Daten und mit Verschlüsselung ist man nicht automatisch sicher...

Man kann in dem Artikel ja jederzeit auf andere Artikel verweisen (siehe SSD/Secure-Erase) und generelle Probleme hinweisen ohne bei Adam und Eva anzufangen. Wenn es jetzt um wichtige Wirtschaftsgeheimnisse geht, würde mit dd auch nicht reichen. dd beschreibt nämlich keine blocks, die von der Festplatte als "bad" markiert wurden. Diese lassen sich aber durchaus noch (teilweise) auslesen. Kann also durchaus sein, dass man auf einer ausgenullten Festplatte in den badblocks noch einige Daten findet.

Naja. Ich arbeite derzeit noch an einem anderen Artikel. Wenn der fertig ist, mach ich mich mal hier ran 😉

Hallo, nette Diskussion hier. Schön wäre wirklich, wenn sich jemand die Mühe macht und etwas ins Wiki schreibt. Diese Diskussion wird zwar auch über die Hilfe gefunden werden, übersichtlicher wird es im Wiki. Also bitte auch etwas Energie ins Wiki.

Danke, didi

Hallo,

ich habe den Artikel Baustelle/Freien Speicher mit Pseudozufallszahlen überschreiben in "Daten sicher löschen" integriert, nachdem das in der Artikeldiskussion (http://forum.ubuntuusers.de/topic/baustelle-freien-speicher-mit-pseudozufallszah/2/#post-5486357) vorgeschlagen wurde.

Hallo,

Danke für die Ergänzung. Habe ein wenig Syntax korrigiert. Datei- und Verzeichnisnamen werden immer fett geschrieben.

Gruß, noisefloor