[English]In Microsoft 365 können Administratoren sogenannte "Empfangskonnektoren" für Exchange Online einrichten. Diese sollen den Fluss eintreffender E-Mails steuern und ggf. Regeln zum Graylisting, oder andere Einschränkungen umsetzen. Ein Leser hat mich kürzlich auf ein für ihn überraschendes Verhalten hingewiesen. Bei Filterung von Mails nur nach "TLS-Übertragung" erfolgt plötzlich ein Whitelisting der Domäne, was nicht dokumentiert ist. Der Leser fragt sich, ob das breiter bekannt ist. Ich stelle das Thema mal zur Diskussion hier im Blog ein.
Anzeige
Konnektoren in MS 365/Exchange Online
Konnektoren dienen dazu, den E-Mail-Fluss bei Exchange Online zu steuern. Konnektoren sind eine Sammlung von Anweisungen, die den E-Mail-Verkehr in und aus einer Microsoft 365- oder Office 365-Organisation bei Exchange Online anpassen. Eigentlich brauchen die meisten Microsoft 365- und Office 365-Organisationen keine Konnektoren für den regulären E-Mail-Verkehr. Von Microsoft gibt es aber den Artikel Configure mail flow using connectors in Exchange Online (deutsche Fassung hier), der die E-Mail-Fluss-Szenarien, die Konnektoren erfordern, beschreibt. Dort werden auch Szenarien skizziert, wo Konnektoren zum Einsatz kommen.
Beobachtung eines Lesers
Ein Blog-Leser hat mich bereits am 18. Januar 2024 per E-Mail kontaktiert, weil er bei der Verwendung von Konnektoren in Microsoft 365 etwas überrascht war – ich komme erst jetzt dazu, das entsprechend aufzubereiten. Der Leser schrieb mir dazu:
Hallo,
vor Kurzem bin ich über ein Verhalten von M365 gestolpert, dass mich doch sehr überrascht hat.
Ich frage mich, ob dieses Verhalten weitläufig bekannt ist oder für andere genauso überraschend ist, wie es das für mich war.
Und zwar kann man auch in M365 Empfangskonnektoren einrichten.
Zum Einrichten gibt es wohl folgende Optionen, die im Screenshot aufgeführt sind:
Anzeige
So weit so gut. Nun ist der Leser über das Verhalten des Konnektors doch etwas stutzig geworden. Dazu schrieb er mir:
Aktiviert man "Reject email messages if they arent sent over TLS" erhöht man die Sicherheit des Mail-Flusses zu den angegebenen Domänen marginal, da ja TLS verlangt wird und Plaintext damit ausgeschlossen wird. Großartig!
Was aber zusätzlich noch passiert ist, dass faktisch ein Whitelisting für diese Domäne im Hintergrund nicht sichtbar erstellt wird und einfach alle Mails akzeptiert werden, solange sie nur TLS verschlüsselt sind. Habe ich so mit dem Emkei Fake Mailer erfolgreich getestet
Ok, schränkt man das Cert noch auf die Domäne ein, ist es evtl. nicht so schlimm, aber das Verhalten ist so nicht dokumentiert bzw. konnte ich dazu nichts finden.
Microsoft sagt dazu man möge doch bitte "Enhanced Filtering" für den Connector aktivieren. Das ist laut Dokumentation – so wie ich es verstehe – nur bei Mail-Weiterleitungen sinnvoll.
Der Leser fragt dazu: "Ist das ein bekanntes Verhalten?" bzw. ist das nur für ihn neu, oder hat er was übersehen?
Anzeige
Ein E-Mail Header würde helfen um das zu verifizieren bzw. zu sehen was da genau passiert.
Bei Empfangskonnektoren gibt es drei Typen
a) Office 365
b) Your organization's email server
c) Partner organization.
Im Fall b) wird dem sendenden Host von Microsoft ein "besonderes Vertrauensverhältnis" zugesprochen. Das bedeutet, dass die "üblichen" Exchange-Online-Protection-Prüfungen nicht durchgeführt werden (also z.B. Spamfiltering).
Das ist aber nachvollziehbar. Wäre der eigene Email-Server eine Spam-Schleuder, hätte man ja ein gravierenderes Problem.
Stellt man auf Fall c) um, werden die EoP-Prüfungen aber korrekt durchgeführt.
Moin
Fall B wurde für die Hybrid Umgebung o365 onPrem Exchange entworfen und soll genau so arbeiten. Dieses Verhalten ist so erwünscht.
sollte man meinen. leider war der Test mit einem Partner connector
Zeig mal Header.
Was soll ich sagen, das Verhalten hat sich zwischenzeitlich geändert. Wir hatten das eindeutig analysiert und auch einen Fall bei Microsoft mit der Produktgruppe besprochen. Dort war die Aussage im Prinzip: "Works as designed, deal with it". Da mir das komplett neu war habe ich versucht die Info weiter zu geben.
Offensichtlich war es ja dann doch nicht "by design", da man das Verhalten geändert hat. Ich habe die alten Connectoren zu externen Partnern nur deaktiviert, daher kann ich 100% sagen, dass es kein M365 oder OnPrem Konnektor war.
Ich meine, das ist mir jetzt lieber als wenn das Verhalten wie vorher war. Auch wenn die Info im Artikel damit nicht mehr aktuell ist. Aber vielleicht liest es mal jemand und denkt sich: "Aha, deshalb hatte es sich so verhalten…"
Klingt alles ziemlich dubios. Und die nachhaltige Weigerung einen Header zur Verfügung zu stellen spricht dann für sich.
Dass MS so ein Ticket ohne Beispiel bearbeitet hat, wage ich auch zu bezweifeln …
Ich habe die original-Header damals über das File Transfer tool von MS transportiert und daher keine Kopie in meinem Postfach.
Wie auch immer kann jeder sich darüber denken was er möchte. Aber welchen Vorteil hätte ich durch gefakte Nachfrage unter Kollegen?
Ich für meinen Teil werde keine solchen Konnektoren mehr anlegen und rate auch davon ab, außer man fügt noch weitere Checks hinzu (Subject Name check oder IP Filter).
Bei uns ist es zum Glück gut ausgegangen, da weitere Sicherheitsmaßnahmen gegriffen hatten.
@Fragesteller Jcrvr:
Woran erkennen Sie an einem eingehenden Email über den Partnerconnector, dass keine Exchange-Online-Protection-Prüfungen durchgeführt wurden?
Bei meinen Tests werden auch beim Partner-Connector Header in eingehenden Emails aufgeführt wie
X-MS-ExchangeOrganization-SCL
X-Microsoft-Antispam
X-Forefront-Antispam-Report
X-Microsoft-Antispam-Mailbox-Delivery
X-Microsoft-Antispam-Message-Info
Die Interpretation der gesetzten Werte ist (natürlich) schwierig, da MS-internes Knowhow, aber dass die eingehenden Emails "whitegelistet", also ohne Prüfung angekommen werden, kann ich nicht bestätigen.
Es hatte sich so verhalten das jede Mail zugestellt wurde, die von dieser Domäne eingingen. Ob die sendenden IPs DMARC compliant waren, im SPF aufgeführt wurden oder nicht war völlig egal (wie bei whitelisting).
Ich hatte das mit dem Emkei Fake Mailer nachgestellt und konnte uns dann Mails mit den Absende-Domänen unserer Partner senden zu denen wir TLS forcen wollten.
Faktisch war dies einem kompletten Whitelisting gleichzusetzen was als Sicherheitsvorfall aufkam und dann analysiert wurde.
Laut MS war das Verhalten i.O. also haben wir alle derartigen Konnektoren abgeschaltet, danach war das Verhalten von EOP wieder wie gewünscht.
Zwischenzheitlich hat sich das Verhalten aber erneut geändert und das Whitelisting lässt sich nicht mehr nachvollziehen.