Ich habe einen Homeserver, der auf einem HP Proliant Microserver Gen7 mit 10 GB ECC-Speicher und Debian 8 (Jessie) läuft. Momentan habe ich eine kleine Systemfestplatte (gesichert mit rsnapshot) und 2 x 3 TB Speicherfestplatten, die als Raid 1 mit mdadm eingerichtet sind. Darüber habe ich LVM-Gruppen für verschiedene Zwecke, eine davon ist zusätzlich mit dm-crypt/luks verschlüsselt, um private Daten zu speichern.
Ich plane, zwei weitere Festplatten gleicher Größe für den Speicherpool zu kaufen und den Server wahrscheinlich von Grund auf neu einzurichten. Ich werde auf jeden Fall wieder Debian verwenden, dieses Mal aber wahrscheinlich mit XenServer-Virtualisierung. Der Speicherpool wäre also 4 x 3 TB groß, wobei bei Raid1 6 TB nutzbar bleiben und bei Raid5 (oder RaidZ1) 9 TB.
Obwohl die Kombination aus mdadm / lvm / dm-crypt gut funktioniert, finde ich sie unglaublich komplex, insbesondere wenn es darum geht, eine einfache Notfallwiederherstellungsstrategie zu planen. Ich muss für jede der Schichten recherchieren, was der beste Prozess zum Sichern und Wiederherstellen von Metadaten ist usw.
In einer perfekten Welt würde ich den gesamten Speicher zu einem verschlüsselten RAIDZ1-Pool machen, ABER die Verschlüsselung hat es noch nicht in das ZFS unter Linux geschafft und nach meinen Recherchen ist es völlig unklar, WANN mit einer Implementierung zu rechnen ist.
Bei Btrfs ist die Situation ähnlich: Es scheint zumindest produktionsstabil zu sein, aber leider wird auch die Verschlüsselung erst in einer unvorhersehbaren Zukunft möglich sein.
Von den Dateisystemen, die ich bevorzugen würde, unterstützen beide (noch) keine native Verschlüsselung unter Linux. Nun, es gibt eine Reihe von Anleitungen und Tutorials zur Verwendung von LUKS-verschlüsselten LVMs in Verbindung mit ZFS oder BtrFS. Es gibt den Ansatz, LVM über ZFS oder ZFS über LVM zu verwenden – für mich klingt das nach einem schrecklichen Durcheinander.
Das Konzept von EncFS gefällt mir überhaupt nicht, daher ist das auch keine Option.
Hoffentlich gibt es einige Optionen, von denen ich noch nicht gehört habe, daher meine Frage hier: Was gibt es sonst noch, um dies zu erreichen, und ein „einfach (im Sinne von erweiterbar usw. wie ZFS, Fehlerkorrektur) zu verwaltendes Dateisystem zur Auswahl unter Linux für Heimserver, das vollständig oder teilweise verschlüsselt werden kann?“
UPDATE Dez. 2017: ZFS auf Linux mit Verschlüsselung in Kürze verfügbar: https://blog.heckel.xyz/2017/01/08/zfs-encryption-openzfs-zfs-on-linux/
Antwort1
mdadm / lvm / dm-crypt ist wahrscheinlich die beste Lösung – und es ist überhaupt nicht so komplex – Sie müssen nur jede Schicht entsprechend behandeln – oder, je nach Bedarf, mdadm /dm-crypt/lvm (wenn Sie möchten, dass alle LVs ein einzelnes Gerät mit einer Passphrase gemeinsam nutzen)
Sie haben Recht, encfs nicht zu verwenden -es ist unsicher.
Antwort2
Wenn Sie sich für das ZFS-Setup entscheiden, würde ich Folgendes vorschlagen:
Verwenden Sie kein LVM, erstellen Sie ZVOLs über dem Pool
für Betriebssystem - GPT-Partition für unverschlüsselten ZFS-Pool mit Spiegel (oder Raidz)
- für private Daten - verwenden Sie LUKS auf der GPT-Partition und erstellen Sie dann darüber einen ZFS-Pool-Spiegel (oder Raidz).
Nach dem Booten melden Sie sich per SSH an, geben das Passwort für die verschlüsselten Partitionen ein, importieren den Pool, der auf LUKS liegt, und starten dann virtuelle Maschinen (am besten schreiben Sie ein Shell-Skript).
Das vorgeschlagene Schema ist alsoGPT / LUKS / ZFS / Daten oder ZVOL für VM
Vergessen Sie nicht, eine BIOS-Partition (Größe 1 MB) zu erstellen. Wenn Sie keinen UEFI-Boot verwenden, vergessen Sie auch nicht, eine Partition für GRUB zu erstellen, etwa 150 MB.
bei starkem zufälligem E/A-Verkehr schlage ich vor, ZFS Prefetch zu deaktivieren (echo 1 > /sys/module/zfs/parameters/zfs_prefetch_disable)
Antwort3
Dies ist ein Ratschlag für alle, die einige Daten verschlüsseln möchten: Verschlüsseln Sie immer 100 % aller möglichen Speicher, die mit dem Computer verbunden sind, unabhängig davon, ob es sich um die Grub-Partition, die Systempartition, die Home-Partition, die Datenpartition, den Swap-Speicher usw. handelt. IMMER ALLES VERSCHLÜSSELN.
Warum? Weil Sie keine Kontrolle darüber haben, wo die Anwendungen/das System Daten speichern.
Beispielhafter Ablauf von Katastrophenereignissen:
- Booten normal
- Verwenden Sie eine App
- Öffnen Sie ein „privates“ Dokument
- Systemabsturz (Software oder Hardware)
- Der nächste Start funktioniert nicht
- Ein Gerät hat sein Lebensende erreicht (funktioniert nicht mehr)
Sie können nicht löschen, was sich auf einem solchen Gerät befindet (es funktioniert nicht), Sie können es nicht lesen, also, was wurde dort gespeichert? Vielleicht etwas „Privates“? Sie können nicht einmal wissen, was und wo.
Aber jemand anders (vielleicht mit ein paar Millionen in der Tasche) hat es gelesen, also können Sie das Gerät nicht in den Müll werfen, bis Sie bestätigt haben, dass keine „privaten“ Daten darauf sind. Das können Sie allerdings nicht wissen, es sei denn, Sie geben das Gerät an eine Firma weiter. Andererseits sind die „privaten“ Daten gefährdet, vielleicht „kopieren“ sie es (dort arbeitet eine böse Person usw.).
Stellen Sie sich diese Frage: Kennen Sie jede Quellzeile des gesamten von Ihnen verwendeten Codes (Bootcode, Systemcode, Anwendungscode usw.), Quellcode, den Sie selbst kompilieren … und verwenden Sie niemals irgendeine Art von „Binärcode“ … Sie müssen den Compiler also mit Bleistift und Papier kompiliert haben.
Andernfalls verwenden Sie Code, von dem Sie nicht wissen, was er tut.
Randbemerkung: Wenn Sie „private“ Daten verwenden müssen, verbinden Sie diesen Computer nie wieder mit dem Internet. Möglicherweise hat ein Teil der von Ihnen verwendeten App Daten gespeichert und diese später an Internetserver gesendet.
Extremes Beispiel: Sie verwenden eine Schreib-App, um eine TXT-Datei zu lesen. Diese verfügt über einen versteckten Code, um die Datei irgendwo versteckt zu speichern. Nach einigen Jahren der Aktualisierung verfügt diese App (oder eine andere) dann über einen versteckten Code, um die versteckt gespeicherten Daten zu lesen und sie an einen Internetserver oder einen Computer eines Drittanbieters usw. zu senden.
Die Fälle sind extrem? Ich habe es auf die harte Tour gelernt ... auf meinem Linux tritt ein Trojaner (innerhalb einer App, die ich verwenden möchte) auf, der anscheinend nichts tut (hat keine Sockect-Verbindung usw.), aber er protokollierte einige Schreibvorgänge auf der Festplatte und führte einen doppelten Schreibvorgang durch ... nach fast zwei Wochen nahm ein anderer Trojaner diese Informationen und versuchte, sie an eine IP zu senden ... meine Güte, ich hatte einen anderen Computer in der Mitte meiner Internetverbindung (ja, natürlich bin ich das und ich war total paranoid, das hat mich gerettet), um diese Verbindungen zu „entdecken“ und zu „blockieren“ ... ganz zu schweigen davon, dass ich nur „Linux“ verwende, da dies unter Windows nicht unter Kontrolle ist. Solche Trojaner waren da, ohne dass der Autor der App etwas wusste, sie wurden eingeschleust, als die App im Repository gespeichert wurde. Ich hoffe, Sie verstehen, dass ich lieber nicht sage, welche App es war, da sie jetzt „repariert“ wurde ... wer weiß, seit wann!
Denken Sie, ich denke nur an Trojaner, versteckte Dinge usw.? Überhaupt nicht. Denken Sie an Swap-, Temp-Dateien usw. ... Einige Apps speichern das Dokument, das Sie verwenden/erstellen, damit Sie nicht verlieren, was Sie getan haben. Wo zum Teufel speichern sie diese Daten? Nicht unbedingt auf Ihrer verschlüsselten Partition, vielleicht im Swap-, Temp-Ordner oder allgemein dort, wo der Autor der App es wollte. Sie können also nicht immer wissen, wo es gespeichert ist. ... alles wieder verschlüsseln.
Oh, ja, grub.cfg kann in einem RAID0 liegen, LUKS über LUKS ... über LUKS usw. Sie benötigen nur eine sehr kleine Partition für Stufe 1,5 oder 2 von 8 MiB oder weniger im unformatierten Zustand (Bulk Dump), damit Grub2 booten kann ... suchen Sie im Internet nach der BIOS-GRUB-Partition.
Entschuldigung, ich habe ZFS noch nicht ausprobiert und bin nicht sicher, ob Grub-Dateien (grub.cfg usw.) in einem ZFS gespeichert werden können … aber ich habe es getestet, sie über Folgendes zu haben: Ext4 über LVM über LUKS über LVM über LUKS … also auf einigen Ebenen … über LUKS über ein echtes GPT (auch in einem MBR) ohne EFI-Partition und es bootet ordnungsgemäß … musste nur die Erweiterungen „Crypto“ und „LVM“ hinzufügen, als ich Grub2 installierte … ich ziehe es vor, meine eigene grub.cfg einzugeben, also verwende ich nie etwas anderes als grub2-install in Bezug auf Grub2 (ich bin wieder paranoid).
Ich verwende als Haupt-Bootloader immer meinen eigenen grub.cfg, der andere Bootloader aufruft. Auf diese Weise überlasse ich dem System die Verwaltung seines eigenen Bootloaders, ohne den Haupt-Bootloader zu berühren, den ich manuell mit einem Texteditor bearbeite.
Tut mir leid, ich bin total paranoid.
Was müssen Sie denken? Wenn es einen „Ort“ gibt, an dem unverschlüsselte Daten geschrieben/gelesen werden können, sind alle Arten von „privaten“ Daten ein völliger Fehlschlag, da sie manchmal auf diesen unverschlüsselten Teil geschrieben werden können. Um sicher zu gehen, sollten Sie niemals einen unverschlüsselten Teil haben.
PD: Wenn Sie eine EFI-Partition verwenden, bedenken Sie, dass jeder Code darauf schreiben kann, da sie keinerlei Schutz bietet und es sich um eine nicht verschlüsselbare FAT32-Partition handelt.
PPD: Wo können Daten auf einem FAT32 gespeichert werden? Überall, auch auf freiem Speicherplatz. Und auf Ext4? Genau das Gleiche ... immer den gesamten Speicher verschlüsseln.