gocryptfs: Verschlüsselung von Dateien auf einem Samba/CIFS-Share (am Beispiel Nextcloud/externer Speicher)

gocryptfs Logo

Bei der Nutzung von (externen) Cloud-Speicherdiensten spielt Verschlüsselung eine essentielle Rolle: Im Normalfall möchte man sensible Daten nicht unverschlüsselt bei solchen Diensten ablegen, da der Anbieter hier (zumindest theoretisch) die Möglichkeit hätte, auf diese Daten zuzugreifen. Zur Verschlüsselung gibt es unter Linux verschiedenste Programme, wobei ecryptfs lange Zeit der de-facto Standard war. Jedoch muss man diese Software mittlerweile als veraltet ansehen, da diese anscheinend (trotz Bugs, die die Sicherheit betreffen) nicht mehr weiterentwickelt wird (siehe hier).

Eine modernere Alternative zum Verschlüsseln von Dateien ist gocryptfs, welches ich euch heute mal vorstellen möchte.

Ausgangssituation war dabei folgende: Von einem (Root-)Server (mit vollverschlüsselter Festplatte) läuft eine Nextcloud-Instanz. Der Speicherplatz der Cloud soll nun mit der App External Storage Support erweitert werden. Das Ziel soll dabei eine Hetzner StorageBox sein. Diese soll als Samba/CIFS-Share auf dem Server mittels /etc/fstab eingebunden werden, jedoch sollen alle auf der StorageBox gespeicherten Datei transparent durch gocryptfs verschlüsselt werden. Direkt nach dem Booten soll das verschlüsselte Verzeichnis auf dem Samba-Share automatisch, d.h. ohne manuellen Eingriff, auf dem Nextcloud-System zur Verfügung stehen.

Dieses Vorhaben lässt sich relativ einfach mit gocryptfs umsetzen, ist aber auch auf andere Anwendungen oder Dienste übertragbar. Das Ziel der Verschlüsselung muss dabei nicht unbedingt eine StorageBox sein, vielmehr kann dies ein beliebiger Speicher sein, der mittels fstab auf dem Nextcloud-System eingebunden werden kann.

Voraussetzungen

Generell sind hier zwei getrennte Systeme (z.B. bei unterschiedlichen Anbietern) notwendig. Das eine ist die Quelle (der Root-Server), hier ist das Passwort für die Ver-/Entschlüsselung bekannt. Auf dem Ziel-System landen dann nur die verschlüsselten Daten. Auf diesem System ist das Passwort, welches zum Entschlüsseln der Daten benötigt wird, nicht bekannt. Selbst wenn das Ziel-System kompromittiert werden sollte, sieht ein Angreifer hier nur „Datenmatsch“, mit dem nichts anzufangen ist.

Exemplarisch nutze ich hier einen Root-Server, auf dem Nextcloud bereits installiert ist und der unter Ubuntu 22.04 LTS läuft. Das Vorgehen sollte aber auch auf anderen Distributionen umsetzbar sein.
Das Ziel der Verschlüsselung ist eine StorageBox bei Hetzner.

Installation und Funktion von gocryptfs

gocryptfs ist als FUSE Dateisystem implementiert und nutzt prinzipiell zwei Ordner: einen verschlüsselten Ordner („cipher“) und einen unverschlüsselten Ordner („plain“). Den verschlüsselten Ordner „mountet“ man dann mittels gocryptfs in den unverschlüsselten Ordner und arbeitet dann ausschließlich mit diesem. gocryptfs verschlüsselt dann vollkommen transparent sämtliche Inhalte im verschlüsselten Ordner.

Wir wollen dies nun erst einmal mit einem vereinfachten Beispiel durchspielen, bei dem beide Ordner („cipher“ und „plain“) auf dem lokalen System liegen.

Vor der Nutzung des Programms muss dieses erst einmal installiert werden:

apt update && apt install gocryptfs

Für diese einfache Demonstration erstellen wir uns erst einmal die beiden Verzeichnisse:

mkdir test_encrypted
mkdir test

Nun wird das verschlüsselte Verzeichnis initialisiert:

gocryptfs -init test_encrypted

Hier wird man nun zweimal zur Eingabe eines Passworts aufgefordert. Das Passwort sollte dabei natürlich ausreichend komplex sein.
Anschließend wird der sog. Master Key angezeigt. Diesen sollte man sich umgehend notieren, z.B. in einem Passwort-Safe. Im verschlüsselten Verzeichnis (test_encrypted) findet man nun eine Datei gocryptfs.conf, in der Parameter der Verschlüsselung gespeichert sind. Sollte diese Datei einmal gelöscht werden, kann man nur noch mit dem Master Key Zugriff auf die unverschlüsselten Daten erhalten.

Im nächsten Schritt kann man nun das verschlüsselte Verzeichnis in das unverschlüsselte Verzeichnis „mounten“:

gocryptfs test_encrypted test

Nun arbeitet man einfach mit dem unverschlüsselten Verzeichnis und erstellt hier z.B. eine Datei:

echo "Das ist ein Test" > test/test.txt

Wenn man nun das verschlüsselte Verzeichnis betrachtet, ist hier nun eine neue Datei mit kryptischem Namen entstanden: gocryptfs verschlüsselt nämlich nicht nur die Dateiinhalte, sondern auch die Datei-/Verzeichnisnamen:

Verschlüsselung mit gocryptfs
Verschlüsselung mit gocryptfs

Am Ende kann dann das verschlüsselte Verzeichnis wieder ungemountet werden. Wichtig ist hierbei, dass als Argument das unverschlüsselte Verzeichnis angegeben wird:

fusermount -u test

gocryptfs in der Praxis (am Beispiel Nextcloud in Verbindung mit einer StorageBox)

Wie kann man sich die Verschlüsselung durch gocryptfs nun in der Praxis vorstellen?
Ich nehme hier mal als Beispiel Nextcloud: Wenn man sich einen kleinen Root- oder vServer bei einem Anbieter – z.B. Netcup (Affiliate-Link) – besorgt und darauf Nextcloud installiert hat, ist meistens der zur Verfügung stehende Speicherplatz der Knackpunkt. Kleinere Server haben meistens nur (sehr) wenig Speicherplatz, der bei einer gut genutzten Cloud schnell zuneige gehen wird. Hier kann der zur Verfügung stehende Speicherplatz nun durch externen Speicher erweitert werden. Dieser externe Speicher soll nun:

Warum nutze ich hier nicht die Server-seitige Verschlüsselung von Nextcloud?
Die Server-seitige Verschlüsselung von Nextcloud nützt nur etwas, wenn die Systeme (Nextcloud und externer Speicher) getrennt sind (der Key zur Entschlüsselung wird auf dem Nextcloud-Server gespeichert). Dies ist in unserer Konstellation der Fall, dennoch hat die Server-seitige Verschlüsselung einen entscheidenden Nachteil: Viele Apps funktionieren nicht, wenn die Server-seitige Verschlüsselung aktiv ist (selbst, wenn nur der externe – nicht aber der interne Speicher verschlüsselt wird). Daher lohnt die Sever-seitige Verschlüsselung nur in den seltensten Fällen.

Hier kann gocryptfs eine gute Lösung sein, da ein entschlüsselter gocryptfs-Mount aus Sicht des Betriebssystems (und damit auch aus Sicht der Nextcloud) einfach nur ein lokales Verzeichnis ist.

Im Folgenden möchte ich dies mal an einem konkreten Beispiel zeigen. Eine installierte Nextcloud-Instanz soll hier mit einem externen Speicher erweitert werden. Dieser Speicher wird über eine StorageBox von Hetzner per Samba bereitgestellt. Jedoch sollen alle Inhalt, die auf der StorageBox landen, auf dem Nextcloud-Server per gocryptfs verschlüsselt werden.

Hinweis: Auch wenn ich hier eine StorageBox verwende, funktioniert das Ganze auch mit einem „normalen“ Samba-Share, welches irgendwo im Netzwerk (z.B. auf einem NAS) zur Verfügung steht. Hier muss es gar nicht mal zwingend ein Samba-Share sein, es reicht ein beliebiger Speicher, der per /etc/fstab auf dem Nextcloud-Server gemountet werden kann. Das Beispiel mit der StorageBox habe ich nur gewählt, da dies momentan ein unschlagbares Angebot (Preis-/Leistung) für allgemein nutzbaren Speicher „in der Cloud“ ist.

StorageBox vorbereiten

Zunächst starten wir mit der Vorbereitung der StorageBox. Diese unterstützt sog. Sub-Accounts. Mit diesen kann man einfach einzelne Anwendungsfälle trennen, so dass es sich empfiehlt, einen extra Sub-Account für unsere Erweiterung des Nextcloud-Speichers anzulegen.

Hierzu legen wir zunächst einmal einen Ordner im Haupt-Verzeichnis der StorageBox an. Dazu kann ein beliebiger SFTP/SCP-Client verwendet werden. Ich nutze hierfür gerne Cyberduck, dies geht aber genauso gut mit anderen Programmen, z.B. WinSCP oder FileZilla. Wie man sich mit einem solchen Client an der StorageBox anmelden kann, ist in der Hilfe von Hetzner gut beschrieben.
Hier legt man nun z.B. einen Order nextcloud_ext_crypt an.

Als nächstes loggen wir uns in die Verwaltungsoberfläche der StorageBox (Robot) ein. Nach dem Auswählen der entsprechenden StorageBox kann man nun im Tab Sub-Account einen neuen Sub-Account anlegen (Button Anlegen). Hier wählen wir oben den soeben angelegten Ordner. Unter den Optionen wählt man Samba erlauben und externe Erreichbarkeit, damit der Zugriff später auch klappt.

StorageBox Sub-Account mit Samba-Zugriff
StorageBox Sub-Account mit Samba-Zugriff

Nach dem Klick auf Speichern werden einmalig die Zugangsdaten angezeigt, die man sich sofort notieren sollte (z.B. in einem Passwort-Safe).

Abhängigkeiten installieren

Der Sub-Account der StorageBox wurde nun angelegt und wir können uns per SSH auf den Nextcloud-Server verbinden. Hier holen wir uns erst einmal per sudo Admin-Rechte:

sudo -s

Als nächstes können wir die benötigten Programme installieren:

apt update && apt install cifs-utils gocryptfs

StorageBox per fstab mounten

Nun wird (der Sub-Account) der StorageBox per /etc/fstab beim Systemstart gemountet.

Dazu legen wir uns erst einmal eine Datei an, in der die Zugangsdaten gespeichert werden:

nano /root/.smbcredentials

Die hier einzutragenden Daten wurden beim Anlegen des Sub-Accounts der StorageBox angezeigt. Der Benutzername ist hier immer „u<Nummer>-sub<Nummer>“, in diesem Beispiel vereinfacht uxxxxxx-sub1:

username=uxxxxxx-sub1
password=PaSsW0rD

Als nächstes passen wir die Rechte der Datei an, damit nicht jeder Zugriff auf diese sensiblen Daten hat:

chmod +600 /root/.smbcredentials

Nun wird noch ein Verzeichnis erstellt, in das die StorageBox gemountet werden soll:

mkdir -p /mnt/nextcloud_ext_crypt

Es folgt das Editieren der fstab:

nano /etc/fstab

Ganz am Ende fügen wir hier folgende Zeile hinzu.

Wichtig:

  • Hier muss wieder der richtige Benutzername als Teil des UNC-Pfades angegeben werden (uxxxxxx-sub1).
  • Mit uid und gid muss hier der Webserver-Benutzer als „Besitzer“ des Mounts angegeben werden. Ebenso müssen file_mode und dir_mode entsprechend gesetzt werden, damit die Nextcloud (respektive der Webserver-User) später in dieses Verzeichnis schreiben kann. Dieser Schritt ist essentiell, ohne diesen wird die Nextcloud später nicht in das Verzeichnis schreiben können.
//uxxxxxx-sub1.your-storagebox.de/uxxxxxx-sub1 /mnt/nextcloud_ext_crypt cifs credentials=/root/.smbcredentials,iocharset=utf8,rw,_netdev,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770  0 0

Gemountet werden kann der Samba-Share nun ohne Neustart des Servers durch folgenden Befehl:

mount -a -vvv

Hier sollte dann am Ende folgendes angezeigt werden:

/mnt/nextcloud_ext_crypt : successfully mounted

Falls hier eine Fehlermeldung angezeigt werden sollte, muss man diesem Fehler erst einmal nachgehen, denn die folgenden Schritte hängen davon ab, ob die StorageBox erfolgreich gemountet werden konnte.

Wichtig: In das Verzeichnis /mnt/nextcloud_ext_crypt sollten niemals manuell Dateien oder Verzeichnisse angelegt werden. Dieser Mount speichert einzig und allein die von gocryptfs verschlüsselten Inhalte.

gocryptfs initialisieren

Wir können nun auf dem soeben gemounteten Share die Verschlüsselung mit gocryptfs initialisieren:

gocryptfs -init /mnt/nextcloud_ext_crypt

Hier folgt die Anfrage eines Passworts, welches man sich wieder unbedingt gleich notieren sollte.

gocryptfs: Entschlüsseltes Verzeichnis mittels fstab mounten

Damit das verschlüsselte Verzeichnis automatisch bei Systemstart entschlüsselt werden kann, nutzen wir wieder fstab.

Hier legen wir uns zunächst ein Verzeichnis an, in dem gocryptfs die unverschlüsselten Inhalte bereitstellen soll:

mkdir -p /mnt/nextcloud_ext

Ähnlich wie schon beim Mounten des Samba-Shares legen wir uns eine Datei an, die das Passwort für gocryptfs beinhaltet:

nano /root/.gocryptfs

Hier wird einfach das reine Passwort von gocryptfs eingetragen.

Die Rechte sollten hier wieder sicherheitshalber angepasst werden:

chmod +600 /root/.gocryptfs

Nun folgt noch die Erweiterung und der fstab:

nano /etc/fstab

Am Ende wird folgende Zeile eingefügt:

/mnt/nextcloud_ext_crypt /mnt/nextcloud_ext	fuse./usr/bin/gocryptfs rw,nofail,auto,x-systemd.idle-timeout=10,x-systemd.automount,allow_other,quiet,passfile=/root/.gocryptfs 0 0

Wieder mounten wir das Verzeichnis ohne Reboot des Servers:

mount -a -vvv

Hier sollte dann folgende Meldung erscheinen:

/mnt/nextcloud_ext       : successfully mounted

Damit ist das Mounten des gocryptfs-Verzeichnisses auch schon abgeschlossen.

Falls dieses Verzeichnis übrigens mal manuell ungemountet werden muss, kann dies mit folgendem Befehl erledigt werden:

fusermount -u /mnt/nextcloud_ext

Verschlüsseltes Verzeichnis in der Nextcloud als externen Speicher hinzufügen

Weiter geht es nun in der Weboberfläche von Nextcloud. Falls noch nicht geschehen, ist im App Store die App „External Storage Support“ herunter zu laden.

Wir wechseln anschließend in die Admin-Einstellungen der Cloud unter Externer Speicher. Hier kann nun das unverschlüsselte Verzeichnis (in unserem Beispiel /mnt/nextcloud_ext) einfach als lokaler Storage angegeben werden:

Lokales (entschlüsseltes) Verzeichnis in der Nextcloud als externen Speicher hinzufügen
Lokales (entschlüsseltes) Verzeichnis in der Nextcloud als externen Speicher hinzufügen

Nun sollte dieses externe Verzeichnis bei den entsprechenden Benutzern in der Files-App von Nextcloud auftauchen. Zum Testen, ob alles funktioniert kann man hier nun mal Ordner oder Dateien anlegen/hochladen.

Hinweis: Falls es in der Nextcloud beim Anlegen/Hochladen von Ordnern oder Dateien zu Fehlermeldungen kommt, wurde vermutlich der Samba-Share nicht mit dem korrekten User (uid/gid) gemountet. In diesem Fall bitte nochmals den entsprechenden Eintrag in der /etc/fstab kontrollieren.

Wenn man nun nochmal auf das verschlüsselte Verzeichnis (/mnt/nextcloud_ext_crypt) schaut (entweder direkt über die Konsole oder auch per SFTP-/SCP-Client), sieht man, dass hier nur noch verschlüsselte Inhalte zu finden sind:

Verschlüsselte Inhalte im Sub-Account der StorageBox
Verschlüsselte Inhalte im Sub-Account der StorageBox

Am Ende sollte man noch einen Reboot des Nextcloud-Servers durchführen und kontrollieren, ob der externe Speicher weiterhin in der Nextcloud verfügbar ist, d.h. ob das automatische Mounten und Entschlüsseln beim Systemstart funktioniert hat.

Fazit

Im Artikel wurde das Verschlüsselungs-Tool gocryptfs mit deinen Grundfunktionen vorgestellt. Ein sinnvoller Verwendungszweck ist wie hier gezeigt die Erweiterung einer Nextcloud mit einem verschlüsselten externen Verzeichnis, ohne dass man die Server-seitige Verschlüsselung von Nextcloud nutzen muss. Auf diese Weise kann ein beliebiger Cloud-Speicher eingesetzt werden (dieser muss nur im Linux-System gemountet werden können), auf diesem landen dann aber ausschließlich verschlüsselte Inhalte.

Das hier gezeigte Vorgehen kann aber auch auf andere Programme übertragen werden. Der große Vorteil ist hier, dass gocryptfs die Verschlüsselung gegenüber dem Betriebssystem und den Programmen vollkommen transparent abbildet. Aus Sicht eines Programms/Webserver, o.ä. stellt sich ein gemounteter gocryptfs-Ordner einfach wie ein lokaler Ordner dar.

Auch wenn das im Artikel gezeigt Szenario mit dem Erweitern einer Nextcloud um ein externes (verschlüsseltes) Verzeichnis etwas speziell ist, kann gocryptfs auch sehr gut eingesetzt werden, um beliebige Daten auf einem einem Speicher der Wahl (z.B. auch einem USB-Stick oder eine externen Festplatte) zu verschlüsseln.

Weiterführende Artikel

Links

12 Kommentare zu „gocryptfs: Verschlüsselung von Dateien auf einem Samba/CIFS-Share (am Beispiel Nextcloud/externer Speicher)“

  1. Hallo Jan,

    Super Artikel.

    Wie schaut es mit der Umsetzung des externen Speichers über die config.php, Eintrag datadirectory, aus?
    Anstatt der Anbindung über die NC App.

    (rsync -av /var/nextcloud_data/ /mnt/ex_nc_data)

    Somit würden alle hochgeladenen Daten auf der verschlüsselten StorageBox liegen.

    Gruß Hans

    1. Hi Hans,

      du meinst sicher, den externen Speicher als Haupt-Speicher nutzen, die schon mal hier beschrieben. Das sollte auch in der hier gezeigten Konstellation funktionieren, das Verzeichnis über gocryptfs sollte dann nur vor dem NC-Setup bereits vorbereitet sein.
      Bei einem Umzug des Datenverzeichnisses (offiziell nicht von NC unterstützt), sollte man auf jeden Fall noch einen kompletten File-Scan über OCC vornehmen.

      Gruß,
      Jan

  2. Hallo Jan, toller Bericht.
    Gibt es hier eine Dateigrößenbeschränkung? Ein Upload einer 5GB-Datei in die Cloud mit Standard-Verzeichnis funktioniert – die gleiche Datei in ein verschlüsseltes Verzeichnis bricht immer ab. Sieht so aus wie 4GB Grenze?
    Grüße, Carsten

    1. Hi Carsten,

      ich habe das mal rein, lokale mit einer ~6GB Datei getestet, als nur mittels eines lokalen gocrypotfs-Verzeichnisses, da hat das wunderbar funktioniert. Hier kommt diese Einschränkung also nicht her.
      Erstaunlich bei der Kombination mit NC/gocryptfs: Der Upload (hier ein lokal) ist recht schnell erledigt. Erst wenn NC meint, die Datei sei hochgeladen, beginnt der Transfer auf die StorageBox.
      Ich vermute hier eher seitens der StorageBox einen Timeout o.ä., konnte hierzu aber keine Infos finden. Das ganze „live“ zu testen wird auf Grund des atemberaubenden Breitbandausbaus leider einige Zeit in Anspruch nehmen. ;-)

      Gruß,
      Jan

      1. Hi Carsten,

        ich habe hier noch ein paar Tests gemacht: Also ich bekomme hier immer eine Fehlermeldung der Art „… is locked, existing lock on file: exclusive“.
        Auch wenn diese Fehlermeldung etwas verwirrend ist: Der Upload an sich klappt aber einwandfrei. Hatte dies aber nur mit einer lokalen Instanz und einem lokalen Samba-Share getestet, nicht wirklich auf einer StorageBox.

        Gruß,
        Jan

    1. Hi Frank,

      puh, Kubernetes ist ein sehr weites Feld, das sehe ich auf absehbare Zeit leider nicht im Blog.
      Ich habe noch etliche Themen in der Pipeline, komme aber leider kaum zum Schreiben…

      Gruß,
      Jan

  3. Hallo Jan
    nur zur Info.

    Logwatch gibt hier folgenden Fehler aus.
    ——————— Kernel Begin ————————
    WARNING: Kernel Errors Present
    CIFS: VFS: \\uxxxx-sub1.your-storagebox.de Send error in SessSetup = – …: 6 Time(s)
    1 Time(s): CIFS: reconnect tcon failed rc = -11

    Das LW wird jedoch angelegt und funktioniert alles.

    Gruß Hans

      1. Hallo Jan,
        dmesg log, ja genau. Beim Verbinden „rohen“ Verbindung zur StorageBox.

        Zudem diese Meldung.

        kernel: CIFS: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3.1.1 (or even SMB3 or SMB2.1)

        Gruß Hans

        1. Hi Hans,

          ok, alles klar.
          Die Verbindung funktioniert ja aber trotzdem. Letztere Meldung ist ja nur der Hinweis, dass er eine höhere SMB-Version verwendet, da keine Version explizit mitgegeben wurde.

          Gruß,
          Jan

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert