Ich kenne einige Kleinstunternehmen und Freiberufler, die Kunden- oder gar Patientendaten bei einem Provider lagern wollen. Zu Backup-Zwecken oder gar für einen Remote-Zugriff. Für mich stellt sich da die Frage:

Wie weit kann und darf man seinem Provider für gehostete Server oder Cloud-Dienste eigentlich trauen?

Administratoren haben bei Internet-Providern ja nicht nur theoretisch, sondern je nach Berechtigungsstufe faktischen, d.h. administrativ-digitalen oder womöglich gar physikalischen Zugriff auf die gehosteten Systeme und angebundene Datenhaltungssysteme. Der potentielle Zugriff ist in vielen Hosting-Szenarien (Container-Technologie etc.) inhärent gegeben und für den ordnungsgemäßen Betrieb z.T. sogar notwendig; unabhängig davon, ob sich Administratoren für die gelagerten Inhalte interessieren oder nicht. Einen potentiellen Zugriff von IT-Verantwortlichen auf die Inhalte von Daten oder Datenströme auf gehosteten Systemen verhindert auch eine ISO 27001-Zertifizierung des Providers (z.B. von Strato) nicht zwingend. Gesetzliche Datenschutz- und Geheimhaltungsvorgaben – insbesondere für Patientendaten – sind in simplen Hosting-Szenarien deshalb nur schwer einzuhalten. Hinzu kommt das Risiko potentieller Schwachstellen in der Technik zur Isolation gehosteter Dienste oder virtualisierter Server gegeneinander – insbesondere bei Einsatz von Container-Technologien.

Für Daten, die im eigenen oder – oft noch wichtiger – im Kundeninteresse zwingend geheimzuhalten sind, ist daher folgende Regel angebracht: “Im Internet und in der “Cloud” gibt es keine Freunde”.

Sichere Ablage von privaten Dateien oder Kunden-Daten auf gehosteten Systemen?

Was also tun, wenn man oft unterwegs ist und eine Art sicheren, privaten Cloud-Dienst benötigt, der es einem bei Bedarf erlaubt, z.B. vom Notebook aus zumindest auf einzelne, wichtige Dateien zuzugreifen? Die aber niemand anderes einsehen soll?

Aufwand und Kosten für Betrieb und Absicherung eines eigenen, im Internet exponierten Servers sind für kleine Firmen und Freiberufler durchaus ein Thema … Dann will man einerseits gerne auf Hosting-Angebote zurückgreifen, andererseits aber auch seine Geheimhaltungspflichten nicht verletzen … Und was tun, wenn der gewünschte Datenzugriff gar für mehrere Personen (in begrenzter Anzahl) ermöglicht werden soll?

Oftmals reichen in einem Szenario mit Remote-Zugang rein lesende Zugriffe auf die zentral gelagerten Daten aus. Zu ändernde Inhalte synchronisiert man ggf. rollierend in einem speziellen organisatorischen Prozess über einen definierten administrativen User.

Ein anderes, einfacheres Szenario ist die sichere Lagerung von verschlüsselten Daten als Backup bei einem Cloud-Dienst. Da will ein beauftragter Admin bei Gelegenheit ggf. nur einige Files oder Verzeichnisse austauschen oder zum aktuellen Bestand hinzufügen – und nicht alle zu sichernden Daten komplett neu hinterlegen. Umgekehrt will er bei Bedarf nur bestimmte Versionen von einigen Dateien aus dem verschlüsselten Archiv zurückholen. Andere Benutzer haben zum Backup jedoch keinen Zugang.

Unter diesen Voraussetzungen beginnt man sich als Linux-Anwender dafür zu interessieren, ob und wie man verschlüsselte Container-Files auf einem Server nutzen und bei Bedarf auf einem Client sicher über das Internet öffnen oder mounten kann. Geht so was? Wenn ja, ist das auch hinreichend schnell?

Ich bespreche nachfolgend einen Ansatz, der auf einem gehosteten Linux-Server, Linux-Endgeräten und Veracrypt aufbaut. Ich gehe davon aus, dass die geheimzuhaltenden Daten auf dem gehosteten Server in einem Veracrypt-“Container” lagern. Ich setze den Umgang mit und Wissen über Veracrypt [VC] voraus. Unter https://www.veracrypt.fr/ en/ Documentation.html findet man u.a ein Tutorial.
Das grafische VC-Interface macht das Erstellen und Mounten von Container-Dateien zu einer relativ einfachen Übung.

Das jeweilige (mobile) Endgerät, das auf den gehosteten Server zugreifen soll, bezeichne ich nachfolgend schlicht als “Client”. Es geht in diesem Artikel primär um die sichere Lagerung der Daten auf dem Server; dennoch halte ich ein einem zweiten ergänzenden Artikel auch ein paar grundsätzliche Anmerkungen zur Sicherheit der Daten auf den Clients für angebracht.

Einschränkung:
Ich behaupte und impliziere mit diesem Artikel keineswegs, dass die Nutzung von verschlüsselten Containern eine Maßnahme ist, die für sich schon Datenschutzvorschriften und Gesetzen, die die Geheimhaltung von Daten regeln, genügen würde. Das nachfolgende Diskutierte kann höchstens ein mögliches Element in einer ganzen Kette von Sicherheitsmaßnahmen sein. Genaueres muss man in jedem Fall mit seinem Datenschutzbeauftragten und auch Anwälten klären.

Verschlüsselung

Die dauerhafte Lagerung der Daten soll bei einem Provider oder Cloud-Dienst erfolgen. Aus der Einschränkung, dass Fremde und das Personal beim Provider die Daten in keinem Fall einsehen dürfen, ergibt sich:

Die geheimzuhaltenden Daten dürfen nur auf dem eigenen Endgerät bzw. den Endgeräten der eigenen Mitarbeiter in eine unverschlüsselte Form gebracht werden – und auch dort nur temporär.

Wesentlich ist einerseits also eine (hochwertige) Verschlüsselung auf allen relevanten Ebenen des Zugriffs und der Lagerung. Anderseits sind Vorkehrungen zu treffen, dass eine Entschlüsselung nur auf bestimmten Geräten abseits des Servers stattfindet:

Anforderung 1: Ausschließlich verschlüsselte Ablage der Daten auf dem gehosteten Linux-Server. Das bedeutet aber auch: Auf dem Server dürfen keine unverschlüsselten Daten/Dateien/Dateifragmente im Speicher oder gar den Datenhaltungssystemen auftreten und verbleiben.
Anforderung 2: Verschlüsselung des Transportwegs zum und vom Server.
Anforderung 3: Entschlüsselung der Daten nur auf dem Client.
Anforderung 4: Verschlüsselung bearbeiteter Dateien auf dem Client vor dem Rücktransfer zum Server.

Ein paar ergänzende Hinweise sind aus meiner Sicht angebracht:

Hinweis 1:

Da ein Betriebssystem, Linux-Desktop-Systeme und nicht zuletzt Anwendungen Daten in allen möglichen Verzeichnissen puffern und/oder im Hinhtergrund Sicherungskopien erstellen, bedeuten die Anforderungen 1 und 3, dass wir das Container-File nie (!) auf dem Server mounten und dort auch nie auf dessen Inhalte zugreifen dürfen. Würde man das tun, stünden die geheimzuhaltenden Daten dort ja irgendwo unkontrolliert im Klartext bereit. Besonders kritisch sind in diesem Zusammenhang übrigens SSDs mit Wear Leveling zu sehen (s. den kommenden 2-ten Artikel dieser Miniserie). Heute sind solche SSDs aber fast immer Teil von Hosting-Angeboten. Also:

Ein Szenario, bei dem Anwender über das Internet auf einen auf dem Server gemounteten und entschlüsselten VC-Container zugreifen, der für externe Nutzung (z.B. über NFS) freigegeben wurde, verbietet sich in unserem Szenario von vornherein.

Das ist eine ziemlich massive Einschränkung! Klassische VPN-Ansätze sind somit ohne weitere Maßnahmen unzureichend. Und auch der “Multiuser”-Zugriff auf per NFS bereitgestellte Containerinhalte fällt flach. Um erst gar nicht in Versuchung zu kommen, installiert man das Tool Veracrypt auf dem Server am besten überhaupt nicht. (Es wird dort auch nicht benötigt.)

Hinweis 2:

Die meisten Hosting-/Cloud-Angebote bzgl. Speicherplatz – u.a. auch Stratos HiDrive – verschlüsseln zwar den Transportweg, erfüllen aber nicht die Bedingung einer verschlüsselten Lagerung der Dateien im technisch meist unspezifizierten “Cloud”-Speicher. Tatsächlich empfiehlt z.B. Strato für die sichere Lagerung von Daten eine “Synchronisation” – genauer ein Up- und Downloaden – von verschlüsselten Containerdateien.

Obwohl nicht primäres Thema dieses Artikels wollen wir bereits erste Bedingungen bzgl. der Sicherheit der Daten auf dem Client formulieren. Schließlich will man Dateien, die man aus dem Server-Archiv kopiert hat, ja auch auf seinem eigenen Endgerät vor der Einsichtname durch Fremde schützen – z.B. für den Fall eines Verlusts des Laptops/Notebooks. Eine vollständige Sicherheitskette muss deshalb u.a. auch folgenden Anforderungen gerecht werden:

Anforderung C1: Haltung/Lagerung von Dateien, die aus dem zentralen VC-Container auf den Client (Notebook/Laptop) kopiert wurden, nur in verschlüsselter Form.
Anforderung C2: Vermeidung der Ablage von Dateien/Dateifragmenten, die durch das Öffnen von Dateien aus dem Container auf dem Client in unverschlüsselter Form entstehen und ggf. an verschiedenen Stellen des Verzeichnisbaums gespeichert werden.

Hinweis 3:
Vielen Anwendern ist nicht klar, dass die eigentliche Herausforderung bzgl. einer durchgehenden Datensicherheit in der Anforderung C2 besteht. Siehe hierzu die Anmerkungen und Hinweise im zweiten Artikel dieser Serie.

Einsatz von verschlüsselten Veracrypt-Containern

Würde man nur lokal arbeiten, könnte man zur Erfüllung der Anforderungen 1 und 3 auf Tools zur Erstellung verschlüsselter Container-Dateien zurückgreifen, die dann (als Loop-Device) im Dateisystem des Clients unter gleichzeitiger Dekryptierung gemounted werden. Entsprechende Anwendungen erledigen die Ver- und Entschlüsselung quasi “en passant”.

In Frage kommen hierfür unter Linux etwa LUKS, aber eben auch Veracrypt. Letzteres betrachten viele als verbesserten Nachfolger von Truecrypt.

Der Hauptentwickler von Veracrypt ist übrigens Franzose. Vive la France! Die Entwickler haben VC mit Hilfe von Sponsoren im Jahr 2016 einem Sicherheitsaudit unterziehen lassen. Das weckt Vertrauen. [Der Vollständigkeit halber sei darauf hingewiesen, dass meines Wissens aber noch nicht alle Mängel aus dem Sicherheitsaudit von 2016 behoben sind – sehr wohl aber die wichtigsten (s. die entsprechenden Links am Ende des Artikels)]. Für uns relevant ist hier aber folgende Aussage der Entwickler:

Note that VeraCrypt never saves any decrypted data to a disk – it only stores them temporarily in RAM (memory). Even when the volume is mounted, data stored in the volume is still encrypted.

Zitiert nach “https://www.veracrypt.fr/ en/ Beginner%27s%20 Tutorial.html“. (Hervorhebung von mir.)

So wie das geschrieben ist, sollte das also auch gelten, wenn das Verzeichnis, auf dem die Veracrypt-Container-Datei liegt, mit einem geeignetem Tool auf einem Remote-System gemounted wird. Der Container auf dem Server enthält und erhält auch dann nur kryptierte Daten.

1-User-Szenario mit Veracrypt

Wir betrachten zunächst ein 1-User-Szenario. Der User habe auf dem Server den Usernamen “smy” und auf dem Client “myself“.

Ich gehe davon aus, dass der Anwender mit Hilfe von Veracrypt bereits ein verschlüsseltes Container-File angelegt und dieses über SFTP oder SCP auf dem gehosteten Server hinterlegt hat. (Der Anwender hat es dort aber wegen der oben angeführten Gründe nie geöffnet!)

Das
Container-File selbst sei auf dem Server als Datei “/mydirs/conts/vc_cont_srv” gespeichert, also im Verzeichnis “/mydirs/conts”.

Weiter gehe ich davon aus, dass der Anwender auch lokal (auf dem Client) einen verschlüsselten Veracrypt-Container angelegt hat, um dort Dateien (evtl. Datei-Kopien vom Server-Container) verschlüsselt abzulegen. Der lokale Veracrypt-Container sei in Form der Datei “/home/myself/mycont/vc_cont_cli” gespeichert.

Auf dem Client seien mehrere Mount-Punkte für Remote-Verzeichnisse und VC-Container vorgesehen.

Mount-Punkte auf dem Client:

“/home/myself/mnt_remote” für das Mounten eines beliebigen Remote-Verzeichnisses (hier etwa von “conts”).
“/home/myself/mnt_vc_srv” für das Mounten des Veracrypt-Containers vom Server (“vc_cont_srv”).
“/home/myself/mnt_vc_cli” für das Mounten des lokalen Veracrypt-Containers (“vc_cont_cli”).

Zielsetzung: Zweistufiges Mounten statt Hin- und Herschieben kompletter Containerfiles

Wir möchten in unserem Szenario nicht größere Containerfiles vom Server zum Client kopieren, dort lokal mounten, damit arbeiten und danach wieder das geänderte Veracrypt-Containerfile vollständig auf den Server zurückschieben. Das ist unbequem und kostet bei großen Containern in Abhängigkeit von der Bandbreite der Internet-Anbindung des Clients natürlich Zeit – besonders beim Upload.

Unser Lösungsansatz besteht vielmehr darin, das Verzeichnis des Servers, das den VC-Container enthält, remote auf dem Client zu mounten. Anschließend hängen wir das Containerfile mit Hilfe von Veracrypt in den lokalen Verzeichnisbaum des Clients ein. In der obigen Skizze sind beide sukzessiven Schritte des Mountens angedeutet.

Die Dekryptierung und bei Änderungen auch die Kryptierung von Container-Inhalten (neue oder geänderte Files/Verzeichnisse) würde im Zuge eines solchen Verfahrens allein im RAM des Clients vor sich gehen.

Nun ist Mounten ein Prozess, bei dem nicht das gesamte Filesystem durchforstet werden muss, und der deshalb schnell ist. Unsere Hoffnung ist also, dass dies auch für das Mounten des VC-Containers aus einem remote gemounteten Verzeichnis gilt. Falls das so funktionieren würde, läge der wünschenswerte Unterschied gegenüber einem Hin- und Her-Kopieren des gesamten Container-Files vor allem darin, dass bei Zugriffen auf Container-Inhalte nur diejenigen (verschlüsselten) Datenbereiche über Inodes addressiert und transferiert würden, die am Client tatsächlich benötigt werden.

Zunächst (beim Mounten) vor allem Veracrypt-Header und Verzeichnisstrukturinformationen. Blöcke, die zu einzelnen Dateien gehören, welche anschließend dem Client mit lokalen Instrumenten wie Editoren geöffnet werden, müssten allerdings vollständig übertragen werden (soweit es sich nicht um streambare Dateien handelt) – aber eben nur die Blöcke der zu bearbeitenden Dateien. Und nicht der komplette Container. Ein vollständiger Datei-Transfer ist ggf. auch für Schritte zum (Zwischen-) Speichern geänderter Dateien zu erwarten (s.u.). Deshalb arbeiten wir auf dem Client evtl. effizienter mit Kopien (s.u.), die wir nach Abschluss der Arbeiten wieder in den gemounteten Container laden.

Einsatz von SSH für die Verschlüsselung des Transportweges

Um der Anforderung 2 nachzukommen, können wir unter Linux z.B. auf SSH (genauer: OpenSSH mit Key-Authentication) setzen. Ansonsten müssten wir uns mit einer aufwändigen Kerberos- und NFS4- Konfiguration herumschlagen,
um eine hinreichende Verschlüsselung zu erreichen. SSH bringt zugegebenermaßen Latenzprobleme mit sich – aber bei aDSL/vDSL-Verbindungen mit begrenzten Upload-Geschwindigkeiten ist das vermutlich nicht mal das primäre Problem, über das es sich nachzudenken lohnt.

Wie man SSH für eine schlüsselbasierte Authentifizierung konfiguriert, habe ich in diesem Blog schon mehrfach an anderer Stelle besprochen. Ich gehe daher davon aus, dass für den SSH-Zugang zum gehosteten Server auf dem Client ein (passwortgeschütztes) Keyfile etwa unter “~/.ssh/KEYFILE” bereitsteht.

Zu weiteren Maßnahmen für eine Absicherung der SSH-Verbindung gegenüber Angriffen siehe etwa https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html. In Sinne des genannten Artikels hat man sich natürlich um aktuelle OpenSSH-Versionen zu kümmern. Vor allem aber sollte man die einzusetzenden asymmetrischen SSH-KEX-Algorithmen, symm. Verschlüsselungs- und Hash-Algorithmen auf noch als sicher geltende Verfahren einschränken!

Einsatz von SSHFS

SSH erlaubt zunächst nur eine verschlüsselte Verbindung. Wir wollen in unserem Szenario ja aber das Verzeichnis “conts” vom Server mounten. Dafür haben wir mehrere Möglichkeiten, u.a.

CIFS über einen SSH-Tunnel,
NFS3/4 über einen SSH-Tunnel.
NFS4 mit Kerberos
SSHFS.

Vermutlich ist NFS4 die performanteste und skalierbarste unter den genannten Alternativen. NFS4 erfordert jedoch Einiges an grundsätzlicher Konfigurationsarbeit – im Besonderen bzgl. der Benutzerberechtigungen. Hinzu kommt die Einrichtung der SSH-Tunnel. Will man SSH-bedingte Latenzprobleme vermeiden, führt kein Weg an NFS4 und Kerberos vorbei. Damit sind manche User evtl. überfordert.

Ich greife in diesem Artikel daher mal zu SSHFS; das kombiniert mir den Einsatz von FUSE bei gleichzeitiger Verschlüsselung der Verbindung: FUSE erlaubt es, Filesysteme auf einfache Weise im Userspace zu mounten. SSHFS erlaubt das Mounten von Remote-Verzeichnissen über FUSE und unter SSH. Dabei werden u.a. Fähigkeiten von SFTP genutzt. Letzteres ist bei OpenSSH dabei. Voraussetzung der Nutzung ist die Installation der Distributionspakete zu FUSE und SSHFS. Auf dem Server muss OpenSSH natürlich hinreichend eingerichtet sein. Der zugehörige Port muss in der Firewall geöffnet sein. Zugangsberechtigungen sollten auf User-, Gruppen-Ebene und Host-Ebene geregelt sein.

Es ist – wie bei SFTP auch – möglich, bestimmte SSHFS-Benutzer auf das Mounten definierter Verzeichnisse unterhalb eines CHROOT-Verzeichnis einzuschränken. Dafür nimmt man als Admin normale SFTP-Einstellungen für User- und Gruppen-Zugriffe auf ein definiertes CHROOT-Directory vor. Siehe hierzu etwa
https://wiki.archlinux.org/ index.php/SSHFS
https://wiki.archlinux.org/ index.php/ SCP_and_SFTP
SFTP mit Key-Authentication auf (gehosteten) Linux-Servern für Web-Entwickler mit unterschiedlichen Privilegien – II

Performance von SSHFS?

Man sollte sich bei Gelegenheit mit den Parametern von SSHFS zum Caching, zur Komprimierung etc. befassen. Das Schöne ist, dass man bei etwas Optimierung in einigen Anwendungsfällen sehr wohl an die Performance von NFS herankommt – mit Ausnahme von Random Read-Operationen (max. 60% der NFS-Performance ohne SSH-Tunnel). Siehe für Benchmark-Daten und Optimierungshinweise:

http://www.admin-magazine.com/ HPC/ Articles/ Sharing-Data-with-SSHFS
https://www.smork.info/ blog/ 2013/04/24/ entry130424-163842.html
http://www.linux-magazine.com/ Issues/ 2014/165/ SSHFS-MUX
http://homepages.warwick.ac.uk/ staff/ E.J.Brambley/ sshspeedtest.php
Kritik: http://julio.meroh.net/ 2016/02/ sshfs-performance-analysis-for-builds.html

Tip: Bei langsamen Leitungen sollte man unbedingt auch Performance-Vergleiche für Zugriffe mit oder ohne Kompression anstellen.

Mounten des Server-Verzeichnisses mit SSHFS

Ich gehe mal davon aus, dass auf dem Client (Laptop/Notebook/PC) zu einem bestimmten Zeitpunkt nur ein User – hier “myself” – arbeitet. Wie mounted der nun konkret ein Verzeichnis vom Server unter Beachtung des Key-Files mit SSHFS?

Der Server habe beispielsweise die Adresse “h1234567.stratoserver.net”. Der SSH-Zugang sei dort in der Firewall z.B. unter dem Port 57888 geöffnet. Der notwendige Befehl zum Mounten des oben angegebenen Remote-Verzeichnis wäre dann:

myself@mytux:~> sshfs -p 57888 -o "IdentityFile=/home/myself/.ssh/KEYFILE"  smy@h1234567.stratoserver.net:/mydirs/conts/ ~/my_mnt -o idmap=user -o uid=$(id -u) -o gid=$(id -g) 
Enter passphrase for key '/home/myself/.ssh/KEYFILE':

Durch die Optionen “-o uid=$(id -u) -o gid=$(id -g)” wird eine Abbildung der UID und GID des lokalen Users “myself” auf den Remote-User “smy” und dessen Rechte geleistet! Das ist eine sicherheitsrelevanter Punkt, den man bei Konfigurationen für mehrere User im Auge haben muss.

Hinweis: Man kann die Optionen übrigens auch nur nach einem “-o”, dann aber kommasepariert angeben.

Man wird zur Eingabe des Passworts aufgefordert. Danach steht einem der Inhalt des gemounteten Verzeichnisses bereits zur Verfügung:

myself@mytux:~> la my_mnt
insgesamt 573448
drwx------  1 myself users      4096 19. Aug 14:58 .
drwxr-xr-x 83 myself users      4096 20. Aug 15:38 ..
-rw-------  1 myself users 524288000 19. Aug 15:29 vc_cont_srv
myself@mytux:~>

Mounten des Veracrypt-Containers auf dem Client – Fehlermeldung ???

Funktioniert nun bereits der zweite Schritt, nämlich ein lokales Mounten des Containers “vc_cont_srv”, der uns auf dem Client ja nun unter “/home/myself/my_mnt/vc_cont_srv” zur Verfügung steht? Leider Nein!

Versucht man wie gewohnt, den Container mit Veracrypt auf das Zielverzeichnis “/home/myself/mnt_vc_srv” zu mounten, so erhält man eine Fehlermeldung der Art:

Keine Berechtigung:
/home/myself/my_mnt/vc_cont_srv

VeraCrypt::File::Open:232

Was ist die Ursache und wie kann man damit umgehen?

Rechteproblem beim lokalen Mounten eines Veracrypt-Containers aus einem SSHFS/Fuse-Verzeichnis heraus

Die Fehlermeldung deutet an, dass bereits der Zugriff auf das Containerfile selbst nicht klappt! Man könnte dabei auf ein Problem mit SSHFS-Rechten tippen; ggf. mit der UID und GID-Abbildung. Führt man aber einen Zugriff auf andere Dateien mit gleicher User-Berechtigung durch, so geht das einwandfrei! Also muss das Rechteproblem am Zusammenspiel von Veracrypt mit FUSE liegen. Ein wenig Recherche im Internet zeigt, dass Veracrypt den Mount-Prozess mit “root”-Rechten abwickelt. Nächste Frage: Darf “root” denn nicht auf die Inhalte des gemounteten FUSE-Filesystems zugreifen? Ein Versuch zeigt tatsächlich:

mytux:~ # cd /home/myself/my_mnt
-bash: cd: /home/myself/my_mnt: Permission denied
mytux:~ # cd /home/myself/
mytux:/
home/myself #

Es handelt sich hier um eine (sehr sinnvolle) Sicherheitssperre unter FUSE! Die ist vor allem auf Multiuser-Systemen wichtig! Interessanterweise kommen dabei andere und mehr Gründe als nur die Sorge um reine Zugangsberechtigungen ins Spiel. Siehe hierzu: https://www.kernel.org/ doc/ Documentation/ filesystems/ fuse.txt

Kann man diese Sperre für unsere Situation umgehen? Antwort: Ja, wenn das von “root” auf dem Client erlaubt wird oder wurde! Es geht dabei um eine grundlegende FUSE-Sicherheits-Einstellung, die man in der dortigen Datei “/etc/fuse.conf” vornehmen muss. Siehe hierzu:
http://man7.org/linux/man-pages/man8/mount.fuse.8.html
https://wiki.ubuntuusers.de/ FUSE/

Auf einem Client-System unter Debian sieht diese Datei etwa wie folgt aus:

root@deb:~# cat /etc/fuse.conf 
# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE)

# Set the maximum number of FUSE mounts allowed to non-root users.
# The default is 1000.
#mount_max = 1000

# Allow non-root users to specify the allow_other or allow_root mount options.
#user_allow_other
root@deb:~#

In unserem Fall, in dem der User “myself” allein dem Laptop nutzt, finde ich es akzeptabel, die Option

user_allow_other

zu setzen – also das Kommentarzeichen “#” zu entfernen.

Hinweis:
In einigen Linux-Distributionen (Opensuse Leap, Ubuntu) ist die Konfigurationsdatei “/etc/fuse.conf” aber nicht mal vorhanden. Macht nichts: Man kann sie einfach anlegen; sie wird dann ausgelesen.

Unser User “myself” hat nach dieser grundlegenden Systemänderung dann zwei Optionen, zwischen denen er unter SSHFS wählen kann: “allow_root” und “allow_other”. Für unsere Zwecke genügt “allow_root”. Wir müssen unseren SSHFS-Befehl noch wie folgt anpassen:

myself@mytux:~> sshfs -p 57888 -o "IdentityFile=/home/myself/.ssh/KEYFILE"  smy@h1234567.stratoserver.net:/private-backup/private-backups/conts/ ~/my_mnt -o idmap=user -o uid=$(id -u) -o gid=$(id -g) -o allow_root   
Enter passphrase for key '/home/myself/.ssh/KEYFILE':

Die erforderlichen Kommandos wird man als Admin des Clients natürlich in adäquater Weise in Scripts einbauen, die man dem User bereitstellt.

Jedenfalls klappt es danach auch mit Veracrypt: Der User “myself” kann das File endlich in seinen Verzeichnisbaum einhängen. Hat man im Veracrypt-Dialog den Slot 4 gewählt und den vorgesehenen Mount-Point “/home/myself/mnt_vc_srv” explizit unter “Options” eingetragen, so sieht das Ergebnis wie folgt aus:

myself@mytux:~> mount
smy@h1234567.stratoserver.net:/mydirs/conts/ on /home/myself/my_mnt type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1029,group_id=100,allow_other)
veracrypt on /tmp/.veracrypt_aux_mnt1 type fuse.veracrypt (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/mapper/veracrypt4 on /home/myself/mnt_vc_srv type ext4 (rw,relatime,data=ordered)

In meinem Testfall kontrolliere ich noch, ob der Inhalt des Containers auch angezeigt wird:

myself@mytux:~> la ~/mnt_vc_srv
insgesamt 76127
drwxr-xr-x  3 myself  users     1024 19. Aug 16:14 .
drwxr-xr-x 83 myself  users     4096 20. Aug 15:50 ..
-rwxrwxrwx  1 myself  users 19580917 18. Nov 2011  ajax.pdf
-rw-r--r--  1 root root   3544281  6. Jan 2017  blktrace_sdb6_kernel44.zip
drwx------  2 root 
root     12288 19. Aug 15:29 lost+found
-rw-r--r--  1 myself  users 31498557  4. Jan 2017  Reiher-848x480-13064.mp4
-rw-r--r--  1 myself  users  1159382  4. Jan 2017  Reiher-848x480-600kb.mp4
-rw-r--r--  1 root root   9963112  6. Jan 2017  sdb6.blktrace.0
-rw-r--r--  1 root root   5791834  6. Jan 2017  sdb6.blktrace.1
-rw-r--r--  1 root root   3864342  6. Jan 2017  sdb6.blktrace.2
-rw-------  1 root root   2529586  6. Jan 2017  sdb6.blktrace.3
myself@mytux:~>

Das sind offenbar keine besonders gheimnisvollen Daten. Ist ja nur ein Test. Man sieht, dass auch der User “root” hier mal was abgelegt hat. Obwohl ich (“myself”) gemountet habe, werden die Zugriffsrechte aber natürlich nicht umgangen:

myself@mytux:~> cat mnt_vc_srv/sdb6.blktrace.3
cat: mnt_vc_srv/sdb6.blktrace.3: Keine Berechtigung
myself@mytux:~>

Man kann nun auf dem Verzeichnis unter “/home/myself/mnt_vc_srv” nach Bedarf arbeiten. Z.B. Libreoffice-Dateien anlegen und bearbeiten.

Wie lange dauert das Mount des VC-Containers?

Das Mounten des Verzeichnisses “conts” mit SSHFS geht sehr schnell von statten. Das anschließende Mounten
eines 1GB großen Containers, der mit 500 MByte an Dateien in einem recht verzweigten Baum gefüllt war, dauerte bei Tests mit einer aDSL-Verbindung [16MBit/s] nur zwischen ca. 4 und 5 Sekunden.

Das ist akzeptabel. Es ist offensichtlich, dass hierfür (wie erwartet) nicht das gesamte Container-File transportiert wird. VC genügt offenbar der Zugriff auf Header Informationen aus dem File und den Filesysteminformationen für das Loop-Device.

Arbeiten mit größeren Files – z.B. unter LibreOffice Writer

Ich habe testweise mal ein 2,4 MByte großes odt-File unter LO-Writer editiert und zwischendrin immer wieder abgespeichert. Da sieht es dann so aus, dass das gesamte File zur Ablage über das Netz transferiert wird. Reguläres Speichern im Hintergrund gibt es unter LO ja leider nach wie vor nicht …

Das ist bei einer langsamen Verbindung natürlich nicht prickelnd – LO Writer ist während des Speicherns bei einer ADSL-Uploadgeschwindigkeit von 2.4MBit zw. ca. 7 – 8 Sek. nicht benutzbar.

Das Speichern von Wiederherstellungsinformation passiert dagegen ja lokal am Client und geht schnell. Aber reguläres Speichern eben nicht. Dafür benötigt man eine hinreichend schnelle Verbindung.

Alternativ arbeitet man jedoch am besten mit einer lokalen Kopie der Datei und lädt die dann “hoch”, indem man sie in das gemountete Verzeichnis unter dem Vercrypt-Mountpunkt /home/myself/mnt_vc_srv” des Servercontainers kopiert. Immerhin muss man so nur einzelne Dateien kopieren und nicht den ganzen Container!

Unmount?

Hat man seine Arbeiten beendet, so muss man zwei Unmounts in folgender Reihenfolge vornehmen:

Unmounten des Veracrypt-Containers vom Verzeichnis “/home/myself/mnt_vc_srv”. Dies macht man am besten über das VC-Interface.
Unmounten des SSHFS Remote-Verzeichnisses vom Verzeichnis “/home/myself/my_mnt”

Für Letzteres ist der Befehl “fusermount -u” heranzuziehen:

myself@mytux:~> fusermount -u my_mnt

Weiter oben hatte ich ja auf Parameter von SSHFS für eine Optimierung (Cahcing etc.) hingewiesen. Das Caching sorgt bei viel RAM auf dem Client in vielen Situationen übrigens für einen falschen Eindruck beim Dateitransfer. Kopiert man etwa mittels eines Dateimanagers wie Dolphin größere Dateien in Richtung Server, so signalisieren Dolphin bzw. KDE einem ein sehr schnelles Ende des Transfers; das findet aber nur im lokalen Puffer statt. Der echte Transfer über Netz hat dann bei langsamen Upload-Verbindungen gerade erst begonnen.

Man sollte bei größeren Dateitransfers also den
ausgehenden Netzverkehr im Auge haben, bevor man mit dem Unmounten beginnt. Oftmals ist noch nicht alles zum Server transferiert worden, was da hin muss.

Verbindungsabbruch und Folgen

Was ich im Vorfeld dieses Artikels nicht getestet habe, sind Folgen einer Verbindungsunterbrechung. Dennoch kann man dazu was sagen. Ein Verbindungsabbruch hat potentiell Konsequenzen für die Konsistenz des Container-Files, aber auch des umgebenden Filesystems auf dem Server. Probleme mit letzterem sind mit Hilfe von “fsck” auf dem Server relativ einfach zu beheben. Zumindest, wenn man das Verzeichnis auf dem Server mit einem eigenen Filesystem unterlegt hatte – wozu ich ausdrücklich rate, falls dies denn im Rahmen des Hosting-Paketes möglich ist!

Schwieriger sieht es mit der internen Konsistenz des Container-Files selbst aus. Hier muss man auf dem Client (!) eine Dekryptierung ohne Mounten vornehmen. Danach kann man dann fsck auf das dekryptierte Filesystem anwenden. Informationen, wie man das mit Truecrypt zu machen hatte, findet man hier. Angeblich gelten die Anweisungen auch für Veracrypt in analoger Weise.

http://john.wesorick.com/2012/03/running-fsck-on-truecrypt-volume.html
Siehe auch:
https://serverfault.com/ questions/ 83601/ how-to-fsck-ext3-a-truecrypt-volume
http://sebsauvage.net/ links/ ?GsfKdw

Das dauert je nach Größe des Container-Files natürlich unangenehm lange, da dabei über Netz gearbeitet werden muss. Regelmäßige Backups des Vercrypt-Containers sind in unserem Szenario nicht nur aus diesem Grunde Pflicht. Darauf weise ich ausdrücklich hin.

Größeren Schäden vorbeugen kann man auch durch reine Read-Only-Mounts. Und falls Schreiben/Änderungen an Container-Inhalten absolut erforderlich sind: Arbeiten auf Datei- oder Verzeichnis-Kopien und nur kurzzeitiges RW-Mounten zum Upload der geänderten Datei.

Gleichzeitiger Zugriff mehrer Personen? Einsatz für Firmen?

Wie sieht es nun mit Szenarien aus, bei denen mehrere User zugreifen müssen? Hierzu sind mehrere Punkte anzuführen:

Skalierung: Ich habe das nicht getestet – aber vermutlich gilt: SSHFS skaliert nicht so gut wie NFS. Ab einer durch Tests zu bestimmenden Useranzahl lohnt sich vermutlich der Umstieg auf NFS.

Read Only: Auch unter NFS können nicht mehrere User unabhängig voneinander einen VC-Container bei sich lokal zum Lesen und Schreiben auf dem jeweiligen Client mounten. Das führt unweigerlich in die Katastrophe! Die Konsistenz des VC-Containers kann am Server unter diesen Bedingungen nicht aufrechterhalten werden!

Die Vercrypt-Entwickler haben zu diesem Thema eine entsprechende Empfehlung abgegeben, die schon für Truecrypt-Container galt:

Für schreibende Zugriffe durch mehrere Personene muss der Container bereits am Server gemounted und dann einem Sharing-Verfahren (z.B. über NFS oder SSHFS) unterworfen werden.
Ansonsten darf der Container nur dann auf mehreren Endgeräten gleichzeitig gemounted werden, wenn dies ausschließlich lesend erfolgt. Dies bedeutet im Klartext, dass bereits das umgebende Verzeichnis (hier: ) nur ReadOnly gemounted wird.

Siehe: https://www.veracrypt.fr/ en/ Sharing%20over%20Network.html

Die erste Variante fällt für unseren gehosteten Server – wie oben begründet – flach. Das bedeutet:

Multiuser-Szenarien auf gehosteten Servern sind nur im rein lesenden Modus möglich, nicht aber für Schreibzugriffe.

Würde man den Container andererseits indirekt über einen eigenen Server in der Firma mounten und dort freigeben, stellt sich die Frage, warum man nicht gleich über diesen Server arbeitet.

Ausweg bzgl. notwendiger Änderungen:
Leider nur in Kombination mit organisatorischen Maßnahmen. So könnten Mitarbeiter inhaltliche Änderungen lokal vornehmen und in GIT-/SVN-Repositories einchecken, die spätestens beim nächsten Aufenthalt in der Firma abgeglichen werden. Das Ergebnis des Abgleichs wird dann wieder für alle sichtbar in eine Containerdatei ausgespielt, die auf den Clients der mobilen Mitarbeiter nur lesend gemounted werden darf und kann.

Ich finde, das ist für viele Anwendungsfälle keine massive Einschränkung.

Ein Mehrbenutzerszenario, bei dem User auf dem Server grundsätzlich nicht nur lesende Operationen durchführen dürfen, ist von Haus mit sekundären Sicherheits-Problemen verbunden. Man muss etwa verhindern, dass die User geheimzuhaltende Daten eigenhändig und abseits des Containers auf den Server transferieren können. Alles andere als einfach …

Hochsicherheit am Server?

Man kann für manche Dateien, deren Inhalte (z.B. Passwörter) besondere Sicherheitsvorkehrungen erfordern, das Spielchen noch etwas weiter treiben:

Man erlaubt nur RO-Zugriffe – und hinterlegt diese Dateien innerhalb des VC-Containers nochmals verschlüsselt. Am besten mit GnuPGP – das gilt noch als sicheres Verfahren. Das PGP-File oder den PGP-Container kopiert und entschlüsselt man dann mit Tools wie Kleopatra oder KGpg auf dem Client.

Ein Angreifer, der es irgendwie schafft, den VC-Container oder den Datenverkehr vom/zum Client zu knacken, sieht sich dann immer noch mit dem PGP-File/Container konfrontiert. Wohlgemerkt: Das erhöht zwar die Sicherheit auf dem gehosteten Server. Aber es verschiebt die Sicherheitsthematik ganz genau wie die VC-Entschlüsselung auf den Client.

Weitere Schwachstellen?

Sind wir nun nach menschlichem Ermessen sicher? Nun ja, jedes System kann gehackt werden. Und sicher hat auch ein böswilliger Admin beim Provider die Möglichkeit dazu. Eine manupulierte Implementierung von SSH wäre in unserem Szenario z.B. ein Ansatzpunkt für einen Angriff. Ein Minimum an weiteren Vorsichtsmaßnahmen muss daher sein, dass wir Systempakete selbst installieren (soweit möglich) – und deren Integrität mit IDS-Tools überwachen. Für einzelne Komponenten wie SSH ggf. mit Tripwire.

Man kann die Integritätsbetrachtung aber natürlich beliebig ausdehnen – bis hin zum Host-Kernel, auf den man oft keinen Einfluss hat. Das führt zur Frage des Einsatzes von Root-Servern, die man absichern muss. Die Frage ist dann: Wann hat man gesetzlichen Vorgaben auf dem Stand der Technik Genüge getan?
Wir nähern uns erneut Domäne von Vorgaben durch Datenschutzbeauftragte und Anwälten. Und das sprengt diesen Artikel. Aber es macht erneut klar: Echte Sicherheit endet nicht bei der verschlüsselten Ablage von Daten.

Ausblick

Wir haben gesehen, dass es bei einer bzw. wenigen Personen durchaus möglich ist, Veracrypt-Container auf einem Server zu nutzen, ohne jemals eine Entschlüsselung auf dem Server selbst vornehmen zu müssen. Eine einfache Möglichkeit des Zugriffs ergibt sich dabei über SSHFS und eine anschließendes Mounten des VC-Containers auf dem Client.

Szenarien für Lese- und Schreibzugriffe mehrerer Anwender sind ohne Gefährdung der Sicherheit nicht möglich. Hier ist auf ReadOnly-Szenarien und organisatorische Maßnahmen auszuweichen.

Für Einzelanwender geht dagegen sogar Lesen und Schreiben. U.a. LibreOffice erfordert aber hohe Upload-Raten der Verbindung, da das Zwischenspeichern zum Transfer der gesamten geöffneten Datei führt.
Alternativ arbeitet man mit lokalen Kopien am Client. Ein Hin- und Her-Kopieren des gesamten Containers erscheint jedoch überflüssig. Bitte
korrigiert mich, wenn ich etwas übersehen haben sollte.

Im nächsten und letzten Artikel dieser Serie

Veracrypt, SSHFS und sichere Datenhaltung auf gehosteten Servern – II – die Client-Seite …

stelle ich einige Hinweise zur Sicherheit der Daten auf unserem Client zusammen. Denn es gilt: Wir handhaben dort entschlüsselte Daten und haben damit die Sicherheitsthematik auf das Endgerät des Benutzers verschoben.