Exchange Online Protection Funktion

Ohne Zugriff auf den Source Code oder entsprechende Dokumentationen ist es schwer, die genauer Funktion von Exchange Online Protection (EOP) zu analysieren und die Funktion zu verstehen. Das ist aber sichtig, denn Sie wollen ja schließlich wissen, wo die IP-Whitelist oder auch Transport-Regeln und "Inbound connectors" ineinander greifen. Schließlich senden und Empfangen alle Mandanten über die gleiche Umgebung.

Ein Service, viele Mandanten

Exchange Online Protection verspricht ein robuster und zuverlässiger Spam- und Malware-Filter zu sein, bei dem Sie als Administrator eigentlich nicht viel einstellen müssen. Schließlich "kaufen" sie ja einen Service und erwarten, dass dieser auch wie versprochen funktioniert. Entsprechend kann Microsoft ja auch Personal und Software einsetzen, um die Filterqualität hoch und die False-Positive-Rate niedrig halten. Das klappt aber nicht immer, denn immer mal wieder werde ich um Hilfe gebeten, wenn Mails nicht zugestellt werden. Dazu ist es erst einmal wichtig, die Funktion genauer zu verstehen. Zuerst geht es um die Mandanten in Office 365 aber auch auf der Gegenseite. Als EOP-Betreiber muss mal mehrere Konstellationen berücksichtigen. Die Gegenseits kann nämlich einfach eine Firma mit eigenem Mailserver und IP-Adresse sein. Es kann aber sich auch um einen Hoster handeln der selbst für mehrere Kunden die Mailkommunikation betreibt. Das kann ein "Hosted Spamfilter" wie z.B. NoSpamProxy aus der Cloud sein oder ein Hoster wie IONOS, Strato, GMX etc. die ebenfalls viele Kunden hinter den gleichen Servern verstecken.

Auf jeder Seite gibt es nicht nur "gute Mitbürger" sondern auch Spammer. Das kann ein einzelner Host sein, der über Blacklists sehr schnell ausgegrenzt werden kann. Das funktioniert aber nicht für bösartige Kunden oder einzelne gekaperte Konten bei eine Mandanten. Das Problem ist als nicht nur für Exchange Online Protection akut, sondern auch für alle Hosting-Firmen, die Mails für ihre Kunden senden und empfangen. Sie haben nicht nur ein Interesse daran, dass ihre Mails versendet werden, d.h. sie selbst nicht auf Blacklisten landen sondern auch dass sie nicht irrtümlich zu viele Mails blockieren, weil sie eine Blackliste nutzen.

Ablehnen oder Quarantäne

Als wir bei Net at Work vor über 10 Jahren NoSpamProxy entworfen haben, haben wir uns gegen eine Quarantäne entschieden. Warum sollte ich als Betreiber eine Mail in eine Quarantäne beim Benutzer oder sogar serverseitig ablegen und damit die Verantwortung verlagern? Der Absender kann nämlich nachweisen, dass die Mail zugestellt wurde und der Empfänger droht mir Konsequenzen an, weil ich die Nachricht unterdrückt habe. Eine "Unzustellbarkeit" an den Absender zu generieren verbietet sich, da Spammer mit gefälschten Adressen arbeiten und ich damit selbst zum Störer werden. Wir haben bei NoSpamProxy daher jede Mail entweder angenommen und dann auch ins das Postfach zugestellt oder auf SMTP-Level abgelehnt. Andere Produkte haben jede Mail angenommen und dann asynchron versucht die guten Mails und von schlechten Nachrichten zu trennen.

Nun können Sie in Exchange Online, und damit auch in Exchange Online Protection verschiedene Dinge einstellen, die das System deutlich komplexer werden lassen. Es gibt da drei Dinge:

  • Trusted IP / Blocked IP
    Sie können in ihrem Tenant IP-Adressen pflegen, die von Exchange Online als vertrauenswürdig oder schädlich angesehen werden sollen. Viele Firmen tragen hier z.B.: ihre öffentliche statische IP-Adresse der OnPremises-Umgebung ein oder die festen IP-Adressen von Webservern bei verschiedenen Cloud-Diensten, die dann über Exchange Online ihre Mails zustellen und verteilen können. Aber sie können hier schon sehen, dass diese Einstellung nur pro Mandant gelten darf. Schließlich möchte ich als Office 365 Kunde nicht ihrem Firmenserver vertrauen, nur weil sie bei Office 365 ihre Adressen in die Whitelist eingetragen haben. Hier muss Office 365 also unterscheiden können.
  • Inbound Connectoren
    Sie können weiterhin "eingehende Connectoren" einrichten, die z.B. anhand der Absender Domain, Zertifikaten oder IP-Adressen angewendet werden. Das ist aus meiner Sicht sogar flexibler als die Whitelist/Blacklit auf IP-Ebene. Aber auch hier ist klar dass das nur pro Office 365 Tenant gelten darf. Wäre doch tödlich, wenn ein Tenant-Admin z.B. alle Mails von GMX als Partner-Connector einträgt und die anderen Tenants das auch nutzen würden.
  • Transport Regeln
    In den Exchange Transport Regeln gibt es einen Eintrag "Bypass Spam Filtering", auf den ich aber weiter unten erst eingehe

Sie haben zumindest bei den ersten beiden Punkten gesehen, dass der Tenant eine wichtige Komponente ist und an welchen Tenant die Mail geht, kann Exchange Online nur an den Domänen der "RCPT TO"-Zeilen im Header anschauen. Ein direktes Ablehnen einer Verbindung anhand einer IP-Adresse in einer Blocklist wäre aber auch kontraproduktiv, weil dann individuelle Vertrauenslevel pro Tenant nicht mehr greifen können.

SMTP-Ablauf

Es wird also Zeit sich den Weg einer Mail per SMTP noch mal genauer anzuschauen und was Exchange Online Protection daraus lernen kann:

Status Information Beschreibung

CONNECT

IP-Addresse

Sobald sich ein SMTP-Client mit Office 365 verbindet, kenn Exchange Online die IP-Adresse. Ein dummes System würde nun direkt die IP-Adresse gegen Blacklisten prüfen. ich bin sicher, dass Microsoft interne Listen hat, die ganz schlechte Adressen unterbinden. So könnte man ja die Anzahl der Verbindungen, die Datenmenge etc. nutzen, um DoS-Attacken zu unterbinden. Aber eine Verbindung allein anhand der IP-Adresse darf nicht abgelehnt, werden, da es ja ein legitimer Client sein könnte, der sich noch anmeldet.

EHLO/HELO

 

Die meisten SMTP-Clients senden EHLO, so dass Exchange Online in der Antwort auch die Anmeldeverfahren und STARTTLS offeriert.

STARTTLS

Zertifikat

Optional nutzt der SMTP-Client das Angebot auf eine TLS-Verbindung zu wechseln. So kann der Client nicht nur das Zertifikat des SMTP-Servers überprüfen sondern auch seinerseits sein Zertifikat übertragen. Das ist Voraussetzung, wenn später irgendwann ein "Inbound Connector" auf Basis eines Zertifikatnamens gewinnen soll.

Verschlüsselte Verbindungen sind auch für Clients erforderlich, die sich noch mit schwachen Anmeldeverfahren anmelden.

MAIL FROM

Sender-Domain

Aus der Absenderzeile kann Exchange Online die Domain ermitteln, die der Absender vorgibt zu sein. Das muss nicht stimmen aber die Information kann per SPF, DKIM, DMARC weiter evaluiert werden. Zudem erlaubt es Spoofing zu unterbinden, denn eine Mail einer Kundendomain sollte ohne Anmeldung nicht angenommen werden.

Die MailFrom-Adresse kann schon ein erster Indikator für den Tenant sein, denn Sie können auch von OnPremises über Exchange Online ihre Mails an externe Empfänger senden. EOP muss also noch weiter schauen, was an zusätzlichen Informationen ankommt.

RCPT TO

ZielDomain

Erst aus dieser Zeile kann EOP genau erkennen, zu welchem Tenant die Mail gesendet wird. Vorher kann die Mail noch an beliebige Tenants gehen.

Interessanter Fakt: Wenn Sie nach der ersten RCPP-TO-Adresse einen zweiten Empfänger in eine, anderen Tenant angeben, bekommen Sie eine Fehlermeldung.

RCPT TO:user1@fcarius.onmicrosoft.com
250 2.1.5 Recipient OK
RCPT TO:user1@msxfaq.onmicrosoft.com
452 4.5.3 Recipients belong to multiple tenants [DM3NAM05FT061.eop-nam05.prod.protection.outlook.com]

Die RCPT-TO-Adresse kann aber durchaus wieder extern sein, wenn Sie authentifiziert als Absender ihres Tenants senden.

DATA

Header+ Mail

Nach dem DATA kann der Absender nun seine gesamte Mail mit dem SMTP-Header senden. Sobald der Versand gestartet hat, kann der Empfänger die Mail nur noch durch einen Verbindungsabbruch unterbrechen. Wenn der Sender am Ende sein ".<enter>" sendet, dann kann der Empfänger die Mail aber immer noch mit einer Fehlermeldung ablehnen.

QUIT

Verbindungsabbau

Wenn die Mails übertrage wurde, kann der Sender die Verbindung sauer schließen.

Exchange Online Protection muss also einige Dinge mehr auswerten, ehe er genau erkennen, kann, welcher Fall zutreffend ist und welche Filter und Entscheidungsregeln zum Tragen kommen. Eine umfangreiche Seite gibt es dazu auf Office 365 Inbound Mailrouting.

Hoster zu Hoster

Interessant wird es nun, wenn ein Hoster für mehrere Kunden seine Mails an Office 365-Mandanten senden soll. Jeder Office 365 Mandant hat einen eigenen MX-Record, der auf einen eigenen Namen verweist.

carius.onmicrosoft.com  MX preference = 0, mail exchanger = carius.mail.protection.outlook.com
msxfaq.onmicrosoft.com  MX preference = 0, mail exchanger = msxfaq.mail.protection.outlook.com

Das macht Microsoft aber schon dafür, dass der Absender die beiden Zieldomains, die beide auf EOP verweisen nicht als Bündel zu einen Mailserver zusammenfasst. Es darf nicht passieren, dass eine Mail an zwei Empfänger in unterschiedlichen Tenants als "eine Mail mit zwei RCPT-TO-Zeilen" losgesendet wird. Es müssen zwei getrennte Mails sein, auch wenn das mehr Bandbreite im Internet und mehr Verbindungen kostet.

Dennoch kann es passieren, dass die ausgehenden Mailserver des Hosters nun mal gerade auf einer Blackliste liegen. Hier haben Sie dann drei Optionen:

  • Support-Ticket beim Absender
    Sie mögen bitte dafür sorgen, dass ihre Hosts nicht auf einer Blackliste landen oder die Mails über einen anderen Host verwendet werden, die noch nicht gelistet sind. Das ist aber nicht einfach, denn ausgereifte Spamfilter lernen auch Mailvolumen von Systemen und wenn da ein "Cold standby"-Host plötzlich loslegt, dann ist das verdächtig. Ein Host im gleichen Subnetz bekommt aber oft auch die gleichen Strafen wir der Schadserver.
    Letztlich haben seriöse Provider also schon ein Interesse nicht auf Blacklists zu landen. Ein ausgehender Spamfilter, eine professionelle Kundenqualifizierung und schnelle Reaktion bei missbrauchten Konten sind hier wichtig.
    Ein Support-Ticket ist also eher ein Hinweis an den Sender, denn machen kann er auf die Schnelle nichts.
  • Support-Ticket bei EOP
    Natürlich können Sie auch Microsoft fragen, ob Sie die Mails blocken und wie sie dies "lösen" können. Aber kein Mailprovider liefert ausführliche Informationen über die genutzten Blacklists und andere Filter-Methoden um den Spammern das Leben nicht zu erleichtern. Die globale EOP-Konfiguration wird vermutlich auch nicht hier angepasst.
  • Blackist - Betreiber
    Ein Mailserver kommt in der Regel nicht unverschuldet auf eine Blackliste. Viele Listen sind privater Natur und automatisiert. Einige Listen sind sogar sehr streng und bauen Honepots, um Spammer zu sammeln und die Quell-Mailserver auf die Liste zu setzen. Das tut natürlich weh, wenn ein böser Spammer eine Mail an so eine Bot-Adresse sendet und damit den Mailserver eines Providers lahm legt. Auch hier ist ein ausgehender Spamfilter besonders wichtig.
    Es gibt Listen, bei denen Sie sich austragen können. Einige verlangen für diesen Service auch "Geld" oder sie warten, bis die Liste den Eintrag wieder alleine löscht. Sie müssen ja als Versender nur die Ursache beheben.

Sie kommen mit keiner der drei Ansprechstellen auf die Schnelle weiter. Daher können Sie sich hier eine Aktion auch sparen und das Problem aussitzen. Bei jeder Spamfilter kann es eben diese Sonderfälle geben. Wenn Sie mit ihrem Auto liegen bleiben, dann dauert es auch einige Zeit bis das Pannenfahrzeug sie zur Werkstatt geschleppt hat und das Auto wieder funktionsfähig ist.

Das Risiko eines Hosters, dass seine IP-Adressen ein schlechtes Rating bekommen, ist durchaus real. Daher blockiert z.B. Azure per Default ausgehende Verbindungen auf Port 25/TCP. Man will einfach nicht riskieren, dass jemand mit geklauten Zugangsdaten einen Service in Azure als Relay oder Spam-Versender betreibt und damit das gesamte Netzwerk in Misskredit bringt. Amazon AWS hingegen erlaubt SMTP ausgehend aber wenn Blacklists dann komplette Subnetze herabstufen, dann kann das durchaus ihren legitimen Service stören. Sie wissen ja nicht, wer neben ihnen noch auf VMs tut. Auch Spammer haben die Leistung von Cloud-Diensten schon lange erkannt und nutzen diese. Mit geklauten Kreditkarten oder "Trial"-Versionen ist das schnell installiert.

IP-Black/Whitelist und Inbound Connector

Hinsichtlich dem Empfang können Sie aber doch etwas tun, denn Microsoft nutzt sicher auch Blacklisten aber eben nicht als absolutes Entscheidungskriterium sondern nur als ein Aspekt bei der Bewertung einer Mail. Wie Sie oben an den SMTP-Phasen gesehen haben, scheint Microsoft zumindest bis zum "DATA" die Data die Verbindung zu erhalten und möglichst viel über den Absender zu erfahren. Exchange kennt bis dahin nämlich

  • Source-IP Adresse
  • TLS Zertifikatname (optional)
  • Angebliche AbsenderDomain
  • Gewünschte Zieladresse (ihre Tenant)

Bis dahin zählt die Mail zwar noch nicht als "angenommen" aber Exchange Online Protection kann den Tenant bestimmen und dann kommen schon die beiden möglichen Einstellungen zum Tragen:

  • IP Whitelist/Blacklist
    Sie können für ihren eigenen Tenant bestimmte Adressen zulassen. Das ist natürlich keine gute Idee, wenn die IP-Adresse von einem Hoster kommt und viele Absender sich dahinter verstecken. Es kann aber für ein paar Stunden helfen, eine wichtige Mail von einem Kunden zuzulassen
  • Inbound Connector
    Besser finde ich aber den Weg, einen Inbound Connector für explizit die Remote Domain anzulegen, um Mails von diesem Absender anders zu behandeln

Die sind es aber nicht alleine, denn es gibt ja noch die "Inbound Connectoren", die sie in Exchange Online konfigurieren können. Sie können hier ja verschiedene eingehende Connectoren anlegen wie:

  • Von dem eigenem Unternehmensserver -> Office 365
  • Von Partnern zu Office 365

Beide Connectoren können die Gegenseite entweder über den Namen im TLS-Zertifikat oder auch über eine Remote-IP-Adresse identifizieren und zudem optional die Absenderdomain vorgeben

In dem Fall, dass ein Connector auf die übermittelten Werte zutrifft, werden IP-Blacklisten überstimmt.

Wenn Sie aber einfach nur ein anonymer Absender sind und Office 365 ihre Einlieferung unterbindet, dann können Sie nicht viel tun außer einen anderen Mailserver mit einer nicht geblockten IP-Adresse zu verwenden.

Angenommen und Quarantäne

Wenn die Mail dann diese erste Schwelle überschritten hat, dann wird sie von Exchange Online Protection meines Wissens nicht mehr abgelehnt. Sie wird angenommen und durchläuft dann weitere Stationen

  • Erweiterte Spamfilterung
    Nach dem Empfang hat Microsoft nun auch den kompletten Inhalt der Mail, d.h. Body und Anlagen. Ein Spamfilter über den Body hilft, weitere Spam-Mails zu erkennen und zu behandeln. Sie bekommen einen Spam Confidence Level - SCL, der später noch relevant wird
  • Malware-Filterung
    Spam ist störend aber Viren sind gefährlich und daher wird ein Virenscanner über die Mail geschickt, der bösartige Dateien erkennt

Beide Filter arbeiten aber auf einer bereits empfangenen Mail. Der Absender konnte seine Mail also erfolgreich an Exchange Online Protection übertragen. Es wäre gefährlich, wenn so eine Mail nun einfach gelöscht wird. Für Viren ist das noch möglich, da hier "erkannte Viren" quasi immer unerwünscht sind und es kaum False Positive gibt. Alle anderen Mails landen aber in der Quarantäne. Je nach Einstellung landen die Mails in einer Server-Quarantäne oder im "Junk-E-Mail"-Ordner des Anwenders. Das "Verschieben" der Mail in diesen Ordner wird wieder über den Spam Confidence Level - SCL gesteuert.

Und hier kann eine Transportregel von ihnen als Administrator konfiguriert werden, die diesen SCL-Wert nachträglich anpasst.

Sie verändert damit die Bewertung, die EOP schon vergeben hat anhand der hier konfigurierten Bedingungen. Allerdings betrifft dies eben nur die Nachrichten, die nicht weiter vorne schon abgelehnt oder durch den Virenscanner entfernt wurden.

Quellensuche

Je nach dem, an welcher Stelle die Übertragung der Mail unterbunden wurde, müssen die Sender oder der Administrator am Ziel oder der Benutzer nachschauen.

  • Absender mit NDR
    Wenn die Mail von Exchange Online Protection schon auf dem Weg zum Exchange blockiert wird, dann bekommt der einliefernde SMTP-Service eine SMTP-Fehlermeldung, aus der diese, sofern er richtig konfiguriert ist, eine Unzustellbarkeit erstellt. Hier ein Beispiel einer von Office 365 formatierten Mail, wenn ich einen falschen DMARC-Eintrag habe
  • Empfänger
    Wenn die Mail soweit von Office 365 angenommen wurde, dann könnte der Anwender selbst einfach in seinem "Junk-E-Mail"-Ordner nachschauen, ob die Mail anhand des SCL dort abgelegt wurde.
  • Administrator des Zielsystems
    Wenn die MAil auch dort nicht ist  aber von Exchange Online angenommen wurde, dann muss diese Mail ja im Message-Tracking im Zielsystem erscheinen. Hier kann dies aber ein Exchange Administrator nachschauen und auch noch mal schnell in der zentralen Quarantäne

Mit etwas Glück haben Sie die Mail dann gefunden oder wie erkennen den Grund für die Ablehnung. Erst dann könnten Sie überlegen, über welchen Weg sie die Blockade lösen.

Weitere Links