[Debian Lenny] LVM und Verschlüsselung "luks"

seim

seim

seim oder nicht seim?
Hi,

ich habe vor ein bestehenden File Server ein wenig umzurüsten, da zum einen das Problem besteht, dass immer eine Festplatte voll wird während die anderen noch massig freien Speicher haben (-> mehrere Festplatten zu einer großen zusammenfügen) und zum anderen möchte ich gerne bei dieser Gelegenheit die Platten verschlüsseln.


Zunächst steht natürlich die Frage offen wie sehr die Verschlüsselung die Geschwindigkeit des Rechners beeinflussen wird (2GHz, P4 Single Core) - sollte natürlich nicht so sein, dass ich durch die Verschlüsselung eine Durchsatzrate von weniger als 20MB/s erziele - evtl. werde ich das direkt am entsprechenden Rechner testen.

Auf der anderen Seite steht natürlich die Datensicherheit. Im Moment ist nichts gespiegelt oder ähnliches, fällt eine Platte aus dann sind die Daten darauf weg. Diese Stufe der Sicherheit reicht mir aus, es sollte nur nicht so sein, dass durch den Ausfall einer einzigen Platte das gesamte virtuelle Laufwerk unbrauchbar wird. Zumind. die Daten die auf anderen Platten lagen sollten weiterhin erreichbar oder wiederherstellbar sein (das "RAID0" z.B. fällt damit direkt weg).

Und zu guter Letzt natürlich die Reihenfolge der Anwendungen.
Da gibt es meines Wissens nach nun zwei Möglichkeiten:

1) "echte" HDD --crypt--> crypted virtual Drive --LVM--> VolumeX ----> Logical VolumeX --Filesysten--> Files

2) "echte" HDD --LVM--> VolumeX ----> Logical VolumeX --crypt--> crypted virtual Drive --Filesysten--> Files
 
LVM und Luks

Hallo

Ich würde zur Variante 2 raten

Physikalisches device (also hdd) komplett verschlüsseln per kuks (2 Partitonen eine /boot nicht verschlüsselt, der Rest halt als komplettes device verschlüsseln).

Dann lvm auf das verschlüsselte crypto-device, damit bist du was die Volumes angehst,
a. flexibvel
b. nur das crypto-device muß entschlüsselt werden, ansonsten(also erst LVm und dann jedes volume verschlüseln) mußt du alle volumes separat entschlüsseln.

das Ganze kannst du automatisieren, wenn du die ein keyfile generierst und auf USB-Stick speicherst.
Wen du das nciht amchst, muß du den Server an einen Monitor hängen, da bei jedem Booten die Passphrase an der Tastatur eingeben werden muß. keine gute Idee wenn der Server weit weg steht, oder kein Monitor vorhanden ist.

mfg
schwedenmann
 
Eigentlich hatte ich eh nicht vor die Systemplatte zu verschlüsseln. Die ist wirklich nur für das System und auch nicht sonderlich groß weshalb die auch nicht freigegeben ist.

Das Entschlüsseln würde ich dann irgendwie mit einem Shellscript lösen (bekomm' ich sowieso nicht hin aber ich schreib das trotzdem mal auf) ansonsten würde ich das Server's Power ein wenig erweitern (wäre ohnehin bequemer).
 
Gut auch wenn das "automatisch" geht.. Wer tippt dann das Passwort für mich ein?
 
Technische Antwort:

Wozu Passwort? Man nehme ein Keyfile.

Logische Antwort:

Was nutzt einem ein verschlüsseltes System, welches beim Booten ohne eine einzige Abfrage zur Authentifizierung _automatisch_ entschlüsselt wird?

Dann kannst Du Dir den ganzen "Hokuspokus" auch sparen.
 
Wohin dann mit dem Keyfile, dass wirklich nur ich an die Kiste kann und niemand sonst? Wenn ich da nen USB Stick reinstecken soll.. der File "Server" steht irgendwo im Keller (ist im Prinzip nur n Rechner wo ich alle Platten reinstecke die ich oder Freunde von mir ansonsten entsorgt hätten).

Was nutzt einem ein verschlüsseltes System, welches beim Booten ohne eine einzige Abfrage zur Authentifizierung _automatisch_ entschlüsselt wird?

Genau deshalb fand' ich das mit der /etc/crypt.. so "seltsam"
 
Das Keyfile macht nur dann Sinn, wenn es auf einem externen Medium liegt, aber das gilt für ein Script, welches z.B. das Passwort für Dich "automatisch eingibt" genau so, egal obn man ein Passwort in diesem Script drin hat oder aus einem Keyfile auslesen lässt.

Ohne externes Medium macht nur eine Passwortabfrage Sinn, egal wie man das nun anstellt.

Genau deshalb fand' ich das mit der /etc/crypt.. so "seltsam"

Lies vielleicht zuerst die Dokumentation bevor Du urteilst.
 
Ok hab den Speed mal ein wenig getestet (naja gut über Samba merkt man nicht viel von dem "Speed")

Testsystem:
Athlon XP 3000+ @512MB Ram, Debian 5.03, lvm2, cryptsetup
160GB SATA1 HDD @ext3
lvm --> aus sda1 und sda2

sda1 nativ: 30-33 MB/s --> Samba Maximum
sda1 crypt: 20-25 MB/s
lvm: 30-33 MB/s
lvm crypt: 20-25 MB/s

----

Also LVM scheint die Geschwindigkeit nicht sonderlich zu beeinflussen und wenn doch dann erst ab einem Wert der zu Hoch für den Flaschenhals "Samba" ist. Über AFP wird man das vielleicht merken, aber auch da kommt man duch Netatalk max. auf 40 MB/s

Ein wirklichen Verlust stellt die Verschlüsselung dar.. max. kommt man damit auf 25 MB/s - ob das nun an der vergleichsweise alten Hardware liegt weiß ich nicht. Evtl. teste ich das nochmal mit AES-128 statt mit 256

Code:
cryptsetup -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdaX
 
lvm und luks

Hallo

Ich verstehe nur nicht, was die performance mit crypt oder lvm zu haben soll.

Wenn der Server gebootet ist und du per samba darauf zugreifst, dann ist der doch offen. da wird nichts live verschlüsselt, also kann luks auch keine Bremse sein.



mfg
schwedenmann
 
Wenn die Festplatte verschlüsselt ist und ich das wie auch immer offen schalte und dann ne Datei darauf kopiere dann werden diese Daten wohl auf irgendeine Art und Weise verschlüsselt werden bevor die auf der Platte landen. Und die Geschwindigkeit ist halt geringer (max. 25 MB/s statt 33 per Samba oder 40 per AFP bei unverschlüsselt)
 
LUks

Hallo


Wenn die Festplatte verschlüsselt ist und ich das wie auch immer offen schalte und dann ne Datei darauf kopiere dann werden diese Daten wohl auf irgendeine Art und Weise verschlüsselt

Das ist ein Trugschluß.

Nur während des mountens und unmountens, wird ent- bzw. verschlüsselt. Es findet keine on-the fly Verschüsselung statt.

Ist die POartiton erst mal gemountet, ist alles lesbar, wenn du dann per ssh auf den Rechenr zugreifst, mußt du doich kein passphrase von LUKS eingebn?, oder.
Ergo ist der Rechner nicht verschlüsselt.

Sicher ist die HDD nur, wenn der PC aus ist !
Was ja auch vollkommen ausreicht.
Ob es überhaupt eine on-the-fly Opensource Verschlüsselung gibt, was ich nicht, wärer aber interssant das zu testen.

mfg
schwedenmann
 
Wenn die Daten sicher sein sollen wenn der PC aus ist.. dann geht das doch nur wenn die verschlüsselt auf der Platte liegen oder :D?

Und da ich mir nicht vorstellen kann wie der in 3sek. (so lange dauert das ca. nachdem ich das PW eingegeben hab) die komplette Festplatte einmal entschlüsselt.

Danach liegt ein neues Laufwerk bereit in /dev/mapper/csda1 welches man wie eine einzelne Partition behandeln kann (also nochmal Partitionieren geht z.B. nicht) diese kann man dann mounten. Aber ich gehe mal stark davon aus, dass auf dem Weg von /dev/mapper/csda1 nach /dev/sda1 (da wird sich dm-crypt wohl dazwischen hängen) verschlüsselt wird.
 
schwedenmann irrt. Es ist jederzeit alles verschlüsselt und die Daten werden beim Zugriff auf das jeweilige Device (dass bei cryptsetup luksOpen unter /dev/mapper erstellt wird) entschlüsselt. Die Daten liegen verschlüsselt auf der Platte. Einzig Daten, die im Cache sind müssen nicht entschlüsselt werden, dieser ist aber mit dem Ausschalten des PCs weg, da er im Hauptspeicher und swap vorgehalten wird. (Auch deshalb sollte man swap immer mit Verschlüssseln).

seim hat das schon richtig verstanden. Die 3sek benötigt der Algorithmus um durch verschiedene Operationen aus dem Kennwort einen Schlüssel zu machen mit dem der Schlüssel für die Festplatte entschlüsselt werden kann. Es ist auch durchaus Absicht, dass dieser Vorgang 3 Sekunden oder so dauert, ein Brute-Force Angriff wird damit erheblich erschwert.

@schwedenmann: Das steht übrigens alles inder dm-crypt Doku. LUKS wird nur benutzt, um das Kennwort für die Entschlüsselung komnfortabler abzulegen. Dsa Kennwort gibst du nur einmal ein, weil dann wie gesagt das eigentliche Festplattenkennwort damit entschlüsselt wird. Dieses Kennwort wird dann im Speicher vorgehalten und in der Folge immer wieder verwendet. Deshalb kann man zum Beispiel durch Tricks wie das Tiefkühlen des Hauptspeichers dieses Kennwort aus dem laufenden System entwenden. (Wenn man nicht sowieso schon über Firewire oder ähnliche Tricks an den Hauptspeicher kommt..)
 
Zuletzt bearbeitet:
Ok das heißt also, dass der PC erst sicher ist wenn der Ram solange ausgeschaltet war dass ein Großteil der Daten "entsorgt" ist.

Naja und die swap Festplatte dagegen muss ich mir auch noch was überlegen dass man die direkt mit verschlüsselt. Naja.. ich hab' die noch nie auch nur zu 1% belegt gesehen also das System kann definitiv erstmal booten und dann die swap Platte dazuladen.
 

Ähnliche Themen

Debian 3.1 auf Notebook installieren (ohne CD-LW, USB, DSL...)

[openSuse10.2] SATA mal wieder...

Zurück
Oben