ZFS mit Geli auf extra Festplatte vs. Full Encyption

kashee Opeiah

FreeBSD rockz
Hallo zusammen,
ich habe mich seit langer Zeit mal wieder angemeldet und grüße alle BSD-Freunde :).

Ich bin gerade in der Plannungsphase mir ein eigenes Storage zu bauen. Bis auf die CPU, welche morgen kommt, habe ich bereits alle Hardware zusammen.

Mein Plan sieht vor, auf einer einzelnen Festplatte ein FreeBSD 12.1 mittels GPT und UEFI zu installieren.
Dazu sollen zwei gleich große Festplatten im ZFS Mirror mit Geli-Verschlüsselung laufen. In diesem Geli-Mirror sollen dann alle schützenswerten Werten Daten liegen.

Hintergrund, der Server/PC soll über keine Grafikkarte, Maus und Tastatur verfügen.
Wenn er startet soll er also ohne Eingabe des Passwortes hochfahren und dann will ich das Passwort zum entschlüsseln per SSH eingeben.

Was haltet ihr von diesen Ideen? Oder empfiehlt ihr mir doch eine Full Disk Encryption?

Viele Grüße
KO
 
Ich verstehe jetzt nicht ganz was Du mit "ZFS Mirror mit Geli-Verschlüsselung" und "Full Disk Encryption" meinst. GELI ist imho eine Full Disk Encryption.

Du kannst:
- Mit GMIRROR einen Mirror erstellen, diesen mit GELI verschlüsseln und darauf einen einfachen ZFS Pool legen.
- Die Platten einzeln mit GELI verschlüsseln und darauf einen ZFS Mirror legen.
- Auf die beiden Platten einen ZFS Mirror legen und dessen eigene Verschlüsselung nutzen.

Ob's noch andere Möglichkeiten gibt...?
 
Ich denke so wie er es beschreibt soll das Basissystem auf einer einzelnen, unverschlüsselten Platte liegen.

Da musst du folgendes beachten: Swap sollte auch verschlüsselt werden, hier am besten eine eigene Partition auf der OS Platte dafür bereitlegen und mit Geli OTP verschlüsseln.
Wenn Programme sterben schreiben sie oft einen Coredump ins aktuelle Workdir, auch da können sensitive Daten abgelegt werden. Auch schreibt so manches gerne mal nach /tmp oder /var/tmp oder /var/run.. /var/cache...

Das musst du halt alles beachten. Genau kommt es aber immer auf deinen Usecase an. Wenn du ALLES verschlüsselst musst du dir aber keine Gedanken machen.

Zum Thema Unlock: Ich nehme an das Ding soll bei dir irgendwo in reichweite stehen, da kann man auch gut eine alte Tastatur ranhängen und das PW blind eintippen. Handhabe ich bei meinem Homeserver auch so.

Die professionelle Variante wäre natürliche ein eigener remote Access Controller. Die kosten aber natürlich gut Geld.
 
@Rosendoktor
oh, dann habe ich mich wohl in der Terminologie vertan. Entschuldige bitte das Missverständnis.
Ich möchte es genau so machen, wie von @medV2 beschrieben.
Das Basissystem auf einer unverschlüsselten Festplatte speichern und dann den ZFS Mirror mit Geli verschlüsseln.

Den Swap zu verschlüsseln ist schon mal eine sehr gute Empfehlung. Danke dafür.

Ja, der Usecase ist das er in meiner Reichweite steht bzw. in einer Abstellkammer, wo ich aber nicht immer hinrennen will :ugly:
 
Ok, wie soll denn das System hochgefahren werden? Willst Du Dich per ssh anmelden, die Daten entsperren und dann die Dienste starten die damit arbeiten sollen? Anstatt jetzt einzeln swap, /tmp, /var/... zu verschlüsseln kannst Du auch auf dem verschlüsselten ZFS Mirror ein komplettes zweites System installieren (mit identischer FreeBSD Version, selbstredend), und dieses nach dem Ensperren mit "reboot -r" starten. Das erste, unverschlüsselte System wird dann heruntergefahren und ausgehängt, und das zweite, vollverschlüsselte hochgefahren. Lediglich der Kernel läuft dabei weiter. So hab ich es gemacht auf meinem kleinen FreeBSD Server im Flur.
 
Danke für deine Anwort.
Mir war nicht klar, dass Swap verschlüsseln, mit den Einschränkungen beim Starten der Dienste einhergeht.
Hast eine Anleitung für mich, oder kannst du mir grob skizieren wie du dabei vorgegangen bist?
 
Der verschlüsselte swap ist kein Problem. Den kannst du beim booten mit nem zufälligen Key automatisch verschlüsseln und einhängen lassen. geli onepad ist da dein Freund.

Je nachdem welche Verzeichnisse du verchlüsseln möchtest, musst du aber aufpassen. Wenn die Daten für einen Sambaserver beim start nicht verfügbar sind, weil du das entsprechende Verzeichniss erst später entschlüsselst und einhängst ist das für Samba kein Problem. Aber ein MySQL Server z.b. wird dir einen Error werfen. Kommt halt drauf an was du alles haben möchtest, das lässt sich so pauschal nicht sagen.
Die Idee von Rosendoktor ist natürlich auch denkbar, also 2 BSD Systeme, du bootest ins erste, loggst dich per ssh ein, entschlüsselst das zweite und bootest in dieses rein. Kommt halt auch immer etwas auf dein "Bedrohungsszenario" an ;)
 
Oder man nimmt Hardware mit irgendeiner Form von IPMI. Dann kann man die KVM-Konsole oder die SOL-Konsole zum Entsperren nutzen.
 
Hallo datasmurf,
hatte ich mir auch überlegt, es aber dann wieder verworfen.

Ich werde es jetzt, wie von Rosendoktor vorschlagen, mit rerooting versuchen.

Ich habe noch eine Frage, in einem Tutorial wurde aesni als Kernel-Modul geladen und zur Verschlüsselung eingesetzt.
Laut dem nachfolgenden Thread soll dies aber nicht die optimalste Lösung sein:
https://www.bsdforen.de/threads/freebsd-11-zfs-geli-usb.33080/

Welche Verschlüsselung würde ihr mir denn für Geli empfehlen?
 
Ich habe noch eine Frage, in einem Tutorial wurde aesni als Kernel-Modul geladen und zur Verschlüsselung eingesetzt.

Falls Missverständnis: AES-NI nutzt die HW-Beschleunigung der CPU unterstützend für geli.
Welchen Verschlüsselung/Algo/Stärke du dann mit geli fährst, ist unabhängig von AES-NI. Das Gerödel geht auch in software, mit machts aber mehr Spaß. :)
Es eignen sich gut: AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS

FreeBSD nimmt aktuell bei geli standardmäßig AES-XTS-256. Meinem naiven Bauchgefühl nach ist das sicher genug, sodass niemand sich lange genug die Zähne an meinen Urlaubsfotos ausbeißt. :)
 
Und warum sollte AES-NI nicht zu trauen sein, wie in dem anderem Thread angedeutet? AES ist ein deterministischer Algorithmus, AES ist immer AES. Da kann man keine Backdoor einbauen. Wenn man einen Block Klartextdaten in AESNI reinwirft, bekommt man AES verschlüsselte Daten raus und nichts anderes.

Viel kritischer ist RDRAND, da es schwer bis unmöglich ist, die Qualität von Zufallszahlen sicher zu bestimmen. Aber kein modernes Betriebssystem (wobei ich nicht weiß, was Windows dort treibt) nutzt RDRAND als einzige Entropiequelle. Das ist spätestens seit den nie bestätigten oder widerlegten Gerüchten, dass die NSA Intels RDRAND-Implementierung weniger zufällig gemacht hat, vorbei. Oder den diversen Bugs, die vor allem AMD in diversen Prozessorgenerationen bis hin zu Zen2 vor Firmwareupdate damit hatte.

Ich würde mir um Verschlüsselungsalgorithmen keine Sorgen machen. Gegen Diebstahl der Hardware und so weiter sind alle von GELI unterstützten und auch alle sonst gebräuchlichen Algorithmen sicher genug. Und alle anderen Szenarien sind ganz schnell im Bereich von https://xkcd.com/538/ Oder anders gesagt, der Algorithmus ist de facto niemals das Problem, sondern das Keymanagement.
 
Danke für euren Input.
Habe mich heute Abend an die Installation der verschlüsselten Geli Devices gemacht und war erfolgreich :)

Es hängt jedoch noch an dem ZFS System. Ich weiß nicht, welchen Mountpoint ich dem /ROOT Dataset geben soll. Ich habe / probiert, aber dann ist mir das komplette System um die Ohren geflogen, weil das Root Dateisystem ja überschrieben wurde.

Hier mal mein zfs list:
zfsstorage 1.42G 9.93T 88K legacy
zfsstorage/ROOT 176K 9.93T 88K none
zfsstorage/ROOT/default 88K 9.93T 88K /mnt/new
zfsstorage/tmp 88K 9.93T 88K /mnt/new/tmp
zfsstorage/usr 1.42G 9.93T 88K /mnt/new/usr
zfsstorage/usr/home 88K 9.93T 88K /mnt/new/usr/home
zfsstorage/usr/ports 741M 9.93T 741M /mnt/new/usr/ports
zfsstorage/usr/src 712M 9.93T 712M /mnt/new/usr/src
zfsstorage/var 528K 9.93T 88K /mnt/new/var
zfsstorage/var/audit 88K 9.93T 88K /mnt/new/var/audit
zfsstorage/var/crash 88K 9.93T 88K /mnt/new/var/crash
zfsstorage/var/log 88K 9.93T 88K /mnt/new/var/log
zfsstorage/var/mail 88K 9.93T 88K /mnt/new/var/mail
zfsstorage/var/tmp 88K 9.93T 88K /mnt/new/var/tmp
 
Falls ich jetzt kein Detail übersehen habe, kannst du es dir viel einfacher machen, indem du im Installer die Verschlüsselung zusammendrückst. (sofern deine HW irgendeine Art remote-console zwecks PW-Abfrage anbietet)

Oder soll nur der mirror verschlüsselt werden und es ist ok, das System unverschlüsselt zu lassen, damit es alleine booten kann?
 
Ich hab's so:
Code:
root@polaris:~ zfs get mountpoint
NAME                    PROPERTY    VALUE       SOURCE
polaris_zroot           mountpoint  none        local
polaris_zroot/root      mountpoint  legacy      local
polaris_zroot_pre       mountpoint  none        local
polaris_zroot_pre/root  mountpoint  legacy      local

Also none oder legacy. Allerdings hab' ich alles händisch installiert und das ganze System einfach in einem einzigen Dataset.
 
Zurück
Oben