Verschiedene Wege der Verfügbarkeit vom www aus

[ayron]

Hallo erstmal,
ich habe seit kurzer Zeit eine 218+ und mich schon ausgiebig damit befasst. Ich würde gerne die Station auch vom www aus erreichen (v.a. für Fotostation und Drive), das ganze aber möglichst sicher. Hierbei sind mir jetzt folgende Möglichkeiten eingefallen, ich weiß nur nicht welche die sinnvollste ist:

1) Kein Quickconnect, Keine Portfreigaben am Router, Zugriff ausschließlich via FritzVPN ins Heimnetz
Vorteile: Geringe Angriffsfläche
Nachteile: Aufwendig sich jedesmal per VPN einzuwählen, insbesondere für andere Personen

2) Nur Quickconnect, keine Portfreigaben
Vorteile: Es werden am Router keinerlei Ports geöffnet, somit fraglich mehr Sicherheit für das Heimnetz und die DiskStation selbst?
Nachteile: Kompletter Datenverkehr geht über Synology Server; Datenverbindung ist langsamer

3) Portfreigaben und Synology-Domain: FritzBox schickt Port 80, 443, 5000, 5001 (5000 und 5001 am besten noch ändern!) and die Diskstation, erreichbarkeit im web via mystation.synology.me mit entsprechendem Letsencrypt Zertifikat
Vorteile: Direkte Verbindung auf die DiskStation erfolgt direkt, keine Zwischenschaltung von Synology-Servern, maximale Geschwindigkeit
Nachteile: Offene Ports --> Angriffspunkt (was ich nicht verstehe ob jetzt hier wirklich nur die DiskStation auf die weitergeleitet wird angegriffen werden kann oder potentiell auch andere Geräte im Netzwerk von der Portöffnung betroffen sein können?

4) Virtuelle Trennung in 2 Diskstations indem ich Virtual DSM nutze und diese zweite Station über 2) oder 3) freigebe
Vorteile: Nur die Daten, die ich im www brauche werden auch auf der entsprechenden zweiten Diskstation abgelegt (Hardware-Trennung wäre natürlich besser ist aber nicht wirtschaftlich)
Nachteile: Ziemlich viel Security through Obscurity, ich muss zwei Maschinen warten, Performance-Verluste


Die Allgemeinen Sicherheitstipps sind mir bekannt. (Updates, Admin deaktivieren, 2FA für Administratoren, E-mail Benachrichtigung, Synologys internes fail2ban, Firewall mit geoblock, Protokolle Prüfen).

Was ich noch nicht verstanden habe, ob durch eine Freigabe im www auch die Dateidienste betroffen sind? Ich vermute mal nicht. Also wenn ich ein Netzwerklaufmerk mounten will geht das nur via VPN-Einwahl ?

So ich hoffe ihr könnt mir als Synology Einsteiger ein klein wenig helfen bei der Entscheidungsfindung!
Danke

 

[Fusion]

Hast ja selber schon alles beleuchtet. Entscheiden musst dann auch noch selber.

zu 3) von der Portöffnung ist primär nur die DS "betroffen". 5000/5001 braucht man auch nicht.
Ist ein Angreifer mal auf der DS eingebrochen kann er natürlich von dort auch weitere Geräte im Netzwerk angreifen

zu 5) Dateidienste sind ohne Hand anlegen nicht von extern verfügbar, das ist auch gut so.
Um von extern auf die Freigaben zuzugreifen bleibt einmal wie genannt VPN und vorgehen wie im LAN, oder man geht über andere Protokolle (z.B. webDAVs oder andere). Müssen natürlich auch irgendwie erreichbar sein.

Hängt eben extrem davon ab wie viele bedarfte und unbedarfte Nutzer auf welche Funktionen/Dienste auf der DS zugreifen können sollen.
Ob sie sich am DSM anmelden können müssen, oder ob das Web-Interface vieler Dienste (z.B. Drive oder andere), oder auch die DS Apps ausreichen.
Gibt viele Variable.
Wenn du aber erst mal festgelegt hast, wer wie zugreifen können muss, dann ergibt sich der Rest fast von alleine.

 

[ayron]

Danke erstmal! Ich würde dann wohl die Portfreigaben also 3) favorisieren, v.a. wegen der Möglichkeit ein Gültiges Zertifikat zu haben.

Wieso "braucht" man 5000/5001 nicht? In einem aktuellen idominix Video soll man 80,443,5000,5001 freigeben, wobei Synology selbst empfiehlt statt 5000/5001 andere Ports einzustellen um automatisierte Angriffe zu verhindern.

Was ich nicht kapiere wieso man auch den unverschlüsselten 5000er freigeben soll, wenn man doch sowieso 5001 durch die https Weiterleitung erzwingt?

Bis auf die SynologyApps und deren Webinterfaces werde ich erstmal nichts weiter einrichten. Für Moments, Drive, Backup, FotoStation, FileStation müsste ich ja mit obigen Ports auskommen?

 

[Fusion]

Weil es Mittel und Wege gibt die Dienste auch via 80/443 zu erreichen. Stichwort benutzerdefinierte Domains oder Reverse Proxies, oder Aliase (Systemsteuerung > Anwendungsportal und Systemsteuerung > Netzwerk > DSM Einstellungen).
Bedingt teilweise eben mehrere Subdomains von extern für den Zugriff (im Fall von benutzerdefinierten Domains)

Eine Umleitung auf https kann nur funktionieren wenn du per http erstmal bis zur DS kommst.
Wenn du eh per https auf die DS kommst ist auch keine Umleitung mehr nötig.
Klar?

 

[ayron]

Ok ich verstehe. Subdomains wären jetzt kein Problem, bei meinen 2-3 Diensten wäre das ja auch noch übersichtlich.

Welchen Vorteil habe ich denn von den ReverseProxies? Klar ich hab 2 Ports weniger offen, aber die verlinken ja ohnehin nur auf die DiskStation und in meinem Heimnetz hab ich defenitiv keinen "Mangel" an freien Ports.

 

[Fusion]

Ganz klar, alles was unter Systemsteuerung > Anwendungsportal > Anwendungen nicht aufgeführt wird willst du ja vielleicht auch über eine Domain erreichen?
Oder wenn du intern verschiedene Dienste auf verschiedenen Ports laufen lassen willst, aber diese extern alle mit einer subdomain auf 443 erreichen willst. (weil den Trick den Port 443 im Router auf einen anderen Port an der DS umzuleitrn funktioniert eben nur einmal für einen Zielport. Deshalb lieber gleich auf so Konstrukte verzichten.

 

[rednag]

Hör auf @Fusion

Durch dessen Hilfe habe ich meinen ausufernden Port-Zoo auch ein wenig eindämmen können.
Hier eben mit dem Reverse Proxy.

 

[ayron]

Ok dann werde ich das mal so versuchen. Soll ich dann nur Port 443 freigeben, oder muss der 80er auch mit offen sein? Wenn ich den 80er aufmache kann ich dann sicher sein, dass einzelne Dienste nicht doch eine unverschlüsselte Verbindung zulassen? Den Haken in den Einstellung https erzwingen habe ich gesetzt, aber gilt das dann auch gleichzeitig für Drive/FotoStation/Moments?

Ich bin mir nicht ganz sicher ob ich das komplett verstanden habe mit den Reverse Proxys einrichten.
1) Jeder Dienst hat eigentlich seinen eigenen Port im internen Netz
2) Ich richte subdomains für jeden Dienst ein, z.b. moments.name.synology.me?
3) Ich erstelle eine Reverse Proxy Regel und sage: hostname "moments.name.synology.me" Port 443 weiterleiten auf localhost auf Port XYZ

Stimmt das so in etwa? Was mache ich mit meinem LetsEncrypt-Zertifikat. Wildcard Zertifikate gibt es ja noch nicht, d.h. ich muss bereits bei der Zertifikatserstellung alle meine Subdomains eintragen?

 

[Fusion]

Du kannst sicher sein, wenn du es einfach ausprobierst und die Dienste per http aufrufst.
Bei den Mobil-Apps gibt es dann noch Sonderheiten zu beachten, weil diese still und heimlich im Hintergrund oft den Port 5001 oder andere benutzen wollen.
Da muss dann trotz gesetztem https Häkchen noch der Hostname auf sub.domain.de:443 eingetragen werden. (immer mal wieder Tickets an den Support schreiben, dann wird es vielleicht irgendwann auch augenscheinlich konfigurierbar umgesetzt)
Wenn du dann irgendwo nicht umgeleitet wirst kann man nachsehen an welcher Einstellung es liegt.

Wenn du nur Port 443 öffnest kannst du auf jeden Fall sicher sein. Allerdings muss dann der Aufruf von außen immer per https (443) erfolgen, weil http (80) am Router hängen bleibt / abgewiesen wird.
Unter 443 ist automatisch verschlüsselt, da muss nichts erzwungen werden. Erzwingen/Umleiten auf https macht wie gesagt nur Sinn, wenn man auch auf http erst mal bis zur DS durchkommt.

zu 1) Jeder Dienst muss irgendwie erreichbar sein, wenn man ihn nutzen können soll. Ein Port ist eine der Möglichkeiten wie dies geschehen kann, in dem Fall, wenn der Dienst über TCP/IP angesprochen werden soll. Der Port ist pro IP nur von einem Dienst verwendbar. Ein weiterer Weg ist z.B. SNI (Server Name Indication), hier wird anhand des Hostnamens, host.domain.de, der der anfragende übermittelt entschieden für welchen Dienst diese Anfrage ist. Das nutzen z.B. die benutzerdefinierten Domains die man im Anwendungsportal eintragen kann. Nur damit können sich diese Dienste dann den Port 443 "teilen" (weil eine "Weiche" davor sitzt).
zu 2) Das ist eine Möglichkeit. Macht die Namen halt unnötig lang. Aber wenn keine eigene Domain (dienst.domain.de) zur Verfügung steht...
Andere Möglichkeit war ja Alias via name.synology.me/alias, leider auch nicht kürzer.
zu 3) für die Syno Anwendungen kann man benutzerdefinierte Domains vergeben. Solange du also eine dynDNS auf moments.name.synology.me hättest (weiß nicht, ob man mehr als einen synology.me pro DS betreiben kann. Eventuell leitet Synology auch alle xxx.name.synology.me an dieselbe IP die hinter name.synology.me steckt (musst du ausprobieren, weiß ich nicht). Aber da gäbe es ja noch andere Anbieter (dynv6.com, spdns.de, selfhost, etc) und die auf deinen Anschluß zeigt, reicht es, wenn du dies als benutzerdefinierte Domain einträgst.
Nur wenn man aus welchen Gründen auch immer die benutzerdefinierten Domains nicht nutzen will, könnte man dort im Anwendungsportal eben einen benutzerdefinierten Port XYZ eintragen.
Der Reverse proxy würde dann wie in deinem Beispiel auf diesen Port umleiten.
Beide Möglichkeiten sehen nach außen hin gleich aus https://moments.name.synology.me, nur intern laufen die Daten eben über verschiedene Wege ins Ziel.
Im lokalen Netz wäre das (wenn die DNS Auflösung funktioniert) über beide Wege erreichbar (https://moments.name.synology.me und https://LAN-IP-DS:XYZ

zu 4) Wildcards gibt es schon, allerdings im Moment nur auf den Staging Servern, also nicht im freien Produktivbetrieb.
Also entweder alle Subdomains mit als Alternate Names eintragen (ich würde das allerdings erst machen, wenn du auch sicher bist, dass die Dienste (mit Zertifikatswarnung und Syno-Cert) überhaupt erreichbar sind), oder pro Dienst ein eigenes Zertifikat holen.
Und LE bedingt auch Erreichbarkeit über Port 80 zusätzlich (mindestens beim ersten Mal, wenn ein Zertifikat ausgestellt wird).
Zertifikate können auch, begrenzte Anzahl pro Woche, mit teilweise geänderten Domain Namen neu geholt werden etc. Man ist da nicht festgenagelt. Aber erst mal überlegen wie und dann machen um unnötig viele Anfragen an LE zu vermeiden.

 

[frankyst72]

5000/5001 brauchst Du nur dann, wenn Du Dich von außen auf der DSM-Oberfläche anmelden willst. Let's Encrypt bringt keine Sicherheit gegen Hacker, sondern nur, dass Du Dir sicher sein kannst (oder auch der Hacker ) Dich mit Deiner DS verbunden zu haben.

Also ich nutze hauptsächlich Aliasnamen über Systemsteuerung > Anwendungsportal. Das taugt für meine einfachen Anforderungen.

 

[ayron]

5000/5001 brauchst Du nur dann, wenn Du Dich von außen auf der DSM-Oberfläche anmelden willst. Let's Encrypt bringt keine Sicherheit gegen Hacker, sondern nur, dass Du Dir sicher sein kannst (oder auch der Hacker ) Dich mit Deiner DS verbunden zu haben.

Naja aber https braucht nunmal ein Zertifikat und Zertifikats-Warnungen sind nervig. Zudem könnte mir somit ein Man-In-The-Middle Angriff auffallen weil ich auf einmal einen Zertifikatsfehler bekomme den ich vorher nicht hatte. Aber ich weiß schon das das Zertifikat selbst kein Allerheilmittel ist ;-)

Von außen auf DSM wollte ich eigentlich schon zugreifen können. Oder wird davon abgeraten? Für den Admin würde ich zztl 2FA einrichten, doppelt hält besser ;-). Wenn ich auf DSM möchte führt kein weg an 5000/5001 vorbei, oder geht das auch via Reverse Proxy und 443?

@Fusion: 1000Dank erstmal. Ich werde versuchen es mal einzurichten und mich dann nochmal zurückmelden

 

[Fusion]

DSM > Systemsteuerung > Netzwerk > DSM Einstellungen > benutzerdefinierte Domain

Per Reverse Proxy habe ich es noch nicht probiert, sollte aber auch gehen denke ich.

Ich zitiere mich aus Post #2: 5000/5001 braucht man nicht. Mag sicher Fälle geben wo man es verschleiert nutzen will, weil man keinerlei Domains benutzen kann/will.
Dann würde ich aber immer VPN vorziehen.

Wer ganz sicher sein will stellt seine DS überhaupt nicht ins Netz bzw macht sie nicht erreichbar.
Muss jeder selber abwägen wo der beste Kompromiss zwischen Sicherheit und Komfort/Nutzbarkeit liegt.

 

[ayron]

So also die Applikationen Drive, File, Moments und Note habe ich jetzt zum laufen gebracht. Es ist nur Port 443 weitergeleitet. Die Adressen sind jetzt halt recht lang z.b. https://moments.meinhostname.synology.me:443





Allerdings will ich auch noch DSM über den 443 anzusprechen. Habe folgendes Probiert:
1) Reverse Proxy erstellen indem ich einfach dsm.meinhostname.synology.me mit Port 443 auf den 5001 weiterleite.
--> funktioniert

2) DSM > Systemsteuerung > Netzwerk > DSM Einstellungen > benutzerdefinierte Domain
-->Hattest du vorgeschlagen, funktioniert auch!

Wirkt auf mich als wäre beides exakt dasselbe am Ende. Ist vermutlich egal für was ich mich entscheide, oder?

 

[Fusion]

Hatte ich ja gesagt, nach außen hin sieht das am Ende identisch aus. Was du nimmst bleibt dir überlassen.

Im Browser kannst du das 443 am Ende weglassen. https impliziert dies schon und der Browser macht es von selbst.
Nur in den Mobil Apps dann anders herum, Haken bei https und dafür nur den Hostnamenort eintragen.

 

[ayron]

Das mit dem 443 wusste ich nicht - danke!

Macht es denn irgeindeinen Sinn jetzt noch ein wenig Security through Obscurity zu betreiben? Also z.B. statt 443 anderen Port außen zu verwenden und die internen Ports unter Anwendungsverwaltung abzuändern? Bei meinem überschaulichem Setup wäre die Obscurity ja nicht so mein Problem.

Aber vermutlich ist das Mist, weil wer den Hostnamen hat, der kann doch sicherlich einfach nach den Ports Scannen und gucken wo er rauskommt, oder?

 

[ayron]

Ein letztes Problem hab ich noch: Die FotoStation bekomme ich nicht zum laufen über den ReverseProxy.

1) In der FotoStation unter Einstellungen -->Hostname/statische IP: "foto.myhostname.synology.me"; http:"leer gelassen"; https: "6633"
2) Bei Reverse Proxy den Port für foto.myhostname.synology.me von 443 auf 6633 weiterleiten.
--> Ich kriege die Weiterleitung mit dem üblichen Zertifikatsfehler, danach erscheint aber "502 Bad Gateway - nginx".

 

[Fusion]

Mit der Photo Station geht das so nicht, weil du den Port der Photo Station nicht von 443 auf was anderes ändern kannst.
Den port 6633 den du eingetragen hast ist nur für den Fall, wenn die Portweiterleitung im Router 6633 > 443 ist, damit die Photo Station ihre geteilten Links mit einem von außen erreichbaren Port generiert.

Gab ein paar Threads in Forum, aber musst an den webserver config files etc rumbasteln.

 

[ayron]

Ok danke für die Erklärung!
Kann ich nicht einfach die PhotoStation auf Port 443 lassen, dieser Port ist doch jetzt intern frei. Moments, Drive, DSM, FileStation, NoteStation nutzen doch alle andere Ports.
Wenn ich jedoch foto.myhostname.synology.me 443 --> 443 intern weiterleite funktioniert auch nichts.

Komme ich also um ein "rumbasteln" am Ende nicht herum? Wundert mich irgendwie, wie ist dass den von Synology aus gedacht das man das nutzt?

 

[Fusion]

"Gedacht" ist, dass man https://name.synology.me/photo verwendet.

 

[ayron]

Achso somit geht das ganze aber direkt, ohne das ich irgendetwas weiter einrichten muss! Danke!

Frage ist nur ob das mit den Links zum Teilen auch funktioniert. Aber wenn ich in der photostation-Oberfläche einfach bei domain name.synology.me eintrage und bei Ports nichts weiter einstelle, dann sollte es glaub ich funktionieren?

Welchen Vorteil hätte ich vom "rumbasteln" an den config-files denn? Das ich für die photostation eine eigenenständige Domain habe, oder noch weitere Vorteile?