Lync Edge - die sichere Außenverbindung

Achtung
Ein Lync Edge darf nicht gegen einen OCS2007 R2 Backend Server mit Benutzern betrieben werden. Dies ist nicht supportet. 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

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.

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

Windows Server

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.

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

Hinweis:
Der Edge fragt auch die DNS-Records _sipfederationtls._tcp.<eigenedomain.tld> ab. Gerade beim Einsatz mit "SplitDNS", 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.

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.

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

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

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.

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

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:

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  
AdminClient Edge:500001/TCP
Edge:500002/TCP
Edge:500003/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

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 for Lync Server 2010 is to open it outbound, to "Any" for RDP/TCP for 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)

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.

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:

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.

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

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.

Weitere Links

Tags:Lync Edge