Freien Speicher shredden

[azerty]

Hallo miteinander

Ich möchte auf einer Partition (ext3) den gesamten freien Speicherhplatz shredden (mit /dev/urandom überschreiben) jedoch nicht die vorhandenen Dateien.

Es soll wirklich nur der freie Speicherplatz überschrieben werden, die Dateien und die Partition an sich sollen unbeschädigt bleiben.

Dazu habe ich dies gefunden, allerdings bin ich mir nicht ganz sicher ob das die richtige Methode für mich ist, daher wollte ich vorher kurz hier nachfragen.

Danke für eure Hilfe Leute.

:ws:

[Spasswolf]

Lass doch

Code: Alles auswählen

dd if=/dev/urandom of=/Verzeichnis/auf/der/Partition/$DATEI

laufen, bis die Partition voll ist.

Edit: Ich seh gerade, dass das auch im Link vorgeschlagen wurde, klingt vernünftig ...

[azerty]

Lass doch

Code: Alles auswählen

dd if=/dev/urandom of=/Verzeichnis/auf/der/Partition/$DATEI

laufen, bis die Partition voll ist.

Edit: Ich seh gerade, dass das auch im Link vorgeschlagen wurde, klingt vernünftig ...

Das heißt hier würde ich praktisch künstlich eine Datei aufblasen bis die ganze HDD voll ist.

Was passiert wenn die HDD voll ist, bricht der Vorgang ab?

Danke für deine Hilfe!

[cosmac]

hi,

Was passiert wenn die HDD voll ist, bricht der Vorgang ab?

ja, mit einer Fehlermeldung von dd. Deshalb darf ein Script auf den Fehler hin nicht abbrechen.

Interessanter ist, wie man sicherstellt, dass die Zufallsdaten auch wirklich auf die Platte geschrieben werden. In dem Moment, wo dd abbricht, stehen die letzten MegaBytes ja noch im Cache, bei den heutigen Hauptspeichergrößen sind's evt. sogar GigaBytes. Wenn man also direkt danach die Datei wieder löscht, wird entsprechend viel freier Platz nicht überschrieben. Früher hätte ein "sync" gereicht, aber funktioniert das bei ext3 oder gar ext4 noch so einfach?

Das nächste Problem könnte es geben, falls dd eine größere Blocksize als das Dateisystem verwendet. Was passiert dann mit dem letzten Block, den dd schreiben will? Mit bs=512 sollte man auf jeden Fall auf der sicheren Seite sein. Oder man übernimmt den Wert von "IO Block" aus der Ausgabe von "stat Datei_auf_der_Partition".

[rendegast]

Mit bs=512 sollte man auf jeden Fall auf der sicheren Seite sein.

Nein, nur auf der langsamen.
'bs=4k' ist praktikabler.
Zudem habe ich mal irgendwo gelesen, daß beim Schreiben einer Datei <4k der Rest dieser Einheit genullt wird.
(Sind bei einer Riesendatei 4k Verschnitt relevant?)

Nach ct sollte übrigens 'if=/dev/zero' ausreichend sein -> Geschwindigkeit.

Außerdem als root durchführen, da ansonsten die für root vorgesehene Sicherheitsreserve (im Standard 5%) nicht beschrieben wird.

In dem Moment, wo dd abbricht, stehen die letzten MegaBytes ja noch im Cache, ...
Früher hätte ein "sync" gereicht, aber funktioniert das bei ext3 oder gar ext4 noch so einfach?

'sync' sollte reichen -> Warten bis zum Ende der Plattenaktivität (dürfte IMO aber sehr kurz sein).
ext3 hat im Standard eine commit-Zeit (journal) von 5s, falls das damit gemeint sein sollte.
Um den Plattencache zu schreiben 'hdparm -f /dev/...'

[cosmac]

Mit bs=512 sollte man auf jeden Fall auf der sicheren Seite sein.

Nein, nur auf der langsamen.
'bs=4k' ist praktikabler.

o.k., ich erhöhe auf 1k, immerhin werden Dateisysteme auf kleinen Partitionen per Default mit 1k-Blöcken angelegt. Wer sehr viele sehr kleine Dateien hat, macht das auch mal per Hand. Dabei hättest du mit 4k das gleiche Problem wie mit richtig großem bs.

(Sind bei einer Riesendatei 4k Verschnitt relevant?)

in diesem Fall schon, es geht ja darum, alte Dateireste sicher zu schreddern. Wenn die alten Daten reiner Text waren, können 4k eine Menge Geheimnisse enthalten

Nach ct sollte übrigens 'if=/dev/zero' ausreichend sein -> Geschwindigkeit.

da sind wir uns absolut einig.

Außerdem als root durchführen, da ansonsten die für root vorgesehene Sicherheitsreserve (im Standard 5%) nicht beschrieben wird. (...) Um den Plattencache zu schreiben 'hdparm -f /dev/...'

ich wusste doch, da war noch was. Man kann garnicht paranoid genug sein