Exchange Hybrid Absicherung

Für die Koexistenz von Exchange On-Premises mit Microsoft 365-Diensten wie Exchange Online und insbesondere Microsoft Teams ist ein "Hybrid-Mode" erforderlich. Wer in Teams auch auf Kalender von lokalen Postfächern zugreifen will, muss "Classic Hybrid" einrichten, bei dem die lokalen Exchange Server von Exchange Online per Autodiscover, EWS und MRSPROXY erreichbar sind. Diese Seite behandelt die Absicherung dieses Zugangs.

Risiken

Schon vor der Cloud habe ich mit Exchange On-Premises immer zwei Gruppen von Kunden gehabt. Die eine Gruppe hat Exchange On-Premises per HTTPS aus dem Internet erreichbar gemacht und darauf vertraut, dass Exchange sich schon gut "wehrt" und die Anwender ihr Zugangsdaten sicher aufbewahren. Nur ganz kleine Firmen haben dazu ihren Exchange Server über Port 443 per NAT oder sogar direkt erreichbar gemacht. In der Regel ist schon eine Firewall/Portfilter davor und die Sicherheit konnten wir durch einen ReverseProxy weiter steigern, welcher eine Preauthentifizierung durchgeführt hat. Auch MDM-Lösungen haben den ActiveSync-Zugang zusätzlich abgesichert.

Dennoch ist es auch heute damit immer noch möglich, z.B.: per Username/Kennwort-Attacken entweder interne Konten zu sperren oder Zugänge zu erraten oder abgephishte Zugangsdaten direkt zu missbrauchen. Auch haben uns der Hafnium Exploit u.a. gezeigt, dass jede Software Fehler haben kann, die teils ohne Authentifizierung missbraucht werden können.

Die andere Firmengruppe hat ihren Exchange Server nicht direkt veröffentlicht, sondern nur von "intern" erreichbar gemacht. Das schützt zwar nicht generell, da es auch viele internen Angriffe gibt aber der Angreifer musste erst einmal ins LAN kommen. Benutzer im Homeoffice oder auf Reisen haben dann ein VPN aufgebaut, um als "intern" und vertrauenswürdiger zu zählen.

Exchange Erreichbarkeit

Für den Exchange Hybrid Mode kann ich aber kein VPN nutzen und muss meinen Exchange Server zumindest für bestimmte Subnetze aus dem Internet erreichbar machen. Microsoft beschreibt dies auch:

In der ersten Tabelle wird recht allgemein beschrieben, welche eingehenden Verbindungen erforderlich sind:


Quelle: https://docs.microsoft.com/en-us/exchange/hybrid-deployment-prerequisites

Das ist aber eine sehr verallgemeinerte Übersicht und führt nur die "Exchange Online Endpoints" auf. Diese Liste ist auch durchaus stattlich und kann auf folgender Seite eingesehen werden:

Aber auf der gleichen Seite gibt es weiter unten noch eine detailliertere Tabelle zu den einzelnen URLs, auf der ich schon mal die Exchange 2010/2013-Einträge entfernt habe:


Quelle: https://docs.microsoft.com/en-us/exchange/hybrid-deployment-prerequisites

Aber auch so ist sichtbar, dass es für keinen Weg eine "PreAuth" gibt und die Mailbox Migration sogar NTLM/Basic erfordert. Dennoch können wir nun weitere Absicherungen diskutieren können.

Source-IP

Der erste Verteidigungsring ist natürlich die Filterung auf die Quell-IP-Adresse. Da der komplette Verkehr über HTTPS (oder SMTP) abgewickelt wird, findet immer ein TCP-Handshake (TCP SYN ACK RES) statt. Ein Angreifer könnte daher maximal einen TCP-SYN-Flooding gegen die veröffentliche öffentliche IP-Adresse absenden, deren ACK-Antwort dann die missbrauchte Adresse treffen würde. Eine Verbindung käme aber nie zustande.

Das Problem bei dieser Konfiguration ist aber, dass die Liste der IP-Adressen durchaus mächtig ist. Früher gab es mal ein PowerShell-Commandlet, um die Exchange Datacenter IPs für einen Tenant zu ermitteln aber die Funktionen sind mittlerweile entfallen oder depreciated:

Achtung:
Die auf der Webseite veröffentlichten IP-Adressen sind nicht immer vollständig. Nutzen Sie bei Abfragen immer den REST-Service
Selbst dann scheint es weitere Exchange Server zu geben, deren Source-IP nicht aufgeführt sind. Es gibt wohl auch keine Garantie, dass die Adressen exklusiv von Exchange Online genutzt werden auch wenn aus dem Produktbereich die Information kommt, die IP-Adressen wären exklusiv.

Auf der andern Seite kann man natürlich annehmen, dass jeder Exchange Frontend Server nicht von den Clients selbst eingehend angesprochen wird, sondern seinerseits auch ausgehende Verbindungen zu anderen Exchange Servern in Exchange Online aber eben auch über Hybrid zur On-Premises-Umgebung aufbauen. Allein für Exchange hat Microsoft mehrere IDs.

PS C:\> $o365range=Invoke-RestMethod https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7
PS C:\> $o365range | where {$_.serviceArea -eq "Exchange"} | ft id,urls,tcpports,notes

 id urls                                                               tcpPorts notes
 -- ----                                                               -------- -----
  1 {outlook.office.com, outlook.office365.com}                        80,443
  2 {smtp.office365.com}                                               587
  3 {r1.res.office365.com, r3.res.office365.com, r4.res.office365.com} 80,443
  5 {*.outlook.office.com, outlook.office365.com}                      143,993  Exchange Online IMAP4 migration
  6 {*.outlook.office.com, outlook.office365.com}                      995      Exchange Online POP3 migration
  8 {*.outlook.com, attachments.office.net}                            80,443
  9 {*.protection.outlook.com}                                         443
 10 {*.mail.protection.outlook.com}                                    25
154 {autodiscover.*.onmicrosoft.com}                                   80,443

Allerdings waren beim letzten Check die IP-Adressen von ID1, 5 und 6 identisch und interessant sind auch nur die Bereich mit 80/443. Aber auch diese Liste ist durchaus lang:

PS C:\> ($o365range | where {$_.id -eq 1}).ips
13.107.6.152/31
13.107.18.10/31
13.107.128.0/22
23.103.160.0/20
40.96.0.0/13
40.104.0.0/15
52.96.0.0/14
131.253.33.215/32
132.245.0.0/16
150.171.32.0/22
204.79.197.215/32
2603:1006::/40
2603:1016::/36
2603:1026::/36
2603:1036::/36
2603:1046::/36
2603:1056::/36
2620:1ec:4::152/128
2620:1ec:4::153/128
2620:1ec:c::10/128
2620:1ec:c::11/128
2620:1ec:d::10/128
2620:1ec:d::11/128
2620:1ec:8f0::/46
2620:1ec:900::/46
2620:1ec:a92::152/128
2620:1ec:a92::153/128
2a01:111:f400::/48

Allein wenn ich nur die IPv4-Adressen anschaue, sind ein /13-Subnetz schon über 500.000 IP-Adressen und das /14 noch 256000-Adressen , so dass die /16, /20, /22-Subnetze gar nicht mehr auffallen. Bei den knapp 1 Millionen IPv4-Adressen sind die IPv6-Adresse noch gar nicht berücksichtigt. Allein ein Subnetz wie "2603:1026::/36" sind "4,951,760,157,141,521,099,596,496,896" Hosts. Die Frage bleibt, ob diese IP-Adressen wirklich alle von Exchange Online Servern benutzt werden und nicht auch fremde Dienste, z.B. Azure-VMs o.ä. im gleichen IP-Bereich angesiedelt sein könnten.

Eine Aussage von Microsoft, dass hier nur Exchange Server stehen, habe ich noch nicht. Für die Microsoft Teams IP-Bereiche der Transport-Relays gibt es so eine Aussage. Siehe auch IP-Adressen vertrauen.

Dennoch ist natürlich die Filterung auf diese IP-Adressen die erste Schutzfunktion, wenn die eigenen Exchange Server nicht aus dem Internet erreicht werden sollen.

Source-IP aus SPF?

Es gibt durchaus noch eine zweite Quelle, Sie Sie als "Source-IP-Adresse" von Exchange Online heranziehen könnten. Jede Domain, die über Exchange Online ihre Mails versendet. sollte die Microsoft Server im SPF-Record per "Include" addieren:

Die Abfrage des DNS-Text-Records ist mit PowerShell sehr einfach:

PS C:\> (Resolve-DnsName -Type TXT spf.protection.outlook.com).strings.split(" ")
v=spf1
ip4:40.92.0.0/15
ip4:40.107.0.0/16
ip4:52.100.0.0/14
ip4:104.47.0.0/17
ip6:2a01:111:f400::/48
ip6:2a01:111:f403::/49
ip6:2a01:111:f403:8000::/50
ip6:2a01:111:f403:c000::/51
ip6:2a01:111:f403:f000::/52
-all

Wenn die diese Liste aber mit der öffentlichen Liste vergleichen dann finden Sie Sie zwar wenige Überlappungen aber auch zusätzliche und fehlende Einträge. Anscheinend verwendet Exchange Online weitere Systeme, um Mails ins Internet zu senden aber nicht alle Hybrid Server dienen auch zum direkten Versand ins Internet.

Das ist auch nicht ungewöhnlich, dass ein Hoster den Versand ins Internet über andere Hosts abwickelt.

Damit ist der SPF-Record nicht geeignet, eine Allow-Liste für den Hybrid-Eingang zu definieren.

URLs

Ich kann zwischen Exchange Online und meine On-Premises Exchange Server natürlich einen Reverse Proxy schalten. Wenn ich mehrere Server nutze, dann ist ein Loadbalancer sinnvoll. Beide Systeme können nun einfach TCP-Verbindungen durchleiten oder sie können die HTTPS-Verbindungen selbst terminieren. Wenn die externe Anfrage hier terminiert wird, kann das System die Inhalte untersuchen und z.B. nach URLs filtern. Wenn Sie die Liste weiter oben betrachten, dann sehen Sie schon, dass allein für den Hybrid-Mode nur einen Auswahl an URLs erforderlich ist.

ALLOW /autodiscover/autodiscover.svc/wssecurity
ALLOW /autodiscover/autodiscover.svc
ALLOW /ews/exchange.asmx/wssecurity
ALLOW /ews/mrsproxy.svc
BLOCK / *

Ich brauche für den Hybrid-Mode z.B. weder "/owa", "/mapi" noch "/rpc" oder "oab". Diese Zugänge kann ich von extern blockieren oder gar nicht erst veröffentlichen und damit entsprechende Lücken besser absichern. Und selbst der Zugriff auf "/EWS" kann ich auf den MRSPROXY als auch die Unterverzeichnisse "wssecurity" beschränkten. Damit verhindere ich, dass z.B. Mac-Benutzer per EWS mit einfacher Anmeldung überhaupt erst den Server erreichen und eine Anmeldung versuchen können. Denken Sie daran, dass dieses Zwischensystem seinerseits die Zugriff zum nachgelagerten Exchange Server wieder per HTTPS verschlüsseln muss.

Dieser Schutz ist schon sehr gut aber noch ist es möglich, dass von den Microsoft IP-Adressen anonyme Anfragen den Exchange On-Premises Server erreichen und eine Lücke von Exchange ausnutzen. Seit dem Hafnium Exploit sind die Exchange Administratoren zurecht vorsichtig.

HTTPS-Authentication

Anhand der Tabelle haben wir gesehen, dass Exchange Online sich gegen den lokalen Exchange, mit Ausnahme des MRSProxy bei einer Postfachmigration, eine Authentifizierung per "WS-Security Authentication" durchführt. Die Besonderheit dieser Authentifizierung ist, dass keine Benutzernamen oder Kennworte übertragen werden, sondern OAUTH-Tokens. Exchange Online hat ja sowieso kein "Dienstkonto" für den Zugriff auf den lokalen Exchange Server. Stattdessen vertraut der lokale Exchange Server der "Azure AD Authentication Service", der entsprechend digital signierte Tokens ausstellt. Zudem ist die Payload selbst digital signiert aber nicht verschlüsselt. Für die Verschlüsselung der übertragenen Daten sorgt die Transportverschlüsselung per HTTPS.

Wenn wir aber schon für die URL-Prüfung die Daten unverschlüsselt vorliegen haben, dann kann auch dieses System vielleicht auch die Payload auf "Gültigkeit" prüfen. Wenn jeder Request immer mit einem Bearer-Token (Siehe auch Bearer Decoding, Authentifizierung im Wandel der Zeit und HTTP Authentication) kommt, dann kann auch die Applikationsfirewall diese Informationen prüfen. Da nur die "richtigen Exchange Server" auch einen korrekt signierten Request senden können, ist damit eine weitere Schutzfunktion gegen fremden Code umsetzbar. Allerdings hilft das natürlich nicht, wenn der Angreifer die Exchange Online Server gekapert hätte oder als Man in the Middle die Authentifizierungs-Token mitliest.

Die Schutzfunktion muss natürlich alle Varianten der Exchange Online Zugriffe "verstehen". Schon beim ersten Handshake kann es passieren, dass Exchange Online erst einmal einen Request ohne "Bearer" sendet und die Erreichbarkeit zu prüfen und im zweiten Paket ein "leerer Bearer-Header" kommt. Der muss schon durchgelassen werden, damit Exchange On-Premises überhaupt mitteilen kann, von welchem Authentication Service er ein Ticket akzeptiert. Erst mit der dritten Anfrage kommt dann ein gültiges Bearer-Token. Diese Kommunikation habe ich auf Exchange Hybrid Absicherung schon analysiert.

Für eine zusätzliche Sicherheit sollte die Application Firewall natürlich nur Anforderungen zum Exchange On-Premises Server durchlassen, die korrekt authentifiziert sind. Das bedeutet aber auch, dass die Application Firewall natürlich die vorherigen Schritte nachbilden, damit der Exchange Online Server überhaupt eine Anmeldung per Bearer-Token ausführt.

Die Herausforderung hierbei ist natürlich, dass Microsoft das Verhalten auch immer wieder "anpassen" kann.

Für die Prüfung des Bearer-Tokens und anderer Signaturen muss die Application Firewall natürlich zumindest den PublicKey des Signierers kennen. Microsoft hat die Zusammenhänge bei der Authentifizierung durchaus dokumentiert.

Aus der Beschreibung habe ich folgende URL abgeleitet, welche mir die XML-Datei mit den Zertifikaten gibt.

Invoke-WebRequest `
   -Uri https://login.microsoftonline.com/msxfaq.mail.onmicrosoft.com/federationmetadata/2007-06/federationmetadata.xml

Die URL kommt ihnen vielleicht von der Seite ADFS Monitoring oder PRTG Check ADFS bekannt vor, wo ich per Code ebenfalls das Zertifikat auslese, um das Ablaufdatum zu erhalten. Ich habe aus der XML-Datei dann das erste X509-Zertifikat geholt:

Das geht natürlich auch per PowerShell.

Hinweis: Bei mir war das erste Zeichen ein CHR(65279), was auch als "BOM" = "Byte Order Mark" bekannt ist. Daher habe ich es mit einem "Substring" abgeschnitten.

# Abruf der Metadaten meines Tenant
$metadata = Invoke-WebRequest `
                         -method GET `
                         -uri "https://login.microsoftonline.com/msxfaq.mail.onmicrosoft.com/federationmetadata/2007-06/federationmetadata.xml" `
                         -Headers @{"Host"="login.microsoftonline.com"}
# Konvertieren des Body in eine XML-Datei und Extraktion des Siging Zertifikats
$certbase64=([xml]($metadata.content.substring(1))).EntityDescriptor.Signature.KeyInfo.X509Data.X509Certificate

# Konvertrieren des Base64 codierten Zertifikats in ein Byte-Array
$certarray = [System.convert]::FromBase64String($certbase64)

# Instanzieren des Zertifikats anhand des Byte-Arraya
$cert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList @(,$certarray)

#Export als CER-Datei fuer weitere Verwendung.
Export-Certificate -Cert $cert -FilePath c:\temp\oauth.cer -Type CER

Nach der Decodierung konnte ich folgende Properties sehen.

$cert | fl *

EnhancedKeyUsageList : {}
DnsNameList          : {accounts.accesscontrol.windows.net}
SendAsTrustedIssuer  : False
Archived             : False
Extensions           : {System.Security.Cryptography.Oid}
FriendlyName         :
HasPrivateKey        : False
PrivateKey           :
IssuerName           : System.Security.Cryptography.X509Certificates.X500DistinguishedName
NotAfter             : 20.12.2025 21:50:17
NotBefore            : 21.12.2020 21:50:17
PublicKey            : System.Security.Cryptography.X509Certificates.PublicKey
RawData              : {48, 130, 3, 5…}
SerialNumber         : 377DD139A209E9B2415830B1B662446E
SignatureAlgorithm   : System.Security.Cryptography.Oid
SubjectName          : System.Security.Cryptography.X509Certificates.X500DistinguishedName
Thumbprint           : 9CEA37643ACE0D710AD63296857B251D1FCA5C48
Version              : 3
Issuer               : CN=accounts.accesscontrol.windows.net
Subject              : CN=accounts.accesscontrol.windows.net

Sie sehen hier auch, dass das Zertifikat eine Gültigkeit von 5 Jahren hat. Alle Dienste, die von diesem Service ausgestellten Tokens verifizieren, müssen rechtzeitig über die Federation Metadata URL den aktuell gültigen Public Key aktualisieren.

Mit dem "Public Key" könnte nun eine Application Firewall die Tokens prüfen und damit auf Anwendungsschicht sicherstellen, dass nur legitime Zugriffe bis zum Exchange Server durchgereicht werden. Also habe ich mich auf die Suche begeben, zu welchen Systemen sich dazu etwas finden lässt:

ich habe entsprechende Filter noch nicht bei Kunden umgesetzt. Bislang war die Beschränkung auf die Source-IP-Range und optional auf URLs als ausreichend sicher angesehen worden.

Es gibt aber schon Hinweise, dass diverse als Reverse Proxy genutzte Produkte die Bearer-Tokens auswerten und Aktionen ausführen können.

SMTP-Absicherung mail.protection.outlook.com

Auch für den Mailfluss sagt Microsoft, dass es keinen Proxy oder Relay zwischen Exchange Online und Exchange On-Premises geben darf, da ansonsten erweiterte Funktionen wie MTLS und XOORG nicht mehr funktionieren.

Don't place any servers, services, or devices between your On-Premises Exchange servers and Microsoft 365 or Office 365 that process or modify SMTP traffic. Secure mail flow between your On-Premises Exchange organization and Microsoft 365 or Office 365 depends on information contained in messages sent between the organization
"Transport routing in Exchange hybrid deployments" - https://learn.microsoft.com/en-us/exchange/transport-routing

Das bedeutet, dass Exchange On-Premises zumindest die Exchange Online Server ohne Umweg über ein Mailrelay erreichen muss, damit die Cloud den Source-Server anhand eines Zertifikats oder notfalls der IP-Adresse dem richtigen Tenant zuordnen kann.

Kritischer ist aber die Rückrichtung, bei der Exchange Online eine eingehende SMTP-Verbindung zum On-Premises Server aufbaut. Dazu muss der lokale Exchange Server natürlich "aus dem Internet" per SMTP erreichbar sein. Nun möchte natürlich niemand einen Exchange Server über Port 25 einfach mal so erreichbar machen. Und vor allem schon deshalb nicht, da ein Exchange Server über den "Default Receive Connector" auch anonym Mails ohne effektiven Spamfilter für interne Empfänger annimmt. Wenn Sie dann noch den "Default Receive Connector" derart angepasst haben, dass interne Clients ihn als Relay nutzen dürfen, dann bedeutet eine Erreichbarkeit aus dem Internet ein offenes Relay. Hier müssen Sie also auf jeden Fall gegensteuern.

So ein Zugang bleibt nicht lange unentdeckt, wenn er nicht abgesichert ist.

Ich würde daher Exchange Online immer eine Verbindung zu einer IP-Adresse aufbauen lassen, die nur von Exchange Online erreichbar ist. Das ist zwar noch keine 100% Sicherheit, weil auch ein Admin in einem anderen Tenant einen entsprechenden Outbound-Connector einrichten kann, aber dazu muss er das System wissen. Das ist aber aus einem SMTP-Header einfach zu finden. Die IP-Filterung ist also nur ein Teil der Lösung:

Die Liste der IP-Adresse können Sie per RestAPI von Microsoft laden.

#JSON-Liste von Microsoft laden
$ips= Invoke-RestMethod https://endpoints.office.com/endpoints/Worldwide?ClientRequestId=b10c5ed1-bad1-445f-b386- b919946339a7 

# Regeln mit den IP-Adressen von Port 25 ausgeben
($ips | where {$_.tcpports -eq "25"}).ips

# Die Liste müssten Sie nun der Firewall bringen.

Einige Firewalls haben aber auch vordefinierte Filter.

Auch mit einer Filterung auf SourceIP-Adressen sollten Sie auf jeden Fall sicherstellen, dass...

  • ... der Default Receive Connector kein Relay ist
    Wenn Sie intern ein offenes Relay benötigen, dann legen Sie dazu besser einen eigenen Receive Connector an, auf dem dann ausgewählte IP-Adressen oder Subnetze erlaubt werden
  • ... die Firewall nur Office 365 auf diesen Zugang erlaubt
    Ihr Exchange Server wird vermutlich hinter einer Firewall per NAT den Port 25 bereitstellen. Dann sollten Sie auf der Firewall die Source-IP entsprechend filtern.
  • ... optional ein TLS-Check durchgeführt wird
    Sofern möglich, kann eine Firewall auch den TLS-Handshake nach dem STARTTLS mitlesen und so erzwingen, dass die Exchange Online Gegenseite mit einem Zertifikat kommen muss.

Damit dürfte dann auch der SMTP-Zugang zum lokalen Exchange Server für den Hybrid Mode ausreichend abgesichert sein.

SMTP-Absicherung On-Premises

Die Mailübertragung von Exchange Online zu Exchange On-Premises muss natürlich auch abgesichert werden. Kaum jemand wird einen On-Premises Exchange Server ungesichert mit einem Bein ins Internet stellen. Daher ist hier die Filterung nach Source-IP-Adressen besonders wichtig. Leider sind die Schutzfunktionen von Exchange On-Premises selbst ziemlich beschränkt.

Der Hybrid Konfiguration Wizard geht davon aus, dass Sie den "Default Receive Connector" nicht verändert haben und addiert nur einen Eintrag in die Konfiguration:

Set-ReceiveConnector `
   -Identity „EX2016\Default EX2016“ `
   -TlsDomainCapabilities "mail.protection.outlook.com:AcceptCloudServicesMail"}

Über diesen Eintrag bekommt eine eingehende Verbindung, bei der sich der Absender mit einem Zertifikat der Domain "mail.protection.outlook.com" authentifiziert die Berechtigungen "AcceptCloudServicesMail". Damit werden einige Regeln der Exchange Header Firewall außer Kraft gesetzt, die ansonsten intern genutzte Header entfernt. So kann Exchange On-Premises dann berücksichtigen, dass Die Mail vom eigenen Connector kommt. Wenn Sie aber genau hinschauen, dann sollten ihnen zwei Dinge auffallen

  • Andere Tenants können auch
    Was hindert mich in meinem Tenant einen Outbound Connector zu ihrem Receive Connector aufzubauen und damit von diesem "Vertrauen" zu profitieren
  • Erreichbarkeit des Connectors
    Allein die Funktion "TlsDomainCapabilities" blockiert ja keine anderen Verbindungen zu dem Connector und das ist sogar sinnvoll, wenn der Connector auch für die interne Kommunikation zwischen Exchange Servern oder von internen SMTP-Clients genutzt wird.

Sie können schon die Konfiguration besser absichern, aber dazu müssen Sie manuell Hand anlegen, z.B. indem sie einen eigenen Receive Connector für den Eingang von Office 365 vorsehen. Bei Exchange 2010 hat Microsoft das sogar noch gemacht aber ab Exchange 2013 nicht mehr. Wenn Sie einen eigenen Connector vorsehen, dann können Sie diesen z.B. über die Remote-IP auf die Office 365-Adressen begrenzen oder sie geben ihm eine eigene IP-Adresse oder TCP-Port und routen auf der Firewall den Verkehr von Exchange Online auf diesen separaten Connector. So können Sie dann auch z.B. TLS erzwingen, damit keine ungesicherten Verbindungen über diesen Connector möglich sind. Aber auch an Angreifer weiß natürlich, wie er STARTTLS nutzt und ein Client-Zertifikat sendet, um diese Hürde zu umgehen. Damit hat er zwar keinen Vertrauenslevel aber er kann dennoch eine Mail per SMTP senden.

Daher ist es auch weiterhin wichtig, die Source-IP entsprechend abzusichern, denn ein On-Premises Exchange hat aktuell keine Einstellmöglichkeit, um z.B. nur Verbindungen mit einem Zertifikat auf den Namen "mail.protection.outlook.com" zuzulassen.

Microsoft Teams

Neben der reinen Exchange Hybrid-Bereitstellung, gibt es natürlich noch andere Cloud-Dienste, die ebenfalls mit Exchange On-Premises kommunizieren wollen. Wenn die Postfächer der Anwender "On-Premises" liegen und sie mit Microsoft Teams ihren Kalender nutzen wollen, dann ist ebenfalls eine Exchange Hybrid Bereitstellung erforderlich. Allerdings reicht es dann nicht die Exchange Online Bereiche zuzulassen, denn bei Teams spricht der Client mit dem Teams Service, der dann seinerseits eine Verbindung zu Exchange On-Premises direkt aufbaut. Teams bedient sich dabei ebenso "Autodiscover" und "EWS".

Aber auch Teams Bots, die sie selbst hosten um die Funktion mit eigenen Daten anzureichern, müssen aus der Cloud angesprochen werden. Auch hier ist es schon wichtig, den selbst geschriebenen Bot nicht aus dem ganzen Internet erreichbar zu machen und allein auf die Sicherheit des Tokens zu setzen. Nach meiner Einschätzung sind dies alle IP-Adressen aus der ID12:


Quelle https://learn.microsoft.com/de-de/microsoft-365/enterprise/urls-and-ip-address-ranges?&view=o365-worldwide#skype-for-business-online-and-microsoft-teams

Auch hier sollten Sie ihre Firewall prüfen, ob diese den WebService von Microsoft zur dynamischen Pflege nutzen kann.

Zwischenstand

Eine Beschränkung auf die von Microsoft veröffentlichten IP-Adresse ist eine einfache Lösung den Zugriff auf die lokalen Exchange Server auf Exchange Online zu beschränken. Solange es aber keine Zusicherung von Microsoft gibt, dass diese IP-Range auch nur von Exchange Online genutzt wird, bleibt ein ungutes Gefühl, dass vielleicht doch eine AzureVM eines anderen Tenants mit einer IP-Adresse aus dem Bereich auf ihren lokalen Exchange Server zugreifen könnte.

Der Exchange Online Service weist sich mit seinem OAUTH-Token aus und wenn Sie allein der Verifizierung durch den Code auf dem lokalen Exchange Server nicht trauen, dann könnte eine Prüfung des OAUTH-Tokens einen zusätzlichen Schutz bieten.

Aktuell habe ich noch keine Bestätigung, dass Reverse Proxy Server solche Prüfungen durchführen können und Exchange Online immer ein Bearer-Token mit sendet.

Weitere Links