Zwei Domains, wie trennen?

[MisterY]

Hi,

ich habe zuhause einen Proxmox-Server stehen und habe zwei Domains, eine bei Strato und eine bei no-ip.org.
Ich würde gerne es so haben, dass die Strato-Domain auf VM1 zeigt und No-IP auf VM2 und Server 2. Wenn man die Strato-Domain eintippt, soll man überhaupt nichts von VM2 und Server2 mitbekommen. Wie mache ich das am besten?

 

[p4n0]

Du willst sicherlich auf den 'security-thread' von letzter Woche hinaus..

Wenn du keine 2 IP Adressen nach draußen hast bringt dir dein Vorhaben eh nix.

Ein OpenVAS gegen deinen Anschluss laufen lassen und man weiß welche Dienste bei dir laufen.. Egal auf welcher VM.

Grueße

 

[TCM]

Einfach einen HAProxy oder sonstigen Reverse-Proxy auf die Adresse hängen, der je nach Domain vom entsprechenden Server ausliefert. Wo soll da das Problem sein?

 

[MisterY]

und wie geht das mit dem HAProxy?

 

[p4n0]

Das Problem besteht darin, dass er nur 1 oeffentliche IP hat und deswegen die Domains NIE ordentlich voneinander trennen werden kann.

 

[TCM]

Wie wärs mal mit technischen Details? Nur durch Wiederholung wirds nicht wahrer.

 

[fdsonne]

Das Problem besteht darin, dass er nur 1 oeffentliche IP hat und deswegen die Domains NIE ordentlich voneinander trennen werden kann.

Der Sinn hinter dem HA/Reverse Proxy wäre in diesem Fall genau die Trennung
Bspw. anhand der genutzten URL auf den einen ODER eben den anderen internen Server weiter zu leiten...

Von "außen" brauchst du genau eine IP und einen Port, damit das funktioniert. Da bekommt auch kein anderer was davon mit, kein OpenVAS würde sehen, was da noch für Domains drauf laufen usw. usf.


PS: die Aussage, Domains von einander zu trennen ist technisch gesehen übrigens kappes
Nur so als kleine Randanmerkung... Die zwei genannten Domains sind perse schon getrennt. Denn der, der von der einen Domain weis, weis schlicht nix von der anderen, es sei denn, man sagt ihm was davon... Genau an diesem Punkt würde in Reverse Proxy VOR dem eigentlichen Diensteserver eben aufgehen. Denn nur der Reverse Proxy kennt die Zuordnung. Und der der mit einer falschen URL kommt, wird entweder ganz abgeweisen oder irgendwo auf eine Dummy Page geleitet. Der Rest mit der richtigen URL bekommt den Kontent, den er sehen soll -> fertig.


Eine andere Alternative wäre bspw. einfach IPv6 zu nutzen

 

[p4n0]

Der Sinn hinter dem HA/Reverse Proxy wäre in diesem Fall genau die Trennung
Bspw. anhand der genutzten URL auf den einen ODER eben den anderen internen Server weiter zu leiten...

Von "außen" brauchst du genau eine IP und einen Port, damit das funktioniert. Da bekommt auch kein anderer was davon mit, kein OpenVAS würde sehen, was da noch für Domains drauf laufen usw. usf.


PS: die Aussage, Domains von einander zu trennen ist technisch gesehen übrigens kappes
Nur so als kleine Randanmerkung... Die zwei genannten Domains sind perse schon getrennt. Denn der, der von der einen Domain weis, weis schlicht nix von der anderen, es sei denn, man sagt ihm was davon... Genau an diesem Punkt würde in Reverse Proxy VOR dem eigentlichen Diensteserver eben aufgehen. Denn nur der Reverse Proxy kennt die Zuordnung. Und der der mit einer falschen URL kommt, wird entweder ganz abgeweisen oder irgendwo auf eine Dummy Page geleitet. Der Rest mit der richtigen URL bekommt den Kontent, den er sehen soll -> fertig.


Eine andere Alternative wäre bspw. einfach IPv6 zu nutzen

Es geht ihm aber darum die Dienste zu 'verstecken' die er daheim hosted... Und wenn die Domains beide auf seine IP daheim zeigen, dann geht das einfach nicht. Da bringt dir auch
n HA/Reverse Proxy nix.

Er hat auf der einen Moehre Owncloud oder sonstiges am laufen und auf der andern VM halt sein Zeug was public gehosted werden soll.

Wenn er mir jetzt seine URL von dem Public Kram posted dann kann er NICHTS sinnvolles tun, um seinen Owncloud oder sonstigen privaten Kram vor mir zu verstecken.

Außer er stellt den privaten Kram in nen gesondertes Netz und regelt das per VPN. Sobald aber beides Public erreichbar ist gewinnst du mit nem Scanner sofort.
(Und da ist es auch voellig egal ob da N Domains drauf zeigen, die sind eh belanglos wenn die Zieladresse bekannt ist...)

Grueße

 

[TCM]

Wenn du die Domain nicht kennst, kannst du auch nicht auf den Server hinter dem Proxy zugreifen. Und Zugriff auf eine Domain offenbart auch nicht automatisch die andere Domain.

 

[TheBigG]

Per Reverse IP Lookup oder Letsencrypt falls ein Cert für alle Seiten genutzt wird rauszufinden welche Domains auf einer IP gehostet werden ist kein Problem. Das ganze schon auf dem Webserver per HTTP Auth abzufangen wäre hier wohl der beste weg, weil dann müsste man erst mal das knacken bevor man die Application an sich angreifen kann.

 

[fdsonne]

Es geht ihm aber darum die Dienste zu 'verstecken' die er daheim hosted... Und wenn die Domains beide auf seine IP daheim zeigen, dann geht das einfach nicht. Da bringt dir auch
n HA/Reverse Proxy nix.

Genau das ist doch gegeben bei einem Reverse Proxy... Von "außen" siehst du NUR den Reverse Proxy. Nichts anderes! Was da an Diensten läuft, ist somit perse versteckt. -> eben der Sinn eines Reverse Proxys, der die Verbindung von außen terminiert und nach intern neu aufbaut anstatt eben mit einem Portforwarding zu arbeiten oder direkt bis ins LAN reinzurouten.
Dem TE gehts doch offenbar darum, den Personengruppen, die Zugriff über die eine oder andere URL auf die Dienste haben, untereinander den Zugriff auf die Dienste der anderen URLs zu verstecken... Genau das macht der Reverse Proxy

Da ist (in deinem Beispiel mit Owncloud), einzig und allein HTTPS offen. Der Reverse Proxy zeigt die Owncloud Instanz einzig und allein dann, wenn du auf "owncloud.domain.tld" zugreifst. Nicht aber auf "x.x.x.x" oder "wasweisich.no-ip.tld" oder welche Domain auch immer. -> alle Anfragen (bei richtiger Konfiguration) auf URLs abseits von "owncloud.domain.tld" laufen ins Leere -> oder werden wo auch immer hin umgeleitet, wenn gewünscht. Deswegen kannst du immernoch eine Nextcloud Instanz hinter der selben public IP hosten, die auf "nextcloud.blablub.no-ip.org" lauscht. Und der Nutzer, der "owncloud.domain.tld" müsste schon ziemlich gut raten um auf "nextcloud.blablub.no-ip.org" zu kommen und umgekehrt.

Wenn er mir jetzt seine URL von dem Public Kram posted dann kann er NICHTS sinnvolles tun, um seinen Owncloud oder sonstigen privaten Kram vor mir zu verstecken.

Das halte ich für ein Gerücht
Du müsstest schlicht und ergreifend raten wie die Namen für die dir nicht bekannten Dienste sind, damit dich der Reverse Proxy da drauf lassen würde... Das würde bestenfalls dann gehen, wenn du A) den Reverse Proxy kompromitierst, B) dich mit nem Port Mirror VOR den Anschluss klemmst und jegliche Anfragen mitsnifferst und/oder C) auf der Client Seite den Traffic mitsnifferst...

Technisch gesehen geht das sogar soweit, dass du den Spaß sogar noch mit einem DynDNS Anbieter kombinieren kannst. So nutze ich das bspw. bei mir Zuhause. Da gibt es ein paar public Domains, verschiedene, wo gewisse Personengruppen auch nix gegenseitig von Wissen. Alle leiten in dem Fall auf einen DynDNS Eintrag und dieser zeigt auf meinen Reverse Proxy. Der Reverse Proxy hängt hinter einem NAT am stino VDSL Anschluss. Und es ist einzig und allein HTTS aka 443/tcp offen. Der Reverse Proxy gibt dabei NUR dann eine Seite zurück, wenn du mit der richtigen URL ankommst. Kommst du mit der falschen, bspw. direkt mit dem DynDNS Eintrag, der IP oder sonstweden anderen Namen -> bekommst du einfach NICHTS.

Per Reverse IP Lookup oder Letsencrypt falls ein Cert für alle Seiten genutzt wird rauszufinden welche Domains auf einer IP gehostet werden ist kein Problem.

Man nutze einfach einen Reverse Proxy, welches mehrere Zertifikate für die verschiedenen URLs hinterlegt hat... Damit eben genau die anderen URLs NICHT in dem einen Zertifikat hinterlegt sind.
Valide public Zertifikate für no-ip.org zu bekommen dürfte aber so ziemlich unmöglich sein!? Keine Ahnung...

 

[TCM]

Per Reverse IP Lookup oder Letsencrypt falls ein Cert für alle Seiten genutzt wird rauszufinden welche Domains auf einer IP gehostet werden ist kein Problem.

Jetzt wirds langsam ganz schön wischiwaschi. Hier mal abschließend alles, was man wissen muss:

Es gibt unterschiedliche Sachverhalte:

1) Kann jemand durch Zugriff auf eine Domain oder Zugriff auf den Server herausfinden, welche anderen Domains dieser Server anbietet? Nein bzw. nur durch brute-force aller möglichen Domainnamen oder Abhören der Serverleitung, was wir hier mal außen vor lassen. Zusätzlich gilt allerdings, dass DNS eine öffentliche Datenbank ist. Wenn jemand die Vorwärtszuweisungen von Domain -> IP-Adresse regelmäßig speichert und abfragbar macht, wäre natürlich auch hierüber trivial rauszukriegen, was der Server alles hostet, sofern die Domains erfasst sind.
2) Kann jemand, der zwei Domains kennt, überprüfen, ob diese auf demselben Server liegen? Natürlich ist das trivial. Dieser Fall war hier aber nicht gegeben. Falls das auch gefordert ist, bringt der Proxy natürlich nichts. Solche Sachen wie Zertifikate nicht auf beide Domains gleichzeitig ausstellen verstehen sich natürlich von selbst und liegen auch komplett in der Hand des Admins.

Ansonsten besteht der Zugriff auf die Domains aus HTTP-Requests, die einen gültigen Host:-Header enthalten sollten. Unbekannte Domains und Zugriffe ohne Header sollte man an der Stelle abweisen. Damit muss jeder Client im Vorfeld wissen, welche Domain er vom Server haben will und kann das nicht einfach rausfinden, wie hier mehrfach ohne Beleg behauptet wurde. Magische Scanner gibt es nicht.

 

[TheBigG]

Jetzt wirds langsam ganz schön wischiwaschi. Hier mal abschließend alles, was man wissen muss:

An meiner aussage ist garnichts Wischiwaschi, eher fängst du mit Wischiwaschi an. https://reverseip.domaintools.com/

Aber glaub was du willst, aber dann verkaufe es nicht als fakt bzw. stelle alle was du nicht kennst nicht als Magie da.

 

[TCM]

Genau das hab ich doch auch geschrieben. Ohne den Link bedeutet "reverse lookup" allerdings erstmal was völlig anderes. Und diese Seite muss erstmal überhaupt an seine Domains kommen. Einfach so tauchen die da nämlich auch nicht auf. Wenn du schon so neunmalklug daherkommst, kannst du vielleicht noch erklären, was das mit der HTTP-Auth sollte. Das trägt nämlich zum Problem überhaupt nichts bei. Und der andere Kollege wollte direkt am Anschluss irgendwas scannen, was Quatsch ist und bleibt.

 

[TheBigG]

HTTP Authentifizierung per Nutzer und Passwort oder alternativ per Clientzertifikat würde ich empfehlen vor die Application zu schalten damit Lücken in der Application (owncloud oder what ever) nicht direkt ausgenutzt werden können. Die Wahrscheinlichkeit das im Webserver an sich eine Lücke ist (wenn man ihn aktuell hält) ist niedriger als die Wahrscheinlichkeit das alle Applicationen die dahinter sind sicher sind. Stichwort weniger Angriffsfläche bieten, VPN ist leider nicht überall der gangbare weg.