Wie Sie Microsoft Exchange sicherer machen – Exchange Hardening Teil 1

Exchange war als E-Mail-System schon immer einer erhöhten Gefahr ausgesetzt. Dies liegt einerseits daran, dass seit der Verbreitung des Internets die E-Mail-Systeme Nachrichten auch ausserhalb der eigenen Organisation verschicken können und daher auch extern erreichbar sein müssen und andererseits am Umstand, dass die Benutzer von überall her und jederzeit auf ihre Daten zugreifen möchten.

In diesem 2-teiligen Artikel zeige ich die Möglichkeiten auf, Exchange 2016 sicherer zu konfigurieren. Im ersten Teil behandle ich allgemeine Grundsätze und den Client-Zugriff, im zweiten Teil befasse ich mich mit Transport und Datenablage.

Allgemein

Ich beschränke mich auf die aktuelle Version der Software und möchte dies auch gleich als ersten Tipp betrachten:

Aktuelle Versionen

Sowohl Exchange als auch das Betriebssystem sind in den aktuellen Versionen out-of-the-box schon resistenter gegen Angriffe als in der Vergangenheit.

System aktuell halten

Exchange- und Betriebssystemaktualisierungen sollten möglichst bald eingespielt werden, insbesondere, wenn damit Sicherheitslücken geschlossen werden. Nicht zu vergessen, dass Microsoft nur die letzten zwei kumulativen Updates unterstützt. blogs.technet.microsoft.com/exchange/2013/02/08/servicing-exchange-2013/

Am einfachsten kann die installierte Version in der Systemsteuerung kontrolliert werden:

Achtung: Die Aktualisierung kann ein Weilchen dauern.

Keine unnötige Zusatzsoftware auf den Servern installieren 

Jede zusätzliche Anwendung auf den Server erhöht die Chance auf Bugs und Sicherheitslücken. Deshalb möglichst darauf verzichten.

Host Firewall nutzen

Die integrierte Windows Firewall sollte aktiviert bleiben und nur die Ports geöffnet lassen, die wirklich benötigt werden. Exchange erstellt alle benötigten Regeln, sodass normalerweise keine Konfiguration nötig ist.

Der zusätzliche Filter zur Unternehmens-Firewall und Reverse Proxy/Loadbalancer ergibt den allgemein empfohlenen, mehrschichtigen Schutz.

Administrative Berechtigungen

Der Grundsatz, möglichst nur die Berechtigungen zu erteilen, die wirklich nötig sind, lässt sich in Exchange dank Role-based Access Control (RBAC) hervorragend umsetzen. Es gibt einige vordefinierte Rollen – falls diese den Anforderungen nicht genügen, kann bis auf die Parameter der Kommandos eingeschränkt werden.

Administratoren sollten zwei Accounts verwenden: einen normalen Benutzer, verknüpft mit der produktiven Mailbox, und einen dedizierten Administrationsaccount ohne Mailbox.

Client-Zugriff

Client

Das Client-Ökosystem sollte eingeschränkt werden, sodass nur wirklich benötigte Arten des Zugriffs zugelassen und diese weiter eingeschränkt werden können. Muss man beispielsweise Outlook von extern zulassen oder reicht Outlook on the Web (OWA)? Müssen alle mobilen Telefone unterstützt werden oder kann ich auf einen bestimmten Typ und Hersteller oder wenigstens OS einschränken?

Wie?

Mit dem Cmdlet Set-CasMailbox lassen sich pro Mailbox die meisten Zugriffsprotokolle deaktivieren oder Outlook- und ActiveSync-Versionen einschränken.

Authentisierung

Eine starke Authentisierung mit mehreren Faktoren kann den unbefugten Zugriff massiv erschweren. Deshalb sollte dies unbedingt in Erwägung gezogen werden. Dabei ist es wichtig abzuklären, welche Clients die gewählte Authentisierungsform unterstützen, und die Übrigen zu deaktivieren. Auf keinen Falls sollte die starke Authentisierung auf zum Beispiel OWA beschränkt bleiben, aber Outlook-Benutzer können weiterhin mit Benutzername/Passwort zugreifen.

Reverse Proxy / Web Application Firewall

Reverse Proxies können die im letzten Abschnitt erwähnte Authentisierung schon in einer vorgelagerten Netzwerkzone (DMZ) übernehmen. Sie erlauben es auch, die nötige Software nicht auf den Exchange Servern selbst installieren zu müssen. Je nach Produkt steht auch eine Web Application Firewall (WAF) zur Verfügung, die generelle Attacken auf den Webdienst erkennen und blockieren kann. Exchange-spezifische Regeln sind hingegen bei keinem mir bekannten Produkt vorhanden.

Microsoft empfiehlt nicht mehr zwingend wie für Exchange 2010 einen Reverse Proxy zu verwenden – der Client-Zugriff kann auch direkt von der Firewall an einen internen Loadbalancer weitergeleitet werden.

Loadbalancer

Die meisten Loadbalancer arbeiten als physische oder virtuelle Appliance auf der Grundlage eines Linux-OS. Dies hat den sicherheitsrelevanten Vorteil, dass der Zugriff der Clients aus dem Internet auf einem Nicht-Windowssystem terminiert werden kann. Auch die Prä-Authentisierung kann falls gewünscht auf dem Loadbalancer erfolgen.

TLS/SSL

Die Abwicklung des verschlüsselten Verkehrs wird durch SSL/TLS mit einer ganzen Auswahl von Algorithmen ermöglicht. Einige dieser Algorithmen gelten nicht mehr als sicher und müssen deaktiviert werden, insbesondere RC4 und SSLv3 (blogs.technet.microsoft.com/exchange/2015/07/27/exchange-tls-ssl-best-practices/).

Administrationszugriff

Achtung: Seit Exchange 2013 ist die Administration Web-basiert (Exchange Admin Center) und läuft über das gleiche virtuelle Directory wie die Einstellungen für Outlook on the Web (OWA): Exchange Control Panel oder ECP. Wird der Benutzerzugriff von extern zugelassen, ist auch das Exchange Admin Center veröffentlicht. Falls mit starker Authentisierung gearbeitet wird, kann das akzeptabel sein. Falls nicht, lässt sich dies auf unterschiedliche Arten lösen:

1. Zwei ECP Websites pro Server mit unterschiedlichen IP-Adressen konfigurieren und EAC auf der extern publizierten Website deaktivieren
2. Mindestens einen Exchange Server nicht nach aussen veröffentlichen und bei allen anderen EAC deaktivieren
3. OWA/ECP mittels AD Federation Services authentisieren und den Zugriff auf ECP extern für administrative Benutzer unterbinden

Fazit

Trotz der sichereren Out-of-the-box-Konfiguration der aktuellen Exchange-Version gibt es immer noch genügend Punkte, über die man sich zumindest Gedanken gemacht haben sollte. Im 2. Teil dieses Blogs werde ich mich mit Transport- und Datensicherheit befassen.