Exchange und Firewalls

Seite 4/6

Wohin mit Exchange ?

Wo kommen nun die verschiedenen Komponenten hin ?. Ich vertrete den Standpunkt, dass der Exchange Server immer in das interne LAN kommt. Dort ist er am schnellsten zu erreichen. Keine Firewall muss die Megabytes an Daten kontrollieren und Filtern. Sollte die Firewall in einer Notsituation einmal abgeschaltet werden müssen, wäre bei einer Positionierung in der DMZ auch der interne Verkehr lahm gelegt. Und das ist mit Hinblick auf Intranets und das Web Storage System sicher der falsche Weg. Angriffe von innen sind möglich, sicher, aber das sind sie ein einem Netzwerk ohne Internet genauso. Und dies trifft für Dateiserver und Druckserver ebenso zu.

Wie kommuniziert Exchange ?

Bitte lesen Sie hierzu auch die Artikel zu Mail im Internet und Clientkommunikation. Daher fällt die Protokollbetrachtung hier aus. Wir vereinfachen hier die Kommunikation auf drei  Szenarien:

  • Mail versand und Empfang per SMTP
    Exchange sendet Nachrichten per SMTP in das Internet und Empfänger solche aus dem Internet per SMTP. (POP3-Sauger dürften in den seltensten Fällen eine Firewall haben, die mehr als NAT macht, und sind daher auf POP3SMTP.HTM verwiesen.
  • Outlook Webzugriff von Außen
  • VPN-Zugang für Outlook Clients

Alle Dinge "drum herum" wie IP-Routing, Leitwege, Routingprotokolle (RIP, OSPF), DNS-Auflösung etc. werden hier nicht gesondert ausgeführt.

Exchange 2000 hat z.B.: folgende Ports geöffnet. Sie sollten Sie genau überlegen, ob sie überhaupt den Zugriff auf diese Ports von außen zulassen wollen. Denken genau über eine Sicherung per VPN nach. Dann sind nur wenige Ports offen und erst nach einer erfolgreichen Authentifizierung kann es weiter gehen. Oder würden Sie ihren Global Catalog von außen erreichbar machen wollen ?

  • 25 SMTP
  • 53 DNS
  • 80 HTTP
  • 88 Kerberos
  • 102 X.400
  • 110 POP3
  • 119 NNTP
  • 135 RPC
  • 137 - NetBIOS Session Service
  • 139 - NetBIOS Name Service
  • 143 IMAP4
  • 379 LDAP (SRS)
  • 389 LDAP
  • 443 HTTP (SSL)
  • 445 - NetBIOS over TCP
  • 465 SMTP (SSL)
  • 563 NNTP (SSL)
  • 636 LDAP (SSL)
  • 691 LSA
  • 993 IMAP4 (SSL)
  • 994 IRC (SSL)
  • 995 POP3 (SSL)
  • 1503 T.120
  • 1720 H.323
  • 1731 Audio conferencing
  • 1863 - MSN IM
  • 3268 GC
  • 3269 GC (SSL)
  • 6667 IRC/IRCX
  • 6891-6900 - MSN IM File transfer
  • 6901 - MSN IM Voice
  • 7801-7825 - MSN IM Voice

SMTP-Relay oder NAT

Wir gehen von einer echten Internetanbindung aus, bei der die Firma ihre Mails per SMTP versenden kann und per SMTP diese zugestellt bekommen. Wir haben uns entschieden, dass Exchange im internen LAN angeschlossen ist und müssen uns nun überlegen, wie Exchange die Nachrichten senden und annehmen kann. Hierzu gibt es zwei Lösungsansätze:

  • Direkter Versand per DNS und NAT
    Die Firewall kann alle Pakete per NAT umsetzen, d.h.
    Wenn Exchange Nachrichten senden möchte, löst Exchange per DNS das Zielsystem auf und versucht die Nachricht dorthin zu senden. Mit dem passenden IP-Leitweg geht das Paket zur Firewall, welche dann die IP-Adressen umsetzt (d.h. die Absenderadresse durch seine eigene Adresse ersetzt und umgekehrt
    Für den Empfang von Nachrichten muss der Firewall gesagt werden, dass alle eingehenden Pakete auf Port 25 einer offiziellen IP-Adresse auf die interne Adresse des Exchange Servers mittels Reverse NAT umgesetzt werden. Der externe MX-Eintrag verweist dazu auf die definierte Adresse der Firewall.
  • SMTP-Relay
    Auf einem System in einer DMZ wird eine SMTP-Relaysoftware installiert. Teilweise liefert die Firewall ebenso diese Funktion mit (z.B. Checkpoint Secure Server). Exchange wird angewiesen, per Smarthost alle Nachrichten an dieses System zu senden. Das Relay nimmt die Nachrichten an, puffert diese und sendet diese dann in einem zweiten unabhängigen Schritt nach draußen.
    Umgekehrt nimmt dieses Relay die Mail von draußen an, puffert diese und leitet Sie dann an den internen Exchange Server weiter
    Die Firewall kann hier gleich zweimal den Datenverkehr kontrollieren.
    Das SMTP-Relay kann natürlich weit mehr tun, als "nur" weiterleiten.

Meine persönliche Vorliebe und Empfehlung ist die Nutzung eines SMTP-Relay. Sie haben hierbei die meisten Möglichkeiten der Filterung und Steuerung und ein sehr geringes Risiko. Im Gegensatz zu NAT besteht keine direkte Verbindung von innen nach außen und selbst ein unsicherer Exchange Server ist nicht direkt gefährdet. Das Relay kann schon Viren, Werbemails und auch Versuche Sie als Relay zu nutzen abwehren.

Zudem können Sie dann Exchange auch problemlos einige Stunden herunterfahren und die Nachrichten werden trotzdem bis zur Firma zugestellt. Sobald Exchange wieder oben ist, kann das Relay die Mails sehr schnell abliefern.

Machen Sie einfach mal einen "TELNET mailservername 25", und schauen Sie mal, welche Produkte sich so melden, wenn Sie Microsoft, Bertelsmann oder andere per Mail erreichen wollen.

OWA 5.5 in der DMZ

Outlook Web Access ist eine ideale Möglichkeit, um aus dem Internet schnell und problemlos seine Mailbox zu sichten. Aber mit der notwendigen Sicherheit bitte. Mit Exchange 5.5. war auch hier die Anordnung einfach:

  • OWA-Server in die DMZ installieren.
    der OWA-Server muss Mitglied der Domain sein, z.B. OWA ist ein PDC einer eigenen Domain und vertraut der internen Domain.
    Benutzer müssen "Logon on Locally" Recht haben
  • Namensauflösung einrichten
    auf dem OWA noch in der LMHOSTS/HOSTS den Servernamen des Exchange undPDC damit man WINS/DNS sparen kann
  • Ports auf Exchange Server
    Ports für MSExchangeIS und MSExchangeDS z.B. auf 1275 und 1276 fixieren, damit diese bei jedem Start gleich sind
  • Firewall Regeln definieren
    Internet -> OWA port 80 TCP und 443/TCP allow
    OWA -> internMSX port 135, 1275, 1276 TCP allow
    OWA -> PDC port 135,138 TCP allow (fuer Domain userauthentifizierung)

Wenn der OWA-Server aber "intern" steht und der Zugang per Reverse HTTP erfolgt, dann sollte OWA ein "Memberserver" sein (wg Logon Locally). Wenn es ein DC ist, dann könnte sich jeder user auf dem DC anmelden und die Rechte der Freigaben umgehen...

Die Installation ist im Prinzip ganz einfach, aber aufgrund der Zusammenhänge von Firewall, Webserver, Namensauflösung etc. noch tückisch. Ich rate hierbei dann eher zur Nutzung entsprechender Helfer, die dann auch die Gesamtsicherheit können. Oft ist es nicht OWA, welches nicht funktioniert, sondern andere Komponenten.

OWA 200x in der DMZ

Exchange 2000 kann so nicht mehr installiert werden. für die Trennung des Webzugriffs vom Exchange Store ist zwingend der Einsatz des Exchange Enterprise Servers notwendig. Dieser wird dann in der DMZ installiert und seinen Speichergruppen beraubt. Er ist dann ein Frontendserver, welcher zum Client die Standard Internetprotokolle spricht und zum Exchange Server als Backend auf die Informationsspeicher zugreift. (Siehe Frontend Backend Konstellation)

Ohne den Einsatz dieser Kombination können Sie den Zugriff von außen auf den internen Exchange Server z.B. per Reverse Proxy oder eingehendes NAT realisieren. Sie sollten dann aber entsprechende Sicherheitsrichtlinien auf ihrem internen Server definieren, da dieser dann zumindest auf zwei Ports (80 und 443) erreichbar ist, nicht dass "aus versehen" auch ihr Intranet auf dem gleichen Server plötzlich erreichbar wird.

Es gibt noch eine weitere Alternative, einen Outlook Webzugriff eines internen Servers sicherer nach außen zu publizieren: Über die "Revers Proxy", bzw. Reverse Publishing Funktion des ISA-Servers oder eines anderen Servers können anfragen eines Clients an diesen Server gesendet werden, welcher die Informationen dann von innen abholt und weiterleitet. Damit ist ein direkter Durchgriff des Clients auf den Postfachserver überflüssig und dieser Proxy kann auch die Verschlüsselung (SSL) übernehmen und damit den internen Server entlasten. Dies ist aber nur solange elegant, so lange es nur einen Exchange Postfachserver intern gibt. Sobald mehrere Exchange Server intern stehen, werden der Aufwand für Konfiguration und die Einschränkungen der Anwender zu hoch.


Nächste Seite