Der erste Exchange - Verständnis des Konzeptes

[jimmy-one 0]

Hallo Zusammen,

 

mein erster Beitrag hier und gleich habe ich eine Frage.

Wir beschäftigen uns derzeit in einem Demo Szeanrio mit der Einrichtung eines Exchange Servers.

 

Das ganze ist für sich genommen ja kein Hexenwerk.

Jedoch stellt sich für uns folgende Frage.

 

Die virtuellen Verzeichnisse bieten die Möglichkeit der Angabe einer internen und einer Externen URL.

In der Regel befindet sich der Exchange aber hinter der Firewall so dass ohne aktiven

VPN Zugang keine Möglichkeit besteht das System zu erreichen.

 

Wie ist denn das angedachte Konzept?

 

Stellt man ein System z.B. ein Proxy System in die DMZ welches die Anfragen annimmt und dann an den Exchange Server weiterleitet oder stellt man einen zweiten Exchange in die DMZ der mit einem RODC kommuniziert und dieser erhält dann die Externen URLs?

 

Es gibt zwar sehr sehr viel Dokumentation aber dieses einfache Verständnis entzieht sich mir irgendwie.

 

Mag sein das jemand die Augen verdreht aufgrund dieser einfachen Frage aber wir haben in 30 Jahren Unternehmensgeschichte noch nie einen Exchange betrieben und beschäftigen uns jetzt nur damit um einfach mal zu sehen was es da so gibt am Markt.

 

Danke und lieben Gruß

Helmut

[NorbertFe 2.035]

Moin,

 

Stellt man ein System z.B. ein Proxy System in die DMZ welches die Anfragen annimmt und dann an den Exchange Server weiterleitet oder stellt man einen zweiten Exchange in die DMZ der mit einem RODC kommuniziert und dieser erhält dann die Externen URLs?

Ersteres geht, zweiteres geht nicht! Dritte Option ssl auf den Exchange durchlassen. Hängt halt von den Anforderungen und Richtlinien ab. Da aber die meisten Kunden ein Telefon am Exchange hängen haben wollen, ist VPN meist die weniger beliebte Methode. Zum Thema internal/external URL; dazu nutzt man bei Exchange sinnvollerweise Split-DNS, so dass interne und externe URL identisch sind.

 

Bye

Norbert

 

PS: Man kann zwar alles selber machen, aber wenn man sich damit noch nie beschäftigt hat, fährt man meist schneller/einfacher und stressfreier, wenn man jemanden ranholt, der sowas innerhalb einer recht gut kalkulierbaren Zeit mit einem positiven Ergebnis hinstellt. Sicherlich schneller und preiswerter als der Weg, den du grad versuchst.

[jimmy-one 0]

Moin,

 

 

Ersteres geht, zweiteres geht nicht! Dritte Option ssl auf den Exchange durchlassen. Hängt halt von den Anforderungen und Richtlinien ab. Da aber die meisten Kunden ein Telefon am Exchange hängen haben wollen, ist VPN meist die weniger beliebte Methode. Zum Thema internal/external URL; dazu nutzt man bei Exchange sinnvollerweise Split-DNS, so dass interne und externe URL identisch sind.

 

Bye

Norbert

 

PS: Man kann zwar alles selber machen, aber wenn man sich damit noch nie beschäftigt hat, fährt man meist schneller/einfacher und stressfreier, wenn man jemanden ranholt, der sowas innerhalb einer recht gut kalkulierbaren Zeit mit einem positiven Ergebnis hinstellt. Sicherlich schneller und preiswerter als der Weg, den du grad versuchst.

 

Hallo Norbert,

 

das ging aber schnell. Vielen Dank zunächst!

Bezgl. deines PS: Ich stimme dir zu wenn Exchange als Produktive Umgebung in den Einsatz kommen soll.

Vielleicht war ich da etwas zu undeutlich.

 

In unserem Szenario geht es zunächst einmal nur darum das System kennenzulernen, zu wissen was es kann und was nicht.

Es gibt noch gar keine Entscheidungen, lediglich die Info befasst euch mal damit.

Wenn dann am Ende die Erkenntnis sein sollte, dass wir es machen wollen aber zu wenig Know How verfügbar ist wird ein Dienstleister vermutlich eingekauft. Möglicherweise wird es aber auch keine On-Premise Lösung.

Deshalb lohnt ein Einkauf eines Dienstleisters zum Zeitpunkt jetzt nicht.

 

Bietet Microsoft solche Proxy Systeme an, die die Anfrage weiterleiten oder sind das in der Regel 3rd Party Produkte?

 

Besten Gruß

Helmut.

[NorbertFe 2.035]

In unserem Szenario geht es zunächst einmal nur darum das System kennenzulernen, zu wissen was es kann und was nicht.

Aus meiner Sicht kein sinnvolles Vorgehen. Das geht alles in einem Workshop schneller, wenn man jemanden hat, der einem die Stärken, Schwächen und Möglichkeiten aus der Praxis erklären kann. Ein Workshop kostet gefühlt 1-2 Tage (je nach Intensität) und das Thema Office 365 kann man da sicher auch mit reinpacken.

 

Microsoft bietet zwar was an (https://blogs.technet.microsoft.com/jrosen/2013/12/28/setting-up-windows-application-proxy-for-exchange-2013/) das will man aber nicht. Um zu erklären warum, müßte man da aber tiefer einsteigen. ;) Alternativ gibt's natürlich 3rd Party Produkte wie bspw. Sophos UTM oder ähnliche Lösungen die einen Reverse Proxy beinhalten.

 

Bye

Norbert

[mwiederkehr 373]

Als Proxy kann man einen IIS mit ARR nehmen: https://blogs.technet.microsoft.com/exchange/2013/07/19/part-1-reverse-proxy-for-exchange-server-2013-using-iis-arr/

 

Der leitet in dieser Konfiguration dann aber alles weiter, so dass er keine grosse Verbesserung der Sicherheit bringt. Wenn dieses Mass an Sicherheit gefordert ist, würde ich eine Lösung einsetzen, die IPS, Antivirus etc. bietet.

[magheinz 110]

Aus meiner Sicht kein sinnvolles Vorgehen. Das geht alles in einem Workshop schneller, wenn man jemanden hat, der einem die Stärken, Schwächen und Möglichkeiten aus der Praxis erklären kann.

Das beste ist die Kombination aus beidem.

Die Erfahrungen die man sammeln kann wenn man so ein System auch mal kaputt spielt, die bietet kein workshop.

Vor unserer Exchangeeinführung habe ich sicherlich 20 mal eine Testumgebung aufgebaut und wieder kaputt gespielt.

Die Produktivumgebung haben wir dann im Rahmen eines wortkshops entwickelt und umgesetzt.

 

Jeweils nur eines von beidem wäre mir zu wenig gewesen.

[NorbertFe 2.035]

Da war euch aber wahrscheinlich schon lange klar, dass ihr Exchange einführen würdet. Und auch dann hast du wahrscheinlich nicht unbedingt mit der Installation begonnen ohne dir vorher mal ein wenig Einblick zu holen. Ich bin schon ein paar Jährchen in dem Umfeld unterwegs und die meisten sind eben eher Nutzer und Admins, die eher selten in Eigenregie einen Exchange installieren wollen/müssen oder eine Migration durchführen. Aber jeder wie er meint seine Zeit verbringen zu müssen. Ich bin administrativ auch eher bei Implementierung und Migration, anstatt mich bspw. mit Postfachgrößenauswertung oder Statistiken des Exchangeservers zu beschäftigen. ;)

 

Bye

Norbert

bearbeitet 10. November 2017 von NorbertFe

[NilsK 2.937]

Moin,

 

Das "Kaputtspielen" im Lab wird überbewertet. Die Probleme der Praxis erfasst man damit in der Regel nicht.

 

Gruß, Nils

[NorbertFe 2.035]

Man nimmt im Allgemeinen eher "Fehlverhalten" mit in die Produktivumgebung. ;) Zumindest am Anfang.

[jimmy-one 0]

Alles sehr gute und durchdachte Beiträge. Vielen Dank. So ein Workshop habe ich gleich mal auf die Möglichkeiten ToDo Liste geschrieben. Guter Hinweis. Vielen Dank :thumb1:

Ich bin tatsächlich kein Netzwerker wie ich gestehen muss. Das Basiswissen ist vorhanden. Den ganzen Tag aber beschäftigen sich andere damit. Von daher könnte es durchaus manchmal etwas Laienhaft wirken was ich in Bezug auf Netzwerktechnik von mir gebe. Das sei mir vergeben :)

 

Ich stelle mir auf Basis der Antworten gerade ein Angriffsszenario vor.

1.)

Die Firewall wurde für Exchange geöffnet und lässt nur SSL auf den Exchange durch.
Dann öffne ich also quasi eine Tür direkt ins interne Netzwerk.

Wie sicher jeder weiß wurde eine Schwachstelle in SSL bekannt, die erst mal zu stopfen war.

Bis das aber passiert habe ich dem Hacker schon direkten Zugriff auf das interne Netzwerk gegeben.

 

2.)

Ich stelle einen Proxy in die DMZ, der wie hier beschrieben alle Anfragen weiterleitet.

Die Anfragen werden per Firewall nochmals gefiltert so dass nur gewünschte Anfragen zum Exchange weitergeleitet werden.

Das System könnte aber gekapert werden und somit könnte Zugriff auf das interne Netz erfolgen.

 

Dann wäre aber doch die Variante 2 trotz allem die bessere Methode oder seht ihr das anders?

 

Lieben Gruß

Helmut

[magheinz 110]

Man nimmt im Allgemeinen eher "Fehlverhalten" mit in die Produktivumgebung. ;) Zumindest am Anfang.

Deswegen ja dann der workshop...

Moin,

 

Das "Kaputtspielen" im Lab wird überbewertet. Die Probleme der Praxis erfasst man damit in der Regel nicht.

 

Gruß, Nils

Das kommt auf die Tests an die man macht.

[NilsK 2.937]

Moin,

 

zu deinen Szenarien: Szenario 1 wäre nur dann so, wenn du die Portweiterleitung nicht richtig baust. Machst du es richtig, dann lässt du eben nur SSL-Verbindungen zum Exchange-Server durch. Für alles Weitere ist Exchange zuständig. Je nachdem, was die Firewall kann, lässt sich dort vielleicht noch Weiteres einschränken. Auf andere Server käme ein Angreifer so nicht - es sei denn, er findet eine Lücke in Exchange, die ihm das ermöglicht. Bislang sind solche Lücken aber nicht bekannt geworden.

Die SSL-Schwäche, die du ansprichst, hat mit solchen Szenarien nahezu gar nichts zu tun und trifft auf Windows auch nicht zu, weil dort ja kein OpenSSL läuft.

 

Szenario 2 kann genau solche Vorteile bieten, wie du grob beschreibst und wird u.a. deshalb meist vorgezogen.

 

Gruß, Nils

[magheinz 110]

In Variante zwei bekommt der Angreifer der den Proxy übernimmt eben nicht den Zugriff auf die internen Ressourcen. Der Proxy steht ja genau deswegen in der DMZ!

 

BTW: Wir haben hier Variante zwei mit zwei Linux-VMs mit haproxy als Reverseproxy.

Man kann auch fertige Exchange-Reverseproxy-Appliances kaufen, auch virtuelle. Um ehrlich zu sein ist unsere initiale haproxy-config von genau so einem System kopiert:-)

[NorbertFe 2.035]

Raubkopierer:p

Habt ihr dann intern noch mal so ein Paket loadbalancer? Oder geht der Traffic von intern in die dmz?

[magheinz 110]

intern ist auch noch mal so ein Pärchen. Die Pärchen sind jeweils mit Pacemaker etc als HA-Pärchen gebaut.