Exchange 2013 im Internet verfügbar machen

[user09 10]

Hallo,

 

ich möchte einen Exchange Server im Internet verfügbar machen.

Das TMG / Forefront wurde ja leider abgekündigt.

 

Welche Möglichkeiten existieren den Exchange Server sicher ins Internet verfügbar zu machen?

Setzt man hier jetzt auf Appliances von 3. Hersteller?

 

Vielen Dank!

[NorbertFe 2.041]

Tja, entweder trotzdem TMG einsetzen. Wenn mans hat, spricht nichts dagegen. http://blogs.technet.com/b/exchange/archive/2012/11/21/publishing-exchange-server-2013-using-tmg.aspx

Appliances oder andere Firewall-Lösungen funktionieren genau wie früher auch mehr oder weniger gut. (Leider keins so gut wie das TMG).

Oder eben direkt ins Netz. Das wird von MS inzwischen als "sicher" deklariert. Und so richtig entkräften kann man die Aussage auch nicht bisher.

 

Bye

Norbert

bearbeitet 25. Mai 2013 von NorbertFe

[user09 10]

Ein abgekündigtes Produkt noch einzusetzen sehe ich etwas ungünstig.

 

D.h. den Exchange Server in die DMZ und den Exchange Server Zugriff auf die Domäne erlauben????

[NorbertFe 2.041]

Warum siehst du das ungünstig? Kennst du aktuell bessere Produkte? Support gibt's noch ein paar Jahre. Ein Exchange gehört nicht in die Dmz. Um genau zu sein wäre die firewalltechnische Trennung von Dc und Exchange sogar unsupported.

 

Bye

Norbert

[RobertWi 81]

Grundsätzlich ist eine Firewall zwischen Exchange und DC schon erlaubt - wenn die Regel Any/Any lautet. Ok, das hebt die Firewall dann faktisch auf, macht die Firewall ansich aber nicht unsupported.

 

@user09: Wie gesagt, TMG wird noch bis 2020 supported und läuft mit Ex 2013.

 

Aber rein aus der Praxis kann ich das Argument der Entwickler ("Firewall nach ganz vorne und Port 443 an Exchange weiterleiten") schon verstehen. Ich kenne außer dem TMG - und dort auch nur in sehr engen Grenzen - keinen Proxy, der wirklich einen Sicherheits-Gewinn bringt. Dafür müsste ja nicht nur auf Layer 5 od. 6 (= HTTP), sondern eigentlich auf Layer 7 (= OWA mit HTTP) analysiert und gescannt werden. Und da sind die Möglichkeiten eines Proxys extrem eingeschränkt.

 

Das UAG muss formal noch erwähnt werden. Allerdings ist das DIng so teuer, dass es bei den meisten mehr kostet, als Exchange. :)

[zahni 554]

Beim TMG sollte der SSL-Tunnel am TMG enden. Dann kann der Reverse-Proxy schon Einiges bewirken. Am TMG können auch zusätzliche Authentifizierungsmechanismen implementiert werden.  

[RobertWi 81]

Beim TMG sollte der SSL-Tunnel am TMG enden. Dann kann der Reverse-Proxy schon Einiges bewirken.

 

Nicht wirklich mehr, als Exchange auch alleine kann.

 

Am TMG können auch zusätzliche Authentifizierungsmechanismen implementiert werden.  

 

Das wäre ein Argument (und eventuell die Aufteilung auf zwei Zertifikate).

[user09 10]

danke für die Antworten.

Ist es evtl. möglich einen IIS Server zu installieren und diesen als Reverse Proxy (mit Authentifizierung) zu verwenden?

Das wäre dann eine halbwegs gute Lösung.

[NorbertFe 2.041]

Grundsätzlich möglich, aber welchen Vorteil versprichst du dir davon?

[user09 10]

das man nicht direkt auf dem exchange server landet auf dem Mailboxen etc gespeichert sind sondern zuerst

sich im IIS in der DMZ authentifizieren muss.

(kleiner Sicherheitsgewinn)

[RobertWi 81]

Hier mal was zum Lesen bei Lync: http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx

 

Das wird demnächst auch offiziell für Exchange erlaubt sein.

Allerdings ist der Sicherheitsgewinn relativ gering und jeder muss wissen, ob er die Zusatzkosten und den zusätzlichen Aufwand haben will.

[user09 10]

danke.

warum haltet ihr den Sicherheitsgewinn für gering?

Wenn die Authentifizierung am DMZ IIS gemacht wird und dieser nur per LDAP auf den DC zugreift,

dürfte es doch einen Sicherheitsgewinn geben?!

bearbeitet 7. Juli 2013 von user09

[RobertWi 81]

Faktisch hast Du nur den Punkt der Authentifizierung verlagert - die Daten, die übertragen werden, sind aber nach außen immer noch die gleichen.

 

Aber nach innen bringt es eine neue Komplizitätsstufe ins Spiel, einen weiteren Server, den man patchen muss, Lizenzkosten, zusätzliche Hardware, usw.

 

Ein echter Sicherheitsgewinn wäre es, wenn der Proxy auch in den Traffic schaut, dort schon Viren oder Angriff erkennt - das tut er aber nicht.

[user09 10]

>> Faktisch hast Du nur den Punkt der Authentifizierung verlagert - die Daten, die übertragen werden, sind aber nach außen immer noch die gleichen.

 

ja aber ohne Authentifizierung kommt gar kein Traffic am Exchange an.

 

Ein echter Sicherheitsgewinn wäre es, wenn der Proxy auch in den Traffic schaut, dort schon Viren oder Angriff erkennt - das tut er aber nicht.

 

da scheint es aber keine Lösung zu geben?

 

Ich habe das UAG mal installiert aber dieses scheint gefühlsmäßig noch nicht auf Exchange 2013 angepasst zu sein.

 

Ich sehe etwas kritisch dass ein Server im LAN direkt aus dem Internet mit 443 erreichbar ist und dieser auch noch so eng mit der Domäne verknüpft ist.

bearbeitet 7. Juli 2013 von user09

[NorbertFe 2.041]

ja aber ohne Authentifizierung kommt gar kein Traffic am Exchange an.

Und? Stört den Exchange nicht authentifizierter Traffic? ;)

 

 

da scheint es aber keine Lösung zu geben?

Nein, zumindest wäre mir keine bekannt.

 

 

Ich habe das UAG mal installiert aber dieses scheint gefühlsmäßig noch nicht auf Exchange 2013 angepasst zu sein.

Ja, das ist aber nicht unbedingt ein Hinderungsgrund.

 

Ich sehe etwas kritisch dass ein Server im LAN direkt aus dem Internet mit 443 erreichbar ist und dieser auch noch so eng mit der Domäne verknüpft ist.

Warum? Was wäre denn im Umkehrschluß dein Sicherheitsgewinn, wenn du per Reverseproxy den Zugang authentifizierst und dann den Zugriff genehmigst? ;) Denn was der Reverse Proxy genau tun, darüber macht sich sowieso kaum einer Gedanken, sondern die meisten sind froh, wenn sie ihr komplexes System (gibt ja auch Leute die sowas unbedingt per Apache lösen "müssen") überhaupt zum Laufen bekommen. Die Steigerung der Komplexität ist nicht automatisch ein Sicherheitsgewinn, sondern im Allgemeinen eher das Gegenteil.

 

Bye

Norbert

 

 

 

 

 

Grundsätzlich ist eine Firewall zwischen Exchange und DC schon erlaubt - wenn die Regel Any/Any lautet. Ok, das hebt die Firewall dann faktisch auf, macht die Firewall ansich aber nicht unsupported.

 

Stimmt, aber eine any/any Firewall nenne ich router. ;)

 

 

 

Aber rein aus der Praxis kann ich das Argument der Entwickler ("Firewall nach ganz vorne und Port 443 an Exchange weiterleiten") schon verstehen. Ich kenne außer dem TMG - und dort auch nur in sehr engen Grenzen - keinen Proxy, der wirklich einen Sicherheits-Gewinn bringt. Dafür müsste ja nicht nur auf Layer 5 od. 6 (= HTTP), sondern eigentlich auf Layer 7 (= OWA mit HTTP) analysiert und gescannt werden. Und da sind die Möglichkeiten eines Proxys extrem eingeschränkt.

Kann ich nur bestätigen. Meist sind das eher die typischen Paranoia Anfragen, die auch der Meinung sind, dass ein Mailserver (gemeint ist oft der Exchange) in die DMZ gehört. ;)

 

Ein Vorteil der vorgeschalteten Authentifizierung ist die relativ einfache Trennung von internem und externem Zugriff. So dass sehr granular gesteuert werden kann, wer von extern und wer nur intern zugreifen kann. Das ist nur mit Exchange so ohne weiteres nämlich nicht möglich afaik.

 

 

Bye

Norbert

bearbeitet 7. Juli 2013 von NorbertFe