System mit ZFS ueber serielle Konsole entschluesseln

midnight

OpenBSD & FreeBSD
Hallo,

ich setze mich momentan ernsthaft mit FreeBSD auseinander. Unter OpenBSD habe ich mir angewoehnt, alle meine Systeme voll zu verschluesseln. Das geht unter FreeBSD und ZFS auch erstaunlich gut.

Nun versuche ich FreeBSD auf einer Router-Hardware zu installieren. Diese ist allerdings nur per serieller Konsole zu installieren. Das hat "unverschluesselt" auch problemlos funktioniert.

Nun zu meiner eigentlichen Frage: Wie bringe ich FreeBSD dazu, die Passworteingabe zur ZFS-Entschluesselung ueber die serielle Konsole auszugeben? Die loader.conf oder die rc.conf werden ja erst nach der Entschluesselung geladen. Muss ich ZFS patchen oder gibt es einen anderen Trick?
 
Keine Garantie, aber es könnte dich mit den genannten Stellschrauben weiterbringen:


Edit: Kommst du denn weiter, wenn du mal blind das PW tippen versuchst + ein paar Sekündchen Geduld?
 
Falls relevant für PW-Buchstaben: Eingaben werden da noch als US-Keyboard angenommen.

Konsole per BMC holen fiele mir noch ein, wird das Gerät aber wahrscheinlich nicht haben?
 
Ich habe heute den ganzen Tag vergeblich damit verbracht und lass das Thema nun vorerst ruhen. Ich habe eine Testumgebung unter QEMU eingerichtet, da man hier mit Alt+3 schoen in eine virtuelle, serielle Konsole wechseln kann. Scheinbar funktioniert das nicht mit verschluesseltem ZFS, UEFI und serieller Konsole.
 
Sollte es nicht funktionieren, wenn du den "alten" Weg der Vollverschlüsselung gehst? Also unverschlüsseltes /boot.

Je nach individuellem Anwendungsfall sowie Gewichtung zwischen Bequemlichkeit und Sicherheit ist auch die Variante /boot plus keyfile (nur nur keyfile) auf einem unverschlüsselten externen USB-Stick sehr brauchbar.

Vorteile:
  • Keine Passworteingabe notwendig.
  • Geht die interne HDD/SSD kaputt, kann man sie bedenkenlos entsorgen.
  • Geht der USB-Stick kaputt, ist Ersatzhardware sofort ohne Gehäuseöffnung parat. Der Schlüssel für die SSD/HDD ist schnell gewechselt, so dass man den USB-Stick anschließend problemlos entsorgen kann.
Nachteile:
  • Schützt nicht vor allen Angriffsszenarien (Diebstahl, Beschlagnahmung, Manipulation in Abwesenheit)
  • Zusätzliche Hardware in Form des USB-Sticks notwendig
Varianten ohne USB-Stick mit TPM oder Yubikey o.ä. sind natürlich auch möglich.
 
Und gegen Diebstahl und Beschlagnahmung hilft es genau so, auf /boot sind keine schützenswerten Daten, dass du BSD verwendest erkennt man bereits am Bootloader.
Gegen Manipulation in Abwesenheit schützt es schlechter als mit verschlüsseltem /boot, aber auch das hilft da nicht zu 100%. Wenn Manipulation an Anwesenheit möglich ist, ist ein Keylogger sowieso die einfachste Möglichkeit, manipulierte USB Buchsen, .. - dagegen kannst dich als Privatperson fast nicht schützen.
 
Sollte es nicht funktionieren, wenn du den "alten" Weg der Vollverschlüsselung gehst? Also unverschlüsseltes /boot.
Ja, das wird vermutlich gehen. Ich muss mich mal schlau machen, wie das genau funktioniert mit UEFI, /boot und nativer ZFS-Verschluesselung.

Je nach individuellem Anwendungsfall sowie Gewichtung zwischen Bequemlichkeit und Sicherheit ist auch die Variante /boot plus keyfile (nur nur keyfile) auf einem unverschlüsselten externen USB-Stick sehr brauchbar.
Ein guter Tipp fuer mein Router-Szenario. Danke.

Auf meinem Webserver mit serieller Konsole wird hier wohl wirklich nur der Umweg ueber /boot funktionieren. Warum ich dort verschluesseln moechte: Dort soll mein Syncthing-Discovery-Server laufen und den haette ich gerne irgendwie verschluesselt. Meine alternative Idee dazu waere, ein verschluesseltes ZFS-Dataset zu erstellen, dort eine Jail mit Syncthing installieren. Ist diese Idee realistisch? Im Falle eines Festplattentauschs durch den Provider sollen dort keine persoenlichen Daten rekonstruierbar sein.
 
Im Falle eines Festplattentauschs durch den Provider sollen dort keine persoenlichen Daten rekonstruierbar sein.

im Falle echter Hardware (d.h. keine virtuelle Maschine) und Fremdhosting würde ich den Weg über TPM verfolgen, d.h. der Zugang zu deinen Daten erfolgt entweder über ein nur dir bekanntes Passwort oder über das TPM-Modul dieser Maschine.

Bei virtuellen Maschinen kommt es auf den Unterbau an, ob vTPM (z.B. hier bei Xen) unterstützt wird.

Du hättest damit encryption at rest, d.h. beim Wechsel der HDD/SDD könnte man außerhalb der Maschine (ohne dein Passwort) niemals deine Daten entschlüsseln. Zusätzlich würde die Passworteingabe beim Reboot entfallen.

Ansonsten bist du im Bereich serverseitiges Key Management System schnell im Bereich von Cloud-Providern, mit allen Vor- und Nachteilen. Dann kannst du gleich darüber nachdenken, ob du nicht eine clientseitige Verschlüsselung nimmst und beim Provider/Hoster ausschließlich bereits verschlüsselte Daten hochlädst. Das hängt aber ganz von deinen Anforderungen und deinem Vertrauen in den Provider/Hoster ab.
 
im Falle echter Hardware (d.h. keine virtuelle Maschine) und Fremdhosting würde ich den Weg über TPM verfolgen, d.h. der Zugang zu deinen Daten erfolgt entweder über ein nur dir bekanntes Passwort oder über das TPM-Modul dieser Maschine.
Sehr interessant. Das ist mal eine ganz andere Vorgehensweise und wuerde mir in diesem Fall genuegen. Ja, es ist ein Root-Server und keine virtuelle Maschine. Zum BIOS habe ich allerdings keinen Zugang und ueber die Weboberflaeche zur Servereinrichtung gibt es auch keine Option. Wie bekommt man denn sonst seinen Key ins TPM und wie weist man FreeBSD an, genau diesen Key fuer die ZFS-Entschluesselung zu nutzen? Da habe ich auf die Schnelle nichts brauchbares finden koennen.
 
Im Prinzip sollte es ja auch so gehen, oder?

Verschluesseltes ZFS-Dataset anlegen:
Code:
# zfs create -o encryption=on -o keyformat=passphrase -o mountpoint=/jails zroot/jails

Nach einem Server-Reboot dann von Hand entsperren und einbinden:
Code:
# zfs load-key zroot/jails
# mount zroot/jails
# service jail onestart

Oder spricht hier etwas dagegen? Es geht mir in diesem Fall nur darum, die Syncthing-Jail zu verschluesseln, da hier private Dinge liegen. Im Falle eines Festplattentauschs sollen diese Daten nicht mehr lesbar sein.
 
Zuletzt bearbeitet:
Zum BIOS habe ich allerdings keinen Zugang und ueber die Weboberflaeche zur Servereinrichtung gibt es auch keine Option. Wie bekommt man denn sonst seinen Key ins TPM und wie weist man FreeBSD an, genau diesen Key fuer die ZFS-Entschluesselung zu nutzen? Da habe ich auf die Schnelle nichts brauchbares finden koennen.

Ich muss gestehen, ich habe auch keine einzige Erfolgsmeldung mit TPM unter FreeBSD gefunden. :eek:

Nachdem TPM schon seit vielen Jahren im Servermarkt etabliert ist, bin ich eigentlich davon ausgegangen, das müsste auch unter FreeBSD problemlos gehen und gut dokumentiert sein. :o
 
Zurück
Oben