Sicherheit des Synology-Reverse Proxy: Gibt es eine Art öffentliches Verzeichnis von Subdomains?

[foo_1337]

Was meinst du mit dummy zertifikat? Wenn er https terminiert und kein valides cert ausliefert, wird der Browser meckern. Das kann man zwar machen, bringt aber dann andere Nachteile mit sich

 

[DonConto]

Der Kontext war doch, bezogen auf das Auffinden von CNAMEs bzw Subdomains:
Jemand scannt deinen IP Block auf 443 und findet bei dir einen offenen Port und versucht sich zu verbinden. Ich meinte, dass das nichts bringen wird, weil der Reverse Proxy die Anfrage nicht verarbeiten wird (und somit deine Subdomain über diesen Weg unentdeckt bleibt). Du meintest dann, dass man sich nur das Zertifikat anschauen müsse um darüber an die CNAMEs zu kommen. Worauf ich dann sagte, dass das ja nicht das richtige Cert ist sondern nur ein Dummy (also ein self signed von localhost). Ergo: Ein Portscan reicht nicht um an den Namen der Subdomain zu kommen und somit Zugriff auf die dahinter liegenden Services zu bekommen.

 

[sinkpäd]

Im Falle meiner Synology passiert folgendes, wenn ich https://öffentlicheip aufrufe:

Zuerst antwortet eine leere Seite mit einem Self signed Zertifikat (aus dem man leider erkennen kann, dass es von Synology kommt, d.h. der Angreifer sieht, dass eine Synology auf der anderen Seite ist)

Und nach ca. 10 Sekunden scheint der Reverse Proxy einen Redirect zum internen https Port der DSM Oberfläche (bei mir 4443) zu machen, der aber timeoutet, weil der Port nach außen zu ist.

 

[foo_1337]

Worauf ich dann sagte, dass das ja nicht das richtige Cert ist sondern nur ein Dummy (also ein self signed von localhost).

Um das zu realisieren musst du jedoch SNI benutzen, was leider privacy Probleme mit sich bringt, da der Host Header im Klartext übertragen wird. ESNI/ECH sind aktuell Clientseitig viel zu wenig verbreitet um alleine darauf setzen zu können. Und ansonsten gibt es halt noch Dienste, die das für dich erledigen: https://securitytrails.com/dns-trails z.B. Und das dann auch bequem per API.
Aber alles in allem ist das doch security by obscurity. Wenn ich nicht will, dass ein Dritter auf mein Gedöns kommt, muss ich etwas dagegen tun. Mich darauf zu verlassen, dass er den HTTP Hostname nicht errät ist doch grob fahrlässig. Da wäre selbst eine simple basic auth auf dem reverse proxy deutlich sicherer.

@bumbklaatt das ist halt das default self signed, was du austauschen kannst.

 

[sinkpäd]

Ein mögliches Angriffsszenario könnte ja noch sein, wenn man als Angreifer die Möglichkeit hätte, nicht Domains nach Subdomains sondern gezielt viele Domains nach subdomain.wildcard.wildcard zu suchen. So könnte man dann nach nas. / qnap. / ds. / synology. ihr wisst was ich meine suchen und versuchen, diese zu knacken (sofern man es auf das Kapern und evtl. Verschlüsseln von NAS abgesehen hat, was ja viele Angreifer bei Synologys über das IOBroker Addon gemacht haben). Erfolgsversprechender wird aber vermutlich sein, bestimmte IP-Ranges nach den offenen Standardports 5000/5001 zu scannen.

@bumbklaatt das ist halt das default self signed, was du austauschen kannst.

Gerade mit https://www.selfsignedcertificate.com/ eins erstellt, danke!

 

[Rickmer]

Ein 'echtes' Zertifikat kannst du übrigens kostenlos bei letsencrypt bekommen: https://letsencrypt.org/

https://kb.synology.com/en-global/D...tificate_signing_request_on_your_Synology_NAS

 

[DonConto]

Aber alles in allem ist das doch security by obscurity. Wenn ich nicht will, dass ein Dritter auf mein Gedöns kommt, muss ich etwas dagegen tun. Mich darauf zu verlassen, dass er den HTTP Hostname nicht errät ist doch grob fahrlässig. Da wäre selbst eine simple basic auth auf dem reverse proxy deutlich sicherer.

Das ist mir klar, sagte ich ja auch die ganze Zeit. Wie gesagt, der Kontext meiner Antworten ist wichtig :-) Mir ging es nur darum, dass die ganzen automatisierten Zugriffe nach dem Portscan ins Leere laufen wenn der Reverse Proxy nur auf bestimmte Subdomänen antwortet: "Du willst auf IP:443 zugreifen? Kenn ich nicht -> weg."

 

[sinkpäd]

Ein 'echtes' Zertifikat kannst du übrigens kostenlos bei letsencrypt bekommen: https://letsencrypt.org/

Nutze ich natürlich für meine korrekten Subdomains. Für die "Dummyseite" ist es mir aber lieber, ein komplett anonymisiertes self signed Zertifikat zu nutzen.

 

[frogy76]

Wenn ein Angreifer nun meine öffentliche IP auf offene Ports scannt, 80 und 443 findet und anspricht, passiert erstmal nichts. Der Reverse-Proxy leitet dann nämlich auf den DS-internen http-Port (bei mir 8080 statt 5000) bzw. den internen https-Port (4433 statt 5001) um, bekommt aber einen Timeout weil die Ports nicht offen sind.

Wie hast Du die Weiterleitung im Reverseproxy von Synology konfiguriert?

 

[sinkpäd]

@frogy76

Relativ easy eigentlich:

Der Bitwarden Docker-Container läuft auf Port 5555 und das DSM (http) auf 8080

Auf der Fritzbox habe ich nur 80 und 443 geforwarded.

Läuft 1a über die Subdomains. Natürlich müssen einmalig die Records beim Domainanbieter gesetzt werden. Zusätzlich habe ich via SSH den NGINX Reverse Proxy so konfiguriert, dass er automatisch zu https umleitet, wenn man im Browser nur ds.domain.net, also ohne vorangestelltes https:// eingibt.