LVM + Crypt (Truecrypt?) ohne KVM möglich?



T

thomas7

New Member
Hallo zusammen,

nachdem ich mich nun schon einige Zeit mit Linux beschäftige stellt sich mir eine neue Frage bzw. Aufgabe.

Ich hoffe mir kann geholfen werden.

Folgendes vorhaben:
Dedicated Server soll verschlüsselt werden. Mehrere Platten sollen mit LVM zu einer großen Verbunden werden, auch erweiterbar mit neuen HDDs.

Was bisher geklappt ist natürlich mit Truecrypt Container oder Festplatten zu verschlüsseln.
Nun sind diese aber alle einzeln.
Mit LVM habe ich mich noch nie auseinander gesetzt. Aber ich denke das wird nun an der Zeit.
LVM verbindet ja wenn ich das richtig verstanden habe mehrere HDDs zu einer großen Partition.
DM-Crypt ist wohl auch eine verschlüsselung die mit LVM arbeitet? Oder sogar ein Bestandteil ist?

Ich habe nun schon einige Anleitungen gefunden aber hier wird immer auf ein Rescue System verwiesen, welches nicht vorhanden ist.
Nehmen wir folgende Ausganssituation.
Dedi Server mit Ubuntu 12.04. 2 Festplatten.
Nun sollen ein Teil der ersten Festplatte mit der gesamten zweiten Festplatte verbunden und verschlüsselt werden. Der nicht verschlüsselte Teil sollte natürlich zum booten hergenommen werden um wenigstens SSH Zugriff zu haben um nach einem reboot den Rest zu entschlüsseln.
Sollte mal eine dritte HDD hinzukommen so sollte diese mit eingebunden werden zu der großen verschlüsselten Partition.

Mach ich mir hier einen zu großen Kopf und das ganze ist einfacher als ich annehme?

Wie sollte ich vorgehen?
Die HDD1 mit dem Bootsystem splitten, sodass sda1 weiterhin boot bleibt und der Rest dann frei ist um mit der anderen HDD zu "verschmelzen"?

Ich hoffe mir kann jemand auf die sprünge helfen.

Vielen Dank

Gruß
thomas
 
Ein logisches Volume verhält sich wie eine normale Festplattenpartition - mit dem Unterschied, dass es (wenn man es so will) über mehrere Festplatten strecken kann.

Ob sich Truecrypt-Volumes aber so einfach erweitern lassen wie normale unverschlüsselte Dateisysteme kann ich dir nicht sagen - m.W. müsstest du vorher alles vollständig entschlüsseln, das Volume erweitern und dann mit Truecrypt wieder neu verschlüsseln.
 
Nach http://www.hermann-uwe.de/blog/resizing-a-dm-crypt-lvm-ext3-partition kann ein dm-crypt volume vergrößert werden.


Ich bezweifele jedoch immer noch den Sinn des Aufwands. Verschlüsselung schützt vor physischem Zugriff auf die Festplatte während der Server nicht läuft, wenn du Veränderungen am Server ausschließen kannst. So lange er läuft, kann mit physischen Zugriff bei ernsthaftem Interesse mindestens der Schlüssel ausgelesen werden. Und wenn der Server gerade nicht läuft, kann der unverschlüsselte Bereich so manipuliert werden, dass einem Angreifer der Schlüssel übermittelt wird; der Angreifer muss nur warten bis Du den Server wieder bootest.

--
.A.
 
Danke Euch beiden.

Ja dm-crypt ist auch das was ich mir schon ergoogelt hatte jedoch stellt sich hier das Problem mit der Live-CD bzw. dem Recovery System.
Dies steht in der Testumgebung nicht zur verfügung.

Ich müsste also im laufenden Betrieb das ganze so hinbekommen dass Ich einen Teil verschlüssele und der zum booten notwedige Teil eben unverschlüsselt bleibt.

Über Sinn oder Unsinn geht es hier doch aber überhaupt nicht. Meine Frage bezog sich nicht darauf ob das jemand für Sinnvoll hält :)
Natürlich sind die Daten wenn entschlüsselt auch für den Angreifer sichtbar.
Aber solange diese nicht entschlüsselt sind bleiben diese eben "sicher".
 
.A. said:
Ich bezweifele jedoch immer noch den Sinn des Aufwands.
Click to expand...
Ganz so unsinnig ist der Aufwand meines Erachtens nach nicht. Dass Verschlüsselung im laufenden Betrieb wenig zur Sicherheit beiträgt, ist klar.
Interessant sind in diesem Zusammenhang, zumindest für mich, aber folgende zwei Szenarien:
  • Der Hoster tauscht eine der Festplatten aus, entsorgt die getauschte Platte aber nicht richtig und ein Mitarbeiter verkauft sie mal schnell für ein paar Euro auf ebay. In so einem Fall möchte ich ungerne meine zum Teil für mich sensiblen Daten unverschlüsselt gespeichert wissen.
  • Über die Administrationsoberfläche des Hosters lässt sich ein Reboot des Servers ins Rescue-System auslösen. In diesem Fall hätte der Angreifer root-Rechte und könnte nach Belieben Daten kopieren oder verändern. Auch das wäre für mich eher doof. Siehe auch: http://heise.de/-1884180
 
In diesem Fall hätte der Angreifer root-Rechte und könnte nach Belieben Daten kopieren oder verändern.
Click to expand...
Sofern du nicht garantiert den Boot von einem read-only Medium durchführst kann der Angreifer das Startsystem dann manipulieren und du bei einem späteren Boot ihm den Key zu spielen - aber das hatte .A. ja bereits erwähnt.
Dies kann auch etwas versteckt passieren indem on-the-fly während dem Boot-Vorgang ein Patch in den kernel injiziert wird à la Kon-Boot.

In so einem Fall möchte ich ungerne meine zum Teil für mich sensiblen Daten unverschlüsselt gespeichert wissen.
Click to expand...
Das ist ein recht interessantes Argument wenn auch irgendwie leicht von Paranoia geeprägt -> du hast offensichtlich höhere Anforderungen an die Datensicherheit als die allseits beliebte NSA .
Es ist schade dass gängige Festplatten nicht wie die meisten SSD's eine vollwertige AES256 Verschlüsslung auf alle Daten schmeissen aber dann wiederum... wie will man auf einem Server ein Bios HDD Passwort eingeben?


Aaaaaber zu zu deinem eigentlichen Problem... :D
Spricht was dagegen nur die wichtigen Daten (lies: /home/ , /var/www, ...) in einen dm-crypt Container zu packen und das komplett restliche System unangetastet zu lassen? Das sollte die einfachste Lösung darstellen und auch bei Problemen mit dem Container ein voll funktionelles System bereitstellen.

Übrigens - in der Annahme dass ein bereitgestellten Rescue-System voll vertrauenswürdig ist - solltest du einen Hash (bspw Tripwire) deines Bootsystems auf einem externen Speicher ablegen um etwaige Manipulationen erkennen zu können. Allerdings entsteht so ein nicht zu vernachlässigender Mehraufwand.
 
Nicht ganz onTopic

parkbank said:
Ganz so unsinnig ist der Aufwand meines Erachtens nach nicht. Dass Verschlüsselung im laufenden Betrieb wenig zur Sicherheit beiträgt, ist klar.
Interessant sind in diesem Zusammenhang, zumindest für mich, aber folgende zwei Szenarien:
Click to expand...

Könntest du mir erklären, warum Verschlüsselung im laufenden Betrieb wenig beiträgt? Ich meine klar, wenn man mit TC verschlüsselt, liegen die Daten ja entschlüsselt auf dem Rechner. Trotzdem hat der Angreifer ja ERSTMAL keinen "Software"seitigen Zugang zum Server über die Dienste und müsste Exploits oder eine falsche Konfiguration der Software ausnutzen. Er könnte natürlich den Server ausschalten, vom Netz nehmen und die Software im unverschlüsselten Teil manipulieren, aber dann würde man ja mitbekommen, dass der Server zumindest offline war. Würden wir das weiter spinnen und jedesmal wenn der Server offline war mit einem frischen OS versehen, blieben nur noch die Sicherheitslücken :-) Naja macht bestimmt auch keiner.

parkbank said:
[*] Der Hoster tauscht eine der Festplatten aus, entsorgt die getauschte Platte aber nicht richtig und ein Mitarbeiter verkauft sie mal schnell für ein paar Euro auf ebay. In so einem Fall möchte ich ungerne meine zum Teil für mich sensiblen Daten unverschlüsselt gespeichert wissen.
Click to expand...

Genau aus diesem Grund verschlüssele ich meine Daten auf dem Server :-)
Hab neulich erst eine gebrauchte Platte in der Bucht gekauft und die war nicht mal formatiert!
 
Könntest du mir erklären, warum Verschlüsselung im laufenden Betrieb wenig beiträgt?
Click to expand...
Du hast die Frage ja selbst bereits beantwortet:
"Ich meine klar, wenn man mit TC verschlüsselt, liegen die Daten ja entschlüsselt auf dem Rechner. "

Eine Verschlüsslung trägt somit im Betrieb nichts bei (=>keine Erhöhung des Aufwands für den Angreifer) weil alle Daten schlicht bereits entschlüsselt vorliegen. Dass er natürlich erstmal in das System eindringen muss ist klar aber gilt auch für ein nicht verschlüsseltes System gleichermassen.
 
Hallo,

wie schon gesagt, über den Sinn oder Unsinn des ganzen braucht man nicht wirklich reden.
Nennen wir es einfach Paranoia. Dann bin ich das eben leicht (oder ganz :D).

Die Frage jedoch bleibt.
Ich habe eine HDD mit dem System. Und eine weitere HDD.
Nun möchte ich gerne beide über LVM zu einer großen Verbinden und verschlüsseln.
Jedoch sollte da keine KVM vorhanden und auch sonst keine Möglichkeit ein anderes System zu booten das ganze ohne reboot erfolgen.
Also dachte ich an eine Partitionierung der ersten HDD für das Bootsystem ohne verschlüsselung.
Die Restliche Partition mit der anderen HDD zusammenführen und verschlüsseln.
Sollte mal eine weitere HDD eingebunden werden müssen sollte diese sich aber auch in die verschlüsselte Partition einbinden lassen so dass diese Partition wieder nur eine große ist.

Ich hoffe ich konnte das verständlich erklären was ich vorhabe aber leider nicht weis ob das so möglich ist.

Gruß
thomas.
 
d4f said:
Sofern du nicht garantiert den Boot von einem read-only Medium durchführst kann der Angreifer das Startsystem dann manipulieren ...
Click to expand...
Korrekt. Absolute Sicherheit gibt es nicht. Wer an meine Daten rankommen möchte, wird es schaffen. Zur Not eben mit einem Schraubenschlüssel (http://xkcd.com/538/) ;) Für mich ginge es eher darum, es einem Angreifer so schwer wie möglich zu machen, ohne einen abartigen Mehraufwand betreiben zu müssen.

d4f said:
Das ist ein recht interessantes Argument wenn auch irgendwie leicht von Paranoia geeprägt
Click to expand...
Auch das ist korrekt :). Es ist aber meines Erachtens nach gar nicht so abwegig, dass sowas tatsächlich passiert: http://heise.de/-149643, http://heise.de/-199832 (zwei auf Anhieb gefundene Beispiele).
 
thomas7 said:
Ich habe eine HDD mit dem System. Und eine weitere HDD. Nun möchte ich gerne beide über LVM zu einer großen Verbinden und verschlüsseln. Jedoch sollte da keine KVM vorhanden und auch sonst keine Möglichkeit ein anderes System zu booten das ganze ohne reboot erfolgen.

Also dachte ich an eine Partitionierung der ersten HDD für das Bootsystem ohne verschlüsselung. Die Restliche Partition mit der anderen HDD zusammenführen und verschlüsseln. Sollte mal eine weitere HDD eingebunden werden müssen sollte diese sich aber auch in die verschlüsselte Partition einbinden lassen so dass diese Partition wieder nur eine große ist.
Click to expand...

Das klappt bestimmt auch ohne Reboot. Aber irgendwann wird Dein System wegen des Kopierens der Daten eine Library nicht mehr finden und Du musst dann nachhelfen. Da Dein geplantes Bootsystem ohnehin ausreichend vollständig sein muss, sollte es - genügend freier Platz vorausgesetzt - in etwa so gehen:

1. Die erste Platte mit dem Bootsystem ausstatten und in dieses Bootsystem starten.

2. Alle anderen Daten auf die zweite Platte kopieren.

3. Den restlichen Platz auf der ersten Platte mit Verschlüsselung Deiner Wahl versehen und darin LVM einrichten.

4. Die Daten auf die neu eingerichtete erste Platte kopieren.

5. Die zweite Platte mit Verschlüsselung Deiner Wahl versehen und den Inhalt des Containers als PV zur VG hinzufügen.

6. Größe der LV und Dateisysteme anpassen.

8. Bootvorgang wie geplant fortsetzen.

--
.A.
 
Vielen Dank für Antworten.

Ich habe jetzt auch ein Rescue System kann also booten und werde mal sehen wie ich das alles anstelle.
Für LVM und dm-crypt gibt es ja diverse How-To aber so richtig schlau werde ich noch nicht daraus.
Viel schief gehen kann nicht, Noch ist alles recht junfräulich.

So werde ich also versuchen die große Partition der ersten HDD (sda4) zu verkleinern und den übrig gebliebenen Bereich einem LVM zu zuordnen.
Die zweite HDD (sdb) werde ich komplett dem LVM zuordnen und dann diese beiden zu Einem verbinden und dann mit dm-crypt verschlüsseln.

Somit sollte es ja auch funktionieren wenn ich eine weitere HDD einbinden möchte diese dann auch in den LVM einzubinden sodass eine große Partition entsteht.

Soweit meine Theorie.
Auch von Early-SSH habe ich gelesen aber ich werde ja booten können und dann entschlüsseln können ohne Early-SSH denn boot bleibt ja unverschlüsselt.
Erstmal Sicherheit bzw. Sinn oder Unsinn aussen vorgelassen ;)

Gruß
thomas
 
thomas7 said:
Auch von Early-SSH habe ich gelesen aber ich werde ja booten können und dann entschlüsseln können ohne Early-SSH denn boot bleibt ja unverschlüsselt.
Click to expand...
Vielleicht habe ich deinen Ansatz falsch verstanden, aber eine Möglichkeit, das Passwort einzugeben, benötigst du auch mit unverschlüsseltem /boot.
 
Mein Ansatz ist ja nicht das ganze System zu verschlüsseln.

Also HDD1 mit Bootpartition wird verkleinert sodass ein großer Teil frei ist.
Dieser soll mir HDD2 "verschmelzen" zu einer einzigen großen Partition.
Diese soll verschlüsselt werden.
Eine möglichkeit zum hinzufügen einer dritten HDD soll offen bleiben also per LVM ebenso eingebunden werden ich die große Partition und dann eben auch verschlüsselt werden.

Das ganze wird nur bei Bedarf entschlüsselt und liegt die meiste Zeit verschlüsselt ohne mount am Server.
Aber eben wenn benötigt soll man drauf zugreifen können.
 
Dann noch ein kleines Update meinerseits.

Habe es nun geschafft.
Folgendermaßen bin ich vorgegangen.
Partition auf HDD1 verkleinert mit resize2fs
Partition gelöscht
Wieder angelegt mit neuer größe
Dem frei zugeordneten Speicher dann auch noch eine Tabelle geschrieben.
Jetzt der neuen Partition sowie der zweiten HDD mit cryptsetup verschlüsselt.
Zuvor mit badblocks noch randoms schreiben.
Wenn das fertig ist (kann eine weile dauern :) ) mit luksOpen öffnen.

Jetzt noch PV, VG und LV anlegen, mounten und schon habe ich eine neue verschlüsselte große Partition die sich mit weiteren partitionen erweitern lässt sofern der Speicher mal zu ende geht.

Gruß
thomas
 
You must log in or register to reply here.
Back
Top