verschlüsseltes Backup übers I-Net: Dateinamen zu lang

[Loetkolben]

Hallo,

nach langer Internet-Recherche und Ausprobieren auf der Diskstation muss ich mich mit meinem Anliegen doch an Euch wenden.

Hintergrund:
Ich möchte eine Datensicherung über das Internet von einer DS213+ auf eine DS112j (stehen an verschiedenen Orten) durchführen. Dies soll komplett verschlüsselt ablaufen, damit keiner außer mir an meine Daten ran kommt.

aktuelle Einstellungen:
* Quelldaten liegen auf der DS213+ in einem verschlüsselten Ordner
* Zielordner auf der DS112j ist auch ein verschlüsselter Ordner
* in den Optionen der Datensicherung habe ich die Übertragungsverschlüsselung aktiviert

Problem:
Die Datensicherung bricht ab, weil viele der Dateinamen eine bestimmte Länge überschreiten. (Fehlermeldung: ... [23] ... illegal file name...) Ich konnte es mit einem Testordner eingrenzen, dass es wirklich an der Dateinamen-Länge liegt (Wenn ich die entsprechenden Dateinamen kürze, ist das verschlüsselte Backup des Testordners möglich).
Jetzt will ich aber nicht Tausende von Dateien durchsuchen und die Dateinamen kürzen. Schon allein, weil dann viele Verknüpfungen (wie z.B. in iTunes) nicht mehr funktionieren.

Fragen:
1) Wie lang dürfen die Dateinamen bei der oben beschriebenen Variante sein?
2) Wie kann ich das Problem umgehen? Ich will nicht, dass meine Daten von einem Hacker oder so auf dem Weg von der DS213+ zur DS112j abgefangen und missbraucht werden können!
3) Wie unsicher ist eigentlich die Übertragung OHNE aktivierte Übertragungsverschlüsselung?

Vielen Dank im Voraus

 

[Spooky_]

Ich würde mich da mal direkt an den Synology Support wenden. Das Synology Network Backup benutzt ja eine eigene RSync Implementation und mögliche Limitationen bzgl. file name length etc. sind da wohl hardcoded kompiliert.

Passiert dies tatsächlich nur bei aktivierter Transfer Encryption?

 

[Loetkolben]

Ja wenn ich die Übertragungstragungsverschlüsselung abschalte, funktioniert's.
Und wenn ich ich das Backup in einen nicht verschlüsselten Ordner (mit aktivierter Übertragungstragungsverschlüsselung) durchführe, funktioniert es auch.
Aber die Variante: Quell-Ordner=verschlüsselt + Übertragung=verschlüsselt + Ziel-Ordner=verschlüsselt funktioniert nur, wenn die Dateinamen kurz sind.

Ich schreibe mal den Support an.
Trotzdem danke.

 

[Puppetmaster]

Ja wenn ich die Übertragungstragungsverschlüsselung abschalte, funktioniert's.

Dann verzichte doch auf die verschlüsselte Übertragung!
Darüberhinaus kannst du auch auf den verschlüsselten Ziel-Ordner verzichten.
Die Daten aus dem verschlüssselten Quellordner werden auch ohne verschlüsselten Zielordner und ohne Verschlüsselungsübertragung verschlüsselt im Zielordner abgelegt. Daraus kann man ja eigentlich schließen, dass die Daten auch schon verschlüsselt übertragen werden. Was du mit einem verschlüsselten Zielordner (bzw. mit der Übertragung) machst, das ist eine doppelte Verschlüsselung, die nicht notwendig ist. Ausserdem bekommst du ja so auch die Probleme der verkürzten Dateinamen zu spüren.

 

[Spooky_]

Darüberhinaus kannst du auch auf den verschlüsselten Ziel-Ordner verzichten.
Die Daten aus dem verschlüssselten Quellordner werden auch ohne verschlüsselten Zielordner und ohne Verschlüsselungsübertragung verschlüsselt im Zielordner abgelegt. Daraus kann man ja eigentlich schließen, dass die Daten auch schon verschlüsselt übertragen werden. Was du mit einem verschlüsselten Zielordner (bzw. mit der Übertragung) machst, das ist eine doppelte Verschlüsselung, die nicht notwendig ist. Ausserdem bekommst du ja so auch die Probleme der verkürzten Dateinamen zu spüren.

Ganz sicher dass das so ist? Wenn auf die verschlüsselten Daten zugegriffen wird, entschlüsselt die DiskStation ja automatisch (sofern mit dem korrekten Schlüssel gemounted werden konnte), egal welcher Prozess darauf zugreift. In so fern hätte ich auch vermutet, dass synobkp vom System die entschlüsselten Daten bekommt und versenden würde (und nicht die noch verschlüsselten Rohdaten).

 

[Puppetmaster]

Ganz sicher dass das so ist?

Sehr sicher.
Der verschlüsselte Ordner wird beim Einhängen nicht in den Ordner gemountet, den du in der Sicherung als Quellordner auswählen kannst, du kannst dort vielmehr nur den verschlüsselten Ordner auswählen.
Kann man sich auch schön auf der Konsole ansehen.
Wenn du z.B. den verschlüsselten Ordner 'Heinz' anlegest, dann lautet der eigentliche, verschlüsselte Ordner '@Heinz@'. Gemountet wird bei Entsperrung in den Ordner 'Heinz'. Wenn du dann eine Sicherung anlegst, kannst du aber nur '@Heinz@' als Quelle auswählen, und dort drin ist alles verschlüsselt.

 

[Spooky_]

Ah, ja dann macht die Übertragungs- und Zielortverschlüsselung tatsächlich gar keinen Sinn .

 

[süno42]

Hallo Spooky,

Ah, ja dann macht die Übertragungs- und Zielortverschlüsselung tatsächlich gar keinen Sinn .

Auch wenn die Dateien verschlüsselt sind und transparent übertragen werden, ist eine verschlüsselte Übertragung weiterhin sinnvoll. Ich vermute mal, daß die Diskstation für die Übertragungsverschlüsselung auch auf SSH setzt. Die Verschlüsselung ist hier eher uninteressant, aber SSH stellt weiterhin die Authentizität und Integrität der übertragenen Daten sicher. Dies ist sehr wichtig. Ansonsten kann Dir jemand eventuell falsche Daten unterschieben. Dies würde beim Versuch, die Daten zu entschlüsseln, eventuell auffallen. Aber ein Angreifer kann so unterbinden, daß Du eine korrekte Datensicherung hast.


Viele Grüße
Süno42

 

[Puppetmaster]

Die Verschlüsselung [...] stellt weiterhin die Authentizität und Integrität der übertragenen Daten sicher. Dies ist sehr wichtig. Ansonsten kann Dir jemand eventuell falsche Daten unterschieben.

Das ist wohl richtig und sollte auch erwähnt werden.
Aber das Szenario ist wirklich extrem unwahrscheinlich, zumal der "Angreifer" dafür einigen Aufwand betreiben muss (man in the middle) und darüber hinaus keinerlei Nutzen aus dem Unterfangen ziehen kann.

 

[Spooky_]

Hallo Spooky,

Auch wenn die Dateien verschlüsselt sind und transparent übertragen werden, ist eine verschlüsselte Übertragung weiterhin sinnvoll. Ich vermute mal, daß die Diskstation für die Übertragungsverschlüsselung auch auf SSH setzt. Die Verschlüsselung ist hier eher uninteressant, aber SSH stellt weiterhin die Authentizität und Integrität der übertragenen Daten sicher. Dies ist sehr wichtig. Ansonsten kann Dir jemand eventuell falsche Daten unterschieben. Dies würde beim Versuch, die Daten zu entschlüsseln, eventuell auffallen. Aber ein Angreifer kann so unterbinden, daß Du eine korrekte Datensicherung hast.

Viele Grüße
Süno42

Stimmt auch wieder. Darüber hinaus werden ohne Verschlüsselung Benutzername und Passwort wahrscheinlich im Klartext an die Gegenstelle geschickt.

Trotzdem sollte ja zumindest die nochmalige Verschlüsselung der Daten am Zielort nicht wirklich notwendig sein.

 

[snowbeachking]

Hallo,

hier gebe ich nun auch meinen Senf dazu ab. Das Problem der Dateinamenlänge ist ganz simpel: Wenn der Zielordner verschlüsselt ist, dann dürfen die Dateinamen nicht länger als 34 Zeichen (z.B. 30 Zeichen Dateiname + "." + 3 Zeichen Dateiendung) sein. Da ist es relativ egal wie die Daten übertragen werden, ob bspweise via VPN und Backup unverschlüsselt oder via SSH. Es ist auch unerheblich, ob das Quellverzeichnis verschlüsselt ist oder nicht. Wie gesagt, ganz simpel...

Also, Empfehlung meinerseits, das Zielverzeichnis einfach nicht verschlüsseln, aber dafür die Quellverzeichnisse. Hinweis: Systemordner wie z.B. video, photo und music, usw. lassen sich selbstverständlich nicht verschlüsseln. Bei diesen hat man dann "Pech".

Grüße

 

[snowbeachking]

Nachtrag: Lange Dateinamen funktionieren reibungslos von unverschlüsseltem Quellordner auf verschlüsselten Zielordner.

 

[micho2]

Ich habe gerade Probleme bei Backup von unverschlüsselten Quellordnern in einen verschlüsselten Zielordner.
Ich nutzte das Standard DSM Backupprogramm.
Bekomme im DSM die Fehlermeldung: "System: [Network to share] [Sicherung] Failed to backup source folder [/homes] ([23] some files could not be transferd ) .."

Im rsync log sehe ich:
Nov 23 16:11:48 (20106) [ERROR]: rsync: recv_generator: failed to stat "/DS-my_full/homes/frank/CloudStation/.../@eaDir/.." (in DS-full-NB): File name too long (36)

DS-full-NB ist der verschlüsselte Zielordner.
Was ist denn die erlaubte filename / pathname Länge?
snowbeachking schrieb ja:"Nachtrag: Lange Dateinamen funktionieren reibungslos von unverschlüsseltem Quellordner auf verschlüsselten Zielordner."