[English]Microsoft hat gerade eine neue Sicherheitsrichtlinie für Exchange Online vorgestellt, mit der die Annahme von E-Mails von unsicheren On-Premises Exchange Servern (in hybriden Umgebungen) geblockt werden kann. Die betreffenden Administratoren erhalten eine Mitteilung, dass der On-Premises Exchange Server angreifbar sei. Wird binnen 90 Tagen nicht reagiert, verweigert Exchange Online die Annahme weiterer E-Mails. Damit sollen künftig vor allem aus dem Support gefallene Systeme mit On-Premises Exchange Server 2007, 2010 und ab April 2023 auch 2013 eliminiert werden.
Anzeige
Ich bin gerade bei den Kollegen von Bleeping Computer auf das Thema gestoßen, welchess das Exchange Online-Team im Techcommunity Beitrag Throttling and Blocking Email from Persistently Vulnerable Exchange Servers to Exchange Online gerade veröffentlicht hat.
Microsoft versucht im Rahmen der besseren Absicherung der eigenen Cloud auch das Problem zu bekämpfen, dass E-Mails von nicht mehr unterstützten und ungepatchten On-Premises Exchange-Servern (in hybriden Umgebungen) an Exchange Online gesendet werden. Der Einsatz dieser unsicheren Systeme birgt viele Sicherheitsrisiken. Wird ein On-Premises Exchange-Server entdeckt, der Mails an Exchange Online-Instanzen setzt, aber nicht auf dem aktuellen Patchstand ist, greift künftig eine neues Transport-based Enforcement System.
Transport-based Enforcement System
Das von Microsoft beschriebene transportbasiertes Durchsetzungssystem in Exchange Online (Transport-based Enforcement System) besitzt dabei drei Hauptfunktionen hat: Berichterstattung, Drosselung und Sperrung. Das System soll Administratoren über nicht gepatchte Exchange-Server in ihrer lokalen Umgebung zu informieren. Und falls die Verantwortlichen für diese On-Premises Exchange Server nicht reagieren, können die Server blockiert werden.
Anzeige
- Berichterstattung: Exchange Server-Administratoren können bereits über den Exchange Server Health Checker ungepatchte Systeme erkennen. Microsoft fügt im Exchange-Administrationszentrum (EAC) von Exchange Online nun einen neuen Mailflow-Bericht hinzu, der von Health Checker getrennt ist und diesen ergänzt. Der neue Bericht (siehe folgendes Bild) liefert einem Tenant-Administrator Details zu allen nicht unterstützten oder veralteten Exchange-Servern, die E-Mails an Exchange Online senden.
Exchange-Online Bericht, Zum Vergrößern klicken
- Drosselung: Reagiert der Betreiber eines On-Premises Exchange Servers nach einer bestimmten Zeit nicht mit einem Update bzw. Upgrade, drosselt Exchange Online die Nachrichten von diesem Server. In diesem Fall gibt Exchange Online einen wiederholbaren SMTP 450-Fehler (z.B. 450 4.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online throttled for 5 mins/hr) an den sendenden Server aus. Dies veranlasst den sendenden Server, die Nachricht in eine Warteschlange zu stellen und später erneut zu versuchen. Dies führt zu einer verzögerten Zustellung von Nachrichten, und das Verzögerungsintervall wird immer länger, um den Administratoren Zeit zu geben, den Server zu aktualisieren (Details gibt es unter BlockUnsafeExchange).
- Sperrung: Wenn ein Exchange Server nicht innerhalb von 30 Tagen nach Beginn der Drosselung aktualisiert wird, blockiert Exchange Online die Annahme der E-Mail. Exchange Online gibt dann einen permanenten SMTP 550-Fehler (z.B. 550 5.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online blocked for 10 mins/hr.) an den Absender aus, der eine Nichtzustellungsmeldung (NDR) an den Absender auslöst. In diesem Fall muss der Absender die Nachricht erneut senden.
Microsoft verfolgt bewusst einen progressiven Durchsetzungsansatz, bei dem die Drosselung im Laufe der Zeit schrittweise verlängert und zum Schluss die Sperrung in allmählich ansteigenden Stufen eingeführt wird, was in der vollständigen Sperrung des nicht konformen Datenverkehrs endet. In der folgenden Tabelle sind die Stufen der schrittweisen Durchsetzung aufgeführt:
Enforcement Actions; Zum Vergrößern klicken
In Stufe 1 beginnt, wenn ein nicht konformer Server zum ersten Mal entdeckt wird. Dann setzt der Berichtsmodus ein, und der Administrator hat 30 Tage Zeit, den Server zu aktualisieren. Nach 30 Tagen ohne Reaktion beginnt die Drosselung, die in den nächsten 30 Tagen in den Stufen 2-4 alle 10 Tage erhöht wird.
Wird der Server nicht innerhalb von 60 Tagen aktualisiert, beginnen die Modi Drosselung und Sperrung, und die Sperrung wird in den Stufen 5-7 alle 10 Tage über die nächsten 30 Tage erhöht.
Ist der Server 90 Tage nach der Erkennung immer noch nicht aktualisiert, ist Stufe 8 erreicht, und Exchange Online akzeptiert keine Nachrichten mehr von diesem Server. Sobald dieser On-Premises Exchange Server nach der Blockierung gepatcht bzw. aktualisiert, akzeptiert Exchange Online wieder Nachrichten von diesem Server. So soll auch erzwungen werden, dass nicht mehr im Support befindliche Exchange Server, für die es keine Sicherheitsupdates mehr gibt, aus dem Verkehr gezogen werden.
Pausieren der Regel
Der neue Mailflow-Bericht in der EAC ermöglicht es einem Administrator, eine vorübergehende Durchsetzungspause zu beantragen. Dadurch werden alle Drosselungen und Blockierungen an Exchange Online unterbrochen und der Server wird für die vom Administrator angegebene Dauer (bis zu 90 Tage pro Jahr) in den reinen Berichtsmodus versetzt. Microsoft schreibt, dass jeder Tentant die Drosselung und Sperrung (an Exchange Online) für bis zu 90 Tage pro Jahr aussetzen kann.
Das Durchsetzungssystem wird für alle Versionen von Exchange Server und alle E-Mails gelten, die von Exchange Online empfangen werden. Microsoft beginnen mit einer sehr kleinen Untergruppe von veralteten Servern: Exchange 2007-Server, die über einen Inbound-Connector vom Typ OnPremises mit Exchange Online verbunden sind. Nach dieser ersten Bereitstellung wird Microsoft schrittweise weitere Exchange Server-Versionen in den Anwendungsbereich des Durchsetzungssystems aufnehmen. Schließlich wird der Geltungsbereich auf alle Versionen von Exchange Server augeweitet, unabhängig davon, wie diese E-Mails an Exchange Online senden. Details sind dem Microsoft-Artikel zu entnehmen.
Ähnliche Artikel:
Outlook wegen kritischer Schwachstelle CVE-2023-23397 patchen
Patchday: Microsoft Office Updates (14. März 2023)
Exchange Server Sicherheitsupdates (14. März 2023)
Outlook-Schwachstelle CVE-2023-23397 nicht vollständig gepatcht – Absicherung erforderlich
Leitfaden von Microsoft zur Outlook-Schwachstelle CVE-2023-23397
Anzeige
Ich bin bissl verwirrt. Geht es um patchen oder updaten also neu kaufen bzw. MS möchte natürlich das man mietet.
es geht vor allem darum das ungepatchte server (egal ob jemand die einfach nicht gepatched hat oder es kein update mehr gibt da eos) leicht kompromittierbar sind und damit leicht zu spam und virenschleudern werden.
Ab 11. April 2023 läuft auch der erweiterte Support für Microsoft Exchange 2013 aus. Mit Patchen ist da nicht viel, wenn all die On-Premises-Versionen 2007, 2010 und 2013 den Status "End of Life" (EoL) schon erreicht haben oder zeitnah erreichen.
Logische Schlussfolgerung: Neu kaufen.
Exchange Server 2019 (Supportende: 14.10.2025) lässt sich auch On-Premises betreiben. Der Release von Exchange 2022* (* denkbar ist auch ein anderer Name) wurde von Microsoft auf das Jahr 2025 verschoben.
Wenn ich mich nicht ganz täusche, betrifft das nur Emails, die zwischen Exchange Online und Exchange Server in einem Hybrid-Setup ausgetauscht werden. Also den Mailflow innerhalb eines eigenen Hybrid-Setups.
Das Thema betrifft nicht den Mailflow von Exchange Servern mit fremden Exchange Online Tenants.
Finde ich sinnvoll.
Im Artikel von Bleeping Computer steht folgendes :
"As Redmond explains, these are Exchange servers in on-premises or hybrid environments that run end-of-life software or haven't been patched against known security bugs."
Ich denke also beide Szenarien oder? :)
Und da im ersten Schritt auch nur Exchange 2007.
2010 und 2013 sind bei der Maßnahme noch außen vor.
Im Grunde schädigt MS so nur seine eigenen Kunden.
Es wäre auch der Hammer gewesen wenn Exchange Online Mails pauschal blockt nur weil dem System der andere absendende MS Exchange Server nicht passt. Soweit mit bekannt darf ein Anbieter auch nicht pauschal ankommende Mails verwerfen, in dem Fall geht es aber um ausgehenden Mails.
Natürlich darf man ankommde E-Mails ablehnen.
Das passiert regelmäßig wenn der Absender keinen revesrs DNS hat oder die IP zu einer Dial-up Gruppe geört.
Was man nicht darf, eine Email annehmen und dann entsorgen.
dann muss man einen Bounce an den vermeintlichen Absender schicken, das keine Zustellung erfolgte.
sehr unschön da spammer das ausnutzen.
Im Grunde eine sinnvolle Sache, ob die Details hier und dort zu Unmut führen, wird man sehen.
Aber wenn ich schaue, wieviele W7 Clients noch bei unseren Kunden laufen, die man (natürlich) wegen finanzieller Gründe nicht einfach ersetzen will, dann finde ich diese Pistole auf der Brust schon ganz ok.
Wobei W7 ja bis vor 2 Monaten noch Patches bekommen hat, wenn auch nur über ESU (bzw. über BypassESU).
Anders sieht es dagegen bei Exchange 2007 aus.
Der ist seit 6 Jahren EOL und bekommt seit dem keine Patches mehr.
Auch Exchange 2010 ist seit fast 3 Jahren EOL.
Es betrifft alle Exchange Server die ELO sind. Das Ganze hat nicht nur mit Hybrid-Umgebungen zu tun. MS wird in mehreren Stufen alle ELO Systeme später einmal blocken (aus Sicherheitsgründen). Viele winseln weil MS in Sachen Sicherheit zu wenig unternimmt, dieser "neue" Weg ist sicher der Richtige für alle "Schläfer"!
Details hier nachzulesen:
https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078
Und wie will MS das machen?
Der Mailheader kann zwar das Wort "Exchange" beinhalten, aber meines Wissens keine Information über welche Serverversion (2013,2016…) ein Mail verschickt wurde und schon gar nicht auf welchen Patchstand sich dieser Server befindet. MS bezieht diese Informationen über den Inbound Connector der hybrid Umgebung.
Außerdem betrifft es ja die ausgehende Mails einer Firma, nicht die extern eingehenden.
Schau dir mal einen Header einer Mail an, die von einer Outlook/Exchange Kombo stammt. Da steht ungeschönt verdammt viel drinnen.
Unter anderem so Dinge wie:
– mapi id
– SMTP Server (TLS) id
oder auch:
x-originating-ip:
Der SMTP-Header enthält die exakte Exchange Build Nummer und die gibt ziemlich genau Auskunft darüber, welche Hauptversion, welches CU und ich meine sogar welches SU installiert ist. Also ja, Microsoft weiß sehr wohl, von welcher Version eine Mail durch den Connector kommt.
Steht auch so in dem von Thomas Reisel verlinkten Blog Eintrag von Microsoft.
Header kann man umschreiben. ;-)
Das werden dann viele wohl demnächst machen müssen um Geld zu sparen.
Und wie ich Microsoft einschätze, werden die versuchen das abzuwürgen, indem diese Informationen nicht mehr als Klartext sondern mit einem obskuren Hashverfahren in die Header geschrieben werden. Hash ungültig, E-Mail abgelehnt.
Header werden sowieso vom Großteil umgeschrieben. So ist es völlig normal, die internen Server und IPs zu unterdrücken: https://www.alitajran.com/remove-message-header-in-exchange-server/
Der SMTP Header enthält die exakte Exchange Build Nummer?
Mal getestet, Exch 2019 on premise an gmail. Da steht nichtmal drin, dass der Sender ein Exchange Server ist :) Klar, das weiß man vom Helo, aber sonst weiß man da nichts.
Ich habe mir gerade in meinem Outlook einmal den Header einer internen Mail angesehen. Da steht der internen Servernamen und IP, die verwendete TLS Version plus Ciphern, die verwendet werden auch das Feld "ID". Und da steht dann die komplette Exchange Buildnummer drin. Also entweder steht bei dir ein Proxy/Smarthost davor, der die Header vor dem Senden abändert, oder du schaust nicht an der richtigen Stelle.
Warum sollte ich mir den internen Header ansehen? Das ist nicht der Header, der an eine externe Email-Adresse geht. Und um das ging es mir ja, denn der Inbound Connector ist ja laut MS nur der erste Schritt, und danach soll JEDE Kommunikation von alten Exchange Servern geblockt werden. Und ich frage mich, wie das per SMT gehen soll, da dort eben keine Info drinsteht.
PS: Wer hat eigentlich keinen Smarthost vor seinem Exchange Server?
Weil dein On-Prem Exchange mit dem Online-Exchange gekoppelt sind?!? Die kennen sich. Also nicht nur vom sehen her, sondern auch die Versionen usw., weil die miteinander verklöppelt sind. Steht ja auch so im Artikel … es betrifft vorerst Hybrid-Umgebungen
Irgendwo scheint da aber ein Denkfehler zu sein: der Exchange-Online-Administrator kann sich tolle und bunte Berichte generieren lassen, die auch alle einliefernden Mailserver mit evtl. veralteten oder verwundbaren Exchange-Versionen enthalten.
Falls die Administratoren der "bösen" Exchange-Server diese nicht aktualisieren, werden deren Server schrittweise ausgesperrt.
Woher erhalten aber diese Admins die Informationen aus den schönen bunten Berichten, die ja nur am Exchange Online vorliegen?
Dass sie schon längst hätten patchen sollen ist klar, aber wozu dann dieses tolle Berichtswesen?
Wie weiter oben schon geschrieben, das betrifft (derzeit) nur den Hybrid Betrieb. Also Mails die von einem lokalen Exchange 2007 per Hybrid Connector an eigene Exchange Online Postfächer gesendet werden. Somit ist der Administrator des "bösen" Exchange entweder auch der Admin vom EXO, oder zumindest in der gleichen Firma angestellt.
Da oben steht:
In diesem Fall gibt Exchange Online einen wiederholbaren SMTP 450-Fehler (z.B. 450 4.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online throttled for 5 mins/hr) an den sendenden Server aus.
und
lockiert Exchange Online die Annahme der E-Mail. Exchange Online gibt dann einen permanenten SMTP 550-Fehler (z.B. 550 5.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online blocked for 10 mins/hr.) an den Absender aus, der eine Nichtzustellungsmeldung (NDR) an den Absender auslöst.
Sollte somit für jeden der das erhält klar sein oder "googlebar".
Ab davon – was wie wo wird denn geprüft? Der einliefernde Server muss ja gar nicht der sendende Exchange selbst sein. Vmtl. wird da meistens mindestens ein "Smarthost" aka UTM-Device dazwischen sitzen. Einzig wie bereits genannt in einer Hybrid-Umgebung im eigenen Tenant macht das überhaupt Sinn. Was über SMTP 25 von was/wem/welcher Version auch immer eingeht hat Microsoft einen feuchten zu Interessieren. Die dürfen (und das ist diskutabel) maximal dann etwas ausfiltern wenn es ein Schädling ist.
Liest sich also im ersten Moment schlimmer als es ist.
Steht doch oben im Text:
Veraltete Server erhalten eine SMTP 450-Meldung zurückgeliefert und nach Sperrung eine SMTP 550-Meldung.
Man wird also darauf hingewiesen, das der eigene Exchange veraltet ist.
Wer die SMTP-Meldungen allerdings ignoriert oder fatalerweise den Exchange so konfiguriert hat, das diese Meldungen z.B. im Spam landen, hat selbst Schuld.
Entweder nutze die Header
oder Helo
oder führe mit nächstem Update ein Hash Header Funktion ein. Wer den Header nicht da, wird abgelehnt
Aber wieso so kompliziert: jemand der eine Ex07 betreibt wird sicherlich nicht mit Header Fummelei auf MS Block reagieren
Ich bin Fan von sicheren Systemen, daher finde ich es grundsätzlich gut, dass hier ein bisschen nachgeholfen wird.
Mal ehrlich, wer im professionellen Umfeld (Exchange steht in aller Regel nicht beim Privatmann) Mailserver betreibt, der muss eben alle paar Jahre aktualisieren. Ich habe absolut kein Verständnis für Menschen, die meinen ein uralter, nicht mehr patchbarer Exchange müsste unbedingt weiter betrieben werden. Dann lieber abschalten, zum Wohle aller anderen…
Ist die Überschrift nicht ungünstig gewählt? Sind dann nicht alle Exchange von Betroffen…..? ;-)
Anfangs ist das nur über einen Inbound-Connector geplant, später aber für alle Arten des Kontakts. Wie fragt man denn per SMTP ab, welche Version eines Exchange Servers da Kontakt aufnimmt :)?
Wie weiter oben schon mal erwähnt, über den SMTP-Header bzw. genauer gesagt über den X-Header. Der Exchange ist da per se anscheinend recht gesprächig und teilt dort wohl seine Buildnummer mit. Und die sagt einem ganz genau, welche Exchange Version mit welchem CU und ich meine auch SU der gerade läuft. Sofern man also nicht die Header manipuliert kann MS daraus sehr genau erkennen, wer da mit EXO sprechen will.
Ich hab das grade mit Mail 2019 an Gmail getestet und da steht im Header/X-Header nicht mal, dass ein Exchange gesendet hat, geschweige denn eine Build-Nummer. Das weiß man vom HELO, aber im Header steht das nicht. Allerdings unterdrücken wir auch interne Server-Informationen, was aber a sich die meisten machen: https://www.alitajran.com/remove-message-header-in-exchange-server/