Mediendurchquerung

 

Letztes Änderungsdatum des Themas: 2012-10-15

Der A/V-Edgedienst stellt einen einzelnen, vertrauenswürdigen Verbindungspunkt für ein- und ausgehende Medien bereit.

A/V-Edgedienst-Portanforderungen

Die A/V-Edgeanforderungen für Ports und das Protokoll wurden in Microsoft Lync Server 2010 geändert. Je nach Ihren Anforderungen für den Verbund mit Partnerinfrastrukturen und die Konfiguration Ihrer Edgeserver sollten die folgenden Ports in Betracht gezogen werden:

  • UDP 3478

  • TCP 443

  • UDP 50.000-59.999

  • TCP 50.000-59.999

Ausführliche Informationen zu den Anforderungen für die Portkonfiguration und die Netzwerkadressenübersetzung (Network Address Translation, NAT) finden Sie unter Ermitteln der Anforderungen für A/V-Firewall und Ports in der Planungsdokumentation.

Lync Server 2010 implementiert das Protokoll zur interaktiven Verbindungsherstellung (Interactive Connectivity Establishment, ICE), um Medienverbindungen mit Parteien innerhalb einer Umgebung zur Netzwerkadressenübersetzung (Network Address Translation, NAT) auszuhandeln. Einzelheiten zur Implementierung finden Sie in den Microsoft Office-Protokolldokumenten unter https://go.microsoft.com/fwlink/?linkid=145173&clcid=0x407.

A/V-Edgedienst-Portsicherheit

Der A/V-Edgedienst ist eine vom Unternehmen verwaltete Ressource. Daher ist eine Zugangsbeschränkung auf autorisierte Benutzer wichtig für sicherheits- und ressourcenbezogene Überlegungen.

UDP 3478 und TCP 443

Die Ports UDP 3478 und TCP 443 werden von Clients zur Anforderung von A/V-Edgediensten verwendet. Ein Client ordnet über diese beiden Ports dem Remotebenutzer UDP- bzw. TCP-Ports zu, mit denen er eine Verbindung herstellen kann. Um auf den A/V-Edgedienst zuzugreifen, muss der Client zunächst eine Lync-Registrierung für eine authentifizierte SIP-Signalübermittlungssitzung vornehmen, um die Anmeldeinformationen für den A/V-Edgedienst zu erhalten. Die Werte werden über den TLS-geschützten Signalkanal gesendet und zur Minderung des Risikos von Wörterbuchangriffen vom Computer generiert. Die Clients können diese Anmeldeinformationen zur Digestauthentifizierung mit dem A/V-Edgedienst verwenden, um die in einer Mediensitzung zu verwendenden Ports zuzuordnen. Der Client sendet eine erste Reservierungsanforderung, die vom A/V-Edgedienst mit einer 401 Nonce/Authentifizierungsnachricht beantwortet wird. Der Client sendet eine zweite Reservierungsanforderung, die den Benutzernamen sowie einen Hashcode (Hash Message Authentication Code, HMAC) von Benutzernamen und Nonce enthält. Außerdem sollen Wiedergabeangriffe mithilfe eines Sequenznummermechanismus verhindert werden. Der Server berechnet anhand von Benutzername und Kennwort den zu erwartenden Hashcode. Wenn die HMAC-Werte übereinstimmen, wird die Reservierung vorgenommen. Andernfalls wird das Paket gelöscht. Derselbe HMAC-Mechanismus wird auch auf alle nachfolgenden Nachrichten der Anrufsitzung angewendet. Die Lebensdauer des aus Benutzernamen und Kennwort berechneten Werts beträgt maximal acht Stunden. Nach diesem Zeitraum erwirbt der Client für die nachfolgenden Anrufe eine neue Kombination aus Name und Kennwort.

UDP/TCP 50.000-59.999

TCP 50.000 ausgehend wird für Lync Server verwendet, darunter auch für Anwendungs- und Desktopfreigabe, Dateiübertragung und Punkt-zu-Punkt-A/V-Funktionalität für Windows Live Messenger 2011. Die Portbereiche UDP/TCP 50.000-59.999 werden für Mediensitzungen mit Microsoft Office Communications Server 2007-Partnern verwendet, die vom A/V-Edgedienst den Dienst für NAT/Firewallausnahme benötigen. Da der A/V-Edgedienst der einzige Prozess ist, der diese Ports verwendet, gibt die Größe des Portbereichs keinen Aufschluss über das potenzielle Angriffsrisiko. Ein bewährtes Sicherheitsverfahren besteht in der Minimierung der Gesamtzahl der Überwachungsports durch Vermeidung unnötiger Netzwerkdienste. Wenn ein Netzwerkdienst nicht ausgeführt wird, kann er von einem Remoteangreifer nicht genutzt werden und das Angriffsrisiko des Hostcomputers wird reduziert. Durch eine Reduzierung der Portanzahl innerhalb eines Diensts kann jedoch nicht der gleiche Nutzen erzielt werden. Die A/V-Edgedienst-Software ist mit 10.000 offenen Ports nicht anfälliger als mit 10. Die Zuordnung der Ports innerhalb dieses Bereichs erfolgt zufällig, und nicht zugeordnete Ports können keine Pakete empfangen. Ausführliche Informationen finden Sie unter Ermitteln der Anforderungen für A/V-Firewall und Ports in der Planungsdokumentation.

A/V-Edgedienst-IP-Adressanforderungen

In Lync Server 2010 ist ein Edgeserver ein einzelner Server, auf dem alle drei Edgedienste ausgeführt werden, nämlich der Zugriffs-Edgedienst, der Webkonferenz-Edgedienst und der A/V-Edgedienst. Edgeserver ohne Lastenausgleich können NAT für alle drei Dienstrollen verwenden. Das bedeutet, dass Sie für den tatsächlichen Server keine öffentlich routingfähige IP-Adresse bereitstellen müssen und Ihren Umkreisadressbereich verwenden können. Für die interne Schnittstelle des Edgeservers wird NAT jedoch nicht unterstützt.

Sind mehrere Edgeserver hinter ein Hardwaregerät zum Lastenausgleich geschaltet, müssen Sie für die virtuelle IP-Adresse des Hardwaregeräts und den A/V-Edgedienst eine öffentliche Adresse zuordnen. Die öffentliche Adresse muss für Clients, die über das Internet auf den A/V-Edgeserver zugreifen, den direkten routingfähigen Zugriff ermöglichen. Wenn mehrere Edgeserver hinter ein DNS-Lastenausgleichsmodul geschaltet sind, müssen Sie für jede externe Adresse eine öffentliche Adresse zuordnen.

Dies ist erforderlich, weil die Adressierung für eine Mediensitzung auf der IP-Adressebene erfolgt, auf der die End-to-End-Konnektivität durch die Anwesenheit einer NAT-Funktion unterbrochen werden kann. Bei einem Edgeserver beinhaltet die Netzwerkadressenübersetzung (Network Address Translation, NAT) nur die Adressenübersetzung; sie bietet keinerlei Sicherheit durch Erzwingung von Routingrichtlinienregeln oder Paketinspektion. Der einzige potenzielle Nutzen von NAT besteht in der Verschleierung der IP-Adresse des Servers. Der Versuch, die IP-Adresse eines Netzwerkservers zu verbergen, stellt jedoch keine zuverlässige Sicherheitsmethode dar. Für alle Edgeserver ist eine ordnungsgemäß zugeordnete Firewallrichtlinie zur Beschränkung des Clientzugriffs auf die zugewiesenen Überwachungsports und durch Deaktivierung aller anderen unnötigen Netzwerkdienste erforderlich. Die Einhaltung dieser empfohlenen Verfahren vorausgesetzt, bietet NAT keine zusätzlichen Vorteile.

A/V-Datenverkehrdurchquerung für externe Benutzer

Um externen und internen Benutzern einen Medienaustausch zu ermöglichen, muss der für das Einrichten und Beenden von Sitzungen erforderliche SIP-Signaldatenverkehr über einen Zugriffs-Edgedienst geregelt werden. Außerdem muss ein A/V-Edgedienst als Relay für die Medienübertragung fungieren. Die Anruffolge ist in der folgenden Abbildung dargestellt.

Anruffolge zum Ermöglichen der Mediendurchquerung von NATs und Firewalls

c7c70bf2-a9e6-4d5c-941d-ff7bb6f6c13d

Die folgende Ereignisfolge tritt ein, wenn ein externer Benutzer interne Benutzer anruft und deshalb mithilfe des A/V-Edgeservers Nachrichten per Voicemail und/oder VoIP versenden muss:

  1. Im Rahmen dieser authentifizierten, verschlüsselten SIP-Sitzung erhält der Benutzer vom A/V-Authentifizierungsdienst Anmeldeinformationen für die Authentifizierung, indem er eine SIP SERVICE-Anforderung an den Dienst sendet.

  2. Der externe Benutzer authentifiziert sich über den A/V-Edgedienst und bekommt für den anstehenden Anruf Mediensitzungsports (Lync Server 2010 verwendet 3478/UDP und 443/TCP) auf dem Server zugeordnet. An diesem Punkt kann der externe Benutzer Pakete über den zugeordneten Port unter der öffentlichen IP-Adresse des A/V-Edgediensts, jedoch immer noch keine Medienpakete innerhalb des Unternehmens senden.

  3. Der externe Benutzer ruft den internen Benutzer über den vom Zugriffs-Edgedienst bereitgestellten SIP-Signalkanal an. Im Rahmen der Anrufeinrichtung wird der interne Benutzer über den Port des A/V-Edgediensts informiert, der dem externen Benutzer zum Austausch von Medien zur Verfügung steht.

  4. Der interne Benutzer kontaktiert den A/V-Edgedienst unter seiner privaten IP-Adresse, um für den Empfang von Medien authentifiziert zu werden. Dem internen Benutzer wird für die Mediensitzung auch ein Port unter der öffentlichen Adresse des A/V-Edgediensts (Lync Server 2010 verwendet 3478/UDP und 443/TCP) zugeordnet. Nach der Zuteilung des Ports nimmt der Benutzer, wiederum über den Zugriffs-Edgedienst, das Gespräch an und informiert so den externen Benutzer über den Port, den er vom A/V-Edgedienst für den Medienaustausch erhalten hat.

  5. Die Anrufeinrichtung ist abgeschlossen. Interne und externe Benutzer beginnen mit dem Austausch von Medien.

Zusammenfassend gesagt muss der externe Benutzer, um Medien in das Unternehmen senden zu können, authentifiziert werden, und ein authentifizierter interner Benutzer muss dem Austausch von Mediendatenströmen explizit zustimmen. Lync Server 2010 verwendet TCP 50.000-59.999 ausgehend. Lync Server 2010 nutzt im Verbund mit Office Communications Server 2007-Partnern weiterhin den Portbereich von 50.000-59.999 UDP/TCP. Für einen Verbund mit zwei Lync Server 2010- oder Office Communications Server 2007 R2-Partnern wird 3478/UDP und 443/TCP sowie TCP 50.000-59.999 ausgehend verwendet.

Sicherheit von End-to-End-Medien

Der zum Aushandeln einer Mediensitzung verwendete Signalkanal wird durch eine 128-Bit-TLS-Verschlüsselung geschützt. Zudem wurde bestätigt, dass das Serverzertifikat über einen geeigneten FQDN und eine vertrauenswürdige Stelle verfügt. Dieser Mechanismus ist dem Mechanismus von E-Commerce-Websites für Onlinetransaktionen sehr ähnlich. Zur Optimierung der Sicherheit der Medien selbst wird von Lync Server 2010 das SRTP-Protokoll der IETF implementiert. Bei diesem Mechanismus werden 128-Bit Schlüssel über den sicheren Signalkanal ausgetauscht, den die beiden Endpunkte anschließend zum Ver- und Entschlüsseln des Mediendatenstroms mithilfe der 128-Bit-Advanced Encryption Standard (AES)-Verschlüsselung nutzen. Dadurch ist sichergestellt, dass ein Angreifer selbst bei einem erfolgreichen Man-in-the-Middle-Angriff auf den Medienpfad die Unterhaltung nicht abhören oder zusätzliche Medienpakete einschleusen kann. Im letzteren Fall werden die Pakete einfach durch den Client gelöscht.