Beste Verschlüsselungsmethode auf einem remote Server

[satriani]

Hallo,
da ich keinen Dinosaurier ausgraben wollte, habe ich einfach ein neues Thema erstellt.
Es gibt Dateien die in einer FreeBSD v11.1 Jail liegen und gut verschlüsselt werden sollen. Da man ständig mit diesen Dateien hantiert, ist die Performance auch von großer Bedeutung.
Bis die native Datasetverschlüsselung fertig ist vergehen wahrscheinlich noch etliche Jahre ^^ Full encription mit geli auf einem remote Server ist auch ohne weitere nicht möglich, wegen passphrase Eingabe (obwohl es mit dropbear doch machbar sein soll, schlägt aber dafür geli auf die Performance). Also, das Ziel ist klar, schnelle und gute Verschlüsselung, damit auch die Mitarbeiter der Hostingfirma davon nix sehen können
Freue mich auf eure Vorschläge

Gruß.

 

[Athaba]

Wegen Performance: Ich gehe davon aus, dass der Server AESNI unterstützt. Das heißt wenn du das Kernel-Modul lädst wirst du den Unterschied wohl kaum mitbekommen.

Um ehrlich zu sein, bin ich mir nicht sicher ob du realistische Sicherheitsvorteile hast, wenn das nicht gerade dein eigener Server ist und ihn nur in ein Datencenter stellst.

Bei der Dropbear-Sache und ähnlichem ist das mit dem "near" ein wenig happig.

Je nachdem was du mit dem Server vorhast wäre es vielleicht eine andere Herangehensweise sich auf die Daten zu konzentrieren, eingehen. Also sagen wir mal es handelt sich um einen Mailserver, dann könntest du dafür sagen, dass die automatisch verschlüsselt werden, an deinen Key, den du auf deinem Desktop hast. Selbiges könntest du auch für Fileserver und andere Dinge verwenden, wenn du am Server die Daten nur verstaust aber dieser sie nicht (unverschlüsselt) nutzen muss.

Ich kenne einige Leute, die dann mit VNC reingehen und beim Booten das Passwort eintippen. Aber da geht's dann darum was für eine Art von Angriff du dir vorstellst. Dein Provider kann ja dann potentiell das VNC mit einem Keylogger versehen.

Das ist zwar jetzt nicht mehr ganz deine Frage, aber bei solchen Vorhaben ist die sinnvollste Lösung wohl Zugriff auf den Server. Also eigenes Datencenter, Datencenter in der Nähe oder Heimserver, sonst stehst du immer vor zwei großen Punkten, nämlich die Passphrase/Key-Eingabe und der Zugriff darauf bzw. wie sehr du dem System vertrauen kannst, das unverschlüsselt bzw. potentiell modifiziert oder keyloggt ist.

 

[Yamagi]

Du willst pefs: http://pefs.io/

 

[satriani]

Danke euch.
@Athaba Ja, das AES-NI wird von der CPU unterstütz. Aber warum ist die Dropbear-Sache happig? Hat hier jemand das mit dem Dropbear oder ähnlichem hinbekommen? Ich habe es noch nicht ausprobiert, würde mich aber über Erfahrungen sehr freuen.

@Yamagi: pefs kenne ich zwar und finde es ganz gut, aber ich habe irgendwo gelesen, dass es teilweise sehr lahm sein kann. Das habe ich zwar vor paar Jahren irgendwo gelesen, weiß nicht ob es nun besser geworden ist, lasse mich aber gerne eines besseren belehren
Die Verschlüsselung mit geli ist in dem Fall wahrscheinlich schneller.

 

[Rakor]

geli ist auf dem Remoteserver nur bei einer Fulldiskenc schwierig. Wenn du ne Datenpartition einhängst (dann halt von Hand) dann ist das kein Thema da ein geli drunter zu packen.

 

[Athaba]

Aber warum ist die Dropbear-Sache happig?

Es kommt darauf an, wovor du dich schützen willst.

Full Disk Encryption verkauft zum großen Teil den Vorteil, dass du die Angriffsfläche sehr, sehr klein machst, also ein Angreifer es auch schwer hat dir noch vor der Entschlüsselung des ganzen System eine Malware (oder schlechte Konfiguration, etc.) unterzujubeln. Bei Dropbear ist so wie ich das sehe die Angriffsfläche doch wieder ein ganzes System. Das ist natürlich viel besser, als ohne, aber wenn dein Bedenken der Zugriff durch die Hostingfirma ist, dann musst du bedenken, dass die die kleine unverschlüsselte UFS-Partitition als vermutlich schwächstes Glied der Kette angreifen würden.

Insofern ist das Ergebnis näher an einer "normalen" Verschlüsselung einer Partitionen mit deinen Daten oder wie pefs, etc.

Wie gesagt, kommt auf den Anwendungsfall und den Angreifer vor dem du dich währen willst an, was sinnvoll ist. Es ist immer gut, wenn man sich ein möglichst konkretes Szenario überlegt, vor dem man sich schützen will bzw. auch wovor man sich nicht unbedingt schützen will/muss oder bei was für Angriffen man dann doch kapituliert (sprich Threat Modeling macht), damit man sich auch den Limits bewusst ist. Dann kann sich daraus auch das beste Tool bzw. die beste Vorgangsweise ergeben.

 

[Crest]

Eine Alternative ist seit FreeBSD 10.3 auch das Rerooting. Dabei bootet man ein kleines unverschüsseltes System ganz normal. Anschließend meldet man sich dort an z.B. per SSH und entsperrt die GELI Provider. Jetzt kann man dem Kernel sagen woher ab dem nächsten mal sein Rootdateisystem mounten soll und reboot -r ausführen. Anstatt komplett zu rebooten wird das System jetzt alle Prozesse stoppen (ja auch init), alle Dateisysteme unmounten und anschließend das neue Rootdateisystem mounten und von auch ein neues init starten das dann wieder bootet. Der Kernelzustand z.B. GELI Provider und Netzwerk bleiben dabei erhalten. Damit kannst du Full Disk Encryption mit GELI bekommen ohne eine vertrauenswürdige Systemkonsole zu haben. Leider ist das Tooling noch etwas unausgereift, aber der Kernelsupport ist vorhanden. Eine lästiger Bug ist allerdings, das man ZFS Pools erst exportieren muss, weil der Kernel sonst versucht den Pool ein zweites Mal zu importieren was ein kassert auslöst. Deswegen würde ich für das Minimalsystem UFS verwenden. Man muss natürlich beide Systeme gepatched halten.

 

[Yamagi]

Eine lästiger Bug ist allerdings, das man ZFS Pools erst exportieren muss, weil der Kernel sonst versucht den Pool ein zweites Mal zu importieren was ein kassert auslöst

Ich meine, das ist zumindest in -CURRENT inzwischedn gepatcht. Bringt einem auf einem RELEASE natürlich noch nichts, aber immerhin.

 

[Crest]

Ja der Patch war nicht groß, aber kann es auch anders umgehen. Ich hatte z.B. mal ein System aufgesetzt das in ein Plaintext ZFS bootet, ein ZVOL mit einem UFS System drin zum befüllen eines swap backed md(4) Devices verwendet und erstmal in dieses rerootet. Dieses System exportiert alle ZFS Pools und rerootet ein weiteres Mal (in den GELI verschlüsselten Pool). Das ist natürlich nicht sehr sinnvoll, aber es ist halt so beim Debugging entstanden.