Entwurf für Web-Server und Netzwerkdesign
Hallo an alle.
Ich fange am besten erst einmal mit den Informationen zur Situation an
Wir haben eine Web basierte Software entwickelt.
Wird die Software von einem Kunden erworben, richten wir dort einen Server ein.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Zum Problem:
Auf manchen Kunden-Servern ist zusätzlich noch ein Ngninx installiert, der an andere Ports weiterleitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Das erschwert es mir unheimlich ein DNS Forwarding für die internen Clients einzurichten.
Ich habe einen Design erstellt, wie das ganze Setup nach meinem Verständnis nach auszusehen hat.
Dieses Entwurf möchte ich euch jetzt zeigen, um eure Meinungen dazu zu hören.
Entwurf:
Mein Entwurf
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
Ich fange am besten erst einmal mit den Informationen zur Situation an
Wir haben eine Web basierte Software entwickelt.
Wird die Software von einem Kunden erworben, richten wir dort einen Server ein.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Zum Problem:
Auf manchen Kunden-Servern ist zusätzlich noch ein Ngninx installiert, der an andere Ports weiterleitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Das erschwert es mir unheimlich ein DNS Forwarding für die internen Clients einzurichten.
Ich habe einen Design erstellt, wie das ganze Setup nach meinem Verständnis nach auszusehen hat.
Dieses Entwurf möchte ich euch jetzt zeigen, um eure Meinungen dazu zu hören.
Entwurf:
Mein Entwurf
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
Please also mark the comments that contributed to the solution of the article
Content-ID: 92405677220
Url: https://administrator.de/contentid/92405677220
Printed on: November 5, 2024 at 06:11 o'clock
11 Comments
Latest comment
Moin,
das klingt nach ziemlich Gemurkse mit Portweiterleitungen und Proxys.
Wenn Du keinen Plan hast wie das funktioniert wer dann?
Am besten ist es wenn man auf die Kunden IT gar nicht angewiesen ist.
Ausgehende VPN/SSH/Irgendwas Verbindung die von deren IT erlaubt ist.
Fertig.
Stefan
PS: Dein Link geht nicht
das klingt nach ziemlich Gemurkse mit Portweiterleitungen und Proxys.
Wenn Du keinen Plan hast wie das funktioniert wer dann?
Am besten ist es wenn man auf die Kunden IT gar nicht angewiesen ist.
Ausgehende VPN/SSH/Irgendwas Verbindung die von deren IT erlaubt ist.
Fertig.
Stefan
PS: Dein Link geht nicht
Das sagen sie All. Inklusive mir
Alle 3 Versionen von Dir kann man machen.
Wobei ich die 1. und 3. vorziehen würde, denn in Deiner Ansicht fehlt eine WAF.
Jeder Form von Webanwendung wird früher oder später, eher früher, angegriffe und mit Brute-Force und Scannern belegt. Bei der 2. Variante bräuchte man bei jedem Kunden eine WAF.
Die Variante mit dem ausgehenden VPN wäre meine Empfehlung.
Aber auch die Variante mit dem Proxy funktioniert solange die Strecken per SSL gesichert sind.
Portweiterleitungen sind technisch simpel und Fehler lassen sich einfacher finden als VPN-Fehler (KISS).
Wir haben selber eine WAF für Exchange-Server entwickelt weil die meisten UTM Firewalls sehr wenig in Petto haben um interne Server vor Externe Webzugriffe zu schützen.
Stefan
Ich hab mich der Problematik angenommen und möchte der Geschäftsleitung
aufzeigen, wie es richtig umzusetzen ist.
Lobenswertaufzeigen, wie es richtig umzusetzen ist.
Auf die IT vom Kunden sind wir leider angewiesen.
Das ist ja auch kein Problem.Ein Rechenzentrum besitzen wir nicht, naja, noch nicht.
Das tun die meisten anderen Firmen die es behaupten auch nicht.Alle 3 Versionen von Dir kann man machen.
Wobei ich die 1. und 3. vorziehen würde, denn in Deiner Ansicht fehlt eine WAF.
Jeder Form von Webanwendung wird früher oder später, eher früher, angegriffe und mit Brute-Force und Scannern belegt. Bei der 2. Variante bräuchte man bei jedem Kunden eine WAF.
Die Variante mit dem ausgehenden VPN wäre meine Empfehlung.
Aber auch die Variante mit dem Proxy funktioniert solange die Strecken per SSL gesichert sind.
Portweiterleitungen sind technisch simpel und Fehler lassen sich einfacher finden als VPN-Fehler (KISS).
Wir haben selber eine WAF für Exchange-Server entwickelt weil die meisten UTM Firewalls sehr wenig in Petto haben um interne Server vor Externe Webzugriffe zu schützen.
Stefan
Zitat von @Ueba3ba:
Ist eine WAF denn nicht unbedingt bei 1 und 3 notwendig?
Auf dem zentralen Reverse Proxy sollte dann doch eine WAF sein?
Auch bei 3 müsste dann auf dem zentralen Proxy eine WAF sein.
Bei 2 verstehe ich es. Da sollte dann bei jedem Kunden eine WAF sein.
Ist eine WAF denn nicht unbedingt bei 1 und 3 notwendig?
Auf dem zentralen Reverse Proxy sollte dann doch eine WAF sein?
Auch bei 3 müsste dann auf dem zentralen Proxy eine WAF sein.
Bei 2 verstehe ich es. Da sollte dann bei jedem Kunden eine WAF sein.
Eine WAF sollte man immer haben sobald es wichtige Software oder Daten geht.
Bei 2 brauchte man ganz viele WAFs die man pflegen und überwachen muss.
Bei 1 und 3 gibt es einen zentralen Proxy.
Das braucht man dann nur eine WAF.
Stefan
Moin,
meine unmaßgebliche Meinung:
Für mich wäre best practice, erst einmal in der Entwicklungsabteilung nachzufragen, von wo nach wo Euer Programm Verbindungen aufbaut. Denn da stellst Du ja im Wesentlichen Vermutungen an. Als Hersteller aber müsst Ihr es wissen. Und Umschaltungen auf core1 etc. werden ja irgendwo in der Programmlogik gemacht, ebenso wie irgendwelche zusätzlichen SSH Tunnel. Das sollte wohl erst einmal konsolidiert werden, alleine schon aus Sicherheitsgründen, um möglichst wenige "Eingänge" und damit möglichst wenige Angriffspunkte zu bieten.
In diesem Sinne verstehe ich auch das nicht:
Ich gehe doch davon aus, dass die Benutzer-Oberfläche eine WebApp ist, die auf dem IIS läuft. Wozu muss dann die Datenbank über Ports von außen (oder auch nur aus dem LAN) erreichbar sein? Es reicht doch vollkommen aus, wenn die WebApp auf dem Server lokal die Datenbank ansprechen kann. Wenn das wirklich so ist, dass die Datenbank von einem Punkt außerhalb des Servers zu erreichen ist, würde ich das ganz schnell deaktivieren.
verschlüsselt.
Das z.B. ist ein Trugschluss. Nur weil irgendwo Zertifikate installiert sind, bedeutet das ganz sicher nicht, dass überhaupt SSL benutzt und vor allem durchgängig, von A bis Z, eine verschlüsselte Verbindung genutzt wird. Das aber ist natürlich unabdingbar.
Wenn klar ist, welche Verbindungen wirklich genutzt werden müssen, dann solltet Ihr Euch auf 2 Varianten einstellen:
a) der Kunde will alles in seinem Zugriff haben
Bedeutet: kein fremder (=Euer) Proxy, keine fremden Zertifikate und Domains (also solche, auf die - nur - Ihr Zugriff habt, sondern Terminierung direkt auf der Firewall des Kunden. Da dann mit den Vorschlägen von @StefanKittel.
b) dem Kunden ist das egal
Dann könnt Ihr die vorgelagerten Sachen von Euch nutzen, dann aber idealerweise auch direkt mit VPNs abgesichert.
Gruß
DivideByZero
meine unmaßgebliche Meinung:
Zitat von @Ueba3ba:
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
Für mich wäre best practice, erst einmal in der Entwicklungsabteilung nachzufragen, von wo nach wo Euer Programm Verbindungen aufbaut. Denn da stellst Du ja im Wesentlichen Vermutungen an. Als Hersteller aber müsst Ihr es wissen. Und Umschaltungen auf core1 etc. werden ja irgendwo in der Programmlogik gemacht, ebenso wie irgendwelche zusätzlichen SSH Tunnel. Das sollte wohl erst einmal konsolidiert werden, alleine schon aus Sicherheitsgründen, um möglichst wenige "Eingänge" und damit möglichst wenige Angriffspunkte zu bieten.
In diesem Sinne verstehe ich auch das nicht:
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Ich gehe doch davon aus, dass die Benutzer-Oberfläche eine WebApp ist, die auf dem IIS läuft. Wozu muss dann die Datenbank über Ports von außen (oder auch nur aus dem LAN) erreichbar sein? Es reicht doch vollkommen aus, wenn die WebApp auf dem Server lokal die Datenbank ansprechen kann. Wenn das wirklich so ist, dass die Datenbank von einem Punkt außerhalb des Servers zu erreichen ist, würde ich das ganz schnell deaktivieren.
Aber auch die Variante mit dem Proxy funktioniert solange die Strecken per SSL gesichert sind.
Richtig. Es wird in diesem Fall mit LetsEncrypt Zertifikaten gearbeitet. Also ist die Verbindung SSLverschlüsselt.
Das z.B. ist ein Trugschluss. Nur weil irgendwo Zertifikate installiert sind, bedeutet das ganz sicher nicht, dass überhaupt SSL benutzt und vor allem durchgängig, von A bis Z, eine verschlüsselte Verbindung genutzt wird. Das aber ist natürlich unabdingbar.
Wenn klar ist, welche Verbindungen wirklich genutzt werden müssen, dann solltet Ihr Euch auf 2 Varianten einstellen:
a) der Kunde will alles in seinem Zugriff haben
Bedeutet: kein fremder (=Euer) Proxy, keine fremden Zertifikate und Domains (also solche, auf die - nur - Ihr Zugriff habt, sondern Terminierung direkt auf der Firewall des Kunden. Da dann mit den Vorschlägen von @StefanKittel.
b) dem Kunden ist das egal
Dann könnt Ihr die vorgelagerten Sachen von Euch nutzen, dann aber idealerweise auch direkt mit VPNs abgesichert.
Gruß
DivideByZero
Zitat von @Ueba3ba:
Wird die Software von einem Kunden erworben, richten wir dort einen Server ein.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Als Kunde würde ich mich Fragen, warum überhaupt ein Zugriff vom Hersteller von extern notwendig sein sollte, wo doch alles schon im Haus steht (Hardware, Windows Systeme inkl. Lizenzen, DB inkl. Lizenzen, Applikation inkl. Lizenz).
Irgendwie erschließt sich mir der Sinn überhaupt nicht, warum ein so komplizierter Zugriffsweg implementiert werden muss.
Es hört sich eher nach SaaS an. Dann braucht man doch aber nichts beim Kunden direkt zu implementieren.
Moin,
ich würde erst einmal hinterfragen, warum überhaupt differenziert wird - von Kunde zu Kunde. Weil das macht die Fehlersuche und die Dokumentation jeder Installation nicht einfacher. Sowas muss aus aus meiner Sicht standardisiert sein, egal wie klein wie groß der Kunde ist, welche Modul er (nicht) nutzt, etc. Das was ihr da habt ist ein Zoo...
Gruß,
Dani
Auf manchen Kunden-Servern ist zusätzlich noch ein Ngninx installiert, der an andere Ports weiterleitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ich würde erst einmal hinterfragen, warum überhaupt differenziert wird - von Kunde zu Kunde. Weil das macht die Fehlersuche und die Dokumentation jeder Installation nicht einfacher. Sowas muss aus aus meiner Sicht standardisiert sein, egal wie klein wie groß der Kunde ist, welche Modul er (nicht) nutzt, etc. Das was ihr da habt ist ein Zoo...
Das erschwert es mir unheimlich ein DNS Forwarding für die internen Clients einzurichten.
Beim Kunden oder bei euch?Gruß,
Dani