Reverse Proxy filtert Subdomains nicht wie erwartet

[DaDino]

Hallo Zusammen:

Kurzgesagt:
Ich versuche mit dem Reverse Proxy (DSM Gui), Zugang zu meinen Anwendungen zu begrenzen, indem ich explizite Source-Subdomains und -Ports verwende. Die Erwartung ist, dass anderer Traffic abgewiesen wird. Aber die Begrenzung mit Subdomains arbeitet nicht wie erwartet und lässt doch Traffic durch.


Etwas ausführlicher
Ziel:
Der externe Zugriff auf meine Anwendungen soll nur über Subdomains und einen nicht-Standard Port möglich sein (jaja, letzteres ist leicht paranoid )

Ansatz:

• Ich habe eine Domain & dort mehrere CName Verweise auf einen DynDNS Dienst für meine Subdomains
• Im Router wird ein hoher Port (Port_X) von außen 1:1 an die Diskstation weitergeleitet
• Der Reverse Proxy sieht wie folgt aus (alles https; HSTS&HTTP/2 aktiviert):
  • Subdomain1.meineDomainort_X -> Diskstationort_A
  • Subdomain2.meineDomainort_X -> Diskstationort_B
  • ...
• Ergänzend:
  • Ich mache ein ähnliches Spielchen mit Port 80 für LE Zertifikate meiner Subdomains (Router biegt externen Port 80 auf hohen Port um und der Reverse Proxy schickt wieder an 80 wenn die Subdomain stimmt)
  • Über das Application Portal wurden File & Note Station eigene Ports zugewiesen
  • DS213+ mit DSM 6.1.1 up-to-date

Das Problem:
Anfragen an Port_X über meine externe IP - also nicht über eine der obigen Subdomains - wurden trotzdem an einen der Destination Ports weitergeleitet (scheinbar konstant zur Note Station)
Bei Port 80 das gleiche (d. h. da ging dann alles an Port 80 durch, Subdomain egal)
Es scheint, als würde je verwendetem Port eine Regel zum Default erklärt, die dann greift, wenn keine andere Regel (Subdomain) zutrifft.

Workaround:
Je verwendetem Port vorweg eine Regel definieren, die Traffic von beliebigen Hosts ins Nirwana schickt:
*ort_X -> Diskstation:ungenutzter_Port
Allerdings muss diese Regel vor den anderen Regeln für diesen Port angelegt werden und kann danach auch nicht mehr editiert werden.
Dadurch wird mein o. g. Ziel erreicht, aber es fühlt sich an, als würde man einen Bug mit einem anderen Bug aushebeln und das hinterlässt kein gutes Gefühl.


Fehler meinerseits / WASD? Oder doch ein Bug?
Ich bin für Ratschläge dankbar.

Gruß
Stefan

 

[Fusion]

Das liegt daran, dass der Router kein SNI (Server Name Indicator) betreibt, er entscheidet nur nach Ports, wo er die Pakete hinschickt.
Zudem laufen auf der DS mehrere Webserver. Der System nginx und dann eventuell noch mehrere user-backends.
Der Standard-System webserver lauscht auf * alle Namen. Wenn sich also sonst niemand zuständig fühlt (reverse proxy, vhost, etc) dann wird dies dort landen.

 

[DaDino]

Hi Fusion,
danke für deine Antwort, aber ich kann deine Erklärungen noch nicht so recht nachvollziehen

Das liegt daran, dass der Router kein SNI (Server Name Indicator) betreibt, er entscheidet nur nach Ports, wo er die Pakete hinschickt.

Dass der Router stumpfsinnig nach Port weiterleitet, ist doch ok (oder nicht?). Erst der Reverse Proxy der Diskstation soll schließlich mit dem aufgerufenen Hostname etwas anfangen. Dies funktioniert auch grundsätzlich, da Anfragen mit meinen verschiedenen Subdomains sauber vom Reverse Proxy an die richtigen Ziele geschickt werden.

Der Standard-System webserver lauscht auf * alle Namen. Wenn sich also sonst niemand zuständig fühlt (reverse proxy, vhost, etc) dann wird dies dort landen.

Auf alle Namen lauschen ist ja ok, aber doch hoffentlich nicht auf allen Ports Der von mir benutzte Port ist jenseits der 30000. Ich ging davon aus, dass der dort ankommende Traffic ausschließlich vom extra hierauf angesetzten Reverse Proxy aufgegriffen wird.
Oder lauscht mit dem Reverse Proxy tatsächlich automatisch auch "der Webserver" dort. Wenn ja, wie kann ich festlegen, was "der Webserver" dann tut?
Deine Erklärung würde bedeuten, dass mein Ziel (Alles ignorieren lassen, was nicht explizit erlaubt ist) mit Bordmitteln nicht sauber umsetzbar ist

 

[Fusion]

Das bezog sich auf deine Aussage, dass du die public IP + Port deines Routers aufgerufen hast. Wer/was antwortet oder nicht ist dann die andere Frage.

Die Einstellungen im Anwendungsportal sind nicht exklusiv. z.B. kannst du auch wenn du z.B. 7001 für die File Station definierst diese immer noch über den DSM Port ebenfalls erreichen.
Dann beeinflusst z.B. das Paket Web Station, ob ankommender Traffic auf 80/443 eben von der Web Station bearbeitet wird, oder wenn nicht installiert, wird der Traffic auf die DSM Ports umgebogen.
Soll heißen, dies ist ein recht komplexes Feld an Konfigurationen und Wechselwirkungen (man könnte fast Minenfeld sagen).
Ein Reverse Proxy wird exakt auf den Namen und Port reagieren (es ist eine Option, keine Regel), aber das heißt nicht, dass alles andere automatisch verboten ist bzw, nicht doch jemand lauscht auf den "Rest" für den sich keiner zuständig fühlt.

Allein mit der DSM GUI wird man das glaube ich nicht endgültig in den Griff bekommen so wie du es willst (vielleicht kann mich ja jemand widerlegen).
Und wenn man in der webserver config selber rumbastelt, wird man dies vermutlich bei jedem Update und teilweise Neustart wiederholen müssen.
Da ist es eventuell sinnvoller mit der Firewall nur die bestimmten Ports (deine benutzerdefinierten internen) freizugeben, dann sollte zumindest entweder der Reverse Proxy antworten, oder ein Fehler vom webserver kommen.

Persönlich müßte ich die config nachstellen (oder auch deutlich detaillierter in deine config gehen, als bis jetzt bekannt), um vollständig nachvollziehen zu können, an welchem "Schalter" welches Symptom seine Ursache findet.

 

[DaDino]

Tja, ich habe noch etwas rumprobiert und auch den Support kontaktiert.

• Der Support konnte wohl kaum deutsch (obwohl das Formular das suggeriert ) meinte aber, man solle Application Portal und Reverse Proxy nicht zusammen verwenden. Ich habe das Problem jetzt noch mal auf Englisch erklärt, habe aber wenig Hoffnung.
• Bei meinen zahlreichen Tests (nur über die GUI) habe ich immer den Effekt, dass jede Anfrage letztendlich weitergeleitet wird. Offenbar geht es immer an DSM Desktop, File oder Note Station, und nie an die Photo Station. Der Gedanke "wenn keine Regel zutrifft, dann ignoriere die Anfrage" scheint jedenfalls nie zu greifen.

Da ich für mich vor langer Zeit beschlossen habe, auf Synology Geräten nicht abseits der GUI zu arbeiten (gab m. M. n. langfristig immer blöde Überraschungeffekte) werde ich wohl den Einsatz eines entsprechenden Docker Containers auf meinem unRAID Server prüfen müssen...

Trotzdem vielen Dank für deine Ausführungen und die genommene Zeit Fusion!

Gruß
Stefan

 

[Fusion]

kein Ding.

Liegt vermutlich daran, dass Reverse proxies und Anwendungsportal auf dem System Webserver nginx laufen.
Die Photo Station läuft auf dem benutzer Webserver nginx oder Apache

Wie hast du denn deine Reverse proxies definiert? Ziel localhost?
bzw. wie sieht die Kette aus?
Ich nehm mal Beispiel-Port 1234 und die File Station

https://sub.domain.de:1234 per CNAME auf https://sub.dynDNS.de:1234?
Port 1234 im Router auf 2345 an die DS weitergeleitet?
Im Anwendungsportal für die File Station https-Port 2345 definiert?
Oder noch eine Umleitung vergessen? (da bekommt man ja Kopfschmerzen )

Vielleicht bringt ein anderer Weg ein besseres Ergebnis.
Anwendungsportal NUR eine benutzerdefinierte Domain sub.domain.de (wie beim Hoster definiert) nehmen. Der lauscht dann auf Port 443.
Im Router dann eben 1443 auf 443 weiterleiten und von außen dann https://sub.domain.de:<1443> aufrufen.

Wenn die Web Station nicht aktiv ist sollte ein Aufruf von https://public-ip:1443 dann versucht werden auf den DSM Port (Systemsteuerung > Netzwerk > DSM Einstellungen, oder falls von Externer Zugriff > Erweitert überstimmt eben an diesen Port) umzubiegen. Da dieser aber im Router nicht freigegeben ist, schlägt die Verbindung fehl. Nur https://file.domain.de:1443 landet auf dem richtigen Ziel.

 

[DaDino]

Die Kette ist wie folgt (und ja, das macht Kopfschmerzen )

1. Subdomain[1|2|3|4].MeineDomain.de zeigen jeweils per CName Eintrag auf MeinDynDNS.synology.me (d. h. 4 CNAME Einträge zeigen auf den einen Synology DynDNS Eintrag)
2. MeinDynDNS.synology.me zeigt auf meine öffentliche IP
3. Der Router forwarded den externen Port 12345 direkt an den gleichen internen Port an meiner Diskstation

Der Reverse Proxy der Diskstation greift den Traffic nach folgenden Regeln auf:
https://Subdomain1.MeineDomain.de:12345 ==> https://IP_der_Diskstation:11111 ( = DSM Desktop)
https://Subdomain2.MeineDomain.de:12345 ==> https://IP_der_Diskstation:22222 ( = File Station - über Application Portal eingestellt)
https://Subdomain3.MeineDomain.de:12345 ==> https://IP_der_Diskstation:33333 ( = Note Station - über Application Portal eingestellt)
https://Subdomain4.MeineDomain.de:12345 ==> https://IP_der_Diskstation:443 ( = Photo Station - Port ist ja leider nicht änderbar)

Über https://meine_öffentliche_IP:12345 bin ich gerade eben wieder beim DSM Desktop gelandet, d. h. der Proxy hat mich trotz falschem Hostname weitergeleitet. Der direkte Port ist definitiv geschlossen im Router!
Besonders ärgerlich: Dann kriegt man auch mein Zertifikat zu sehen, welches als Alternative Hosts meine weiteren Domains ausweist
Grundsätzlich kann der Reverse Proxy aber die Hostnames interpretieren, denn Anfragen mit den richtigen Subdomains werden korrekt umgesetzt.

Die Intention hinter diesem Konstrukt ist, dass zum einen die Masse der typischen Port 443 Scans ins Leere läuft und zum anderen auch jemand, der bewusst bei mir alle Ports scannt, letztendlich nur zum Reverse Proxy durchkommt.

 

[DaDino]

Neue Erkenntnisse meinerseits zu diesem Thema, vielleicht für Anwender mit gleichem Ziel noch von Interesse:

Der Reverse Proxy (nginx) braucht immer einen "default server" je genutztem Source Port und bei Synology bekommt wohl die erste je Source Port erstellte Regel diesen Status. Bei dieser Regel ist der Source Hostname (Subdomain/Domain) scheinbar völig egal.
D. h. wann immer auf einem vom Reverse Proxy belauschtem Source Port Traffic eingeht und es hierzu keine Regel mit passendem Source Hostname gibt, wird der Traffic einfach über die erste Regel ( "default server") für diesen Source Port weitergeleitet.

So zumindest mein Eindruck. Man korrigiere mich bitte, falls ich damit völlig falsch liege.

 

[Fusion]

Ist bei dir die Web Station installiert? (edit: Dachte wegen Portumbiegungen (ohne WS wird 80/443 auf den DSM Port umgeleitet), ist vermutlich aber uninteressant, sieht weiter unten)

Du kommst von außen auf https://subX.domain.de:12345, der Router leitet diesen Port 1 zu 1 an die DS.
Der Hostname kann ausgewertet werden, also findet eine weitere Umleitung über einen der Reverse Proxies zur IP der DS und einem Anwendungs-spezifischen Port statt.
Kommst du via https://public-IP:12345 leitet der Router auch erst mal weiter an die DS.

Hier die Kurztests bei mir (Anfrage immer mit IP, mit Hostnamen funktioniert es ja):
Kein Reverse Proxy mit 12345 definiert, ohne Web Station > Anfrage läuft ins Leere
Kein Reverse Proxy mit 12345 definiert, mit Web Station > Anfrage läuft ins Leere
Reverse Proxy A mit 12345 definiert (auf localhost 80), ohne Web Station > Anfrage landet auf localhost und wird auf DSM 5000 umgeleitet.
Reverse Proxy A mit 12345 definiert (auf localhost 80), Reverse Proxy B mit 12345 definiert (auf localhost 81), ohne Web Station > Anfrage landet auf localhost und wird auf DSM 5000 umgeleitet
Reverse Proxy A mit 12345 definiert (auf localhost 81), Reverse Proxy B mit 12345 definiert (auf localhost 80), ohne Web Station > Anfrage landet zwar auf nginx spuckt aber ein 502 Bad Gateway aus.
Reverse Proxy A mit 12345 definiert (auf localhost 80), Reverse Proxy B mit 12345 definiert (auf localhost 81), mit Web Station > Anfrage landet auf localhost und zeigt die Standard-Webseite der WS.
Reverse Proxy A mit 12345 definiert (auf localhost 81), Reverse Proxy B mit 12345 definiert (auf localhost 80), mit Web Station > Anfrage landet zwar auf nginx spuckt aber ein 502 Bad Gateway aus.

Ich denke es ist der erste erstellte Reverse Proxy mit einem Source Port (hatte zwar komische Erscheinungen mit erstellen, löschen, Reihenfolge, aber vermutlich nur Browser Cache ursächlich)
Jetzt ist die Frage, wenn man die Liste der Reverse Proxies einfach neu erstellt, welchen Dummy Eintrag man als erstes erstellt für den Port 12345 und wohin umleitet, um den Verkehr "auszuschalten".

Eventuell mal ein Ticket bei Syno, ob sie da nicht was verbessern können.

 

[DaDino]

Danke für die ergänzenden Testreihen. Dann kommen wir wohl zum gleichen Resümee
Schon lustig, wenn man als Kunde die Funktionsweise so per trial und error rausfinden muss.
Passend dazu kam heute von Synology auf meine Supportanfrage von letzter Woche genau der Workaround, den ich in meinen ursprünglichen Post hatte: Erst eine Regel mit * Hostname anlegen und ins Leere zeigen lassen.

Entsprechend habe ich jetzt darum gebeten, mein Ticket in einen Feature Request zu verwandeln:
Die GUI sollte es ermöglichen den "default server" Status zu setzen oder zumindest diesen anzuzeigen (und die Wirkung in der Hilfe zu verdeutlichen)