Datentransfer mit NAS

ShadowDragon

Lt. Junior Grade
Registriert
Apr. 2017
Beiträge
410
Hi,

mich würde einmal interessieren wie ich am besten Daten auf den NAS bewege und Anwendungen Daten von diesem lesen können.

Folgendes Setup:
1. NAS: TrueNAS Core (2 Festplatten im ZFS Mirror)
2. Application server: proxmox (zurzeit alles mit LXC sowie docker Container in LXC Container visualisiert)
3. Endgeräte im Haushalt

Proxmox hängt an einem Switch welcher zur Fritzbox geht und mein NAS hängt an einem weiteren Switch (anderer Raum -_-) welcher auch mit der Fritzbox verbunden ist.

Zum eigentlichen Setup:
1. Unter Proxmox läuft in LXC in docker meine Datenbank (PostgreSQL). Diese soll ein automatisches Backup auf dem NAS bekommen. Bei den Backups müssten auch noch zwei weitere Container Backups durchführen (Minecraft Welt, TeamSpeak Daten).
2. Des weiteren habe ich Jellyfin unter Proxmox am laufen. Die Filme und Bücher liegen hierzu auf einem Media dataset auf dem NAS.
Zeitgleich habe ich vor, wenn ich neue Filme kaufe, diese über Proxmox auf das Media dataset zu ziehen.
3. Ein weiteres dataset ist geplant um Dateien zwischen den Endgeräten im Haushalt auszutauschen. Hier soll natürlich auch nur jede Person seine eigenen Daten sehen können.

Meine Frage ist nun, wie kann ich hier Daten gesichert übertragen? Da ich möchte z.b. nicht, dass der ganze Haushalt direkten Zugriff auf das Media dataset hat, dieser soll ausschließlich über proxmox erfolgen können. Zeitgleich kann ich hier noch nicht viel mit VLANs arbeiten, da die Fritzbox meines Wissens nach keine unterstützt.

Heißt also die Daten sollen verschlüsselt zwischen authentifizierten Clients welche die benötigten Rechte haben übertragen werden.

Darum die Frage: Welches System (e.g. NFS) eignet sich hierfür am besten bei verwendeter Software und den Gesetzen Anforderungen und zu guter Letzt: wie muss ich die entsprechenden permissions und Gruppen etc. unter TrueNAS einstellen?
Vor allem ist mir hierbei die Security wichtig, auch weil ich einfach Mal lernen will, wie man ein solches System sicher umsetzt und man denke ich Mal dies besser von Anfang an planen und umsetzen kann statt später irgendwie einzubauen.
 
Ich denke wenn du das lernen willst, solltest du dich dazu einlesen und es dann ausprobieren und nicht nach einer maßgeschneiderten Lösung fragen.
Dein aktueller Anwendungsfall ist außerdem sehr spezifisch, enthält viele Fragen die ohne genaue System/Installationsinfo/Softwareinfo gar nicht "so einfach" und "pauschal" zu beantworten sind.

z.B "Endgeräte im Haushalt", sind das Windows oder MacOs oder iOs Geräte? Je nachdem welche es sind unterstüzten sie andere Datenübertragungsprotokolle.
Truenas unterstützt sie alle, du musst sie dann dementsprechend konfigurieren.
 
ShadowDragon schrieb:
Daten sollen verschlüsselt zwischen authentifizierten Clients
Du musst eindeutiger werden bzw. die Antwort lautet: viele Wege führen nach Rom.
NFS kann Verschlüsselung afaik erst ab NFSv4, Authentication von "Nutzern" auch erst ab NFSv4, afaik aber nur über Kerberos und das willst du dir privat nicht antun^^ Vorher geht Zugriffskontrolle IP-/Hostbasiert und über die Dateisystemberechtigungen auf dem NFS-Server dann, der Traffic ist aber soweit mich meine grauen Zellen da nicht täuschen unverschlüsselt.
Samba/Cifs kann mit SMBv3 auf jeden Fall encryption at transit, musst du bei truenas aber als auxiliary parameter für jeden Share einzeln einstellen und nennt sich 'smb encrypt', weitere Infos in der Doku, siehe hier: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html, ziemlich weit unten.

Rein von der Zugriffskontrolle aus kannst du noch mit hosts.allow und hosts.deny arbeiten und so IP-basiert erlauben welche Systeme Zugriff haben sollen. Schützt aber nicht vor potentiellen Angreifern, die sich die passende IP selbst geben. Hier musst du für dich selbst überlegen wie wahrscheinlich dieses Szenario ist oder nicht.

Zum Thema ACLs gibt es einen längeren Artikel in der Doku: https://www.truenas.com/docs/core/storage/pools/permissions/
Grundlegend gilt: Es sollte stets vermieden werden einzelne User zu berechtigen sondern immer basierend auf Gruppen.

Für das konkrete Beispiel Jellyfin könntest du auf dem NAS eine Gruppe "media-dataset-rw" anlegen und dieser erlaubst du entsprechenden schreibenden Zugriff. Dann legst einen User für jellyfin bzw. den Zugriff an, packst den User in die zuvor erstellte Gruppe und bindest diese Freigabe entsprechend in jellyfin so ein.
Am Ende sollte in den ACLs der @owner noch berechtigt sein, idR also root auf truenas und @group mit den von dir gewünschten Berechtigungen und sonst niemand.

Wichtig: Das sind die Filesystem ACLs. Zusätzlich kannst du noch Share ACLs verwenden bei den einzelnen Freigaben. Best Practice ist aber eigentlich ausschließlich mit Filesystem ACLs zu arbeiten und bei Share recht freizügig zu sein bzw. dort nur zu klären ob grundsätzlich Zugriff erlaubt sein soll oder nicht. Das gilt nicht nur für Truenas sondern auch bei allen Arten von Fileservern egal ob Windows, Linux oder sonstige Appliances.
 
  • Gefällt mir
Reaktionen: ShadowDragon
snaxilian schrieb:
erst ab NFSv4, afaik aber nur über Kerberos und das willst du dir privat nicht antun^^
Was macht Kerberos eigentlich so kompliziert? (Außer das man Recht wenig dazu findet an Anleitungen)

snaxilian schrieb:
der Traffic ist aber soweit mich meine grauen Zellen da nicht täuschen unverschlüsselt.
Jap, der ist dann bei NFS unverschlüsselt. Verstehe auch nicht wieso das nicht standardmäßig verschlüsselt ist, wenn mittlerweile jeder Messenger verschlüsselt sendet. Wobei diese natürlich übers Internet gehen und in meinem Fall die Daten nur durch's Hausnetz gehen und man damit jeden persönlich kennt der theoretisch Daten abgreifen könnte. Verschlüsselt wäre natürlich definitiv angenehmer, wobei ob es hier noch einen Unterschied macht wenn man verschlüsselt oder nicht, wenn es eh keine richtige Authentifizierung gibt (angenommen man würde NFS nehmen ohne Kerberos).

snaxilian schrieb:
Hier musst du für dich selbst überlegen wie wahrscheinlich
Nun ja, so gesehen bräuchte da ja ein Angreifer eh physischen Zugriff aufs Netz und wenn sich jetzt jemand die IP von Proxmox gibt, wird es eh zu Problemen kommen, da auf einmal 2 Geräte die gleiche IP haben. Also denke Mal das Szenario ist eher unwahrscheinlich.
snaxilian schrieb:
Du musst eindeutiger werden bzw. die Antwort lautet: viele Wege führen nach Rom.
Nun ja, viele Wege gibt es immer.
An welcher Stelle soll ich denn eindeutiger werden?

Generell ist halt mein Ziel die Shares so abzusichern, dass nur berechtigte Geräte und Personen auf die Daten Zugriff haben und niemand anderes. Und diese dann auch nur mit den minimal benötigten permissions.

snaxilian schrieb:
Samba/Cifs kann mit SMBv3 auf jeden Fall encryption at transit, musst du bei truenas aber als auxiliary parameter für jeden Share einzeln einstellen und nennt sich 'smb encrypt', weitere Infos in der Doku, siehe hier: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html, ziemlich weit unten.
Interessant. Dann muss ich Mal nachher schauen ob Proxmox auch mit Samba/Cifs mit SMBv3 umgehen kann.
Aber zumindest die Endgeräte sollten es können.
FartyMcFly schrieb:
Ich denke wenn du das lernen willst, solltest du dich dazu einlesen und es dann ausprobieren und nicht nach einer maßgeschneiderten Lösung fragen.
Hättest du den einen Link oder so wo man anfangen könnte ich einzulesen? Oder irgendein Stichwort wo man als Einstieg nachschauen könnte?
FartyMcFly schrieb:
z.B "Endgeräte im Haushalt", sind das Windows oder MacOs oder iOs Geräte?
iOS, iPadOS, Android 8+, Windows 10, verschiedene Linux distros (alle auf Kerbel 5.4 und höher)

Und zur Software vom application Server:
Proxmox als base System. Darauf laufen TeamSpeak und Minecraft in eigenen LXC Containern. Im Falle von TeamSpeak kann man vermutlich einfach den Container rüberkopieren in einen Share. Bei Minecraft sollte es reichen die Welt welche im Container gespeichert wird rüber zu kopieren nach TrueNAS.

Der PostgreSQL 13 Datenbankserver läuft in einem Docker Container welcher selbst in einem LXC Container läuft. Hierbei wird die Datenbank mit einem Volume in einem Ordner innerhalb des LXC Containers abgelegt.

Bei Jellyfin ist der Plan, dies auch über docker laufen zu lassen, ist aber noch nicht fertig eingerichtet.
 
Zuletzt bearbeitet:
ShadowDragon schrieb:
Verstehe auch nicht wieso das nicht standardmäßig verschlüsselt
Dann nimm dir mal ein Geschichtsbuch und gucke dir an von wann NFS bzw. die Versionen sind. Den RFC zu NFSv3 gab es 1995 und jetzt zeige mir mal bitte die ganzen Messenger, die damals verschlüsselt Daten austauschen konnten. Ansonsten auch mal hier nachlesen: https://de.wikipedia.org/wiki/Network_File_System#Sicherheit

NFSv4 kann dann auch den Traffic verschlüsseln wenn die Option sec=krb5p gesetzt ist.

Zu den Wegen und konkreten Dingen: Es gibt nie die eine allumfassende perfekte und sichere Lösung. Du musst klar benennen können was die "Bedrohungen" sind und was genau das Ziel sein soll. Dann kann anhand der Anforderungen geklärt werden welche Möglichkeiten es gibt und wie diese konkret umgesetzt werden müssen.
ShadowDragon schrieb:
Ziel die Shares so abzusichern, dass nur berechtigte Geräte und Personen auf die Daten Zugriff haben und niemand anderes
Das ist schnell erledigt über die entsprechenden Berechtigungen und Authentisierung per Benutzername + Kennwort und ginge z.B. auch schon mit NFSv3 oder SMB.
Wenn du nur normale Anwender in deinem Netz hast kann das ausreichen. Wenn du versierte "Anwender" der Eindringlinge erwartest, die fähig und willens sind ein live-linux zu nutzen, ggf. arp-poisoning anzuwenden, etc. dann sind weitere Schutzmaßnahmen nötig wie eben Verschlüsselung des Traffics und/oder auth per Kerberos oder ähnliches anstatt uid/gid bei NFSv3.
Wie gesagt: Konkret werden wovor/vor wem du dich schützen willst dann kann man weiter sehen. Wenn du allgemein bleibst dann müsstest du defacto alle nur erdenklichen Maßnahmen umsetzen und wirst nie fertig. Zumal in der jetzigen Umgebung das viel Gefrickel und Ersatzmaßnahmen sind anstatt z.B. VLANs und ne zentrale Firewall zu verwenden.
ShadowDragon schrieb:
Proxmox auch mit Samba/Cifs mit SMBv3 umgehen
Ja, musst es ggf. in der fstab explizit setzen, v.a. wenn du encryption at transit nutzen willst, müssen Server und Client SMBv3.11 sprechen.

ShadowDragon schrieb:
Datenbankserver läuft in einem Docker Container welcher selbst in einem LXC Container
KISS Prinzip und du machst das komplette Gegenteil und wirfst wo nur möglich mit Komplexität um dich^^
Du hast jetzt bereits drei LXCs und für jeden eine eigene Art des Backups? Kann ich nur von abraten. Halte es so einheitlich wie möglich.
Proxmox bietet doch selbst die Möglichkeit an Backups regelmäßig zu erstellen. Doku lesen und gucken welche der dort gebotenen Möglichkeiten passen. Ich würde den stop oder suspend mode nehmen, Snapshots sind spätestens bei Datenbanken nicht crash-konsistent. Wenn du das doch machen willst, dann musst du mit Hook Scripts arbeiten die vorher die DB stoppen/pausieren und danach wieder starten.
 
snaxilian schrieb:
Den RFC zu NFSv3 gab es 1995
Ah, wusste nicht dass NFS schon so alt ist, vor allem wenn man sich dann noch die Ursprünge mit v2 und v1 anschaut. Also älter als meine ersten Aktivitäten im Internet. ^^

snaxilian schrieb:
Wie gesagt: Konkret werden wovor/vor wem du dich schützen willst dann kann man weiter sehen.
Ok. Also, die Anwender innerhalb dieses Haushalts sind eher so normale PC Nutzer. Halt der "average" Windows und Linux Nutzer. Damit man dies mal besser einschätzen kann: Der erfahrenste User neben mir ist in der Lage unter Linux ohne Steam oder so Games mit Wine und Proton zum laufen zu bekommen sowie ne Fritzbox ohne Telekom/Vodafone etc. Techniker einzurichten.
Auf der Windows Seite sieht es eher düster aus. Da muss man schon aufpassen, dass das Heimnetz nicht mit Malware verseucht wird, weil irgendwer wieder ne random .exe Datei vom Top Suchergebnis statt der offiziellen Website geladen hat. -_-

snaxilian schrieb:
und willens sind ein live-linux zu nutzen, ggf. arp-poisoning anzuwenden, etc.
Hier fände ich es mal interessant wo man nachlesen kann, wie man sich gegen sowas absichert.

snaxilian schrieb:
Zumal in der jetzigen Umgebung das viel Gefrickel und Ersatzmaßnahmen sind anstatt z.B. VLANs und ne zentrale Firewall zu verwenden.
Gäbe es denn hier Möglichkeiten die jetzige Umgebung zu verbessern (ohne Anschaffung neuer Hardware)? Zugriff hätte ich hier auf den NAS Server, Proxmox, die beiden Switches und ich könnte Zugriff auf die Fritzbox selbst bekommen um dort Einstellungen vorzunehmen.
VLANs wären natürlich toll, dann könnte ich auch die IPMI-Interfaces in ein seperates VLAN hängen statt denen einfach in der FritzBox Internetzugriff zu entziehen und diese ansonsten zwar Passwortgeschützt, aber offen im Heimnetzwerk zu haben. Da mir der Router aber nicht gehört kann ich diesen leider nicht so einfach gegen ein VLAN-fähiges Gerät austauschen.

Bei zentraler Firewall könnte ich mir vorstellen, dass man dies angehen könnte indem man pfsense oder dergleichen in nem Container? oder ner VM? in Proxmox hostet.

Hier mal eine kurze Skizze des Netzwerks mit welchem ich arbeiten muss:
Network.png

Raum 1 stellt hierbei ein physischer Raum dar, Fritzbox und Proxmox Server sind auch im selben Raum. Alle anderen Geräte sind in unterschiedlichen Räumen und der Einfachheit halber nur nach Anschlussart gruppiert.

snaxilian schrieb:
Kann ich nur von abraten. Halte es so einheitlich wie möglich.
Ok. Also dann am einfachsten ein Backup des ganzen LXC Containers erstellen und dies für jeden Container durchführen, damit es auch einheitlich bleibt.
 
ShadowDragon schrieb:
Was macht Kerberos eigentlich so kompliziert?
Dann schau dir mal den deutsch- oder englischsprachigen Wikipediaartikel dazu an. Zwischen grob verstehen für die Bonuspunkte bei der Fachinformatiker Prüfung und das in der Realität betreiben liegen noch ein paar Unterschiede denn mit verstehen des reinen Protokolls ist es nicht getan, man muss das ja auch mit passender Software umsetzen. Kerberos macht ja erst Sinn oder Spaß wenn man dazu noch einen Verzeichnisdienst (LDAP oder AD) hat, dazu macht dann noch ein DNS-Server Sinn und Kerberos ohne stabile/einheitliche Zeitquelle ist gelinde gesagt mutig. Naja und wenn man dann schon so weit ist, kann man auch gleich noch ne PKI hochziehen und spätestens jetzt ist der Zeitpunkt erreicht wo das für einen allein in ein sehr zeitintensives Hobby geworden ist.
ShadowDragon schrieb:
interessant wo man nachlesen kann, wie man sich gegen sowas absichert.
Gegen ersteres: Im Bios/Uefi andere Bootoptionen deaktivieren und das Bios/Uefi mit starkem Kennwort versehen. Gegen letzteres: Nichts mit vertretbarem Aufwand im privaten Umfeld.
Grundlegend: Zuerst muss man ein Risiko verstehen und nachvollziehen, dann kann man darauf basierend sich Lösungen suchen, ganz klassisch per Suchmaschine und "how to prevent arp poisoning" in diesem konkreten Beispiel.
Das Thema Härtung und Absicherung von IT-Umgebungen ist halt nix was man mal in paar Abenden mit 1-2 Büchern lernt.
ShadowDragon schrieb:
Auf der Windows Seite sieht es eher düster aus.
Non-privilegierter User, UAC aufdrehen, aktuellen Browser mit Adblock/ublock und ein Pihole o.ä. können Wunder wirken. IPv6 bei letzterem nicht vergessen ;)
ShadowDragon schrieb:
jetzige Umgebung zu verbessern
Proxmox als auch Truenas bieten 2FA an mit allen Vor- und Nachteilen ansonsten stelle ich die ketzerische Frage: Was stört dich denn, dass du etwas verbessern willst? Irgendwelche Probleme? Man kann Dinge auch zu Tode "optimieren"^^
ShadowDragon schrieb:
pfsense oder dergleichen in nem Container? oder ner VM?
Ah ich sehe, du hast noch nicht heraus gefunden was das KISS Prinzip ist. Oder gefunden aber nicht verstanden. Virtualisierte Firewalls sind zwar technisch möglich, erhöhen aber die potentiellen Fehlerquellen enorm weil man im einfachsten Fall durch ne Fehlconfig der virtuellen NICs die Firewall aushebelt...
Andererseits könntest so zumindest deine öffentlich erreichbaren Dienste so separieren damit sich ein potentieller Angreifer nicht so einfach weiter durchs Netzwerk bewegen kann.
Eine einzelne Firewall ist aber auch nur ein kleiner Baustein beim Schutz der eigenen Daten und Systeme. Das Stichwort lautet hier Defense in depth.
 
  • Gefällt mir
Reaktionen: Clapinoson und ShadowDragon
Zurück
Oben