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


    Tags: , ,

    Microsoft ExchangeMit dem CU22 und CU11 für Exchange 2016 bzw. 2019 installiert Microsoft die neue Sicher­heits­funktion Emergency Mitigation (EM). Sie soll beim Auftreten von kriti­schen Schwach­stellen auto­matisch Sofort­maß­nahmen um­setzen. Diese können die Bedrohung reduzieren, aber auch Exchange-Features deaktivieren.

    Microsoft weist ausdrücklich darauf hin, dass EM nur Sicherheits­lü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 Voraus­setzungen, die dem EM geschuldet sind:

    Die Download-Seite informiert über die erweiterten Voraussetzungen für das CU.

    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.

    Das Rewrite-Modul spielt eine wesentliche Rolle bei der Abwehr von Angriffen über die HTTP-Verbindung.

    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.

    Verbindung mit dem Office Config Service per PowerShell-Script testen

    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")

    Der Windows-Dienst für EM wird immer ausgeführt, auch wenn man das Feature nicht nutzt.

    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

    Status des EM-Features mit PowerShell abfragen

    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.

    Mit PowerShell prüfen, welche Risikominderungen auf den Exchange-Server angewandt wurden

    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).

    Report zu den angewandten Sicherheitsmaßnahmen abrufen

    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.

    Der von Get-Mitigations.ps1 erstellte Report im CSV-Format

    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.

    Einträge von EM im Eventlog

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

    Zusätzlich zum Eventlog schreibt EM in eine täglich neue lokale Logdatei

    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

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Roland Eich

    Roland Eich ist gelernter Fach­infor­matiker für System­inte­gration und in der IT seit über 14 Jahren zu Hause. Roland deckt auf­grund seiner Erfah­rungen ein breites Spek­trum der Microsoft-Produkt­palette ab.Zudem besitzt er ver­schiedene Zertifi­zierungen (MCITP, MCSA und MCSE, ITIL, PRINCE2).
    // Kontakt: E-Mail //

    Verwandte Beiträge

    Weitere Links

    4 Kommentare

    Danke für den Artikel. Ich treibe ebenfalls als Fach­infor­matiker für System­inte­gration 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.

    Bild von Wolfgang Sommergut

    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.