Tags: Exchange, Sicherheit, IIS
Mit dem CU22 und CU11 für Exchange 2016 bzw. 2019 installiert Microsoft die neue Sicherheitsfunktion Emergency Mitigation (EM). Sie soll beim Auftreten von kritischen Schwachstellen automatisch Sofortmaßnahmen umsetzen. Diese können die Bedrohung reduzieren, aber auch Exchange-Features deaktivieren.
Microsoft weist ausdrücklich darauf hin, dass EM nur Sicherheitslücken schließen soll, solange noch kein Patch oder CU vorhanden ist, um die Schwachstelle zu beseitigen. Administratoren sind also in der On-Prem-Welt weiterhin gefordert, um die Systeme regelmäßig zu warten und Updates und CUs einzuspielen.
Automatische Reaktionen im Notfall
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 Voraussetzungen, 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ärfungsdienstes 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 Risikominderungen 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 organisationsweit 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 Sicherheitsgrü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 Einsatzerfahrungen 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 Sicherheitsmaß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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Roland Eich ist gelernter Fachinformatiker für Systemintegration und in der IT seit über 14 Jahren zu Hause. Roland deckt aufgrund seiner Erfahrungen ein breites Spektrum der Microsoft-Produktpalette ab.Zudem besitzt er verschiedene Zertifizierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
// Kontakt: E-Mail //
Verwandte Beiträge
- Microsoft ersetzt fehlerhafte Exchange Security Updates (SUs) für August
- Alte oder ungepatche Exchange-Server können künftig keine Mails an Microsoft 365 senden
- Exchange Server und IIS mit Windows Extended Protection (WEP) absichern
- Microsoft unterstützt DANE und DNSSEC in Exchange Online
- Exchange erhält mit CU11 bzw. CU22 einen automatischen Notfall-Service (Emergency Mitigation Service )
Weitere Links
4 Kommentare
Danke für den Artikel. Ich treibe ebenfalls als Fachinformatiker für Systemintegration mein Unwesen. Und ich bin ebenfalls über EM gestolpert.
Ich arbeite seit 16 Jahren im Support. Und jetzt stand ich das erste Mal vor der Konsequenz, einem Kunden zu sagen, dass er mal was nicht machen soll.
Seine Exchange Server sind nicht aus dem Internet erreichbar. Und soweit ich das verstanden habe, ist dann EM eher hinderlich. Denn der Dienst kann bei der Konfiguration keine URL abfragen.
Ich hoffe nur, dass ich da keinen Blödsinn erzählt habe. Aber uns fehlen alle die Erfahrungswerte.
Der Artikel ist sehr Informativ, aber was ist wenn wieder ein DNS hack https://officeclient.microsoft.com/ verbiegt?
Nach einer Stunde, mit der richtigen XML Datei, stehen alle Server bzw. sind alle offen.
Oder wie ist das abgesichert das hier nur Updates von MS kommen, wenn ich das richtig verstanden habe, ist das ja nur eine XML Datei die übertragen wird.
Die XML-Datei ist signiert.
Danke,
Okay dann kann sollte diese nicht verändert werden können, aber da kommt schon die nächste Frage welche Stammzertifikate gehen denn da zum signieren?
Aber einfach abwarten, mich wundert es ja schon das an OnPromise überhaupt noch gedacht wird, aus meiner Sicht will MS ja alles in die Cloud kriegen.