Exchange Online als Nebeneingang für Mailempfang

Wenn Sie Office 365 mit Exchange Online nutzen, aber ihre Mails nicht über Exchange Online Protection leiten, weil Sie z.B. einem anderen Spamfilter vertrauen oder Zusatzfunktionen wie SMIME/PGP u.a. integrieren wollen, dann sollten Sie sicherstellen, dass die generelle Konfiguration in ihrem Tenant ihnen keine Hintertür öffnet.

Siehe dazu auch Hybrid Hintereingang und X-OriginatorOrg

Ausgangssituation

Aufgefallen ist es mir bei einem Kunden, der gerade erst mit Exchange Online gestartet ist aber die meisten Empfänger immer noch "On-Premisess" sind. In dem Beispiel wurde zudem der Net at Work NoSpamProxy als AntiSpam/Antivirus-Gateway eingesetzt, welches auch noch SMIME/PGP-Verschlüsselung, Dokumentkonvertierung etc. bereit gestellt hat. In diese Umgebung wurde nun auch ein Exchange Online Tenant integriert und per Hybrid-Setup mit Hybrid Centralized Mail Transport. Eine solche Konfiguration sieht daher wie folgt aus:

Technisch bedeutet das:

  • MX Record verweist auf NoSpamProxy
  • Eingehende Mails über NoSpamProxy werden vom On-Premises Exchange Server lokal zugestellt oder über den Connector zu Office 365 geroutet.
  • Ausgehende Mails gehen über NoSpamProxy in das Internet
    Damit können die Empfänger z.B. den SPF-Record überprüfen und wir können natürlich Disclaimer, SMIME/PGP-Verschlüsselung aber auch TLS-Verifikation durchführen
  • Mail von Office 365 ins Internet gehen über den On-Premises Server
    Dazu gibt es einen Connector von Office 365 zur lokalen Umgebung, die entsprechend

Solange nun in Exchange Online keine Benutzer aktiv sind, sollte auch der Exchange Server in Office 365 ziemlich "ruhig" sein.

Findige Spammer

Allerdings habe ich hier doch einmal über das Messagetracking geschaut, ob dem auch so ist. Wenn ich einen Pilot oder PoC mit Office 365 in die Produktion überführe, muss man schon mal schauen, wer mit dem Testfeld vielleicht schon unbemerkt produktiv arbeitet. Ich war dann schon überrascht, dass es die ein oder andere Mail gab, die sogar von extern gekommen ist. Das hat mich umso mehr überrascht, da der Office 365 Tenant so gar nicht "öffentlich" war. Es gab keinen MX-Record, der auf die Exchange Online Dienste verwiesen hätte.

Die gefundenen Mails waren "natürlich" SpamMessages und so langsam glaube ich zu verstehen, was da passiert.

  • Ein Spammer möchte seinen Müll loswerden
    Das sind nicht nur "Massenspammer" sondern auch gerichtete Angriffe auf einen Kunden mit wenigen Mails sind hier interessant
  • Gute Sender nutzen MX-Records, Böse suchen Alternativen
    Da die Spamfilter immer ausgereifter werden, suchen die Spammer schwächer gesicherte Türen. Schon früher habe ich beobachtet, dass Spammer bevorzugt den "Backup-MX" nutzen obwohl der primäre Mailserver ebenfalls erreichbar gewesen wäre. Die Überlegung dahinter ist, dass der Backup-MX vielleicht beim Provider steht und einen schlechteren oder gar keinen Spamfilter hat. Mails über diesen Service wird eine Firma aber eher annehmen, denn bei einer Ablehnung würde der Backup-MX die Unzustellbarkeiten (Exchange und NDRs) versenden und zwangsläufig zum NDR-Backscatter werden.
  • Office 365 Hintertür
    Exchange Online Protection ist durchaus ein leistungsfähiger Spamschutz aber auch nicht 100% zuverlässig. Ich kann mir das nur so erklären, dass die Spammer nun auch diesen Weg versuchen, um ihren Schadcode zuzustellen.

Es kann keine Fehlkonfiguration sein, das durch das zentrale Mailrouting über die On-Premises Umgebung und den lokalen NoSpamProxy waren die Office 365 Dienste nie über SPF, DKIM, MX-Records für die Domäne ersichtlich. Für einen Spammer ist es natürlich kein Problem zu einer bekannten Domäne zu ermitteln, ob es einen Office 365 Tenant dafür gibt. Dazu muss er z.B. nur per NSLOOKUP nach einem TXT-Record suchen, der ein "ms=xxxxxxx" enthält. Schon kann der Sender ziemlich sicher sein, dass auch SMTP zu Office 365 möglich ist. Die Mailserver sind ja für alle Tenants identisch und einfach aufzulösen. herausgekommen ist also folgendes Mailrouting

Das gilt es natürlich zu verhindern.

Microsoft hat das Thema mittlerweile auch in einem Blog-Artikel thematisiert
Advanced Office 365 Routing: Locking Down Exchange On-Premises when MX points to Office 365
https://techcommunity.microsoft.com/t5/exchange-team-blog/advanced-office-365-routing-locking-down-exchange-On-Premises/ba-p/609238

Microsoft Vorschlag

Auf der Techcommunity-Seite hat Microsoft im Jahr 2019 ebenfalls das Thema beschrieben:

Microsoft nutzt dazu Transportregeln in Verbindung mit dem Header X-OriginatorOrg. Die Microsoft-Beschreibung wurde ca. 1 Jahr nach dieser Seite erstellt und ich habe das Feld X-OriginatorOrg damals schon gesehen. Es gab auch Felder wie "X-MS-Exchange-Crosstenant-Id" und "X-MS-Exchange-Organization-AuthAs", die aber alle damals nicht offizielle beschrieben waren. Im Sep 2022 ist dann z.B. das Feld "X-MS-Exchange-Crosstenant-Id" wieder verschwunden.

Heute würde ich die Beschreibung von Microsoft umsetzen.

Ich habe dennoch die weiteren Beschreibungen nicht gelöscht. Vielleicht helfen die Überlegungen beim Verständnis der Problematik

Hybrid Fehlkonfiguration

Eine weitere Quelle solcher Irrläufer kann eine fehlerhafte Konfiguration in einem anderen Tenant sein. Wer Office 365 als Mailserver nutzt, steht fast immer vor der Herausforderung, interne Mailmailserver den Versand über Office 365 zu erlauben. Technisch wird dies durch einen "Inbound Connector" in Office 365 gewährleistet, über den Nachrichten der selbst betriebenen Mailservern eingeliefert werden.

Office 365 nutzt zur Identifizierung dieser Systeme die Source-IP-Adresse oder den CN aus dem TLS-Zertifikat:

Soweit klingt das alles verständlich. Allerdings zeigt es sich immer wieder, dass bei der Konfiguration des "Inbound Connectors" etwas vergessen wird oder beim Versand z.B. die Source-IP auf der Firewall falsch gesetzt wird oder jemand einen neuen Mailserver "On-Premises" installiert und die Konfiguration in der Cloud nicht anpasst.

Wenn dann dieser interne Server seine Mails an die Postfächer in der Cloud senden will, dann wird er nicht über den "Inbound Connector" erfasst, sondern wie ein ganz normaler "anonymer" Absender über Exchange Online Protection geführt und die Mails wird zugestellt, wenn Sie nicht als Spam erkannt wird. Der normale Anwender der Firma in der Cloud erkennt also auf den ersten Blick keinen Unterschied da die Mail angekommen ist.

Wenn dieser Server nun aber über den Tenant auch Mails zu anderen Domänen zu senden, dann kann er dank des Smarthosts auch andere Tenants erreichen, obwohl der MX-Record der Empfängerdomäne vieleicht gar nicht auf Office 365 verweist. In dem Fall empfängt die anderen Firma Mail direkt in Office 365 oder bei Hybrid sogar lokal mit Office 365 als Zwischenstation. Der Admin der Empfängerstation siehet dann eigentlich nur wenige Mails wo er doch gar keine Mails erwartet.

Wenn es aber wirklich so sein sollte, das der Absender diese Systeme Mails an seinen eigenen Tenant senden will und mangels passendem Eintrag die Mails so beim anderen Tenant landen, dann dürfte der Absender zumindest keine Mails an Domains senden können, die nicht in Office 365 gelistet sind. Office 365 ist ja kein „offenes Relay“. Da kann ich nur hoffen, dass der Betreiber auch die Rückmeldungen (NDR) verarbeitet.

Office 365 Verhalten

Da stelle ich mir natürlich die Frage, wie sich Office 365 diesbezüglich verhält. Als Spammer kann ich es also einfach versuchen eine Mail an die Office 365 Plattform zu senden, auch wenn kein MX-Record darauf hinweist. Aktuell passiert dann folgendes:

  • Es gibt die Domain wirklich nicht
    Das kann passieren, wenn der Spammer sich die Mühe spart vorher per DNS-Abfragen zu prüfen, ob es die Domain in Office 365 gibt. In dem Fall lehnt Office 365 einfach ab. Noch keine Gefahr für den Empfänger aber wohl für den Sender, wenn je häufiger der Absender dies versucht, desto eher landet er auf einer Blockliste.
  • Die Domain gibt es in Office 365 und EOP nimmt
    Natürlich läuft der normale Spamfilter-Prozess hier an. IP-Adressen mit schlechter Reputation werden gleich abgelehnt und auch andere Verbindungen und Inhalte werden natürlich auf Schadcode und Werbung geprüft. Massenspam kommt an Exchange Online Protection 365 in der Regel kaum vorbei. Auch hier besteht also noch keine Gefahr für das Ziel
  • EOP nimmt die Mail an und erkennt keine Mail
    In dem Fall wird die mal an das Postfach zugestellt. Das Postfach kann dabei sowohl in Exchange Online aber auch On-Premisess liegen. Dank der Weiterleitungen sind Empfänger in beiden Welten erreichbar. So eine Mail geht also an ihrem etablierten Spamfilter vorbei

Eigentlich sollte Microsoft prüfen, ob für registrierte Domains der MX-Record auch auf Office 365 verweist. Interessanterweise prüft Office 365 dies und meldet auch, wenn die EOP-Server nicht als MX-Record eingetragen sind. Aber es verhindert nicht, dass doch jemand über Exchange Online Mails an diese Domain einliefert.

Versuch mit Connection Filterung

Damit meine Umgebung entsprechend geschützt ist, hatte ich zuerst vor über die Connection Filterung die IP-Adressen zu beschränken. Meine Planumgebung sollte also wie folgt aussehen. Durch eine geeignete Konfiguration legen Sie quasi einen Schutzgürtel um ihren Office 365 Tenant, der dann über die Allowlist nur noch ausgewählte IP-Adressen mit ihrem Tenant kommunizieren lässt:

In der Allowlist sollten sie natürlich alle Server eintragen, die sich mit ihrem Server verbinden dürfen. Dazu gibt es im Exchange Online Admin Center die Funktion entsprechende IP-Blocklisten oder IP-Allowlisten zu aktivieren. Hier ist normalerweise nichts hinterlegt:

Es gibt hier nur genau einen "Default"-Eintrag. Daher fehlt sowohl der "Add"-Button und den Default-Eintrag können sich auch nicht löschen. Ich weiß nicht, ob Microsoft eine Erweiterung plant. Ich würde mir schon wünschen, dass man mehrere Einträge anlegen und entsprechend benennen kann. Es wäre einfach etwas übersichtlicher, wenn ich mehrere IP-Adressen oder Bereiche verwalte. So kann ich nur einen Default-Bereich verwalten und welche IP-Adresse welche Funktion hat, muss ich mir anderweitig dokumentieren. Hier habe ich mir eine IP-Adresse eingetragen:

Damit habe ich nun aber eine "Allowlist" für meinen Server. Dummerweise ist das nicht zugleich eine "Blocklist" für alle anderen IP-Adressen. Es bedeutet nur, dass meine IP-Adressen "durch" darf, also keinen RBL-Filtern o.ä. unterliegt.

Leider funktioniert diese Funktion also nicht für Blocklisting, da sie hier maximal 1273 einzelne "Class-C Netze (/24) eintragen können und das Internet doch recht groß ist.

Natürlich hat mich nun interessiert, wie schnell solche Änderungen aktiv werden und wann der Client letztlich abgelehnt wird. Exchange Online muss ja zumindest warten, bis es den "RCPT TO" hat, um dann abzulehnen. Auf der anderen Seite gibt es auch Connectoren zum Empfang von Mails, die über IP-Adressen oder Zertifikate qualifiziert werden können. Überstimmen diese eine IP-Blocklist oder IP-Allowlist?. Es wird Zeit für eine Momentaufnahme

  • Allow überstimmt EOP Blocklist
    Mit der expliziten Angabe von IP-Adressen oder IP-Netzwerken werden die Filterlisten von EOP überschrieben, d.h. auch RBL-Listen und andere Quellen, die unseriöse Absender beschreiben, werden damit für diesen Tenant freigegeben.
  • Allow überstimmt Blocklist
    Wenn Sie also die gleiche IP-Adresse im beiden Feldern eintragen, darf die IP senden. das erlaubt aber auch, dass Sie ein Subnetz z.B. blocken und ausgewählte Adressen darauf dennoch erlauben.
  • Mehr als 1273 Einträge sind nicht möglich
    Aber sie können natürlich komplette Netzwerke (Netzwerk/Subnetzmask) verwenden
  • Subnetmark 255.2555.255.0 bis 255.255.255.255
    Sie können IP-Adressen und Subnetze angeben. Allerdings muss sich die Subnet-Mask im Bereich /24 bis /32 bewegen. Ein 0.0.0.0/0 geht also nicht. Größere Bereichen sollen über Transportregeln möglich sein. Allerdings dürfte es so spät schwer werden, Mails dann noch abzulehnen.
  • Enable Safe List
    Damit verhindern sie, dass "gut bekannte gute Sender" blockiert werden. Dies ist aber eine globale Liste, die Microsoft von anderen "Trusted Sources" übernimmt ohne genauerer Informationen dazu bekannte zu geben
  • Transportregeln
    Sie sollten wissen, dass aufwändigere Filterungen, z.B. IP-Adressen mit Domainnamen auch in Transportregeln verwendet werden können. Allerdings ist dann kein Ablehnen mehr möglich, sondern nur ein Löschen, NDR senden oder SCL setzen.
  • Verzögerung bis zu 1h
    Die Einstellungen müssen innerhalb von Office 365 natürlich erst zu allen Eingangsservern repliziert werden. Das kann laut Microsoft bis zu eine Stunde dauern.

Beachten Sie, dass eine Quell-IP nicht immer nur genau eine Domain beschreibt. Hinter einer Source-IP können sich durchaus mehrere Firmen und Absender verbergen.

Aktuell scheint es aber noch keine IPv6-Unteratützung zu geben. Aktuell lösen aber auch die MX-Records nur auf Hostnamen auf, die per IPv4 Erreichbar sind (Stand Feb 2018)

Testserie: IP Filterung

Ich habe eine kleine Testserie gebaut:

  • Zugriff per DSL-IP (Dynamisch)
    Ich habe zuerst von einem PC über einen DSL-Router versucht eine Mail zu senden. Office 365 lehnt nicht sofort ab sondern wartet noch, bis ich den RCPT TO sende. Erst dann kann der SMTP-Service den Zieltenant erkennen und prüfen, ob die IP-Adresse erlaubt ist. Ohne Einstellungen blockt Office 365 natürlich die dynamische IP-Adressen.
  • Freischaltung per Allowlist
    Ich habe dann über das Exchange Online Admin Center die öffentliche IP-Adresse freigeschaltet

    Ich habe dann die TELNET-Tests immer wieder versucht.
  • Verbindung wird angenommen
    In meinem Fall hat es fast die komplette Stunde gedauert, bis ich nun Mails einliefern konnte
  • IP-Allowlist wieder entfernt
    Dann habe ich den Eintrag wieder entfernt, damit ich wieder die gleiche Ausgangssituation habe.

So konnte ich schon mal eine IP-Adresse zulassen, die ansonsten geblockt wird. Office 365 behandelt diesen Absender aber dennoch wie "aus dem Internet"

Testserie: Empfangsconnector

Sie können in Office 365 nun noch einen anderen Weg wählen. Sie legen einen Connector in Exchange an, der eigentlich dafür gedacht ist, Mails von einem Partner oder eben auch von ihrer On-Premises Umgebung zu empfangen. Wenn Sie hier statt "Zertifikat" auch auf die Source-IP-Adresse gehen, dann ist das Ergebnis erst einmal identisch.

Nun gibt es ja noch die Option, dass ich einen Connector erstelle, der Mails annimmt. Um meine Konfiguration nicht zu stören, habe ich dazu eine andere IP-Adresse genutzt, die aber ebenfalls eine dynamische DSL-Adresse war und damit von Office 365 erst einmal abgelehnt wird. Diesmal war sogar "Spamhaus" die RBL-Liste.

Zuerst wollte ich einen Connector vom "Internet" zu "Office 365" erstellen. Office 365 sagt aber, dass man den gar nicht braucht und unterbindet die weitere Konfiguration

Ich habe dann einen Connector gebaut, den auch der Hybrid Wizard einrichtet, damit Mails von meiner vertrauenswürdigen "On-Premises"-Umgebung ohne Filterung angenommen werden:

Hier hat es bei mir ca. 30Min gedauert, bis diese Konfiguration aktiv wurde und dieser Client nun auch seine Mails einliefern konnte.

Das Ergebnis durch einen Connector unterscheidet sich aber schon von einer reinen IP-Allowlist, denn über den Connector wird z.B. auch gesteuert, dass bestimmte System-Header erhalten bleiben.

Versuch mit Transportregel

Daher ist ein Connector der bessere Weg die Zustellung von Partnern und der eigenen Umgebung zu erlauben. Die Pflege der IP-Allowlist ist eine mehr oder weniger schnelle Option bestimmte IP-Adressen aus der Blockierung von Microsoft auszunehmen. Allerdings dauert das schoneinige Zeit, bis es aktiv wird und hat das Risiko, dass sich hinter der gleichen IP-Adresse auch andere Absender verbergen können. Es ist kein Vertrauen auf einen Domänennamen.

Beide Einstellungen lösen aber nicht das Problem, dass ich eigentlich alle anderen IP-Adressen blockieren will. Ich habe das dann über Regeln versucht, die aber auch keine große Netzwerke zulassen:

Lösung Teil1: Inbound Connector mit "*"

Um nun aber wirklich eine Zustellung aus dem Internet durch "Seitenkanäle zu unterbinden gibt es dennoch eine Lösung: Der Trick besteht darin, dass Sie einen "Inbound Connector" anlegen, der für die Domain "*" nur Mails von bestimmten IP-Adressen, d.h. ihrem eigenen Mailserver oder der eigenen Spamfilterlösung erlauben.

Achtung:
Dieser Connector schaltet nicht den Spamfilter von Office 365 (EOP) ab.

Achtung:
Über diese Einstellung können von Extern keine Mails mehr an "<tenantname>.onmicrosoft.com" zugestellt werden. Wer also z.B. von SharePoint oder Teams Channel eine Mail versendet oder empfangen will, kann diesen Weg so nicht gehen

Microsoft hat diesen Weg mittlerweile auch beschrieben
How to block direct delivery to email address with the suffix as domain.onmicrosoft.com or domain.mail.onmicrosoft.com https://blogs.technet.microsoft.com/rrajan/2018/05/08/how-to-block-direct-delivery-to-email-address-with-the-suffix-as-domain-onmicrosoft-com-or-domain-mail-onmicrosoft-com/

Per Powershell sind das folgende Wege:

# Anmeldedaten fuer office 365 Exchange Online abfragen
$UserCredential = Get-Credential

# Remote PowerShell Session instanzieren
$Session = New-PSSession `
   -ConfigurationName Microsoft.Exchange `
   -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
   -Credential $UserCredential `
   -Authentication Basic `
   -AllowRedirection

# CMDLets importieren
Import-PSSession $Session

# Connector anlegen
New-InboundConnector `
   -Enable $True `
   -Name "Inbound only from Antispamrelay" `
   -SenderDomains * `
   -RestrictDomainsToIPAddresses:$true `
   -RequireTls:$true `
   -SenderIPAddresses 80.66.20.12/28

Remove-PSSession $Session

Sie können natürlich auch statt der IP-Adresse auch das Zertifikat des einliefernden Gateways hinterlegen. Die gleiche Konfiguration ist natürlich auch per Browser in ECP möglich:

Wenn ich dann von einem Client eine Mail senden will, der nicht in der IP-Liste erscheint oder das passende Zertifikat vorweisen kann und auch nicht durch eine andere RBL-Liste von Office 365 schon blockiert wird, dann sehe ich folgendes im SMTP-Protokoll:

SMTP error from remote server for RCPT TO command, host: fcarius.mail.protection.outlook.com (216.32.181.106) 
reason: 550 5.7.51 TenantInboundAttribution; There is a partner connector configur ed that matched the message's 
recipient domain. The connector had eith er the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate 
set [DM3NAM05FT043.eop-nam05.prod.protection.outlook.com]

Wenn ich per Mailclient dort etwas hin sende, dann kommt z.B. von 1und1 folgender NDR zurück:

So ist das verständlich.

Tipp: Dieser Connector ist auch mit Hybrid Centralized Mail Transport wichtig, damit Mails aus dem Internet, die über ihre On-Premises-Umgebung kommen ohne weitere Filterung zugestellt werden.

Lösung Teil2: Transport Regel

Die Einrichtung des Partner-Connectors verhindert schon einmal, dass jemand vorbei an meinem per MX-Record veröffentlichten Servern Mails direkt an Office 365 sendet. Eine Teillösung fehlt aber noch. Eingehende Mails, die nun über die On-Premises Plattform mit einer externen SMTP-Domäne und den Partner-Connector zu Office 365 gesendet werden, unterliegen immer noch dem Spamfilter von Office 365.

Aktuell habe ich hier nur den Weg gefunden, eine Transportregel zu bauen, die den Spamfilter basierend auf der Source-IP-Adresse abschaltet. Leider gibt es hier aktuell weder einen Zertifikatsnamen noch den Inbound Connector als Filter.

Im folgenden Dialog lässt sich dann die Source-IP als Kriterium angeben.

Damit kommen nun auch Mails über einen eigenen Spamfilter ohne weitere Filterung in Office 365 Postfächern an.

Ergebnis

Es ist möglich aber Sie müssen dran denken, denn allein die Einrichtung des Exchange Hybrid Mode mit "Hybrid Centralized Mail Transport" stellt ihnen dies nicht ein. Es wäre natürlich schön, wenn auch der Inbound Connector, der beim der Einrichtung von Hybrid Centralized Mail Transport angelegt wird um einen zweiten Connector für "Partner"-Systeme ergänzt wird.

Mit der von Microsoft beschriebenen Lösung gibt es nun aber einen sauber dokumentierten Weg, den Sie bei Bedarf umsetzen können.

Weitere Links