Moin Jungs,
juhu, prima, mein Lieblingsthema: Sinn einer DMZ ;-)
Zitat:
Original geschrieben von ITnetX Hi
Mit ISA kannst Du eine physisch abgetrennte DMZ mit 3 NIC's einrichten. Bei deinem Projekt solltest Du dir noch einige
weitere Punkte überlegen:
EXCHANGE SERVER
Exchange Server gehören nicht in eine DMZ, auch wenn das Konzept der DMZ diese Plazierung aufdrängt. Exchange-Postfächer
enthalten sensitive Daten und gehören immer in den LAN-Abschnitt. |
Es gibt noch einen wesentlich schwerwiegenderen Grund, den Exchange Server NICHT in die DMZ zu verlagern:
ActiveDirectory-Kommunikation
Wenn Du einen MSX in der DMZ hast, wirst Du sicherlich im LAN noch einen DC stehen haben. Damit diese beiden miteinander
kommunizieren können, müssen sehr viele Protokolle (z.B. DNS, LDAP, Kerboros, RPC, Exchange-RPC etc.) zwischen MSX und DC
durch die Firewall geöffnet werden. Das ist ein erhöhtes Sicherheitsrisiko - im Fall der Kompromitierung des MSX gehört
dann auch der DC dem Angreifer. Selbst wenn man den Traffic zusätzlich per IPSec verschlüsselt, halte ich das nicht für
besonders sinnvoll.
Zitat:
Die Kommunikation mit dem Internet kann mit verschiedenen Methoden realisiert werden.
1) Exchange Frontend-Server in die DMZ (eine Lösung von Microsoft, aus meiner Sicht aber eine schlechte Lösung welche die
Sicherheit des Netzwerks beeinträchtigen kann). Ich plaziere Frontend Servers jeweils auch im LAN-Abschnitt).
|
Exakt. MS positioniert IMHO mittlerweile seit ISA 2000 keinen FE mehr in die DMZ. Nur noch in gut überlegten Szenarien
wie z.B. Lastverteilung über mehrere Standorte oder ähnlichem. Dabei zu beachten gilt, dass durch E2k3 sicherlich weniger FE/BE Szenarien benötigt werden, wenn es um Lastverteilung ging.
Zitat:
|
2) ISA Server in die DMZ (z.B. wenn eine andere Firewall eingesetzt wird). Diese Variante ist ein bisschen besser.
|
Diese Lösung begegnet mir immer wieder in Vorträgen etc. Dabei ist mir der eigentliche Sinn noch nicht klar geworden. Weil ich dadurch meiner bescheidenen Meinung nach kein Stück Sicherheit mehr bekomme (gilt nicht für ausschließliches Reverse-Caching/Webveröffentlichen). Man müsste ja dann wieder den ganzen Auth-Traffic durch irgendeine Firewall leiten.
Zitat:
3) SMTP Relay auf dem ISA Server
4) SMTP Relay auf einem Relay Server in der DMZ
|
Da kommen wir genau auf den Punkt. Das wäre für mich die sicherste Lösung. Denn dabei kann der SMTP-Applikationsfilter
des ISA den Traffic inspiziern (wobei ich an dieser Stelle für gewöhnlich nur den Command-Filter verwende). OWA wird über SLL und Basicauthentifizierungsdelegation veröffentlicht. Gerne auch mit FBA.
Zitat:
|
5) Direktes ISA Server-Publishing ohne Relay
|
Auch diese Lösung ist praktikabel. Ich verwende dies z.B. bei uns um einen internen SMTP-Relay-Server zu veröffentlichen. Mein MSX ist ausschließlich per OWA "direkt" nach aussen veröffentlicht.
Zitat:
|
Welche Methode die Beste ist, ist abhängig von Anforderungen an Sicherheit und Funktionalität.
|
Genau. Man muss immer eine Balance finden.
Zitat:
WEB
Webserver werden normalerweise in der DMZ betrieben. Dabei ist darauf zu achten, dass keine anderen, unnötigen Dienste
ausgeführt werden und der Server entsprechend abgesichert ist.
|
Für die Webserververöffentlichung gilt ebenfalls die Auth-Problematik wie beim FE zu beachten. Wenn der Webserver Benutzer gegen das AD authentifizieren muss, gehört er in den meisten Fällen nicht in die DMZ.
Neben der ganzen Thematik der Veröffentlichung von internen Diensten zum Internet muss Flavio auch den ausgehenden Traffic berücksichtigen. Zu einem Firewallkonzept gehört auch dieser nicht unwesentliche Teil. Dabei gilt: Nur zulassen, was zwingend benötigt wird. So gibt es z.B. absolut keinen Grund, warum ein DC per HTTP ins Internet gehen darf. Und vieles mehr.
Viele Grüße
Dieter