MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Optimize, Require, Default

Wenn Sie die Verbindung von ihrem Client zu einem Microsoft 365 Cloud Dienst optimal konfigurieren wollen, dann müssen Sie die drei Klassifizierungen verstehen und ihre Konfiguration entsprechend auslesen. Immer wieder bin ich bei Troubleshootings unterwegs und daher habe ich diese Seite geschrieben

Was bedeutet "Optimize, "Require", "Default"?

Damit sie Dienste in der Cloud nutzen können, muss eine Verbindung möglich sind. Dabei spielen DNS-Auflösung, Proxy-Server, Firewalls und NAT-Umsetzungen eine wichtige Rolle. Einige Protokolle nutzen sehr umfangreiche Portbereiche während andere nur wenige Ports ansprechen. Es gibt Dienste, die große Datenmengen übertragen und entsprechende Bandbreiten benötigen. Andere Diensten ist die Latenzzeit wichtiger ist, z.B. Telefonie. Microsoft veröffentlicht jede Menge DNS-Namen und IP-Adressen im Internet auf verschiedenen Seiten. Siehe dazu auch Office 365 Netzwerkziele.

Aber interessanter finde ich die Klassifizierung nach "Optimize, "Require", "Default" Hier ein Auszug aus einer Microsoft Folie


Quelle: What is it and how to get | BRK3040 Source: https://youtu.be/XiQwR12rkO8?t=1564  

Aber wie gehen wir nun genau mit diesen Zielen um? 

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. Meine Empfehlungen

  • Direkte DNS-Auflösung möglich
  • Routing per NAT zum Ziel
  • in der Firewall anhand der IP-Ranges erlauben
  • Optional QUIC - HTTP/3 zu ausgewählten Adressen erlauben
  • Keine TLS-Inspection (nicht möglich bei Audio/Video (RTP) oder MTLS-Verbindungen
  • Auch Sonderpakete wie UDP  (Port 3478-3481) berücksichtigen

Hier geht es um entweder zeitkritische als auch datenintensive Übertragungen 

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. Meine Empfehlungen

  • Über WPAD auf den Proxy geleitet
  • Proxy kann anhand der DNS-Namen filtern/erlauben
  • DNS-Namen kommen aus den Microsoft-Listen
  • Verkehr von Proxy zum Internet ist nicht weiter gefiltert. Die Proxy-Regeln auf DNS-Namen und URLs sind leistungsfähiger als IP-Adressen
  • Auf Authentifizierung vielleicht verzichten (oder User + Computer erlauben)
  • TLS-Inspektion optional
    Kostet mehr Rechenleistung und bedeutet mehr Aufwand aber dann kann man z.B. Caching aktivieren, um Bandbreite zu sparen und Latenz zu reduzieren
  • TLS-Inspektion Ausnahmen für login.microsoftonline.com u.a. wenn Anmeldung per Zertifikat oder NTLM-extended Protection

So können die Microsoft 365 Verkehre effektive und mit DNS-Namen erlaubt werden, was sicherer als IP-Ranges auf einer Firewall sind. 

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.

  • Alle anderen Zugriffe gehen über den Proxy
  • Unterliegen den Proxy-Filterfunktionen auf DNS-Namen
  • Authentifizierung kann erzwungen werden
  • TLS-Inspection möglich, um Content-Scan zu machen und zu Cachen

Damit stellt sich die Frage, wie wird mit all den Informationen umgehen.

DNS Namen oder IP-Range

Die von Microsoft veröffentlichten Informationen enthalten aber sowohl IP-Adressen als auch DNS-Domains. In unserer Kette von Clients zum Cloud-Service gibt es aber gleich mehrere Komponenten.

  • Direkt: DNS-Anfragen + NAT
    Wenn ein Client eine Gegenstelle direkt erreichen möchte, dann muss der auch die Adresse der Gegenstelle auflösen und dann per IP-Routing und NAT erreichen können.
  • HTTP-Proxy-Server
    Wird hingegen der "Umweg" über einen Proxy-Server gewählt, dann muss der Client nur den Proxy-Server auslösen und erreichen können. Den Umweg erkauft man sich mit mehr Bedarf an Systemen und Rechenleistung, aber gewinnt durch feinere Filter- und Inspektionsmöglichkeiten, einer Authentifizierung und Caching
  • Firewall und NAT
    Das System zwischen Internet und den internen Clients aber auch dem Proxy_Server kann DNS-Abfragen verstehen aber die meisten Firewalls steuern nur die IP-Verbindung mit SourceIP:Port und DestinationIP:Port. Manchmal schauen sie sich noch einen TLS-Handshake an, wenn nicht schon TLS 1.3 eingesetzt wird.
  • UDP und Proxy
    Einige Protokolle sind hingegen gar nicht "Proxy-tauglich", so dass dafür Lösungen gefunden werden müssen.

Erschwerend kommt dazu, dass leider nicht alle IP-Adressen und DNS-Namen in diesen Listen erscheinen und erst über eine DNS-Anfrage ermittelt werden. Microsoft bedient sich z.B. verschiedener Content Delivery Networks (CDN), bei denen eine IP-Adresse durchaus von mehreren Kunden verwendet wird. Eine Freigabe auf IP-Adresse ist hier nur bedingt sicher. Besser ist die Prüfung des DNS-Namens oder TLS-Handshake um wirklich dann nur Microsoft-Endpunkte zu erlauben.

Wenn wir nun die IP-Adressen und DNS-Namen von Microsoft in unser Schutzkonzept überführen wollen, dann müssen wir an den richtigen Stellschrauben drehen.

Other endpoints not included in the Microsoft 365 IP Address and URL Web service
https://learn.microsoft.com/en-us/microsoft-365/enterprise/additional-office365-ip-addresses-and-urls?view=o365-worldwide

Network endpoints for Microsoft Intune
https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/intune-endpoints

Mögliches Setup

Ich möchte die Verbindungen mittels "Optimize" gemäß den Microsoft Vorgaben auf dem schnellsten, kürzesten Weg vom Client zum Ziel bringen. Der Umweg über ein VPN oder Proxy-Server soll vermieden werden. Alles was Zeit kostet oder die Verbindung sogar verhindert, d.h. Authentifizierung, TLS-Inspection, Bandbreitendrosselungen etc. sollten umgangen werden. Die "Required" Vorgaben möchte "vereinfacht" zulassen, z.B. erspare ich mir die Authentifizierung, damit z.B.: auch Intune, Windows Update als "Computername$" die entsprechenden URLs erreichen können. Nur die "Default"-Ziele werden wie allgemeiner Internetzugriff behandelt.

An jeder Station kann ich unterschiedliche Schutzmaßnahmen umsetzen:

Klassifizierung Namensauflösung HTTP-Proxy Firewall/NAT

Optimize

Der Client muss die Namen der Ziele direkt auflösen können, z.B. worldaz.tr.teams.microsoft.com

Wird umgangen

Freigabe auf Ziel-IP und Port

Require

Nur Auflösung des Proxy-Servers

Der Proxy bekommt den DNS-Namen mit und baut seinerseits die Verbindung zum Ziel auf. Er kann:

  • Ziele anhand des Hostnamens erlauben (statt IP)
  • Ich verzichte auf Authentifizierung für explizit erlaubten Cloud-Dienste
  • TLS aufbrechen für Caching
    Wenn ich den Mehraufwand für eine TLS-Inspection mache, dann kann ich auch statische Inhalte cachen (Siehe auch Office 365 und Proxy Server)
  • TLS Aufbrechen für Tenant Restrictions
    Office 365 und Proxy Server
     dann kann ich auch Cachen und Header auswerten und Request modifizieren.

Die Firewall sieht hier nur Zugriffe vom Proxy-Server. Sie kann natürlich auch zusätzlich noch IP-Adressen und Ports filtern, aber so eine Doppelkontrolle würde mehr helfen den Proxy-Server selbst zu härten. Der Mehrwert einer Firewall mit IP-Adress-basierten ACLs ist in Verbindung mit einem vorgeschalteten HTTP-Proxy nur eingeschränkt

Default

Nur Auflösung des Proxy-Servers

Alle anderen Verbindungen werden auch von anderen Kunden und Diensten genutzt und sind nicht zwingend für meinen Tenant

 

Damit diese Konfiguration so funktionieren kann, muss ich natürlich drei Dinge möglichst automatisch konfigurieren:

  • Proxy-Konfiguration des Clients (WPAD)
    Der Client muss wissen, für welche DNS-Namen und IP-Adressen er welchen Proxy nutzen soll. Microsoft stellt immer mehr Cloud-Dienst auf die domain "*.cloud.microsoft" um aber es wird sicher noch einige Zeit noch andere URLs geben.
  • Proxy-Konfiguration
    Der Proxy Server selbst muss zum einen wissen, welche URLs die Clients über ihn anonym oder authentifiziert erreichen oder auch nicht erreichen dürfen. HTTP-Verbindungen kann er direkt cachen, inspizieren und Tenant Restrictions einbauen.
  • Firewallkonfiguration/NAT
    Auf dem Weg vom internen privaten Netzwerk ins Internet kann eine Firewall immer noch IP-Adressen und Ports kontrollieren. Für Audio/Video-Übertragungen, die nicht nur Microsoft Teams sondern auch andere Produkte betreffen, sollte die Firewall die entsprechenden Gegenstellen zulassen. Für die IP-Adressen eines Proxy-Servers sind entsprechende Ausnahmen ratsam.

Nutzung ohne Proxy

Die Installation und der Betrieb eines Proxy-Servers ist natürlich mit zusätzlichen Kosten verbunden und je kleiner ein Standort ist, desto teurer wird die Nutzung pro Anwender. Vorteile wie Caching haben weniger Auswirkungen, insbesondere wenn die Bandbreite hoch ist. Dann sind es eher Sicherheitsüberlegungen, die für einen Proxy-Server sprechen. Wenn Sie hier aber keinen hohen Ansprüche stellen, dann können Sie auch ohne Proxy-Server nur mit einer Firewall die Übertragungen zwischen Clients und Cloud-Diensten steuern.

Allerdings können die meisten Firewalls nur Protokolle (IP,TCP, UDP, ICMP), IP-Adressen und Ports reglementieren. Einige Firewalls können auch TLS aufbrechen und DNS-Anfragen von Clients dynamisch auf IP-Adressen mappen. Das geht oft gut aber manchmal auch nicht.

Es gibt nämlich Endpunkte, die sie noch nicht kennen oder gar nicht von Microsoft sondern anderen Anbietern eines CDN, z.B. Akamai, Cloudflare etc. dynamisch bereitgestellt werden. Da kommen sie mit statisch gepflegten IP-Adressen an ihre Grenzen und lassen dann lieber zu viel Bereiche zu. Auch Microsoft macht uns hier das Leben nicht gerade einfacher, da es nicht die große eine Liste aller Namen und IP-Adressen gibt, sondern nur die von Microsoft 365 verantworten Endpunkte enthalten sind. Dass ihr Windows Client aber auch Windows Update und andere CDNs anspricht, ist wieder in anderen Listen veröffentlicht.

Wundern sich sich daher nicht, dass eine zu strenge Firewall auch Verbindungen blockiert, die eigentlich erlaubt sein sollten.

Womit ich wieder am Anfang wäre, dass ich immer wieder bei Kunden genau solche "Verbindungsprobleme" mit Rimscout, Wireshark, Fiddler und anderen Tools nachspüre.

Firewall blockiert

Die korrekte Konfiguration ihrer Firewalls, Proxy-Server und der Clients über eine WPAD-Datei ist für die Funktion essentiell. Fehler bei der Übertragung sind oft nicht einfach zu ermitteln. Wenn ein Client per Browser z.B. auf https://teams.microsoft.com oder https://outlook.cloud.microsoft zugreift, dann "sehen" die Menschen etwaige Fehler und ein Supporter kann per "Chromium Debugger" auch sehr einfach die Verbindungen analysieren und Fehlerstellen entdecken. Das ist aber nicht der Fall, wenn die Clients ein klassisches Programm sind, z.B. Word, Excel und Zugriffe auf OneDrive oder Lizenzserver oder sogar im Hintergrund aktiv sind, wie z.B. Defender Updates, Windows Update oder Management per Intune. Hier helfen dann nur Protokolldateien und Eventlogs. Nicht immer haben Sie die glückliche Situation, dass der Zugriff "unverschlüsselt" erfolgt und sie mit Wireshark auch in dem Moment gleich den Request und den Fehler finden. Hier sehen Sie den Versuch von Windows Update eine Datei per HTTP (unverschlüsselte Verbindung) zu laden, die von der Gegenseite mit einem 503 quittiert wird.

Die IP-Adresse 146.75.118.17 ist offiziell der Rechner "dl.delivery.mp.microsoft.com" aber die Antwort in Zeile 696 kommt definitiv nicht von Microsoft, sondern einer lokalen Firewall. Nur weil die Verbindung unverschlüsselt war, konnte ich hier die Blockade des Downloads durch eine Palo Alto sehen. Wäre die Verbindung per HTTPS gesichert gewesen, könnte vielleicht ein Blick ins lokale Eventlog oder Windows Update Log helfen. Selbst auf der Firewall fallen solche Blockierungen nicht sofort auf.

Sie können ja mal den Download manuell versuchen. 

Invoke-WebRequest `
   -Uri http://dl.delivery.mp.microsoft.com/filestreamingservice/files/cec8ae1e-eb56-4b23-8045-7505c045567e `
   -OutFile c:\temp\wus.cab

Auf den Clients konnte ich früher noch ein Logging in WINHTTP.SYS aktivieren.

Weitere Links