Hybrid Hintereingang

Die Einrichtung des Exchange Hybrid Mode mit dem HCW ist sehr einfach, wenn die Voraussetzungen erfolgreich umgesetzt sind. Eine Voraussetzung für "Mailrouting" ist, dass die On-Prem-Exchange Umgebung von der Cloud erreichbar ist. Damit Sie hier keine Hintertür offen stehen lassen, sollten Sie diese Seite lesen.

Auf der Seite Hybrid Mail Routing habe ich umfangreich beschrieben, wie Exchange On-Prem und Exchange Online über Connectoren verbunden werden, damit im Hybrid-Betrieb die Mails zwischen den beiden Instanzen sicher (TLS-Verschlüsselt) übertragen werden.

Knapp 2 Jahre nach dieser Seite hat sich Microsoft dem Thema in einem Blog-Beitrag auf https://techcommunity.microsoft.com/t5/exchange-team-blog/advanced-office-365-routing-locking-down-exchange-On-Premises/ba-p/609238 angenommen.
Der Schutz ist weder nicht in der regulären Dokumentation beschrieben noch durch eine HCW-Konfiguration umgesetzt.

Wer sich die Konfiguration aber genau anschaut, erkennt vielleicht eine Lücke, die eine Hybrid Konfiguration öffnet.

Establishing Exchange Hybrid Mailflow
https://www.youtube.com/watch?v=1i_SO6nKe0o&t=605s
Sehr gute Beschreibung zum Mailrouting in einer Hybrid Umgebung

On-Prem zu Office 365 - Gesichert!

Damit ein Mailfluss möglich ist, muss ihr Exchange On-Prem-System eine TLS-Verbindung zu Office 365 aufmachen und sich dabei mit einem Zertifikat oder einer bestimmten Source-IP-Adresse ausweisen, damit ihr Office 365 Tenant die Mails als "von ihrem On-Prem-System akzeptiert. Das macht der HCW bzw. bei der manuelle Konfiguration ist es auch möglich und sieht in der Cloud dann wie folgt aus:

On-Prem gibt es natürlich den passenden SEND-Connector, der keine Sicherheitslücken aufreisst.

Office 365 zu On-Prem - Unsicher

Interessanter ist aber die Gegenrichtung. In der Cloud gibt es einen "Outbound Connector", der Mails von  Office 365 zu ihrer On-Prem-Umgebung routet. Hier mein Test und Spiel-Tenant.

Was sie hier aber auch sehen sollten ist, dass in Exchange Online ein SMTP-Server angegeben werden muss. Dass kann ihr ganz normaler "Eingangsserver" für Mails aus dem Internet sein oder ein eigenständiger Hostname, der nur für Office 365 genutzt wird. Dort muss auf Port 25 ein für Exchange Online erreichbarer Exchange Server oder Exchange Edge-Server lauschen. Ein anderes System ist nicht supported:

„Es dürfen keine weiteren SMTP-Hosts oder Dienste zwischen dem lokalen Exchange 2013-Clientzugriffsserver oder einem Exchange 2013/2010 SP3-Edge-Transport-Server und EOP vorhanden sein. Nachrichten hinzugefügte Informationen, die Hybridtransportfunktionen aktivieren, werden entfernt, wenn die Nachrichten einen Nicht-Exchange 2013-Server, einen Server vor Exchange 2010 SP3 oder einen SMTP-Host durchlaufen.“
Quelle: https://technet.microsoft.com/de-de/library/jj659055(v=exchg.150).aspx

Das bringt uns nun in ein Dilemma:

  1. Sie nutzen einen Exchange Edge
    Ich persönlich kenne nur wenige Firmen, die sich auf den Exchange Edge Server als Virenschutz und Spamfilter verlassen. Quasi alle Firmen nutzen eine AntiSpam Appliance wie z.B. NoSpamProxy o.a. oder einen Cloud Provider als vorgelagerten Spamfilter. Nur wenn Sie heute schon den Edge Server-Server als Ziel für ihren MX-Record nutzen, verschlechtern sie sich nicht.
  2. Sie veröffentlichen den Exchange SMTP-Frontend
    Wer keinen Edge hat, muss dann ja einen Exchange SMTP Frontend über Port 25 aus dem Internet erreichbar machen. Der Server habe aber erst mal überhaupt keinen ausreichenden Spamfilter oder Virenschutz und kann nicht einmal ungültige Empfänger aktiv ablehnen. Viele gewünschte Zusatzfunktionen (Große Anlagen, Verschlüsseln, Signieren, Disclaimer etc.) fehlen komplett. Daher nutzen diese Firmen andere Systeme als für den SMTP-Empfang auf die dann der MX-Record verweist. In dem Fall muss der Exchange Server mit einem eigenen DNS-Namen für Office 365 erreichbar sein.

Nun ist es aber so, dass selbst wenn der Namen ihres "Hybrid Connector Servers" geheim sein sollte, dieser offene Port 25 sehr bald "gefunden" wird. Hier kommt dann eine zweite Konstellation zum Tragen, die mit dem Hybrid Configuration Wizard (HCW), Der Exchange On-Prem Version und dem Receive Connector zu tun hat.

Konstellation Receive Connector Anonym Mail anehmen Bewertung Status

Exchange 2010 und HCW

Eigener Receive Connector für den Empfang von Office 365 mit den IP-Adressen von Office 365 als RemoteIP

Nicht aktiv

Der eigens angelegte Connector mit den IP-Adressen von Office 365 greift nur, wenn ein Office 365 Server eine Verbindung zu diesem Exchange Server aufbaut. Alle anderen "Quereinsteiger" werden auf IP-Level schon geblockt

OK

Exchange 2013 und HCW

Default Receive Connector mit TLS-Einstellung

Nicht aktiv

Die Pflege eines eigenen Receive Connectors mit IP-Adressen ist wohl zu aufwändig und wenig flexibel. Exchange Online nutzt ja immer mal wieder neue Adressen. Daher richtet der HCW mittlerweile keinen eigenen Connector mehr ein und setzt stattdessen die TlsDomain, damit Mails vom Host "mail.protection.outlook.com" besser behandelt werden. Zum Glück ist bei Exchange 2013 der Empfang von anonymen Absendern per Default nicht erlaubt. Leider wird aber genau dies von einem Administrator als erstes wieder freigeschaltet. Schließlich will er ja Mails von internen Systemen oder dem vorgelagerten Spamfilter annehmen. Solange der Exchange Server nicht aus dem Internet erreichbar ist, ist das auch tolerierbar. Aber nun wird er ja unter einem eigenen Namen erreichbar. Die Konfiguration kann also gefährlich werden.

FAIL

Exchange 2016 und HCW

Default Receive Connector mit TLS-Einstellung

Erlaubt

Seit Exchange 2016 hingegen ist per Default schon "Anonym annehmen" gesetzt. Wird der Server nun im Rahmen der Hybrid-Bereitstellung aus dem Internet erreichbar, hat man eine perfekte Hintertür zum Versand von Mails an diese Firma mit Umgehung der über den MX-Record vorgeschalteten Relay-Systeme.

FAIL

For Exchange 2010, the HCW creates an On-Premisess send connector called “Outbound to Office 365” and an On-Premisess receive connector called “Inbound from Office 365”
the receive connector has a list of the Exchange Online Protection (EOP) IP addresses
Exchange 2013, the HCW creates an On-Premisess send connector called “Outbound to Office 365” but does not create a new receive connector. In this case, the “Default Frontend” receive connector is modified for hybrid mail flow and instead of using a list of IPs, a certificate is used to force hybrid mail flow
Quelle: Office 365 – Common Exchange Online Hybrid Mail Flow Issues
https://blogs.perficient.com/microsoft/2015/02/office-365-common-exchange-online-hybrid-mail-flow-issues/

Wir müssen uns also etwas überlegen, wie wir die Veröffentlichung der Exchange Server besser absichern.

Testen sie ihren Hybrid Server

Vielleicht sind sie ja gar nicht "verletzbar". Einen ersten Test können Sie recht einfach machen, indem Sie sich von ihrem PC zuhause mit ihrem Exchange Hybrid Server verbinden und eine Mail einliefern. Das geht per Powershell ganz einfach:

$hybridservername = "hybridserver.msxfaq.net"    # DNS Name des Hybrid Servers
$recipient        = "User1@msxfaq.net"           # Ihre Mailadresse des On-Prem Postfach
$sender           = "spammer@example.com"        # Ein beliebiger Absender

send-mailmessage `
   -SMTPServer $hybridservername `
   -to $recipient `
   -from $sender `
   -Subject "Testmessage"

Wenn ihre Firewall nicht verhindert, dass ich die Meldung versenden und ihr Receive Connector auch eine anonyme Annahme erlaubt, dann sollten Sie eine Mail in ihrem Posteingang finden. Den gleichen Weg können also auch Spammer oder gezielte Angreifer nehmen. Sie haben also eine Hintertür. Wenn dies nicht gelingt, dann scheint "etwas" zumindest den Zugang von "nicht Office 365 Adressen" zu blockieren. Oder sie haben den Exchange 2016 Receive Connector so umgestellt, dass er keine anonymen Verbindungen annimmt. Das dürfte dann aber auch das Hybrid Routing stören.

Wenn Sie zudem noch ihren Default Frontend Receive Connector als "Anonymes Relay" konfiguriert haben, z.B. weil damit interne Systeme über Exchange ins Internet senden dürfen, dann sind Sie durch die unvollständige Einrichtung des HCW in offenes Relay

Zusatzabsicherung On-Premises Receive Connector

Sie haben nun sicher gesehen, dass der "Eingang" des On-Prem-Server mehr oder minder ungeschützt im Internet hängt und über Port 25 von der Cloud erreichbar ist. Es würde so nicht lange dauern, bis jemand per Port-Scan diesen "offenen" Mailserver findet. er ist Default zwar kein "offenes Relay" aber doch ein Hintereingang zu ihrem Exchange Server, der an ihrer mühsam aufgebauten AntiSpam-Filter-Lösung vorbei kommt. Das wollen wir so natürlich nicht lassen. Es bieten sind mehrere Optionen an:

  • Exchange Edge Server
    Laut Microsoft ist ein Edge-Server das einzige zugelassene Relay-System zwischen On-Prem und Cloud beim Hybrid-Routing. Ob der wirklich so viel dann bringt, lass ich mal dahin gestellt sein. Aus meiner Sicht gibt es bessere Optionen für Antivirus, AntiSpam und Verschlüsselung. Aber ein Edge Server würde dennoch nicht verhindern, dass fremde Mailserver über den Weg versuchen eine Mail zuzustellen. Und es würde ihnen auch ohne weiteren Schutz gelingen, denn auch ein Exchange Edge Server beschränkt sich nicht auf Office 365 Server.
  • Schutz durch Firewall
    Wenn Sie den Exchange Receive Connector mit einem eigenen Namen per Reverse NAT über eine Firewall veröffentlichen, dann ist es natürlich möglich, auf der Firewall eine Beschränkung auf "Source-IP" zu hinterlegen. Viele Firewall-Produkte bringen schon die Office365 IP-Adressen mit oder erlauben eine Pflege. Damit kann schon einmal kein anderes Internet-System eine Verbindung zu ihnen aufbauen. Allerdings immer noch jeder Office 365-Tenatn, in dem ein bösartiger Administrator einen SendConnector auf ihren Hybrid-Server einrichtet.
  • Receive Connector mit Remote-IP-Range
    Sie können den "Default Frontend Receive Connector" natürlich auch über die eingebaute Liste der "Remote-IP-Range" besser zustopfen. Per Default sind hier alle IP-Adressen erlaubt. Hier könnten wir alle Office 365 Datacenter-Adressen addieren. Wir sollten zusätzlich aber auch die intern genutzten Adressen addieren, damit der Exchange Server sowohl von anderen Exchange On-Prem Servern als auch internen Clients erreichbar ist. Damit wird der Filter von der Firewall auf ihren Server verlagert.

Die Filterung eingehender Verbindungen auf den Receive Connector auf die Exchange Online Server ist der Mindestschutz, den Sie ihrer On-Prem Exchange Umgebung zugute kommen lassen sollten. Denken Sie dann aber darauf, dass sie weitere Connectoren brauchen, um z.B. Mails von intern oder ihrem normalen Relay anzunehmen.

Der Schutz auf der Firewall ist effektiver, da Angreifer gar nicht bis zu Exchange vordringen. Aber die Pflege kann hier natürlich aufwändiger sein.

Wenn Sie die Filterung nicht direkt auf der Firewall vornehmen wollen und der Exchange Server dank "Reverse-NAT" ohne Source-NAT auch die reale Client-IP zu sehen bekommt, dann können Sie auf verschiedene Wege den Zugang beschränken

  • Default Connector beschränken
    Sie können dazu entweder den bestehenden Receive Connector so anpassen, dass er nicht mehr "Any Source" annimmt, sondern z.B. nur Office 365 DataCenter-IP-Adressen und natürlich die internen Adressen, z.B. 10.0.0.0/18, 172.16.0.0/20, 192.168.0.0/16.
  • Eigener Office 365 Receive Connector auf Port 25
    Sie können aber auch die Konfiguration nachbauen, die der HCW damals mit Exchange 2010 eingerichtet hat. Ein eigene Receive Connector nimmt nur die Mails von Office 365 Servern entgegen und erzwingt TLS. Das bedeutet aber, dass sie immer noch auf der Firewall filtern müssen, da andere Systeme aus dem Internet über die gleiche Serververöffentlichung weiterhin beim Exchange Server landen und dann wieder die Konfiguration eines anderen Receive Connectors angewendet wird. Wenn der natürlich keine anonymen Absender zulässt, dann passiert auch nichts. Bis Exchange 2013 war das sogar der Default.
  • Eigener Office 365 Receive Connector auf anderem Port
    Um das Risiko zu minimieren, dass ein veröffentlichter Port 25 aus dem Internet einen falschen Connector erreicht, könnten Sie den Receive Connector für Hybrid einfach auf einem anderen TCP-Port laufen lassen und in der Firewall beim NAT auch den Ziel-Port umleiten. Extern ist dann weiter der Port 25 ansprechbar aber intern landet der Zugriff dann immer auf genau dem einen Connector, der dann die Source-IP auch filtern kann.

Wer auch immer einen Exchange Server über Port 25 aus dem Internet irgendwie erreichbar macht, sollte regelmäßig prüfen, ob die gewünschte Absicherung immer noch aktiv ist und kein Setup einer 3rd Party Software, eines Administrators o.ä. auch hier eine Hintertür geöffnet hat

Generell sollten Sie natürlich nicht alle IP-Adressen von Office 365 erlauben, da Sie sonst auch noch für Azure-VMs erreichbar wären. Eine Beschränkung auf die Exchange DataCenter-IPs ist hier der richtige Weg. Diese erhalten Sie als gefilterte Liste (Siehe Office 365 Netzwerkziele). Diese können Sie aber über eine Exchange Online Powershell abrufen.

$FormatEnumerationLimit =-1
$ip = Get-HybridMailflowDatacenterIPs
Get-ReceiveConnector "Inbound From Office 365" | Set-ReceiveConnector -RemoteIPRanges $ip.DatacenterIP

Leider konnte ich noch nicht ermitteln, ob diese Adressen auch für die CAS zu CAS-Kopplung per EWS gültig sind. Dann wäre diese Address-Range auch für die EWS-Veröffentlichung und Exchange MRS Migration nützlich.

Restrisiko - andere Tenants

Nun haben wir alles abgesichert, so dass dieser Connector nur noch von Office 365 erreichbar ist. Alle anderen Mailserver und Spammer aus dem Internet können also unseren "Hybrid-Server" nicht mehr erreichen. Dann bleibt aber immer noch eine kleine Lücke. Hinter dem Host "mail.protection.outlook.com" verbirgt sich ja nicht nur unser eigener Tenant. Alle anderen Office 365 Tenants nutzen den gleichen "ausgehenden Host". Als "Bad Guy" könnte ich daher folgendes machen:

Dies soll nicht als Anleitung zum Missbrauch von Office 365 Diensten verstanden werden, sondern dient nur der Erläuterung der verbliebenen Lücke um dann die Gegenmaßnahmen zu beschreiben.

  1. Ich ermittle den Hostnamen ihres Hybrid Servers
    Das ist nicht so schwer. Es reicht mir oft schon eine passende Mail von ihrem System, in der im im Header die Stationen sehe oder eine Suche im Umfeld ihres "Autodiscover"-Hosts. Mit der Funktion Hybrid Centralized Mail Transport kann ich den Weg meist schon erkennen. Ansonsten suche ich einfach ein ihnen zugeordnetes Subnetz und probe die Adressen durch.
  2. Ich hole mir einen Office 365 Tenant
    Das soll immer noch recht einfach gehen, z.B. als Demo-Tenant unter https://demos.microsoft.com oder eben mit einer geklauten Kreditkarte o.ä.
  3. Ich richte ein Postfach und einen "Send-Connector" ein
    zuerst brauche ich ein Postfach. Dazu reicht mir schon ein "admin@%tenantname%.onmicrosoft.com", welches durch Zuweisung einer E1,E3,E5 Eval-Lizenz schon angelegt wird. Dann konfigurieren ich einen "Outbound Connector", der alle Mails an ihre Domäne auf ihren Hybrid Server zustellt.

Wenn Sie nun rekapitulieren, wie Exchange Online und Exchange On-Prem arbeiten, dann werden Sie erkennen, wie einfach ich nun eine Mail an ihrer Verteidigungskette vorbei an ihre OnPrem-Umgebung senden kann. Alle Filter auf Basis der Source-IP oder TLS-Zertifikat des Absenders sind wirkungslos und wenn sie ihre lokale Exchange Umgebung "hinter" EOP verstecken und daher lokal nur wenig Schutzfunktionen eingebaut haben, dann sind sie schlecht geschützt.

Natürlich hat Exchange Online Spamfilter und Virenfilter. Auch das "Throttling" von Microsoft wird es mir nicht erlauben, ihren Mailserver mit massenhaft Mails zu überlasten. Aber darum geht es ja gar nicht. Wenn ich mir die Mühe mache, so viele Details zu ihrer Umgebung zu ermitteln und die Einstellungen vorzunehmen, dann bin ich eher vom Typ "Enkeltrick für Geschäftsführer (Fake President, CEO Fraud)", der mit wenigen gezielten Mails daraus einen Vorteil schlagen will.

Ich habe länger überlegt, wie hoch die Wahrscheinlichkeit für so eine Attacke ist und es gibt tatsächlich Gegenmaßnahmen:

  • SMTP-Header "X-OriginatorOrg"
    Exchange Online addiert einige SMTP-Header, die beim Empfang über den Hybrid Mode auch beibehalten werden. Einer der Header enthält z.B.: die Tenant-GUID und der kann vom Absender nicht gefälscht werden. Entsprechend kann der Exchange Administrator der On-Prem-Umgebung eine Transport-Regel erstellen, die Mails von der Cloud ohne diesen Header als "schlecht" erkennt oder mit einem Spam Confidence Level - SCL kennzeichnet.
  • Blockieren von "onmicrosoft.com"
    Eine weitere Option wäre es die Absenderdomäne "onmicrosoft.com" einfach komplett zu filtern. Wobei ich nicht ausschließen kann, dass gewisse Systemdienste und Applikationen (OneDrive, Microsoft Teams, u.a.) nicht doch mal mit diesen Adressen arbeiten.

Knapp 2 Jahre nach dieser Seite hat sich Microsoft dem Thema in einem Blog-Beitrag auf https://techcommunity.microsoft.com/t5/exchange-team-blog/advanced-office-365-routing-locking-down-exchange-On-Premises/ba-p/609238 angenommen. Der Schutz ist weder nicht in der regulären Dokumentation beschrieben noch durch eine HCW-Konfiguration umgesetzt.

Microsoft beschreibt dort, wie der Administrator im lokalen Exchange Server eine Transport-Regel einsetzen kann, die alle Mails von Externen, anonymen, Absendern zu einem Postfach umleitet, es sei denn der Header "X-OriginatorOrg" kennzeichnet die Mail als vom eigenen Tenant kommend oder sie kommt im Beispiel von einem internen Server.

Wobei die Filterung auf IP-Adresse auch nicht 100% scher ist, denn auch der Angreifer könnte die gleiche private Adresse in seiner Umgebung genutzt haben. Leider gibt es keinen SMTP-Header, welche den Receive Connector kennzeichnet.

Magic Parameter XOORG und X-OriginatorOrg

Am 15 Feb 2019 hat Microsoft auf dem Exchange Teamblog einen sehr technischen aber ebenso wichtige Artikel veröffentlicht.

Der Artikeln beschreibt ziemlich genau die Problematik des "Hintereingang" und dass der Exchange On-Premises Server quasi den Office 365 Servern vertraut und es keinen per Default eingebauten Schutz von Microsoft gibt. Natürlich kann ich hier fragen, warum jemand eine Mail an meine Domain direkt an Office 365 einliefern sollte, wenn der MX-Record doch ganz woanders hin zeigt. Die guten Absender machen das ja auch nicht aber die bösen Jungs hindert das nicht. Firmen, die über die Funktion Hybrid Centralized Mail Transport alle Mails von Office 365 über die On-Premises Exchange Server routen können ähnliche Probleme haben, weil der On-Premises Server nicht unterscheiden kann, ob die Mail nun über den eigenen Tenant oder einem anderen Tenant kommt. In dem Blog-Artikel beschreibt Microsoft aber schön, wie beim SMTP-Protokoll.

220 OK
HELO office365.com
OK
MAIL FROM: <user@uclabor.de> SIZE=22396 AUTH=<> XOORG=uclabor.de
...

X-OriginatorOrg: uclabor.de

Leider enthält Exchange On-Premises keine Funktion um schon beim "MAIL FROM" eine Mail zu bewerten und quasi einen unpassenden "XOORG" gleich abzulehnen oder nur einen passenden XOORG anzunehmen. Exchange Online setzt aber zusätzlich auch noch das Feld "X-OriginatorOrg".

Beide Werten dürfen Sie natürlich nur vertrauen, wenn die Verbindung von den Office 365 MailServern kommen, was sie anhand der IP-Adressen oder dem Namen im TLS-Zertifikat festmachen können

Beide Werte werden von Office 365 gesetzt und lassen sich offiziell nicht durch einen Client verändern.

Zwischenstand

Aktuell schützt Microsoft ihren Office 365 Tenant, indem ihr On-Prem-Server sich über eine statische IP-Adresse oder ein Zertifikat gegenüber Exchange Online ausweisen muss. In die Gegenrichtung stehen Sie aber relativ ungeschützt da, wenn Sie im Rahmen einer Exchange Hybrid Bereitstellung einen Exchange Server oder Exchange Edge Server neben ihrer normalen Abwehrkette Richtung Internet oder Office 365 veröffentlichen. Die Filterung auf die Source-IP-Adresse ist essentiell aber wird von Microsoft nicht entsprechend gefordert oder beschrieben. Der HCW übernimmt diese Aufgabe nicht mehr. Sie sind also auf sich alleine gestellt, um die IP-Adressen der Exchange Online Server in ihrer Firewall oder mittels eines eigenständigen Receive Connectors zu pflegen.

Weitere Links