Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie am besten die DMZ überwinden?
Exxtreme
2010-05-13, 23:00:28
Folgendes Szenario:
Vertriebsmitarbeiter sollen sich von aussen mit einem internen Exchange-Server verbinden können. Sei es mit dem Laptop oder mit einem Ipad/Iphone. Dazwischen soll aber eine DMZ sein. Den Exchange-Server will ich aber nicht in die DMZ stellen weil man dann paar Ports von der DMZ ins interne Netz öffnen müsste.
Wie stellt man das jetzt am geschicktesten an? Wie es mit einigem an Aufwand geht das wüsste ich durchaus. Aber vielleicht habe ich eine sehr gute Möglichkeit übersehen.
Danke im Voraus.
ravage
2010-05-13, 23:25:38
Exchange Frontend Server ist wahrscheinlich das Stichwort was du suchst. Aber ich bin in sachen Exchange auch nur ein Leihe :)
Oder ist der Frontend Server das was du als "einigem Aufwand" meinst?
Avalox
2010-05-14, 00:08:26
OWA Sync - Eine Port 80/443 getunnelte Outlook Synchronisation. Ab Exchange 2003.
Exxtreme
2010-05-14, 10:11:16
Exchange Frontend Server ist wahrscheinlich das Stichwort was du suchst. Aber ich bin in sachen Exchange auch nur ein Leihe :)
Oder ist der Frontend Server das was du als "einigem Aufwand" meinst?
Japp, das meine ich mit "Aufwand". ;D
OWA Sync - Eine Port 80/443 getunnelte Outlook Synchronisation. Ab Exchange 2003.
Und das kommt ohne so eine Art eines Reverse Proxy in der DMZ aus?
The_Invisible
2010-05-14, 10:43:26
wo ist das problem bei der firewall die regeln so festzulegen das man zwar von intern auf dmz eine verbindung aufbauen kann aber nicht umgekehrt, also auf sessionbasis?
mfg
Exxtreme
2010-05-14, 11:32:18
wo ist das problem bei der firewall die regeln so festzulegen das man zwar von intern auf dmz eine verbindung aufbauen kann aber nicht umgekehrt, also auf sessionbasis?
mfg
Exchange ist leider so konstruiert, dass es eine Verbindung zum AD-Controller braucht. Und damit das aus der DMZ heraus klappt müsstest du ein paar Ports von der DMZ ins interne Netz öffnen was ich aber nicht will.
Einen Umweg gibt es und zwar über einen sog. Reverse Proxyserver/Exchange Frontend Server in der DMZ, den man per Tunnel ins interne Netz lassen könnte. Der Reverse Proxy übernimmt so eine Art Brückenfunktion. Das ist aber ein Aufwand, den ich ehrlich gesagt scheue. ;) Wenn es aber nicht anders dann muss ich in den sauren Apfel beissen. ;)
Wir haben für so etwas einen Terminalserver/Citrix Access Gateway , der von außen nur mit Crypto-Card angefahren werden kann.
Die Kommunikationsbeziehungen von Exchange-Server, AD und TS bleiben so intern. Raus gehts nur mit 443.
Aber der Aufwand ist auch hinsichtlich des Nutzens... :rolleyes:
hadez16
2010-05-14, 11:50:13
verstehe das Problem nicht...
eine DMZ befindet sich parallel zur Netzstruktur, quasi als "eigenes Netz" mit einer Feuerwand richtung Internet und richtung Intranet.
Wenn du Client-Anfragen zum Exchange-server (im LAN) leiten willst...was hat die DMZ damit zu tun?!
Exxtreme
2010-05-14, 12:22:49
Wir haben für so etwas einen Terminalserver/Citrix Access Gateway , der von außen nur mit Crypto-Card angefahren werden kann.
Die Kommunikationsbeziehungen von Exchange-Server, AD und TS bleiben so intern. Raus gehts nur mit 443.
Aber der Aufwand ist auch hinsichtlich des Nutzens... :rolleyes:
Die Lösung soll möglichst "universell" sein damit man alles ranhängen kann. Und da fällt Citrix wohl raus weil es nicht überall läuft. ;)
verstehe das Problem nicht...
eine DMZ befindet sich parallel zur Netzstruktur, quasi als "eigenes Netz" mit einer Feuerwand richtung Internet und richtung Intranet.
Wenn du Client-Anfragen zum Exchange-server (im LAN) leiten willst...was hat die DMZ damit zu tun?!
Parallel? Für mich sieht das eher wie eine Reihe aus.
Internet - Firewall 1 - DMZ - Firewall 2 - Internes Netz
Alles was von außen reinkommt muss erstmal die DMZ passieren. Und aus der DMZ kommst du ins interne Netz zunächst gar nicht rein weil alle Ports dicht sind.
Avalox
2010-05-14, 12:43:44
Japp, das meine ich mit "Aufwand". ;D
Und das kommt ohne so eine Art eines Reverse Proxy in der DMZ aus?
Ja.
Ihr kommt doch heute bestimmt schon mit Port 80/443 aus der DMZ in das Internet?
Im Prinzip lassen sich Outlook Clients dort synchronisieren, welche prinzipiell in der Lage sind vom selben Client im Webbrowser auch das Web Access von Exchange manuell aufzurufen.
hadez16
2010-05-14, 12:50:21
Parallel? Für mich sieht das eher wie eine Reihe aus.
Internet - Firewall 1 - DMZ - Firewall 2 - Internes Netz
Alles was von außen reinkommt muss erstmal die DMZ passieren. Und aus der DMZ kommst du ins interne Netz zunächst gar nicht rein weil alle Ports dicht sind.
das wäre mir neu. Firewall-Appliances haben für DMZ ein eigenes Regelwerk PARALLEL zum Intranet/LAN.
Die Struktur einer DMZ selbst lässt sich als Reihe betrachten, ja.
fl_li
2010-05-14, 18:36:01
1. Sauberste Lösung: Exchange Front- und Backendlösung
2. Die von Avalox vorgeschlagene Lösung (OWA Sync per HTTPS)
3. Den Exchange Server mittels einem VPN ins LAN einbinden
4. Den Exchange Server mit einer 2. Netzwerkkarten ausstatten: eine Netzwerkkarte für die DMZ, eine für die interne Kommunikation (LAN).
Lösung 3 und 4 sind aber nicht unbedingt als "sicher" einzustufen.;)
Exxtreme
2010-05-16, 13:49:35
Also ... *g* Jetzt stehe ich irgendwie auf dem Schlauch und kapiere gar nix mehr. X-D
Irgendwo habe ich einen Denkfehler. Die DMZ soll doch verhindern, dass man aus dem Internet direkt ins interne Netzwerk reinkommt. Um das trotzdem zu bewerkstelligen müsste ich entweder paar Ports von der DMZ ins interne Netz öffnen (sehr unerwünscht) oder sowas wie einen Reverse Proxy (weniger böse aber Aufwand) einrichten. Anscheinend gibt es auch eine Möglichkeit drei, die ich aber grad nicht sehe. Bzw. wie funktioniert das OWA-Sync genau?
The_Invisible
2010-05-16, 14:25:04
in der dmz stehen in der regel rechner die öffentlich erreichbar sind. das interne netz muss nich zwingend seriell durch das dmz vom internet getrennt sein. verkompliziert wird das durch heute neue firewalls die auch schon virtualisiert arbeiten können. so kann man quasi auf einer guten firewall mit nur 2 ports (fortigate) mehrere vlans fahren die mittels l2-switch gesplittet werden und auf der firewall auf jeweils einer eigenen instanz laufen zb 10 verschiedene netze fahren (limitiert durch fw ram und cpu). noch lustiger wirds dann wenn man anfängt zwischen diesen virtuellen instanzen vpns oder ähnliches zu schalten.
wie wärs den mit einer VPN ins dmz netz von den clients aus? so brauchst du öffentlich gar nix freischalten und nur ausgewählte benutzer kommen hinein. da könntest sogar leicht definieren das benutzer aus dem vpn-netz nicht ins interne kommen. naja, viele wege führen nach rom ;)
mfg
Exxtreme
2010-05-16, 16:38:12
wie wärs den mit einer VPN ins dmz netz von den clients aus? so brauchst du öffentlich gar nix freischalten und nur ausgewählte benutzer kommen hinein. da könntest sogar leicht definieren das benutzer aus dem vpn-netz nicht ins interne kommen. naja, viele wege führen nach rom ;)
mfg
So ist es eigentlich auch geplant. Die mobilen Teile wählen sich per VPN ins Netzwerk ein. Am liebsten wäre es mir Mobiles Gerät -> VPN -> internes Netzwerk. Wir werden aber die DMZ brauchen da wir bestimmte Dienste bestimmten Kunden anbieten wollen. Und sobald man sich per VPN an Firewall 1 anmeldet kommt man zwangsläufig in die DMZ. Jetzt bräuchte man quasi eine Brücke von Firewall 1 direkt ins interne Netz. Gut, vielleicht gibt es Router, die sowas können, ohne dass man eine DMZ mit zwei Firewalls aufbauen muss. Was ich aber definitiv nicht will ist eine "Exposed host" Pseudo-DMZ.
Ich habe das folgendermaßen gelöst:
1. Apache Reverseproxy, der Anfragen per HTTPS entgegennimmt und dann Outlook Web Access bzw den Activesync-Konnektor des Exchange-(Frontend-)Servers anzapft und die Antworten wieder an den Client zurückreicht.
Damit kann jeder mit einem Webbrowser auf OWA zugreifen sowie Smartphones per Activesync synchronisieren.
Den Reverseproxy kannst du in die DMZ stellen. Es wird natürlich eine Möglichkeit benötigt, dass der Reverseproxy den Exchange-Server erreichen kann, aber *irgendeinen* Weg zum Exchange-Server musst du freimachen, irgendwie müssen die Anfragen ja dort landen können.
2. VPN-Server, bei dem sich Nutzer von außen SSL-gesichert anmelden können und von dem aus wiederum ein Exchange-Frontend-Server erreichbar ist. Darüber kann dann auch per Outlook auf Exchange zugegriffen werden. Theoretisch kann Outlook auch per RPC über HTTPS (und damit über einen Reverseproxy) mit dem Exchange-Server kommunizieren, allerdings vergewaltigt zumindest die 2003er-Ausgabe den HTTP-Standard so sehr, dass Apache damit nicht mehr zurecht kommt. Mit dem MS-ISA-Server als Reverseproxy gehts natürlich.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.