Traversée du contenu multimédia

 

Dernière rubrique modifiée : 2012-10-15

Le service Edge A/V fournit un point de connexion unique approuvé, utilisé à la fois par le trafic multimédia sortant et entrant de l’entreprise.

Exigences relatives aux ports du service Edge A/V

Les ports et le protocole utilisés par le service Edge A/V ont changé dans Microsoft Lync Server 2010. Selon la fédération requise avec les infrastructures partenaires et la configuration de vos serveurs Edge, l’utilisation des ports suivants peut être envisagée :

• UDP 3478

• TCP 443

• UDP 50 000 à 59 999

• TCP 50 000 à 59 999

Pour des détails sur les spécifications en matière de configuration de port et de traduction d’adresses réseau (NAT), consultez Détermination des conditions requises pour le pare-feu A/V externe et les ports dans la documentation consacrée à la Planification.

Lync Server 2010 implémente le protocole ICE (Interactive Connectivity Establishment) pour négocier les connexions multimédias avec les parties au sein d’un environnement NAT. Des informations spécifiques à l’implémentation de ce protocole sont disponibles dans les documents se rapportant aux protocoles de Microsoft Office à l’adresse https://go.microsoft.com/fwlink/?linkid=145173&clcid=0x40C.

Sécurité des ports du service Edge A/V

Le service Edge A/V est une ressource gérée par l’entreprise. Pour garantir la sécurité et protéger les ressources, il est donc important de restreindre l’accès aux seuls utilisateurs autorisés.

UDP 3478 et TCP 443

Les clients utilisent les ports UDP 3478 et TCP 443 pour acheminer leurs requêtes au service Edge A/V. Un client utilise ces deux ports pour allouer les ports UDP et TCP respectivement, pour la connexion des utilisateurs distants. Pour accéder au service Edge A/V, le client doit au préalable avoir établi une session de signalisation SIP authentifiée pour s’inscrire auprès de Lync, afin d’obtenir les informations d’authentification du service Edge A/V. Ces valeurs sont acheminées via un canal de signalisation protégé par TLS ; elles sont générées par ordinateur pour réduire les risques d’attaques par dictionnaire. Les clients peuvent ensuite fournir ces informations d’identification pour l’authentification Digest sur le service Edge A/V, pour l’affectation des ports utilisés au cours d’une session multimédia. Le client envoie une requête Allocate initiale et le service Edge A/V répond sous forme de message de vérification/valeur à usage unique 401. Le client envoie une seconde requête Allocate contenant le nom d’utilisateur et un code de hachage HMAC (Hash Message Authentication Code) incluant le nom d’utilisateur et la valeur à usage unique. Un mécanisme de numéro de séquence est également mis en œuvre pour éviter les attaques par relecture. Le serveur calcule le code de hachage HMAC attendu, en se basant sur le nom d’utilisateur et le mot de passe. Si la valeur HMAC correspond, il exécute la procédure Allocate. Sinon, le paquet est rejeté. Le même mécanisme HMAC est également appliqué aux messages ultérieurs reçus au cours de cette session d’appel. La durée de vie maximale de la valeur nom d’utilisateur/mot de passe est de 8 heures. Passé ce délai, le client acquiert un nouveau nom d’utilisateur/mot de passe pour les appels suivants.

UDP/TCP 50 000 à 59 999

Le port TCP 50 000 sortant sert pour Lync Server, notamment pour le partage d’applications et du Bureau, le transfert de fichiers et la fonctionnalité A/V point à point de Windows Live Messenger 2011. Les plages de port UDP/TCP 50 000-59 999 sont utilisées pour les sessions multimédias avec les partenaires Microsoft Office Communications Server 2007 qui nécessitent un service de traversée de pare-feu ou de NAT du service Edge A/V. Le service Edge A/V étant le seul processus utilisant ces ports, la taille de la plage de ports ne donne pas d’indication quant à la surface d’attaque potentielle. Par mesure de sécurité, il est recommandé de toujours réduire au minimum le nombre total de ports d’écoute en n’exécutant que les services réseau nécessaires. Lorsqu’un service réseau n’est pas en cours d’exécution, il ne peut pas être exploité par un intrus distant, ce qui permet de réduire la surface d’attaque de l’ordinateur hôte. Toutefois, la réduction du nombre de ports ne présente pas les mêmes avantages, dans le cas d’un service unique. Le logiciel du service Edge A/V n’est plus exposé aux attaques avec 10 000 ports ouverts qu’avec 10. L’allocation des ports de cette plage est aléatoire et les ports non actuellement alloués n’écoutent pas les paquets. Pour des informations détaillées, consultez Détermination des conditions requises pour le pare-feu A/V externe et les ports dans la documentation consacrée à la Planification.

Exigences relatives à l’adresse IP du service Edge A/V

Dans Lync Server 2010, un serveur Edge est un serveur unique qui exécute les trois services Edge, à savoir le service Edge d’accès, le service Edge de conférence web et le service Edge A/V. Les serveurs Edge qui n’utilisent pas l’équilibrage de charge peuvent utiliser NAT pour les trois rôles de service. Ainsi, il n’est pas nécessaire de fournir d’adresse IP routable publiquement vers le serveur lui-même et vous pouvez utiliser la plage d’adresses de votre périmètre. Toutefois, NAT n’est pas pris en charge pour le périmètre interne du serveur Edge.

Si vous utilisez plusieurs serveurs Edge derrière un programme d’équilibrage de charge matérielle, vous devez allouer une adresse publique à l’adresse IP virtuelle du programme d’équilibrage de charge et au service Edge A/V. L’adresse publique doit fournir un accès routable direct aux clients qui accèdent au service Edge A/V par le biais d’Internet. Si vous utilisez plusieurs serveurs Edge derrière un programme d’équilibrage de charge DNS, vous devez allouer une adresse publique pour chaque adresse externe.

Cette exigence s’explique par le fait que l’adressage d’une session multimédia a lieu au niveau de la couche de l’adresse IP, où la présence d’une fonction NAT est susceptible d’interrompre la connectivité de bout en bout. Pour un serveur Edge, un NAT fournit uniquement la traduction d’adresses ; il n’offre aucune sécurité, que ce soit par l’application de règles de stratégies de routage ou la vérification des paquets. Le seul avantage potentiel d’un NAT est le masquage de l’adresse IP du serveur, mais le fait de masquer l’adresse IP d’un serveur réseau ne constitue pas une mesure de sécurité fiable. Tous les serveurs Edge ont besoin d’une stratégie de pare-feu associée pour restreindre l’accès des clients aux ports d’écoute désignés et en désactivant tout autre service réseau non nécessaire. Compte tenu de la conformité à ces pratiques recommandées, la présence d’un NAT n’offre aucun autre avantage.

Traversée du trafic A/V de l’utilisateur externe

Pour que les utilisateurs externes et internes soient en mesure d’échanger des données multimédias, le service Edge d’accès doit pouvoir gérer la signalisation SIP nécessaire pour initialiser et mettre fin à une session. Un service Edge A/V doit également servir de relais lors du transfert des données multimédias. La séquence d’appel est illustrée dans la figure suivante.

Séquence d’appel utilisée pour permettre aux données multimédias de traverser les NAT et les pare-feu

La série d’événements suivante se produit lorsqu’un utilisateur externe appelle des utilisateurs internes et, par conséquent, doit envoyer des données vocales ou VoIP, voire les deux, par le biais du serveur Edge A/V :

1. Dans le contexte de cette session SIP authentifiée et chiffrée, l’utilisateur obtient les informations d’authentification du service d’authentification A/V en envoyant une demande de service SIP au service.

2. L’utilisateur externe s’authentifie auprès du service Edge A/V et obtient les détails des ports de session multimédia (Lync Server 2010 utilise 3478/UDP et 443/TCP) utilisés sur le serveur pour l’appel à venir. À ce stade, l’utilisateur externe peut envoyer des paquets par la voie du port alloué sur l’adresse IP publique du service Edge A/V, mais ne peut toujours pas envoyer de paquets de médias à l’intérieur de l’entreprise.

3. L’utilisateur externe appelle l’utilisateur interne par le biais d’un canal de signalisation SIP fourni par le service Edge d’accès. La configuration de l’appel prévoit que l’utilisateur interne soit notifié sur quel port du service Edge A/V l’utilisateur externe peut échanger des données multimédias.

4. L’utilisateur interne contacte le service Edge A/V sur son adresse IP privée afin d’être authentifié en vue de la réception des données multimédias. Un port est également alloué à l’utilisateur interne sur l’adresse publique du service Edge A/V (Lync Server 2010 utilise 3478/UDP et 443/TCP). Après réception des détails du port, l’utilisateur interne répond à l’appel - toujours par le biais du service Edge d’accès - puis notifie l’utilisateur externe du port obtenu sur le service Edge A/V pour l’échange multimédia.

5. La configuration de l’appel est maintenant terminée ; les utilisateurs internes et internes peuvent commencer l’échange des données.

En résumé, pour envoyer des données multimédias à l’intérieur de l’entreprise, l’utilisateur externe doit être authentifié. De plus, un utilisateur interne authentifié doit accepter de manière explicite d’échanger des flux multimédias. Lync Server 2010 utilise les ports TCP 50 000-59 999 sortants. Lync Server 2010 en fédération avec des partenaires Office Communications Server 2007 continue à utiliser la plage de ports 50 000 – 59 999 UDP/TCP. Une fédération impliquant des partenaires Lync Server 2010 ou Office Communications Server 2007 R2 utilisera les ports 3478/UDP et 443/TCP, et la plage TCP 50 000-59 999 sortante.

Sécurité des échanges multimédias de bout en bout

Le canal de signalisation utilisé pour négocier une session multimédia est protégé à l’aide du chiffrement TLS 128 bits, avec vérification que le certificat du serveur comporte un nom de domaine complet (FQDN) et une autorité approuvée correspondants. Ce mécanisme est similaire à celui utilisé par les sites de commerce électronique pour les transactions en ligne. Pour améliorer la sécurité du média lui-même, Lync Server 2010 implémente le protocole SRTP de IETF. Le mécanisme utilise un échange de clé 128 bits sur le canal de signalisation sécurisé. Ainsi, si un intrus parvient à lancer une attaque de l’intercepteur (« man-in-the-middle ») sur le chemin d’échange multimédia, il ne peut pas écouter la conversation ou injecter des paquets multimédias supplémentaires. Dans ce dernier cas, le client rejette simplement les paquets.