Frage zur Verschlüsselung von Ordnern

[itari]

Nun habe ich das "Gemeinsame Verzeichnis" auf der Synology geloescht und eine Wiederherstellung gestartet.
Das einzige, was danach wieder da ist, ist der gemeinsame Folder mit allen Rechten und Verschluesselung - er ist allerdings leer.
Hat jemand eine Erklaerung?

Das (leere) Verzeichnis (gemeinsamer Ordner) muss existieren für einen Wiederherstellung. Probiere es noch einmal aus.

Itari

 

[jahlives]

Ja davon hab ich auch schon gehört, aber ich glaube, dass das ins Reich der Legenden gehört. Oder hast irgendwo ne Beschreibung dazu gefunden?

Itari

Et voilà das Ergebnis der Versuche der Uni Princeton: http://citp.princeton.edu/pub/coldboot.pdf
Bei einer Kühlung der RAMs auf -196 Grad seien nach 60min noch 99.83% der Bits korrekt und auslesbar im RAM. Wohlgemerkt im RAM ohne das der Computer läuft

 

[pit070166]

Das (leere) Verzeichnis (gemeinsamer Ordner) muss existieren für einen Wiederherstellung. Probiere es noch einmal aus.

Itari

Habe jetzt nochmal ein wenig gespielt und Folgendes erfahren:

- Sichern verschlusselten Verzeichnisses "Test" nach Amazon S3
- Dieses Verzeichnis auf der Synology geloescht
- Von Amazon S3 wiederhergestellt: Der Ordner und seine Einstellungen (incl. "Automatisch anhaengen") sind wieder da - aber leer.
- Neustart der Synology: "Automatisch anhaengen" ist nicht mehr gesetzt, aber alle zuvor gesicherten Files sind wieder da.

Viele Gruesse
Pit

 

[itari]

Et voilà das Ergebnis der Versuche der Uni Princeton: http://citp.princeton.edu/pub/coldboot.pdf
Bei einer Kühlung der RAMs auf -196 Grad seien nach 60min noch 99.83% der Bits korrekt und auslesbar im RAM. Wohlgemerkt im RAM ohne das der Computer läuft

Was lernen wir daraus, lege nur verschlüsselt Schlüssel im RAM ab

Itari

 

[Heatseeker]

Naja im RAM könnte man den Schluessel schon ablegen, aber dann müsste der RAM auch nach dem Abschalten mit Stromversorgt werden, damit sich die Zellen refreshen. Das frisst dann schon etwas mehr Strom. Das mit dem Swapen seh ich nicht als so großes Problem, da ich glaube (!), dass man bestimmte RAM-Bereiche als nicht "swap-bar" markieren kann, oder irre ich mich da.

Dass da nun der gemeine Einbrecher nun mit einer Kanne flüssigem Stickstoff durch die Gegend rennt und erstmal meine DS einfriert sehe ich persönlich nun nicht als eine sooooo große Gefahr...

 

[itari]

Das mit dem Swapen seh ich nicht als so großes Problem, da ich glaube (!), dass man bestimmte RAM-Bereiche als nicht "swap-bar" markieren kann, oder irre ich mich da.

Das ist - glaube ich - beim tmpfs nicht wirklich möglich. Auch sonst sind solche Annahmen nicht immer realisiert ... Das Setzen von Sticky Bits hat eher historische Bedeutung und macht auch nicht unbedingt das, was wir hier diskutieren.

Itari

 

[jahlives]

Was lernen wir daraus, lege nur verschlüsselt Schlüssel im RAM ab

Und wie entschlüsselst du den Schlüssel? Wenn das automatisiert geschehen soll, dann muss das PW für den Schlüssel irgendwo unverschlüsselt stehen

 

[itari]

Und wie entschlüsselst du den Schlüssel? Wenn das automatisiert geschehen soll, dann muss das PW für den Schlüssel irgendwo unverschlüsselt stehen

Den merkt sich der Prozi halt in der Encryption-Unit in einem dafür vorgesehenen Register und falls es das nicht gibt, ist es halt dumm gelaufen und der Schlüssel muss jedesmal neu entschlüsselt werden und du musst halt das Passwort immer wieder neu eingeben

Itari

 

[goetz]

Hallo,
ich möchte mich noch mal wiederholen:

Frage ist, was passiert beim einfachen Reset, Admin-Zugang ist wieder frei, bleiben die eingehängten Verzeichnisse, ist der importierte Schlüssel noch da?

Wer testet es?

Gruß Götz

 

[Trolli]

Ohne Neustart oder mit Neustart bei automatischem Einhängen?

EDIT: Meine Prognose:
Ohne Neustart bleibt das Volume einfach eingehangen. Der Reset setzt nur das Kennwort und die Netzwerkeinstellungen zurück. Warum sollte es auch anders sein? Schlimm wäre es, wenn man dann ohne weitere Eingabe den Schlüssel exportieren könnte. Das ist aber nicht möglich, dazu muss man den Schlüssel erneut eingeben.

Auch das automatische Einhängen wird wahrscheinlich davon unberührt bleiben. Ist halt eine riesen Sicherheitslücke wie das automatische Einhängen insgesamt. Meiner Meinung macht eine Verschlüsselung bei automatischem Einhängen eh keinen Sinn. Das kann man sich dann auch ganz sparen.

 

[jahlives]

Meiner Meinung macht eine Verschlüsselung bei automatischem Einhängen eh keinen Sinn. Das kann man sich dann auch ganz sparen.

Full ack. Da kann man es gleich unverschlüsselt lassen

 

[pit070166]

naja - falls ich als relativ unbedarfter User-Only auch mal was sagen darf - so schlimm finde ich es nicht.
Vor der Verschluesselung habe ich ja auch alle meine Daten auf der Synology gehabt und gehofft, dass niemand sie klaut.
Ich freue mich drueber, dass ich jetzt meine Daten nach ausserhalb des Hauses sichern kann - sei es Amazon oder auch die Synology eines Freundes.
Oder bin ich da zu blauaeugig, was die Sicherheit angeht?

Viele Gruesse
Pit

 

[modchris]

Uralter Thread, ich weiß, aber Thema ist ja weiterhin aktuell und ich habe auch ein Verständnisproblem mit der Verschlüsselung.

Wenn der verschlüsselte Ordner nun dauerhaft gemounted ist (NAS läuft 24/7), sind die Daten wie schon erwähnt grundsätzlich gegen Diebstahl sicher wenn die Platten komplett geklaut werden (kann ja durchaus passieren). Wenn sich nun aber jemand über das Internet (wie auch immer) "reinhackt" hab ich keine Chance oder? Dann sind die Ordner quazi offen? Ich hatte gehofft hier eine weitere Hürde zu schaffen für diesen Fall. Mir geht es speziell um ein paar sensible Daten, die unbedingt geschützt werden müssen, habe halt Angst dass über FTP oder so BruteForce Attacken gestartet werden und dabei evtl. das Passwort geknackt wird oder vielleicht sogar eine Sicherheitslücke existiert und ich dann ohne Hose dastehe...

Hatte mir das eigentlich so vorgestellt, dass wenn ich einen verschlüsselten Ordner öffne, dass ich das separate Passwort eingeben muss, also quazi über Windows gemounted wird und beim Schließen des Explorers oder so wieder der Ordner unmounted wird.

Fällt euch ne andere Lösung ein? Sonst würde ich fast schon dazu tendieren die Daten per Winzip mit einem Passwort zu versehen.

 

[Puppetmaster]

Wenn du solch sensible Daten hast, kann der Rat nur lauten, die DS die die Daten enthält nicht im Internet verfügbar zu machen.
Alternativ könntest du auch noch so etwas wie einen Truecrypt-Container in Betracht ziehen. Der liegt immer verschlüsselt auf der DS und wird am Client dann entschlüsselt.

 

[AtomicOne]

Nun möchte ich diesen Ur-Uralten Thread erneut herauskramen ...
Ich würde nämlich auch gerne die Verschlüsselung einsetzen.
Aber ich würde das ganze gerne auch auf "user-ebene" machen.
Ich finde nämlich nur verschlüsselte "Gemeinsame-Ordner" aber keine Option das die User ihre home-ordner oder Unterordner dieser verschlüsseln können.

Und gemeinsame Ordner kann nur ein Admin einhängen.
(die auto-mount Funktion ist eh Kappes)
Das bedeutet ja dass jeder der die Verschlüsselung nutzen möchte Admin-Rechte benötigt um über das Web-Interface die Ordner einzuhängen.
Zusätzlich finde ich das Einhängen über das Webinterface extrem lässtig.
Ich hätte ja kein Problem damit jedes mal das Passwort einzugeben.
Aber sich dafür jedes mal über das Webinterface anzumelden ...

Ich stelle mir die Lösung folgendermaßen vor:

Eine kleine App die Client-Seitig installiert ist ermöglicht das mounten eines verschlüsselten Ordners (egal ob Gemeinsam oder im Home-Ordner).
Zusätzlich hätte ich das ganze gerne über einen Time-Out gesteuert.
Wenn die App nach X-Sekunden / Minuten kein "keep-alive" mehr sendet wird der Ordner automatisch ausgehängt.
Somit kann man es nicht vergessen falls man mal schnell los muss und einfach den Laptop zuklappt ohne zuvor den Ordner auszuhängen.
Zusätzlich könnte die App die Möglichkeit bieten die entsprechenden Ordner direkt in Windows zu mappen.
Dann hätte man eine Funktionsweise analog zu dem angeblich nicht mehr sicheren TrueCrypt.

Ich weiß dass es eine Möglichkeit gibt die entsprechenden Ordner per shell / ssh zu mounten.
Ich bastle bereits an entsprechenden Scripten bzw. einer GUI für Windows.
Falls sich daran jemand beteiligen möchte und gute Ideen hat ...

Parallel habe ich das ganze mal an Synology geschickt.
Vielleicht machen sie ja etwas daraus.
Sicherheit und Verschlüsselung wird ja immer wichtiger (auch wenn man das Gefühl bekommt eh machtlos zu sein...).

 

[Online78]

Hallo AtomicOne

wie sieht es aus, konntest du an deinem Projekt etwas arbeiten? Hast du Lösungen? Ich selber finde deine Idee gut. Lass mal hören ;-)

Gruss Online78

 

[AtomicOne]

Leider hatte ich Beruflich sehr viel zu tun in letzter Zeit und bei meiner DS211j war das ganze auch nur bedingt interessant.
Da ich mir aber eine DS1815+ zu zulegen gedenke wird das ganze wieder interessanter.

Über ein Shell-Kommando via SSH habe ich das schon erfolgreich hinbekommen. (Allerdings noch ohne den gewünschten Timeout, was aber eher einfach zu lösen sein sollte).
Bin mir allerdings nicht mehr so sicher ob ich das über ein Shell-Script machen sollte ... das "Keep-Alive" sollte natürlich möglichst "fälschungssicher" sein. Also über eine Art Hashwert aus IP,MAC,Zeit,User und eine Art Session-ID oder ähnliches.
Da stoßt man dann mit der sh doch schnell an die Grenzen.
Aber ruby sollte so etwas locker schaffen.
Dort wäre auch ein einfaches UDP-Protokoll schnell implementiert.



Was mich ein wenig stört ist, dass über die Konsole gemountete ecryptfs-shares nicht im DSM als "Eingehängt" angezeigt werden.
Der Status wird dort leider nicht durchgereicht (ich hätte das ganze ja gerne in beide Richtungen).

Wenn dazu jemand eine Idee hat ... gibt es dazu irgendwo ein "Status-Flag" oder ähnliches ?

Letzte Option wäre, das ganze tatsächlich über das Webinterface des DSM zu machen und einfach die entsprechenden HTTP-Pakete zu "faken" ohne einen Browser zu nutzen.
Leider kenne ich mich aber damit nicht gut genug aus.
Müsste man mal mit "Live-HTTP Headers" loggen was da genau über POST und GET geschickt wird.

Und nach wie vor das Problem dass nur root "mount" und "umount" machen dürfen.
Also der Server-Seitige Prozess der auch das TimeOut monitoring macht, müsste mit root-Rechten laufen, während der Client-Seitige Prozess nur User-Rechte haben darf.


Ich denke ich habe ausreichend Kenntnisse das zu realisieren, nur ob es hübsch und vorzeigbar wird weiß ich nicht.
Und ... den ruby Teil denke ich schaffe ich. Nur habe ich noch nie mit Tcl eine GUI gebaut.

Wie gesagt, wenn sich jemand beteiligen möchte ...
Wäre doch nett wenn evtl. sogar ein fertiges DSM-Paket herauspurzelt (womit ich leider auch noch keine Erfahrungen habe).
Ruby wäre da wirklich mein Favorit, da es dann auch noch Plattform unabhängig wäre.

 

[Merthos]

/usr/syno/sbin/synoshare --enc_mount "$SHARE" "$PASSWORD"
/usr/syno/sbin/synoshare --enc_unmount "$SHARE"

...dann taucht das auch im DSM auf.

Es gab schon mehrfach Versuche, so was zu bauen. Tatsache ist wohl, dass das Interesse doch eher gering ist.

 

[AtomicOne]

/usr/syno/sbin/synoshare --enc_mount "$SHARE" "$PASSWORD"
/usr/syno/sbin/synoshare --enc_unmount "$SHARE"

...dann taucht das auch im DSM auf.

Es gab schon mehrfach Versuche, so was zu bauen. Tatsache ist wohl, dass das Interesse doch eher gering ist.

Danke, diese Art des Mountens ist ja sogar noch einfacher.
Sehr gut.
Ich hätte das direkt über mount -t ecryptfs gemacht.

Ich werde mich da mal in den nächsten Tagen dran machen ...

 

[linuxdep]

Mal ne Frage:
1. wie macht Synology das mit dem automount?
2. wie mounte ich es per Hand ohne PW einzugeben mit dem Keyfile? - gefunden Forenbeitrag geht nur nicht

mount -t ecryptfs -o ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough=n,no_sig_cache,ecryptfs_enable_filename_crypto /volume1/@secure@/ /volume1/secure
mount: mounting /volume1/@secure@/ on /volume1/secure failed: Invalid argument

Wenn das keyfile auf einem USB Stick (sicher verstaut) liegt, ist es gegen schnelle Einbrecher sicher genug, denn die werden sich nicht lange auf die Suche nach dem Stick machen, woher sollen die auch wissen das auf der Box was verschlüsselt ist ;-)