Office 365 Ports

Wer Dienste in der Cloud nutzt, muss Ports von innen nach außen erlauben aber auch gewisse Dienste von extern erreichbar machen. Microsoft publiziert sowohl die Ports, Dienste als auch die IP-Adressen. Aber das reicht vielen Firewall-Administratoren nicht beim Planungsgespräch, weil die Angaben zu vage sind und für die Einrichtung der Regeln durchaus belastbarere Informationen zu den Diensten und Protokollen vorliegen sollen. Es ist schon klar, dass mittlerweile die meisten Dienste sich durch 443/TCP tunneln. Aber die meisten Firewalls können auch solche Protokolle betrachten und ggfls. blocken.

Firewall, NAT und Proxy

Größere Firmen setzen auch spezielle Application Proxy Server ein, die z.B. HTTPS aber auch SIP mit dynamisch erstellten vertrauenswürdigen Zertifikaten doch wieder öffnen und bewerten. Während kleinere Firmen den Zugriff aufs Internet in der Regel gar nicht beschränken und einfach per NAT die Verbindungen umsetzen, werden in größeren Firmen oft die Ports beschränkt oder sogar eigene Application-Proxyserver aufgesetzt. Da immer mehr Dienste mit allen drei Varianten zurecht kommen wollen, hat es sich schon zum Standard entwickelt, Daten einfach in 443/TLS zu tunneln, also so zu tun, als wenn hier nur "gesurft" wird. Ausgehend 443 ist meist offen und selbst Proxy Server überbrücken TLS-Verbindungen oft einfach nur, weil sie in der Regel nicht tiefer hinein schauen dürfen. Technisch kann man als Firma schon auch SSL-Verbindungen inspizieren.

In der Gegenrichtung muss eine Firma mit Office 365 aber auch eventuell Dienste veröffentlichen, z.B. ADFS-Server oder für den Hybrid-Betrieb entsprechende Exchange CAS-Server und Lync Dienste. Auch hier kann man als kleine Firma vieleicht einfach mit Reverse-NAT arbeiten. Webdienste hingegen stellt man doch lieber per Reverse Proxy bereit. Dies gilt ins besondere, wenn man die URLs besser absichern will oder intern eine Lastverteilung auf mehrere Server vornehmen muss.

Der Überblick

Ich habe mal versucht alle Office 365 Dienst auf der rechten Seite aufzulisten und die verschiedenen Clients auf der linken Seite, wohlwissend, dass sich Zugriff und Dienste sehr schnell auch wieder ändern können.

Der Weg von innen Richtung Cloud kann in der Regel über einen HTTP-Proxy oder NAT erfolgen. Nur wenn gesonderte Relaysysteme erforderlich (z.B. ADFSProxy, Lync Edge) oder ratsam (z.B. Exchange Reverse Proxy) sind, habe ich diese auf dem roten "Relay"-Bereich platziert.

Man kann recht gut sehen, dass in den meisten Fällen "443" zum Einsatz kommt und ein paar "exotische" Dienste wie IMAP/POP noch andere Ports nutzen. Auch wer ein VPN in die Azure-Cloud aufbauen will, braucht unter anderem zusätzliche Ports und Lync versucht neben 443 natürlich auch High Ports (50.000-50059) und 3478/UDP.

Weitere Links