Reverse Proxy - Subdomain öffnet sich mit Port und Zertifikat vom DSM

[Fred Feuerstein]

Hallo zusammen,

mir stellt sich gerade ein Problem, welches mich ziemlich verzweifeln lässt, da ich es nicht gelöst bekomme.
Ich hoffe das von Euch einer daraus schlau wird und vielleicht die Lösung parat hat.
Es stellt sich wie folgt dar.


Ausgangssituation

Ich verfüge für meine Diskstation über eine Domain (z.B. meinedomain.de).
Zu dieser sind für die diversen Anwendungen der Diskstation Sub Domains via cname gepflegt.
Bislang habe ich in der NAT meines Routers Ports hinter der Anwendung zu Diskstation durchgereich und die Anwendung entsprechend im DSM-Anmeldportal gepflegt.
Das funktionierte auch immer reibungslos.


Ziel / Wunschgedanke

Jetzt habe ich allerdings die Vorstellung mittels dem DSM Reverse Proxy die Anzahl der in der NAT durchgereichten Ports auf das mögliche Minimum zu reduzieren und somit die Angriffsfläche auf meine Diskstation und mein LAN weiter zu reduzieren.
Hierfür habe ich im Reverse Proxy folgende Regel erstellt und entsprechend das zugehörige LE Zertifikat zugewiesen.

QUELLE
Protokoll: HTTPS
Hostname: anwendung.meinedomain.de
Port: 443
HSTS aktiviert

ZIEL
Protokoll: HTTPS
Hostname: 127.0.0.1 (localhost & Host-IP auch getestet)
Port: 54627 (Port der Anwendung)

Der Aufruf der Seite über https funktioniert so schon mal problemlos.

Wenn jetzt jedoch ein Aufruf der URL ohne Angabe des Protokolls oder mit http erfolgt, resultiert ein Redirect auf https://anwendung.meinedomain:5001 (DSM-Port) und es wird das DSM-Zertifikat gezogen.
Also falscher Port und Zertifikat, folglich wird vom Browser auch ein Sicherheitsrisiko ausgegeben.

Das Anlegen einer weiteren Reverse Proxy Regel mit Quelle HTTP / Port 80 und gleichen Ziel bringt auch keine Abhilfe :-(

Ich habe diverse Einstellungen durchgespielt und mit jeweils gelöschten Browsercache getestet, aber immer das gleiche Problem.
Leider finde ich auch im WWW keine weiteren Anhaltspunkte zur Lösung.

Kennt von Euch jemand dieses Problem und hat vielleicht die Lösung hierzu?


Danke und Gruß,

Martin

 

[Ulfhednir]

Du hast ja auch HSTS aktiviert.
Unabhängig verstehe ich nicht, warum du überhaupt Port 80 für HTTP öffnen möchtest, wenn es generell sicherer ist HTTPS zu verwenden.

 

[Fred Feuerstein]

HTTP war nur testhalber, für einen Redirect oder ob der Reverse Proxy eine Regel nach HTTPS anwenden kann.

Meinem Verständnis nach sollte HSTS ja auch greifen wenn die URL ohne vorangestelltes Protokoll aufgerufen wird. Jedoch funktioniert es bei mir so nicht, es erfolgt kein Redirect auf die entsprechende Anwendung, sondern auf DSM Port und Cert. :-(

Grundsätzlich ist mein Ziel auch auf HTTP zu verzichten. Der Port 80 sollte dann nur noch für den Reverse Proxy und LetsEncrypt in der NAT und DSM-Firewall gepflegt sein.

 

[Ulfhednir]

HSTS erzwingt die Verwendung von HTTPS für die jeweilige Domain. Die Information bleibt dann auch im Browser gespeichert.
Was passiert denn, wenn du einen anderen Browser verwendest, und gezielt: http://anwendung.meinedomain.de:80 aufrufst? Ebenfalls die Weiterleitung auf https://dsm:5001? Hast du etwas im Anmeldeportal verstellt - auf 80/443 umgestellt? Hast du vielleicht in der Webstation einen eine Art index.html mit einem redirect eingerichtet?

Das wären jetzt die Punkte, die ich als erstes Mal abklappern würde.

 

[Fred Feuerstein]

Firefox und Edge liefern unter http://anwendung.meinedomain.de:80 das gleich Problem.

Irritierender Weise kann Chrome aber mit allem umgehen.
Dieser kann mit allem provoziert werden, also mit http oder mit https und Port 80 oder ohne, der Chrome findet immer das korrekte Ziel, also https://anwendung.meinedomain.de:1234 inkl. dem zugehörigen Zertifikat.

Es ist außschließlich der Reverse Proxy in der DSM-Firewall auf Port 80/443 konfiguriert.

Die Webstation habe ich nicht in use, also nicht einmal installiert.

 

[Fred Feuerstein]

Ich kann Erfolg vermelden

Das Thema HTTPS Redirect konnte ich mit einer *.conf im Folder /usr/local/etc/nginx/conf.d/ erschlagen.
Die Datei enthält nur folgendes:
server {
listen 80;
listen [::]:80;
server_name *.meine.domain
return 301 https://$http_host$request_uri;
}

Somit sind nun HTTPS Einträge im Anmeldeportal > Reverse Proxy ausreichend und es ist in der URL kein vorgestelltes https:// erforderlich.
Den DSM Zugriff habe ich mit einem Zugangskontrollprofil auf mein lokales LAN und VPN eingegrenzt.


Lediglich die DS File App ärgert mich noch ein wenig.

• Für diese muss ich weiterhin den definierten HTTPS-Port in der NAT pflegen und diesen auch bei der Anmeldung via App nutzen, also z.B. file.meine.domain:54321
• Ich kann den Port auch nicht über den Reverse Proxy nutzen, vermutlich fehlen mir hier noch Angaben im Header, da sobald ich über den Proxy gehe bekomme ich "Anmeldedaten ungültig" als Fehler gemeldet.

Hat hier jemand eine Idee, wie ich diesen Port aus der NAT verbannen kann oder zumindest die Anmeldung über den Proxy realisiert bekomme?

 

[Fusion]

Systemsteuerung > Anwendungsportal / Loginportal > Anwendungen da gibt es funktionierende Reverse Proxies die sich eben "benutzerdefinierte Domain" nennen für die Syno-eigenen Dienste wie die File Station. Auch Header und 301 redirects werden da im Hintergrund schon automatisch gesetzt.
In DS File (Version, Android 4.14.0-468) muss man allerdings immer noch file.example.com:443 eintragen, weil der sonst die 5001 benutzt. Bis Synology das irgendwann mal überarbeitet. In einem Webbrowser hingegen reicht auch file.example.com

 

[Fred Feuerstein]

Hhm, es läuft ja bereits recht sauber, nur die File App will nicht so richtig.

Der 301 Redirect auf https erfolgt ja bereits, wenn ich die FileStation in einem Browser via http://file.meinedomain.de aufrufe. Der Reverse Proxy übernimmt das forwarding von 443 auf localhost:54321

Lediglich um die App nutzen zu können muss ich aktuell in der NAT noch den Port der entsprechenden lokalen IP zuordnen. Aber ich möchte am liebsten auf diese Konfiguration in der NAT schließen können.

Wenn ich jetzt unter Systemsteuerung > Anmeldeportal > Anwendungen die ‚Benutzer definierte Domain‘ konfiguriere, habe ich meiner Ansicht nach nichts gewonnen, da komme ich ja ursprünglich her.

Und ob ich in der App jetzt file.example.com:443 oder file.example.com:54321 verwenden muss, nimmt sich jetzt auch nichts, oder?

Vielleicht habe ich aber auch einen Denkfehler.


Otherwise any other ideas?!

 

[Fusion]

"meinedomain.de" gehört übrigens einer Firma, das sollte man nicht verwenden, wenn sie einem nicht gehört.

Irgendein Port muss ja offen sein, wenn man kein Relay-Dienst verwenden will.

Ich war jetzt davon ausgegangen, dass 443 dieser Port sein soll.
Sprich extern > 443 > NAS, dort die Entscheidung wer dienst.example.com verarbeitet.

Dafür sind die benutzerdefinierten Domains eben da.
54321 muss dafür in der Router-Firewall weder geöffnet sein, noch muss dafür irgendeine Weiterleitung definiert sein.
Aber den habe ich auf auf der NAS nirgends definiert, bei Anwendungen nur die benutzerdefinierte Domain und sonst überhaupt nichts.

Und dass man file.example.com:443 in DS File eingeben muss liegt eben an der App und nicht an der Portfreigabe. Im Browser geht es ja auch, der bei https stillschweigend 443 benutzt.
Aber 443 muss dafür trotzdem im Router offen sein.

Kann dir nur sagen, dass es so funktioniert mit benutzerdefinierten Domains und nur Port 443 offen.
Wo der Fehler liegt, wenn man stattdessen einen benutzerdefinierten Port für die Anwendungen definiert und dann einen reverse Proxy darauf setzt.... und das nur bei der File Station nicht funktioniert....fehlt mir gerade die Muse dazu dies nachzustellen.

Nur noch zwei Punkte die mir grad im Kopf rumspuken:
Externer Zugriff > Erweitert sollte leer sein.
Die dynDNS Domain sollte keine der für Dienste verwendeten Domains sein.

 

[Fred Feuerstein]

Asche über mein Haupt, jetzt hast Du mir die Augen geöffnet.

Mir wollte es nicht in den Kopf gehen, das man der App selbst bei geforderten HTTPS noch den :443 mitgeben muss.
Das erschien mir sowas von abwegig, dass ich es stumpf selbst mit Deinem Hinweis nicht verstehen wollte.

Jetzt ist alles prima, danke für die Unterstützung.


In meinem Router ist seitens der NAT, nun fast alles geschlossen.
Es sind nur noch 80 (Redirect 443), 443, Drive Server, Hyper Backup Vault konfiguriert.

Beide letzteren sind aber glaube ich eine andere Baustelle, da nicht http-Protokoll.

Danke nochmals und Gruß,
Martin