17. Considérations de sécurité (Security Considerations)
Cette section examine les attaques qui pourraient être menées contre les déploiements TURN et discute de la manière d'atténuer ces attaques par le biais de mécanismes dans le protocole ou de pratiques recommandées dans l'implémentation.
La plupart des attaques contre TURN sont atténuées par le serveur qui exige que les requêtes soient authentifiées. Pour cette raison, cette spécification impose l'utilisation de l'authentification. Le mécanisme obligatoire à implémenter est le mécanisme d'identification à long terme de STUN. D'autres mécanismes d'authentification avec les mêmes propriétés de sécurité ou plus fortes PEUVENT être utilisés. Cependant, il est important de s'assurer qu'ils peuvent être invoqués de manière interopérable.
17.1. Attaques externes (Outsider Attacks)
Les attaques externes sont celles où l'attaquant n'a pas d'identifiants dans le système et tente de perturber le service tel que vu par le client ou le serveur.
17.1.1. Obtention d'allocations non autorisées (Obtaining Unauthorized Allocations)
Un attaquant pourrait souhaiter obtenir une allocation sur un serveur TURN pour un certain nombre de raisons malveillantes. Un serveur TURN fournit un mécanisme pour envoyer et recevoir des paquets tout en masquant l'adresse IP réelle du client. Cela fait du serveur TURN une cible attrayante pour les attaquants qui souhaitent l'utiliser pour masquer leur véritable identité.
Un attaquant pourrait également simplement souhaiter utiliser les services d'un serveur TURN sans les payer. Comme les services TURN nécessitent des ressources du fournisseur, il est attendu que leur utilisation s'accompagne d'un coût.
Ces attaques sont prévenues par l'utilisation du mécanisme d'identification à long terme, qui permet au serveur TURN de déterminer l'identité du demandeur et si le demandeur est autorisé à obtenir une allocation.
17.1.2. Attaques par dictionnaire hors ligne (Offline Dictionary Attacks)
Le mécanisme d'identification à long terme utilisé par TURN est susceptible aux attaques par dictionnaire hors ligne. Un attaquant capable d'écouter un échange de messages entre un client et un serveur peut déterminer le mot de passe en essayant un certain nombre de mots de passe candidats et en voyant si l'un d'eux est correct. Cette attaque fonctionne lorsque les mots de passe ont une faible entropie (par exemple, des mots d'un dictionnaire). Cette attaque peut être atténuée en utilisant des mots de passe forts avec une grande entropie. Dans les cas où une atténuation encore plus forte est nécessaire, le transport TLS peut être utilisé entre le client et le serveur.
17.1.3. Rafraîchissements et permissions falsifiés (Faked Refreshes and Permissions)
Un attaquant pourrait souhaiter attaquer une allocation active en lui envoyant une requête Refresh avec une expiration immédiate afin de la supprimer et de perturber le service au client. Cela est empêché par l'authentification des rafraîchissements. De même, un attaquant souhaitant envoyer une requête CreatePermission pour créer une permission vers une destination non désirée est empêché de le faire par l'authentification. Les motivations de telles attaques sont décrites dans la Section 17.2.
17.1.4. Données falsifiées (Fake Data)
Un attaquant pourrait souhaiter envoyer des données à un client ou à un pair comme si elles provenaient respectivement du pair ou du client. Pour ce faire, l'attaquant pourrait envoyer une indication Data ou un message ChannelData falsifié au client ou une indication Send ou un message ChannelData falsifié au serveur TURN.
Parce que les indications et les messages ChannelData ne sont pas authentifiés, cette attaque n'est pas empêchée par TURN. Cependant, cette attaque est généralement présente dans les communications basées sur IP et n'est pas significativement aggravée par TURN. Considérez une session IP normale entre les hôtes A et B qui n'utilise pas TURN. Un attaquant peut envoyer un paquet à B semblant provenir de A en envoyant le paquet avec l'adresse IP usurpée de A. Cette attaque nécessite que l'attaquant connaisse les adresses IP de A et B. Avec TURN, un attaquant souhaitant envoyer un paquet au client en utilisant une indication Data doit connaître l'adresse IP (et le port) du client, l'adresse IP et le port du serveur TURN, et l'adresse IP et le port du pair (à inclure dans l'attribut XOR-PEER-ADDRESS). Pour envoyer un faux message ChannelData au client, l'attaquant doit connaître l'adresse IP et le port du client, l'adresse IP et le port du serveur TURN, et le numéro de canal. Cette combinaison particulière est légèrement plus facile à deviner que le cas sans TURN.
Ces attaques sont mieux atténuées par des techniques d'authentification de la couche application. Dans le cas du trafic en temps réel, l'utilisation de SRTP [RFC3711] peut empêcher ces attaques.
Dans certains cas, le serveur TURN pourrait être situé dans le réseau de manière à pouvoir envoyer à des hôtes que le client lui-même ne peut pas atteindre directement. Par exemple, si le serveur est situé derrière un pare-feu qui autorise les paquets provenant de l'extérieur du pare-feu à passer au serveur, mais pas aux autres hôtes derrière le pare-feu. Dans ces cas, un attaquant pourrait être capable d'envoyer une indication Send au serveur avec un attribut XOR-PEER-ADDRESS contenant l'adresse de transport de l'un des autres hôtes derrière le pare-feu. Si le serveur autorise le relais du trafic vers n'importe quel pair, cela fournirait à l'attaquant un moyen d'attaquer un hôte arbitraire derrière le pare-feu.
Pour atténuer cette attaque, TURN exige que le client établisse une permission vers un hôte avant de lui envoyer des données. Ainsi, l'attaquant ne peut attaquer que les hôtes avec lesquels le client a déjà communiqué, à moins que l'attaquant ne soit capable de créer des requêtes authentifiées. De plus, un administrateur de serveur peut configurer le serveur pour restreindre la plage d'adresses IP et de ports vers lesquels il relaiera les données. Pour fournir une sécurité encore plus grande, un administrateur de serveur peut exiger que le client utilise TLS pour toutes les communications entre le client et le serveur.
17.1.5. Usurpation d'un serveur (Impersonating a Server)
Lorsqu'un client apprend l'adresse relayée d'un serveur TURN, il utilise cette adresse relayée dans un protocole d'application pour recevoir du trafic. Ainsi, un attaquant souhaitant intercepter ou rediriger ce trafic pourrait essayer d'usurper l'identité du serveur TURN et fournir au client une adresse relayée falsifiée.
Cette attaque est empêchée par le mécanisme d'identification à long terme, qui fournit l'intégrité des messages pour les réponses et authentifie qu'elles proviennent du serveur. De plus, un attaquant ne peut pas rejouer d'anciennes réponses du serveur, car l'ID de transaction dans l'en-tête STUN empêche cela. Les attaques par rejeu sont encore découragées en changeant fréquemment la valeur nonce.
17.1.6. Écoute du trafic (Eavesdropping Traffic)
TURN se préoccupe principalement de l'authentification et de l'intégrité des messages. La confidentialité n'est qu'une préoccupation secondaire, car les messages de contrôle TURN ne contiennent pas d'informations particulièrement sensibles. Le contenu protocolaire principal des messages est les adresses IP des pairs. S'il est important d'empêcher un espion sur une connexion TURN d'apprendre cela, TURN peut être exécuté sur TLS.
La confidentialité des données d'application relayées par TURN est mieux fournie par le protocole d'application lui-même, car l'exécution de TURN sur TLS ne protégera pas les données d'application entre le serveur et le pair. Si la confidentialité des données d'application est importante, l'application devrait chiffrer ou protéger autrement ses données. Par exemple, pour les médias en temps réel, la confidentialité peut être fournie en utilisant SRTP.
17.1.7. Attaque de boucle TURN (TURN Loop Attack)
Un attaquant pourrait essayer de faire boucler indéfiniment des paquets de données entre deux serveurs TURN. L'attaque se déroule comme suit. Premièrement, l'attaquant envoie une requête Allocate au serveur A avec une adresse source du serveur B. Le serveur A envoie sa réponse au serveur B, et pour que l'attaque réussisse, l'attaquant doit pouvoir voir ou deviner le contenu de cette réponse afin que l'attaquant puisse apprendre l'adresse de transport relayée allouée. L'attaquant envoie ensuite une requête Allocate au serveur B avec une adresse source du serveur A. Encore une fois, l'attaquant doit pouvoir voir ou deviner le contenu de la réponse afin que l'adresse de transport relayée allouée puisse être apprise. En utilisant les mêmes techniques d'adresse source falsifiée, l'attaquant lie ensuite un numéro de canal sur le serveur A à l'adresse de transport relayée sur le serveur B et lie de même le même numéro de canal sur le serveur B à l'adresse de transport relayée sur le serveur A. Enfin, l'attaquant envoie un message ChannelData au serveur A.
Le résultat est un paquet de données qui boucle de l'adresse de transport relayée sur le serveur A à l'adresse de transport relayée sur le serveur B, puis de l'adresse de transport sur le serveur B à l'adresse de transport sur le serveur A, puis boucle à nouveau.
L'atténuation contre cette attaque est la suivante. En exigeant que les requêtes soient authentifiées et/ou en randomisant le numéro de port attribué pour l'adresse de transport relayée, le serveur force l'attaquant à intercepter ou voir les réponses envoyées à des tiers (dans ce cas, l'autre serveur) afin que l'attaquant puisse authentifier la requête et apprendre l'adresse de transport relayée. Sans l'une de ces deux mesures, l'attaquant peut deviner le contenu de la réponse sans avoir besoin de la voir, ce qui rend l'attaque plus facile à réaliser. De plus, en exigeant des requêtes authentifiées, le serveur force l'attaquant à avoir des identifiants que le serveur acceptera, ce qui en fait une attaque d'initié au lieu d'une attaque externe et permet de remonter l'attaque jusqu'au client qui l'a lancée.
Une atténuation supplémentaire peut être obtenue en imposant des limites par nom d'utilisateur sur la bande passante utilisée par les allocations appartenant à ce nom d'utilisateur pour le relais de données, afin de limiter l'impact de cette attaque sur les autres allocations. Une atténuation supplémentaire peut être obtenue en décrémentant le TTL lors du relais de paquets de données (si le système d'exploitation sous-jacent le permet).
17.2. Considérations relatives aux pare-feu (Firewall Considerations)
Une considération de sécurité clé pour TURN est que TURN ne doit pas affaiblir les protections offertes par un pare-feu déployé entre le client et le serveur TURN. Il est prévu que les serveurs TURN seront souvent présents sur l'Internet public, tandis que les clients pourraient souvent être situés dans un réseau d'entreprise desservi par un pare-feu d'entreprise. Si le serveur TURN fournit une "porte dérobée" dans l'entreprise, TURN sera bloqué par ces pare-feu.
Par conséquent, un serveur TURN émule le comportement d'un dispositif NAT qui implémente le filtrage dépendant de l'adresse [RFC4787], qui est une propriété commune dans de nombreux pare-feu. Lorsqu'un NAT ou un pare-feu implémente ce comportement, les paquets provenant d'une adresse IP externe sont autorisés à être envoyés à une adresse IP interne et un port uniquement si l'adresse IP interne et le port ont récemment envoyé un paquet à cette adresse IP externe. Un serveur TURN introduit le concept de permissions, qui fournit exactement le même comportement sur le serveur TURN. Un attaquant ne peut pas envoyer un paquet à un serveur TURN et s'attendre à ce qu'il soit relayé à un client à moins que le client n'ait d'abord essayé de contacter l'attaquant.
Il est important de noter que les politiques de certains pare-feu sont encore plus strictes que le filtrage dépendant de l'adresse. Les pare-feu peuvent également être configurés pour un filtrage dépendant de l'adresse et du port, ou peuvent être configurés pour ne pas autoriser du tout le trafic entrant. Dans ces cas, la communication avec un client serait moins restreinte que ce que le pare-feu autorise normalement, si le client est autorisé à se connecter à un serveur TURN.
17.2.1. Permissions falsifiées (Faked Permissions)
Dans les pare-feu et les dispositifs NAT, les permissions sont accordées implicitement par les paquets traversant de l'intérieur du réseau vers le pair extérieur. Ainsi, par définition, les permissions ne peuvent pas être créées par une entité à l'extérieur du pare-feu ou du NAT. Avec TURN, cette restriction ne tient plus. Puisque le serveur TURN se situe à l'extérieur du pare-feu, un attaquant à l'extérieur du pare-feu peut maintenant envoyer des messages au serveur TURN et essayer de créer des permissions pour eux-mêmes.
Cette attaque est bloquée car tous les messages qui créent des permissions (à savoir, ChannelBind et CreatePermission) sont authentifiés.
17.2.2. Adresses IP sur liste noire (Blacklisted IP Addresses)
De nombreux pare-feu peuvent être configurés avec des listes noires pour empêcher les clients derrière le pare-feu d'envoyer des paquets vers ou de recevoir des paquets depuis des plages d'adresses IP sur liste noire. Cela est accompli en examinant respectivement les adresses source et de destination des paquets entrant et sortant du pare-feu.
Cette capacité est également présente dans TURN, car le serveur TURN est autorisé à restreindre arbitrairement la plage d'adresses de pairs vers lesquels il relaiera.
17.2.3. Exécution de serveurs sur des ports bien connus (Running Servers on Well-Known Ports)
Un client malveillant derrière un pare-feu pourrait essayer de se connecter à un serveur TURN et d'obtenir une allocation, qu'il peut ensuite utiliser pour exécuter un serveur. Par exemple, le client pourrait essayer d'exécuter un serveur DNS ou un serveur FTP.
Cela n'est pas possible avec TURN. Un serveur TURN n'acceptera jamais le trafic d'un pair pour lequel le client n'a pas installé de permission. Ainsi, un pair ne peut pas simplement se connecter au port alloué afin d'obtenir le service.
17.3. Attaques d'initiés (Insider Attacks)
Dans une attaque d'initié, le client a des identifiants légitimes mais viole la relation de confiance qui accompagne ces identifiants. Ces attaques ne peuvent pas être empêchées par des moyens cryptographiques mais doivent être prises en compte dans la conception du protocole.
17.3.1. DoS contre le serveur TURN (DoS against TURN Server)
Un client souhaitant perturber le service aux autres clients pourrait obtenir une allocation et ensuite l'inonder de trafic, dans une tentative de submerger le serveur et de l'empêcher de servir d'autres clients légitimes. Cela est atténué en recommandant que le serveur limite la quantité de bande passante qu'il relaiera pour un nom d'utilisateur donné. Cela n'empêche pas le client d'envoyer une grande quantité de trafic, mais cela permet au serveur de supprimer immédiatement le trafic excédentaire.
Puisque chaque allocation utilise un numéro de port sur l'adresse IP du serveur TURN, le nombre d'allocations sur le serveur est fini. Un attaquant pourrait essayer de consommer toutes les allocations en demandant un grand nombre d'allocations. Cela est empêché par la recommandation que le serveur impose une limite sur le nombre d'allocations actives en même temps pour un nom d'utilisateur donné.
17.3.2. Relais anonyme de trafic malveillant (Anonymous Relaying of Malicious Traffic)
Un serveur TURN fournit un certain degré d'anonymisation. Un client peut envoyer des données à un pair sans révéler sa propre adresse IP. Ainsi, un serveur TURN pourrait devenir un outil attrayant pour les attaquants pour lancer des attaques contre une cible sans crainte de détection. En effet, un client pourrait enchaîner plusieurs serveurs TURN ensemble, de sorte qu'un nombre arbitraire de relais soient utilisés avant que le paquet de données n'arrive à la cible.
Un administrateur préoccupé par cette attaque peut maintenir des journaux capturant l'IP source réelle et le port du client, et éventuellement même chaque permission que ce client a installée. Cela permettrait un traçage médico-légal pour déterminer la source d'origine, si une attaque est découverte être relayée à travers un serveur TURN.
17.3.3. Manipulation d'autres allocations (Manipulating Other Allocations)
Un attaquant pourrait essayer de perturber le service aux autres utilisateurs du serveur TURN en envoyant des requêtes Refresh ou CreatePermission qui (par usurpation d'adresse source) semblent provenir d'un autre utilisateur du serveur TURN. TURN empêche cela en exigeant que les identifiants utilisés dans les messages CreatePermission, Refresh et ChannelBind correspondent aux identifiants qui ont été utilisés pour créer l'allocation initiale. Ainsi, les requêtes falsifiées d'un attaquant seront rejetées.
17.4. Autres considérations (Other Considerations)
Toute adresse relayée apprise via une requête Allocate ne fonctionnera pas correctement avec l'en-tête d'authentification IPsec (AH) [RFC4302] en mode transport ou tunnel. Cependant, le mode tunnel IPsec Encapsulating Security Payload (ESP) [RFC4303] devrait toujours fonctionner.