bananian NAS (Debian basiert) und verschlüsselung von Festplatten

Der_Haase

New member
Themenstarter
Registriert
25 Nov. 2011
Beiträge
506
Hallo zusammen,

ich bastel gerade an meinem Projekt "NAS" und stehe gerade vor einem elementaren Problem.
Erstmal die Hintergrund-Infos: Das System basiert auf einem Bananapi mit Bananian (Debian basiertes Server-System ähnlich rasppian) auf welchem momentan Open Media Vault als Weboberfläche läuft. Ziel des ganzen ist es, mein x220t (Fedora Linux) und mein Thinkpad 10 (win8.1) synchron zu halten (Dokumente), und zusätzlich alle Daten die nicht dauerhaft benötigt werden via Netzwerk für alle Clients zugänglich zu machen (Musik, Bilder, etc.).
Letzteres ist auch kein Problem, das lässt sich ja über eine einfache Netzwerkfreigabe realisieren.
Nur ersteres bereitet mir noch kopfzerbrechen. Die Synchronisierung an und für sich soll aber hier (noch) nicht Thema sein. Es geht erst einmal um eine ganz elementare Grundproblematik:
Ich will den Bereich für die Dokumente verschlüsseln. es bringt ja nichts verschlüsselte Clients zu verwenden und dann die Daten unverschlüsselt schön gesammelt auf einer Festplatte abzulegen.
Durch die Synchronisierungsanforderung kommt auch eine lokale verschlüsselung (und dann einfach eine übertragung als verschlüsselten container an die NAS) nicht in Frage.
D.h. ich möchte die Festplatten mit dm-crypt verschlüsseln und dann an die NAS hängen.

Meine bisherigen Ideen:
  • NAS komplett verschlüsseln und Festplattenschlüssel auf der NAS speichern
    Das scheint aber unter solchen minimal Systemen nicht problemlos machbar zu sein.
  • Nur festplatte verschlüsseln
    • Entweder manuel via OMV Oberfläche (oder SSH) nach jedem boot manuell mit eingabe des PW mounten
    • oder den Schlüssel auf einem USB Stick ablegen welcher zum booten der NAS kurz eingesteckt wird und es wird dann via script automatisch die Festplatte mit dem PW vom Stick gemounted und der Stick danach wieder abgezogen

Hierzu nun ein paar Fragen:
  1. Wenn ich eine verschlüsselte Partition mounte, wo im OS könnten dann evtl. die Schlüssel liegen? Also gibt es bei dieser Methode die Gefahr, dass auch wenn die NAS aus ist, jemand aus dem /tmp/ den Schlüssel auslesen kann?
  2. Hat jemand schon mit einem solchen Problem zu tun gehabt und vielleicht eine gute Lösung parat?
  3. Allgemeine Meinung zu dem vorhaben, oder vielleicht alternativen?
  4. Gibt es evtl. schon fertige NAS Systeme die dies können? (Wäre auch eine alternative, aber bissher habe ich das eben nur bei teuren Unternehmens-NAS-Systemen gefunden.


merci schonmals :)
 
Hi,

dm-crypt ist eine ausgereifte Technik. Die symmetrischen Schlüssel für die laufende Entschlüsselung der Volumes liegen also im RAM (und natürlich mit deiner Passphrase asymmetrisch verschlüsselt im LUKS-Header jedes Volumes). Ich gehe davon aus, dass für die betreffenden RAM-Blöcke neben anderen Sicherheitsmaßnahmen auch das Paging (Swap) ausgeschlossen wird.

Was hingegen OMV mit den eingegebenen Passphrasen tut, kann ich mangels eigener Erfahrung nicht sagen. Du solltest auf jeden Fall /tmp ins RAM legen und Swap deaktivieren.

Kommerzielle NAS (Synology, QNAP) verwenden kein dm-crypt, da es durch die Verschlüsselung kompletter Volumes sperrig und nicht wirklich multi-user-fähig ist. Stattdessen wird ecryptfs für einzelne Ordner/Freigaben verwendet.

Meine Einschätzung – anhand deiner knappen Beschreibung – ist, dass für deinen Anwendungsfall Ordner-Verschlüsselung hinreichend wäre.

Google sagt mir, dass der ARM Cortex-A7 des BananaPi kein Hardware-AES hat, die Performance beim Verschlüsseln großer Datenmengen (auch ein rsync derselben) dürfte also unterirdisch sein. Zum Vergleich: mein Synology DS211 hat (angeblich) Hardware-AES, ist aber beim Verschlüsseln äußerst gemächlich. Bei größeren Datenmengen kommt man um Intel-basierte NAS wohl nicht herum.

Ich würde sagen, probiere mit dem B-Pi mal alles aus und hol dir dann ggf. ein richtiges NAS ...
 
Zuletzt bearbeitet:
@Linerunner:

Danke für die ausführliche Antwort.
Deine Einschätzung ist richtig, eine Ordner-Verschlüsselung sollte ausreichen. Um den Anwendungsfall etwas genauer zu präzesieren:
Bilder und Musik soll für alle Clients im Netzwerk bereit gestellt werden, hier muss nichts synchronisiert werden und diese Daten müssen auch nicht verschlüsselt werden.
Dokumente: Wie schon geschrieben will ich hier einen sync verschiedener Geräte bereitstellen. D.h. bei den Clients kann es zu änderungen in den Dateien kommen, die NAS soll dann diese Änderungen erkennen, auf die eigene Platte legen und an die anderen Clients weiterreichen, so dass überall ein gleicher Datenstand herrscht (und die NAS am besten noch Versionierte Backups hat).
Bei den Dokumenten gibt es einige Ordner die im klartext auf der NAS liegen dürfen, aber einige möchte ich doch nur verschlüsselt ablegen (~5-10GB Daten).

Kann ich so etwas mit einem Synology Gerät bewerkstelligen? Alternativ würde ich das ganze eben Client-seitig mit rsync (o.Ä.) realisieren müssen. Mir wäre es aber recht wenn das die NAS übernehmen könnte.
Hoffe mein Anwendungsfall ist so etwas detailierter Beschrieben.

... Ich gehe davon aus, dass für die betreffenden RAM-Blöcke neben anderen Sicherheitsmaßnahmen auch das Paging (Swap) ausgeschlossen wird. ...
SWAP würde ich auf jedenfall deaktivieren, weitere Sicherheitsmaßnahmen fallen mir jetzt keine ein. Welche meinst du damit?

Was hingegen OMV mit den eingegebenen Passphrasen tut, kann ich nicht sagen. Du solltest auf jeden Fall /tmp ins RAM legen und Swap deaktivieren.
Klingt nach einer guten Idee.

Google sagt mir, dass der ARM Cortex-A7 des BananaPi kein Hardware-AES hat, die Performance beim Verschlüsseln großer Datenmengen (auch ein rsync derselben) dürfte also unterirdisch sein. Zum Vergleich: mein Synology DS211 hat (angeblich) Hardware-AES, ist aber beim Verschlüsseln äußerst gemächlich. Bei größeren Datenmengen kommt man um Intel-basierte NAS wohl nicht herum.

Ich würde sagen, probiere mit dem Pi mal alles aus und hol dir dann ggf. ein richtiges NAS ...
Hätte ich auch selber drauf kommen können :facepalm: . Seit sogar die ATOM CPUs Hardware AES können hab ich völlig verdrängt, dass es ja auch noch CPUs gibt die das nicht können... das ist somit auch ein guter Punkt!

Noch eine Frage zu Synology:
Wie restriktiv bin ich den hier eingesperrt? Hat man genug Einstellmöglichkeiten für spezifische Anwendungsfälle?
Weiter kenne ich Synology eigentlich nur Negativ aus den (IT) Medien wenn es mal wieder um Lücken und Bugs geht und das Synology hier wohl gern ältere Geräte nicht ausreichend mit Updates und Patches versorgt... ist da was drann? Oder "müsste" ich mir nur sorgen machen wenn ich die Synology nach ausen freigeben möchte (was ich nicht vor habe).
 
Ich befürchte auch, dass die Performance auf einem BananaPi leider mindestens extrem zäh, wenn nicht unbrauchbar sein dürfte. Für eine ernsthafte Nutzung wirst du um performantere und für diesen Zweck gemachte Hardware wohl nicht herum kommen.

Synology ist dabei aus meiner Sicht zusammen mit QNAP noch einer der "besten" Anbieter, der seine Systeme relativ gut pflegt und die Firmware/Software weiterenwickelt. Natürlich ist damit ab einem gewissen Alter auch mal Schluss, aber bei anderen Herstellern passiert das oft deutlich schneller. Wenn die ganze Geschichte nur im LAN stattfinden soll, ist das meist ohnehin nicht so wild; das NAS sollte dann eben sauber vom Internet isoliert werden.
 
Bitte linrunner ohne 'e'.

Kann ich so etwas mit einem Synology Gerät bewerkstelligen? Alternativ würde ich das ganze eben Client-seitig mit rsync (o.Ä.) realisieren müssen. Mir wäre es aber recht wenn das die NAS übernehmen könnte.
Das syncen wird imho immer vom Client aus gesteuert, mit entsprechender Software dort. Ich hätte auch ganz entschieden etwas dagegen, wenn ein NAS von sich aus auf meine Maschinen zugreifen dürfte. Von Synology gibt es den DS Cloud Client für Windows, Linux, Android, usw., ich verwende nur den für Android. Der ist umständlich zu konfigurieren (im krassen Gegensatz zu Synology DSM übrigens!), macht man ja aber nicht ständig, und tut ansonsten seinen Job.

Die Linux-Version habe ich nie ausprobiert, ich ziehe rsync und Unison vor. Windows habe ich keinen Bedarf ...

Die "Cloud" läuft dabei natürlich nur im LAN.

weitere Sicherheitsmaßnahmen fallen mir jetzt keine ein. Welche meinst du damit?
Ich meinte solche die der Kernel von sich aus vornimmt.

Noch eine Frage zu Synology: Wie restriktiv bin ich den hier eingesperrt? Hat man genug Einstellmöglichkeiten für spezifische Anwendungsfälle?
Ich hab ganz am Anfang mal den ssh Zugang aktiviert (samt .ssh/authorized_keys), um im Laufe der Zeit festzustellen, daß man den eigentlich nie braucht. Höchstens mal zum Nachschauen "wie haben die das gemacht?". Die Browseroberfläche ist extrem komfortabel --> Live Demo

Weiter kenne ich Synology eigentlich nur Negativ aus den (IT) Medien wenn es mal wieder um Lücken und Bugs geht
Lücken hat jedes System und Synology kümmert sich drum, daher das Medienecho.

das Synology hier wohl gern ältere Geräte nicht ausreichend mit Updates und Patches versorgt...
Kommt darauf an was man unter "älter" versteht. Der Supportzyklus läßt sich sicher auf der Synology-Site recherchieren. Tip: die beiden letzten Ziffern der Modellbezeichnung korrespondieren ungefähr mit dem Erscheinungsjahr.

Meine wurde Anfang 2011 mit DSM 3.0 geliefert, inzwischen bin ich bei DSM 5.2.

Oder "müsste" ich mir nur sorgen machen wenn ich die Synology nach ausen freigeben möchte (was ich nicht vor habe).
So ist es. Zugriff von außen macht man eh besser per eigenem VPN. Netzwerk/Firewall-Funktionalität immer hübsch getrennt von den (NAS)-Daten auf eigenem Router abwickeln ...
 
@cyberjonny:
merci auch für diese Infos.
...Wenn die ganze Geschichte nur im LAN stattfinden soll, ist das meist ohnehin nicht so wild; das NAS sollte dann eben sauber vom Internet isoliert werden.
Naja, wie auch linrunner geschrieben hat würde das ganze wenn überhaupt via VPN von der fritzbox stattfinden, an welcher dann auch die/das NAS hängt. Das NAS noch besser vom internet isolieren würde ja heißen ein getrenntes Netzwerk aufbauen was dann doch zu unpraktisch wird.

Habe mich in der zwischenzeit ein wenig zu synology eingelesen: Prinzipiell sollte da alles funktionieren was ich brauche, wobei ich nicht herausfinden konnte, ob ich verschlüsselte Ordner für jede Aufgabe verwenden kann (also auch für die multi-client synchronisierung).

Bitte linrunner ohne 'e'.
...verlesen, sorry.

Das syncen wird imho immer vom Client aus gesteuert, mit entsprechender Software dort. Ich hätte auch ganz entschieden etwas dagegen, wenn ein NAS von sich aus auf meine Maschinen zugreifen dürfte.
Hmm... ok. Ich würde das tatsächlich bevorzugen. Einfach die zu synchronisierenden Ordner für einen weiteren user freigeben und die NAS soll via Netzwerkfreigabe das ganze abgrasen... aber das ist dann wohl Geschmackssache :).

Ich meinte solche die der Kernel von sich aus vornimmt.
Ok.

Ich hab ganz am Anfang mal den ssh Zugang aktiviert (samt .ssh/authorized_keys), um im Laufe der Zeit festzustellen, daß man den eigentlich nie braucht. Höchstens mal zum Nachschauen "wie haben die das gemacht?". Die Browseroberfläche ist extrem komfortabel --> Live Demo
Heißt also, dass das grundsätzlich möglich wäre. Ich denke ja auch nicht das man es braucht, aber evtl. könnte es ja mal ganz praktisch werden.

Lücken hat jedes System und Synology kümmert sich drum, daher das Medienecho.
Das stimmt wohl. Allerdings, wenn man sich mal bei diversen Rezessionen zu Synology umschaut wird doch immer wieder von vielen Bugs berichtet, bis hin zu spontaner Nicht-Sicherung der Daten...
Da ist eben immer die Frage: Einzelfälle oder doch häufiger vorkommend.


Danke nochmals für die Rückmeldungen, ich denke ich werde das ganze mal genauer überdenken... So ne Synology kostet dann halt (im vgl. zum Pi) ne ganze Stange Geld. Und da die Datenmenge die täglich geändert wird doch relativ gering ausfällt wäre der Leistungseinbruch vermutlich zu verschmerzen. Die Frage ist nur, ob mir nicht ein vorgefertigtes - und damit pflegeleichteres - System lieber ist.

Wenn nicht immer diese doofe Geschichte mit der verschlüsselung wäre...
Ich denke ich werde einfach mal, auch zum Verständniss, das ganze mit dem Pi testen und dann sehen ob / wann limitierungen auftreten. Und ggf. sich zu Weihnachten mit ner "echten" NAS beschenken...
 
ob ich verschlüsselte Ordner für jede Aufgabe verwenden kann (also auch für die multi-client synchronisierung).
Ja doch, sind ganz normale Ordner. Müssen allerdings nach jedem Boot des NAS per Weboberfläche [EDITH: oder auch per ssh/Kommandozeile] aufgeschlossen werden – wenn man den Key nicht hinterlegen möchte ...

Dass ich hier nur aus (eigener plus Freunde/Kollegen) Synology-Erfahrung berichte, heißt übrigens nicht, dass Mitbewerber wie QNAP schlechter wären. Ich hab nur dazu eben keine Erfahrungen ...
 
Zuletzt bearbeitet:
Ja doch, sind ganz normale Ordner. Müssen allerdings nach jedem Boot des NAS per Weboberfläche [EDITH: oder auch per ssh/Kommandozeile] aufgeschlossen werden – wenn man den Key nicht hinterlegen möchte ...

Dass ich hier nur aus (eigener plus Freunde/Kollegen) Synology-Erfahrung berichte, heißt übrigens nicht, dass Mitbewerber wie QNAP schlechter wären. Ich hab nur dazu eben keine Erfahrungen ...

merci auch für die infos :)

- - - Beitrag zusammengeführt - - -

So,

nachdem ich nun mich nochmals weiter eingelesen habe komme ich zum Schluss, das für meine Zwecke aktuell (Synology Option wird evtl. später geprüft) owncloud oder seafile auf dem banana pi auf einer verschlüsselten Festplatte die beste Option darstellt.
Durch die Verschlüsselung wird es natürlich deutlich langsamer, aber für Testzwecke sollte es erst einmal ausreichen.
Nach Vergleichen der beiden Systeme werde ich mich vermutlich für Seafile entscheiden, das scheint wohl insgesamt zuverlässiger zu funktionieren und etwas performanter zu sein. Die zusätzlichen Features die OwnCloud bietet brauche ich momentan nicht. Mir geht es nur darum Ordner auf mehreren Clients synchron zu halten.
Desweiteren bietet Seafile auch die Möglichkeit der client-side encryption womit eigentlich am besten bedient wäre. Allerdings geht aus den Bugreports und Foreneinträgen hervor, dass das ganze noch nicht so ausgereift und fertig entwickelt ist (z.B. werden Momentan nur die Dateiinhalte verschlüsselt, nicht aber die Dateinahmen. Auch gibt es noch kein genaues Backupkonzept).
Kurz: Ich werde wohl oder übel auf eine verschlüsselte Festplatte setzen müssen.

Die Idee wäre aktuell daher das System abzusichern (tmp und swap) und dann eine mit dm-crypt verschlüsselte Platte anzuhängen. Diese würde ich gern via keyfile auf einem USB Stick wärend des bootvorgangs mounten (oder wenn das nicht funktioniert alternativ eben via ssh manuell einbinden).

Zum "absichern" nun noch eine Frage:
Da der Banana nicht über viel RAM verfügt bin ich am überlegen ob es anstatt den tmp-Ordner auf den RAM auszulagern nicht eine Möglichkeit wäre diesen automatisch bei jedem Bootvorgang verschlüsselt zu erzeugen (siehe z.B.: https://unix.stackexchange.com/questions/55773/move-tmp-to-ram ). Wäre dies auch eine Möglichkeit, oder ergeben sich hieraus im Vergleich zur RAM Methode Sicherheitslücken?

Edit fragt: Ob das ganze vielleicht auch bei SWAP möglich und / oder Sinnvoll wäre. RAM ist dann doch eher Mangelware auf dem kleinen....
 
Zuletzt bearbeitet:
Ich kann dir zwar leider bei deiner Frage nicht helfen - da ist linrunner vermutlich der weitaus kompetentere Ansprechpartner -, aber mich würde sehr interessieren, zu welchen Ergebnissen/Erkenntnissen du bei deinem "Experiment" dann kommst. Ich fände es super, wenn du dann irgendwann mal darüber berichten würdest! :)

Den Gedanken, auf diese Weise ein "Mini-NAS" zu realisieren, hatte ich nämlich auch schon. Nur die Zeit, die zum Ausprobieren nötig gewesen wäre, (bisher) leider nicht...
 
Ah ja, schon werden die komplexen Anforderungen nachgeschoben. So ist das mit den Projekten ... ;)

/tmp: tmpfs nimmt sich nur soviel RAM wie tatsächlich belegt ist im Filesystem unter /tmp. Hast Du mal nachgeprüft wieviel das bei dir ist?

Swap: wie wolltest Du denn mit der Maschine noch arbeiten, sobald sie wegen zu knappem RAM anfängt mit Paging? Und das auch noch verschlüsselt? :facepalm:

Hast Du mal überprüft, wieviel RAM tatsächlich benötigt wird -- mit free (netto-Angaben ohne Buffers)? Ich unterstelle mal, daß selbstverständlich kein grafischer Desktop installiert ist. Ohne GUI ist ein Linux in der Regel ziemlich Speicher-sparsam.
 
Zuletzt bearbeitet:
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben