Office 365 Netzwerkziele

Damit Anwender mit Office 365 arbeiten können, müssen sie natürlich die Dienste in der Cloud auch nutzen können. Auch wenn "Internet-Zugriff" mittlerweile zum Standard gehört, gilt für Firmen oft noch dass "ungefilterter Internetzugriff" nicht üblich ist. Da gibt es zum einen das Jugendschutzgesetz, welches Firma dazu zwingt, junge Auszubildende zu schützen, obwohl diese heute per Smartphone ungefiltert das Internet nutzen können. Zum Anderen versprechen sich Firmen aber natürlich einen besseren Schutz, wenn auch von Innen nach Außen nicht alles erlaubt wird.

Beachten Sie dazu auch die Seite IP-Adressen vertrauen

Erste Hürde ist daher meist ein HTTP-Proxy, der eine Authentifizierung erfordert. Das ist zwar mittlerweile auch per "integrierter Anmeldung" möglich, aber das funktioniert nicht im jedem Falle. für den Zugriff auf Office 365 Ziele wäre eine Umgehung der Authentifizierung wünschenswert. Wenn eine Firma die Dienste von Office 365 nutzt, dann werden Sie die Office 365 Server schon als "Trusted" ansehen. Schließlich vertrauen sie diesen Servern ja schon ihre Daten an.

https://aka.ms/o365ips   Kurzlink zur Textbeschreibung der Office 365 IP-Adressen
https://aka.ms/ipurlws   Kurzlink zum Webservice

Achtung:
Die bisher von Microsoft und hier im Artikel auch genannten URLs zu Webseiten werden wohl im Oktober abgeschaltet. Stattdessen sollten Sie den neuen REST-Service unter den folgenden Adressen nutzen.
https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7
https://endpoints.office.com/endpoints/o365worldwide

Optimierung

Microsoft veröffentlicht die Liste der Ziele in der Cloud nicht nur, damit sie diese in der Firewall zulassen sondern verbindet damit sogar noch drei Abstufungen:

Optimierung Beschreibung

Optimieren – Erforderlich

Diese Verbindungen werden sehr intensiv genutzt und müssen „optimiert“ werden. Dies betrifft z.B. Audio/Video bei Teams über UDP etc. Sind diese Verbindungen nicht möglich, dann hat es direkte negative Auswirkungen auf die Dienste.

Zulassen – Erforderlich

Diese Verbindungen müssen nicht zwingend optimiert werden und könnten also auch über einen http-Proxy laufen. Allerdings können diese Protokolle meist keine Authentifizierung anzeigen, d.h. ein http-Proxy muss diese Verbindungen als allow-List durchlassen.

Standard – Erforderlich

Diese Ziele müssen erreichbar sein aber unterstützen eine Anmeldung z.B. an einem http-Proxy. Allerdings ist auch hier der Mehrwert zu hinterfragen, da viele Anmeldedialoge nicht nur stören, sondern auch unsicherer sind. Jedes Mal, wenn ein Anwender seine Zugangsdaten eingibt, besteht auch das Risiko eines abphishen.

Je "freizügiger" die Verbindung zum Internet ist, desto kritischer wird dies speziell bei Firmen mit erhöhtem Schutzbedarf gesehen. Darunter fallen nicht nur KRITIS-Firmen, sondern auch Banken, Versicherungen, u.a. Beim BSI gibt es Empfehlungen zur Absicherung.

URL oder IP-Adresse?

Alle Quellen, die sie letztlich anzapfen enthalten teils Hostname, auch mit Wildcard aber auch IP-Adressen. Die beiden Quellen sind für sich nicht vollständig. Wenn Sie z.B. die Hostnamen haben, dann können Sie damit per NSLOOKUP zwar ein paar Adressen auflösen aber nie alle Adressen. Microsoft liefert ihnen je nach ihrem Standort die "naheliegenden" Server. Eine globale Firewall-Richtlinie lässt sich so natürlich nicht ermitteln. Das Gilt noch im so mehr, wenn die Hostnamen mit einem "*.<domain>" für sehr viele Namen stehen können.

Auch die Liste der IP-Adressen ist zusätzlich zu betrachten. Es gibt dabei durchaus IP-Adressen, die eben nicht per DNS-Name aufgelöst werden können. Für Dienste wie den Skype for Business AVEdge oder Teams TURN/STUN-Server werden im Protokoll selbst per IP-Adresse adressiert und nicht über Namen.

Insofern sollten sie bei IP-Adress-basierten Filtern die IP-Adressen "Allowlisten" und ein Stück weit darauf hoffen, dass alle per DNS-Namen aufgeführten Einträge auch in den IP-Listen enthalten sind. Zusätzlich können Sie natürlich die DNS-Namen nutzen, um über Proxy-Ausnahmen diese Zugriffe anders zu behandeln. Es gibt auch Firewalls, die Pakete per NAT durchlassen aber dennoch den TLS-Handshake "beobachten" und so den Namen der Zielseite ermitteln, um den Dienst dingfest zu machen.

Wichtige Ziele zuerst!

In den folgenden Abschnitten werden Sie von URls und IP-Adressen geradezu erschlagen und der ein oder andere Administrator ist versucht gleich zu kapitulieren. Es steht aber nirgends geschrieben, dass Sie alle Adressen und Ziele in ihrer Firewall als "Ausnahme" einzutragen haben. Diese Listen enthalten alle Office 365 Dienste. Hierbei ist aber genau zu unterscheiden, welche Dienste welchen Anspruch an die Verfügbarkeit haben und welche Dienste nennenswerte Daten übertragen.
Wie so oft sind es vielleicht 10% der Ziele, die 90% des Datenvolumens übertragen und daher optimiert werden sollten. Dazu zählen:

  • Exchange Online (outlook.office365.com)
  • OneDrive (my-tenantname.sharepoint.com
  • SharePoint (tenantname.sharepoint.com)

Für diese Dienste ist zwar auch das Thema Latenzzeiten relevant aber doch nur eingeschränkt. Für die Laufzeit sind ganz andere Dienste kritisch wie:

  • Skype for Business Audio/Video
  • Teams Audio/Video
  • Direct Routing SIP Trunk

Auf der anderen Seite gibt es ganz viele Dienste, die Sie auch weiterhin problemlos über einen Proxy leiten können, denn Sie sind weder für Latenzzeit noch Durchsatz wichtig, z.B. die Aktivierung für Office Produkte und viele andere Dinge. Für den Download von Office 365 ProPlus ist ein Proxy sogar aufgrund des Caching von Vorteil, wenn Sie nicht eine lokale Installationsquelle bereitstellen wollen.

Office 365 Adressen über REST

Dies ist die aktuelle API und sollte seit August 2018 genutzt werden. Alle früheren Wege sollten als nicht mehr aktuell angesehen werden.

Anfang 2018 hat Microsoft einen neuen REST-Service mit JSON-Antworten für die Publizierung von Office 365 Adressen bereit gestellt. Spätestens im Oktober 2018 soll der Dienst von "Beta" in Production überführt werden, da die bisherigen URLs dann wohl entfallen sollen.

https://endpoints.office.com/version
https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a7

Als REST-API können Sie die Daten natürlich ganz einfach per PowerShell abrufen:

$o365list=Invoke-Restmethod "https://endpoints.office.com/endpoints/worldwide?tenantname=msxfaq&clientrequestid=$((new-guid).guid)"

.....
id                     : 11
serviceArea            : Skype
serviceAreaDisplayName : Skype for Business Online and Microsoft Teams
ips                    : {13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/39}
udpPorts               : 3478,3479,3480,3481
expressRoute           : True
category               : Optimize
required               : True
...

Bei meinem letzten Abruf kamen 83 Einträge zurück, deren Aufbau aber nicht immer gleich ist.. Sie können die Adressen natürlich "Filtern". Wenn ich die Daten z.B. nach dem "ServiceArea" gruppiere, sehe ich:

$o365list | group serviceArea -NoElement

Count Name
----- ----
   55 Common
    8 Exchange
    7 SharePoint
   13 Skype

Allerdings erwarte ich von einer guten Firewall oder einem guten Proxy, dass diese diese Datenquelle auch selbst einbinden können.

Office 365 IP-Adressen per HTML

Dieser frühere Weg sollte nicht mehr genutzt werden.

Microsoft veröffentlicht die Ports und IP-Adressen für Office 365 auf einer Webseite

Mit ein bisschen Powershell kann aber auch aus dieser HTML-Datei zumindest eine Liste der IP-Adressen extrahiert werden.

# Quellwebseite
$ipsourceuri = "https://support.office.com/de-de/article/URLs-und-IP-Adressbereiche-von-Office-365-8548a211-3fe7-47cb-abb1-355ea5aa88a2"

# HTML-Seite abrufen
$htmlpage =Invoke-WebRequest `
   -Uri $ipsourceuri `
   -UseBasicParsing

# Per RegEx alle IP-Adressen ggfls mit Subnet einsammlen
$iplist = ($htmlpage.content | Select-String "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" -AllMatches).matches.value

# Ausgeben
$iplist

Dies ist ein schneller und ganz einfacher Ansatz, der alle Ziffern in der Form xxx.xxx.xxx.xxx erwischt. Das müssen nicht sicher IP-Adressen sein, da auch 999.999.999.999 getroffen wird. Zudem enthält die HTML-Seite verschiedene Gruppierungen. Wer also nur die IP-Adressen für einen Dienst benötigt, müsste noch diese Abschnitte selektieren. Zudem habe ich so natürlich erst mal keine IPv6-Adressen. Es kann aber schon reichen um z.B. Änderungen an der Liste zu erkennen und einen Firewall Administrator zu informieren.

Office 365 Adressen aus XML-Datei

Dieser frühere Weg sollte nicht mehr genutzt werden.

Es geht aber noch viel einfacher. Wer genau die Seite "Office 365 URLs and IP address ranges " (https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2) liest, finden im Fließtext einen Link auf eine XML-Datei:

Office 365 Adressen per XML
https://support.content.office.net/en-us/static/O365IPAddresses.xml

Microsoft Azure Datacenter IP Ranges
https://www.microsoft.com/en-us/download/details.aspx?id=41653

Die Datei ist mit knapp 100 Kilobyte nicht mal klein. Die Struktur ist relativ übersichtlich.

Diese Datei lässt sich natürlich ebenso einfach per PowerShell abrufen. Hier ein Beispiel

[xml]$iplist = (Invoke-WebRequest `
    -Uri https://support.content.office.net/en-us/static/O365IPAddresses.xml).content

# Ausgabe aller Adressen (IPV4, IPV6 und DNS-Namen
$iplist.SelectNodes("//address")

Ausgabe der IPv4-Addressen
$iplist.SelectNodes("//addresslist[@type='IPv4']/address")

Da fehlt mir nun nur noch für die verwendeten Proxy-Server und Firewalls eine Kommandozeile um die Zielsätze automatisch zu pflegen.

Office 365 Adresse für Exchange Hybrid Mail Flow

Neben der XML-Datei gibt es eine weite Option die IP-Adressen der Datacenter-Systeme zu ermitteln. Diese werden z.B. von Exchange Online auch ausgehend genutzt und weichen etwas von der Gesamtliste ab.

Achtung:
Der Befehl "Get-HybridMailflowDatacenterIPs" ist mittlerweile als "Depreciated" gekennzeichnet.

Daher hier eher als Archiv die Ausgabe vom Nov 2020

$Session = New-PSSession `
    -ConfigurationName Microsoft.Exchange `
    -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
    -Credential (get-credential) `
    -Authentication Basic `
    -AllowRedirection 
Import-PSSession $session
$FormatEnumerationLimit =-1
$ip = Get-HybridMailflowDatacenterIPs

# Stand 29.8.2018
$ip.DatacenterIPs

65.55.88.0/24
94.245.120.64/26
207.46.51.64/26
207.46.163.0/24
213.199.154.0/24
213.199.180.128/26
2a01:111:f400:7c00::/54
23.103.132.0/22
23.103.136.0/21
104.47.0.0/17
23.103.198.0/23
23.103.200.0/21
2a01:111:f400:fc00::/54
65.55.169.0/24
134.170.140.0/24
134.170.171.0/24
157.55.133.160/27
157.56.87.192/26
157.56.112.0/24
207.46.100.0/24
134.170.101.0/24
157.56.116.0/25
157.56.120.0/25
52.100.0.0/14
207.46.108.0/25
40.107.0.0/16
40.92.0.0/14
157.56.110.0/23
216.32.180.0/23
23.103.144.0/20


Get-ReceiveConnector "Inbound From Office 365" `
| Set-ReceiveConnector -RemoteIPRanges $ip.DatacenterIP

Diese Ausgabe ist aber nicht weiter zu beachten, das Sie von Microsoft als "Depreciated" gekennzeichnet ist und in den offiziellen Quellen zusätzliche Adressen aufgeführt werden.

Ich orientiere mich daher an der offiziellen Seite bezüglich Port 25/TCP
https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#exchange-online

40.92.0.0/15  (Als Teilmenge auch in get-hybridmailflowdatacenterips enthalten)
40.107.0.0/16  (Identisch get-hybridmailflowdatacenterips enthalten)
52.100.0.0/14  (Identisch get-hybridmailflowdatacenterips enthalten)
104.47.0.0/17  (Identisch get-hybridmailflowdatacenterips enthalten)
2a01:111:f400::/48 (Obermenge von get-hybridmailflowdatacenterips))
2a01:111:f403::/48  (Nicht in get-hybridmailflowdatacenterips enthalten)

Leider konnte ich noch nicht ermitteln, ob diese Adressen auch für die CAS zu CAS-Kopplung per EWS gültig sind.

Currently, EOP accepts mail from 25 IP address ranges. By the end of September, this list will be consolidated down to 4 EOP IP address ranges. This deprecation will take place over several weeks and should be completed by the end of September 2018.
Quelle: Announcement: Deprecation of EOP Outbound IP Address Ranges
https://social.technet.microsoft.com/Forums/en-US/e493ef15-17b0-40f2-8b81-003a6f9295f9/announcement-deprecation-of-eop-outbound-ip-address-ranges?forum=onlineservicesexchange

Dies passt dann auch zu den öffentlichen Informationen und der Auflösung von "*.mail.protection.outlook.com"

BGP-AS, ASN und Whois

Während der Arbeit an der Seite ExpressRoute musste ich mich auch etwas über "BGP" informieren und habe auch hier gesehen, dass Netzwerkbereiche als "Autonomous System (AS)" zusammengefasst und mit Leitwegen versehene werden. BGP im Internet und OSPF im LAN haben schon lange RIP als Routingprotokoll abgelöst. Ein Router muss aber zu einer IP-Adresse nun erst mal das passende AS finden, um dann über den Leitweg den "Next Hop" zu bestimmen. anhand der BGP-Daten bilden sich also Gruppen von IP-Subnetzen.

Leider kann ich nichts zuverlässig sagen, dass es genau ein passendes AS für Office 365 gibt. Aber es gibt anscheinend das ASN= 8075, welches bei einer Stichprobe scheinbar alle Subnetze umfasst, die in der Office 365 IP-Liste gelistet werden. Aber sind wohl auch noch ein paar Adressen mehr drin. Dennoch ist BGP eine gute Quelle um die Zugehörigkeit von IP-Adressen zu einem Netzwerkverbund zu ermitteln. Meist sind dies Provider, oft aber eben auch große Firmen wie Microsoft, Google, Amazon etc.

Die BGP-Routen kann man sicher auch von einem BGP-Router abfragen. Dazu muss man aber so ein System im Zugriff haben und bezweifle, dass die meisten Firmen einen BGP-Router des Providers überhaupt auf dem Management-Level erreichen können. Aber es gibt ja die benannten Auskunftsdienste und diese lassen sich doch recht einfach anzapfen. So liefert RIPE.NET eine JSON-Antwort

https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS8075

Das Powershell-Skript dazu ist schnell gebaut:

# URL zur Abfrage der RIPE-Datenbank
$url = "https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS8075"

# Anfordern der Daten per REST
$json = Invoke-RestMethod -Method get -Uri $url

# Ausgabe 
$json.data.prefixes.prefix

So einfach bekommt man eine Liste der IP-Adressen zu einem Autonomous System (AS).

Konfiguration der Firewalls und Proxies

Allein die Daten zu haben ist natürlich nur die halbe Miete. Mit den Adressen muss nun natürlich auch gearbeitet werden. Hier sehe ich drei AnsatzMöglichkeiten.

  • Firewall
    Der erste Ansatz ist natürlich die Steuerung der Firewall. Wenn die IP-Subnetze der Office 365 Ziele bekannt sind, könnte ein Administrator damit vielleicht sogar automatisch Regel zu diesen Zielen konfigurieren.

Aktuell ist mir keine Firewall bekannt, die BGP-Informationen oder RIPE-Daten auswertet um über das Autonomous System (ASN) eine Filterung nach Zielen und Quellen durchzuführen.

Per Zufall habe ich aber z.B. bei einer Firma gesehen, dass ein McAfee Proxy entsprechende "predefined Sets" hat, die von McAfee wohl gepflegt und dem Kunden bereitgestellt werden.

  • Router
    Eine weitere Stelle zur Verwendung dieser Regeln kann natürlich der Router sein. Wenn Sie mehrere Wege zum Internet haben, dann können sie natürlich auch hier diese IP-Liste als Quelle nutzen, um statische Leitwege über ein anderes Interface zu routen.

Beachten Sie dabei aber, dass die Umsetzung auf offizielle IP-Adressen (NAT) erst nach dem Routing passiert, damit die Pakete dann auch mit der richtigen offiziellen Adresse ihr Netzwerk verlassen und die Rückpakete damit auch den gleichen Weg wieder ankommen.

  • Proxy Server
    Über eine WPad-Datei können Sie den Clients abhängig von den Zielen alternative Proxy Server mitgeben. So könnten sie schon auf dem Client ein Routing nach Zielen zu einem anderen Proxy eintragen, der vielleicht auch eine andere externe Internetanbindung nutzt. Allerdings ist dieser Ansatz nur bedingt tauglich, da verschiedene Dienste nicht auf IP-Adressen sondern auch FQDNs nutzen. Das kann eine Proxyerkennung zwar auch, aber nur wenn das Protokoll auch HTTP-Proxy nutzt. Einige Dienste, z.B. Audio/Video nutzen bevorzugt andere Dienste. (3478/UDP)

Wie Sie ihr Wissen um die aktuellen Office 365-IP-Adressen nun intern einsetzen, ist letztlich spezifisch für ihre Umgebung. Allgemein einsetzbare Skripte oder Tools gibt es aktuell nicht.

Vielleicht implementieren Sie ja eine Lösung, die Sie entsprechend veröffentlicht haben. Über einen Hinweis darauf freue ich mich.

Weitere Links