Limit Enforcement System

In einem Blogeintrag vom 23. März 2023/8. Mai 2023 hat Microsoft das erste mal angedeutet, dass Sie Mails von nicht mehr aktuellen Exchange Servern blockieren wollen. Diese Seite beleuchtet die Zusammenhänge und, sofern schon öffentlich, die Funktionsweise.

Diese Funktion ist noch nicht scharf sondern nur angekündigt aber soll in 2023 aktiv werden. Sie betrifft nur SMTP-Verbindung von Exchange On-Premises zu Exchange Online über den "OnPremises Inbound Connector", als keine normalen Verbindungen "aus dem Internet".

Microsoft sichert die Cloud weiter ab, indem Sie zukünftig auch "unsichere Mailserver" einschränken. Dies betrifft zuerst unsichere OnPremises Exchange Server in einer Hybrid Bereitstellung aber es ist nicht ausgeschlossen, dass auch andere "alte" Server gedrosselt oder blockiert werden. Da hilft sicher nicht gegen Spammer, denn die werden sicher neue Systeme aufbauen aber Inhaber von schlecht gewarteten Systemen zum Umdenken bewegen. Anders als beim Straßenverkehr gibt es im Internet keinen "TÜV", der unsichere Fahrzeuge aus dem Verkehr zieht. Da können große Provider wie Microsoft, Google, Yahoo u.a., die angeblich ca. 70% aller Privatpostfächer hosten, schon einen Druck aufbauen.

Weckruf

Bislang ist nur folgender Blog-Artikel öffentlich und eine Information im Message Center in Office 365 Tenants.

Auf den ersten Blick könnte man annehmen, dass Microsoft mit Exchange Online zukünftig nur Mails von supporteten Exchange Servern annimmt und natürlich all den anderen Diensten wie Postfix, Sendmail, QMail etc. Aber warum sollte Microsoft einem Postfix mehr vertrauen als einem Exchange On-Premises Server, der vielleicht nicht mehr offizielle unterstützt wird?

Natürlich sollten sie ihre lokalen Exchange Server immer möglichst aktuell halten, auch wenn dies im Mai 2023 bedeutet, dass nur noch Exchange 2016 und Exchange 2019 übrig geblieben sind. Und selbst da muss es dann ein supporteter Stand sein, d.h. das aktuelle oder vorherige CU/SU und keine ältere Version. Wer also hier schludert und einen zu alten Stand hat, bekommt Abzüge in der B-Note.

Beim Exchange Hybrid Setup vertraut der Exchange Online Tenant dem lokalen Server, als wenn es ein internes System ist. Wenn das interne System aber unsicher ist, dann ist auch der Tenant im Risiko und wenn über einen gehackten lokalen Server Schadsoftware über die Cloud ins Internet gesendet werden, leidet auch die Reputation von Exchange Online.

Microsoft erfasst heute schon die einliefernden Mailserver und ich bin immer wieder überrascht, wenn die Kuchendiagramme selbst im Jahr 2023 einen "sichtbaren" Anteil an Exchange 2007 Servern zeigen, die maximal Windows 2008R2 unterstützen, was auch schon lange nicht mehr gepatched wird.

Scope: Hybrid Connector

Was in der ganzen Aufregung aber gerne vergessen wird, ist die Beschränkung dieser Maßnahme auf den On-Premises-Connector. Es gar nicht um den generellen Empfang von Mails über SMTP und deren Einlieferung zu Exchange Online sondern nur um die Mails, die von einem lokalen Exchange Server zum eigenen Tenant zugestellt werden. Wer so eine "Exchange Online - Hybrid"-Umgebung betreibt, hat seinen Tenant sehr eng mit seinen lokalen Exchange Server gekoppelt und bei der Konfiguration durch den HCW - Hybrid Configuration Wizard wird im Tenant auch ein "Inbound Connector - Typ: On-Premises" eingerichtet. Exchange Online erkennt dann den lokalen Exchange Server anhand der Source-IP oder, besser noch, dem Client-Zertifikat.

Diese "besondere" Verbindung bekommt deutlich weitere Berechtigungen, z.B. dass die Mails über diesen Connector als "intern" angesehen werden. Der Absender kann per Definition nicht gefälscht sein, Empfangsbeschränkungen auf Postfächern und Verteilern werden anhand des Absenders und nicht mehr über "anonym" ausgewertet und ein solches On-Premises System kann sogar Mails über Exchange Online in die Cloud versenden.

Und ab da hat Microsoft nicht nur für den einen Kunden sondern für alle Kunden und den Service an sich ein Interesse, das diese Mails keinen Missbrauch darstellen. Wenn Sie aber nun lokal immer noch einen Exchange Server betreiben, der anhand seiner Versionsnummer nachweislich Lücken hat und damit "im Feuer" stehen kann, dann muss man sich im Zeichen von "Zero Trust" schon fragen lassen, warum das System mitspielen darf. Insbesondere wenn Microsoft entsprechende Exchange Updates, Patches oder Mitigations (EEMS - Exchange Emergency Mitigation Service) veröffentlicht hat und der Administrator einfach noch nicht zur Installation gekommen ist. Wie schnell so was schief gehen kann, haben wir mit Hafnium Exploit und Pwn2Own 2021 in der Vergangenheit gesehen.

Alle Vorkehrungen gelten nicht für Mails, die anonym über andere Connectoren oder aus dem Internet zugeliefert werden.

Wenn dann ein solcher unsicherer On-Premises Server "gehackt" wird, und über Exchange Online sehr viele unerwünschte Mails an Exchange Online Postfächer, andere Tenants oder in die Welt sendet, dann hat sehr wohl nicht nur der Kunde ein Problem sondern der komplette Exchange Online Service könnte von anderen Spamfiltern abgewertet werden. Hier hat Microsoft zurecht ein Interesse, nicht nur die eigenen Kunden gegen eingehenden Spam aus dem Internet zu schützen, sondern auch zahlende Kunden den unwissentlichen Missbrauch zu verhindern.

Reporting

Gehen wir also davon aus, dass Exchange Online anfangen wird, Mails von lokalen Exchange Servern nach gewissen Kriterien zu drosseln und im Endeffekt auch zu blockieren, wen Sie vorgeben aus der eigenen Firma zu kommen und zu Exchange Online der Firma zustellen wollen. Das macht Microsoft natürlich nicht von heut auf morgen, sondern in verschiedenen Wellen und über das Exchange Admin Portal auf https://admin.exchange.microsoft.com können Sie demnächst sogar einen Report einsehen:


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078

Es hat den Eindruck, dass Microsoft aus den "Received By"-Zeilen der eingehende Mails sich einfach die Version des Exchange Server extrahiert um dessen Patchstand zu erkennen. Solche Angaben sind natürlich nicht digital signiert und könnten verfälscht werden. Allerdings ist es recht unwahrscheinlich, dass jemand On-Premises mit Transportregel hier arbeiten wird.

Enforcement

Wenn ein Administrator aber weder die Meldungen im Messagecenter noch im Reporting findet, dann wird er indirekt durch ein Throttling immer mehr auf die Situation hingewiesen. Microsoft unterscheidet hier 8 Stufen und zu jeder Stufe gibt es einen Report. Wenn ein einliefernder Server 30 Tage aus Sicht von Microsoft nicht "Compliant" ist, dann startet "Stage 2" und pro Stunde werden für 5 Minuten alle Mails von diesem Server zu Exchange Online mit einem temporären SMTP-Fehler abgewiesen. Das könnte wie folgt aussehen:

450 4.7.230 Connecting Exchange server version is out-of-date; 
            connection to Exchange Online throttled for 5 mins/hr. 
            For more information see https://aka.ms/BlockUnsafeExchange.

Der einliefernde On-Premises Server stellt die Mail zurück und versucht es später wieder. Die meisten Anwender sehen also entweder noch keinen Fehler oder bemerken maximal eine Verzögerung. Der Anteil dieser Zeit nimmt bis maximal 50% alle 10 Tage zu. Eher früher als später sollte ein Administrator also die Beschwerden seiner Anwender ernst nehmen und bei der Fehlersuche diese "450 7.4.230"-Meldungen erkennen.


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078

Nach ca. 60 Tagen startet bei Stage 5" die nächste Eskalation, bei der nun für 5 Minuten zusätzlich Mails mit einem "500 5.7.230"-Fehler permanent abgelehnt werden:

550 5.7.230 Connecting Exchange server version is out-of-date; 
            connection to Exchange Online blocked for 10 mins/hr. 
            For more information see https://aka.ms/BlockUnsafeExchange.

Diese dauerhafte Ablehnung dieser Mail führt dazu, dass ihr eigener On-Premises Exchange Server einen Unzustellbarkeitsreport an den Absender der Mail zurück sendet. Spätestens jetzt kann der Administrator des lokalen Exchange Servers nicht mehr untätig bleiben. Mit den weiteren Stufen 6-8 nimmt der Anteil der "Unzustellbarkeiten bis auf 100% zu.

Nach 90 Tagen kann ein On-Premises Exchange Server keine Mails mehr an seinen Tenant über Hybrid Mail Routing senden.

Wenn der Administrator oder Managed Services Dienstleister erst jetzt aus seine Büroschlaf erwacht ist, kann er als "Quick Fix" bei Microsoft beantragen, dass diese Blockade für bis zu 90 Tage außer Kraft gesetzt wird.

Bitte stellen Sie nicht von vorneherein den Antrag diese 90 Tage zu aktivieren, denn es gibt keine Verlängerung.

Diese Filterung ist aktuell erst einmal für Exchange 2007 geplant.

"The enforcement system will eventually apply to all versions of Exchange Server and all email coming into Exchange Online, but we are starting with a very small subset of outdated servers: Exchange 2007 servers that connect to Exchange Online over an inbound connector type of On-Premises."
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078

Ich bin aber sicher, dass Exchange Online später auch andere unsichere Versionen berücksichtigt.

Ohne OnPremises-Connector?

Wenn Sie genau mitgelesen haben, dann wissen Sie, dass diese ganze Drosselung und Ablehnung von Exchange Online nur angewendet wird, wenn es sich um einen "On-Premises"-Connector handelt. Sie könnten ja z.B. alternativ einen "Partner-Connector" anlegen, der statt des On-Premises-Connectors auf die Source-IP oder das Source-Zertifikat triggert und so den Standardeingang mit Spamfilter etc. umgeht.

Ganz ohne eine Konfiguration sollten Sie allerdings nicht arbeiten, wenn Sie auch lokal einen Exchange Server für die gleiche Domain betreiben, denn eine Mail von einer eigenen Maildomain von "extern" dürfte durch Exchange Online Protection sehr oft als Phishing oder Spam klassifiziert werden und damit vermutlich nicht zuverlässig im Postfach landen.

Wer Exchange On-Premises mit Exchange Online zuverlässig verbinden will, kommt daher nicht umhin, dass der lokale Server ausreichend aktuell ist.

On-Premises Connector ohne Exchange?

Sie können in Exchange Online einen "Inbound Connector" vom Typ "On-Premises" anlegen und anhand der Source-IP oder Zertifikat qualifizieren. Der einliefernde Server muss dabei aber gar kein Exchange Server sein. Das Szenario beschreibt Microsoft sogar selbst:


Quelle: Configure mail flow using connectors in Exchange Online
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/use-connectors-to-configure-mail-flow#when-do-i-need-a-connector

Es könnte ja sein, dass Sie lokal verschiedene Dienste nutzen, die Mails an die Exchange Online Postfächer oder sogar darüber hinaus ins Internet senden sollen. Ein Weg wäre natürlich, diese Mails gar nicht über Exchange Online zu senden, sondern über einen anderen Mailversender zu leiten. Mit der passenden Konfiguration kann aber auch Exchange Online als ausgehendes Relay verwendet werden. Ein Dienst kann mit jeder definierten SMTP-Adresse eine Mail an Exchange Online zur direkten Zustellung ins Postfach oder als Relay ins Internet senden. Allerdings sollten sie die einliefernde IP-Adresse z.B. per SPF für ihre eigene Domain freischalten, damit Exchange Online Protection die Mail nicht als Spoofing aussortiert.

Denken Sie auch daran, dass Exchange Online die Absenderadresse auf ihre Domain prüft.

Generell sollten Sie aber auch keine Mails versenden, zu denen es keinen Rückweg gibt

Auf die Frage, ob Exchange Online nun auch diese Verbindung auf eine Version prüft, konnte ich noch keine Antwort finden. Ich vermute mal, dass Exchange Online hier zumindest am Anfang keine Prüfung ausführt.

Aber auch hier sollten Sie eine "Fair use"-Policy und die Exchange Online Service Descriptions und Limit im Blick behalten. Wer sich eine 1 User Microsoft 365 E1-Lizenz kauft, um damit tausende Mails versenden will, dürfte gegen die Nutzungsbestimmungen verstoßen. Auch wenn Microsoft nicht jeden Verstoß hart abregelt, sollten Sie nicht sicher sein, dass dies auch immer so bleibt.

Blockade aufgrund der Version?

Ich wurde natürlich gefragt, wie Exchange Online denn die Version eines einliefernden Exchange Servers ausfindig machen kann. Dazu brauchen Sie einfach nur eine Mail zu öffnen, die Sie von ihrem On-Premises-Server in ihrem Exchange Online Postfach erhalten haben, indem ein lokaler Benutzer oder eine SMTP-Einlieferung eine Mail an ein Exchange Online Postfach sendet. Wenn Sie dann den "Header" der Mail anschauen, dann sehen Sie mehrere dieser "Received:"-Zeilen, die den Weg der Mail von unten nach oben wiedergeben. Interessant ist die letzte Zeile:

Received: from FR3P281MB1646.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:7d::12)
 by FR3P281MB1678.DEUP281.PROD.OUTLOOK.COM with HTTPS; Sat, 6 May 2023
 14:34:22 +0000
Received: from AS9PR06CA0535.eurprd06.prod.outlook.com (2603:10a6:20b:49d::33)
 by FR3P281MB1646.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:7d::12) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.29; Sat, 6 May
 2023 14:34:21 +0000
Received: from AM7EUR03FT038.eop-EUR03.prod.protection.outlook.com
 (2603:10a6:20b:49d:cafe::a4) by AS9PR06CA0535.outlook.office365.com
 (2603:10a6:20b:49d::33) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.29 via Frontend
 Transport; Sat, 6 May 2023 14:34:21 +0000
Received: from mail.netatwork.de (80.66.20.27) by
 AM7EUR03FT038.mail.protection.outlook.com (100.127.140.120) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
 15.20.6387.12 via Frontend Transport; Sat, 6 May 2023 14:34:20 +0000
Received: from NAWEX16.netatwork.de (192.168.100.33) by NAWEX16.netatwork.de
 (192.168.100.33) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2507.23; Sat, 6
 May 2023 16:34:19 +0200
Received: from carius.de (192.168.101.105) by NAWEX16.netatwork.de
 (192.168.100.33) with Microsoft SMTP Server id 15.1.2507.23 via Frontend
 Transport; Sat, 6 May 2023 16:33:31 +0200

Die von unten erste Zeile zeigt die Einlieferung von meinem Desktop 192.168.101.105 per SMTP an den lokalen Exchange Server von Net at Work. Der empfangende Server protokolliert dies unter Angabe der von ihm gesehenen IP-Adresse aber auch die Version 15.1.2507.23. Die Versionsnummern können Sie ganz schnell gegen bekannte Seite prüfen:

Die 15.1.2507.23 steht dabei für Exchange 2016 CU23 vom März 2023. Diese Versionsnummer wertet Exchange Online beim Empfang aus.

Ich wüsste nicht, dass Exchange beim SMTP-Transport eine Erweiterung nutzt, um die Versiondaten zu übermitteln. Allerdings nutzt Exchange XOORG und Exchange, was ein 3rd Party Gateway nicht kann und daher darf zwischen Exchange On-Premises und Exchange Online ja auch kein anderes SMTP-Relay stehen.

Insofern ist Exchange Online natürlich davon abhängig, dass der On-Premises Server hier korrekte Werte einträgt und niemand auf dem Weg die Werte verändert. Da diese Prüfung aber aktuell nur eine Verbindung vom eigenen On-Premises-Server betrifft, welche über den "OnPremise-Connector" in der Cloud seine Mails zustellt, sollten Sie noch auf folgende Zeilen im Header achten:

X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=<guid>;Ip=[<ip>];Helo=[mail.netatwork.de]
X-MS-Exchange-CrossTenant-AuthSource: NAWEX16.netatwork.de
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem

Durch den Wert "HybridonPrem" im Feld "X-MS-Exchange-CrossTenant-FromEntityHeader" wird deutlich, dass diese Mail über einen "OnPrem-Connector" auch zugestellt wurde.

Dies ist übrigens auch eine elegante Möglichkeit zu prüfen, ob ihre Hybrid-Bereitstellung auch korrekt funktioniert.

Version als Spamfilter?

Die Kontrolle der Version soll wohl nur für den Hybrid Connector erfolgen aber wäre es nicht generell interessant, die Versionsnummer des einliefernden Mailservers z.B. als Filterkriterium für Spam einzusetzen? Nun ist es aber wie so oft, dass die Spammer solche Filter ganz schnell dadurch umgehen, dass Sie entweder aktuelle Produkte einsetzen und vor allem die Nummer sehr einfach fälschen können.

Sie würden also nur die Firmen bestrafen, die mit alten Servern ihre Mails versenden. Ein alter Service ist zwar grundsätzlich eher für Missbrauch anfällig aber nicht generell unsicher. Gegen eine unsichere Konfiguration, insbesondere bei Mailservern, ist eine aktuelle Version auch nicht gefeit.

Insofern sollten wir diese Filterung nur für Systeme nutzen, die wie sehr gut kennen, ihre korrekte Version ausliefern und allein anhand der Source-IP oder des Zertifikats einen höheren Vertrauenslevel erhalten. Genau das bekommen Exchange On-Premises Server bei einer Verbindung zum eigenen Tenant zugestanden. Für Spam-Filterung ist dieses Kriterium aber nicht sinnvoll.

Wenn Sie neugierig sind, könnten sie natürlich dennoch die Header der Mails ihrer Kunden und Lieferanten auf veraltete Softwarestände überprüfen und vielleicht einen Hinweis geben. Besonders für Dienstleister wäre dies durchaus ein Möglichkeit, dem Absender ein Updateangebot zu unterbreiten. Das kann aber auch nach hinten los gehen.

Einschätzung

Die neue Funktion wird dafür sorgen, dass eine Hybrid Bereitstellung nur noch mit On-Premises-Servern möglich ist, die von Microsoft auch unterstützt werden. Umgekehrt bedeutet dies, dass ältere Server nicht mehr ihre Mails an Exchange Online der eigenen Firma zustellen dürfen. Es betrifft aber nicht die Zulieferung von einem alten Exchange 2010 Server an einen anderen Tenant oder gar das Internet sondern wirklich nur die eigene Hybrid-Verbindung und hier sollten Sie schon aus eigenem Interesse dafür sorgen, dass die Server aktuell sind.

Ich kann verstehen, dass es wenige Firmen geben wird, die heute noch mit Exchange 2007, Exchange 2010 und Exchange 2013 arbeiten und nach Aktivierung dieser Funktion nach spätestens 90 Tagen nicht mehr den Hybrid-Mode nutzen können. Vielleicht zählen noch ein paar Exchange 2016 Kunden auf Windows 2012R2 dazu, der auch im Herbst 2023 aus dem Support fällt aber das Betriebssystem ist für die Cloud nicht relevant, weswegen die Exchange 2016-Firmen noch eine längere Schonfrist haben.

Dennoch muss man auch Microsoft verstehen, die ihre Plattform besser schützen wollen und ein lokale Exchange Hybrid-Server, der über einen "OnPrem"-Connector seine Mails an einen Tenant einliefern kann, hat damit schon sehr viele "Vorteile", die er aber nicht haben sollte, wenn er nachweislich unsicher ist. Und das sind Exchange Server früher oder später, wenn Sie von Client erreichbar sind, eine Lücke entdeckt wurde und nach 10 Jahre Support nicht mehr vom Hersteller gestopft werden. Wenn Sie solche alte Server weiter betreiben wollen, dann konfigurieren sie einen "Partner-Connector". Allerdings ist die Cloud dann kein "ausgehendes Relay" mehr für ihre On-Premises-Systeme. Hier müssen Sie sich dann einen alternativen Weg zum Versand von On-Premises ins Internet überlegen.

Ich sehe keine ernsten Probleme, die sich nicht lösen ließen und als Administrator bekommen Sie sehr lange vorab Hinweise, Meldungen und nach und nach werden die Nutzer als "Sensor" ihren Admin mit Problemberichten aus seinem Dämmerschlaf wecken. Wenn Sie sichere und supportete Systeme betreiben, dann werden Sie diese weitere Schutzfunktion von Microsoft gar nicht bemerken.

Weitere Links