Exchange Hybrid Absicherung

Für die Koexistenz von Exchange OnPremises 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 OnPremises immer zwei Gruppen von Kunden gehabt. Die eine Gruppe hat Exchange OnPremises 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 OnPremises-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 Mio 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. AzureVMs 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.

URLs

Ich kann zwischen Exchange Online und meine OnPremises 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 OnPremises Server erreichen und eine Lücke von Exchange ausnutzen. Seit dem Hafnium Exploit sind die Exchange Administratoren zurecht vorsichtig.

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 OnPremises ü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 OnPremises 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 OnPremises 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 OnPremises 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 OnPremises Server aufbaue. 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. Die Hintertür bleibt nicht lange unentdeckt. 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.

Sie sollten 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.

Microsoft Teams

Neben der reinen Exchange Hybrid-Bereitstellung, gibt es natürlich noch andere Cloud-Dienste, die ebenfalls mit Exchange OnPremises kommunizieren wollen. Wenn die Postfächer der Anwender "OnPremises" 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 OnPremises 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