Category Archives: Security und Security-Tools

firejail firecfg – Problem mit dem KDE-Login unter Opensuse Leap 42.3 – .ssh-Dateien und ssh-agent als Ursache

Posted on by

Experimentiert man unbedarft mir neuen Dingen, muss man sich nicht wundern, wenn man sich Probleme schafft. Jetzt passierte mir das mit firejail.

Ich muss manchmal Skype benutzen. Zu meinem großen Ärger, da jede Art von Closed Source UDP-Streaming Applikation ein prinzipielles Sicherheitsrisiko darstellt. In einen UDP-Datenstrom können immer Pakete integriert werden, die ganz anderen Zwecken dienen als der Übertragung der eigentlichen Audio- und Videodaten. Und wenn man dann den Code nicht kennt … Neben dem Aufsetzen eines speziell konfigurierten Containers ist die Nutzung von Firejail eine Gegenmaßnahme, solchen Applikationen das Vordringen ins System zu erschweren.

Opensuse 42.3 bietet im Repository “Virtualization”
ein RPM-Paket firejail 0.9.5 zum Download an. Das habe ich installiert. nach der Installation war zunächst auch ein kein Problem feststellbar.

Aber dann habe ich ein wenig in der Dokumentation gestöbert. Auf der Seite https://firejail.wordpress.com/documentation-2/ findet man dann unter dem Titel “I’ve just installed Firejail, now what?!” Hinweise zu bestimmten Kommandos, um “pulseaudio” [PA] zu korrigieren (wundert mich nicht) und auch das Kommando “firecfg” auszuführen:

$ firecfg –fix-sound
$ sudo firecfg

Beides hat u.U. aber unangenehme Nebenwirkungen:

1) Pulseaudio zunächst nicht mehr deaktivierbar
Das erste Kommando korrigiert “pulseaudio”-Konfigurationsdateien zwar; es sorgt aber auch dafür, dass man unter Opensuse PA nicht mehr einfach über YaST und die dortige Audio-Konfiguraiton abschalten kann. Bekanntermaßen verwende ich PA nur, wenn nicht umgehbar. So erzwangen etwa frühere Skype Versionen für Linux ( u.a. die Version 4.3) die Nutzung von PA. Das ist beim aktuellen “skypeforlinux” (Beta) nicht der Fall; das kooperiert auch direkt mit Alsa.

Das ist auf meinem Laptop auch gut so, denn PA erzeugt dort ein dauerhaftes unangenehmes Hintergrundsgeräusch (niederfrequenter Pfeifton; keine Rückkopplung) auf meinem eingebauten Mikrophon (unabhängig von Skype). Das ließ sich auch durch Ändern der Empfindlichkeit und der Regelung von Verstärkungsfaktoren unter dem PA-eigenen “pavucontrol” nie beseitigen. Ein solches Geräusch tritt bei mir im reinen Alsa-Betrieb dagegen nicht auf.

Beseitigt habe ich die Aktivierung von PA dann durch Umbenennen/Verschieben der Datei “~/.pulseaudio” und anschließende erneute Deaktivierung von PA über YaST.

2) Kein KDE-Login und kein X11-Start mehr für bestimmte Accounts möglich
Schlimmer ist dagegen eine Auswirkung des zweiten Kommandos: Es erzeugt eine Liste von Links unter dem Verzeichnis von “/usr/local/bin“, die alle auf firejail verweisen. Normalerweise führt das dazu, dass viele Programme/Anwendungen über firejail gestartet und geschützt werden. Leider ist die Liste der Profile für Anwendungen aber keineswegs vollständig. Wird für eine Anwendung nichts gefunden, dann kommt wohl ein “default.profile” zum Einsatz. Letzteres verhindert aber den Zugriff u.a. auf ~/.ssh und ~/.gnupg-Verzeichnisse und dortige Dateien. Das wird aber unter Umständen unter Opensuse zu einem Megaproblem beim Start von KDE aus SDDM oder KDM heraus:

Ich konnte mich unter bestimmten Accounts nach dem Absetzen von firecfg nicht mehr von KDM oder SDDM aus in KDE (Plasma 5) einloggen. X11 wurde nicht gestartet; man landet nach ca. 1 Sekunde wieder auf dem KDM oder SDDM-Login-Schirm.

Die Fehlermeldungen hierzu waren unzureichend. Nach mühsamen Experimenten mit Konfigurationsdateien stieß ich schließlich darauf, dass allein die Existenz eines “~/.ssh“-Verzeichnisses zu Fehlern beim KDE-Start
führte. Entfernte ich das Verzeichnis komplett, ließen sich KDE und X11 wieder regulär starten.

Wer oder was will im Start “~/.ssh” auslesen? Mir fiel dazu zunächst nichts ein. Dann stieß ich auf ssh-agent. Und tatsächlich ergab sich unter Opensuse Leap 42.3 folgendes Bild: 

mytux:~ # ps aux | grep ssh
root      1574  0.0  0.0  53492  5816 ?        Ss   13:30   0:00 /usr/sbin/
sshd -D
myself       4065  0.0  0.0  20136  1868 ?        S    13:30   0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/
agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc
myself       4067  0.0  0.0  13312   332 ?        Ss   13:30   0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc

Offenbar klappt diese Art des X-Starts nicht mit dem komplett gefüllten “/usr/local/bin” (genauer mit den dortigen Links). Ich sehe die Ursache – wie gesagt – im “default.profile”.

Die Link-Orgie unter “/usr/local/bin” beseitigt man übrigens mit

firecfg –clean

Danach klappt der Login in das X11/KDE-Gespann alles wieder. Meine Strategie ist im Moment, die Profile für verschiedene Anwendungen zu checken und “/usr/local/bin” langsam und systematisch mit Links zu füllen, die nur bestimmte Anwendungen betreffen.

Bei manchen alten Accounts habe ich zudem festgestellt, dass die Anlage der Links unter /usr/local/bin” auch dazu führt, dass jeglicher Netzwerkzugriff unterbunden ist. Hier bin ich noch an der Ursachenforschung.

Merke: Nicht gleich alles machen, was Manuals vorschlagen, wenn man von einer neuen Anwendung noch zu wenig versteht.

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

Posted on by

Vor einigen Tagen habe ich abends ein paar begeisterte Linux-Anhänger getroffen; einige Gesprächspartner haben mir gegenüber die Sicherheit von Linux gegenüber MS Windows hervorhoben. Bei allem Respekt: IT-Sicherheit ist selten nur eine Frage des Betriebssystems. Wer meint, dass die Installation von Linux “Sicherheit” quasi garantieren würde, irrt gewaltig. Der Einsatz von Linux entbindet den Nutzer keineswegs

  • von einer detaillierten Risiko-Analyse/-Bewertung für potentiell bedrohte Daten oder Systeme
  • und von der Festlegung geeigneter Gegenmaßnahmen.

Dieser Artikel liefert hierfür ein relativ einfaches Beispiel:

Wir betrachten die Sicherheit der Inhalte von Dateien, die wir in verschlüsselten Datei-Containern verwahren. Wir öffnen solche Dateien bei Bedarf beispielsweise auf einem Laptop. Der Kontext wurde durch den vorhergehenden Artikel dieser Miniserie

Veracrypt, SSHFS und kryptierte Datenhaltung auf gehosteten Servern – I

vorgegeben: Dort hatte ich beschrieben, wie man verschlüsselte Veracrypt-Container auf gehosteten Servern zur Lagerung geheimzuhaltender Informationen einsetzen kann. Ich hatte bereits im letzten Artikel betont, dass die Dateien auf dem Server selbst nie in entschlüsselter Form verwendet werden sollten. Um diesen Punkt herum rankten sich dann zwei durchzuführende Mount-Prozesse, um die Container-Inhalte remote auf einem Client – z.B. auf einem mobilen Laptop – bequem nutzen zu können.

Der Client ist also das System, auf dem wir unsere geheimen Daten entschlüsseln und konkret nutzen. Ich gehe nachfolgend auf einige ausgewählte und prinzipielle Sicherheitsaspekte ein, die man dort im Auge behalten sollte. Die Liste der sicherheitsrelevanten Punkte ist damit keineswegs abgedeckt; aber unsere Diskussion wird zeigen, dass Sicherheit immer nur durch eine Kombination verschiedener Maßnahmen entsteht – unter Linux ebenso wie unter anderen Betriebssystemen. Linux erleichtert dem User dabei im Idealfall die Umsetzung der notwendigen Maßnahmen; der Einsatz von Linux allein ist für die Erfüllung von Geheimhaltungspflichten in der Regel aber unzureichend.

Ausgangssituation und Nutzerverhalten

Die zu schützenden Güter (im ISO 27001-Jargon: Assets) sind in unserem Beispiel geheimzuhaltende Informationen, welche in Dateiform vorliegen. Nehmen wir als extremes Beispiel etwa eine “odt”-Datei, in der der User etliche schwer zu merkende Passwörter hinterlegt hinterlegt hat. Ein ebenso brisantes Beispiel wäre etwa die Hinterlegung von Patientendaten, auf die eine Ärztin im mobilen Einsatz zugreifen möchte, in einem verschlüsselten Dateicontainer. Der Container kann remote vorliegen – etwa als Veracrypt-Archiv auf einem über das Internet erreichbaren Server. Verschlüsselte Container können aber auch lokal auf dem Laptop selbst angelegt sein.

Als Anwender/Anwenderin vertrauen wir dabei völlig auf die Verschlüsselung der Dateien. Unser Linux-Laptop für den mobilen Einsatz sei zeitgemäß ausgestattet und beinhalte u.a eine SSD. Als Anwender greifen wir auf unsere Dateien, wie im letzten Artikel beschrieben, bei Bedarf mit SSHFS und in jedem Fall mittels lokalet VC-Mounts auf dem Client zu.

Wenn erforderlich öffnen wir die Datei auf dem Laptop mit Hilfe einer passenden Anwendung (z.B. LibreOffice). Ggf. legen wir dort sogar eine Kopie der Datei an. Die Kopie lagern wir auf dem Laptop in einem der dortigen verschlüsselten VC-Containern. Geöffnete, entschlüsselte Dateien schließen wir nach Beendigung unserer Arbeit sofort wieder.

Als potentielles Bedrohungsszenario betrachten wir im Rahmen dieses Artikels primär den Verlust oder Diebstahl des Laptops. In diesem Fall ist ein physikalischer Zugriff
Unbefugter oder Krimineller auf das Gerät möglich. Frage:

Sind unsere Dateien, die dort in einem Veracrypt-Container lagern, sicher?

Schlüsselfragen

Zunächst ist festzuhalten, dass die letzte Frage im Kern falsch gestellt. Es geht ja letztlich nicht um die Dateien, sondern um deren Inhalte. Die richtige Frage wäre: Sind die Informationen, die (u.a.) in den Dateien hinterlegt wurden, im vorgegebenen Bedrohungsszenario vor dem Zugriff Unbefugter sicher?

Ich nehme die Antwort vorweg: Nein, sie sind es nicht – zumindest nicht ohne eine Reihe von Zusatzmaßnahmen. Das liegt an einer Vielzahl von potentiellen “Schwachstellen”, die sich bereits im Zuge der Entschlüsselung der Dateien auf unserem Laptop ergeben. Bereits für den Server hatten wir ja ansatzweise diskutiert, dass einmal entschlüsselte Datei-Inhalte trotz des späteren Schließens der Datei und trotz des Löschens von evtl. angelegten Kopien im Filesystem erhalten bleiben könnten. Schlüsselfragen sind also:

  • Was machen die Anwendungen, die wir zum Öffnen, Auslesen oder Bearbeiten der Dateien benutzt habe, mit den Datei-Inhalten? Wo verbleiben ggf. Reste entschlüsselter Daten nach Beendigung der Anwendung?
  • Was machen das Betriebssystem, das Desktop-System (KDE, Gnome, …) und die eingesetzten Filesysteme mit den Dateien? Wo verbleiben ggf. Reste entschlüsselter Information?
  • Was macht unsere Hardware mit unseren Dateien? Wo verbleiben ggf. Reste entschlüsselter Information?

Wir können das nachfolgend nur schlaglichtartig beleuchten. Das ist aber schon hinreichend, um unsere Ausgangsthese zu belegen.

Anwendungen als Schwachstelle

Zur Ansicht der (durch Veracrypt) entschlüsselten Datei verwenden wir geeignete Linux-Programme (Editoren, Office-Programme, IDEs etc.). Im Beispiel etwa LibreOffice [LO]. Nun legen die meisten solcher Programme temporär oder gar dauerhaft Kopien der Datei im Originalzustand oder nach vorgenommenen Änderungen an. Das Problem ist, dass diese Kopien i.d.R. nicht im Bereich des gemounteten VC-Datei-Containers landen, sondern in anderen vordefinierten Verzeichnissen, die auch ohne gemounteten Container erreichbar sind. Dort wird die Information aber ohne weitere Maßnahmen unverschlüsselt hinterlegt!

Für LO können dies einerseits Dateien mit Recovery-Informationen (in der Regel die vollständige Datei unter “/tmp” in Ordnern/Dateien mit dem Namen “luxxxxx..” sein. Diese temporären Dateien werden nach dem regulären Schließen der Dateien zwar wieder gelöscht; im Fall eines Crashes verbleiben sie aber. Es gibt zudem auch cache-artig hinterlegte Bilder, die langfristig im /tmp-Verzeichnis verbleiben. Hat man in LO gar die Option zum automatischen Anlegen von Backup-Dateien aktiviert, so finden sich letztere dauerhaft – also auch nach dem Schließen der jeweiligen Dokumente – im vorgesehenen Ordner wieder. Bei mir etwa unter dem Standardverzeichnis “~/.config/libreoffice/4-suse/user/backup/”. Natürlich unverschlüsselt!

Aber auch gezieltes Löschen und ein anschließendes Leeren des Papierkorbs nutzen nichts: Wer einmal versucht hat, gelöschte Dateien in einer Partition zu restaurieren, weiß, dass ein normales Löschen von Dateien überhaupt keine Sicherheit darstellt. Die Inhalte verbleiben lange auf den HDDs oder SSDs, bis sie wirklich überschrieben werden. Je mehr Platz (bei ext4: Inodes) ein Linux-Filesystem hat, desto größer die Wahrscheinlichkeit für ein Verbleiben der Original-Information in Festplatten-Blöcken. Die Chance, gelöschte Dateien oder Fragmente davon teilweise oder gar vollständig wiederherzustellen, ist somit relativ groß.

Aufpassen muss man natürlich auch auf Anwendungen, die mit internen oder extern Versionsverwaltungssystemen kooperieren. Solche Systeme können bei schreibenden Zugriffen u.U. eine automatische Versionierung vornehmen und eine
Serie von unterschiedlichen Dateizuständen im System hinterlegen.

Identifizierte Schwachstellen:
Anwendungen erzeugen typischerweise temporäre und dauerhafte Dateikopien – in unserem Fall unverschlüsselt in Festplatten-Bereichen außerhalb des kryptierten Datei-Containers. Auch nach einem gezielten Löschen solcher Informationen lassen sich die enthaltenen Informationen von Leuten mit physikalischem Zugriff auf die Laptop-Festplatten (HDD/SSD) rekonstruieren. Zu Gegenmaßnahmen s. weiter unten.

Betriebs- und Desktop-Systeme als Schwachstelle

Bei zu geringem RAM beginnt ein Betriebssystem u.U. zu pagen bzw. zu swappen. Auch in diesem Fall landet dekryptierte Information auf der Festplatte. Ein weiteres Übel können in unserem Kontext Desktop-Suchmaschinen (z.B. unter KDE) darstellen, die ggf. automatisch Verzeichnisse, Dateien und deren Inhalte sowie geöffnete Dateien nach Schlagworten scannen. Auch dann landet unverschlüsselte Information dauerhaft auf Festplatten – nämlich in Index-Verzeichnissen oder Datenbanken der Suchmaschinen.

Identifizierte Schwachstellen:
SWAP-Bereiche auf der Platte und Datenbanken von Desktop-Suchmaschinen sind Orte für das potentielle Auffinden entschlüsselter Information.

Eraser-Programme als Gegenmaßnahme?

Wenn man seine Anwendungen sehr gut kennt und weiß, wo überall Datei-Inhalte abgelegt werden, könnte man sich gegen ein Rekonstruieren gezielt gelöschter Information ggf. dadurch absichern, dass man zu Programmen greift, die einen Löschvorgang nicht nur als Freigabe entsprechender Knoten im Filesystem verstehen sondern entsprechende Blöcke tatsächlich mit Nullen oder zufälligen Zeichen überschreiben. Dieses Vorgehen setzt, wie gesagt, voraus, dass man vollständig überblicken muss, welche Anwendungen wo genau Informationen hinterlegen. Und man muss die notwendigen Löschvorgänge auch regelmäßig durchführen.

Nun gibt es zudem Programme, die alle freigegebenen Blöcke einer Festplatte identifizieren und überschreiben können. Auch solche Programme muss man aber regelmäßig laufen lassen – u.a. vor einem Shutdown des Systems. Selbst dann besteht aber immer noch die Gefahr, dass ein Laptop in einem StandBy- oder Hybernation-Zustand verloren geht oder gestohlen wird.

Die Vorstellung, ein gezieltes Löschen und Überschreiben von freigegebenen Speicherblöcken regelmäßig und in typischen Arbeitssituationen rechtzeitig sowie ohne Lücken durchführen zu können, halte ich insgesamt für illusorisch.

Verschlüsselte Partitionen als Lösung?

Das eigentliche Fazit aus den bisherigen Überlegungen ist: Im RAM entschlüsselte und geheimzuhaltende Informationen müssen auf dem Laptop immer in verschlüsselter Form auf die Festplatten gelangen. D.h.:

Alle Partitionen auf den Speichersystemen des Clients sollten vollständig verschlüsselt betrieben werden.

Das muss unabhängig vom Einsatz von verschlüsselten Datei-Containern realisiert werden! Egal, ob letztere lokal oder remote vorliegen. Entscheidend ist, dass das Entschlüsseln und Öffnen von Container-Dateien auf dem Client in unserem Szenario immer zu einer verschlüsselten Ablage von Information auf den Datenträgern des Clients führen muss – egal was die Anwendungen oder das Betriebssystem da genau ablegen wollen.

Systeme mit verschlüsselten Partitionen kann man unter Linux z.B. mit Hilfe LUKS oder eben auch Veracrypt einrichten. Verbunden ist damit typischerweise die Eingabe eines speziellen Codes beim Hochfahren des Systems oder beim Übergang aus einem Hybernation-Zustand in den Normalbetrieb. Erst dann wird die Entschlüsselung der Partitionsinhalte vorgenommen.

Was immer eine Anwendung danach tut: Die Informationen erreichen den Plattencontroller dann nur in verschlüsselter Form (hoffentlich). Wir haben das Prinzip der verschlüsselten VC-
Container, das wir bereits im letzten Artikel betrachtet hatten, inzwischen also auf die Festplatten und dortigen Partitionen des Clients ausgedehnt.

Die richtige Konsequenz aus unseren Sicherheitsanforderungen scheint also zu sein, auf den Clients nicht VC-Container für Datei-Kopien anzulegen, sondern gleich alle Platten bzw. deren Partitionen zu verschlüsseln. Nachdem wir dafür entwickelten Verfahren und Verschlüsselungsverfahren unter Linux vertrauen – sind unsere Informationen nun endlich sicher?

SSDs als Schwachstelle

Tja. Die Antwort auf die letzte Frage könnte eigentlich Ja lauten, wären da nicht sehr unangenehme Eigenschaften von modernen SSDs. Ich will hier gar nicht auf alle Details eingehen (davon verstehe ich zu wenig; s. jedoch die unten angegebenen Links). Aber der entscheidende Punkt scheint mir das Wear-Leveling zu sein, das praktisch alle modernen SSDs aufweisen. Da einzelne Speicherbausteine der SSD jederzeit ausfallen können, ist der tatsächliche Speicherplatz auf SSDs deutlich größer ausgelegt als der nutzbare Netto-Platz. Information, die auf reguläre Speicherblöcke geschrieben wird, wird redundant vervielfacht, um gegen einzelne Ausfälle von Speicherzellen gewappnet zu sein. Die Verwaltung übernimmt dabei der herstellerspezifische, in die SSD verbaute SSD-Controller in autonomer Weise. Der bemüht sich wiederum um einen gleichmäßige Auslastung aller vorhandenen Speicherzellen.

An die intern redundant hinterlegten Informationen kommt man mit Mitteln eines normalen Betriebssystems leider nicht heran. Wohl aber mit Spezialtools für das Auslesen von SSDs. Fazit:
Hast du oder hat dein System irgendwann mal unverschlüsselte Information auf die Platte geschrieben, so weißt du nicht, im welchen und wie vielen Speicherzellen diese Information auf der SSD noch vorhanden ist. Das wiederum bedeutet:

Eine SSD, die man unvorsichtigerweise irgendwann mal unverschlüsselt genutzt hat, enthält womöglich noch zu schützende Informationen in Bereichen, an die man ohne spezielle Mittel gar nicht herankommt. Wohl aber Experten, die physikalische Zugriff auf die SSD erhalten!

Nun gibt es jedoch auch Werkzeuge, die angeblich in der Lage sind, alle(!) Speicherzellen einer SSD zu überschreiben. Genau ein solches Tool müsste man bei einer SSD, die man schon benutzt hat und nun verschlüsseln will, vorab zum Einsatz bringen. Diese Tools sind aber mit Risiken verbunden, nach Auskunft mancher Tester im Internet auch nicht zuverlässig und stressen die SSD in jedem Fall.

Schlussfolgerungen

In unserem Szenario führt die bisherige Diskussion zu folgenden Punkten:

  1. Ein halbwegs sicherer Client erfordert gem. der obigen Anforderungen und Diskussion vollständig verschlüsselte Partitionen aller Festplatten und SSDs.
  2. Am besten verzichtet man auf Clients mit höchsten Sicherheitsanforderungen ganz auf den Einsatz von SSDs. Das ist übrigens die Empfehlung von Experten des BSI wie auch der Veracrypt-Entwickler.
  3. Wenn man SSDs dennoch benutzen will oder muss: An den Controller der SSD dürfen von Anfang an nur verschlüsselte Daten übermittelt werden. Die SSD ist also bereits im jungfräulichen Zustand (Fabrikzustand) ausschließlich mit verschlüsselten Partitionen zu versehen – und auch später dürfen nur verschlüsselte Partitionen hinzukommen.
  4. Zudem gibt es die Empfehlung, dass die (hinreichende lange) Passphrase oder notwendige Keyfiles für den Zugang zu den verschlüsselten Partitionen nicht geändert werden sollten. Der Grund dafür ist, dass ein sicheres Überschreiben der alten Header nicht gewährleistet werden kann. Wird also ein Password/Keyfile kompromittiert, ist es am besten eine neue SSD aufzusetzen, als auf der ursprünglichen SSD alte Passwörter zu ändern.

Ferner gilt: Wird ein Laptop
im nicht heruntergefahrenen Zustand verloren/entwendet, ist diese Situation ohne weitere Maßnahmen kaum besser als bei einem unverschlüsselten System: Es ist lediglich die Sperre des Bildschirmschoners zu überwinden.

Verschlüsselte virtuelle Maschinen als Maßnahme?

Es gibt noch einen weiteren Ansatz, sich zu schützen: Nämlich virtuelle Maschinen auf verschlüsselten Partitionen oder LVM-Volumes anzulegen – und die Datei-Container vom Server nur dort zu öffnen und zu bearbeiten. Dieser Ansatz, bei dem nicht alle Partitionen des Laptops verschlüsselt werden müssten, erscheint mir halbwegs sicher; ich bin aber auch dabei ein wenig skeptisch:

  • Zum einen muss die Abschottung von Host perfekt sein. Wer überblickt das aber schon?
  • Zum anderen darf man Verzeichnisse des Gastes/Hostes nicht im jeweils anderen System nutzen oder Dateien vom Gast zum Host kopieren oder Gastdateien mit Programmen des Hosts auslesen oder öffnen. Ein Mounten von Verzeichnissen des Gastes im Host verbietet sich daher. Aber auch umgekehrt muss man aufpassen.

Die geheimzuhaltenden Dateien dürfen nur und ausschließlich im Gastsystem und mit Programmen des virtuellen Gastsystems geöffnet werden. Sie dürfen nie unter dem Host-System selbst – also hier unter dem Laptop-Betriebssystem – geöffnet werden. Also ist von Samba und NFS zum gegenseitigen Mounten von Verzeichnissen zwischen virtualisiertem Gast und Host abzusehen! Zudem dürfen sich auf den Platten des (Virtualisierungs-) Hosts keine Informationen befinden, die Hinweise auf Passwörter und die Entschlüsselung der Partitionen für den Gast geben.

Setzt man trotzdem auf den Ansatz mit virtualisierten Gastsystemen, weil man auf dem Client nicht alles verschlüsseln will, so ist es wohl am einfachsten, für das Gastsystem ein verschlüsseltes LVM-Volume des Laptops heranzuziehen. Siehe die Links unten.

Fazit

Eine Sicherheit allein durch den Einsatz verschlüsselter Datei-Container gibt es in unserem Szenario nicht. Auch unter Linux nicht! Egal, ob die Container remote auf gehosteten Servern oder lokal vorhanden sind. Vielmehr ist für eine vollständige Verschlüsselung aller Partitionen des Client-Systems zu sorgen, wobei auf den Einsatz von SSDs im Idealfall verzichtet werden sollte.

Wir haben hier nur einen kleinen Teil von Sicherheitsaspekten betrachtet. Das, was wir diskutiert haben, hätte man in ähnlicher Weise aber auch für andere Betriebssysteme aufschreiben können. Sicherheit ist ein weit komplexeres Thema als nur eine Frage des Betriebssystems. Das gute an Linux ist jedoch, dass man hier alle notwendigen Tools zur Verbesserung der Sicherung geheimzuhaltender Information als Opensource Programme und kostenfrei vorfindet.

Also: Verschlüsselt eure geheimzuhaltenden Informationen. Nicht zuletzt, wenn ihr im Auftrag von Unternehmen unterwegs seid! Verlangt euren (Linux-) Admins entsprechende Lösungen ab. Aber hört nicht auf, Sicherheit zu hinterfragen. Sie ist immer relativ! Auch unter Linux!

Links – weitere Infos

Grundlegende Probleme der Verschlüsselung reiner Datei-Container-Verschlüsselung
https://www.computerwissen.de/ it-sicherheit/ web-security/ artikel/ verschluesselte-container-bieten-ihnen-keinen-zuverlaessigen-schutz.html
https://www.cs.washington.edu/ research/ security/ truecrypt.pdf

SSDs mit Wear-Leveling und Sicherheitsprobleme
http://www.zdnet.com/ article/ ssd-security-the-worst-of-all-worlds/
https://www.pcwelt.de/ ratgeber/ Datensicherheit-6581465.html
https://www.computerwoche.de/ a/ die-geheimen-schwaechen-der-ssd,2501912,4
https://www.computerbase.de/ forum/ showthread.php?t=1395284
https://forum.truecrypt.ch/ t/ ssds-not-appropriate-for-encryption/486
https://www.veracrypt.fr/ en/ Wear-Leveling.html
https://www.ghacks.net/ 2011/02/23/ solid-state-drives-and-encryption-a-no-go/
https://debianforum.de/ forum/ viewtopic.php?t=163274
http://news.softpedia.com/ news/ systemd-232-supports-veracrypt-encrypted-partitions-adds-60-improvements-509945.shtml

Performance SSDs – Encryption – TRIM
https://security.stackexchange.com/ questions/ 61089/ can-truecrypt-encrypt-ssds-without-performance-problems
https://www.heise.de/ ct/ hotline/ Linux-Verschluesselte-SSD-trimmen-2405875.html
http://mgessat.com/ verschluesselungssoftware-veracrypt-unabhaengige-ueberpruefung-abgeschlossen/
http://media-addicted.de/ ssd-and-truecrypt-durability-and-performance-issues/744/
http://asalor.blogspot.de/ 2011/08/ trim-dm-crypt-problems.html

Sicheres Löschen von Files auf konventionellen HDDs mit Wipe
[funktioniert nicht mit Flash-Speichern/SSDs]
https://superuser.com/ questions/ 19326/ how-to-wipe-free-disk-space-in-linux
https://tails.boum.org/ doc/ encryption_and_privacy/ secure_deletion/ index.en.html
https://wiki.ubuntuusers.de/ Daten_sicher_l%C3%B6schen/
https://www.cyberciti.biz/ tips/ linux-how-to-delete-file-securely.html

Vollständiges Löschen von SSDs?
https://wiki.ubuntuusers.de/ SSD/ Secure-Erase/
http://www.pc-magazin.de/ ratgeber/ festplatte-restlos-loeschen-sicher-saeubern-ssd-secure-erase-anleitung-hdd-3196204.html#
https://wiki.ubuntuusers.de/ SSD/ Secure-Erase/

Bereinigen des RAMs, Caches, SWAP spaces
https://www.tecmint.com/ clear-ram-memory-cache-buffer-and-swap-space-on-linux/

LVM und verschlüsselte Volumes
https://debianforum.de/ forum/ viewtopic.php? f=12&t=127012

KVM Gastsysteme auf verschlüsselten Volumes
https://www.ibm.com/ support/ knowledgecenter/ en/ linuxonibm/liaat/liaatkvmsecencrypt.htm
https://www.ibm.com/ support/ knowledgecenter/ linuxonibm/liaat/ liaatsecurity_pdf.pdf
https://security.stackexchange.com/ questions/ 20334/ memory-dumping-cause-for-concern-in-virtualization
https://forums.whonix.org /t/ how-useful-is-in-guest-encryption/1253
https://security.stackexchange.com/ questions/ 29535/ full-disk-encryption-within-a-vm-how-secure-is-it/29538#29538

Ein paar Aspekte von LUKS
https://wiki.ubuntuusers.de/ LUKS/ Containerdatei/
https://www.pcwelt.de/ ratgeber/ Ausgesperrt_ _Luks_mit_ Ersatzschluessel_ oeffnen-Linux-8664088.html
http://www.bocekm.com/ enlarge-luks-encrypted-logical-volume/

Backups mit LUKS und SSHFS
https://ruderich.org/ simon/ notes/ encrypted-remote-backups

Veracrypt, SSHFS und kryptierte Datenhaltung auf gehosteten Servern – I

Posted on by

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:

  1. 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.
  2. Anforderung 2: Verschlüsselung des Transportwegs zum und vom Server.
  3. Anforderung 3: Entschlüsselung der Daten nur auf dem Client.
  4. 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:

  1. Unmounten des Veracrypt-Containers vom Verzeichnis “/home/myself/mnt_vc_srv”. Dies macht man am besten über das VC-Interface.
  2. 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.

r

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.

Links

Veracrypt
https://en.wikipedia.org/ wiki/ VeraCrypt
http://www.deutschlandfunk.de/ verschluesselungssoftware-veracrypt-unabhaengige.684.de.html?dram:article_id=369309
https://www.computerbase.de/ 2016-10/ truecrypt-alternative-veracrypt-audit/
http://www.linux-magazine.com/ Online/ Features/ VeraCrypt

Audit Report zu Veracrypt
https://ostif.org/ wp-content/ uploads/ 2016/10/ VeraCrypt-Audit-Final-for-Public-Release.pdf
https://www.golem.de/ news/ truecrypt-nachfolger-veracrypt-audit-findet-schwerwiegende-sicherheitsluecken-1610-123893.html

LUKS
https://wiki.ubuntuusers.de/ LUKS/ Containerdatei/

SSH mit Key Files
https://www.digitalocean.com/ community/ tutorials/ how-to-configure-ssh-key-based-authentication-on-a-linux-server
https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html
https://wiki.mozilla.org/ Security/ Guidelines/ OpenSSH

FUSE
https://de.wikipedia.org/ wiki/ Filesystem_in_Userspace

SSHFS
https://wiki.archlinux.de/ title/ Sshfs
https://wiki.archlinux.org/ index.php/ SSHFS
https://www.heise.de/ ct/ artikel/ Toolbox-Dateizugriffe-mit-sshfs-1646679.html
https://www.linode.com/ docs/ networking/ ssh/ using-sshfs-on-linux

SSHFS mit Identityfile
https://unix.stackexchange.com/ questions/ 61567/ sshfs-specify-key
https://stackoverflow.com/ questions/ 22393502/ how-do-i-specify-the-key-file-for-sshfs

Cloud-Definition
https://www.cloud.fraunhofer.de/ de/ faq/ publicprivatehybrid.html

Strato HiDrive
http://cloudlist.de/ dienst/ strato-hidrive-test/
https://strato.de/ blog/ 3-truecrypt-alternativen-fuer-
hidrive/