Reverse-Proxy: DSM-Proxy, Traefik oder nginx-proxy?

[Bowman68]

Liebe Alle,

ich betreibe auf meiner auf DS620slim bereits mehrere Dienste unter Docker / Docker-Compose, die jedoch nur lokal zugreifbar sind - und bleiben sollen (z.B. Paperless-NGX). Zukünftig möchte ich auf der Synololy jedoch auch meine bisher auf einer externen VM gehosteten Webdienste (Nextcloud, Wordpress) betreiben, natürlich ebenfalls in Docker-Containern, jedoch extern zugreifbar. Auf der derzeitigen extern gehosteten VM laufen diese Dienste momentan hinter einem recht einfachen Reverse-Proxy (jwilder/nginx-proxy), zukünftig sollen sie auf der Synology natürlich ebenfalls hinter einem Reverse-Proxy laufen.

Qual der Wahl: Welchen würdet ihr empfehlen?

Grundsätzlich möchte ich die Dinge möglichst wenig komplex und einfach konfigurierbar halten, den von Synology in DSM mitgelieferten Reverse-Proxy habe ich noch nicht probiert, finde ihn aber recht interessant und würde ihn grundsätzlich gerne nutzen. Allerdings möchte ich direkt auf dem Synology-System laufende Dienste (wie den Synology-Proxy) möglichst wenig im Internet exponieren (sei es auch nur unter Port 443), daher frage ich mich, ob es unter Sicherheitsaspekten nicht sinnvoller wäre, einen Reverse-Proxy mit eingeschränkten Rechten in Containern (Traefik oder nginx-proxy) zu nutzen. Alle Container-Dienste nutzen jeweils eigene Bridge-Netze, die in der Synology-Firewall entsprechend eingeschränkt sind (insbesondere um die nur lokal zu erreichenden Dienste zu schützen)

Wie schätzt ihr die Sicherheit des Gesamt-Setups ein, abhängig davon, ob man den Synology- oder 'containerisierte' Reverse-Proxys nutzt? Wie ist das mit der Firewall der Synology und deren Wirksamkeit beim Einsatz von 'containerisierten' Reverse-Proxys? Ich würde z.B. gerne alle Anfragen auf 443, die von ausserhalb Deutschlands kommen, grundsätzlich blocken. Traefik finde ich spannend, allerdings für meine Zwecke evtl. ein bisschen zu sehr over-the-top und ich habe damit noch keine Konfigurationserfahrung...

Was wären eure Empfehlungen?

 

[plang.pl]

Der Synology-eigene RP basiert auch auf einem nginx. Ist aber sehr beschnitten. Zumindest bei der GUI.
Ich verwende den NGINX Proxy Manager.
Hier vielleicht noch ein interessanter Thread für dich: https://www.synology-forum.de/threads/swag-vs-nginx-proxy-manager.127388/#post-1085057

 

[Ulfhednir]

Qual der Wahl: Welchen würdet ihr empfehlen?

Ganz einfach: Den der deine Anforderungen an der Sicherheit erfüllt, mit dem du auch klar kommst bzw. den bei dem du den besten "Support" erwarten kannst. Ich behaupte jetzt mal, dass deutlich über 95% der Benutzer in diesem Forum einen Nginx basierten Proxy verwenden. Ich schließe mich da als SWAG-User ein. Wenn du bei Traefik Probleme bekommst, stehst du möglicherweise hier im Forum mit deinen Fragestellungen alleine dar.

Wenn man dazu noch Benchmarks (die aller Wahrscheinlichkeit im Heimgebrauch gar nicht zu Buche schlagen) heranzieht, steht Nginx besser dar.
https://medium.com/beyn-technology/...fik-v3-20-faster-than-traefik-v2-f28ffb7eed3e

Es wird sicherlich auf Vorzüge für Traefik geben. Heise schreibt hier z.B.:

Der wesentliche Vorteil: Traefik 2.0 kann nicht nur HTTP, sondern beliebigen TCP-Verkehr verarbeiten und TLS terminieren.

Wenn ich das richtig interpretiere, könnte ich damit z.B. eine RDP-Session durchschleifen ohne ein TS-Gateway einsetzen zu müssen.
Aber das sind für mich eher Business-Funktionaltitäten.

Bei Nginx sehe ich mit Synology drei Abstufungen:
1.) Standard-Synology-Implementierung: Dürfte für viele Benutzer, die größtenteils "nur" auf Synology eigene Dienste verwenden vollkommen ausreichen. Wenn du allerdings Anwendungen besitzt, die kein zusätzlichen Login anbieten (z.B. Dashboards wie Heimdall)
solltest du eine Stufe weiter gehen.
2.) Wäre dann der Nginx-Proxy-Manager. Hat ein schönes Frontend und bietet auch bereits Basis-Authentifizierungen, um einen zusätzlichen Schutz zu gewährleisten.
3.) SWAG ist dann die "Hardcore"-Variante, bei der du die direkt Konfigurationsdateien ohne Frontend anpassen musst. Diese sind dafür aber auch in brauchbarer Weise vorgefertigt. Zudem gibt es direkt ordentliche Konfigurationen für MFA-Login wie Authelia.

Solltest du dich für Nginx entscheiden, musst du halt selbst entscheiden, was dich am meisten anspricht. Ich kann dir zumindest so viel mitgeben, dass die Lernkurve bei SWAG enorm ist und man ein gutes Grundverständnis zum Proxy aufbauen kann.

 

[plang.pl]

Der NGINX RP kann auch stumpf einen Port weiterleiten.

 

[Bowman68]

...vielen Dank für die bisherigen Antworten!

Ganz einfach: Den der deine Anforderungen an der Sicherheit erfüllt, mit dem du auch klar kommst bzw. den bei dem du den besten "Support" erwarten kannst.

...so halte ich es auch erstmal, drum habe ich jetzt den von Synology im DSM mitgelieferten Reverse-Proxy in Betrieb.

Meine Überlegungen kreisten ja hauptsächlich um Sicherheitsbedenken: Ist es sicherer, einen mit begrenzen Nutzerrechten laufenden Reverse-Proxy in einem extra Container zu betreiben, verglichen mit dem im DSM verfügbaren Proxy, der ja letztlich direkt im Hostsystem läuft? Ich kann die Frage nicht beantworten, neme mir die Devise "weniger ist mehr" zu Herzen und nutze daher erstmal den mitgelieferten Proxy. Synology hat damit erstmal einen Vertrauensvorschuss, schliesslich bin ich ja (hoffentlich) nicht der einzige, der das Ding benutzt... ;-) Besondere, damit einher gehende Risiken sind mir zumindest oder gar Sicherheitsvorfälle sind mir zumindest noch nicht bekannt...

Ich habe noch eine Frage zur Firewall-Konfiguration in Verbindung mit der Zertifikatserstellung/-verlängerung durch LetsEncrypt, mache dazu aber einen gesonderten Thread auf...

 

[plang.pl]

Naja ich würde meinen File-Server nicht ins Internet exposen. Egal, ob das der Reverse Proxy oder ein anderer Dienst ist.

 

[Bowman68]

Naja ich würde meinen File-Server nicht ins Internet exposen. Egal, ob das der Reverse Proxy oder ein anderer Dienst ist.

...tu' ich ja auch nicht. Nichtsdestoweniger stellt sich mir die Frage, wie weit ein auf dem Hostsystem laufender Proxy unsicherer ist als ein in einem Container laufender (letztlich ja auch auf dem Hostsystem, aber in einem anderen Namespace)...

 

[plang.pl]

Für interne Zwecke sehe ich da kein Problem.

 

[Bowman68]

Für interne Zwecke sehe ich da kein Problem.

...für interne Zwecke brauche ich keinen Proxy, da kann ich auch direkt per lokaler IP und Portnummer auf die Dienste zugreifen. Nein, mir geht es schon um Dienste, die aus dem Internet erreichbar sein sollen...

 

[plang.pl]

Na also. Dann würde ich das nicht machen.
Reverse Proxy heißt nicht automatisch, dass der nach extern offen ist. Ich betreibe einen Reverse Proxy nur intern, um 1. eine zentrale Stelle für Zertifikate zu haben und 2. um mir nicht von jedem Container den Port merken zu müssen und 3. um jeden Dienst mit https anzusprechen

 

[Bowman68]

...die Sicherheitsfrage stellt sich mir unabhängig davon, ob das nun auf der Synology läuft oder einem anderen System. Wie ich ja schrieb, beitreibe ich diese Dienste bisher auf einer extern gehosteten VM, dort hinter einem containerisierten nginx-Proxy ebenfalls in Containern. Auch dort will man ja nicht, dass ein in einem Container laufender, aber evtl. kompromittierter Dienst mit seinen Rechten auf die Dateien anderer Dienste zugreifen kann, die in anderen Containern laufen. Dort ist das bekanntlich mit getrennten Namespaces abgesichert. Bisher lief das jahrelang problemlos, warum auch nicht - ein Großteil aller Webdienste wird so betrieben.
Synology ist nicht erst seit gestern am Markt, auf deren NAS laufen auch Dienste die aus dem Netz zugreifbar sein sollen (ich sage nur Mailserver...). Daher gehe ich davon aus, das deren Einstellungen - und mir geht es hier ja nur um den Proxy-Dienst - entspechend gehärtet sind. Für mich neu und nicht ganz geheuer ist nur der Umstand, das der Proxy mit speziellen Systemrechten im Namespace des Hostsystems zu laufen scheint.
Gibt es dazu Hintergrundinfos von Synology oder evtl. andere Threads hier im Forum?

 

[plang.pl]

Mailserver

Ja die DS kann einiges. Aber das heißt noch lange nicht, dass sie das tun soll. Und wer auf seinem NAS, wo die privaten, wertvollen Daten liegen, einen Mailserver hostet, hat eh den Schuss nicht gehört. JM2C
Klar geht man davon aus, dass sie sicher sind. Und stand jetzt sind sie das auch. Aber wenn es mal eine Zero-Day Lücke gibt, sind instant deine ganzen Daten kompromittiert. Da habe ich den RP lieber in einem Container oder noch besser in einer VM, bei der es egal ist, wenn irgendein Hacker / eine Ransomware da einfällt.

 

[Bowman68]

...so, ich bin noch ein bisschen in mich gegangen, ich mach das jetzt anders:

- die aus dem Internet erreichbaren Dienste werde ich in einer auf der Synology laufenden VM betreiben, dort ebenfalls per docker-compose.
- in dieser VM kommt der einfache nginx-Proxy zum Einsatz, den ich auch bisher in der extern gehosteten VM verwendet habe. Der kümmert sich dann auch um LetsEncrypt-Zertifikatsbeschaffung. Der Proxy auf der Synology wird wieder deaktiviert.
- die auf der Synology laufende VM wird in einem anderen Subnetz betrieben und von dem Netz der Synology per Firewall isoliert.
- der Router macht seine Portfreigabe für 80 und 443 direkt in das Netz dieser VM.

...das sollte erstmal reichen. So habe ich die Vorteile der durch die Virtualisierung möglichen besseren Isolation und kompletten Trennung von Userrechten und Dateisystem, kombiniert mit der Speicherung auf der lokalen Synology und deren Möglichkeit, den Zustand der VM per Snapshot zu sichern. Updates/Upgrades eines Systems ohne vorherigen Snapshot finde ich extrem 'unbequem', ich bin da echt ein Weichei...

 

[plang.pl]

Ich nutze auch den NGINX RP im Docker. Nicht auf der DS. Bei der DS musst du ggfs. etwas pfuschen, da die standardmäßig ja auf Port 443 und 80 hört, sodass der nicht an den Container gebunden werden kann. Das kann man entweder mit einem MACVLAN umgehen oder das der DS irgendwie "abtrainieren". Letzteres wäre wohl die bessere Option. Ich weiß auch, dass es geht, aber leider nicht wie.
Was wird das OS der VM werden? Ich empfehle den Ubuntu-Server oder lubuntu (mit schmaler UI)

 

[Janüscht]

Bei IPv4 kann man die NAT im Router nutzen, um den externen Port 443 auf einen internen anderen Port umzuleiten. Dazu ist kein MacVLAN notwendig und auch nicht zu empfehlen.

Bei IPv6 sieht es ein bisschen anders aus, dort muss dann wirklich tätig werden. Eine Möglichkeit dazu wäre: https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7

 

[plang.pl]

Das habe ich so auch nicht gesagt. Es ging darum, dass man an den Docker Container den Port 443 nicht binden kann, da DSM selbst bereits darauf lauscht.

 

[Bowman68]

Ich nutze auch den NGINX RP im Docker. Nicht auf der DS. Bei der DS musst du ggfs. etwas pfuschen, da die standardmäßig ja auf Port 443 und 80 hört, sodass der nicht an den Container gebunden werden kann.

...das ist nicht nötig, da die VM ja mit einer eigenen IP (sogar in einem anderen Subnetz als das der Synology als Host) läuft. Per Portfreigabe im Router wird 80 und 443 wird direkt an die IP der VM weitergeleitet. In dieser läuft dann ein nginx-Proxy, der alle per docker-compose laufenden Dienste erreichbar macht. Das läuft prima, ich bin immer wieder begeistert wie leicht sich so Docker-Dienste migrieren lassen...

Was wird das OS der VM werden? Ich empfehle den Ubuntu-Server oder lubuntu (mit schmaler UI)

Debian 12 in Minimalkonfiguration. Ich habe darin letztlich nur docker und qemu-guest-agent installiert.

 

[plang.pl]

Warum 80? Leite lieber nur 443 weiter.

 

[Bowman68]

Warum 80? Leite lieber nur 443 weiter.

...Port 80 wird von LetsEncrypt bei der Zertifikatsverlängerung für die http Überprüfung benötigt:
https://community.letsencrypt.org/t/is-port-80-required-for-renewals/121432

LetsEncrypt selbst empfiehlt 80 offen zu lassen:
https://letsencrypt.org/docs/allow-port-80/

Da die Kontroll-Anfragen am Router auf 80 reinkommen, der Redirect aber erst im Proxy (in der VM) erfolgt, muss die Anfrage ja erstmal dorthin kommen, daher die Portweiterleitung...