Disk Array verschlüsseln

RobJ

Well-Known Member
Hallo,

ich möchte ein Diskarray (Raid 5 mit 8x320) verschlüsseln. Was empfehlt ihr mir dazu? Ich habe bisher vor Geli zu verwenden. Unter Debian habe ich Erfahrungen mit dm-crypt LUKS gemacht. Dabei ist mir aufgefallen, daß das Filesystem mit chkfs nicht mehr überprüfbar ist.
Wird das mit Geli genauso sein? Auf welcher Ebene findet die Verschlüsselung statt? Was passiert, wenn standardmäßig ein fschk gestartet wird? Wird die Geli Platte dabei zerstört?
Ich möchte nur ein FS erstellen. Was muß ich für das Durchbrechen der 2TB Grenze beachten?

Grüße
RobJ
 
Hi,


Also ich hab sehr gute Erfahrungen mit GELI gemacht.
Mit FBSD > 6.2 ist es sogar möglich die / (Slice) zu verschlüsseln.

Mit Geli ist es auch möglich die slice im geli zu prüfen mit fsck_ufs (falls man ufs einsetzt)

Also Lösch Dein Linux und freunde Dich mit Beastie an.

BSD - The Power to Server

Unix, life free or die.
 
Also, zur 2 Terabytegrenze:
- Mit UFS2 kannst du ohne Probleme mehrere tausend Terabyte verwalten
- Nach einigen Änderungen in fsck, die ab 6.1(?) drinnen sind, ist es nun auch möglich mehrere Terabyte große Dateisysteme zu scannen ohne das man in "out of Memory"-Probleme läuft.
- DOS-Partitionierte Festplatten (mbr und dieses Kram) sind auf maximal 4TB, praktisch meist sogar nur 2TB begrenzt. Umgehen kann man das durch GPT-Partitionen. Leider kann das x86-BIOS davon nicht ohne weiteres booten, weshalb hab den zugehörigen Fake-MBR zweckentfremden muss... Oder einfach von einer anderen, kleineren Platte starten.

Zu GELI:
- geli ist eine Geomklasse, liegt also unterhalb deines Dateisystems.
- fsck und alles andere sind davon also nicht betroffen
- geli kann mit weiteren Geomklassen kombiniert werden, wie gmirror z.B.
 
Also ich kann zu der 2 TB Grenze praktisch nichts sagen, weil ich schlicht und einfach nicht genug Platten habe. Aber ich hab erst vor ein paar Tagen 2x 250 GB Platten mit gemirror und geli aufgesetzt und ich hatte auch die Sorge wie du das das nicht richtig funktioniert. Geli mir gmirror ist schon mal gar kein Problem. fsck hab ich dann auch mal ausprobiert und das funktioniert ebenfalls. Eigentlich ist es genau so wie Yamagi gesagt hat. ;)
 
Also Lösch Dein Linux und freunde Dich mit Beastie an.

BSD - The Power to Server

Nimm's bitte nicht persönlich aber abgesehen davon, dass es im Slogan "to serve" heisst, wirkt deine Aufforderung, Linux zu löschen, recht aggressiv.

Wir sind zwar alle pro-BSD aber nicht unbedingt gegen Linux (oder jedenfalls nicht auf die Art, die man aus manchen Linux Foren kennt.)

Ich z.B. habe nach 2 Jahren *BSD auf meinem Laptop wieder Linux drauf,
wollte es auf meinen Home-Server aber nicht wieder aufspielen.
 
Also Lösch Dein Linux und freunde Dich mit Beastie an.
also, irgendwie verschliesst sich mir der kontext dieser aussage...
egal.
ZURUECK ZUM THEMA!!

geli verschluesselt also nicht auf dateisystemebene? super!
das ist in meinen augen naemlich immer die groesste schwachstelle bei crypto-filesystemen gewesen.
am besten ist es imho wenn nur die einzelnen dateien gecrypted werden.

als filesystem sollte man dann auch etwas mit journaling versuchen.
und was die 2tb-grenze angeht rate ich dir persoenlich auch zu ZFS, das passt auf alle faelle.

vor allen dingen ist es fuer diese plattengroessen ausgelegt. und damit auch rattenschnell.
 
Hallo,

danke für Eure Tipps.
Dann werde ich also folgendes probieren.

1. vorhandene Platten shredern.
2. Raid5 vom Controller initalisieren lassen
3. Mit gpt eine UFS Partition erstellen - das System bottet von einer eigenen Systemplatte
4. Mit Geli verschlüsseln
5. Arrayinhalte zurückspielen

ZFS hört sich wirklich super an. Habe die Nachrichten hier und im Netz verfolgt. Allerdings warte ich lieber auf die 7er. Bis dahin entwickle ich auch einen Plan, wie sich ZFS konfigurieren läßt.

Grüße
RobJ
 
Hi,


danke für die schnelle Info. Wie steht es um die Stabilität von ZFS?
Bisher verstehe ich es als komplexes Softwareraid mit vielen extra Funktionen.
Würdet ihr ZFS die logische Verknüpfung zweier Hardwareraids zu trauen?
Genau diese Entscheidung muß ich fällen.
Ich habe zwei DiskArrays. Es wäre schön, nur einen Mountpoint zu haben. ZFS könnte einige Probleme beseitigen. Wird z.B. das Softrwareraid, oder die beiden einzelnen Raids verschlüsselt?. Später könnte ich weitere Platten einfach "anhängen".
Also, wer traut sich mit ZFS was?

Grüße
RobJ
 
Hmm gute frage, ich denke mal nicht, dass hier bereits so viele Leute ZFS benutzen.
Nutze einfach mal die Mailing List, dort gibts evtl. weitere Infos. Pawel selbst gibt vielleicht auch Auskunft, sind ja alles freundliche hilfsbereite Menschen.
 
Hallo,

Hmm gute frage, ich denke mal nicht, dass hier bereits so viele Leute ZFS benutzen.
Nutze einfach mal die Mailing List, dort gibts evtl. weitere Infos. Pawel selbst gibt vielleicht auch Auskunft, sind ja alles freundliche hilfsbereite Menschen.

Ich werde wohl auf die 7er FreeBSD warten.
Meine beiden Raids werde ich mit gpt, UFS2 und Geli bearbeiten.
Bin mal gespannt, wie es sich entwickelt.

Grüße
RobJ
 
Hallo Allerseits

Dabei ist mir aufgefallen, daß das Filesystem mit chkfs nicht mehr überprüfbar ist.

Also das muss ich klarstellen! DAS ist definitiv NICHT der FALL.
Die Verschlüsselung mittels dm-crypt unter Linux fügt nur eine weitere schicht beim zugriff aud den Datenträger hinzu. D.h. Statt wie bisher direkt auf (z.B hda1) den Datenträger zu schreiben / ihn zu formatieren / ihn mittels fsck zu checken muss man das alles mit dem angelegten dm-crypt device (z.B. hda1_crypted) anstellen.
Es wird beim setup bzw. beim starten nämlich nur (richtiges Passwort vorausgesetzt) das mapping angelegt. Demzufolge darf jeder zugriff von anderen programmen nicht mehr auf /dev/hda1 erfolgen, sondern muss auf /dev/mapper/hda1_cryptet stattfinden. In den standard Startskripten von Debian war eine verschlüsselung noch nicht vorgesehen, weshalb man beim einrichten darauf achten musste das das startup von dm-crypt mit der passworteingabe VOR dem checken des dateisystems durchgeführt wird. Ansonsten versucht nämlich fsck die verschlüsselte partitionstabelle zu interpretieren bzw. zu reparieren.

Zu GELI:
- geli ist eine Geomklasse, liegt also unterhalb deines Dateisystems.
- fsck und alles andere sind davon also nicht betroffen
- geli kann mit weiteren Geomklassen kombiniert werden, wie gmirror z.B.
das selbe gilt für die verschlüsselung mittels dm-crypt!

geli verschluesselt also nicht auf dateisystemebene? super!
das ist in meinen augen naemlich immer die groesste schwachstelle bei crypto-filesystemen gewesen.
am besten ist es imho wenn nur die einzelnen dateien gecrypted werden.
Das ist blödsinn... s.o. DAS ist nämlich die größte stärke dieses konzeptes. Es werden eben nicht nur die Daten verschlüsselt, sondern auch das Filesystem, die Verzeichnisstruktur die positionsdaten der Datei auf dem Datenträger usw...
Wäre das nicht der fall hätte man ja z.B einen Ordner mit 2000 Dateien und somit 2000 Dateinamen wodurch man sich evtl. schon recht gut einen überblick über den inhalt machen kann. So hat man aber nicht die geringste ahnung was wo in welcher anzahl mit welchem namen und mit welchem inhalt gespeichert wurde.

Würdet ihr ZFS die logische Verknüpfung zweier Hardwareraids zu trauen?
Genau diese Entscheidung muß ich fällen.

Du willst also dein Array verschlüsseln und nutzt dafür aber einen Hardwareraid controller ??
Das finde ich nicht durchdacht... Das einzige was für einen hardware controller spricht ist dessen performance. Dieser vorteil wird aber von der Verschlüsselung ja sowas von zunichte gemacht. Wenn die cpu schon Terabyteweise daten verschlüsseln muss kann sie auch gleich nocht die rechenarbeit für das softwareraid mit übernehmen. Das macht vielleicht 10% mehr rechnerei notwendig, zumal du ja eh ein software-raid mit den beiden hardware-raids erstellen willst. Also im prinzip fügst du mit dem HW-setup unter dem SW-setup nur noch ein (evtl. Problematisches) glied in die kette.

Benutze deinen controller nur für diebereitstellung der anschlüsse und lass die finger von der eingebauten arrayverwaltung. Die Vorteile liegen auf der hand... Du kannst dein array erstellen wie DU es haben willst und nicht wie es dir die Hardware vorgibt. Du bist unabhängig vom controller hersteller. Im defektfall kommst du mit jedem x-beliebigen controller wieder an deine Daten, du kannst die reihenfolge der platten am controller wechseln wie du lustig bist (die position der platte im array wird bei SW-setups durch eine signatur auf der platte festgelegt, nicht durch deren position am controller wie bei vielen HW-arrays). Du hast zugriff auf die einzelnen Platten und kannst sie somit auch z.B. mittels SMART überwachen. Bei HW muss das der controller machen, sofern das überhaupt unterstützt wird. Wofür du dann aber auch wieder die herstellersoftware brauchst.

Es gibt noch viele viele weitere gründe, ganz besonders bei deinem angedachten setup, nur das SW-array zu nutzen und die hardware außer acht zu lassen, aber ich denke ich hab micht schon genug ausgetobt.

eins noch: eine Online expansion ist unter linux mit dem raid5 treiber auch kein problem, und dm-crypt kommt damit eh klar.

mfg
rootgremlin
 
Hallo rootgremlin,

>...
Also das muss ich klarstellen! DAS ist definitiv NICHT der FALL.
>...
Demzufolge darf jeder zugriff von anderen programmen nicht mehr auf /dev/hda1 erfolgen, sondern muss auf /dev/mapper/hda1_cryptet stattfinden.
>...

Ups, da hast Du Recht. Im Eifer des Gefechts hab ich das falsche Device angesprochen.

>...
In den standard Startskripten von Debian war eine verschlüsselung noch nicht vorgesehen, weshalb man beim einrichten darauf achten musste das das startup von dm-crypt mit der passworteingabe VOR dem checken des dateisystems durchgeführt wird. Ansonsten versucht nämlich fsck die verschlüsselte partitionstabelle zu interpretieren bzw. zu reparieren.
>...

Da fschk.ext3 selbst nach x-maligem Starten kein Filesystem, da verschlüsselt, erkennen wird, repariert es doch auch nicht, oder doch? Nun ja, ich will hoffen, daß ich mit meiner Annahme richtig liege. Mit meinen Kenntnissen an den Startskripten herum zu basteln, halte ich für gewagt.

>...
Du willst also dein Array verschlüsseln und nutzt dafür aber einen Hardwareraid controller ??
Das finde ich nicht durchdacht...
Das einzige was für einen hardware controller spricht ist dessen performance.
>...

Warum denn das? Ich benutze bisher zwei 8-fach DiskArrays von Infortrend. Das sind super solide Maschinen. Mir geht es nicht um Geschwindigkeit im Dauertransfer, sondern um stets schnellen Zugriff, egal auf welches File. Welche Hardware würdest Du denn dafür nehmen? Bisher sind es ca. 5TB.

>...
Dieser vorteil wird aber von der Verschlüsselung ja sowas von zunichte gemacht. Wenn die cpu schon Terabyteweise daten verschlüsseln muss ...
>...

Zunächst muß sie nur die Daten dekodieren, die abgerufen werden. Ich erhoffe mir mit einer Cryptokarte noch einer erhebliche Beschleunigung. Bisher sind es mit dm-crypt 10MB/s mit einem PIV 2,4 Ghz. Das reicht für normale Belange aus. Weißt Du, was die Cryptokarten bringen und ggfs. kosten?

>...
kann sie auch gleich nocht die rechenarbeit für das softwareraid mit übernehmen. Das macht vielleicht 10% mehr rechnerei notwendig, zumal du ja eh ein software-raid mit den beiden hardware-raids erstellen willst. Also im prinzip fügst du mit dem HW-setup unter dem SW-setup nur noch ein (evtl. Problematisches) glied in die kette.
>...

Ich habe bisher zwei Hardware Raid5s. Ein Softwareraid war nicht mein Ziel. Es ging viel eher, nach dem Einwurf hier im Thread, um den Gedanken ZFS einzusetzen.
Die Raids wurden angeschafft, gerade weil ich dem Softwareraid aus dem Weg gehen wollte. Mir ist nicht klar, wie stabil die Biester laufen. Was passiert bei einem Crash, Strom aus, oder ähnliches?

>...
...Im defektfall kommst du mit jedem x-beliebigen controller wieder an deine Daten, du kannst die reihenfolge der platten am controller wechseln wie du lustig bist (die position der platte im array wird bei SW-setups durch eine signatur auf der platte festgelegt, nicht durch deren position am controller wie bei vielen HW-arrays).
>...

Das werde ich mal probeweise mit einem Highpoint 454 Billigcontroller probieren.
Aber nicht mit den beiden Hardwareraids.

>...
...hab micht schon genug ausgetobt.

Danke für Deine Korrekturen, Hinweise und Vorschläge.

Grüße
RobJ
 
Hallo,

Da fschk.ext3 selbst nach x-maligem Starten kein Filesystem, da verschlüsselt, erkennen wird, repariert es doch auch nicht, oder doch? Nun ja, ich will hoffen, daß ich mit meiner Annahme richtig liege. Mit meinen Kenntnissen an den Startskripten herum zu basteln, halte ich für gewagt.

Das passiert definitiv nicht. Automatismen die was zerstören hatte ich noch nie unter Linux. Für solch eine gravierende änderung bei der Ausführung eines fsck's ist zumindest ein --force notwendig. Ich bin mir aber ziemlich sicher das fsck selbst dann nihts kaputt machen wird.

Warum denn das? Ich benutze bisher zwei 8-fach DiskArrays von Infortrend. Das sind super solide Maschinen. Mir geht es nicht um Geschwindigkeit im Dauertransfer, sondern um stets schnellen Zugriff, egal auf welches File. Welche Hardware würdest Du denn dafür nehmen? Bisher sind es ca. 5TB
.

Nach dem was ich hier gelesen hatte ging ich davon aus das das ganze Projekt im privaten Bereich anzusiedeln ist. Gerade dabei würde es meines erachtens Sinn machen das Setup mittels Software zu realisieren, speziell auch wegen der im vergleich zum crypto aufwand nicht ins gewicht fallenden mehrbelastung der cpu durch die xor raid5 berechnung.

Gerade wenn es nicht um die Dauertransferleistung geht finde ich die "reine" softwarelösung absolut hinreichend, eher sogar besser, weil sie einem so ganz nebenbei auch einiges an Geld, aber vor allem Nerven sparen kann. Als Hardware kommt alles in Frage was einen stabilen Treiber im Linux Kernel hat.

Nochmal: Ich gehe hier vom Privatanwender aus. Und bei dem ist das Finanzielle sicher oft das entscheidende kriterium welcher Controller angeschafft wird. Dabei werden entsprechende einbußen beim Service in kauf genommen. Damit meine ich vornehmlich den Treibersupport für zukünftige versionen, aber auch schon die qualität der verwaltungssoftware.

Zunächst muß sie nur die Daten dekodieren, die abgerufen werden. Ich erhoffe mir mit einer Cryptokarte noch einer erhebliche Beschleunigung. Bisher sind es mit dm-crypt 10MB/s mit einem PIV 2,4 Ghz. Das reicht für normale Belange aus. Weißt Du, was die Cryptokarten bringen und ggfs. kosten?

Über Crypto Hardware kann ich keine Aussagen treffen. Aber 10MB/s scheint mir arg wenig zu sein wenn ich annehmen kann das du halbwegs aktuelle Platten benutzt.
Ich hatte bei meinen Heimserver bervor ich ihn final aufsetzte einige test laufen lassen. Hardware ist ein Dual XEON HT 3,4GHz mit 4x400GB Seagate Barracuda ES SATA an einem Onboard Promise 150TX4 Controller als software raid5 und dm-crypt. Verschlüsselung ist aes256.
Das Testweise erstellte Raid0 lieferte kontinuierlich ca. 130MB/s lesen/schreiben
Das dannach erstellte Raid5 lieferte ebenfalls kontinuierlich ca. 130MB/s lesen/schreiben was auf eine schwäche in Promise chip bzw. dessen anbindung ans systen deuten lässt.
Jedefalls Reduzierte sich der Dauerdurchsatz auf ca 60-70MB/s wenn das raid5 verschlüsselt wurde.
Die Auslastung der CPU kann ich auch nicht als massiv bezeichnen, lag bei etwa 20% auf einer CPU, die anderen idle.

Im nachhinein kann ich aber nicht mehr sagen mit welcher schlüsselstärke ich testete und ob der aes algorythmus damals schon als asm optimierte version eincompilliert war.

Die Raids wurden angeschafft, gerade weil ich dem Softwareraid aus dem Weg gehen wollte. Mir ist nicht klar, wie stabil die Biester laufen. Was passiert bei einem Crash, Strom aus, oder ähnliches?

Also meiner erfahrung nach absolut Stabil.
Wie ich ja schon geschrieben hatte wird die Position der Platte im Array anhand einer signatur festgelegt, die nur einmal beim initialisieren geschrieben wird.
Insofern also unproblematisch. Ebenso bei der crypto-schicht, da diese sozusagen immer transparent vor dem eigentlichen datenträgerzugriff ist.
Das Gröste Problem dürfte imho das Deiteisystem sein, was aber ebenso auf Wardwarelösungen zutrifft.

Ich baharre deswegen für den Heimgebrauch so auf das SW setup weil es mir auf lange sicht das praktikabelste erscheint.
Geht im laufe der zeit einer der teuren HW kontroller kaputt bin ich unter umständen gezwungen genau diesen typ nochmals zu besorgen (der u.U aber nicht mehr hergestellt wird) und dessen nachfolgermodelle inkompatibel sind.
Evtl. wird der Hersteller aufgekauft und bietet keine treiber mehr für z.B 2.8er Kernel serien an.
Evtl bietet er keine OSS treiber und ich wäre deswegen auf ein kompatibles OS/kernel version festgelegt.
u.s.w.

Danke für Deine Korrekturen, Hinweise und Vorschläge.

Bitte!

Grüße,
rootgremlin
 
Zurück
Oben