Verständnisfrage Reverse Proxy aus Synology NAS

[Don-DCH]

Hallo zusammen,

ich habe eine Verständnisfrage bezüglich des Reverse Proxys auf meinem Synology NAS.

Mein Verständnis ist so, dass normalerweise ja Verbindungen bis zum Server hin komplett verschlüsselt sind, sofern der Aufruf über HTTPS erfolgt. Sprich wenn ich die Domain Google.com aufrufe sind alle daten verschlüsselt anbei ein Schaubild:

Ich habe bei mir ein Synology NAS, auf dem sich ganz leicht der Reverse Proxy einrichten lässt, nun verstehe ich aber nicht ganz die Funktionsweise, für mich sieht es so aus, als ob die Verbindung aufgebrochen werden würde.



Wenn ich jetzt von einem Client auf meine Subdomain navigiere, erstmal unabhängig ob extern oder Intern (DNS Umschreibung, das er immer auch intern auf das NAS Zeigt, da aktuell keine Portfreigabe) https://www.musik.meinnas.com dann findet, so mein Verständnis die Verbindung zum Reverse Proxy ja in jedem Fall verschlüsselt statt. Der Reverse Proxy muss aber die Pakete an den Server/Docker Container im selben Netzwerk weiterleiten. Nun passiert das ja über HTTP, wieso bekomme ich dann trotzdem eine vollkommen verschlüsselte Verbindung im Browser angezeigt?

Ich verstehe es so, das der Reverse Proxy die Verbindung aufbricht oder zumindest unverschlüsselt weiterleitet, was ja im eigenen Netzwerk nicht so schlimm ist, wenn es auf dem gleichen NAS ist sehe ich es noch unktritischer.

Anbei nochmal ein Schaubild, wenn ich meine Domainaufrufe bekomme ich eine gesicherte Verbindung, aber ich verstehe nicht weshalb, da ab dem Reverse Proxy ja http verwendet wird.

Sind die Anmeldedaten Beispielsweise trotzdem sicher?

Oder bricht der Reverse Proxy die Verbindung auf?



Ich hoffe, dass Ihr meinen Ansatz/Denkweise versteht und mir helfen könnt licht ins dunkle zu bringen 😊

Viele Grüße

 

[TheHille]

Meine Erfahrungen mit HAProxy auf OpnSense: Du hast die Wahl zwischen http oder https bei der Verbindung zwischen Proxy und deinem Server...
Ich kann da auch ein Zertifikat einbinden und den Port auf z.B. 443 ändern.

Weiß aber nicht, ob das bei Synology auch geht. Ich tippe mal auf schon?

Du müsstest bei dem Docker-Container auch den Webservice auf https umstellen und dies entsprechend in den Reverse-Proxy-Einstellungen im NAS einstellen.


Hier die Doku von Synology selbst:

Reverse Proxy-Regeln anpassen​

Ihre Synology NAS kann als Reverse Proxy-Server fungieren, der Anfragen aus dem Internet zu Geräten im lokalen Netzwerk überträgt. Mithilfe von Reverse Proxy-Regeln können Sie sensible Ports vor potenziellen Bedrohungen wie in den beiden folgenden Szenarios verbergen:


Szenario 1: Angenommen, 80 sei der sensible Port, der gemäß der Firewall-Regel keinen externen Zugriff zulassen darf. Sie können eine Reverse Proxy-Regel einrichten, um es vertrauenswürdigen Benutzern zu ermöglichen, über das Internet den sensiblen Port 80 über einen anderen Port (z. B. 81) zu erreichen. Auf diese Weise können vertrauenswürdige Benutzer die Firewall umgehen und trotzdem auf den Port 80 zugreifen.


Szenario 2: Angenommen, 80 sei der sensible Port, der den externen Zugriff nur über ein bestimmtes Gerät (z. B. einen Server mit dem Namen "MyTrustee") zulassen darf. Mithilfe von Reverse Proxy-Regeln können Sie es einrichten, dass nur Verkehr von MyTrustee den Port 80 erreicht, von anderen Geräten jedoch nicht.

Reverse Proxy-Regeln einrichten:​

1. Gehen Sie zu Systemsteuerung > Anwendungsportal > Reverse Proxy.
2. Klicken Sie auf Erstellen und nehmen Sie die folgenden Einstellungen auf der Seite Allgemeinvor:
   • Beschreibung: Geben Sie einen Namen an, der auf die Funktion der Regel schließen lässt.
   • Geben Sie die Regeln für die Quelle (das Gerät, das Anfragen aus dem Internet sendet) und das Ziel(das Gerät im lokalen Netzwerk) an:
     • Protokoll: Die von Quelle bzw. Ziel verwendeten HTTP- oder HTTPS-Protokolle
     • Hostname: Der Name des Quell-/Zielgeräts
     • Port: Der vom Quell-/Zielgerät verwendete Port
     • HSTS aktivieren und HTTP/2 aktivieren (nur für die Quelle)
3. Um ein Zugangskontrollprofil festzulegen, klicken Sie auf Zugangskontrolle aktivieren und wählen Sie ein Zugangskontrollprofil aus. Weitere Informationen zum Erstellen eines Zugangskontrollprofils finden Sie im Abschnitt Zugangskontrollprofile anpassen unten.
4. 
   

   Anmerkung:​

   • Klicken Sie im Dropdown-Menü Erstellen auf WebSocket, um den WebSocket-Funktionsheader rasch zu erstellen, damit Reverse Proxy WebSocket unterstützt.
5. Das weitere Verhalten von Reverse Proxy können Sie auf der Seite Erweiterte Einstellungenanpassen.
   • Proxy Verbindungstimeout (Sek.): Legen Sie das Proxy-Zeitlimit für die Verbindung zum Zielserver fest.
   • Proxy Senden-Timeout (Sek.): Legen Sie das Proxy-Zeitlimit für an den Zielserver gesendete Anfragen fest.
   • Proxy Lese-Timeout (Sek.): Legen Sie das Proxy-Zeitlimit für das Warten auf Antwort vom Zielserver fest.
   • Proxy HTTP-Version: Wählen Sie die HTTP-Version aus, die für die Kommunikation zwischen Proxy-Server und Zielserver verwendet wird.
   • Die vom Zielserver zurückgeschickte Fehlerseite verwenden: Wenn der Zielserver HTTP-Fehlercode zurückschickt, wird die Fehlerseite des Zielservers angezeigt, wenn diese Option aktiviert ist. Ansonsten wird die Synology NAS-Fehlerseite angezeigt.
6. Klicken Sie auf OK, um die Einstellungen zu speichern.

https://kb.synology.com/de-de/DSM/help/DSM/AdminCenter/application_appportalias?version=6

Hier ein Beispiel:

https://strobelstefan.de/2021/02/18...ehrere-dienste-oder-geraete-verwenden-teil-2/

 

[Helge01]

Meine Erfahrungen mit HAProxy auf OpnSense: Du hast die Wahl zwischen http oder https bei der Verbindung zwischen Proxy und deinem Server...

Aber auch da wird die Verbindung aufgebrochen.

für mich sieht es so aus, als ob die Verbindung aufgebrochen werden würde

Das ist korrekt. Die Verbindung wird bis zum Reverse Proxy per HTTPS verschlüsselt und dort aufgebrochen. Anschließend geht es dann zum Backend entweder wieder verschlüsselt oder unverschlüsselt weiter.

 

[up.whatever]

wieso bekomme ich dann trotzdem eine vollkommen verschlüsselte Verbindung im Browser angezeigt?

Dein Browser weiß nichts davon, was hinter dem Reverse Proxy passiert. Aus Sicht des Browsers ist der Reverse Proxy der Webserver.

 

[TheHille]

@Helge01 jupp, sehe ich auch so. Aber sicher sollte das ganze trotzdem sein, siehe @up.whatever

 

[KillerCow]

Je nachdem, welches Tool du als reverse Proxy einsetzt, kannst du auf verschiedene Arten die Verbindungen weiterleiten. HAProxy und nginx, um mal zwei populäre Tools zu nennen, können sowohl als TCP, als auch http(s) Proxy arbeiten.

Zu beachten bei einem Reversproxy: Die Zielsysteme sehen per se erstmal nur und einzig die IP des Proxies als Quell-IP! Heißt, du siehst erstmal nicht, wer wirklich mit dir redet.
Aber dafür gibt es Abhilfe. Arbeitet man auf TCP-Ebene, dann gibt es "proxy protocol". Arbeitet man auf http(s)-Ebene, dann nutzt man passende Header, um die originale Quell-IP weiterzuleiten.

Unterschied TCP/http(s) Proxy:

• TCP: arbeitet auf Layer 4. Was oben drüber gesprochen wird (z.B. TLS, http, was auch immer), interessiert den Proxy nicht. Das wird alles 1:1 an das Zielsystem weitergereicht. Nur die TCP-Verbindung wird auf dem Proxy beendet und eine neue zum Zielsystem aufgebaut.
• http(s): Der Proxy spricht http und im Falle von https auch TLS. In diesem Modus kann/muss der Proxy dann die http-Anfrage manipulieren... z.B. Header verändert/hinzufügen/löschen usw.

 

[Helge01]

Aber sicher sollte das ganze trotzdem sein

Das bezweifel ich auch nicht sonst hätte ich ein großes Problem.

 

[KillerCow]

Ich verstehe es so, das der Reverse Proxy die Verbindung aufbricht oder zumindest unverschlüsselt weiterleitet, was ja im eigenen Netzwerk nicht so schlimm ist, wenn es auf dem gleichen NAS ist sehe ich es noch unktritischer.

In dem Fall terminiert der Proxy die TLS Verbindung, genau. Ob er nach hinten raus dann http oder wieder https spricht, kannst du dir aussuchen. Erstere Variante nennt man auch gerne "TLS-Termination Proxy" oder "TLS-Offloading". Zweitere Variante kenne ich unter "reencrypt".

Ob die unverschlüsselte Kommunikation innerhalb deines Heimnetzes sicher ist, kannst nur du bewerten

 

[Helge01]

TCP: arbeitet auf Layer 4. Was oben drüber gesprochen wird (z.B. TLS, http, was auch immer), interessiert den Proxy nicht. Das wird alles 1:1 an das Zielsystem weitergereicht. Nur die TCP-Verbindung wird auf dem Proxy beendet und eine neue zum Zielsystem aufgebaut.

Nicht nur die TCP-Verbindung, es kann auch da die TLS Verbindung z.B. am HAProxy beendet und die Verbindung damit aufgebrochen werden (SSL Offloading), genau wie bei HTTP/HTTPS Offloading.

 

[KillerCow]

Ich wollte es nicht noch undurchsichtiger machen, als es schon ist. Aber ja, vollkommen korrekt 👍

Richtig krank wird es in dem Szenario aber, wenn man gemischte http1.1/http2 Verbindungen auf TCP-Ebene mit TLS-Termination und Reencrypt fährt. Ich habe es zumindest noch nicht geschafft, im haproxy-backend alpn dynamisch auf das Protokoll zu setzen, das im Frontend ausgehandelt wurde... Daher muss ich im Frontend via use_backend-if-Konstrukt das Protokoll checken und das passende Backend benutzen, mit statisch gesetztem alpn
Aber das führt hier zu weit

 

[Don-DCH]

Vielen herzlichen Dank euch für die schnellen und zahlreichen Rückmeldungen!

Allgemein geht es mir nicht explizit um den Reverse Proxy vom Synology NAS, natürlich würde ich mich anhand dessen auf eine Erklärung freuen. Mir ist es wichtig zu verstehen ob die Verbindung aufgebrochen wird bzw. entscheidend für mich ist. Wenn ich jetzt einen Docker Container habe auf dem gleichen oder einem anderen NAS und nach außen hin wie im Beispiel weine https Domain nach außen freigebe und das intern über http weiterleite ist das ganze ja bis zum Proxy absolut sicher und verschlüsselt, richtig?

Also würde nichts dagegen sprechen, das ganze so zu betreiben oder?

Ein Einsatz über HTTPS wäre mir generell am liebsten aber bei mancher Software ist das für mich zumindest sehr kompliziert und schränkt im Beispiel von Musik auch an ansteuern von Sonos etc. ein, da über HTTPS das leider nicht geht.

@TheHille
Vielen herzlichen Dank dir für die ausführlcihe Beschreibung und das Beispiel. Allerdings wird da HTTPS zu HTTP Weitergeleitet aber komischerweise der Port 5001 genommen welcher nur auf HTTPS hört bei Synology, vermute da einen kleinen Fehler in der Konfig. Bei Nextcloud macht er eine HTTPS Weiterleitung.

Das praktische ist ja, dass der Proxy ja das Zertifikat bereitstellt. Sprich ich brauche auf dem Reverseproxy NAS ein SSL Zertifikat beispielsweise von Lets Encrypt und dann habe ich zu allen Diensten eine interne sichere Verbindung oder muss Nextcloud oder der Dienst der über HTTPS dann auch ein ofizielles Zertifikat dann haben, weil dieses dann anstelle des Reverse Proxy Zertifikats genommen wird?

--So vermeidet man Vollzitate--

Vielen Dank, das war meine Frage, wie steht es um die SIcherheit, würdest du sagen das kann man gefahrenlos so betreiben um Musik unterwegs zu hören. Meiner Meinung nach spricht nichts dagegen. EIn VPN Wäre in jedem Fall besser, mir geht es aber um genau die oben gezeigte Konstellation. Reverse Proxy mit Zertifikat, unt intern HTTP. Das sollte ja sicher sein oder?

--So vermeidet man Vollzitate--

Ok, das heißt, wie oben gefragt, wäre es egal, ob ich auf HTTP oder HTTPS weiterleite, es wird immer nur das Zertifikat des Reverse Proxy berücksichtigt? Und das bei dem Server hinten dran kann ein selbstsigniertes sein beispielsweise?

--So vermeidet man Vollzitate--

Das heißt es gibt doch ein Einfallstor oder wie genau meinst das?

--So vermeidet man Vollzitate--

Hmm, generell finde ich verschlüsselt immer besser, aber woran amcht man es fest ob es sicher ist http zu nutzen, was wären da für dich faktoren?
Habe Smart Home Geräte in einem Extra Netz, falls du in die RIchtung magst ?

 

[Helge01]

Innerhalb deines privaten Netzwerkes spielt es keine Rolle ob die Verbindung weiterhin verschlüsselt ist. Ist dein Netzwerk kompromittiert dann hält die verschlüsselte Verbindung keinen Angreifer auf, der greift gleich auf den Server/NAS zu. Ich glaube kaum das bei dir jemand mit Wireshark das Netzwerk zu Hause überwacht.

Innerhalb meines Netzwerkes werden normalerweise alle Verbindungen verschlüsselt. Aber gerade die Verbindungen vom HAProxy (Reverse Proxy) zu den Servern im Backend sind bei mir unverschlüsselt, da nur so die IPS (Intrusion-Prevention-System) die Netzwerkverbindung belauschen kann um Angriffe abwehren zu können.

 

[KillerCow]

es wird immer nur das Zertifikat des Reverse Proxy berücksichtigt? Und das bei dem Server hinten dran kann ein selbstsigniertes sein beispielsweise?

Der Client, der von "draußen" kommt, sieht nur das Zertifikat des haproxy, wenn der die TLS-Terminierung übernimmt, genau. Dem haproxy kannst du dann sagen, ob er das Zertifikat deines Servers prüfen soll oder nicht (verify-Parameter).

Das heißt es gibt doch ein Einfallstor oder wie genau meinst das?

Das mit der Quell-IP ist nur spannend, wenn du einen IP-Filter auf dem Server benutzen willst, um den Zugriff abzusichern oder in einem Zugriffslog die originalen IPs sehen willst oder ähnliches. Ohne weitere Maßnahmen siehst du da nur die IP des haproxy. Das solltest du zumindest im Hinterkopf behalten.
Zum Umgehen, wie schon beschrieben, entweder haproxy im http-Modus betreiben und passende "forwarded" Header setzen (und hoffen, dass die Zielanwendung die auswertet) oder im tcp-Modus "proxy-protocol" benutzen, sofern die Zielanwendung das kann. Letzte Möglichkeit, haproxy als transparenten Proxy betreiben, aber dann wirds noch etwas lustiger.

aber woran amcht man es fest ob es sicher ist http zu nutzen

Wie andere schon geschrieben haben, im Heimnetz tut unverschlüsselt in der Regel nicht weh. Mit halbwüchsigen Kindern, denen man vielleicht hier und da den Zugriff auf bestimmte Ressourcen blockieren möchte, wäre ich da dann schon etwas vorsichtiger. Die sind heutzutage recht erfinderisch

 

[Don-DCH]

@Helge01 und @KillerCow Vielen Dank euch nochmal, ich glaube damit ist mir so einiges klar geworden

Eine abschließende Frage habe ich noch, oft wird gesagt das noch ein Websocket benötigt wird (In den Docker Anleitungen)
Dies kann man über die Optionen einfügen, anbei ein Screenshot

Ich verstehe aber nicht ob man es wirklich benötigt.
Einen schönen Artikel habe ich auf :
https://www.ionos.de/digitalguide/websites/web-entwicklung/was-ist-websocket/
gefunden, aber wenn ich es richtig verstehe benötige ich nicht zwingend ein Wbesocket, man kann aber auch gefahrenlos generell einen hinzufügen, stimmt das so?

Viele Grüße und ein schönes Wochenende euch!

 

[KillerCow]

Das mit den Headern brauchst du nur, wenn dein Proxy auf http-Ebene arbeitet. Wenn er auf TCP-Mode arbeitet, bekommt er davon nichts mit und kann auch keine Header einbauen.

Die Header kannst du theoretisch gefahrlos setzen. Wenn eine Anwendung keinen WebSocket benutzt, dann setzt sie die Header nicht bzw. dann sind die eher uninteressant. Probier es einfach. Wenn du sie setzt und du hast dann Probleme mit http-basierten Anwendungen, dann nimm sie raus und schau, ob es dann geht. Eventuell muss man da dann noch etwas Feintuning reinstecken.

 

[Don-DCH]

Hmm, weißt du wie ich das rausfinden kann auf welcher Ebene mein Proxy arbeitet?
Ich leite generell HTTPS anfragen über die Domain an meinen Localhost HTTP. HSTS ist ebenfalls gesetzt.