Exchange Extended Protection

Im Aug 2022 hat Microsoft Updates für kritische Lücken in Exchange 2016/2019 released, die aber nicht durch die Installation des Updates gestopft werden. Sie müssen manuell noch die Konfiguration hinsichtlich Extended Protection anpassen.

"Extended Protection" ist eine Funktion des IIS und nicht nur für Exchange relevant. Details finden Sie dazu auf IIS Extended Protection. Es sichert aber nur Anmeldungen mit NTLM ab,

Im Exchange Security Updates Feb 2024 wird diese Funktion by Default aktiviert.
Ohne entsprechende Vorbereitungen kann der Client Zugriff gestört sei.
Siehe dazu auch CVE-2024-21410 Betrachtung und IIS Extended Protection

Kurzfassung

Die Welt ist schlecht und PCs zum Surfen gibt es in Hotels, in Internet Cafes es. Wenn Sie hier in einem Browser per OWA ihre Mails über HTTPS lesen, können Sie erst einmal nicht sicher sein, dass niemand mitliest. Lokale Administratoren können auf solchen PCs zusätzliche "RootCAs" installieren und einen InspectionProxy einschleifen, der alles mitliest. Siehe auch Fiddler.

Vereinfacht: Extended Protection verhindert dies, indem der Webserver Informationen aus dem Zertifikat im Datenstrom mit zum Client überträgt. Diese Informationen kann kein Proxy dazwischen nachmachen und der Client kann prüfen, ob die TLS-Verbindung mit dem gleichen Zertifikat aufgebaut wurde. Unterscheiden sich hier die Zertifikate, dann wird die Verbindung nicht hergestellt.

Das bedeutet aber auch beim Einsatz von "Extended Protection":

  • Ausgehender Inspection Proxy
    Wenn Sie über einen Proxy-Server surfen, der SSL-Inspection nutzt, muss die URL ausgenommen werden. Ansonsten funktionieren Outlook, OWA etc. nicht mehr.
  • Eingehender Proxy/Loadbalancer
    Wen eingehende Verbindungen nicht direkt bei Exchange sondern einem Reverse Proxy oder Loadbalancer mit SSL-Bridging/Offloading landen, dann muss das Zertifikat auf dem Loadbalancer und den Exchange Servern identisch sein. Ansonsten ist ihr Exchange Server nicht mehr erreichbar. SSLOffloading muss deakiviert werden, d.h. eine unverschlüsselte HTTP-Verbindung zwischen Reverseproxy/Loadbalancer zu Exchange um CPU-Last auf Exchange zu sparen, ist nicht mehr möglich.

Die Funktion ist nicht auf Exchange beschränkt, sondern eine Windows/IIS-Funktion und kann auch von anderen Anwendungen genutzt werden. Es gibt für Exchange noch weitere Vorarbeiten, z.B. SSLOffload bei Outlok Anywhere muss abgeschaltet werden, NTLMv1 muss entfallen, Probleme mit öffentlichen Ordnern auf älteren Servern sind zu erwarten.

Es ist eine ganze Menge von Punkten und lesen Sie unbedingt die Blog-Artikel und Anleitungen von Microsoft, eher Sie Ex2019 CU14 installieren

Die Funktion Extended Protection (EP) ist eigentlich eine Windows IIS-Thematik und schon seit 2009 verfügbar. Die Aktivierung ist aber mit dem Exchange Aug 2022 Updates erforderlich, um zusammen mit dem Update entsprechende Lücken zu schließen.

Auch mit dem Nov 2022 Update ist EP zusätzlich zu konfigurieren. Siehe Kommentar auf:
Lukas Sassl Microsoft ‎Nov 10 2022 12:15 PM "@MicPluton it’s required to enable Extended Protection to address these vulnerabilities. Without Extended Protection turned on, the server is still vulnerable."
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2022-exchange-server-security-updates/ba-p/3669045

Exchange 2019 24H1 (CU14)Update

Lange Zeit war "Extended Protection" optional und nicht standardmäßig eingeschaltet. Im dem Updates im Januar 2024 wird sich das ändern und ist von Microsoft auch schon mit dem Nov 2023 Update angekündigt worden.

Sie sollten und können sich also vorbereiten, um das Januar 2024 Update dann zügig installieren zu können. Sie können beim Setup natürlich die Aktivierung von "Extended Protection" verhindern. Ich würde aber eher folgendes machen:

Wenn ihnen all diese Aufgaben zuviel sind oder sie sich unsicher sind, dann können wir sie dabei unterstützen oder vielleicht ist eine Nutzung von Exchange Online eine Option

Wobei es je nach Firmengröße schon sportlich wäre, mal eben zu Exchange Online zu migrieren.

Offizielle Quellen

Wer genau den Exchange Team Blog Artikel liest, kann die relevante Zeile finden:

Addressing some of CVEs released this month requires admins to enable Windows Extended protection on your Exchange servers
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862

Das kleine Wort "require" wird dabei gerne überlesen. Es bedeutet aber, dass ohne die Aktivierung von "Windows Extended Protection" die Lücken noch nicht geschlossen sind und allein die Installation der Updates nicht ausreicht. Auch aus dem "Flussdiagramm" ist eigentlich gut zu sehen, dass die Aktivierung von "Windows Extended Protection" erforderlich ist.


Das Bild ist mittlerweile veraltet aber zeigt, die sie schon im Aug 2022 den Schutz aktivieren konnten.

Warum auch immer, scheint dies bei vielen Administratoren aber nicht angekommen zu sein. Um die Einrichtung abzuschließen, hat das Exchange Team sogar ein kleines Skript samt Warnung bereitgestellt:

To help you enable this feature, we have developed a script for this process. Please carefully evaluate your environment and review all known issues mentioned in the script documentation before enabling Windows Extended protection on your Exchange servers.
The current version of this script can be found at https://aka.ms/ExchangeEPScript and the documentation is at https://aka.ms/ExchangeEPDoc.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862

Und es kommt noch eine weitere Warnung dazu:


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862

Wenn ich es richtig sehe, brauchen alleine 5 von 6 CVEs die Aktivierung von Extended Protection, damit die Lücken geschlossen sind.

... And it is not mandatory to enable Extended Protection, but we recommend that you work to do so. The CVEs that refer to it will not be addressed until Extended Protection is enabled. But there is no "time requirement" here.
Quelle: Nino Bilic, Microsoft: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/bc-p/3595407/highlight/true#M33555

Welche CVE-Lücken erst durch die Aktivierung von "Extended Support" abgesichert werden, können Sie im CVE nachlesen. Nach meiner Recherche am 25. Aug 2022 waren dies:

Das kann sich aber auch ändern, wenn Microsoft die Updates überarbeitet.

Was ist Extended Protection?

"Extended Protection" ist eine Funktion des IIS und nicht nur für Exchange relevant. Details finden Sie dazu auf IIS Extended Protection

Wenn ein Client eine HTTPS-Verbindung zu einem Webserver aufbaut und dann über die verschlüsselte Verbindung sich anmeldet, dann sollte diese Kommunikation eigentlich sicher sein. Dennoch gibt es das Risiko eines "Man in the Middle (MITM)"-Attacke, wenn sich der Angreifer z.B. ReverseProxy dazwischenschaltet. Klingt schwer aber ist es nicht, denn genau genommen sind Fiddler und Co auch solche Tools und genauso könnte eine lokale Malware die Verbindung aufbrechen.

Um dies zu verhindern, wird mit Extended Protection auch eine Information aus dem "äußeren TLS-Kanal" verknüpft. Vereinfacht nutzt der Webserver eine Information aus dem Webserver-Zertifikat, um bei der Windows Anmeldung einen weiteren Faktor zu addieren. Diese Information hat der Angreifer nicht und kann daher die Anmeldung nicht simulieren, da der Client ja nur das Zertifikat des Angreifers sieht. Extended Protection ist daher keine Funktion von Exchange sondern eine Einstellung der Authentication pro virtuellem Verzeichnis im IIS.

Die Funktion gibt es nur für die Anmeldung mittels "Windows Authentication", d.h. Kerberos, NTLM aber nicht Basic, OAUTH oder andere Anmeldeverfahren. Sie sichert daher keine Anmeldungen ab, wenn Sie OWA über eine Formularanmeldung nutzen. Die beiden Hyperlinks gehen zu.

Wenn ein Client eine Verbindung zu einem Server aufbaut, könnte ein Angreifer sich einmal zwischen die beiden Systeme platzieren und als Relay, ReverseProxy,, NAT-Router alle Pakete mitschneiden und ggfls. sogar aufbrechen und damit mitlesen. Ein zweiter Angriff basiert darauf dass der Angreifer übertragene Pakete einfach noch mal überträgt und die Endstellen das nicht bemerken. Wenn z.B. das Anmeldeverfahren zwar an sich verschlüsselt ist aber die Kennwort immer mit dem gleichen Schlüssel geschützt werden, dann kann ich eine "Replay-Attacke" fahren.

Diese und andere Schwächen können abgesichert werden, indem Challenge-Response-Verfahren und Abhängigkeiten mit dem Zertifikat auf dem Backend einbezogen werden. Der IIS kann z.B. Informationen nutzen, die in seinem Zertifikat eh vorhanden und das Gegenstück "öffentlich" ist. Das macht es aber einem Angreifer unmöglich oder scher schwer, solche Verbindungen zu übernehmen, denn er hat das Wissen nicht. Allerdings hat so ein erweiterter Schutz auch Einschränkungen wie:

  • NTLMv1
    Diese schwache Anmeldefahren sollten Sie sowieso nicht nutzen aber mit Extended Protection kann es nicht mehr genutzt werden.
  • SSL Offloading/SSL-Bridging
    Wenn sie einen Reverse Proxy oder Layer-7-Loadbalancer vor dem IIS platzieren, der die HTTPS-Verbindung aufbricht, dann funktioniert dies nur dann, wenn auch auf der inneren Verbindung HTTPS mit dem genau gleichen Zertifikat zum Einsatz kommt. Sie müssen als auch den internen Verkehr wieder verschlüsseln. ein "Offloading" der Verschlüsslung ist nicht möglich.
  • Kompatible Clients mit "Required"
    Der Schutz wirkt ab besten, wenn er auch erzwungen wird, da sonst ein dazwischengeschaltetes System ja vorgeben kann, dass der Client oder der Server kein Extended Protection könnten. Mit dem Zwang sperren Sie aber alte Clients aus, die mit Extended Protection nichts anfangen können.

Das Feature wurde von Microsoft schon im August 2009 im Rahmen eines "Non Security Updates" bereitgestellt. Die meisten Webserver sollten es also können aber es wurde nicht per Default aktiviert. Es obliegt dem Anwendungsentwickler, bei der Installation seiner Lösung auf einem IIS die Konfiguration entsprechend anzupassen. Windows 7 Clients und Windows 2008R2-Server haben die Funktion schon an Bord.

Da könnte natürlich schon fragen, warum das Exchange Team diese Einstellung nicht schon viel früher zum "Standard" gemacht hat und erst nach ca. 12 Jahren den Support in Exchange dafür bereitstellt.

Checkliste

Sie könnten nun fragen, warum Microsoft mit der Installation der Updates nicht auch gleich mit aktiviert. Das wäre aber keine gute Idee, denn es gibt schon einige Abhängigkeiten, die Microsoft publiziert.

Achtung: Exchange 2019 CU14 (Feb 2024) aktiviert automatische Extended Protection, um die Lücke CVE-2024-21410 zu verhindern.

Hier meine Zusammenfassung und Ergänzungen aus anderen Quellen:

Prüfung Erledigt

Exchange Minimalversion

Die Aktivierung von Extended Protection betrifft nicht nur die Frontend-Server, sondern alle Server. Ehe Sie daher die Funktion aktivieren, müssen alle Server in der Topologie den folgenden Stand haben.

  • Exchange Server 2013 CU23 (mittlerweile Out of Support)
  • Exchange Server 2016 CU23
  • Exchange Server 2019 CU11 oder höher mit August 2022 Security Updates installed

Aktivieren Sie nicht Extended Protection auf älteren Exchange Servern.

Public Folder auf Ex2016 CU22 / Exchange 2019 CU11 oder älter

Aktualisieren Sie die Server zuerst auf die aktuelle Version (Exchange 2016 CU23 / Exchange 2019 CU12 + Security Updates).

Public Folder auf Exchange 2013 Public Folder Koexistenz

Ein Zugriff auf öffentliche Ordner über Exchange 2013 ist nicht mehr möglich. Migrieren Sie die öffentlichen Ordner auf einen Exchange 2016/2019 Server. Wenn Sie nur Exchange 2013-Server haben, können Sie das SSL-Kennzeichen auf dem "RPC virtual directory" im IIS des Backend Servers entfernen.

Modern Hybrid

Sie können keine "Modern Hybrid"-Bereitstellung mit Extended Protection betreiben. Sie müssen den Server ausfindig machen, der vom Microsoft bereitgestellten Proxy für den Zugriff auf EWS genutzt wird und bei der Konfiguration ausschließen oder nachträglich die Einstellungen auf dem EWS zurückstellen.

Um die Sicherheit zu verbessern, sollte der Hybrid Server dann keine Postfächer hosten und auch sonst nur von den Hybrid Agenten erreichbar sein.

Keine Azure App Proxy Veröffentlichung

Wenn Sie z.B. OWA über den Azure AD Application Proxy veröffentlichen, dann funktioniert dies mit Extended Protection nicht mehr, da der App Proxy wie ein Layer-7-Loadbalancer die SSL-Verbindung terminiert und nach innen neu aufbaue. SSL-Bridging ist zwar erlaubt, aber nur wenn die Zertifikate überall gleich sind. Laut Nino Bilic (Microsoft) soll das nichts gehen.

That is correct - it will not work; that is exactly why Hybrid Agent (aka Modern Hybrid) does not work with Extended Protection; because it is an Azure App Proxy.
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/bc-p/3596373/highlight/true#M33591

NTLMv1

Die Absicherung des Server mit Extended Protection verhindert eine Anmeldung per NTLMv1. Wenn alle Client auch NTLMv2 oder neuer können, dann stört es nicht. Es ist aber ein Problem für Clients, die nur NTLMv1 können oder per Richtlinie auf NTLMv1 gezwungen werden oder wenn Sie auf dem Server, warum auch immer, NTLMv1 erzwingen.

Hinweis: Die Abschaltung von NTLMv1 sollten sie schon lange vollzogen haben. Nun gibt es einen Grund mehr.
Wenn NTLMv1 nicht abgeschaltet ist, funktioniert es aber nicht mehr mit EP und NTLMv1-Only-Clients.

Retention Policies mit Tags die eine "Move"-Aktion ausführen

Diese Funktion würde dann nicht mehr funktionieren. Microsoft arbeitet daran. Ich gehe davon aus, dass der Prozess selbst auch per EWS auf den Server zugreift und hier noch Nacharbeiten erforderlich sind.

MAPI over HTTP-Probe auf Exchange 2013 geht auf "Fail"

Das "Self Monitoring" von Exchange im Rahmen von Exchange 2013 Managed Availability geht auf "Fail". Outlook kann sich dennoch verbinden und arbeitet weiter

Unterschiedliche TLS-Konfigurationen auf Exchange Servern

Es ist essentiell, dass alle Exchange Server hier z.B.: hinsichtlich der TLS-Version gleich konfiguriert sind. Seit längerem wird ja schon die Abschaltung von TLS 1.1 und älter empfohlen. Es könnte also sein, dass noch nicht alle Server "identisch" konfiguriert sind.

SSL-Offloading/SSL-Bridging

Damit Extended Protection funktioniert, darf ein vorgeschalteter Reverse Proxy, Loadbalancer etc. zwar die Verschlüsselung aufbrechen aber muss zum Backend ebenfalls mit dem gleichen Zertifikat verschlüsseln. SSL-Offloading ist nicht mögich. Es ist dabei sogar möglich, dass unterschiedliche TLS-Versionen zwischen Client<->HLB und HLB<->Exchange genutzt werden solange es das identische Zertifikat ist.

"Required" statt "Allow" auf /EWS oder /ExchangeServerActiveSync

Die Einstellung für Extended Protection darf auf diesen virtuellen Verzeichnisse nicht auf "required" stehen. Das Konfigurationsskript von Microsoft setzt diese korrekt aber vielleicht haben Sie sich bei der manuellen Anleitung verklickt.

Hybrid FreeBusy und Hybrid Migration

Die Cloud spricht dazu die veröffentlichten Exchange Frontend Servern an. Auf dem "/EWS"-Verzeichnis der veröffentlichten Frontend-Servern darf die Extended Protection aktuell nicht aktiviert sein.

If you are using Modern Hybrid or the Hybrid Agent enabling Extended Protection will cause Hybrid features like Free/Busy and mailbox migration to stop working. To resolve this issue, identify the hybrid servers that are published using Hybrid Agent and disable Extended Protection on the Front-End EWS endpoints for these servers.
Quelle: https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/

Offen

Ich habe noch keine Infos oder Tests zu den folgenden Konstellationen:

"Enhanced Security" ist ja eine IIS-Konfiguration und gibt es aber auch bei ADFS

3rd Party Programme

Wenn Sie andere Tools verwenden, die sich mit den Exchange On-Premises Servern per HTTP verbinden, dann sollten Sie nach dem Aktivieren von Extended Protection deren Funktion prüfen.

Die Voraussetzungen und den aktuellen Stand von Exchange können Sie per Skript auch automatisch prüfen lassen:

.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection | ft -autosize

Dieser Server erfüllt alle Voraussetzungen und Extended Protection ist auch aktiv.

Aktivierung

Microsoft beschreibt auf https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/#enabling-extended-protection ausführlich, welche virtuellen Verzeichnisse wie zu konfigurieren sind. Es sind pro Exchange Server insgesamt 23 virtuelle Verzeichnisse im IIS mit je zwei Parametern (Extended Protection und SSLFlags) anzupassen. Das ist dann doch arbeitsintensiv und fehleranfällig. Microsoft hilft uns daher dabei, indem sie ein PowerShell-Skript bereitstellen, welches die Änderungen macht:

Skript
https://aka.ms/ExchangeEPScript
https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/
https://github.com/microsoft/CSS-Exchange/releases/latest/download/ExchangeExtendedProtectionManagement.ps1

Voraussetzungen für den Start des Skript sind:

  • Exchange Management Shell
    Der Start muss nicht auf einem Server selbst gestartet werden. Es muss nur die Exchange Management Shell vorhanden sind.
  • Elevated Shell
    Starten Sie die Shell als "Administrator"
  • "Organization Management"
    Der ausführende Benutzer muss zudem in der Gruppe "Organization Management" sein.

Das Skript sucht am Anfang über Internet nach Updates, indem es die Datei "https://github.com/microsoft/CSS-Exchange/releases/latest/download/ScriptVersions.csv" herunterlädt. Wenn dies nicht möglich ist, sollten Sie selbst immer mal wieder nach einem Update schauen.

Wenn Sie EP aktiviert haben und die Konfiguration nicht passt, dann bekommt die Anwender mit z.B. Outlook immer wieder eine Kennwortbox, die selbst bei der Eingabe korrekter Anmeldedaten nicht funktioniert.

Achtung
Ältere Versionen des Skripts haben ohne Rückfrage direkt alle Exchange Server in der Organisation "gesichert", die es erreichen kann. Meine Version 22.08.24.1638 fragt vorab zumindest einmal:

Ich hätte das Skript so angelegt, dass es beim Start ohne Parameter nur ReadOnly den aktuellen Status anzeigt und erst bei Angabe eines Parameters die Änderungen durchführt.

Eine andere Rückfrage kann aber auch noch kommen: Das Skript ist digital signiert und wenn Sie auf ihren Server die Ausführung von Skripten beschränkt haben, müssen Sie die Ausführung erst betätigen.

[PS] C:\ExchangeEP>.\ExchangeExtendedProtectionManagement.ps1

Do you want to run software from this untrusted publisher?
File C:\ExchangeEP\ExchangeExtendedProtectionManagement.ps1 is published by CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US and is not trusted on your system. Only run scripts from trusted
 publishers.
[V] Never run  [D] Do not run  [R] Run once  [A] Always run  [?] Help (default is "D"): d

Folgende Parameter sind möglich:

  • [string[]]$ExchangeServerNames = $null,
    Sie können eine Liste oder den Namen eines Exchange Servers angeben, auf den sich da Skript beschränken soll. Damit können Sie z.B. erst mal auf einem Server die Änderungen durchführen, den Sie aus der Verteilung genommen haben und mit Clients und einer HOSTS-Datei die Funktion prüfen.
  • [string[]]$SkipExchangeServerNames = $null,
    Das ist dann die umgekehrte Vorgabe mit der die einzelne Server ausschließen können, z.B. den Hybrid Server
  • [switch]$ShowExtendedProtection
    Damit werden die aktuellen Einstellungen angezeigt
  • [string]$InternalOption
    Microsoft schreibt dazu war nichts, aber im Skript sieht man, dass nur eine Variable "$SkipEWS=$true" gesetzt wird aber zumindest in der Version 22.08.24.1638 noch keine Auswirkung hat.
  • [string]$RollbackType
    Wenn Sie hier ein "RestoreIISAppConfig" angeben, dann versucht das Skript ein Rollback basierend auf vorher angelegten Sicherheitskopien.

Wenn Sie sich unsicher sind, dann würde ich das Skript zuerst mit "-ShowExtendedProtection" aufrufen. Er läuft dann die Server durch und zeigt nur die aktuelle Konfiguration an.

Die Ausgabe ist leider kein Objekt, welches in die Pipeline übergeben wird, sondern das Skript macht direkt die Formatierung als Tabelle und Ausgabe. Hier die fraglichen Zeilen im Code:

Gleiches passiert bei der Ausgabe der Registrierungsänderungen:

Das hat Microsoft etwas unglücklich gelöst. Ich hätte da wenigstens eine Weiche per Parameter angegeben, der eine Ausgabe in die Pipeline erlaubt. Das Skript dahingehend zu ändern ist zwar einfach, aber bricht zum einen die Signierung und überlebt das nächste Autoupdate nicht.

Die Änderungen sind dann wieder unspektakulär und landen erst einmal auf der Konsole.

Wer die Ausgaben protokollieren will, sollte vorher ein "Start-Transcript" machen. Allerdings legt das Skript auch Protokolldateien ab

Wenn Sie das Skript ohne Parameter aufrufen, dann wird die Konfiguration durchgeführt. Allerdings :prüft das Skript zur Sicherheit, ob die Voraussetzungen gegen sind.

  • Exchange Updates noch nicht installiert
  • SSL Offloading konfiguriert
  • TLS 1.2-Konfiguration in NET nicht gesetzt

    Siehe dazu auch TLS 1.2 Enforcement

Nur wenn es keine Blocker gibt, sieht es wie folgt aus:

Leider sieht man auch hier, dass die Ausgaben schon im Skript formatiert und ausgegeben werden.

Die Aktivierung/Deaktivierung von Extended Protection funktioniert ohne Neustart des Server o.ä. sondern wird nahezu sofort aktiv.

Die Änderungen erfolgen auch in der Application.config. Diese wird durch ein Exchange Updates in der Regel nicht überschrieben, d.h. nach einem Update müssen Sie EP nicht erneut aktivieren. Dennoch ist eine Kontrolle ratsam

Kontrolle

Analog zu dem Skript "ExchangeExtendedProtectionManagement.ps1" aktualisiert Microsoft auch das Prüfskript "HealthChecker.PS1". Es ist vielleicht keine schlechte Idee, danach einmal das Skript laufen zu lassen.

Exchange HealthChecker

Dort wird dann auch direkt rot angezeigt, wenn Extended Protection nicht aktiv ist.

Es gibt also schon viele Hinweise von Microsoft, dass die Aktivierung von Extended Protection erforderlich ist

Leben ohne Extended Protection

Natürlich gibt es auch Firmen, die einen Reverse Proxy eines Dienstleisters nutzen. Ich habe gehört, dass es viele IT-Firmen mit kommunalen Kunden so die OnPremises Exchange Server schützen und dazu natürlich SSL aufbrechen und aus Kostengründen gerne mit Wildcard-Zertifikaten arbeiten, die Sie natürlich nicht an den Exchange Admin durchreichen. Aber auch hier gibt es Möglichkeiten.

  • Sie verzichten auf NTLM
    Es ist ja immer noch eine Anmeldung per "Form based" möglich, auch wenn dann ein Man in the Middle direkt die Anmeldekarten mitliest.
  • NTLM-Authentifizierung beschränken
    Das obige Angriffsmuster funktioniert ja, weil der Angreifer den Client des Anwender aus eine Adresse7URL leitet und dort NTLM anbietet. Es könnte daher eine Lösung sein, die NTLM-Anmeldung z.B. nur auf ausgewählte Domains zu beschränken, z.B. "Trusted Intrant". Ganz sicher ist das natürlich nicht, wenn die entsprechende Applikation sich nicht dann hält
  • NTLM deaktivieren
    Mit Windows 2025 soll NTLM sogar gan entfallen oder Microsoft ist auf dem besten Weg dahin. Wenn z.B. kein Dienst aus dem Internet per NTLM nutztbar wäre, dann würde zumindest ein externer Angreifer keine NTLM-Angriffe mehr fahren können
  • Arbeiten mit SNI
    Vielleicht hat ihr Reverse Proxy Admin noch nicht gehört, dass man problemlos mehrere Zertifikate auf der gleichen IP-Adrese:Port-Kombination mittels Server Name Indication (SNI) nutzen kann.

Es gibt also schon weitere Alternativen, um auch ohne Extended Protection zu arbeiten. Aber die Schutzmechannismen sind dann eher andere Einstellungen, die aber nicht vergleichbar sicher sind.< /p>

Weitere Links