Lync Edge - die sichere Außenverbindung

So verbinden Sie ihre Skype for Business mit einem Edge Server mit anderen Firmen, Office 365 Online und erlauben externe Teilnehmer.

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/

Achtung
Ein Lync Edge darf nicht gegen einen OCS2007 R2 Backend Server mit Benutzern betrieben werden. Dies ist nicht unterstützt. Einige Einstellungen für Benutzer greifen z. B. nicht, d.h. Benutzer ohne "Remote Access"-Recht können dann dennoch von unterwegs arbeiten etc. Der Edge darf erst dann installiert werden, wenn KEIN OCS 2007R2 installiert ist. Während der Migration muss daher ein OCS Edge weiter betrieben werden.

Achtung
Die Ports und Beschreibungen sind noch nicht auf Lync 2013 angepasst. So fehlt z.B. noch der XMPP Port.

Achtung: Microsoft Teams nutzt die Port 3478-3481. Ihr Edge muss ausgehend auch diese Ports erreichen können.

Die Edge-Rolle zwischen OCS und Lync hat sich ein wenig verändert. Zum einen hat die Möglichkeit eines DNS-Round-Robin als Verfügbarkeitsoption den Bedarf an LoadBalancer reduziert und zudem wurden einige Protokolle verändert. Auf der anderen Seite gibt es neue Zugänge wie z.B. SimpleURL und auch bekannte Funktionen wie Adresslistdownload, Gruppenauflösung etc. benötigen neben dem Edge noch einen Reverse Proxy. Das muss nicht immer ein ISA/TMG-Server sein. Was letztlich bereit zu stellen ist, ist ein Reverse Proxy für HTTPS mit der gewünschten Schutzfunktion.

Sehr schöne Übersicht der Ports und IP-Adressen
Edge Server scenarios in Skype für Business Server 2015
https://technet.microsoft.com/en-us/library/mt346416.aspx

Skype for Business Protocol Workloads Poster
https://www.microsoft.com/en-us/download/details.aspx?id=46448

Visio-Diagramm für Lync 2013 Kommunikationsports
http://www.lync-solutions.com/Documents/Lync_2013_protocol_poster_v6_7.pdf

Microsoft Lync Server 2010 Protocol Workloads Poster
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ad8ff3fb-014e-4fd7-8003-436d896ab0c6

Für Windows Phone 7 gibt es eine Lync Protocol App zur Anzeige der Ports
Lync Protocol&Ports | zune://navigate/?phoneappid=209f1437-ab9d-40f3-860f-3194b3b269fb

Lync Topology

Es erklärt sich von selbst, das Sie den "Edge-Server" natürlich in der Lync Topologie eintragen müssen. Dazu zählen die interne und die drei offiziellen Namen und Ports, die NAT-Einstellung und natürlich der "Next Hop"-

Den "Next Hop" auf dem Edge können Sie aber eigentlich nicht vergessen, da der Parameter verpflichtend ist. Allzu oft wird aber auch vergessen, die Zuordnung des Edge am Standard Server bzw. Enterprise Pool vorzunehmen.

An diesem Server muss der Client nämlich auch verwiesen werden, damit er bzw. der RTP-Datenstrom, den Weg nach draußen kennt.

Vergessen Sie dabei nicht, dass Sie auf der Site auch die Federation Route entsprechend eintragen.

Windows Basis Installation

Klar ist, dass der Lync Edge auf einem Windows 2008/20008R2-Server installiert werden muss. Er kann sogar Mitglied der Domäne sein, wenn Sie ihn per Gruppenrichtlinien verwalten wollen. Oft steht der Edge-Server aber auch in einem eigenen Subnetz und dann macht man sich es einfacher, wenn er einfach als Standalone-Server vor sich hin arbeiten. Allerdings sind die entsprechenden Ports zu öffnen, was in der Folge beschrieben wird. Aber Ports alleine sind es nicht.

  • IP-Leitwege
    Per Default werden alle IP-Pakete in das Internet geroutet. Das ist für Federation und external Access natürlich auch erforderlich. Dennoch muss der Edge natürlich auch alle "internen" Netzwerke erreichen können. Wenn dies nicht über das "Default Gateway" möglich ist, dann müssen Sie statische Routen addieren. (z.B. NETSH oder ROUTE ADD

Route ADD ist unter Windows 2008 und höher nicht mehr empfohlen. Nutzen Sie stattdessen netsh (IP Routing commands  http://technet.microsoft.com/en-us/library/cc783403(WS.10).aspx)

REM: Hier Beispiele für die "privaten" Netzwerke. x.x.x.x ist der interne Router und "LAN" der Kartenname
netsh interface ipv4 add route 10.0.0.0/8 Interface=LAN nexthop=x.x.x.x store=persistent
netsh interface ipv4 add route 172.16.0.0/12 Interface=LAN nexthop=x.x.x.x store=persistent
netsh interface ipv4 add route 192.168.0.0/16 Interface=LAN nexthop=x.x.x.x store=persistent
  • DNS-Auflösung
    Weiterhin muss der Server natürlich die Federation-Partner auflösen können. Ehe Sie nun aber als DNS-Server einen externen Server eintragen, dann sollten Sie beachten, dass der Edge auch den "Next Hop" und alle anderen internen Lync-Server auflösen und erreichen muss. Auch wenn der Edge zwei Netzwerkkarten hat, sollten Sie nicht auf der externen Karte einen externen DNS-Server eintragen und intern den internen DNS-Server. Der TCP-Stack addiert einfach diese Einträge und entsprechend landen einige externe Anfragen intern und interne auch Extern. Beides geht nicht.
    Speziell wenn der Edge auch noch Mitglied der Domäne ist, sollte er immer einen DNS-Server fragen, welcher auch AD-Informationen bereit stellen kann. Dieser muss dann eben per Forwarder auch die externe Auflösung erlauben.

Hinweis:
Der Edge fragt auch die DNS-Records _sipfederationtls._tcp.<eigenedomain.tld> ab. Gerade beim Einsatz mit "Split-DNS", wenn der Edge noch die internen Server fragt, muss der Eintrag also auch intern vorgenommen werden. Wenn Sie dann noch intern "sip.<eigenedomain.tld>" verwenden, dann hilft nur einen HOSTS-Datei auf dem Edge, damit der Edge die externe offizielle Adresse in Erfahrung bringen kann.

Microsoft rät davon ab, dass der Edge Server den internen DNS-Server fragt. Systeme in einer DMZ sollten nie nach intern fragen, sondern nach Extern. Die wenigen Server, die intern über Namen erreichbar sein müssen, können über HOSTS-Einträge gepflegt werden.

  • DNS-Registrierung
    In dem Zuge sollten Sie auch noch mal einen Blick auf die Einstellungen der Netzwerkkarten tätigen. Die interne Netzwerkkarte mit der einen internen IP-Adresse kann sich gerne am internen DNS-Server registrieren und eintragen.

Die externe Netzwerkkarte dürfen sich nicht registrieren.
Die drei externen Adressen des Edge sind in der Regel von intern nicht zu erreichen und erwarten auch keine Daten "von innen". Wenn ein interner Frontend mit dem Edge über dessen externe Adresse sprechen möchte, dann wir er dort keine Antwort bekommen.

  • Zertifikate und CRL
    Da die Kommunikation zwischen internen Lync-Servern und Edge per TLS gesichert und verschlüsselt wird, muss dieser auf der internen Netzwerkkarte ein Zertifikat haben. Wird das von einer internen CA ausgestellt, dann sollten Sie bei einem Standalone Server nicht vergessen, dass die Stamm-CA als vertrauenswürdige "Root" addiert werden. Weiterhin sollten Sie sicherstellen, dass der Edge-Server per HTTP die entsprechenden CRL der CAs erreichen kann.

Hinweis:
Der Access Edge sendet bei einer SIP-Verbindung zu einem Federation Partner sein Zertifikat mit. Die andere Seite nimmt die Verbindung nur an, wenn Sie dem Aussteller des Zertifikats vertraut. Leider ist die Liste der Stammzertifikate in Windows 2008 deutlich reduziert und das dynamische Nachladen dem Server nur möglich, wenn er die Microsoft Server per HTTP erreichen kann.
Siehe auch Rolle der CA
Certificate Support and the Update Root Certificates Component
http://technet.microsoft.com/en-us/library/bb457160.aspx
http://technet.microsoft.com/en-us/library/cc733922(WS.10).aspx
Weiterhin können zu viele Stammzertifikate einen Bufferüberlauf verursachen
Siehe 2464556 TLS client authentication fails between Unified Communications peers with a logged Schannel warning

Update your firewall now with this new CRL endpoint
http://blogs.technet.com/b/lync/archive/2014/04/16/update-your-firewall-now-with-this-new-crl-endpoint.aspx

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"SendTrustedIssuerList"=dword:0
  • NTP
    Zertifikate sind nur in einer bestimmten Zeitspanne Gültig. Daher muss auch der Edge-Server eine korrekte Zeit haben
  • Windows Features installieren
Add-WindowsFeature `
   RSAT-ADDS, `
   NET-Framework-Core, `
   NET-Framework-45-Core, `
   NET-Framework-45-ASPNET, `
   Web-Net-Ext45, `
   NET-WCF-HTTP-Activation45, `
   Windows-Identity-Foundation, `
   Telnet-Client `
   -Source D:\sources\sxs

Wenn all das gewährleistet ist, dann kommt natürlich noch die Einrichtung der Firewall bezüglich der Verbindungen. Am besten laden Sie sich das folgende Visio-Sheet herunter und drucken es aus.

Microsoft Lync Server 2010 Protocol Workloads Poster
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ad8ff3fb-014e-4fd7-8003-436d896ab0c6

Installation

In den seltensten Fällen ist ein Edge Server Mitglied der Domäne. So kann der Installer natürlich nicht per LDAP im AD den CMS-Server finden und sich die Daten direkt holen. In diesem Fall müssen Sie die Konfiguration auf einem Server in der Topologie in eine ZIP-Datei exportieren:

export-csconfiguration -filename c:\to_edge.zip

Diese Datei übertragen Sie dann auf den Lync Edge Server und starten das Setup. Hier werden Sie dann gefragt, wo die Datei zu Installation liegt. Nach der Installation selbst erfolgt der weitere Abgleich dann wieder per HTTPS auf 4443, d.h. der interne Lync CMS-Master sendet die Update auf den EdgeServer per HTTPS auf dessen WebService auf Port 4443.

Externe Kommunikationen

Der Edge-Server ist in den meisten Fällen nicht viel mehr als ein "intelligenter Proxy", der auf Applikationsebene die Protokolle kennt, die zwischen intern und extern übertragen werden. Der Edge bedient dabei drei Zugänge, die jeder für sich eine eigene IP-Adresse benötigen. Es sind auch Konfigurationen möglich, bei denen die drei Dienste auf einer IP-Adresse mit unterschiedlichen Ports laufen, aber dies schränkt oft die Kompatibilität mit anderen Servern ein.

Rolle Ports Beschreibung

Access
Edge

5061/TLS
443/HTTPS

SIP-Verkehr wie Status, Einladungen und die ersten Message einer Kurzmitteilungen

WebConf
Edge

443/TLS

Der Name "WebConf" ist irreführend, da es eigentlich nicht viel mit "Web" zu tun hat. Intern heißt der Dienst "RTCDATAPROXY", was viel besser die Funktion beschreibt. Es ist ein Application Proxy für RTC-Daten

AV Edge

443/TLS
50000-59999 UDP
50000-59999 TCP
3478/UDP

Als "Audio/Video"-Edge ist der Dienst mit einer breiten Portrange dafür zuständig, Audio und Video-Nutzdaten zwischen den Internet und Intern zu übertragen. Das bedeutet z.B. dass alle internen LYNC-Clients, die mit externen Lync Clients oder Federation-Partnern A/V machen, mit diesem Edge sprechen, sofern es keine 3+ Konferenz über die MCU auf dem Frontend ist.

Office 365 hat die Ports noch enger gefasst:

Lync Online Media Port Changes Offer Better Bandwidth Management
http://blogs.technet.com/b/nexthop/archive/2013/07/03/lync-online-media-port-changes-offer-better-bandwidth-management.aspx
Audio: 50000-50019 UDP
Video: 50020-50039 UDP
Audio: 50040-50059 UDP

AV Edge

3478-3481/UDP

Wenn Sie per Federation mit Microsoft Teams telefonieren wollen, dann muss ihr Edge Server ausgehend auch diese Ports beim Microsoft Teams Transportrelay erreichen können.

In Lync 2013 scheinen die High-Ports komplett zu entfallen, wenn auch die Gegenseite Lync 2013 hat.
Quelle: Port Summary - Single Consolidated Edge with Private IP Addresses using NAT (http://technet.microsoft.com/en-us/library/gg425891.aspx)

Nicht vergessen werden darf eine vierte Kommunikation, welcher per HTTPS mit dem Frontendpool am Edge-Server vorbei erfolgt und typischerweise über einen Reverse Proxy bereit gestellt wird.

Rolle Ports Beschreibung

Reverse
Proxy HTTPS

443/HTTPS

Diese Rolle läuft NICHT auf dem Edge sondern ist ein eigenes System und stellt den Zugriff der externen Clients auf Webservices bereit. Und die bieten ein sehr umfangreiches Leistungsspektrum.

  • Herunterladen von Meeting-Inhalten
  • Auflösen von Mitgliedschaften in Gruppen
  • Herunterladen von Offline Adressbüchern
  • Zugriff auf den Lync WebClient
  • Zugriff auf die "/Dialin"-Konferenz Seite
  • Zugriff auf "Location Information Services" (LIS)
  • Device-Update für externe Telefone und Clients

Ein Blick auf den internen IIS zeigt all diese virtuellen Verzeichnisse

Es ist also absolut erforderlich, diese Komponente bereit zustellen, wenn Sie nur eine der Funktionen nutzen. Zugriffe werden nach intern auf den Frontend Server (nicht auf einen ebenfalls vorhandenen Directory weiter gegeben. Hochverfügbarkeit ist nicht per DNS sondern nur mit Load Balancern möglich

HTTPS SimpleURL

443/HTTPS

Parallel dazu gibt es natürlich noch die "SimpleURLs" für die Einladung zu Meetings und Anzeige von Einwahlnummern, die zwar vom gleichen Webserver bereit gestellt werden, aber durch einen eigenen Namen und URLs oft getrennt zu betrachten sind.

HTTP

80/HTTP

Adresse zum Download der Meeting Addins für anonyme Teilnehmer.

Nicht alle Dienst, die auf Port 443 arbeiten müssen darüber zwingend "HTTPS" sprechen.

Interne Kommunikationen

Gerne wird vergessen, dass der Edge natürlich auch intern Verbindungen aufbauen. Und damit ist nicht nur die Verbindung zum "Next Hop", also dem Standard Server oder Frontend Pool gemeint, sondern auch alle Clients. Wenn nämlich z.B. per Federation zwei Partner von ja intern und extern miteinander Audio/Video machen, dann geht das NICHT über den Frontendpool, sondern der Interne Client spricht direkt mit dem Edge.

Die Lync Edge Rolle ist die "Application Firewall" für die Lync Kommunikation. Auch wenn Sie den Server noch mal durch eine Portfilter-Firewall geschützt in andere Netzwerke stellen, so kann keine Firewall sinnvoll die Datenströme inspizieren, da alles per TLS verschlüsselt ist. Viel mehr kann z.B.: die Checkpoint SmartScreen die Funktion behindern und stören.
Aus meiner Sicht ist es relativ unkritisch, das interne Netzwerk des Edge-Servers auch in das interne LAN zu stellen, da nicht nur die internen Lync-Server sondern auch alle Clients immer dann eine Verbindung zum Edge-Server aufbauen, wenn Sie mit externen Partnern kommunizieren. Insofern ist das Firewall-Regelwerk nach innen sehr breit zu fassen.
ähnlich der Diskussion, ob ein ISA/TMG Domainmitglied sein sollte oder nicht, bin ich eher ein Fürsprecher, den Edge-Server als Domainmitglied über Gruppenrichtlinien und zentrale Verwaltung zu betreiben statt einen losgelösten Standalone-Server zu nutzen.

In Umgebungen, in denen der Edge aber nun in einer DMZ steht und eine Firewall den Edge auch gegen interne Zugriffe absichert, müssen die erforderlichen Ports dann freigeschaltet werden. Zudem muss die interne IP-Adresse des Edge Servers auch von allen Netzwerken intern erreichbar sein. Dies bedeutet:

  • IP Routing
    Beachten Sie, dass der Edge nicht nur mit den Lync Servern kommuniziert, sondern auch mit allen Clients
  • Namensauflösung
    Auch wenn der Edge per Default die meisten Namen nach extern auflösen wird, muss er doch die internen Lync-Server auflösen können

zudem sind natürlich einige Ports zu öffnen. Das können Sie gut sehen, wenn Sie auf einem PC mit NetMon 3 o.ä. einfach mal die Verbindungen mitschneiden

Bitte nicht verwirren lassen. Die Kommunikation wird immer vom Client auf den Edge-Server aufgebaut.

Source Ziel:Port Protokoll Beschreibung

Edge

NetHop:5061/TCP

SIP/TLS

Der Standardport für die Kommunikation

Lync CMS

Edge:4443/TCP

Lync Replication

Über diesen Port sendet der interne CMS-Server KonfigurationsÄnderungen an den Edge-Server, der diese in seine lokale SQL-Datenbank überträgt.

Client und Frontend

Edge: 443/TCP
Edge 3478/UDP

STUN
STUN

Alle Clients, die mit externen Personen z.B. telefonieren, Desktop-Sharing etc. machen, sprechen direkt mit dem Edge-Server.
Auch die Frontend-Server benötigen diese Ports, z.B. wenn Konferenzen mit externen Teilnehmern stattfinden

Frontend

Edge:5062/TCP

SIP/MTLS

A/V Authentication Service

Frontend

Edge:8057/TCP

PSOM

DataMCU / DataEdge / Port 8057

Adminclient

Edge:50001/TCP
Edge:50002/TCP
Edge:50003/TCP

CLS

Lync 2013 CommonLogSystem zur Fehlersuche von dem Client, auf dem CLSController.exe gestartet wird.

Reverse Proxy

Frontend-Pool:4443/TCP

HTTPS

Zugriff auf die "externe Webseite" auf dem FE-Pool

Port-Diagramm

Kurz gefasst, sind es z.B. folgende Kommunikationskanäle:

Wenn Sie sich mal die AVEdge-Anforderungen nach extern anschauen, dann sehen Sie einen Pfeil mit "ANY", der mit einem Stern gekennzeichnet ist. Eigentlich soll der AVEDGE dies nicht benötigen, aber ich habe schon erlebt, dass externe Clients einen Port <50000 geöffnet haben, auf den dann der AVEDGE gehen sollte. In der Microsoft Dokumentation steht dazu auch nur:

Regarding the 50,000-59,999 port range, the best practice für Lync Server 2010 is to open it outbound, to "Any" für RDP/TCP für the A/V Edge external interface if corporate policy allows.
Determining External A/V Firewall and Port Requirements (http://technet.microsoft.com/en-us/library/gg425882.aspx)

Die Öffnung der Port 50.000-59.999 ist kein Sicherheitsproblem, da die Ports vom Edge immer nur kurz für bekannte Verbindungen geöffnet werden. Wenn diese Ports aber geschlossen sind, dann werden die Pakete zwischen den Edge Servern über 3478/443 getunnelt, was mehr Latenzzeit und mehr Last auf dem Edge bedeutet.

Achtung: Bei Federation mit Microsoft Teams kommen auch die TURN-Ports 3479, 3480 und 3481 zum Einsatz. Daher der gesonderte blaue Pfeil mit dem Teams Icon. Siehe auch Vorbereiten des Netzwerks Ihres Unternehmens für Microsoft Teams (https://docs.microsoft.com/de-de/microsoftteams/prepare-network)

Insofern habe ich mir angewöhnt, dass der AVEDGE nach außen nicht weiter beschränkt ist.

Edge und weitere Firewall

Windows 2008 und 2008R2 bringen ja schon eine ganz gut einstellbare lokale Firewall mit sich, die man aber natürlich auch einschalten sollte. Lync als Windows 2008-Anwendung trägt bei der Installation eine ganze Menge von Regeln ein, die in einer eigenen Gruppen zusammengefasst sind. Hier ein Überblick.

Die ersten 5 Regeln erlauben eingehende Daten auf die entsprechenden Dienste. Etwas irritierend ist natürlich, dass die Ports auf "Any" stehen. Aber hier vertraue ich mal darauf, dass die Microsoft Entwickler schon dafür gesorgt haben, dass ein anderes als das hinterlegte Programm davon eben nicht profitieren kann.

Etwas gefährlich ist aber die Regel "CS System", welche als Programm zwar "System" hat, aber ansonsten alles erlaubt. Nachgeforscht habe ich hier deswegen, da ich auch mal einen Edge Server direkt am Internet betrieben habe und von außen per RDP mich hätte anmelden können. Diese Art Remote-Zugang möchte ich natürlich nicht haben. Und das passiert so.

  1. Die Regel erlaubt eingehende Verbindungen auf "System", wenn der entsprechende Prozess auch Daten annimmt.
  2. RDP ist per Default ausgeschaltet
    Aber viele Administratoren schalten es natürlich ein um ihre Server zu verwalten
  3. Durch das Einschalten von RDP wird auch eine Firewall-Regel angelegt, die eingehende Verbindungen auf 3389 ermöglicht.
    Allerdings weißt Microsoft darauf beim Aktivieren hin und sie können die Regel natürlich anpassen.
  4. Sie passen die RDP-Regel z.B. an, damit nur interne Clients auf die interne IP-Adresse zugreifen können
  5. Sie testen und extern und sind erstaunt, dass der Edge dennoch von extern erreichbar ist !!!

Die "CS System" Regel erlaubt dies. Erst eine ""Blockiere RDP von Extern"-Regel würde den Zugriff auch dann unterbinden. Das ist zumindest eine Abhilfe.

Bitte schützen Sie ihren Edge auch von extern durch eine Firewall. Das entspricht dann auch eher dem 4-Augen-Prinzip. Ein einfacher Portfilter mittels Zugriffslisten auf dem Router reicht ja schon aus.

Es ist sehr einfach per DNS-Abfrage auf "sip.<ihre domain> die IP-Adresse des Edge zu erhalten und dann per RDP sie einfach zu ärgern.

Edge Pool

Für eine höhere Verfügbarkeit können mehrere Edge Servers als Pool verschaltet werden. Empfohlen ist dabei die Verteilung der Zugriffe über DNS-RoundRobin. Alternativ kann die Verteilung durch Loadbalancer erfolgen, die dann aber intern ebenfalls per LB verteilt werden müssen. Ein Loadbalancer ist immer dann erforderlich, wenn z.B. OCS-Clients bedient werden, die kein DNS-RoundRobin erlauben. Zudem sind einige Dinge zu beachten:

  • AV-Edge Zertifikat
    Das Zertifikat auf dem AV-Edge muss auf allen Servern des Pools identisch sein. Die Publickey/Private-Key Daten werden ausschließlich dazu genutzt die MRAS-Tokens zu erzeugen. Da ein Client aber ein MRAS-Token von einem Edge bekommt aber bei der Nutzung von STUN/TURN bei einem anderen Edge des Pools landet, muss dieser das gleiche Zertifikat nutzen. Ansonsten kann es die Credentials nicht verifizieren.
  • LB Afffinity
    Seit Lync 2013 ist "DNS RoundRobin" das empfohlene Verfahren. Sollten Sie aber dennoch einen Hardware Loadbalancer für Edge einsetzen, dann achten Sie darauf, dass Verbindungen von einem anderen System anhand der Source-IP auch immer beim gleichen Edge ankommen..
  • Hairpinning und NAT
    Denken Sie an den Sonderfall, dass zwei Endpunkte beide je einen anderen Edge-Server in ihrer Umgebung nutzen können. Wenn hier dann per ICE eine "TURN-Verbindung" ausgehandelt wird uns sie die Edge-Server hinter NAT verbergen, dann muss der eine Edge-Server die öffentliche IP-Adressen des anderen Edge-Servers erreichen können und umgekehrt. Ansonsten funktioniert Audio/Video etc. nicht. Dieser Fehler ist sehr schwer zu finden.

Microsoft Dokumente und Referenz-Implementierungen

Wildcard auf Edge Server

OCS 2007 R2 unterstützt offiziell keine "Wildcard-Zertifikate". Erst mit Lync wird die möglich sein, aber auch nur, wenn alle Gegenstellen ebenfalls Lync verwenden.

Wildcard Zertifikate erscheinen vielen Administrator als ultimative Lösung. Schließlich muss man sich nicht auf Namen festlegen und kann über Hostheader selbst bei Verwendung von SSL mehrere Webseiten und Namen unter einer IP-Adresse betreiben. Auch wenn diese Zertifikate mehr kosten, so sind sie doch sehr flexibel einzusetzen.

Auf der anderen Seite nutzen immer mehr Protokolle die Möglichkeit, dass sich die Gegenstellen gegenseitig identifizieren. Dazu ist es aber normal der Fall, dass der angesprochene Servername auch im Zertifikat enthalten ist. Wenn ein Client einen Server unter seinem Namen anspricht und dann aber ein Zertifikat "*.firma.tld" bekommt, kann darüber schon noch hinweg sehen. Anders sieht es aber aus, wenn der Client sich selbst am Server ebenfalls mit einem Zertifikat ausweisen muss. Er kann hier nur sein "*.firma.tld"-Zertifikat vorweisen. für die Gegenseite ist es dann erst mal schwer daraus den Partner zu ermitteln. Erst wenn der SSL-Handshake aufgebaut ist, können im Nutzdatenstrom dann weitere Informationen ausgetauscht werden. OCS 2007R2 hat diese Intelligenz noch nicht, so das hier noch nicht mit SAN-Zertifikaten gearbeitet werden kann.

Aber selbst mit Lync sind Wildcard-Zertifikate zwar möglich, aber mit Einschränkungen verbunden:

  • Wildcard auf Frontend/Pool
    Dies ist supportet, aber da LCS und OCS dies nicht unterstützen, sollten Sie dies erst planen, wenn wirklich alle Lync einsetzen. Das Zertifikat auf dem FE ist aber sowieso in fast allen Fällen ein internes Zertifikat, so dass auch mehrere Namen kein echtes Problem sind und keine Kosten entstehen.
  • Wildcard auf dem Edge
    Normalweise benötigt der AccessEdge und der DataEdge ein offizielles Zertifikat. Wildcards sind seit Lync 2010 möglich aber unterliegen einer wichtigen Einschränkung: Nicht alle Gegenstellen reicht das aus, insbesondere da sich damit die Server untereinander auch authentifizieren. OCS-Gegenstellen haben damit z.B. das Problem dass ein Rechner namens "sip.netatwork.de" ankommt, sich aber mit "*.netatwork.de" ausweist. Insofern funktionieren Wildcard-Zertifikate auf dem Edge nur, wenn die Gegenstellen Lync betreiben
  • Edge auf dem internen Edge
    Es ist möglich aber aus meiner Sicht macht es nicht wirklich Sinn. Hier können Sie einfach ein internes Zertifikat verwenden.
  • Phone Client
    Ein echtes "Problem" gibt es aber mit den Telefonen (Aastra, Polycom), die keine Wildcard-Zertifikate unterstützen. Relevant sind hierbei die Namen, die per DNS Autokonfiguration mitgegeben werden. Diese Namen müssen im SAN-Zertifikat enthalten sein.

Auch wenn also ein Wildcard-Zertifikat auf der einen Seite viel Arbeit sparen kann, so bleibt es ein kniffliges Thema in einigen Randbereichen und erfordert einige Tests.

Private Zertifikate auf Edge Server

Erst mal ist ein Zertifikat auch nur ein Zertifikat und genau genommen hindert Sie niemand daran auch auf den externen Adressen erst mal private Zertifikate zu nutzen. Schließlich können Sie dies ja auch als "Closed Federation" ansetzen und ihre Partner auffordern, ihren privaten Zertifikaten oder der ausstellenden privaten CA zu vertrauen. Das funktioniert sogar zwischen zwei Partnern einer Partnerschaft. Und ihre eigenen Client können, sofern Sie der RootCA als Domainmitglied vertrauen, auch von extern arbeiten. Allerdings sollten Sie zwei Dinge beachten.

  • Vertrauen und CRL
    Welchen Eindruck macht es für einen Partner, wenn Sie ihn auffordern eine ihm völlig unbekannte RootCA zu vertrauen. Hinzu kommt, dass Sie ihre CA dann "richtig" betreiben müssen und dazu gehört auch die Bereitstellung eines CRL im Internet
  • Federation-Clients im Internet
    Übersehen wird auch gerne, dass ein Anwender einer Partnerfirma nicht immer hinter dem Edge-Server versteckt sind. Wenn Sie dann aber unterwegs mit ihnen kommunizieren, dann bekommen Sie direkt das Zertifikat. Dann fällt auf, wenn auch die Clients des Kunden nicht ihrem privaten Zertifikat vertrauen.

Und ob dies es dann wert ist, das Geld für offizielle Zertifikate zu sparen, sei mal dahin gestellt. Nur auf dem AVEDGE können Sie ein privates Zertifikat verwenden.

DoS auf Benutzerkonten

Eine normale Funktion des Edge-Servers ist die Anmeldung von Anwendern von Extern. Wer aber die Konfiguration der Client über DNS-Einträge automatisch macht, zeigt damit auch möglichen Angreifern, wie Sie per SIP mit Anmeldung sogar Konten sperren können. Aber selbst eine manuelle Konfiguration ist kein Schutz. Es "kostet" einen Angreifer zu wenig, die IP-Subnetze eines möglichen Ziels in Erfahrung zu bringen und Port 5061 oder 443 zu "proben".

Das Lync Team hat sich dieser Problematik schon mal für den Edge-Server angenommen, welcher als Einfallstor denkbar ist.

Aus meiner Sicht greift dies aber zu kurz, da auch Lync andere Dienste wie Autodiscover, EWS nutzt und auch die Lync Webservices per HTTPS mit Authentifizierung angesprochen werden. Eigentlich wäre es an der Zeit, dass die Domaincontroller, welche letztlich die fehlerhaften Anmeldungen protokollieren und das Konto sperren, dies etwas feiner Abstufen und erst mal Fehlversuche von den Clients bzw. Servern blocken und bei wiederholten Fehlversuchen das Konto dann doch sperren. Siehe auch DoS mit Account Lockout

ICE, STUN und TURN

Die quasi wichtigste Funktion des Edge-Servers ist die sichere Verbindung für Audio und Video. Nun ist es aber gerade im Internet üblich, dass Clients sich hinter einen NAT-Router verbergen. NAT schützt in gewisser Weise den Client, da eingehende Pakete nur als Antwort auf eine ausgehende Verbindung möglich sind. Damit wird es aber eigentlich unmöglich, dass ein Client hinter einem NAT-Router angesprochen wird. Ein "Anruf" würde daher ins Leere laufen, weil der Audiokanal zum Endgerät nicht aufgebaut werden kann.

Wer SIP etwas kennt weiß, dass jeder Client sich bei einem SIP-Registrar anmelden und damit eine ausgehende Verbindung aufgebaut wird, auf die der SIP-Registrar antworten kann. Über diesen Weg wird auch in einem "Session Description Packet" (SDP) ausgetauscht, wie die Partner miteinander kommunizieren können. Dazu müssen die Partner aber erst mal ermitteln, wie sie erreichbar sind. Und mit Lync gibt es da eigentlich drei mögliche Verbindungen

  • Die eigene direkte IP-Adresse
    Der Lync Client nimmt alle ihm bekannten lokalen IP-Adressen und öffnet dort Ports für eingehende Verbindungen. Diese Kandidaten sind ideal und kommen z.B. bei einer internen Kommunikation zum Einsatz
  • Externe Adresse des Routers
    Der Lync Client baut ausgehend Verbindung zu einem STUN-Server auf. Diese "sieht" nun die externe IP-Adresse:Port, die der NAT-Router verwendet. STUN sendet diese Informationen an den Client zurück. Der Klient kann nun auch diese meist offizielle Adresse und Port als "Kandidat" aufführen. In vielen Fällen leitet ein Router nämlich Pakete an diese Adresse:Port-Kombination an den internen Client weiter.
  • TURN-Tunneladresse
    Mit dem Edge kann der Client aber auch einen Tunnel auf den AVEDGE über Port 3478/UDP aufbauen. Der Edge ist ja extern erreichbar. Der Edge reserviert nun von seiner Portrange 50000-59999 Ports und bietet diese dem Client an, der nun die "AVEDGE externer IP:Port" als weitere Kandidaten aufnimmt.

Dies machen beide Clients und diese Kandidaten werden als SDP im SIP-Paket ausgetauscht. Dann versuchen die Clients miteinander sich irgendwie Pakete zu senden und sich zu erreichen. Das ganze ist natürlich mit Tokens abgesichert und individualisiert, so dass der Client "merkt", über welchen Weg Daten der Gegenstelle abkommen. Die beste mögliche Verbindung wird dann per SDP ausgetauscht und genutzt. Das ganze passiert übrigens schon gleich nach dem INVITE und ist als "Early Media" oft schon abgeschlossen, ehe ein Anwender den Ruf annimmt.

DNS-Auswertungen

Über dass Skype for Business Monitoring können Sie eigentlich sehr gut ermitteln, welche Clients mit welchen anderen Domänen wie intensiv kommunizieren. Allerdings brauchen Sie dazu natürlich die CDR/QoE-Rolle mit einem SQ-Server. Gerade kleinere Umgebungen sparen sich diese Komponente. Dennoch können Sie auch per DNS-Abfragen auf dem Edge-Server zumindest erste Rückschlüsse auf die Nutzung ziehen. Hier ein paar Beispiele:

# Listet alle bestehenden Verbindungen zu anderen Server. Leider ohne 
Get-NetTCPConnection -RemotePort 5061

Leider enthalten wir hier so keine Information über die Datenmengen. Das ist dann eher wieder eine Aufagbe für NetFlow,SFlow und Co

Auch die DNS-Auflösung und der DNS-Cache kann eine interessante Quelle sein

# listet alle DNS-Einträge aus dem Cache
Get-DnsClientCache -RecordType "SRV" -RecordName "_sipfederationtls._tcp.*"
 
# Nun mit aufbereitung nach Domainname
 
Get-DnsClientCache -RecordType "SRV" -RecordName "_sipfederationtls._tcp.*" | select {$_.name.substring(23)},{$_.data}

Wenn Sie z.B. diesen Befehl also z.B. alle 10 Minuten ausführen und die Ergebnisse zusammenführen, dann können Sie grob ermitteln, wann und wie aktiv eine Domain über die Zeit ist.

Weitere Links

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/