Ist die Blockgröße wichtig, wenn eine Platte mit dd und Nullen gelöscht wird?

887
Emil

Ich habe
dd if=/dev/zero of=/dev/sda bs=4096
zum Abwischen einer Platte verwendet. Kann die Blockgröße ein Sicherheitsrisiko sein oder beschleunigt es gerade die Sache.

Entschuldigung für mein schlechtes Englisch

1
Der einzige Sicherheitsaspekt besteht darin, dass der Rest des Blocks möglicherweise nicht initialisiert wird, wenn während des Schreibvorgangs ein Schreibfehler auftritt. Je größer der Puffer ist, desto größer ist der nicht initialisierte Block. Wenn Sie die Disc vor der Entsorgung löschen, sollten Sie nach "Erase mil std" suchen: Zu den Dienstprogrammen, die Sie finden, gehören "wipe" und "safe-delete". AFH vor 6 Jahren 0

1 Antwort auf die Frage

0
Austin Hemmelgarn

Wenn Sie nur eine normale Festplatte verwenden, hat die Blockgröße keinen Einfluss auf die Leistung.

Wenn es sich um eine SSD handelt, kann dies Auswirkungen auf die Sicherheit haben, aber Sie können eine SSD nicht wirklich sicher löschen, indem Sie sie ddsowieso verwenden. Daher ist es unwichtig (und wenn Sie nur alles nuke machen möchten, um eine SSD wiederzuverwenden, verwenden Sie blkdiscardsie einfach.) stattdessen).

Es ddist jedoch nicht sicher und unabhängig von der Blockgröße auch keine wirklich hohe Leistung. Ich würde vorschlagen, DBAN zum Abwischen von Festplatten zu suchen . Neben den Optionen zum sicheren Abwischen herkömmlicher Festplatten bietet es auch einen schnellen Nullfüllmodus, der dasselbe macht wie Sie dd, in den meisten Fällen jedoch viel schneller.

Bearbeiten Sie als Antwort auf Fragen zur Sicherheit von ddFestplatten zum Löschen

Das ddLöschen einer Festplatte ist aus verschiedenen Gründen keine sichere Methode, um eine Festplatte zu löschen:

  • Neu zugewiesene Sektoren werden nicht gelöscht. Fast jede Festplatte wird letztendlich fehlerhafte Sektoren neu zuordnen. Wenn dies der Fall ist, können Sie diese Sektoren überhaupt nicht berühren, wenn Sie keine spezielle Firmware verwenden oder den Festplattencontroller vollständig umgehen (was ein Löten und ein wenig geheimnisvolle Kenntnis des jeweiligen Festplattenlaufwerks erfordert). Dies bedeutet, dass selbst wenn Sie jedes verfügbare Byte mit Informationen mit Null-Bytes füllen, die fehlerhaften Sektoren immer noch die Daten enthalten, die sie gemacht haben, als sie neu zugewiesen wurden (und in den meisten Fällen sind die meisten dieser Daten wiederherstellbar). Dies gilt auch für das Löschen über andere nicht-physische Methoden. Wenn also auf Ihrer Festplatte Sektoren neu zugewiesen wurden und Sie sicherstellen müssen, dass die Löschung erfolgt, müssen Sie dafür nicht-elektronische Mittel verwenden.
  • Durch das Überschreiben eines Sektors auf magnetischen Medien werden nicht alle Spuren der vorherigen Daten vollständig entfernt. Auf diese Spuren kann nicht über die normale Festplattenschnittstelle zugegriffen werden. Ein gut finanzierter Angreifer kann jedoch ein Rasterkraftmikroskop verwenden, um diese Spuren zu beobachten.

    Stellen Sie sich vor, Sie verwenden einen Bleistift, um auf ein dickes Stück Papier zu schreiben. Wenn Sie das oberste Blatt abgerissen haben, sind die Eindrücke, die auf diesem Blatt geschrieben wurden, auf den nächsten Blättern noch schwach vorhanden und können mit einer Reihe von einfachen Mitteln wiederhergestellt werden.

    Aus diesem Grund führen alle gängigen Festplattenwischprodukte mehrere Durchgänge mit unterschiedlichen Mustern durch. Jeder nachfolgende Durchlauf schwächt die Spuren der ursprünglichen Daten, wodurch die Wiederherstellung schwieriger und schwieriger wird.

Es ist noch schlimmer für eine SSD, auch wenn sie nicht das zweite Problem haben, das oben aufgeführt ist, weil es viele andere Dinge gibt, die Ihnen in den Weg kommen können:

  • Die meisten modernen SSDs verwenden eine Copy-on-Write-Blockzuordnung. Das bedeutet, dass Sie beim Schreiben an einen bestimmten Ort, wie er vom Betriebssystem gesehen wird, die Daten nicht bereits an diesem Ort überschreiben, sondern an einen neuen physischen Ort auf den Medien des Geräts schreiben und möglicherweise vorhandene Daten von dort kopieren der alte Standort
  • Alle modernen SSDs, ob sie nun ein Copy-on-Write-Block-Mapping verwenden oder nicht, sind überlastet und führen eine gewisse Abnutzung durch. Dies bedeutet, dass Sie zu einem bestimmten Zeitpunkt nicht auf jedes einzelne Byte des Flash-Speichers auf dem Gerät zugreifen können. Dies führt im Wesentlichen zu den gleichen Problemen, die bei der Neuzuweisung fehlerhafter Sektoren beim Löschen von Festplatten auftreten.
  • Einige SSDs verwenden Inline-Komprimierung, um die Speichereffizienz zu verbessern. Dies bedeutet, dass die genauen Daten, die in jeden Block des Flash-Speichers geschrieben werden, von den Daten abweichen können, die Sie schreiben möchten.
  • Einige SSDs verwenden Inline-Deduplizierung, um die Speichereffizienz zu verbessern. Dies bedeutet, dass ein bestimmter Datenblock, den Sie schreiben, möglicherweise nicht tatsächlich in den Flash-Speicher des Geräts geschrieben wird.

Wenn Sie sich wirklich um die Sicherheit kümmern, versuchen Sie nicht, SSDs elektronisch zu löschen (wenn es sich jedoch um ein TCG-Opal-kompatibles SED handelt und Sie dem Hersteller vertrauen, nehmen Sie diesen Weg), und versuchen Sie nicht, stark zu wischen Antriebe elektronisch, wenn sie Hinweise auf schlechte Sektoren der Vergangenheit zeigen.

Wie kann DBAN bei der Nullfüllung besser als DD sein? Ich bin dieser Behauptung sehr skeptisch. davidgo vor 6 Jahren 0
@davidgo `dd 'muss für jeden Block aus' / dev / zero 'kopieren, DBAN verwendet den gleichen vorgefüllten Puffer erneut, so dass nur ein E / A-Aufruf pro Block ausgeführt werden muss, verglichen mit zwei und einem Memcpy für` dd`. Austin Hemmelgarn vor 6 Jahren 0
@AustinHmmelgam - so? / dev / zero ist eine spezielle Datei. Das Betriebssystem liest den Inhalt nicht von der Festplatte. Als schnellen Test dauerte das Lesen von 10 Gigs von / dev / zero und das Schreiben in / dev / null mit dd mit 1-KByte-Blöcken 9,5 Sekunden auf meinem Laptop. Dasselbe mit 4k-Blöcken (dh 40 Gigs) zu tun, dauerte 11,1 Sekunden und 40k-Blöcke (dh 400 Gigs) 37 Sekunden - dies sagt mir, dass das Lesen von / dev / zero keine bedeutende Ressourcequelle ist. davidgo vor 6 Jahren 0
@davidgo Auch wenn es sich um eine spezielle Datei handelt, ist immer noch ein Systemaufruf beteiligt, dh es müssen mindestens zwei Kontextwechsel vorgenommen werden. Es geht auch um die Pufferbehandlung (DBAN weist einen einzelnen Puffer zu, füllt ihn mit Nullen auf und ruft dann wiederholt write mit diesem see-Puffer als Argument auf, während `dd 'für jeden Block read und dann für jeden Block schreiben muss, weil er es ist muss mit dem Kopieren von regulären Dateien umgehen). Austin Hemmelgarn vor 6 Jahren 1
Aus welchem ​​Grund sagen Sie, dass "dd" nicht sicher ist? Was könnte sicherer sein, als die Platte mit Nullen zu schreiben? Hashim vor 6 Jahren 0
@Hashim Meine Antwort wurde aktualisiert, um die Sicherheitsaspekte zu erweitern. Austin Hemmelgarn vor 6 Jahren 0