How To für OWA in der DMZ

[nic7575 13]

Folgende Aufgabenstellung:

 

Vorhanden ist ein Exchange 2010. Ich möchte nun aber die Firewall auf Port 443 nicht direkt zum Exchange freimachen. Stattdessen möchte ich gerne einen Server in die DMZ stellen und den OWA dort zum fliegen bekommen.

 

Wie stellt man das am Besten an. Gibt es ein deutsches HowTo ?

[BrainStorm 10]

Hallo nic7575,

 

Wie stellt man das am Besten an. Gibt es ein deutsches HowTo ?

 

Am besten gar nicht. Die CAS Rolle in der DMZ ist seitens Microsoft weder empfohlen noch supported.

Zudem bräuchtest du dann einen DC im selben Netz und du müsstest deine Firewall zur Kommunikation mit Domaincontrollern und Mailboxservern noch weiter aufreissen.

 

Einzig und allein sinnvolle Variante wäre die OWA Freigabe über einen ISA/TMG und Platzierung der Client Access Rolle im internen Netz.

 

Warum hast du bedenken den HTTP SSL Port 443 nach intern weiterzuleiten?

[nic7575 13]

Hallo nic7575,

 

 

 

Am besten gar nicht. Die CAS Rolle in der DMZ ist seitens Microsoft weder empfohlen noch supported.

Zudem bräuchtest du dann einen DC im selben Netz und du müsstest deine Firewall zur Kommunikation mit Domaincontrollern und Mailboxservern noch weiter aufreissen.

 

Einzig und allein sinnvolle Variante wäre die OWA Freigabe über einen ISA/TMG und Platzierung der Client Access Rolle im internen Netz.

 

Warum hast du bedenken den HTTP SSL Port 443 nach intern weiterzuleiten?

 

Tja, ich habe da halt arge Sicherheitsbedenken. Wenn erstmal ein Port nach intern frei ist kann man dort auch angegriffen werden.

 

Mein Firewall bietet demnächst einen Reverseproxy für Http/s an. Mal schauen ob ich es damit "sicher" hinbekomme.

 

Habe jetzt nicht nachgeschaut, aber welche Vorraussetzungen vom OS her benötige ich für die CAS-Rolle ? Reicht da auch ein XP ?

[Dy0nisus 10]

Du möchtest einen Exchange auf XP installieren? :)

 

Exchange 2010 ? Systemanforderungen: Hilfe zu Exchange 2010

 

Gruß Dennis

[BrainStorm 10]

Tja, ich habe da halt arge Sicherheitsbedenken. Wenn erstmal ein Port nach intern frei ist kann man dort auch angegriffen werden.

Achso ;) Dann erläutere ich dir mal dein geplantes Szenario näher:

Wenn du dir einen Exchange 2010 mit CAS Rolle (für OWA) in die DMZ stellen würdest, muss dieser natürlich auch Mitglied deines Active Directorys sein. Weiterhin muss der Server auch in der Mitglied der Gruppe "Exchange Server" sein. Diese Gruppe hat auf allen deinen Exchange Servern administrative Rechte. Nehmen wir mal an, jemand kompromittiert nun deinen in der DMZ platzierten CAS Server, dann ist er ohne großen Aufwand Administrator deiner gesamtem Exchange Organisation.

 

Alles weitere darfst du dir selber ausmalen ;) Und dabei hättest du keine Sicherheitsbedenken?

 

Mein Firewall bietet demnächst einen Reverseproxy für Http/s an. Mal schauen ob ich es damit "sicher" hinbekomme.

Wäre zu überprüfen. Wenn die Firewall das mitbringt, sparst du dir ggf. den ISA/TMG

 

Habe jetzt nicht nachgeschaut, aber welche Vorraussetzungen vom OS her benötige ich für die CAS-Rolle ? Reicht da auch ein XP ?

 

Die CAS-Rolle ist Teil deines Exchange 2010 Servers, demnach gelten auch die selben OS Voraussetzungen. In diesem Fall Windows Server 2008 oder 2008 R2.

[nic7575 13]

Also dann sollte ich wohl noch etwas warten bis die Firewall was hergibt.....Danke für die Antwort ;)

[BrainStorm 10]

Also dann sollte ich wohl noch etwas warten bis die Firewall was hergibt.....Danke für die Antwort ;)

 

Gern geschehen ;)

Mich würde noch interessieren um welche Firewall es sich bei dir handelt und ob deine OWA Veröffentlichung dann auch funktioniert.

[NorbertFe 1.831]

Ausserdem würde mich der zu erwartende Sicherheitslevel interessieren, der zu solchen Überlegungen führt. Das klingt mir doch sehr nach "Voodoo". Ein Reverseproxy ist auf jeden Fall dann die einzige Variante die einen direkten Zugriff von I-Net ins LAN verhindern würde. Und das kann derzeit der ISA/TMG in Zusammenhang mit Exchange einfach am besten. Zur Not kanns aber auch ein Apache. Nur den muß man auch erstmal sicher konfiguriert bekommen. ;)

 

Bye

Norbert

[LukasB 10]

Vielleicht sollte man hierbei auch noch erwähnen das der Sicherheits-Track-Record von IIS seit Version 6 und von OWA 2003 aufwärts sehr gut ist.

 

Falls mich meine Erfahrung nicht täuscht gab es bei IIS 6 lediglich zwei Sicherheitsprobleme (Directory Traversal, und die WebDAV-Geschichte). Für OWA gab es meines Wissens nie ein Sicherheitsproblem.

 

Aus diesem Grund sehe ich auch wenig Gründe im Kleinkunden-Umfeld für OWA-Publishing einen seperaten Forefront TMG verkaufen zu müssen. Natürlich ist es vom Design her schöner und besser, aber mit die dafür benötigten Mittel kann man andernorts oft besser einsetzen.

[NorbertFe 1.831]

Vielleicht sollte man hierbei auch noch erwähnen das der Sicherheits-Track-Record von IIS seit Version 6 und von OWA 2003 aufwärts sehr gut ist.

 

Falls mich meine Erfahrung nicht täuscht gab es bei IIS 6 lediglich zwei Sicherheitsprobleme (Directory Traversal, und die WebDAV-Geschichte). Für OWA gab es meines Wissens nie ein Sicherheitsproblem.

 

Aus diesem Grund sehe ich auch wenig Gründe im Kleinkunden-Umfeld für OWA-Publishing einen seperaten Forefront TMG verkaufen zu müssen. Natürlich ist es vom Design her schöner und besser, aber mit die dafür benötigten Mittel kann man andernorts oft besser einsetzen.

 

Genau deswegen frug ich ja. ;) Denn pauschal einen zugriff aufs LAN zu verdammen ist einfach, nur ist oftmals der korrekte Grund dazu gar nicht gegeben, bzw. wird dann bei Services die sich nicht so ohne weiteres proxien lassen trotzdem umgesetzt.

 

Bye

Norbert

[Dukel 436]

[...]

Zur Not kanns aber auch ein Apache. Nur den muß man auch erstmal sicher konfiguriert bekommen. ;)

 

Bye

Norbert

 

Dafür gibts mod_security. Sowas hat dafür der ISA nicht an Bord (oder ist der mitlerweile auch WAF?).

[Stephan Betken 43]

Dafür gibts mod_security. Sowas hat dafür der ISA nicht an Bord (oder ist der mitlerweile auch WAF?).

Äh, ich kann zwar nicht viel zu mod_security sagen, aber was kann man damit, was der ISA nicht kann?

[Dukel 436]

mod_security ist eine Web Application Firewall für Apache (kann man in verbindung mit dem apache proxy verwenden). So viel ich weiss macht ISA ja nur Reverse Proxy.

 

Aber das wird hier glaube ich zu OT.

[NorbertFe 1.831]

Dafür gibts mod_security. Sowas hat dafür der ISA nicht an Bord (oder ist der mitlerweile auch WAF?).

 

Und was ist der ISA dann deiner Meinung nach? Ein Portfilter? ;)

Wäre jetzt wirklich mal interessant zu wissen, was der Apache mit mod_security besser kann.

Ich finde es nicht OT, sondern hier im Thread durchaus interessant.

 

 

Bye

Norbert

[Dukel 436]

Isa ist ein Reverse Proxy, wie z.B. der Apache mit dem Proxymodul oder Squid auch sein kann. Eine WAF wie mod_security schaut zusätzlich noch die Http Pakete an und leitet sie nicht nur weiter. Wenn in einer Http Anfrage verdächtige Anforderungen stehen (z.B. SQL injection, XSS,...) kann die Anfrage verworfen werden.

 

Web Application Firewall ? Wikipedia