Exchange 2016/2019: Sicherheits-Feature Emergency Mitigation installieren und konfigurieren

Der EM-Dienst kann drei Arten von Maßnahmen anwenden, um eine mögliche Bedrohung abzuwehren:

• URL-Rewrite-Regel für IIS: Damit werden bestimmte Muster bösartiger HTTP-Anforderungen blockiert.
• Deaktivierung von Exchange-Services: Anfällige Dienste auf einem Exchange-Server können hierdurch (temporär) abgeschaltet werden.
• Deaktivierung von App-Pools: Wie Exchange-Dienste können auch App-Pools deaktiviert werden.

Installation von CUs mit EM

Grundsätzlich lassen sich die genannten CUs genauso installieren wie gewohnt. Geändert haben sich nur die Voraussetzungen. Zudem müssen Administratoren die CUs nicht mehr aus dem Lizenzportal herunterladen, sondern können es auch über die öffentlichen Support-Seiten bekommen. Das CU für Exchange 2019 ist hier verfügbar.

Auf der Download-Seite des CUs erfährt man die zusätzlichen Voraus­setzungen, die dem EM geschuldet sind:

Man benötigt vor allem den URL-Rewriter für die IIS. Die Universelle C-Runtime wird bei der Installation des IIS-Moduls mit heruntergeladen und eingerichtet. Dieses erscheint dann untermittelbar im IIS Manager.

Hinweis: Bevor man mit der CU-Installation beginnen kann, möchte Exchange meistens einen Neustart durchführen.

Wie man aus den zwingenden Voraussetzungen für das CU-Setup erkennen kann, lässt sich die Installation des Entschärfungs­dienstes nicht vermeiden. Administratoren müssen das Feature aber nicht nutzen und können es nach dem Einspielen des CUs per PowerShell deaktivieren.

Microsoft verfolgt mit diesem Vorgehen offenbar das Ziel, schlecht gewartete Systeme mit dem standardmäßig angeschalteten EM abzusichern.

Eine weitere Voraussetzung für EM besteht darin, dass der Exchange-Server den Office Config Service (OCS) unter

https://officeclient.microsoft.com/getexchangemitigations

erreichen können muss. Mit diesem verbindet es sich einmal pro Stunde, um ihn auf das Vorliegen so genannter Risiko­minderungen zu prüfen.

Werden Schwachstellen erkannt, implementiert der EM-Dienst automatisch eine entsprechende Konfiguration, welche der Service in Form einer XML-Datei erhält.

Admins können mit einem mitgelieferten Script die Verbindung zum OCS testen. Es lässt sich mit

TestMitigationServiceConnectivity.ps1

aus dem Script-Verzeichnis von Exchange aufrufen.

Nachdem das CU auf dem Exchange-Server eingespielt wurde, erhält dieser einen neuen Dienst namens Microsoft Exchange Notfallrisikominderungsdienst ("Microsoft Exchange Emergency Mitigation Service"). Er sollte ggf. ins Monitoring aufgenommen werden. Egal ob man den EM aktiviert oder deaktiviert, der Dienst läuft immer mit (Status "Wird ausgeführt")

Konfiguration von EM per PowerShell

Der EM ist nach Abschluss der CU-Installation sofort aktiv und kann aktuell nur mittels PowerShell konfiguriert werden.

Den Status fragt man wie folgt ab:

Get-OrganizationConfig | fl MitigationsEnabled

Diese und folgende Einstellungen lassen sich natürlich nicht nur organisations­weit abfragen bzw. anpassen, sondern auch immer pro Exchange-Server, beispielsweise mit

Get-Exchangeserver

Mit

Set-OrganizationConfig -MitigationsEnabled $false

kann man EM organisationsweit deaktivieren. Hingegen erledigt

Set-Exchangeserver -MitigationsEnabled $false

diese Aufgabe für einen Server.

Letzteres macht durchaus Sinn, wenn einige Exchange-Server aus dem Internet erreichbar sind und andere nicht.

Anwendung von Risikominderungen prüfen

Weiterhin sollten Admins regelmäßig den Zustand des EM prüfen und schauen, ob er aus Sicherheits­gründen irgendwelche Exchange-Funktionen blockiert hat. Dies lässt sich mit dem Cmdlet

Get-ExchangeServer | fl name, MitigationsApplied, MitigationsBlocked

feststellen.

Es macht in diesem Fall Sinn, einen Automatismus zu bauen, welcher im Fall einer neuen Mitigation eine Nachricht an den jeweiligen Exchange-Administrator versendet.

Da der EM neu ist und damit noch die Einsatz­erfahrungen fehlen, kann es vorkommen, dass er Dienste oder Zugänge blockiert, welche die Abläufe im Unternehmen stören. Wenn man dann EM nicht im Blick behält, könnte eine Suche nach dem Fehler langwierig sein.

Ein weiteres Script kann die empfohlenen Sicherheits­maßnahmen weiter analysieren. Auch dieses ist im Skript-Verzeichnis des Exchange-Servers zu finden (Get-Mitigations.ps1).

Der Report schaut aktuell noch ziemlich übersichtlich aus, weil Microsoft bis auf einen Test noch keine Mitigation ausgeliefert hat. Man könnte das Script regelmäßig laufen und sich den Report auch per Mail schicken lassen.

Mitigations blockieren

Wenn man bestimmte Risikominderungen verhindern möchte, so kann der Administrator dies folgendermaßen erreichen:

Get-ExchangeServer | Set-ExchangeServer -MitigationsBlocked @("PING1")

Möchte man den Befehl auf mehrere Mitigations anwenden, dann gibt man sie in Form einer Komma-separierten Liste an.

Wichtig ist das Blockieren besonders dann, nachdem man eine der Maßnahmen rückgängig gemacht hat, etwa weil EM eine wichtige Exchange-Funktion deaktiviert hat. In diesem Fall würde die Mitigation sonst beim nächsten Durchlauf erneut angewandt.

Protokollierung im Eventlog

Für das Troubleshooting kann man die Ereignisse 1005, 1006 und 1008 mit der Quelle MSExchange Mitigation Service auswerten, welche man ebenfalls im Auge behalten sollte. Hier erfährt man Details zu den Aktionen von EM, wobei 1008 ausschließlich auftretende Fehler protokolliert.

Zusätzlich schreibt der Mitigation-Service eine lokale Logdatei unter \V15\Logging\MitigationService.

Fazit

Aktuell fehlen noch die Erfahrungen mit diesem neuen Feature, aber es bleibt zu hoffen, dass dieses nicht zu oft und nicht zu heftig eingreifen muss, so dass die Abläufe innerhalb der Organisation nicht zu sehr gestört werden. Andernfalls dürfte die Akzeptanz für dieses Feature schwinden, was jedoch der Sicherheit von Exchange insgesamt abträglich wäre.