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.
Schutzstufen
Sie können natürlich einen Exchange Server mit einem Bein direkt oder über ReverseNAT mit dem Internet verbinden. Ich bin sicher, dass es mehr als genug dieser Umgebungen gibt, die sich allein auf den "vorhandenen Schutz" eines aktuell gepatchten und vor allem konfigurierten Betriebssystems und Servers stützen. Gut muss ich das aber nicht finden.
Der Exchange Server ist für Hybrid über HTTPS (TCP-Port 443) und SMTP (TCP-Port 25) erreichbar und für beide Protokolle gibt es mehrstufige Möglichkeiten die Sicherheit zu verbessern:
Stufe | HTTP | SMTP |
---|---|---|
PortfilterDer erste Schutz besteht schon ml darin, dass Exchange nicht komplett aus dem Internet erreichbar ist, sondern eine Veröffentlichungsregel davor (Reverse NAT) nur Port 25/443 durchlässt und RDP, SMB, LDAP etc. natürlich gar nicht von extern, womöglich anonym erreichbar sind. Das ist die Basisfunktion einer Firewall. |
Portfilter | Portfilter |
RemoteIP-FilterungDer zweite Hebel ist die Einschränkung auf die Quell-IP-Adresse. Microsoft veröffentlicht die Adressen, welche aus der Cloud auf lokale Exchange Server zugreifen müssen. Eine gute Firewall hat dynamische Listen, um nur diese Adressen zu erlauben. Damit blocken Sie vermutlich 99% des Internet schon weg. DoS Attacken sind zwar weiter auf ihren Router davor und die Bandbreite möglich, aber Exchange hat Ruhe. Das funktioniert natürlich nur soweit, wie der legitime Zugriff von Homeoffice Usern über eine andere Verbindung, z.B. eigene IP-Adresse oder VPN erfolgt. |
Firewall | Firewall |
TLS-Zwang und TLS-PrüfungFür das Protokoll SMTP wissen wir, dass Exchange Online eine MTLS-Verbindung mit STARTTLS einleitet und sich mit einem öffentlichen Zertifikat "mail.protection.outlook.com" ausweist. Eine gute Firewall schaut sich die SMTP-Verbindung an und blockt Zugriffe, die nach dem HELO nicht mit einem STARTTLS weiter gehen und zudem schaut sie sich bis TLS 1.2 das übermittelte Zertifikat an. Damit ist ein weiterer Schutz gegen fremde Systeme möglich, die sich nicht als "mail.protection.outlook.com" ausweisen können. Viel mehr können Sie bei SMTP aber nicht machen, denn nach dem STARTLS darf eine Firewall eigentlich nicht mehr reinschauen, da sie sonst den MTLS-Kanal bricht und Exchange Online nicht mehr als vertrauenswürdig anschaut. Eventuell könne die Firewall ihrerseits ein Zertifikat mit dem Namen "mail.protection.outlook.com" einer eigenen PKI nach innen weitergeben, um dann auch noch die Mails auf Malware zu prüfen. Exchange nutzt aber auch im SMTP-Protokoll eigene nicht dokumentierte Erweiterungen, die daher vermutlich keine Firewall umsetzen kann. |
Entfällt | Firewall |
Protokoll/URL-FilterungBei SMTP kann die Firewall bis zum STARTLS jegliche andere missbräuchliche Verwendung unterbinden. Bei HTTPS kann sie aber auch die TLS-Verbindung aufbrechen und den HTTP-Datenstrom anschauen. In der ersten Näherung kann sie sich auf bestimmte URLs beschränken. Zugriffe nach "/Autodiscover", "/EWS", "API" sind für Hybrid ausreichen. Sogar die Migration per MRS kann über die eigene URL "/EWS/mrsproxy.dll" unterschieden werden. Auch die Methoden (GET/POST/PUT etc.) kann eine Firewall überwachen. |
WAF | Entfällt |
HTTP Authentication/PreauthenticationExchange Online meldet sich am OnPremises Server natürlich an. Die Migration (MRS) nutzt dazu eine klassische "Negotiate"-Anmeldung mit Username/Kennwort, die ein Reverse Proxy natürlich auch zumindest in Ansätzen betrachten kann. Die meisten anderen Zugriffe erfolgen mit einem OAUTH-Token und das ist auch für den Reverse Proxy lesbar und prüfbar. Offiziell unterstützt Exchange keine Preauthentication im klassischen Sinn. Es sollte aber funktionieren, wenn Exchange nichts davon merkt. Wenn ein erst einmal anonymer Client von de Web Application Firewall erst einmal ein 401 mit BEARER bekommt und die zweite Anfrage von der WAF geprüft und dann an Exchange gesendet wird. Das funktioniert nur nicht mit PoPToken oder NTLM und IIS Extended Protection. |
WAF | Entfällt |
HTTP PayloadZuletzt kann ein Reverse Proxy natürlich "versuchen" die Payload von MAPI/HTTP und EWS/HTTP zu interpretieren. Das sehe ich aber als sehr aufwändig, kostenintensiv und wenig sinnvoll an. Bis hier habe ich als Client schon die Source-IP-Beschränkung, URLFilterung und Preauthentication überwunden. |
schwer | Entfällt |
Also schauen wir uns die verschiedenen Schutzlevel noch einmal genauer an.
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:
- Hybrid deployment prerequisites
https://docs.microsoft.com/en-us/exchange/hybrid-deployment-prerequisites
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:
- Office 365 URLs and IP address ranges -
Exchange Online
https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#exchange-online - Other endpoints not included in the
Office 365 IP Address and URL Web service
https://docs.microsoft.com/en-us/microsoft-365/enterprise/additional-office365-ip-addresses-and-urls?view=o365-worldwide - IP-Adressen vertrauen
- Office 365 Netzwerkziele
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:
- Get-HybridMailflowDatacenterIPs (depreciated)
https://docs.microsoft.com/en-us/powershell/module/exchange/get-hybridmailflowdatacenterips - Office 365 Netzwerkziele
-
Office 365 IPs über REST
https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7
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.
- Exchange Webseite absichern
- Exchange mit Extended Protection veröffentlichen
- Exchange Hybrid Absicherung
- Exchange mit Extended Protection veröffentlichen
- Exchange Extended Protection
- IIS Extended Protection
- Deep Dive: How Hybrid Authentication
Really Works
https://techcommunity.microsoft.com/t5/exchange-team-blog/deep-dive-how-hybrid-authentication-really-works/ba-p/606780 - Principles of Token Validation
https://www.cloudidentity.com/blog/2014/03/03/principles-of-token-validation/ - Step 1: Create the authorization server
objects for your Exchange Online
organization
https://docs.microsoft.com/en-us/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help#step-1-create-the-authorization-server-objects-for-your-exchange-online-organization
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.
- Byte Order Mark
https://de.wikipedia.org/wiki/Byte_Order_Mark - How to remove Byte-Order-Mark with PowerShell
https://baswijdenes.com/how-to-remove-byte-order-mark-with-powershell/
# 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
- Export-Certificate
https://docs.microsoft.com/en-us/powershell/module/pki/export-certificate
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.
- JWT_VERIFY_CERTKEY
https://developer-docs.citrix.com/projects/netscaler-advanced-policy-expression-reference/en/12.0/http_version_t/http_version_t/ - Einen JSON Web-Token mit dem NetScaler
12 prüfen
https://www.provectus.de/2018/05/ein-json-web-token-mit-dem-netscaler-12-prufen/ - OpenID Connect token validation in
Citrix ADC
https://xenit.se/blog/2018/10/22/openid-connect-token-validation-in-citrix-adc/ - Validating OAuth 2.0 Access Tokens with
NGINX and NGINX Plus
https://www.nginx.com/blog/validating-oauth-2-0-access-tokens-nginx/
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.
- AcceptCloudServicesMail und CloudServicesMailEnabled
- Hybrid Hintereingang
- Configure Force TLS on Exchange On-Premises environment | Settings of
Receive connector | Part 9#12
https://o365info.com/configure-force-tls-on-exchange-On-Premises-environment-settings-of-receive-connector-part-9-12-tls/
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:
Auch hier sollten Sie ihre Firewall prüfen, ob diese den WebService von Microsoft zur dynamischen Pflege nutzen kann.
- Help secure your Microsoft Teams channel bot and web app behind a firewall
https://learn.microsoft.com/en-us/azure/architecture/example-scenario/teams/securing-bot-teams-channel
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
- Office 365 URLs and IP address ranges -
Exchange Online
https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#exchange-online - IP-Adressen vertrauen
- Office 365 Netzwerkziele
- TCP SYN ACK RES
- Hafnium Exploit
- Bearer Decoding
- Authentifizierung im Wandel der Zeit
- HTTP Authentication
- ADFS Monitoring
- PRTG Check ADFS
-
More Whitepapers to Help You Securely
Publish Exchange
https://techcommunity.microsoft.com/t5/exchange-team-blog/more-whitepapers-to-help-you-securely-publish-exchange/ba-p/588770 - Principles of Token Validation
https://www.cloudidentity.com/blog/2014/03/03/principles-of-token-validation/ - Deep Dive: How Hybrid Authentication
Really Works
https://techcommunity.microsoft.com/t5/exchange-team-blog/deep-dive-how-hybrid-authentication-really-works/ba-p/606780 - Hybrid deployment prerequisites
https://docs.microsoft.com/en-us/exchange/hybrid-deployment-prerequisites - Exchange Online endpoints
https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges - Get-HybridMailflowDatacenterIPs (depreciated)
https://docs.microsoft.com/en-us/powershell/module/exchange/get-hybridmailflowdatacenterips - [MS-XOAUTH]: OAuth 2.0 Authorization
Protocol Extensions
https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-xoauth/0b717658-4ceb-4401-9da9-7860c9ca2f2f?redirectedfrom=MSDN