luks-Partition retten

[nafur]

Hallo,

Ich habe (bzw hatte) eine Partition auf meinem Server die per luks verschlüsselt ist.
Nach einem Stromausfall (der Server steht hier zu hause und hatte natürlich keine USV ) stellte sich heraus, dass der MBR der Boot-Festplatte etwas abbekommen hatte. Nachdem ich den repariert hatte, wollte ich die verschlüsselte Partition mounten... Wie man sich denken kann tat dies (natürlich? ) nicht.
Es gibt keine Fehlermeldung die darauf schließen ließe, dass irgendwas kaputt ist, sondern es kommt die normale "Command failed: No key available with this passphrase." Meldung.

Ich dachte zunächst ich wüsste das Passwort nicht mehr, allerdings bin ich mir sehr sicher wie das Passwort aussieht (also ich weiss die Bestandteile und wie sie ungefähr zusammengesetzt sind) und habe die letzten Tage mithilfe dieser Bestandteile einen "Brute-Force"-Angriff gefahren, allerdings bisher ohne Erfolg.
So langsam habe ich allerdings das Gefühl, dass die Partition vielleicht doch was abbekommen hat.

Daher nun ein paar Fragen

1. Kann ich irgendwie prüfen, ob der Header noch i.O. ist ohne das Passwort zu haben? (Also wie weit kann ich das Prüfen? Könnte ich feststellen dass es den Bereich in dem der Master key liegt erwischt hat ohne das passwort zu haben?)

2. gibt es irgendwelche Recovery tools? Also Angenommen ich wüsste dass der Header kaputt ist, ich hätte aber das Passwort. Gibt es einen Backup-Header o.ä.?

Ein Backup vom Header habe ich vorher leider nicht angelegt.

Grüße
nafur

[Danielx]

Hallo und willkommen im df.de!

Es gibt keine Fehlermeldung die darauf schließen ließe, dass irgendwas kaputt ist, sondern es kommt die normale "Command failed: No key available with this passphrase." Meldung.

Vermutlich zeigt dann auch ein "cryptsetup luksDump <Device>" plausible Daten an, soweit man das eben sagen kann?

Also Angenommen ich wüsste dass der Header kaputt ist, ich hätte aber das Passwort.

Wenn der mit dem PW verschlüsselt MK defekt ist, hilft dir das Passwort nichts.

Gibt es einen Backup-Header o.ä.?

Nein.

Ein Backup vom Header habe ich vorher leider nicht angelegt.

"cryptsetup luksHeaderBackup ..."

Ansonsten, könntest du dir mal die Spezifikation von LUKS ansehen:
http://code.google.com/p/cryptsetup/wiki/Specification
Dort findest du die Antwort auf deine Fragen.

Siehe auch:
http://de.wikipedia.org/wiki/Dm-crypt#On-Disk-Format

Tag: wiki

Gruß,
Daniel

[nafur]

Es gibt keine Fehlermeldung die darauf schließen ließe, dass irgendwas kaputt ist, sondern es kommt die normale "Command failed: No key available with this passphrase." Meldung.

Vermutlich zeigt dann auch ein "cryptsetup luksDump <Device>" plausible Daten an, soweit man das eben sagen kann?

Joa, soweit ich das beurteilen kann schon...

Dann fange ich wohl mal so langsam an mich damit abzufinden, den Server neu aufzusetzen... :-/

[marcometer]

Hallo,
ich habe so mehr oder weniger das gleiche Problem.
Auch bei mir hat sich der Server aufgehaengt waehrend die Partition am laufen war und nun verweigert er allen meinen 3 gesetzten Passwoertern die Richtigkeit.
luksDump gibt soweit sehr plausible Daten aus und die Passwoerter sind auf jeden Fall richtig.
Ich habe mich schon damit abgefunden, dass ich das Ganze neu aufsetzen darf, aber wie kann ich das in Zukunft verhindern?

[jeff84]

Ich habe mich schon damit abgefunden, dass ich das Ganze neu aufsetzen darf, aber wie kann ich das in Zukunft verhindern?

Den Header an einem sehr sicheren Ort sichern...
http://www.saout.de/tikiwiki/tiki-index.php?page=LUKSFaq

[Danielx]

Hallo und willkommen im df.de!

Auch bei mir hat sich der Server aufgehaengt waehrend die Partition am laufen war und nun verweigert er allen meinen 3 gesetzten Passwoertern die Richtigkeit.

Hm, das hört sich aber seltsam an, das würde ja bedeuten, dass entweder ein Schreibzugriff auf den LUKS-Header stattgefunden haben muss (nur wer oder was war das?) oder genau der Sektor der Festplatte kaputt gegangen sein muss, auf dem der Header liegt.
Bzgl. des defekten Sektors: Hast du das mal mit smartctl überprüft?

Ich habe mich schon damit abgefunden, dass ich das Ganze neu aufsetzen darf, aber wie kann ich das in Zukunft verhindern?

Den Header an einem sehr sicheren Ort sichern...
http://www.saout.de/tikiwiki/tiki-index.php?page=LUKSFaq

Ab cryptsetup 1.1.x (also bei Debian ab Squeeze) bietet cryptsetup auch direkt eine Möglichkeit, den LUKS-Header zu sichern und wiederherzustellen (wie ich oben schon angedeutet habe):

Code: Alles auswählen

cryptsetup luksHeaderBackup --header-backup-file <file> <device>
cryptsetup luksHeaderRestore --header-backup-file <file> <device>

Gruß,
Daniel

[jeff84]

Ab cryptsetup 1.1.x (also bei Debian ab Squeeze) bietet cryptsetup auch direkt eine Möglichkeit, den LUKS-Header zu sichern und wiederherzustellen (wie ich oben schon angedeutet habe):

Code: Alles auswählen

cryptsetup luksHeaderBackup --header-backup-file <file> <device>
cryptsetup luksHeaderRestore --header-backup-file <file> <device>

Oh ok, gut zu wissen. Die Andeutung muss ich oben wohl überlesen haben...

[nafur]

Ich hab mir das mit smartctl mal angesehen, und die beiden Festplatten (unter dem luks liegt ein lvm-Raid) scheinen keine Fehler zu haben.
(Sind auch noch ziemlich neu) Auf welche Werte sollte man da denn achten?

Eine andere Idee die mir noch gekommen ist:
Wenn man nun annimmt, dass beim Reset ein Schreibzugriff im luks-Header stattgefunden hat, luksDump aber sinnvolle Daten zurück gibt, bleiben meines Erachtens zwei Möglichkeiten: Der Master Key wurde geändert, oder der Hash vom Master Key wurde geändert.
Besteht die Möglichkeit luks anzuweisen, das Passwort zu schlucken ohne den Master Key mit dem Hash zu vergleichen?
Damit könnte man die Daten, falls wirklich nur der Hash kaputt ist, noch wiederherstellen...

Grüße
nafur

[Danielx]

Auf welche Werte sollte man da denn achten?

• Reallocated_Sector_Ct
• Reallocated_Event_Count
• Current_Pending_Sector

Wenn man nun annimmt, dass beim Reset ein Schreibzugriff im luks-Header stattgefunden hat

Vielleicht wurde aber auch nur das Tastatur-Layout umgestellt, hast du das evtl. mal überprüft?

Der Master Key wurde geändert, oder der Hash vom Master Key wurde geändert.

Oder der Salt oder die Anzahl der Iterationen.
Mit "Master Key" meinst du wahrscheinlich den verschlüsselten MK.

Besteht die Möglichkeit luks anzuweisen, das Passwort zu schlucken ohne den Master Key mit dem Hash zu vergleichen?

Ja, dazu müsstest du die Überprüfung im Quellcode deaktivieren und dir cryptsetup bauen.

Damit könnte man die Daten, falls wirklich nur der Hash kaputt ist, noch wiederherstellen...

Allerdings kann es dir passieren, dass eben der Hash nicht verändert ist und du somit mit einem falschen MK die Daten liest und evtl. schreibst, was dann nur Datenmüll erzeugt.
Vor solchen Versuchen sollte man immer ein Backup machen und eigentlich sogar schon bevor diese Versuche nötig sind, damit diese gar nicht erst nötig werden.

Gruß,
Daniel

[Flintz]

I have ein ganz ähnliches Problem:
Passphrase wird nicht mehr erkannt aber luksDump gibt sinnvolle Daten aus.

Hat hier noch jemand irgendwelche Erfahrungen damit gemacht? Der Thread endete ja relativ abrupt. Ich hab die Hoffnung mal noch nicht aufgegeben an die Daten wieder ranzukommen. Backup hab ich leider weder von den Daten noch vom luks-Header (ersteres ist bei 6TB etwas sehr aufwendig, zweiteres wusste ich bisher nicht dass nötig sein könnte).

Bin für jeglichen Anregung dankbar.

Flintz