interne webanwendung öffentlich zugänglich machen [gelöst]
interne webanwendung öffentlich zugänglich machen [gelöst]
hallo,
was wäre der geschickteste weg eine webanwendung mit datenbank im internen netz fürs internet freizugeben(MediaWiki).
wir haben einen webserver in einer dmz stehen und die anwendung läuft auf nem server im internen netz.
kann ich da ne indexseite bauen fürs internet welche auf den internen server weiterleitet?
oder muss ich die webanwendung auf den webserver in der dmz stellen so das diese nur die datenbankverbindung ins interne netz herstellt.
gruesse rene
was wäre der geschickteste weg eine webanwendung mit datenbank im internen netz fürs internet freizugeben(MediaWiki).
wir haben einen webserver in einer dmz stehen und die anwendung läuft auf nem server im internen netz.
kann ich da ne indexseite bauen fürs internet welche auf den internen server weiterleitet?
oder muss ich die webanwendung auf den webserver in der dmz stellen so das diese nur die datenbankverbindung ins interne netz herstellt.
gruesse rene
Zuletzt geändert von rene04 am 07.10.2005 07:56:10, insgesamt 1-mal geändert.
Am einfachsten wäre wohl, wenn Du das Wiki auf den Server in der DMZ verlegst. Alternativ kannst Du auf dem Server in der DMZ einen Proxy für das Wiki im internen Netz einrichten. Ich denke das geht auch mit dem Apachen, aber die Details dazu kenn ich nicht
Bert
Bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
Ich habe das mit mod_proxy in der httpd.conf[ realisiert:
Dazu noch die FW angepaßt und fertig.
Code: Alles auswählen
ProxyRequests Off
ProxyPass /egroupware http://192.168.66.12/egroupware
ProxyPassReverse /egroupware http://192.168.66.12/egroupware
Hi rene,
ich habe nicht mehr gemacht als schon beschrieben:
1. in der apache config mod_proxy geladen
( LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so )
2. die o.g. Zeilen in die passende virtual host Sektion eingetragen
3. in der Firewall die Kommunikation von DMZ-Webserver und internem Server für Port 80 freigeschaltet.
Damit kann ich öffentlich über https://www.domain.tld/egroupware auf den Webserver zugreifen, der unter http://192.168.66.12/egroupware läuft.
that's it
ich habe nicht mehr gemacht als schon beschrieben:
1. in der apache config mod_proxy geladen
( LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so )
2. die o.g. Zeilen in die passende virtual host Sektion eingetragen
3. in der Firewall die Kommunikation von DMZ-Webserver und internem Server für Port 80 freigeschaltet.
Damit kann ich öffentlich über https://www.domain.tld/egroupware auf den Webserver zugreifen, der unter http://192.168.66.12/egroupware läuft.
that's it
Hi Rene,
kann ich dir nicht sagen, ich lese hauptsächlich englische Dokus. Auch wenn ich deutsche Dokus mag, so sind die englischen meist aktueller...
Such nach den oben genannten Stichwörternbei google und grenze die Sprache ein.
blogsearch.google.com könnte auch eine Anlaufstelle sein, sry mehr kann ich dir dazu nicht sagen.
kann ich dir nicht sagen, ich lese hauptsächlich englische Dokus. Auch wenn ich deutsche Dokus mag, so sind die englischen meist aktueller...
Such nach den oben genannten Stichwörternbei google und grenze die Sprache ein.
blogsearch.google.com könnte auch eine Anlaufstelle sein, sry mehr kann ich dir dazu nicht sagen.
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
da du es aussprichst - komisches design das alles? - die datenbank und der webserver gehören in die DMZ - backup der DB und evt. der daten am webserver triggerst du dann vom internen LAN heraus - die firewall zwischen DMZ und internem LAN ist dann so eingerichtet das der Webserver oder der DB server niehmals von selbst verbindungen ins LAN aufbauen kann ...herrchen hat geschrieben:nur mal so angemerkt:
wenn du dem webserver in der DMZ zugriff ins interne netz gibst, ist der sinn der DMZ dahin.
herrchen
so wie das jetzt ist kannst du die DMZ für marketing zwecke auf plakaten anführen aber sonst ...?
![Wink :wink:](./images/smilies/icon_wink.gif)
markus
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
ihr meint also das eine dmz auszeichnet das alles was in ihr steckt keine verbindung zum internen netz aufbauen darf, auch nicht wenn dieser explizit durch eine firewall geöffnet wurde? hmmm, und was ist wenn der webserver in der dmz gehackt wird? dann kommen die auch an die db ran. oder wie darf ich mir das vorstellen? bin da etwas unerfahren.
gruesse rene
gruesse rene
- herrchen
- Beiträge: 3257
- Registriert: 15.08.2005 20:45:28
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Berlin
http://de.wikipedia.org/wiki/DMZrene04 hat geschrieben:aha, so langsam verstehe ich den sinn einer dmz ;) was für eigenschaften hat die noch so?
herrchen
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
http://en.wikipedia.org/wiki/Demilitari ... mputing%29
1)
hier ist dann die DB/Webserver worst case am Galgen - du kannst aber durch laufende Integritätstests, durch Intrusion Protection usw. das alles recht gut in den Griff bekommen - zerlegt einer wirklich deinen Server in der DMZ naja dann musst du eben Analysieren/Maßnahmen ergreifen das das nicht mehr auf dem Weg geht 100% sicherheit gibt es sowieso nicht - DANN KANNST DU ABER DIE DB USW. AUS DEM LAN HERAUS HERSTELLEN
Kernaussage ist, dass sich das kontrollieren lässt! - Szenario 2 nicht
2)
der jetztige Fall bei dir - alles wie oben + über den DB Server komme ich ins LAN ...
Quizfrage: vom LAN bleibt noch etwas über (DB Recovery ist möglich)?
[ ] ja
[ ] nein
markus
worst case bei dem Szenario ja - wenn du aber die FW zw. externem Netz und DMZ sehr gut (hehe - musst nat. wissen was du tust - lesen!) aufbaust wird das schwer - dann nat. den server selber harden usw.rene04 hat geschrieben:ihmmm, und was ist wenn der webserver in der dmz gehackt wird? dann kommen die auch an die db ran.
1)
hier ist dann die DB/Webserver worst case am Galgen - du kannst aber durch laufende Integritätstests, durch Intrusion Protection usw. das alles recht gut in den Griff bekommen - zerlegt einer wirklich deinen Server in der DMZ naja dann musst du eben Analysieren/Maßnahmen ergreifen das das nicht mehr auf dem Weg geht 100% sicherheit gibt es sowieso nicht - DANN KANNST DU ABER DIE DB USW. AUS DEM LAN HERAUS HERSTELLEN
Kernaussage ist, dass sich das kontrollieren lässt! - Szenario 2 nicht
2)
der jetztige Fall bei dir - alles wie oben + über den DB Server komme ich ins LAN ...
Quizfrage: vom LAN bleibt noch etwas über (DB Recovery ist möglich)?
[ ] ja
[ ] nein
markus
das erscheint mir alles recht sinnvoll.
zu deiner quizfrage: da ich die db backups über ein bandlaufwerk sichere, ja. aber das gelbe vom ei ist es trozdem nicht, das stimmt schon. werde wir wohl diesbezüglich mal eine umstrukturierungsstraterkie ausdenken müssen.
danke für die hinweise.
gruesse rene
zu deiner quizfrage: da ich die db backups über ein bandlaufwerk sichere, ja. aber das gelbe vom ei ist es trozdem nicht, das stimmt schon. werde wir wohl diesbezüglich mal eine umstrukturierungsstraterkie ausdenken müssen.
danke für die hinweise.
gruesse rene
Also ich stelle meine Exchange Datenbanken beispielsweise NICHT in eine DMZ. Dann kann ich meine Firmenrechner auch gleich alle an einen Hub hängen und mit öffentlichen IPs versehen.meandtheshell hat geschrieben:bert hat aber recht - so wird es gemachtrene04 hat geschrieben:
@bert: ich mag ungern die anwendung mit samt der db in der dmz auf einem webserver liegen haben.
Im Exchangefall wird auch mit Reverseproxies oder mit Frontendservern gearbeitet, damit nicht gleich die ganze Datenbank offen liegt wenn der Proxy in der DMZ gehackt wurde.
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
ja - und das ist schlecht - den so oder so triggerst du von der DMZ ins LAN eine verbindung - d.h. das wird ausgenutzt um ins LAN vorzudringen den die Firewall zwischen DMZ und LAN muss das in deinem Fall dann über den Reverseproxie erlaubenMcClane hat geschrieben: Also ich stelle meine Exchange Datenbanken beispielsweise NICHT in eine DMZ. Dann kann ich meine Firmenrechner auch gleich alle an einen Hub hängen und mit öffentlichen IPs versehen.
Im Exchangefall wird auch mit Reverseproxies oder mit Frontendservern gearbeitet, damit nicht gleich die ganze Datenbank offen liegt wenn der Proxy in der DMZ gehackt wurde.
wenn du angst um die DB hast dann kannst du eben noch einen rechner in die DMZ stellen (oder Vserver auf der gleichen maschine) wo du versch. datenbanken aus einer großen machst und somit disjunkte mengen hast wobei du dann aus Jux und Tollerei jeden Vserver mit DB drinnen so resktriktiv aufbauen kannst, dass erstens das hineinkommen zu dem teil der DB extrem schwer ist (da muss ein wizard ran und der rauft sich die haare aus) und nochdazu hast du worst case nur einen teil der DB offen liegen - ABER NEVER EVER hat eine maschine zugriff auf daten im LAN d.h. sie kann sebstständig Verbindungen aufbauen ...
markus
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30