Verschlüsselung und Benutzerordner

[zxmc]

Hallo zusammen

habe gerade eine DS218j zum Ausprobieren da und mir ist noch immer nicht klar, ob das Gerät das kann, was ich suche (und wie ich das dann einrichten müsste...)

Zum Hintergrund: ich arbeite zeitweise freiberuflich von Zuhause und verarbeite dabei auch gelegentlich (wirklich!) sensible Daten Dritter. Das Bedrohungsszenario das mich konkret interessiert ist daher "Diebstahl des NAS" bzw. "Beschlagnahme des NAS durch Strafverfolgungsbehörden" d.h. mit Trennung der Stromversorgung aber ohne irgendwelche Faxen auf Geheimdienst-Niveau (RAM tiefkühlen und auslesen etc.).

Bisher liegen solche Daten aus historischen Gründen auf einem alten Windows-Rechner, dessen Platten mit TrueCrypt bzw. später dann mit VeraCrypt verschlüsselt sind. Damit war das konkrete Problem bislang gelöst: nach Unterbrechung der Stromversorgung kommt man an den Inhalt der Platten nur mit der Passphrase ran. Etwas Vergleichbares lässt sich wohl auf einer DS nicht machen, oder?

1a.) Wenn ich das richtig verstehe, lassen sich "gemeinsame Ordner" verschlüsseln. Zumindest bei aktiviertem Auto-Mount liegt der Key aber auf dem NAS und bei jedem Start ist so ein Ordner dann wieder "offen". Die Sicherheit besteht in so einem Fall also nur über die Benutzerberechtigung. Ist das so? Und wird bei deaktiviertem Auto-Mount dann kein Key auf dem NAS mehr gespeichert? Gibt es zu dem dahinter stehenden Sicherheitskonzept irgendwo eine Doku?
1b.) Wenn man kein Automount von verschlüsselten Ordnern macht und stattdessen manuell einghängt: erfolgt dann ein unmount, wenn die DS über die Energiesparoptionen "herunterfährt" bzw. ist nach einem WoL ein zuvor manuell eingehängter verschlüsselter Ordner wieder da oder getrennt?

2.) Weiterhin gibt es einfache "Ordner" (damit sind wohl Benutzer-Ordner gemeint - ist mir noch immer nicht klar, was das sonst sein sollte und wie sie sich von "gemeinsamen Ordnern" in technischer Hinsicht unterscheiden). Diese Ordner sind nach meinem Verständnis grundsätzlich unverschlüsselt und nur über die Benutzerberechtigungen geschützt. Bedeutet das, dass jemand der die Platten aus dem NAS ausbaut und an ein anderes (Linux-)System hängt, vollen Zugriff auf die einfachen Ordner erhält?

Oder gibt es andere DS-Modelle, die für das genannte Bedrohungsszenario einfach besser geeignet wären?

Grüsse

 

[peterhoffmann]

Die Sicherheit besteht in so einem Fall also nur über die Benutzerberechtigung. Ist das so?

Ja.

Und wird bei deaktiviertem Auto-Mount dann kein Key auf dem NAS mehr gespeichert?

Nein.

erfolgt dann ein unmount, wenn die DS über die Energiesparoptionen "herunterfährt"

Ich nehme an, dass du damit den HDD-Ruhezustand meinst. Dann erfolgt kein unmount.

ist nach einem WoL ein zuvor manuell eingehängter verschlüsselter Ordner wieder da oder getrennt?

Ich habe es nicht probiert, da ich kein WOL nutze. Vom Verständnis würde ich sagen, dass er da ist, da das System ja nur schläft. Fazit: Einfach mal probieren (Feedback ist erwünscht!).

meinem Verständnis grundsätzlich unverschlüsselt und nur über die Benutzerberechtigungen geschützt. Bedeutet das, dass jemand der die Platten aus dem NAS ausbaut und an ein anderes (Linux-)System hängt, vollen Zugriff auf die einfachen Ordner erhält?

Solange etwas unverschlüsselt ist, hat man so vollen Zugriff.

Oder gibt es andere DS-Modelle, die für das genannte Bedrohungsszenario einfach besser geeignet wären?

Im Schreiben füllt die DS218j nicht die volle Gigabitgeschwindigkeit aus, wenn der Ordner verschlüsselt ist.
Siehe hier: https://www.synology.com/de-de/products/performance#1_2bay
Teste das mal aus, ob dir die Geschwindigkeit beim Lesen und Schreiben in verschlüsselten Ordnern grundsätzlich reicht. Speziell bei vielen kleinen Dateien könnte das etwas langatmiger werden.
Ansonsten mal die DS218+ anschauen.

 

[peterhoffmann]

Ansatz:
Es gibt mehrere Ansätze die Entschlüsselung beim Start automatisiert zu vollziehen, aber beim Diebstahl/Mitnahme dies zu verhindern.

Beispiel:
Man zerlegt das Passwort (123456789) in mehrere Teile (123+456+789) und legt die Teile in verschiedenen Bereichen ab.

Dabei kommen u.a. in Frage:

1. externer Webserver
2. USB-Stick (mit langem Kabel an der DS)
3. Freigabe im eigenen Netzwerk (z.B. Fritzbox, PC, Raspi, usw.)

Beim Start lässt man durch ein Script die Teile zusammensuchen, zusammensetzen und entschlüsseln.

Nehmen wir an, die DS wird aus dem Netzwerk genommen, fehlt mindestens der Teil vom Passwort, der nur intern im eigenen Netzwerk zur Verfügung steht. Wenn man dann noch das PW auf dem externen Webserver löscht, fehlt schon der zweite Teil. Wenn dann noch das Kabel mit dem USB-Stick nicht mitgenommen wurde, fehlt auch Teil3.

Gedanken zum Verstecken:
Raspi über WLAN: Der ist seitens Netzwerkkabel unabhängig und kann so gut versteckt werden, benötigt nur Strom (2 Watt, ca. 5 Euro im Jahr)
USB-Stick: sehr kleines Modell, versteckt im Kabelwust, Kabelschacht vom Schreibtisch, verkabelt hinterm Schrank
externer Webserver: Zusätzlich könnte man z.B. mittels PHP den (richtigen) Teil vom Passwort nur in einem festen Zeitfenster zur Verfügung stellen

Extremversion:
Auf der Synology ein verschlüsselter Ordner in dem ein Truecrypt/Veracrypt-Container liegt, der nur bei Bedarf geöffnet wird.

 

[zxmc]

Danke für die Rückmeldungen. Es ist in der Oberfläche der DS alles nicht so ganz intuitiv und miteinander verbunden (und auch die Texte in den Dialogen sind nicht immer so ganz klar), aber im Prinzip hab ich jetzt wohl alles zusammen:

- ich verwende ausschließlich Shared Folders
- die werden verschlüsselt
- Keymanager wird verwendet und zwar auf externem USB-Gerät mit Auto-Mount.

Das USB-Gerät für den Key-Manager ist eine Micro-SD-Karte in einem Card-Reader. Etwas blöd an der DS218j ist dabei, dass die USB-Anschlüsse vom Stromstecker fast blockiert werden der Card-Reader (im USB-Stick-Form) nicht direkt angesteckt werden kann. Dann eben mit USB-Verlängerungskabel... Der Stick wird nur zum Start der DS gesteckt und nach dem Hochfahren automatisch ausgeworfen. Dann kann man das Gedöns abziehen und die Mirco-SD wieder an einem sicheren Ort aufbewahren. Geht die SD kaputt oder verloren, lassen sich die verschlüsselten Ordner noch immer über Passphrase bzw. Schlüsseldatei "zu Fuss" mounten und ein neuer Keymanager einrichten.

Im HDD-Standby sollten die verschlüsselten Ordner eigentlich nicht getrennt werden, beim "automatischen Ausschalten" der DS (in den Energieoptionen) vermutlich schon (muss ich noch testen), so dass ein WoL dann wohl keinen Sinn mehr macht. Aber das muss ich halt nochmal wirklich ausprobieren.

 

[zxmc]

wie erwartet: Die DS kennt nur drei Zustände: 1.) DS an und Platten an 2.) DS an und Platten aus 3.) DS ganz aus. Bei 1.) und 2.) bleiben verschlüsselte Ordner geöffnet, bei 3.) eben nicht. Wird die DS aus dem Zustand 3.) per WoL geweckt, muss ein (Auto-)Mount erfolgen, sonst sind verschlüsselte Ordner nicht da.

Leider lässt sich der Keystore des Schlüsselmanagers nur auf der DS-Systempartition oder einem USB-Gerät einrichten. Optimal für mich wäre der Keystore auf einem (S)FTP-Speicherplatz - aber das scheint nicht vorgesehen zu sein.

 

[peterhoffmann]

Bei 1.) und 2.) bleiben verschlüsselte Ordner geöffnet, bei 3.) eben nicht.

Danke für die Info.

Leider lässt sich der Keystore des Schlüsselmanagers nur auf der DS-Systempartition oder einem USB-Gerät einrichten.

Einerseits wegen diesen Einschränkungen, sowie auch wegen dem Schlüsselmanager selber (fremde Software), nehme ich ihn nicht. Wer weiß, was der für Hintertüren wiederum hat.

Beim Zusammenbauen vom Passwort per Script kann man beliebige Quellen nehmen, alles eine Frage wie man die Quellen über die Konsole ansprechen und auslesen kann. Und dabei bleibt alles (nur für dich) transparent, sprich es kommt keine Software wie der Schlüsselmanager zum Einsatz.

 

[zxmc]

Beim Zusammenbauen vom Passwort per Script kann man beliebige Quellen nehmen, alles eine Frage wie man die Quellen über die Konsole ansprechen und auslesen kann. Und dabei bleibt alles (nur für dich) transparent, sprich es kommt keine Software wie der Schlüsselmanager zum Einsatz.

gibt es dazu eine Anleitung für Nicht-Linuxer? Am besten mit dem einen oder anderen Musterbeispiel? Eigene Domain ist vorhanden, eine lokale Fritzbox und ein Raspi Zero (Pi-hole) auch. Im Prinzip müsste damit ja etwas gehen. Genau genommen wäre mir eine Abholung der (Teil-)Schlüssel vom Android-Smartphone z.B. per (s)ftp am Liebsten: wer das Gerät nicht hat und nicht entsperrt bekommt, der könnte den lokalen Smartphone-ftp-Server nicht starten und auch sonst nicht auf die Schlüssel zugreifen.

 

[peterhoffmann]

Das hier sollte für den ersten Start ausreichen:
https://www.synology-forum.de/showt...ger-geht-nicht&p=714057&viewfull=1#post714057
Ansonsten auch die Suchfunktion vom Forum mit "synoshare" füttern.

Ein Weg mit (s)ftp müsste auch möglich sein. Auf den ersten Blick: mit "wget" die Datei über FTP holen, auslesen und wieder löschen. Das hätte nur den Nachteil, dass man die Datei "schreibt" und sie damit wiederherstellbar sein könnte. Aber eventuell gibt es auch einen Weg die Datei gar nicht abzulegen, sondern direkt auszulesen. Denkbar wäre auch die Datei bzw. deren Inhalt sicherheitshalber zu überschreiben.

Hier der Weg um den Inhalt einer Datei von einem Webserver zu ziehen (z.B. externe Domain, Pihole, Webserver auf dem Handy, usw.):

pwteilX=$(curl -k http://www.domain.tld/dateiname.txt)

Wenn du das alles hinbekommen hast, bau im Script noch ein kurzes "sleep" ein, siehe hier:
https://www.synology-forum.de/showt...ner-werden-beim-Start-nicht-immer-eingebunden

 

[zxmc]

Danke, das sieht doch alles sehr machbar aus. Und wenn auf dem Smartphone ohne Root auch ein Webserver lauffähig ist (hatte bislang nur FTP geprüft und für möglich befunden), dann wäre das wohl das Einfachste.

 

[zxmc]

so, im Prinzip läuft es - nach einigen Mühen:

- das Passwort darf nur max. 64 Zeichen lang sein, was die zusammengesetzten PW etwas einschränkt (die Kette ist nur so stark wie das schwächste Glied...) Gegen gewöhnliche Diebe ist das kein Problem, bei einem kriminaltechnischen Institut wäre es schon problematisch, wenn Teile des PW bekannt werden und nur noch ein schwacher Rest fehlen würde
- Verwendet man ein PW mit 64 Zeichen, kann man keinen Exportschlüssel mehr erstellen. Das mag unter kryptographischen Aspekten auch tatsächlich überflüssig sein (weil in dem Fall möglicherweise der Exportschlüssel mit dem PW identisch wäre), aber wenn man es trotzdem versucht (die Optionen sind nicht ausgeblendet), dann erhält man bei der notwendigen Eingabe des Passworts die irreführende Fehlermeldung, dass das eigene PW nicht korrekt sei.

Wirklich zufrieden bin ich allerdings nicht - aus meiner Sicht gibt wohl eine klare und nicht behebbare Schwachstelle bei den DS: ein Reset des Admin-Passworts ist offenbar nicht mit einem Unmount verschlüsselter Ordner bzw. Neustart des Systems verbunden. Bei einem Angreifer, der a.) weiß, dass ein Synology-NAS existiert und der es b.) nicht auf die Hardware, sondern auf die Daten abgesehen hat, genügt es, wenn dieser sich im laufenden Betrieb mit gemounteten verschlüsselten Ordnern Zugang zum NAS verschafft, das Admin-PW zurücksetzt, sich als Admin einloggt und dann die Verschlüsselung der verschlüsselten Ordner deaktiviert (dazu ist kein weiteres PW mehr nötig). Danach kann er die DS ausschalten, nach Hause tragen und in aller Ruhe alle Daten auswerten. Oder übersehe ich da etwas, was so ein Vorgehen verhindern könnte?

 

[Fusion]

Wenn du das getestet hast, dann ist es ein Bug. Die Ordner sollten beim Zurücksetzen ausgehängt werden.
https://www.synology.com/de-de/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS

 

[peterhoffmann]

- das Passwort darf nur max. 64 Zeichen lang sein, was die zusammengesetzten PW etwas einschränkt (die Kette ist nur so stark wie das schwächste Glied...) Gegen gewöhnliche Diebe ist das kein Problem, bei einem kriminaltechnischen Institut wäre es schon problematisch, wenn Teile des PW bekannt werden und nur noch ein schwacher Rest fehlen würde

Nehmen wir an, dass du die 64 Zeichen voll nutzt und in 4 Teile zerlegst. Dann hast du PWs mit jeweils 16 Zeichen.
Nehmen wir an, du nutzt das abc und ABC (2x26), 10 Ziffern und 10 Sonderzeichen. Damit sind wir bei 72 Zeichen.
72 hoch 16 => 521'578'814'501'447'328'359'509'917'696
Lässt du die Sonderzeichen weg, sind es noch 62 hoch 16 => 47'672'401'706'823'533'450'263'330'816

Zerleg das Passwort nur in drei Teile und es wird noch viel unübersichtlicher:
62 hoch 21 => 4,3674252383913877424036476406215e+37
Egal wie, da ist ein "kriminaltechnisches Institut" immer machtlos.

- Verwendet man ein PW mit 64 Zeichen, kann man keinen Exportschlüssel mehr erstellen.

Ich nehme an, dass du die key-Datei meinst. Die ist sowieso nur das Passwort (verschlüsselt). Der Schlüssel um eine Keydatei auszulesen ist ein paar Leuten (inkl. mir) bekannt. Die Keydatei ist damit obsolet und nur ein zusätzliches Sicherheitsrisiko.

ein Reset des Admin-Passworts ist offenbar nicht mit einem Unmount verschlüsselter Ordner bzw. Neustart des Systems verbunden.

Wie Fusion schon anführte: Wenn das so ist, ist das ein (böser) Bug. Mir war das bisher nicht bekannt, aber ich muss zugeben, dass ich es noch nie getestet habe.
Hast du das selbst getestet?

 

[zxmc]

Mit dem Admin-Reset habe ich mich auf die Auflistung unter https://www.synology-wiki.de/index.php/Durchführung_eines_Reset_am_Gehäuse und https://synoguide.com/2014/07/30/reset-admin-password-synology/ verlassen. Sieht so aus, als ob früher kein Unmount erfolgte, aber bei einer aktuellen DSM Version wohl schon. Ich werde es trotzdem nochmal selbst testen und melde mich dann nochmal.

Hinsichtlich der anderen Punkte: ja, unter dem Strich kein ernsthaftes Problem. Aber trotzdem lästig, wenn man es nicht vorher weiss: n Passwörter mit Standard-Einstellungen im Passwortmanager erzeugt, eingerichtet und danach festgestellt, dass die Länge überschritten ist... Zum Glück kannte ich die weiteren Einschränkungen bei Passwörtern schon vorher (= : , ).

Nachtrag: zu DSM Version: 5.0-4458-2:
"Fixed a security issue causing encrypted shared folders to be mounted automatically after resetting the admin's password by pressing the reset button."

Sollte aktuelle Geräte bzw Geräte mit aktuellem System also nicht mehr betreffen.

 

[zxmc]

also: getestet und für gut befunden - bei einem Rücksetzen des Admin-PW werden verschlüsselte Ordner tatsächlich getrennt.

 

[peterhoffmann]

Super.

 

[zxmc]

zum (hoffentlich) Abschluss der Sache:

- testweise hab ich versucht, "homes" und alles drunter zu verschlüsseln (etwas blöd, dass dann alle Benutzerverzeichnisse mit einem Schlüssel verschlüsselt werden müssen und man das im Standard nicht trennen kann).
- Prompt die Fehlermeldung über zu lange Datei- bzw. Verzeichnisnamen bekommen und mich drüber geärgert, dass die DS mir nicht sagt, welche konkreten Dateien bzw. Ordner das Problem verursachen.
- über Google auf

find . -type f | grep -E "^(.+)/[^/]{127,}$"

gestoßen und die problematischen Dateien und Ordner identifziert (ausnahmslos aus dem Browser gespeicherte Webseiten) und gelöscht bzw. umbenannt
- dann lief es. Oder besser gesagt: läuft es. Dauert ja ein Weilchen. Wobei es so aussieht, als ob für das Verschlüsseln zunächst eine verschlüsselte Kopie der gesamten zu verschlüsselnden Daten angelegt wird - es muss also noch mal mindestens so viel Platz auf der DS sein, wie der gesamte zu verschlüsselnde Ordner benötigt...

 

[peterhoffmann]

Wobei es so aussieht, als ob für das Verschlüsseln zunächst eine verschlüsselte Kopie der gesamten zu verschlüsselnden Daten angelegt wird - es muss also noch mal mindestens so viel Platz auf der DS sein, wie der gesamte zu verschlüsselnde Ordner benötigt...

Beim nachträglichen Verschlüsseln ist genau das das Problem.

 

[zxmc]

etwas misslich ist , dass das Schlüssel-zusammensuchen-und-mounten-Skript zwar bei einem Start des ausgeschalteten NAS problemlos durchläuft, aber bei einem Re-Start nicht. Lustigerweise wird das Skript beim Re-Start ausgeführt und es ruft auch die Schlüsselteile ab. Nur das Mounten klappt dann aus unerfindlichen Gründen nicht.

Noch jemand mit diesem Problem oder vielleicht sogar einer Lösung?

 

[peterhoffmann]

Ich kann dein Script von hier aus schlecht sehen. *augen-anstreng*

Grundsätzlich habe ich festgestellt, dass beim Entschlüsseln von mehreren Ordnern manchmal welche nicht entschlüsselt werden. Daher habe ich ein Sleep (sleep 10) in die Schleife eingebaut. Ab da funktionierte es zuverlässig (fast 20 gemeinsame Ordner).

 

[zxmc]

das Skript läuft auf dem nachfolgenden Muster. Das Skript läuft auch beim Re-Start (sehe ich an den Logs der Webserver) und produziert auch die korrekten PW (geht ja auch nicht anders, denn beim Start vom ausgeschalteten NAS klappt es ja auch).

#!/bin/bash
# Zielverzeichnis: /usr/local/etc/rc.d
# Dateiname (beliebig; zum Beispiel:) start.sh
# Rechte: chmod 755 start.sh
# Verschlüsselungs-Passwort = Verzeichnisname+Passwortstamm
# Skript setzt voraus, dass das entsprechende Verzeichnis bereits existiert und mit dem entsprechenden Passwort verschlüsselt wurde (i.d.R. über die Weboberfläche der DiskStation). 

#120 Sekunden warten auf NAS (kann zum Testen bei laufendem System verkürzt werden auf 1)
sleep 120

#Verschluesselte Verzeichnisse (kann quasi beliebig ergänzt werden); keine Pfadangaben verwenden
i1="eBooks"
i7="test"

#Gedenkpause
sleep 10

#Teilschluessel einsammeln aus drei Quellen, kann im Prinzip beliebig verkürzt oder ergänzt werden
j1=$(curl -k https://xxx)
j2=$(curl -k https://xxx)
j3=$(curl https://xxx)

#Passwort-Stamm zusammensetzen
pw=$j1$j2$j3

#Passwortstamm anzeigen lassen (zum Testen; danach auskommentieren)
#echo $pw

# Verzeichnisse mounten
synoshare --enc_mount $i1 $i1$pw
synoshare --enc_mount $i7 $i7$pw

# Nochmal sacken lassen
sleep 10

# Variablen loeschen
unset pw
unset j1
unset j2
unset j3

Bei einem Start vom ausgeschalteten System werden zuverlässig alle Ordner (bei insgesamt 5) entschlüsselt und eingehängt. Beim Warmstart zuverlässig gar keiner.