Exchange - Wie weiter ohne Threat Management Gateway (TMG)

Ich werde oft gefragt, was verwendet werden kann, um Exchange Services im Internet ohne TMG (Threat Management Gateway) zu veröffentlichen. In diesem Artikel zeige ich ein paar Optionen.

Hintergrund

Seit 1.12.2012 ist Microsofts Firewall/Proxy Produkt «Forefront Threat Management Gateway» nicht mehr verfügbar. Bestehende Kunden können ihre Installationen problemlos weiterbetreiben, da das Produkt noch bis 2015 im Mainstream- und bis 2020 im Extended Support ist.

TMG wurde sehr oft eingesetzt, um HTTP/S-basierte Services wie SharePoint, ADFS oder Exchange im Internet zu veröffentlichen. Mit Hilfe von Assistenten ist es sehr einfach konfigurierbar.

Folgende Anforderungen konnten durch TMG abgedeckt werden:

• Authentisierung: keine nicht authentisierten Verbindungen zu den Exchange Servern
• SSL Offloading: Die HTTPS-Verbindung wurde auf dem TMG terminiert. Dadurch wurden die Exchange Server entlastet.
• Loadbalancing: Die Verbindungen konnten an einzelne Server oder Serverfarmen im internen Netzwerk weitergeleitet werden.
• Analyse des Verkehrs: Antimalware-Überprüfung und NIS (Network Inspection Service) schon in der DMZ

Weitere Features, die aber für die Exchange Implementation irrelevant sind: Forward Proxy, VPN Gateway und Enterprise Firewall.

Die Alternativen

VPN-Lösungen mit Reverse-Proxy-Funktion

Einige Hersteller von VPN Gateways konnten bereits Exchange veröffentlichen. Dazu gehören zum Beispiel SonicWALL, F5 oder Microsoft selbst mit UAG (Unified Access Gateway).

Dies sind sicher gute Lösungen, wenn das Produkt schon im Unternehmen vorhanden ist. Andernfalls könnten die Kosten abschrecken. Für UAG muss auf jeden Fall pro authentisiertem Benutzer oder Gerät zusätzlich zum Server eine Client-Access-Lizenz erworben werden. Eventuell besitzt man die CALs schon im Rahmen einer Enterprise CAL Suite.

Somit empfiehlt es sich, die Kosten der möglichen Lösungen genau zu kalkulieren.

Loadbalancer mit Authentisierungsoption

Einige Hersteller von Netzwerk Loadbalancern haben die entstandene Lücke zum Anlass genommen, ihre Produkte mit einer Möglichkeit zu versehen, die Verbindungen neben der Lastverteilung auch zu authentisieren. Zu diesen Herstellern gehören Citrix (Netscaler) und KEMP (Loadmaster). Bei beiden Herstellern ist das Add-on noch in einer Beta-Phase (Stand März 2013).

Für eine Exchange-Umgebung mit mehreren Servern ist ein Loadbalancer sowieso nötig. Deshalb ist es auch sinnvoll, die Sicherheitsfunktionen in die gleiche Infrastruktur zu integrieren. Bei KEMP wird dafür kein Aufpreis verlangt.

Linux-basierte Reverse Proxies

Dazu gehören SQUID oder Apache. Bei dieser Lösung ist wichtig, dass die Unterstützung für Authentisierungsprotokolle abgeklärt wird. Basic funktioniert, NTLM üblicherweise nicht. Ausserdem muss das nötige Linux-Wissen vorhanden sein. Wenn dies im Exchange Team nicht der Fall ist, kann das verteilte Know-how zu längeren Troubleshooting-Zeiten führen.

IIS als Reverse Proxy

Mit dem Application-Request-Routing-Modul bietet Microsoft selbst ebenfalls einen Reverse Proxy an, der viele der Anforderungen abdecken kann. Aber Achtung: Es gibt kein Authentisierungsmodul, das in der DMZ mit Accounts aus dem AD funktioniert, wenn der Server selbst in einer Workgroup konfiguriert ist. Ausserdem unterstützt das Exchange Team diesen Setup (noch) nicht.

TMG in Form einer Appliance

Es gibt Hersteller von TMG-basierten Appliances, die gemäss eigener Angabe weiterhin ihre Produkte verkaufen können. Hierzu gehören Winfrasoft, SecureGUARD oder Iron Networks. Hierbei habe ich ein leicht ungutes Gefühl, da einige Hersteller behaupten, sie seien die einzigen, die berechtigt sind, TMG weiterhin anzubieten.

Gar keinen Reverse Proxy

Natürlich ist es ebenfalls möglich, auf einen Reverse Proxy zu verzichten und die Firewall den Verkehr direkt auf die Client Access Server weiterleiten zu lassen. Oftmals ist der Reverse Proxy reiner «Durchlauferhitzer», sogar ohne Authentisierung. In solchen Fällen gibt es keine Funktionalität, die nicht von der Firewall oder dem Exchange Server selbst zur Verfügung gestellt werden könnte.

Die Stolperfallen

Was gilt es nun bei der Wahl der Alternative zu beachten?

Authentisierungsprotokolle

Es gibt Lösungen wie zum Beispiel die aktuelle Version Netscaler, die für die externe Verbindung nur Forms-bases Authentication unterstützen. Damit ist zwar Proxying von Outlook Web Access (OWA) und Exchange Control Panel (ECP) möglich, nicht aber ActiveSync oder Outlook Anywhere.

Interne Verbindungen können entweder Basic oder NTLM verwenden. NTLM wird von Linux-basierten Proxies oft nicht unterstützt.

Integration von Zwei-Faktor-Authentisierung

Kann das Produkt für Zwei-Faktor-Authentisierung auf der Lösung installiert werden oder ist es bereits integriert? Appliances sind in dieser Hinsicht normalerweise eingeschränkt und verwenden eventuell sogar ein proprietäres Betriebssystem, das Installationen verunmöglicht. Achtung: Die Lösung einfach auf den Exchange Servern zu installieren, mag zwar eine Lösung sein, aber das funktioniert nur, wenn der Proxy die Verbindung nur durchreicht – nicht unbedingt sinnvoll.

DMZ-Integration

Funktioniert das Produkt auch in der DMZ? Wie ist die Anbindung ans AD? Hier kann zum Beispiel RADIUS oder LDAP verwendet werden. LDAP ist performanter und es muss nicht extra ein RADIUS Server oder NPS, Microsofts Implementation davon, installiert werden. Allerdings ist es ratsam, die gesicherte Variante LDAPS zu verwenden. Dafür benötigt jeder konfigurierte Domänen-Kontroller ein vertrautes Zertifikat.

SSL Offloading

Achtung: Mit Exchange 2013 RTM wird noch kein SSL Offloading unterstützt. Wichtig ist auch abzuklären, wieviele SSL-Verbindungen eine Lösung erlaubt.

Fazit

Es nützt nichts, TMG nachzutrauern, schliesslich gibt es genügend Lösungsansätze. Mein Favorit ist die Loadbalancer-Integration, da diese Geräte sowieso meistens benötigt werden. Eine Übersicht finden Sie in der folgenden Illustration – für mehr Informationen besuchen Sie einen unserer Kurse zum Thema Exchange.