rapport maret

TRAVAIL DE DIPLÔME 2004

ETUDE DE CAS : VOIP/SIP & SÉCURITÉ

LUDOVIC MARET ETR

PROFESSEUR RESPONSABLE : MR STEFANO VENTURA

Travail de diplôme : VoIP/SIP & Sécurité Ludovic Maret

sur 107 05.04.2005

1 CAHIER DES CHARGES Ce travail de diplôme comprend les activités suivantes :

1. Tutorial présentant les problèmes liés à la sécurisation d’un réseau d’entreprise ayant déployé la VoIP et proposant des solutions de sécurisation. Il s’agira d’abord de :

o Définir et présenter les différentes vulnérabilités de la VoIP à l’intérieur et

extérieure de l’entreprise. Ne sera pris en considération que la problématique SIP.

o Définir et présenter les différentes architectures de déploiement possibles en tenant compte d’une configuration disposant d’un propre GW ISDN et d’une connexion VoIP à travers Internet pour communiquer avec d’autres filiales ou des collaborateurs itinérants

o Définir les différentes stratégies et mécanismes de sécurisation

2. Réaliser un GuideLine de prescriptions de sécurisation de la VoIP/SIP. Ce Guide pourra être utilisé comme guide pour un Audit.

3. Réalisation d’un laboratoire permettant de démontrer les différentes vulnérabilités de

la VoIP et l’efficacité des mesures défensives préconisées. Par exemple : écoute de communications, vol d’identité, DoS, etc. Il ne s’agit pas de traiter toutes les attaques mais de les classer et traiter les plus représentatives pour chaque type.

4. Si le temps le permet, proposer et réaliser un banc de test reproduisant les

configurations sécurisées les plus représentatives de l’interfaçage du service VoIP avec Internet. Ce banc de test doit permettre de comparer l’efficacité, les performances ainsi que l’interopérabilité de différentes mécanismes d’interconnexion (STUN, Turn, FW/ALG). Les résultas de ces observations feront l’objet d’un rapport.


sur 107 05.04.2005

2 TABLE DES MATIÈRES 1 CAHIER DES CHARGES ______________________________________________________ 2 2 TABLE DES MATIÈRES_______________________________________________________ 3 3 RÉSUMÉ ___________________________________________________________________ 5 4 INTRODUCTION _____________________________________________________________ 6 5 VULNÉRABILITÉS DE LA VOIP/SIP À L’INTÉRIEUR ET À L’EXTÉRIEUR DE L’ENTREPRISE __________________________________________________________________ 7

5.1 VULNÉRABILITÉS À L’INTÉRIEUR DE L’ENTREPRISE __________________________________ 8 5.1.1 Vulnérabilités des protocoles _____________________________________________ 8 5.1.2 Vulnérabilités des systèmes d’exploitation ___________________________________ 9 5.1.3 Vulnérabilités d’infrastructure _____________________________________________ 9 5.1.4 Vulnérabilités humaines _________________________________________________ 9

5.2 VULNÉRABILITÉS À L’EXTÉRIEUR DE L’ENTREPRISE__________________________________ 9 6 ARCHITECTURES DE DÉPLOIEMENT DE LA VOIP/SIP_____________________________ 9

6.1 DÉPLOIEMENT COMPLET D’UNE PLATEFORME DE VOIP :______________________________ 9 6.1.1 Architecture IP-enabled _________________________________________________ 9 6.1.2 Architecture IP-centric __________________________________________________ 9

6.2 ARCHITECTURE VIA ITSP____________________________________________________ 9 6.3 ARCHITECTURE FINALE _____________________________________________________ 9

7 PRESCRIPTIONS DE SÉCURISATION DE LA VOIP/SIP _____________________________ 9 7.1 SÉCURITÉ PHYSIQUE _______________________________________________________ 9 7.2 SÉPARATION DES ADRESSES LOGIQUES _________________________________________ 9 7.3 VLANS_________________________________________________________________ 9 7.4 SOFTPHONES ET HARDPHONES IP_____________________________________________ 9 7.5 FIREWALLS ______________________________________________________________ 9 7.6 GESTION DU FIREWALL VOIP/SIP______________________________________________ 9 7.7 SERVEURS DE VOIP/SIP CRITIQUES____________________________________________ 9 7.8 SCALABILITÉ _____________________________________________________________ 9 7.9 FILTRAGE DES APPELS______________________________________________________ 9 7.10 SÉCURISER LA SESSION SIP _________________________________________________ 9

7.10.1 HTTP Basic Authentification____________________________________________ 9 7.10.2 HTTP Digest Authentification ___________________________________________ 9 7.10.3 Pretty Good Privacy (PGP) ____________________________________________ 9 7.10.4 Secure MIME (S/MIME) _______________________________________________ 9 7.10.5 SIPS URI (TLS) _____________________________________________________ 9 7.10.6 IP Security (IPSec) ___________________________________________________ 9

7.11 SÉCURISER LES FLUX DE MÉDIA TEMPS RÉEL______________________________________ 9 7.11.1 Secure RTP (SRTP)__________________________________________________ 9 7.11.2 IP Security (IPSec) ___________________________________________________ 9

7.12 RADIUS ET AAA _________________________________________________________ 9 7.13 GESTION D’ACCÈS À DISTANCE DES SERVEURS DE VOIP/SIP __________________________ 9 7.14 CONNEXIONS VOIP/SIP WAN-À-WAN__________________________________________ 9 7.15 FIRMWARE ET LOGICIELS PROPRIÉTAIRES DES FABRICANTS ___________________________ 9 7.16 IDS/IPS SIP_____________________________________________________________ 9 7.17 NAT___________________________________________________________________ 9 7.18 RELAIS RTP _____________________________________________________________ 9 7.19 SERVICES DE VOICE MAIL VOIP/SIP ___________________________________________ 9 7.20 WIRELESS LAN ET VOIP/SIP_________________________________________________ 9


sur 107 05.04.2005

8 LABORATOIRE : VULNÉRABILITÉS DE LA VOIP/SIP ______________________________ 9 8.1 INTRODUCTION ___________________________________________________________ 9 8.2 MATÉRIEL NÉCESSAIRE _____________________________________________________ 9 8.3 MISE EN PLACE DU RÉSEAU SIP _______________________________________________ 9 8.4 QUELQUES ATTAQUES AU NIVEAU INTERNE DU RÉSEAU ______________________________ 9

8.4.1 DoS – CANCEL : ______________________________________________________ 9 8.4.2 DoS – BYE : __________________________________________________________ 9 8.4.3 DoS – Bulk REGISTER : ________________________________________________ 9 8.4.4 DoS – Bulk INVITE : ____________________________________________________ 9 8.4.5 Débordement de tampon (buffer overflow) : __________________________________ 9 8.4.6 Détournement d’appel (call hijacking) :______________________________________ 9 8.4.7 Ecoute indiscrète d’autres communications (eavesdropping) :____________________ 9 8.4.8 SPAM - INVITE :_______________________________________________________ 9

8.5 PRÉVENTION : MÉCANISMES DE SÉCURISATION ET RÉFLEXES UTILES_____________________ 9 8.5.1 Switch : ______________________________________________________________ 9 8.5.2 VLANs : _____________________________________________________________ 9 8.5.3 Digest Authentification : _________________________________________________ 9 8.5.4 Filtrage des appels : ____________________________________________________ 9 8.5.5 IDS/IPS :_____________________________________________________________ 9 8.5.6 SRTP : ______________________________________________________________ 9 8.5.7 TLS : ________________________________________________________________ 9

9 CONCLUSION ______________________________________________________________ 9 10 RÉFÉRENCES ______________________________________________________________ 9 11 SYMBOLES ET ABRÉVIATIONS________________________________________________ 9 12 FIGURES ET TABLEAUX _____________________________________________________ 9

12.1 FIGURES________________________________________________________________ 9 12.2 TABLEAUX ______________________________________________________________ 9

13 ANNEXES __________________________________________________________________ 9


sur 107 05.04.2005

3 RÉSUMÉ Avec l'émergence de réseaux convergents et de la VoIP, les systèmes de voix, traditionnellement isolés du réseau de transmission de données, évoluent pour devenir l'une de ses applications principale. L'une des conséquences de cette convergence est que le trafic de voix et ses systèmes associés sont devenus aussi vulnérables aux menaces de sécurité que n'importe quelle autre donnée véhiculée par le réseau. En effet, le déploiement de la VoIP en entreprise est très intéressant. Pour de faibles coûts de mise en place, le service de VoIP permet de téléphoner au sein de l’entreprise et sur Internet "gratuitement". De plus, l’implémentation de la VoIP avec le protocole de signalisation SIP (Session Initiation Protocol) [SA01] fournit un service efficace, rapide et simple d’utilisation. Cependant, SIP est un protocole d’échange de messages basé sur HTTP. C’est pourquoi SIP est très vulnérable face à des attaques de types DoS (dénis de service), détournement d’appel, trafic de taxation, etc. (voir point 5 " Vulnérabilités de la VoIP/SIP à l’intérieur et à l’extérieur de l’entreprise"). De plus, le protocole de transport audio associé RTP (Real-Time Transport Protocol) [SA02] est lui aussi très peu sécurisé face à de l’écoute indiscrète ou des DoS. Si vous souhaitez déployer une plateforme sécurisée de VoIP avec SIP, il faut agir comme suit : En premier lieu, il faut faire un choix sur le type d’architecture de VoIP/SIP que l’entreprise souhaite déployer. Cela dépend en grande partie de l’architecture actuelle du réseau de l’entreprise, des besoins de l’entreprise et évidemment de son budget (voir point 6 "Architectures de déploiement de la VoIP/SIP"). Une fois cela fait, il faut prendre des mesures de sécurités à plusieurs niveaux si nous voulons que le service de VoIP/SIP soit sécurisé. Il faut donc avant toute chose sécuriser le réseau de donnée avec les moyens standard connus de tous les administrateurs réseaux tels que l’utilisation de firewalls, de NAT, de chiffrement IP, VLAN, etc. Ensuite, il faut sécuriser le réseau de VoIP/SIP avec des mécanismes de chiffrement de la signalisation de du flux audio, sécuriser l’accès à tous les serveurs de VoIP, utiliser des VLANs, etc. Pour finir, il faut réussir à combiner les deux types de réseaux (donnée/VoIP) et sécuriser les accès au niveau de la passerelle entre les deux réseaux (voir point 7 "Prescriptions de sécurisation de la VoIP/SIP").


sur 107 05.04.2005

4 INTRODUCTION Grâce à son mécanisme de création de session simple et rapide, SIP a rapidement envahi le marché de la VoIP qui était jusqu’à lors dominé par les implémentations adhérant plutôt au standard complexe de téléphonie par Internet H.323 [SA03]. Tandis que H.323 a été étroitement modélisé sur le standard des réseaux numériques à intégration de services RNIS [SA04] de niveau 3 pour la mise en place d’appel et sur le standard de messages binaires ASN.1 pour la signalisation, SIP est, lui, basé sur le modèle de transaction HTTP requête/réponse en utilisant des messages textes avec une syntaxe proche de HTTP/1.1 (voir Figure 1).

Figure 1 - Modèle client-serveur (HTTP/SIP)

SIPv1 est un protocole de niveau application qui a été défini par la RFC 2543 en mars 1999. Il est basé sur UDP ou TCP et est utilisé pour la création de sessions à participants multiples, comme les applications de vidéo/audio conférence. Il remplit une fonction de signalisation comparable à SS7 [SA05] dans les réseaux commutés publics de téléphonie PSTN [SA06]. En juin 2002, le standard SIPv2, défini par la RFC 3261, remplace complètement SIPv1. Actuellement, SIPv1 n’est plus utilisé puisque cette version n’inclut aucun mécanisme de défense efficace. Cependant, d’un point de vue sécurité, SIPv2 n’est de loin pas parfait. En effet, SIPv2 est autant, voir plus, vulnérable que HTTP. Comme tout système de communication, la simplicité est souvent liée à des problèmes de sécurité. La clarté des messages SIP en fait un outil efficace et rapide mais également lisible, compréhensible et modifiable par d’autres personnes que celles concernées par la session. Le protocole qui transporte la voix, associé au protocole de signalisation SIP dans la VoIP, est RTP. Ce protocole de transport de média RTP a été défini par la RFC 1889 en Janvier 1996. RTP fournit RTP fournit des fonctions de transport réseau de bout-en-bout appropriés pour des applications de transmission de données temps-réel, tel que la voix, la vidéo ou des données de simulation. RTP peut tout aussi bien utiliser les services réseaux unicast ou multicast. En Juillet 2003, la nouvelle RFC 3550 remplace l’ancienne. Cette nouvelle version de RTP est plus fiable et supporte plus de codecs [SA07] audio. RTP est un protocole efficace et assurant une QoS [SA08] très acceptable. Cependant, RTP n’est pas à l’abris d’éventuelles attaques au niveau des données audio telle que la capture des paquets de voix ou l’injection de données audio extérieures à la communication. Nous sommes donc, ici, devant une combinaison de deux protocoles très peu sécurisés qui fonctionnent au dessus d’un protocole IP qui est, lui aussi, vulnérable face à beaucoup d’attaques. Voyons plus en détail les différentes menaces inhérentes au déploiement de la VoIP avec SIP auxquelles il faudra faire face après déploiement de ce service en entreprise.


sur 107 05.04.2005

5 VULNÉRABILITÉS DE LA VOIP/SIP À L’INTÉRIEUR ET À L’EXTÉRIEUR DE L’ENTREPRISE

Les menaces de sécurité associées à la téléphonie sur IP sont beaucoup plus nombreuses qu’avec un réseau commuté traditionnel PSTN. En effet, tant que la VoIP reste un service du réseau IP, les menaces de sécurités sont celles du réseau IP additionnées à celles du réseau SIP. En effet, l’implémentation de SIP fait intervenir des éléments supplémentaires (gateway(s), proxy(s), serveur(s) de redirection, serveur(s) d’enregistrement, serveur(s) d’emplacement, terminaux, etc.) qui induisent de nouvelles vulnérabilités. Certaines de ces vulnérabilités semblent être due au fait que, jusqu’à récemment, les utilisateurs se sont davantage préoccupés de la qualité de la communication et de la rentabilité de la technologie VoIP que de la synchronisation de ces aspects avec les mesures de sécurité et les protocoles appropriés. Les préoccupations envisageables concernant la technologie VoIP comprennent les questions de sécurité habituelles associées aux technologies d’Internet comme leur capacité à protéger les renseignements personnels et de l’entreprise, ainsi que de nouvelles préoccupations causées par la création de dépendances entre les réseaux vocaux et de données. La VoIP comprend deux types de vulnérabilités principales. La première est celle directement dépendante des protocoles utilisés dans l’implémentation et la deuxième est associée avec le système d’exploitation concerné. Chaque protocole (SIP, H323 ou MGCP [SA09]) ou service a ses propres vulnérabilités de sécurité. A ces deux types de vulnérabilités peuvent s’ajouter les vulnérabilités d’infrastructure/humaines. Nous pouvons donc classer les types de vulnérabilités comme suit :

• Vulnérabilités des protocoles • Vulnérabilités des systèmes d’exploitation • Vulnérabilités d’infrastructure • Vulnérabilités humaines

Comme dans tout réseau IP. Le réseau SIP doit principalement faire face à trois types de menaces :

• L’acquisition de services • L’interruption de services • L’interception de services

La plupart des menaces de sécurité peuvent être classées dans ces trois catégories, mais il y a toujours de nouvelles menaces à prendre en compte. La plupart des intrusions de sécurité dans les entreprises ont été faites par les employés de cette même entreprise. En effet, il est d’autant plus intéressant pour un employé de mettre son patron "sur écoute" que pour une personne externe à l’entreprise. Il faut donc que la personne malveillante se trouve physiquement à l’intérieur du réseau de VoIP/SIP et donc à l’intérieur du réseau de données également. Cependant, une certaine catégorie de personnes malveillantes se trouvant à l’extérieur du réseau peut tout aussi bien attaquer le service de VoIP pour plusieurs raisons qui leur incombent. Généralement ces raisons diffèrent des raisons qui poussent des employés à attaquer leur propre entreprise.


sur 107 05.04.2005

5.1 Vulnérabilités à l’intérieur de l’entreprise

5.1.1 Vulnérabilités des protocoles

Ce tutorial ne traitant que de l’implémentation de la VoIP avec SIP, nous ne prendront donc en compte que les protocoles suivants :

• SIP Session Initiation Protocol (RFC 3261) de l’IETF • SDP Session Description Protocol (RFC 2327) de l’IETF [SA10] • RTP Real-Time Transport Protocol (RFC 3550) de l’IETF • RTCP Real-Time Control Protocol (RFC 3605) de l’IETF [SA11]

SIP est un protocole simple et flexible orienté message basé sur les rendez-vous. Les composants principaux d’un système basé sur SIP sont :

• Terminal SIP (User Agent Client ou UAC) – Peut être aussi bien un SoftPhone (logiciel) qu’un HardPhone (IP Phone). Les terminaux sont des appareils pouvant émettre et recevoir de la signalisation SIP. Les autres éléments sont communément appelés des User Agent Server – UAS.

• Serveur d’enregistrement – Ce serveur essentiel reçoit les inscriptions des utilisateurs (adresse IP, port, username).

• Serveur de localisation – Mémorise les différents utilisateurs, leurs droits, leurs mots de passe, position actuelle, etc.

• Serveur de redirection – Redirige les appels vers la position actuelle d’un utilisateur. • Serveur proxy – Effectue le même travail que le serveur de redirection si ce n’est que

le proxy n’annonce pas à l’agent la localisation actuelle de l’utilisateur mais se charge de retransmettre les messages vers celui-ci.

• Passerelle (gateway) PSTN/H323/ISDN/PSTN – Permet l’interconnexion de réseaux différents en convertissant les paquets IP au format désiré.

Voici un rappel sur le principe de l’architecture trapézoïdale SIP :

Figure 2 - Architecture trapézoïdale SIP


sur 107 05.04.2005

Nous pouvons remarquer que le flux RTP ne transite pas par les serveurs SIP mais uniquement entre les deux agents en communications. Voyons maintenant comment se passe un appel SIP :

Figure 3 - Appel SIP standard

Le problème de la sécurité de la VoIP est donc double. Le fait que la voix et les données partagent le même réseau implique qu’aux vulnérabilités de sécurité des réseaux de données s’ajouteront les nouvelles vulnérabilités propres à la VoIP.


sur 107 05.04.2005

Menaces héritant directement du modèle réseau de donnée IP : Les réseaux IP sont de plus en plus déployés et donc de plus en plus connus. Ces réseaux sont donc facilement accessibles et permettent à de plus en plus de monde d’étudier les problèmes de sécurité auparavant trouvés et publiés et ceci à l’inverse de l’obscurité qui caractérise les réseaux PSTN. La téléphonie IP avoue volontiers parler de “Phreaker” afin de désigner toute personne mal intentionnée qui s’attaque à des réseaux téléphoniques. Voici donc une liste non exhaustive des vulnérabilités propres aux réseaux de données IP :

• Denis de service (DoS) : Privation d’accès à un service réseau en bombardant les

serveurs (proxy, gateway, …) avec des paquets malveillants. • Intégrité de message (message integrity) : Vérification que le message reçu n’a pas

été altéré durant la transmission. • Capture de paquets (paquets sniffing) : Obtention d’informations (adresse IP/MAC,

protocoles utilisés). • Reconnaissance : Analyse des services s’exécutant sur un serveur par exemple. • Mot de passe (password attack) : Casser des mots de passe afin d’obtenir des

privilèges. • Personne au milieu (man-in-the-middle) : Paquets modifiés de manière à usurper une

identité ou permettant la récupération d’information de transmission sur des utilisateurs.

o ARP Spoofing o IP Spoofing o Hijacking o DoS o etc.

• Malware : virus, vers (worms), trojans : MALicious softWARE : Applications malicieuse faisant référence à des programmes crapuleux.

• Exploits de vulnérabilité : Programme ou technique profitant d’une vulnérabilité dans un logiciel et qui peut être utilisé pour casser la sécurité ou pour attaquer une station à travers le réseau.

• Détournement (hijacking) : Attaque dans laquelle l’attaquant prend procession d’une connexion en cours entre deux entités en se faisant passer pour l’une des deux entités.

• Mauvaise utilisation (misuse) : Modifier le but inhérent d’une fonction ou autre afin de pouvoir abuser du système.

• Coupure de courant • Autres…


sur 107 05.04.2005

Menaces propres à l’utilisation de la VoIP/SIP : La particularité de la VoIP face aux données IP standard est principalement associée à la notion de qualité de service. En effet, comme dans tout système de téléphonie, la VoIP apporte une très importance à la QoS. Ceci augmente notablement l’exposition aux attaques de types DoS. Cela affecte principalement :

• Délai/latence • Perte de paquet • Variation du délai de transfert de l'information (jiter) • Bande passante • Techniques de codage de la parole

La QoS doit donc faire face à ces nouvelles vulnérabilités propres au service de VoIP, les éléments SIP vulnérables sont :

1. La signalisation (SIP/SDP) : En s’attaquant à la signalisation, le pirate peut obtenir des informations sur les utilisateurs et se faire passer pour quelqu’un d’autre par exemple. Cela permet également de détourner des appels et de manipuler la taxation.

2. Les données (SIP-DATA) : En s’attaquant aux données le pirate peut écouter les communications, modifier/insérer et supprimer de l’information.

Voici les différentes vulnérabilités propres au déploiement d’une plateforme de VoIP avec le protocole de signalisation SIP.


sur 107 05.04.2005

Dénis de service (DoS) : Il s’agit ici de la privation d’accès à un service réseau en bombardant les serveurs (proxy, gateway, …) avec des paquets malveillants. Il existe plusieurs moyens d’effectuer un DoS sur un service de VoIP/SIP :

o Injection de message CANCEL (voir Figure 4 et Figure 5). o Injection de message BYE (voir Figure 6, Figure 7 - DoS BYE à Bob, Figure 8

et Figure 9). o Utilisation des codes de réponses 4xx, 5xx ou 6xx. o Messages INVITE ou REGISTER en masse (Bulk REGISTER/INVITE). o Manipulation des collisions SSRC (RTP). o Injection de paquet (RTP). o Modification de codec audio.

CANCEL sur Bob :

Figure 4 - DoS CANCEL sur Bob


sur 107 05.04.2005

CANCEL sur Alice :

Figure 5 - DoS CANCEL sur Alice

BYE :

Figure 6 - DoS BYE


sur 107 05.04.2005

BYE à Bob :

Figure 7 - DoS BYE à Bob

BYE à Alice :

Figure 8 - DoS BYE à Alice


sur 107 05.04.2005

BYE (aux deux) :

Figure 9 - DoS BYE à Bob et Alice

Utilisation des codes de réponses : Un pirate peut utiliser différents codes de réponse afin d’introduire une condition de DoS :

Les réponses 4xx définissent les réponses dues à un échec depuis un serveur particulier. Le client ne doit pas ressayer la même requête sans modification (par exemple en ajoutant une autorisation particulière). Toutefois, la même requête vers un serveur différent peut réussir.

Les réponses 5xx sont des réponses d’échec émises quand un serveur a un problème.

Les réponses 6xx indiquent qu’un serveur a une information définitive sur un utilisateur particulier et pas juste une instance particulière indiquée dans la requête-URI.

Bulk REGISTER : Le fait d’envoyer une très grande quantité de messages REGISTER avec des URI différentes au serveur d’enregistrement cause le remplissage complet de la liste d’enregistrement. Ce qui veut dire que tous les téléphones IP non enregistrés ne pourront s’enregistrer. Cela provoque donc un DoS sur tous ces téléphones. Bulk INVITE : Le but est ici d’épuiser les ressources de sessions simultanées sur le proxy. Le nombre de connexions simultanées maximum dépend du serveur et du réseau. Il nous suffit donc d’initier plus de n connexions pour que le proxy soit devienne non fonctionnel. Le DoS s’applique donc à l’entièreté des téléphones SIP se servant de ce proxy pour communiquer.


sur 107 05.04.2005

Manipulation des collisions SSRC (RTP) : En envoyant une commande utilisant le SSRC (adresse de la source de synchronisation RTP) d’un autre participant ou en revendiquant le SSRC d’un autre (voir Figure 10), des collisions additionnelles vont entrer en jeu (réduction de la QoS voire DoS). Injection de paquet (RTP) : En injectant des paquets avec le même SSRC mais comportant un numéro de séquence et un timestamp supérieur par rapport aux valeurs actuelles (voir Figure 10), le contenu truqué injecté sera lu avant les paquets réels. Cela entraîne donc un DoS sur l’utilisateur ayant le SSRC considéré.

Figure 10 - Format de paquet RTP et vulnérabilités associées

Modification de codec audio : Le fait de modifier l’encodage audio RTP pendant une session peut être utilisé pour s’attaquer à la QoS. En effet, aussi bien l’utilisation d’un codec de plus faible qualité va provoquer non seulement une réduction de la qualité de la voix mais également d’autres problèmes tels que des DoS, des crashs du système, etc.

Identifie la source d’un flux

RTP

Utilisé par le récepteur pour

détecter la perte de paquet (peut être aussi utilisé pour

restaurer la séquence de

paquet)

Indique l’instant auquel le premier

byte de la cargaison RTP a été généré. Le timestamp est

utilisé pour placer les paquets RTP dans un ordre

temporel correct.


sur 107 05.04.2005

Détournement d’appel (call hijacking) : Le but est ici de détourner l’appel vers le pirate ou d’enregistrer les communications. Cela permet également de se joindre à un appel (conférence audio). Ce type d’attaque peut se faire de plusieurs manières :

• A travers le serveur d’enregistrement (voir Figure 11). • A l’aide d’attaques de type MITM (Man-in-the-middle attack).

o A travers l’utilisation de codes de réponse SIP 301 (voir Figure 12 et Figure 14) & 302 (déplacement permanent\temporaire, voir Figure 13). Ces codes réponses peuvent être spoofés comme des réponses venant de n’importe quel élément SIP, tels que :

• Serveur d’enregistrement – Cela permet d’usurper une identité (fake identity).

• Serveur proxy – Ceci permet d’obtenir toute la signalisation et donc la modification, la suppression voir l’ajout de messages SIP permettant de détourner des appels.

• Serveur de redirection – De manière analogue à un proxy, ceci permet d’obtenir toute la signalisation.

• UAC SIP – Cela permet de discuter avec le partenaire en se faisant pour le vrai destinataire (écoute du média).

o Ou plus créatif, à travers l’utilisation du code de réponse SIP 305 (utilisation du proxy, voir Figure 15).

• Tromper en milieu de session (mid-session tricks). En effectuant une manipulation d’enregistrement :

Figure 11 - Détournement d'appel en effectuant une manipulation d'enregistrement

On peut questionner le serveur d’enregistrement pour obtenir la liste des adresses d’un URI particulier. On peut ensuite donner la liste des adresses associées à notre URI avec chaque enregistrement correct. Mais est-ce que notre agent va le dévoiler aux autres ? Cela dépend si le système de notification est utilisé ou non. En général cela n’est pas le cas. On peut ensuite donner une priorité plus haute à notre enregistrement que celles des autres en faisant attention de ne pas supprimer les autres enregistrements.


sur 107 05.04.2005

Ou alors, on peut s’enregistrer avec une priorité plus faible et lancer un DoS sur les entrées de priorité haute. De cette manière, le proxy ne sera pas capable de délivrer les messages et va virer sur l’entrée suivante dans le serveur d’enregistrement. Le serveur d’enregistrement peut s’adresser à l’usager qui est en train de s’enregistrer (l’usager peut aussi bien être un 3ème usager) afin d’effectuer une authentification avant de recevoir l’information sur l’enregistrement. Or, étant donné que les caractéristiques d’enregistrement avec SIP requièrent un enregistrement chaque heure pour le même URI (une heure est spécifié par défaut), il est peu probable qu’un utilisateur de téléphone SIP doive s’authentifier au serveur d’enregistrement chaque heure. Au lieu de cela, ce que la plupart des téléphones SIP font est de stocker les informations sur le ‘username’ et le ‘password’ avec le téléphone (cela implique d’autres risques d’attaques…) et exécutent une authentification automatiquement pour l’utilisateur quand cela est requis. MITM Attack - Utilisation des messages 30x : L’emplacement de l’entité malicieuse peut être n’importe où (le réseau d’Alice, le réseau de Bob, voire entre les deux). Elle peut alors utiliser le code de réponse 301 (déplacement permanent) ou 302 (déplacement temporaire) afin de détourner des appels. En effet, le client qui a émis la requête doit renvoyer la requête à/aux nouvelle(s) adresse(s) donnée par l’entête de contact. L’URI de la nouvelle requête utilise la valeur du contact obtenue dans la réponse 301 ou 302. Cette URI s’avère être l’URI de l’attaquant. La durée de validité de l’URI du contact peut être indiquée à travers une entête d’expiration ou alors à l’aide d’un paramètre d’expiration dans l’entête du contact. Les deux proxy et terminaux peuvent dissimuler cet URI pour la durée d’expiration. Si il n’y a pas de durée d’expiration, l’adresse est uniquement valide une fois et ne doit pas être cachée pour les transactions futures. Si l’URI dissimulée de l’entête du contact échoue, l’URI de la requête redirigée doit être ressayée une seule fois.


sur 107 05.04.2005

Figure 12 - Détournement d'appel et utilisant un message 301 Moved Permanently

MITM attack - 302 Déplacement temporaire :

Figure 13 - Détournement d'appel et utilisant un message 302 Moved Temporarily


sur 107 05.04.2005

MITM Attacks – Envers le serveur d’enregistrement :

Figure 14 - Détournement d'appel et utilisant un message 301 Moved Permanently afin

d'obtenir des credentials

En utilisant les credentials de Bob, Carol devient capable de s’authentifier auprès de n’importe quel serveur de téléphonie IP. Lui permettant ainsi que pouvoir passer des appels gratuits (voir free phone call) aussi bien que l’habilité à exécuter n’importe quelle fonctionnalité autorisée par les credentials de Bob dans le réseau de téléphonie IP. Par exemple, elle peut s’enregistrer en tant que partenaire de destination avec un service d’enregistrement, ce qui permet de pouvoir détourner des appels facilement.


sur 107 05.04.2005

MITM Attacks – 305 utilisation du proxy, ou l’attaque du “Qui est ton père ?” :

Figure 15 - Détournement d'appel et utilisant un message 305 Use Proxy

Mid Session Tricks / ”Re-INVITE” ou ”Session Replay” : Cette modification peut impliquer des changements d’adresses et de ports, des ajouts/suppressions de flux media etc. Ceci s’effectue en envoyant une nouvelle requête INVITE dans la même communication qui a établi la session. Ceci est aussi connu sous le nom ”re-INVITE attack". En détournant la voie de signalisation, il est possible d’introduire de nouveaux routages dans la voie de signalisation d’une session courante. Ceci permet de refuser une signalisation venant de n’importe qui à notre profit. Cela permet également de faire évoluer la session en introduisant d’autres participants. L’écoute non autorisée (eavesdropping) peut donc se faire de manière simple et en temps réel. Détournement d’enregistrement (registration hijacking) : Si un attaquant peut capturer un message REGISTER correct émis par l’un des téléphones, alors il peut le modifier et renvoyer un nouveau message REGISTER au serveur d’enregistrement pendant la période définie dans le timestamp original. Il peut alors trafiquer le serveur d’enregistrement de plusieurs manières. Par exemple, l’attaquant peut désenregistrer l’enregistrement existant en modifiant le champ ‘Expires’ avec la valeur 0. Dans ce cas, l’appareil enregistré (la victime) ne peut plus envoyer ou recevoir des appels et ne peut plus enregistrer son appareil comme adresse de contact approprié. De ce fait, toutes les requêtes pour l’utilisateur victime seront redirigées vers l’attaquant. Cela induit donc à la fois un détournement d’enregistrement et un DoS sur la victime.


sur 107 05.04.2005

Modification d’identité (request spoofing) : Cette attaque est utilisée pour modifier l’identité de l’émetteur de messages SIP pour trafiquer le récepteur légitime. Ceci peut être fait pour différentes raisons (par exemple : fraude ou taxation). En changeant les entêtes du message, la personne malveillante peut envoyer une requête forgée qui fait en sorte que le récepteur croit qu’il est en communication avec une autre personne. La modification d’identité peut être effectuée sur n’importe quelle requête tel que REGISTER et INVITE. Trafic de taxation (fooling billing) : Le serveur proxy SIP est habituellement celui qui produit l’enregistrement du détail d’appel ou CDR (call detail recording) pour la taxation. Ceci est dû au fait que le serveur proxy est capable d’obliger toute la signalisation et la voix de passer à travers le serveur proxy. Cela signifie que les messages de signalisation d’initialisation de communication et de terminaison vont passer à travers le serveur proxy, et ainsi les CDRs vont être produits correctement. Afin de pouvoir ce faire, la signalisation doit donc passer à travers le serveur proxy. Cela n’est pas le cas quand nous traitons avec l’actuel média de transport. Cela veut dire qu’il n’y a pas d’acquisition de service dans les paquets RTP/RTCP. Une manière simple de trafiquer ce mécanisme de taxation est de dissimuler la signalisation SIP dans les messages RTP ou RTCP. Bien sur, ceci suppose que les deux partenaires de la communication vont devoir utiliser des applications modifiées qui ont la possibilité de parser les paquets RTP/RTCP. Dans ce cas de figure, le serveur proxy SIP ne va voir aucune signalisation échangée entre les deux partenaires de communication, bien que le flux audio va passer entre ces deux utilisateurs. Un appel pourra donc être lancé sans qu’aucune information de taxation ne soit disponible. Cet exemple met l’accent sur le besoin de comprendre qui arrive en premier. Dans notre cas, la signalisation arrive en premier, seulement nous avons besoin d’autoriser les paquets RTP à échanger. Ceci est une restriction qui nécessite d’être introduite dans n’importe quel système de VoIP basé sur SIP.

Réseaux sans fils (WLAN) : Le fait de combiner la VoIP avec les réseaux sans fils afin d’obtenir une très grande liberté de mouvement avec des téléphones IP sans fils ouvre la porte à de nouvelles vulnérabilités. En effet, les réseaux sans fils ne sont pas parfaits et il existe plusieurs moyens de pouvoir s’introduire dans un réseau sans fil plus facilement que dans un réseau IP standard. Cela permet ensuite au Phreaker de lancer n’importe quelle attaque au niveau VoIP/SIP.


sur 107 05.04.2005

SPAM Il existe trois types de SPAM différent avec la VoIP/SIP :

1. CALL SPAM : Ce type de SPAM est définit comme une masse non-sollicitée de tentatives d’initiation de session (avec des messages INVITE), afin de tenter d’établir des sessions de communication audio. Si l’utilisateur répond, le spammer s’affaire à relayer ses messages sur le média temps réel. Ceci est le spam classique de telemarketer, appliqué à SIP.

2. IM SPAM ou SPIM : Ce type de spam est similaire au spam email. Il est définit par

une masse non-sollicitée de messages instantanés, dont le contenu comprend le message que le spammer cherche à convoyer. Le spam IM est le plus souvent envoyé en utilisant les requêtes SIP MESSAGE. Toutefois, une quelconque autre requête qui provoquerait un affichage automatique du contenu sur l’écran de l’utilisateur devrait également suffire. Il est possible d’inclure des requêtes INVITE avec des grandes entêtes de sujet ou des requêtes INVITE avec du texte ou un corps HTML.

3. PRESENCE SPAM : Ce type de spam est similaire au spam IM. Il est définit par une

masse non-sollicitée de requêtes de présence (c'est-à-dire des requêtes SUSCRIBE dans le but d’être sur la "white list" d’un utilisateur afin de pouvoir lui envoyer des IM ou pour initier d’autres formes de communications). A la différence du spam IM, le spam de présence ne doit pas réellement convoyer le contenu dans le message. Il n’est donc pas évident de trouver l’utilité ou la valeur d’un tel type de spam.

Surveillance des appels (call tracking) : La surveillance des appels permet de déterminer les partenaires faisant partie de l’appel et le nombre d’utilisateurs en communication. Si quelqu’un arrive à capturer les DTMFs [SA12] (Dual Tone Multiple Frequencies) avec son trafic de signalisation, il peut alors avoir l’opportunité de capturer les mots de passes de voicemail, des informations sur la carte de visite/crédit ou encore d’autres données saisies par DTMF. C’est pourquoi avec SIP tout ce que nous avons besoin de pister/surveiller est les messages INVITE. Si le BYE est aussi enregistré, la durée de l’appel peut également être tracée. Mais d’autres informations ou parties d’information peuvent être surveillée.

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:[email protected]> From: Alice <sip:[email protected]>;tag=1928301774 Call-ID: [email protected] CSeq: 314159 INVITE Contact: <sip:[email protected]> Content-Type: application/sdp Content-Length: 142


sur 107 05.04.2005

Chiffrement : Avec SIP, il subsiste encore des problèmes lorsque nous désirons chiffrer la signalisation. En effet, le problème du chiffrement avec DES est que cet algorithme est cassable. De plus, la clef DES est envoyée en clair avec le paramètre ‘k’. Et ceci sans compter le fait que le chiffrement entraîne des délais et des interférences (jitter) supplémentaire qui s’oppose très clairement aux fondements de la QoS. Ecoute secrète d’autres communications (eavesdropping, sniffing, wiretapping) : L’écoute secrète de communications peut être facilement réalisée avec un hub, un couteau, un clipper et un sniffer. En fait, tous les moyens sont bons tant que l’attaquant arrive à se placer sur le même chemin que le flux audio avec un hub. Cela peut donc se faire de plusieurs manières :

• En se plaçant entre le téléphone IP (ou le gateway client local) et le switch (voir Figure 16).

Figure 16 - Eavesdropping entre le switch et le téléphone IP

• En se plaçant entre deux switchs (voir Figure 17).

Figure 17 - Eavesdropping entre deux switchs

Il suffit ensuite de capturer le trafic RTP qui transite entre les deux partenaires en communications. Après avoir remis les paquets RTP dans le bon ordre et converti le flux audio en un fichier, il est alors possible d’écouter la communication bidirectionnelle en différé. L’avantage en crackant le réseau téléphonique de cette manière est que le eavesdropper peut également passer des appels gratuits sans la connaissance de l’abonné (voir Figure 18).


sur 107 05.04.2005

Figure 18 - Possibilité d'appels gratuits

Une autre manière de procéder est d’effectuer d’abord une attaque de type Call Hijacking pour rediriger le flux vers l’attaquant. Ceci aura pour effet de faire croire à l’appelant que l’attaquant est bien celui qu’il a voulu appeler. Avec un peu de savoir-faire l’attaquant pourra donc discuter avec l’appelant et lui soustraire des informations. Notons tout de même que cette technique est dangereuse pour l’attaquant puisque c’est lui-même qui va discuter et qu’il fait probablement partie de l’entreprise. Il se peut alors que l’on reconnaisse sa voix. Masquage d’appelant (call masquerading) : Le problème du masquage d’appelant est que le partenaire appelé ne peut authentifier visuellement l’appelant pendant un appel. Cela peut par exemple permettre à des vendeurs peu scrupuleux de faire leur petite publicité sans que l’on puisse savoir à qui l’on a à faire (ou tout du moins jusqu’à ce que le partenaire appelant se présente). Mais à ce moment là, la moitié du travail du vendeur est fait puisque notre curiosité nous a poussé à répondre. Pas d’intelligence/contrôle du flux media durant une session : Il ne faut pas oublier que la signalisation transite sur une voie. Le media sur une autre. Certains appareils ont besoin de contrôler la création de flux médias mais il n’y pas de flux média sans la signalisation appropriée (problème de qui vient en premier, voir fooling billing). Si il y a une modification du flux média (à travers l’utilisation de RTP ou RTCP, par exemple) le protocole de signalisation SIP ne va pas en être au courant. Si le codec utilisé par le protocole de transport du média change, SIP ne le remarque pas. SIP est aveugle face au protocole de transport du media audio. En effet, dans le cas où le flux média serait interrompu, les éléments SIP participants à la session (spécialement les serveurs SIP ou UASs) n’en seront en aucun cas informé jusqu’au moment ou l’un des deux partenaires raccroche le combiné. Il n’y a également pas de contrôle du canal utilisé pour le flux média. Nous avons vu qu’un utilisateur malveillant peut changer le codec utilisé à travers le protocole de média et spécifier un codec qui demande plus de bande passante (par conséquent son utilisation va augmenter la perte de paquets et de ce fait va diminuer la qualité de transmission, ou encore la qualité de la parole). Enfin, aucun contrôle d’aucune sorte n’est disponible pour le flux média. Ce qui favorise grandement la manipulation de flux peu scrupuleuse en toute impunité.


sur 107 05.04.2005

Clients malveillants (malicious clients) : Si on utilise un client malveillant (notre stack à la place du stack du fabriquant ou un stack modifié) et qu’on est le partenaire appelé, on peut, par exemple, enlever les entêtes des routes enregistrées sans problèmes. Et cela aura pour résultante que l’appelant va devoir envoyer des signaux au-delà du "three-way handshake SIP" à travers n’importe quel proxy SIP que le client malveillant à spécifié dans les routes. Cela ouvre la porte à une multitude d’autres attaques (détournement, DoS, etc.). Par ailleurs, il est très simple de connaître les routes utilisées pour transmettre les messages SIP (au travers des champs VIA dans l’entêtes des messages SIP, voir Figure 19). Cela peut par exemple permettre de se faire passer pour l’un des proxy.

Figure 19 - Les clients sont malveillants

Débordement de tampon (buffer overflow) : L’utilisation de messages INVITE modifiés ou fragmentés peut causer un débordement de tampon. Ceci est dû à une mauvaise implémentation de SIP chez les constructeurs de matériels/logiciels de VoIP. Ce type d’attaque peut permettre d’avoir un accès privilégié non autorisé (exécution de code malicieux), un comportement instable du système (interruption de services) ou entraîner un DoS sur l’appareil recevant le message, le faisant ainsi tomber en panne ou l’obligeant à redémarrer la plupart du temps. Ceci n’est pas toujours possible mais actuellement la plupart des téléphones IP, des gateways, des firewalls et des logiciels serveurs SIP sont concernés. La validité de ces vulnérabilités dépend du type de matériel/logiciel (propre aux constructeurs) de déploiement SIP pour la VoIP ainsi que les différentes version de firmware et d’IOS utilisées (logiciel système des téléphones, routeurs et autres).


sur 107 05.04.2005

5.1.2 Vulnérabilités des systèmes d’exploitation

La majorité des vulnérabilités des systèmes d’exploitation des HardPhones sont les débordements de tampon (buffer overrun) qui peuvent permettre à un pirate de prendre une partie ou le contrôle total de la station. Ce ne sont pas les seules et d’autres vulnérabilités sont utilisables par les pirates suivants les systèmes d’exploitation des constructeurs et leurs versions (malwares). Ces vulnérabilités sont pour la plupart relatives à un manque de sécurité dans la phase initiale de développement du système d’exploitation et par conséquent sont découvertes après le lancement du produit. Suivant les constructeurs et suivant les versions de firmware, les vulnérabilités suivantes peuvent apparaître : Mot de passe administrateur par défaut : Si le pirate a un accès physique au téléphone et que celui-ci n’a pas changé son mot de passe administrateur par défaut, il aura un accès total au téléphone et pourra, de ce fait, faire ce qu’il veut (appels gratuits, changement de mot de passe, téléchargement de firmware contenant des malwares, etc.). Par exemple, il est possible d’obtenir les droits administrateurs (Pingtel) en activant l’option more menu ‘factory default’ le mot de passe par défaut sera null. De cette manière nous pouvons obtenir les droits administrateurs. Fuite d’informations (information leakage - Pingtel) : N’importe quel utilisateur authentifié peut, en regardant le téléphone lors d’un appel, d’ores et déjà récupérer les informations sur le numéro de téléphone et le plus souvent le nom du participant. Il peut également activer/désactiver les logs de messages SIP ou encore en lister le contenu et ainsi de découvrir beaucoup d’informations sur les autres partenaires SIP. Virus, vers (worms), codes malveillants (malicious codes) et exploits : Comme tout logiciel, ceux qui sont utilisés en VoIP sont également vulnérables aux malwares et aux exploits. Par exemple, Nimda s’attaque au Call Manager de Cisco et peux engendrer des gros problèmes de sécurité. Epuisement de ressources (resource exhaustion) : Une attaque DoS basée sur DHCP pourrait affamer le réseau d’adresses IP en épuisant le pool d’adresses IP du serveur DHCP dans un réseau VoIP. Et ainsi tous les téléphones ne possédant pas encore d’adresse IP ne pourront téléphoner. Par ailleurs, ceci peut également affecter toutes les stations qui désireraient obtenir une nouvelle adresse IP de manière dynamique et cela uniquement si il n’y a qu’un seul serveur DHCP pour le réseau de donnée et le réseau de VoIP.


sur 107 05.04.2005

Abuser l’interface Web (Pingtel) : Manipulation de la signalisation : En utilisant le mot de passe administrateur, une

personne malveillante peut s’authentifier sur le serveur Web. L’accès administrateur donne un contrôle total sur les paramètres du téléphone. Ces paramètres incluent la configuration d’un serveur proxy/redirection SIP ou autre. En manipulant un ou plusieurs de ces paramètres, il peut obtenir un contrôle complet sur le flux audio VoIP. Ceci peut être fait spécifiant des serveurs malveillants.

Détournement d’appel (call hijacking) : En utilisant l’interface Web authentifié en tant

qu’administrateur, un utilisateur peut modifier les paramètres de transfert d’appel. Paramétrer tous les appels à être transféré à un autre URI SIP ou numéro de téléphone permet à l’utilisateur malveillant de détourner tout le trafic du téléphone vers un tiers. Quand le "call forwarding" est activé, aucune notification n’est présentée à l’utilisateur d’un quelconque appel entrant ou détourné.

DoS : Un attaquant peut introduire une condition de DoS en manipulant n’importe lequel

des paramètres suivants :

o Si la personne possède un accès administrateur : 1. Ports d’écoute : SIP – SIP_TCP_PORT = SIP_UDP_PORT (autre que zéro). 2. Nécessité d’authentifier les appels entrants : SIP_AUTHENTICATE_SCHEME

soit ‘Digest’ soit ‘Basic’. 3. Altérer le comportement du serveur Web : PHONESET_HTTP_PORT = 0 le

serveur s’éteint.

o Si la personne est simplement authentifiée : 1. Redémarrer le téléphone : Pendant 45 secondes le téléphone est inutilisable. 2. Arrêt de la communication téléphonique courante : Sélection du partenaire puis

‘Hangup’. 3. Neutraliser la sonnerie : Remplacer la sonnerie par un fichier vide ou silencieux.

Puis mettre la méthode ALERT sur ‘ring only’. Attaques TFTP : Les attaques TFTP sont inhérentes aux HardPhones. Les serveurs TFTP sont donc des cibles intéressantes pour des personnes mal intentionnées. Les attaques se font communément en plusieurs étapes : 1. Les téléphones téléchargent le fichier de configuration sur le serveur TFTP. 2. Il faut ensuite découvrir les adresses MAC utilisées par les téléphones IP sur le réseau.

Cela peut se faire de deux manières différentes :

En analysant les transactions réseaux :

o Si le Phreaker est connecté au(x) même(s) switch(s) de distribution que les téléphones, le Phreaker peut prendre connaissance facilement des adresses MAC des téléphones parce que les réponses aux requêtes TFTP des téléphones contiennent également les adresses MAC des téléphones.

o D’autres techniques sont possibles pour récupérer ces informations, par

exemple : balayement de requête SIP INVITE (SIP INVITE request sweep) ; “ping sweep”, combiner des attaques ARP en sniffant le réseau, etc.


sur 107 05.04.2005

En utilisant un accès distant Telnet sur le téléphone :

o L’accès Telnet au téléphone, si on utilise la commande ‘show network’ permet de

récupérer les informations suivantes : a. Plateforme du téléphone b. Serveur DHCP c. Adresse IP et masque de sous-réseau d. Passerelle par défaut e. Adresse IP du serveur TFTP f. Adresse MAC g. Nom de domaine h. Nom du téléphone

3. Le téléphone va ensuite télécharger les fichiers de configurations spécifiques depuis le

serveur TFTP :

L’adresse MAC d’un téléphone IP pourrait probablement être utilisée pour construire le nom de fichier de la configuration spécifique du téléphone. L’attaquant a simplement besoin d’examiner le paramètre ‘tftp_cfg_dir’ dans le fichier de configuration générique afin de déterminer ou les fichiers de configuration spécifique sont stockés. Récupérer le fichier est d’office effectué étant donné que TFTP est un protocole avec authentification.

Les informations les plus importantes stockées dans le fichier de configuration

spécifique sont les credentials utilisés par le(s) utilisateur(s) du téléphone utilisés pour s’authentifier sur le réseau de téléphonie IP. Ces paramètres se trouvent sous la ligne ‘configuration parameters’ : ‘linex_authname’ et ‘linex_password’.

4. Si il n’y a pas d’accès Telnet sur le téléphone, il est tout de meme possible de :

Utiliser la force brute sur les noms de fichier du serveur TFTP. Réactiver le service Telnet.

Manipuler l’image du firmware du téléphone.

L’image du firmware est téléchargée et installée sans authentification. L’image du

firmware n’est signée en aucun cas afin de pouvoir vérifier sa validité. Une quelconque image avec un numéro de version supérieur à la version actuelle est tacitement considérée de confiance. Pour compliquer la situation, pas d’autorisation n’est requise depuis l’utilisateur avant qu’une nouvelle image de firmware soit installée. La combinaison du manque d’authentification et d’autorisation de l’image de firmware veut dire qu’un attaquant avec un accès en écriture sur le serveur TFTP est capable de contrôler complètement tous les aspects du téléphone IP.

5. Si une personne malveillante a un accès physique au téléphone :

Elle est capable de reconfigurer les paramètres réseaux du téléphone en utilisant son interface utilisateur. L’accès aux paramètres peut se faire en utilisant la combinaison de touches ‘**#’ (Cisco IP Phone 7960).

Avec un accès physique au téléphone tout est possible (par exemple : redémarrer le

téléphone, récupérer l’adresse MAC, etc.).


sur 107 05.04.2005

Il existe encore une multitude de vulnérabilités propres aux systèmes d’exploitations des constructeurs de téléphone IP. Il ne s’agit ci-dessus que des cas les plus courants. Si vous désirez une liste exhaustive de ces vulnérabilités je vous invite à aller directement sur les sites Internet des fabricants.

5.1.3 Vulnérabilités d’infrastructure

Les réseaux de VoIP peuvent être déployés en toute sécurité dans un environnement réseau sécurisé isolé sans trop de risques. Ceci s’adresse à tous les protocoles, mais en réalité si l’entreprise à besoin d’être connectée à Internet comme c’est souvent le cas aujourd’hui il faudra s’occuper de tous les problèmes additionnels associés. Nous ne devons pas seulement nous inquiéter de sécuriser notre réseau de donnée mais également le réseau de voix. Un des soucis principal est donc la disponibilité de nos réseaux. A chaque fois qu’une panne survient avec notre réseau de données notre réseau de voix va devenir une forme de réseau de sauvegarde pour notre réseau de donnée. En combinant les deux réseaux, la fragilité de la disponibilité augmente de manière drastique. N’importe quel businessman va immédiatement utiliser le téléphone de manière à pouvoir continuer les opérations, avec au moins le premier appel vers le technicien de service ou une personne de soutien aussi bien en interne qu’en externe. Cette situation crée un environnement qui pourrait devenir très attirant pour les pirates. En utilisant une attaque de type DoS par exemple, il devient très facile d’interrompre deux services à la place d’un seul, lesquels pourront permettre à un pirate malveillant d’exploiter très facilement cette opportunité si l’entreprise n’est pas protégée.

5.1.4 Vulnérabilités humaines

Ce type de vulnérabilités comprend le problème de l’administrateur réseau et de l’organisation de l’entreprise. Il y a une bataille entre le "facile à utiliser" et la sécurité d’un réseau. Dans l’environnement d’une petite entreprise, le problème est complexe parce qu’une minorité de personnes travaille sur plusieurs sujets différents afin de diminuer les coûts et parce qu’il n y a pas assez pour du travail à temps plein sur un sujet. L’autre problème est le coût d’une personne à plein temps avec beaucoup d’expérience afin d’éviter que l’entreprise compte sur des consultants externes, des revendeurs et/ou installeurs. Dans cette situation, la meilleure chose à faire est de laisser les décisions sur la sécurité à un consultant ou un revendeur qui ne porte pas beaucoup d’importance à consacrer du temps supplémentaire pour sécuriser et maintenir le réseau à moins qu’il soit spécifiquement engagé pour le faire.


sur 107 05.04.2005

5.2 Vulnérabilités à l’extérieur de l’entreprise

Si le réseau de donnée de l’entreprise n’est pas sécurisé est qu’il possède un accès à un WAN (Internet par exemple), alors le réseau de VoIP/SIP devient une cible très intéressante pour des personnes mal intentionnées. Une telle personne qui parvient à s’introduire dans le réseau de l’entreprise peut tout autant s’attaquer au réseau de donnée qu’au réseau de VoIP. Imaginons qu’une personne malveillante se trouvant sur son réseau domestique avec un accès Internet via NAT-routeur ait installé son proxy SIP. Il suffit qu’il connaisse l’adresse IP du outbound proxy de l’entreprise (avec une attaque de scanning de port et d’adresses IP par exemple afin de détecter si le port 5060 est ouvert sur une station) pour pouvoir l’utiliser en tant que passerelle média (en admettant que le outbound proxy se trouve dans la DMZ par exemple). Cette personne pourra ensuite s’attaquer aux UAs du réseau qui sont gérés par ce proxy. Il peut par exemple utiliser des attaques de DoS Bulk INVITE, SPAM d’INVITE ou d’IM. En vérité, toutes les attaques que l’on a vu à l’intérieur de l’entreprise qui ne nécessite pas de se trouver physiquement sur le même sous-réseau ou sur le même hub sont possibles (IP spoofing, registration hijacking, épuisement de ressources DHCP, etc.). Il n’est donc pas possible d’écouter des communications qui transiteraient au sein de l’entreprise, de détourner des appels en injectant un message 302 Moved Temporarily ou encore d’utiliser de l’ARP spoofing pour détourner les flux audio et la signalisation SIP. Un autre danger d’attaque peut survenir si l’entreprise possède un NAT pour sa connexion Internet et qu’elle a adopté un mécanisme de passage au travers du NAT (voir annexe Projet de semestre : Traversal FW/NAT). Si ce mécanisme met à contribution un élément réseau se trouvant sur le réseau public, il suffit que l’attaquant intercepte les messages transitant entre cette entité et le réseau d’entreprise. Grâce à ces messages, l’attaquant peut apprendre énormément d’informations sensibles (notamment les adresses IP mappées sur le NAT) qui peuvent lui permettre de s’attaquer directement aux UAs du réseau d’entreprise. Le plus grand danger reste l’attaque du relais RTP de l’entreprise. Si l’attaquant parvient à capturer ou détourner le trafic transitant à travers le relais (avec de l’IP spoofing par exemple) alors il pourra écouter toutes les communications entrantes et sortantes de l’entreprise. De manière analogue, il est possible de capturer tout le trafic de signalisation entrant et sortant de l’entreprise au niveau de la passerelle de signalisation. En résumé, n’importe quelle personne s’étant introduite dans le réseau d’une entreprise ayant déployé le service de VoIP/SIP sans mécanismes de sécurisation peut s’attaquer aussi bien au service de VoIP lui-même (DoS) qu’aux UAs du réseau.


sur 107 05.04.2005

6 ARCHITECTURES DE DÉPLOIEMENT DE LA VOIP/SIP Le but ici et de définir et de présenter les différentes architectures de déploiement possibles en tenant compte d’une configuration disposant d’un propre GW ISDN et d’une connexion VoIP à travers Internet pour communiquer avec d’autres filiales ou des collaborateurs itinérants. Voilà ce à quoi pourrait ressembler l’architecture globale du réseau considéré ci-dessous :

Figure 20 - Architecture globale du réseau

Il existe deux stratégies de déploiement possible d’un réseau téléphonique regroupant de la VoIP et de la téléphonie ISDN ou PSTN avec ou sans PBX [SA13] : l’architecture IP centrale (IP-centric) ou architecture IP hybride (IP-enabled) et l’architecture via ITSP (Internet Telephony Service Provider). Ces deux types d’architecture se différencient essentiellement par ces trois questions :

1. Où le PBX de conversion IP va se trouver ? D’où une transformation du PBX en PBX routeur puis en IP-PBX [SA14] (seulement dans le cas où un PBX existe et est nécessaire).

2. Où s’occuper des fonctions de centre d’appel, tels que la gestion des files (queuing, queue slot), le prompting, la musique de mise en attente et les annonces ?

3. Est-ce que nous avons besoin d’un système complet de téléphonie sur IP ou alors simplement quelques téléphone IP à utiliser. Dans ce cas, l’utilisation d’un ITSP est préférable.


sur 107 05.04.2005

6.1 Déploiement complet d’une plateforme de VoIP :

6.1.1 Architecture IP-enabled

Un système de ce type contient essentiellement le même noyau d’architecture qu’un système PBX (une matrice switchée TDM, un contrôle CPU/commun et un logiciel de traitement des appels) avec la possibilité supplémentaire de se servir aussi bien de téléphones standards TDM [SA15] que de téléphones IP via différentes cartes côté stations et côté terminaux du réseau IP. Le contrôle CPU/commun et le logiciel de traitement des appels peuvent rester dans la matrice switchée TDM ou sur un serveur externe. Dans un réseau de stations uniquement IP, l’architecture IP-enabled va influencer sur l’infrastructure de données de l’entreprise aussi bien pour les téléphones IP que pour la connectique des PCs. La plupart des téléphones IP permettent une connectique avec le PC à l’aide d’un commutateur mini-Ethernet afin de n’utiliser qu’un seul port sur le switch. Ce type d’architecture convient particulièrement bien aux entreprises qui désirent migrer vers la VoIP de manière progressive. Vous trouverez ci-dessous un exemple d’architecture IP-enabled adapté à un site unique :

Figure 21 - Déploiement d'un site unique suivant une architecture IP-enabled

Dans un environnement multi-sites, cette architecture simplifie la connectique inter-site. Les deux communications séparées utilisées pour la voix et les données dans un monde TDM sont combinées en une infrastructure de donnée uniforme.


sur 107 05.04.2005

Voici ci-dessous un exemple d’environnement multi-site IP-enabled.

Figure 22 - Déploiement d'un multi-site suivant une architecture IP-enabled

Ici, l’équipement de localisation de la société mère fournit toute l’intelligence de routage de l’entreprise et dirige les appels entrants au bon emplacement sur le WAN. Il est à noter que dans cet exemple, l’équipement du site B n’est composé que du strict minimum, à savoir un routeur, un switch et des téléphones IP. Les appels destinés au site B sont terminés sur le switch de la société mère, convertis en IP à la passerelle puis transportés au site B via l’infrastructure réseau et le WAN. Le site A peut recevoir des appels entrants depuis la société mère à travers le WAN de manière analogue au site B ou alors directement depuis le PSTN avec un contrôle d’appel à distance fourni par le switch de la société mère IP-enabled. Pour la plupart des vendeurs, cette configuration requiert l’addition d’une passerelle média au site A. Un WAN avec une QoS adéquate est décisif pour un déploiement de VoIP multi-site. Puisqu’ Internet ne supporte pas la QoS, la plupart des providers de services privés WAN offrent des conventions de niveau de services et des garanties de performances. Quelques providers permettent aux utilisateurs de donner un ordre de priorité aux paquets qui traversent le WAN en utilisant des techniques de QoS standard (par exemple 802.1 p/Q, DiffServ, MPLS, RSVP et WFQ).


sur 107 05.04.2005

Voici ci-dessous les avantages et les inconvénients des solutions basées sur une architecture IP-enabled : Avantages de IP-enabled Inconvénients de IP-enabled Inclut les composants TDM et le logiciel qui sont considérés comme prouvés et de technologie fiable.

Requiert des investissements importants dans la technologie propriétaire d’un vendeur unique.

Traitement efficace de l’appelant avec des services tels que la gestion des files d’attentes, les annonces, la musique en attente et autres.

Les configurations multi-site peuvent requérir des composants prioritaires additionnels (par ex : passerelle média), par ailleurs l’investissement augmente avec une solution de vendeur unique.

Mise à l’échelle très simple pour de grands centres d’appel qui doivent supporter un grand nombre de clients appelant en file. Permet la migration lente à IP pendant que l’investissement augmente et que les risques diminuent.

L’architecture mixée incluant des composants PBX et IP avec une complexité de gestion plus grande qu’avec des architectures IP-centric (voir point suivant).

Tableau 1 - Avantages et inconvénients de l'architecture IP-enabled


sur 107 05.04.2005

6.1.2 Architecture IP-centric

Les systèmes IP-centric décomposent complètement l’architecture du PBX. La matrice switchée TDM est remplacée par l’infrastructure de donnée de l’entreprise. Les fonctionnalités de contrôleur d’appels, de gestion de la file d’attente, des annonces et de la musique de mise en attente sont fournies via des processus serveur séparés qui peuvent ou pas résider sur des serveurs physiques séparés. Vous trouverez ci-dessous un exemple d’environnement de site unique suivant une architecture IP-centric :

Figure 23 - Déploiement d'un site unique suivant une architecture IP-centric

Dans le déploiement d’un site unique, un routeur doit jouer le rôle de la passerelle média. Par la suite, tout le traitement et la commutation des appels sont effectués avec des paquets. La fonctionnalité de contrôle d’appel est habituellement accomplie par un serveur séparé et peut être configurée dans un cluster pour assurer la redondance. La gestion des files d’appels, la musique d’attente et les annonces sont également accomplies via un serveur séparé : le serveur de média. Des serveurs de média additionnels peuvent être requis en fonction du nombre de sessions/connexions simultanées. Actuellement, chaque appel en file, que l’on soit en train d’écouter de la musique ou une annonce, est alloué sur un flux de VoIP dédié, lequel utilise des cycles CPU. Un système IP-centric se décompose de la même manière que précédemment pour un déploiement multi-site. Un serveur de contrôle d’appels centralisé contrôle les flux VoIP, qu’ils arrivent directement dans la société mère principale ou les sites distants. Avec ce type de déploiement, le serveur de contrôle d’appels (SIP proxy/registrar) de la société mère contrôle toutes les communications entrantes indépendamment de la localisation.


sur 107 05.04.2005

Les appels PSTN entrants à la société mère sont convertis de TDM en IP via la passerelle média (IP-PBX ou IPBX). Le serveur de contrôle d’appels établi un flux VoIP avec le serveur de média pour le traitement en file et ensuite connecte l’appel avec le téléphone IP approprié. La communication entre la société mère et les sites distants est similaire à la solution IP-enabled (voir Figure 24).

Figure 24 - Déploiement d'un multi-site suivant une architecture IP-centric

Voici ci-dessous les avantages et les inconvénients des solutions basées sur une architecture IP-centric : Avantages de IP-centric Inconvénients de IP-centric Fourni une architecture flexible et logique pour le routage des appels.

Une architecture décomposée requiert des plateformes de serveurs multiples.

Donne un nouvel élan à l’infrastructure de données et minimise les investissements en composants TDM.

Requiert une très grande fiabilité et robustesse de l’infrastructure de donnée.

Fournis une meilleure flexibilité dans les environnements distribués, spécialement dans les configurations avec une redirection locale d’appels dans de multiples petits sites.

Mise à l’échelle difficile pour le traitement d’un très grand nombre d’utilisateurs appelants en file.

Fournis un choix dans l’achat des éléments technologiques et autorise le mélange d’environnements pour les routeurs, les serveurs, les applications, etc.

Peut être considéré moins fiable ; peut ne pas être très bien adapté pour des opérations de central d’appel 24x7 (24h/24 7j/7).


sur 107 05.04.2005

Tableau 2 - Avantages et inconvénients de l'architecture IP-centric

6.2 Architecture via ITSP

Un provider de services de téléphonie par Internet (ITSP) utilise les réseaux IP pour fournir des connexions de voix/fax à bas prix à travers la combinaison d’Internet, des lignes louées et du réseau de téléphonie public commuté (PSTN). Un ITSP utilise donc Internet comme média de transport principal pour convoyer les données empaquetées de signalisation et de voix depuis et entre des abonnés. L’ITSP et ses abonnés seront connectés à Internet ; l’ITSP via des liaisons rapides dédiées tandis que les abonnés utilisent leurs connexions Internet habituelles (modems téléphoniques standards, xDSL, etc.) via différents providers de service Internet (ISPs). Un abonné a la possibilité d’utiliser différentes méthodes afin de passer un appel, toutes ces possibilités nécessitent que l’abonné présente ses credentials avant que la requête d’appel puisse être traitée. Un abonné a moyen d’utiliser un SoftPhone, un HardPhone ou d’autres appareils de téléphonies IP (par exemple des adaptateurs de téléphones pour pouvoir utiliser un téléphone standard en tant que téléphone IP) afin de passer l’appel. Une infrastructure d’ITSP inclut un support d’authentification, de facturation et d’autres dispositifs indispensables. L’ITSP utilise des passerelles de voix placées dans différents pays et connectées au backbone IP de l’ITSP à travers des lignes louées. L’ITSP va diriger une requête d’appel à la passerelle de voix appropriée en accord avec le numéro composé. La passerelle de voix va traduire les paquets de voix (si la requête d’appel a été acquittée par le partenaire appelé) et les paquets d’informations de signalisation convoyés par des protocoles basés sur IP en informations pouvant être convoyées par des protocoles utilisés avec les réseaux de téléphonie traditionnelle (SS7 ou autres) et vice versa. Vous trouverez ci-dessous un petit schéma illustrant l’utilisation d’ITSP pour communiquer avec un téléphone se trouvant sur le PSTN :


sur 107 05.04.2005

Figure 25 - Déploiement de la VoIP via un ITSP

Voici ci-dessous un exemple d’utilisation de MSN Messenger utilisant SIP à travers un ITSP Microsoft.

Figure 26 - MSN Messenger via ITSP

Les ITSP actuels supportent aussi bien des protocoles de signalisation tels que H323, SIP et MGCP. Cependant la souscription d’un abonnement chez un ITSP n’est véritablement adaptée qu’a des particuliers ne possédant que très peu de téléphones. En effet, il est vite intéressant, surtout du point de vue du prix, de mettre en place son propre système de VoIP/SIP au sein d’une entreprise mais cela est probablement inutile dans le cas de particuliers ne possédants que peu de téléphones.


sur 107 05.04.2005

Il subsiste néanmoins un problème avec ce type d’architecture de téléphonie. En effet Internet n’est utilisé que comme une "partie" de l’infrastructure de l’ITSP et par conséquent celui-ci est dans l’impossibilité de garantir une QoS (bande passante suffisante, pas de congestion, etc.), laquelle peut aboutir à une qualité réduite de la voix.

6.3 Architecture finale

Etant donné que l’architecture IP-enabled n’est qu’une étape plus ou moins longue de transition vers une architecture IP-centric et que la souscription d’un abonnement à un ITSP n’est pas adaptée pour une entreprise, on va prendre en considération ici uniquement l’architecture finale de déploiement IP-centric en supposant que celle-ci possède déjà un PBX avec liaison PSTN et ISDN ainsi qu’une connexion Internet. Il va donc falloir migrer vers une architecture SIP IP-centric simple. L’architecture devra à peu près s’apparenter à la Figure 24. Si nous le désirons, il y a même la possibilité de connecter le gateway ISDN sur le IP-PBX et nous obtenons ainsi une architecture entièrement centralisée. C’est donc en fonction de cette architecture que l’on va définir des stratégies et des mécanismes de sécurisation.


sur 107 05.04.2005

7 PRESCRIPTIONS DE SÉCURISATION DE LA VOIP/SIP D’ici un proche avenir, les mécanismes de sécurité les plus courants (authentification, chiffrage) feront partie intégrante des standards de VoIP/SIP. Toutefois, aujourd’hui il existe de nombreuses technologies de sécurité IP-centric qui peuvent être intégrées afin d’améliorer la sécurité de l’environnement de VoIP/SIP. La sécurité de réseaux de VoIP/SIP inclut la sécurité au niveau des paquets de voix, laquelle se concentre sur les fonctionnalités des applications, et la sécurité IP qui, elle, se concentre sur la sécurité du réseau ou du transport. Contrôler la sécurité à ces niveaux de l’environnement de VoIP/SIP peut nécessiter un redimensionnement et/ou une re-organisation technique du réseau. Ceci pourrait affecter l’architecture du réseau supportant l’environnement de VoIP/SIP. Quand un système de VoIP/SIP est déployé, certains aspects spécifiques demandent une attention plus approfondie. Ce sont ces sujets que nous allons prendre en considération afin de déployer la VoIP/SIP de manière sécurisée. Il est important de garder à l’esprit que sécuriser n’importe quel réseau est un processus continu qui nécessite d’être continuellement à l’écoute des dernières vulnérabilités qui peuvent subsister dans les composants de l’infrastructure réseau (serveurs, OS, applications déployées à travers l’entreprise). L’architecture de sécurité suivante (voir Figure 27) décrit un type générique de site d’entreprise avec le service de VoIP/SIP. Cette architecture peut être considérée comme la référence de base lorsque l’on désire sécuriser un réseau avec le service de VoIP/SIP. L’architecture ci-dessous est de type IP-centric. Il est également possible de sécuriser un réseau de type IP-enabled de cette manière.

Figure 27 - Architecture de sécurité logique


sur 107 05.04.2005

7.1 Sécurité physique

Les routeurs, les switchs Ethernet, les passerelles de téléphonie et les serveurs déterminent les limites du réseau de VoIP/SIP et peuvent jouer le rôle d’interfaces avec d’autres réseaux. Ces éléments de réseau peuvent fournir aussi bien la connectivité logique que physique du réseau d’entreprise complet et devraient être considérés comme les cibles particulières à défendre contre les attaques. Pour se prévenir contre les accès physiques non autorisés à ces éléments, des mesures doivent être prisent afin d’assurer leur protection. Ces précautions comprennent des accès restreints aux salles des serveurs et les installations réseaux doivent être uniquement accessible au personnel autorisé.

7.2 Séparation des adresses logiques

La VoIP/SIP fournit plusieurs moyens d’incorporation de la téléphonie sur un réseau IP existant. Toutefois, pour des raisons de QoS, de performance, de maniabilité et de sécurité, le déploiement des éléments de téléphonie IP et d’éléments de données IP doivent être déployés sur deux segments logiques IP séparés. La combinaison de segmentation données/voix ainsi qu’une infrastructure switchée atténue déjà fortement les attaques de types eavesdropping. De plus, la limitation de l’accès logique aux composants de VoIP/SIP est nécessaire afin de protéger les applications de téléphonie s’exécutant à travers l’infrastructure. Le fait de contrôler les accès aux éléments de VoIP/SIP (serveurs et terminaux) avec des filtres IP peut aider à assurer une sécurité et un soutient important pour protéger l’environnement de VoIP/SIP des menaces externes. Tous les éléments de VoIP/SIP (serveur proxy, serveur d’enregistrement, terminaux, etc.) devraient être déployés sur leur propre réseau ou sous-réseau IP privé. Idéalement, ces sous-réseaux devraient utiliser un espace d’adresses différent de celui utilisé dans les réseaux de données. Il faudrait, si possible, n’utiliser que des adresses non routables (privées) [réf. RFC 1918] afin de séparer de manière encore plus forte le réseau de VoIP/SIP et le réseau de données. Ceci permet de réduire les chances que le trafic de voix sorte en dehors du segment de réseau téléphonique et inversement. Des connexions réseau peuvent être requises entre les segments réseau de VoIP/SIP et de données afin de fournir des services tels qu’une boîte vocale de messages (voir "voicemail"). Dans ce cas de figure, afin d’aider à protéger le segment réseau de VoIP/SIP, le NAT devrait être implémenté sur le point de connexion du segment VoIP/données. Ceci fournit une protection supplémentaire qui aura comme effet que les hackers situés en dehors du segment réseau de VoIP/SIP seront incapables de scanner le segment de VoIP/SIP afin d’en découvrir les vulnérabilités et ceci à moins que le NAT ne soit pas implémenté ou mal configuré.


sur 107 05.04.2005

7.3 VLANs

Le trafic VoIP/SIP doit être divisé du réseau de données traditionnel en utilisant des réseaux locaux virtuels (VLAN). Dans un environnement réseau switché, les VLANs créent une séparation logique des domaines de collisions qui peut s’étendre aux multiples segments du réseau physique. La séparation des domaines de collisions sert à limiter le risque que des attaques de type DoS ou packet sniffing sur le réseau de données puissent affecter le réseau de voix et inversement. De plus, séparer la voix et le trafic de données dans des domaines de collisions distincts va réduire la concurrence d’accès pour le réseau et, de ce fait, va réduire également la latence (file/temps d’attente) pour les services de transmission. Il est inutile de rappeler que la VoIP/SIP est très sensible à cette latence (QoS). Cette approche de segmentation est donc le moyen le meilleur marché pour améliorer les performances dans une infrastructure réseau existante. Les VLANs peuvent donc accroître la sécurité de l’environnement de VoIP/SIP en segmentant la voix et les données pour les PCs qui sont connectés via des téléphones VoIP/SIP. Cette segmentation VLAN réduit également les problèmes de conflits potentiels avec les vidéophones quand tout ce qui est voix, données et vidéo vient de la même source. La mise en place des VLANs peut être configurée sur le principe du VLAN de ports. Les ports de VLAN pour la VoIP/SIP peuvent être sécurisés en assignant une adresse MAC d’un téléphone sur un port simple. Les ports VLAN du switch qui ne sont pas utilisés par des équipements de voix actifs doivent être désactivés ou assignés à un différent VLAN. De plus, certains téléphones VoIP/SIP possèdent des ports réseaux "built-in" qui ont comme but de pouvoir y connecter une station. Ce type de téléphone VoIP/SIP se doit de supporter la configuration de son port réseau dans un VLAN séparé et doit également permettre de désactiver l’utilisation de ce port. Le fait de désactiver les ports VLAN de VoIP/SIP non utilisés diminue le risque que des éléments réseau malveillants puissent être ajoutés dans le réseau de VoIP/SIP. Afin d’augmenter la protection contre ces éléments, un port VLAN peut être configuré pour uniquement connecter une adresse MAC bien précise. Lors de la mise en place de VLANs de segmentation des réseaux VoIP/données il est important de se poser ces quelques questions concernant l’attribution des adresses IP : Faut-il utiliser des adresses IP fixes pour les HardPhones IP ?

o Oui. Dans ce cas, on réserve deux pools d’adresses IP bien distincts pour les deux VLANs. Ceci n’est pas intéressant si il y a sur le réseau des SoftPhones qui utilisent déjà un service DHCP.

o Non. Dans ce cas, faut-il ajouter un serveur DHCP dédié au VLAN de VoIP ? Oui. Le serveur DHCP devra alors faire partie du VLAN de VoIP uniquement. Non. Le serveur DHCP global doit faire partie des deux VLANs. Ceci est la

moins bonne méthode d’un point de vue sécurité. En effet, il est fortement conseillé d’attribuer des adresses IP de pools différents pour les deux VLANs. Ceci est possible spécifiant sur le serveur DHCP que l’attribution des adresses IP se fait de manière statique pour les téléphones IP (et ceci grâce aux adresses MAC). Il faut donc connaître toutes les adresses MAC des téléphones et mettre sur place la liste d’adresses statiques. Si le réseau de VoIP est en perpétuel mouvement (ajout/suppression de téléphones), cette méthode devient vite très lourde. Il vaut de mieux éviter cette configuration au profit de la mise en place d’un serveur DHCP dédié à la VoIP.


sur 107 05.04.2005

7.4 SoftPhones et HardPhones IP

Les agents de SoftPhones IP résident par inhérence dans le segment de données mais requiert un accès au segment de voix afin de pouvoir contrôler des appels, passer des appels et de laisser des messages vocaux. Toutefois, les SoftPhones ne sont pas immunisés contre les attaques envers les HardPhones. Les SoftPhones PCs sont même plus vulnérables que les HardPhones et ceci pour la simple et bonne raison qu’il existe un grand nombre d’accès possibles dans un système PC. Ces possibilités d’accès dépendent de l’OS, des applications résidentes et des services autorisés qui sont tous sujets aux vers, aux virus, etc. De plus, les SoftPhones doivent résider à la fois sur le segment de données et sur le segment VoIP et sont de ce fait sensibles aux attaques envers l’entièreté du réseau et pas juste le PC lui-même. Par contre, les HardPhones IP doivent être situés dans le segment de VoIP/SIP et s’exécutent sur des OS propriétaires implémentant des services réseaux limités et ont donc certainement moins de vulnérabilités. Puisque le déploiement de SoftPhones fournit une brèche intéressante pour des attaques malveillantes envers le segment de voix, ces téléphones représentent un grand risque pour l’entièreté de l’environnement de VoIP/SIP. De nombreux HardPhones IP fournissent un port de donnée séparé pour la connexion d’un PC. Donc, seul un câble est requis pour permettre la connectivité de données et de voix sur le PC de l’utilisateur. En outre, certains HardPhones IP sont uniquement capables de fournir une connectivité basique de niveau 2. Ils jouent donc le rôle d’un hub en combinant les segments réseau de données et de voix. Tandis que d’autres téléphones IP offrent une connectivité de niveau 2 étendue permettant l’utilisation de la technologie VLAN afin de placer le téléphone et le trafic de données sur deux différents VLANs. Pour assurer une séparation logique de la voix et des données afin de maintenir la sécurité de l’environnement de VoIP/SIP, uniquement les HardPhones implémentant le VLAN de niveau 2 étendu doivent être utilisés. Voici ci-dessous un résumé des trois différentes configurations possibles de téléphones IP :

Figure 28 - Configurations de connexions de téléphones IP

1. La première configuration est appelée daisy-chain. Le HardPhone est connecté au

switch tandis le PC est connecté au téléphone. La particularité de cette configuration est que, sur le segment se trouvant entre le téléphone et le switch, deux types de trafics VoIP/donnée vont devoir cohabiter. Ceci implique que le port du switch doit être configuré de manière à pouvoir véhiculer les deux types de trafics simultanément grâce à une encapsulation (trunk).


sur 107 05.04.2005

2. La deuxième nécessite autant de ports sur le switch qu'il y a de terminaux (PC ou HardPhones).

3. La troisième est un SoftShone. La connectique se fait avec un câble par SoftPhone.

Il faut également faire attention à la connectique dans le cas où l’on souhaite utiliser un service de voicemail. En effet, n’importe quelles connexions entre les segments de voix et de donnée requises par les téléphones pour l’accès à la boîte vocale de messages doivent être contrôlées en bloquant l’accès direct des données au segment de réseau de voix afin d’éviter que les vulnérabilités de données et les tunnels de données ne compromettent le segment de voix. Ceci peut être effectué en plaçant un firewall entre les segments de voix et de donnée.

7.5 Firewalls

Les systèmes de VoIP/SIP requièrent que de nombreux ports soient “ouverts” dans le firewall afin d’éviter un délai sensible de remise des paquets. Le protocole utilisé pour convoyer le trafic (RTP/RTCP) de VoIP/SIP à travers le réseau utilise un large éventail de ports (10024 à 65535) pour transporter les paquets. La VoIP/SIP requiert quatre ports par connexion, deux pour la signalisation et deux pour l’émission/réception d’informations utiles d’utilisateur, la voix dans notre cas. L’ouverture d’un intervalle de ports aussi large va assurément compromettre tout le réseau. Il y a deux méthodes qui peuvent être utilisées pour aider à surmonter cette vulnérabilité ; le mapping de ports dynamique et le mapping de ports statique. Le mapping de ports dynamique limite la palette de ports qui pourraient être utilisée pour le trafic de VoIP/SIP. Ceci réduit le nombre de ports qui sont ouverts sur le réseau, mais avec quatre ports (1023 et plus) requis par connexion, ce nombre pourrait très vite augmenter. Cette option de configuration requiert un firewall statefull s’occupant de tous les appels de VoIP/SIP sortant du groupe de VoIP/SIP. Le mapping statique assigne quatre ports pour chaque ensemble de communication de VoIP/SIP. Cette option demande une quantité considérable de temps pour configurer les routeurs et doit être modifiée à chaque fois qu’un utilisateur de VoIP/SIP à besoin d’être ajouté ou retiré. Sans un firewall statefull s’occupant de toutes les connexions entre les réseaux de données et de voix, nous devrions autoriser de larges intervalles de ports. Les firewalls, les routeurs et les switchs doivent être implémentés de manière à compartimenter les serveurs de VoIP/SIP face aux accès non autorisés. Ceci est indispensable pour limiter et contrôler les accès depuis le réseau de données au réseau de téléphonie IP. Les firewalls sont à placer devant tous les réseaux et les composants supportant les serveurs de VoIP/SIP. Il faut au minimum qu’un filtrage IP soit implémenté entre les réseaux de donnée/voix. Ceci va diminuer la possibilité d’attaques qui pourraient provenir depuis le réseau de données.


sur 107 05.04.2005

Le tableau ci-dessous contient tous les ports potentiels et les services qui doivent être pris en considération dans le filtrage du firewall pour les réseaux et les serveurs de VoIP/SIP :

SERVICE PORT Skinny TCP 2000-2002 TFTP UDP 69 SIP UDP/TCP 5060 TLS TCP 5061 IPSec UDP/TCP 69, 161, 162,389 HTTP TCP 8080/80 MS Terminal Services TCP 3389 RTP/SRTP UDP/TCP 16384-32767 SNMP UDP 161 SNMPtrap UDP 162 DNS UDP 53 NTP UDP 123 LDAP TCP 389 Echo ICMP echo Echo-reply ICMP echo-reply MS-SQL TCP 1433 SSL TCP 443 SMB TCP 445 SCCP TCP 3224 HID agent TCP 5000 ICCS TCP 8002 CTIM (CTI manager) TCP 8003 OSS TCP 18080

Tableau 3 - Services et ports potentiellement utilisés par la VoIP/SIP

7.6 Gestion du firewall VoIP/SIP

Afin d’assurer la sécurité du firewall VoIP/SIP, il est impératif que les connexions administrative/gestion et les accès aux appareils soient contrôlés. Ceci peut se faire en accédant à ces types d’éléments localement ou en utilisant des VPN (IPSec) ESP (Encapsulated Secure Payload). Par mesure de sécurité il faudra donc décrire de manière explicite ces quelques règles dans le firewall :

• Soit bloquer les connexions administrative/gestion soit ouvrir IPSec en utilisant des VPN (ports 69, 161, 162, 389) sur le périmètre de sécurité VoIP/SIP.

• Bloquer MS-SQL (port 1433) sur le périmètre de sécurité VoIP/SIP. • Bloquer Network Time Protocol (NTP port 123) sur le périmètre de sécurité VoIP/SIP. • Tous les Remote Web Access (ports 80, 8080, 443, 8002, 8003, 18080, etc.) sur le

périmètre de sécurité VoIP/SIP sont proxiés. Ceci dépend du matériel et du logiciel de téléphonie SIP.

• Chiffrement des connexions Web sur le périmètre de sécurité VoIP/SIP.


sur 107 05.04.2005

7.7 Serveurs de VoIP/SIP critiques

Les serveurs de VoIP/SIP dit "critiques" (proxy, registrar, redirect, etc.) ont besoin d’être sécurisés et traités avec les mêmes précautions que tout autre serveur contenant de l’information sensible. Les systèmes de VoIP/SIP fournissent des dispositifs puissants de gestion, lesquels peuvent tagger les appels enregistrés de plusieurs manières afin d’aider pour les recherches futures. La mise en place des serveurs de VoIP/SIP est cruciale pour sécuriser l’environnement de traitement de la voix. Ces composants système doivent se trouver sur un segment réseau séparé et protégé par un firewall VoIP/SIP. Dédier et sécuriser les serveurs de VoIP/SIP critiques est la clef de voûte de la sécurisation de l’environnement de téléphonie IP. Certains vendeurs fournissent des services de téléphonie IP sur leurs propres systèmes propriétaire tandis que d’autres fournissent ces services sur les systèmes standard Unix/Linux et Windows. Par conséquent, la sécurisation du traitement de la voix et des plateformes de signalisation pour y inclure leurs applications est vitale dans la protection de l’environnement de VoIP/SIP contre les attaques. De plus, afin de minimiser les risques potentiels, ces serveurs sont dédiés aux applications de téléphonie IP requises pour les opérations de VoIP/SIP.

7.8 Scalabilité

Les serveurs SIP sont limités en nombre de communications simultanées. C’est pourquoi la notion de scalabilité est très importante en téléphonie. En effet, si le nombre d’utilisateurs augmente passablement, il faut que le service soit toujours accessible à tous les utilisateurs et cela sans modification majeure du réseau. Il est par exemple possible, si le nombre de téléphones le permet, de simuler un très grand nombre de communications SIP de manière simultanées. Si le serveur ne supporte pas un grand nombre de communications simultanées, il va saturer et ceci va créer un DoS au niveau de tous les utilisateurs gérés par ce serveur. Il faut donc utiliser des serveurs SIP pouvant gérer un très grand nombre de communications simultanées tel que Sip Express Router (SER) ou sipXpbx.

7.9 Filtrage des appels

Certains serveurs SIP permettent de filtrer des appels sur la base de plusieurs règles bien précises un peu à la manière d’un firewall. Cela permet, par exemple, d’interdire certaines adresses IP ou URI d’émettrent des messages INVITE ou REGISTER. Cela peut également faire en sorte qu’une certaine adresse IP ait le droit d’appeler sans être authentifiée auprès du serveur d’enregistrement. Un peu près toutes les règles de niveau 3, 4 et plus sont applicables. Il faut donc faire attention à bien sécuriser la plateforme de VoIP et pas le contraire.


sur 107 05.04.2005

7.10 Sécuriser la session SIP

Puisque la structure des messages SIP découle directement du modèle HTTP de requête/réponse, tous les mécanismes de sécurité disponibles pour HTTP peuvent être appliqués aux sessions SIP. D’un autre côté, l’utilisation de containers MIME (Multi-purpose Internet Mail Extension) dans les messages SIP suggère l’utilisation potentielle de mécanismes de sécurité d’email tels que PGP (Pretty Good Privacy) ou S/MIME (Secure/MIME). De manière similaire à HTTPS : l’URI sip correspondant sera l’URI SIPS. Ceci va créer un tunnel sécurisé au niveau transport en utilisant TLS (Transport Layer Security). IPSec est également utilisable comme mécanisme général de chiffrement pour toutes les communications IP au niveau réseau. Les mécanismes de sécurité essentiels adaptés à la protection de la session SIP sont représentés dans le Tableau 4. Ils coïncident avec la liste de méthodes recommandées par la version 1 du standard SIP. Pour le moment, deux de ces méthodes, à savoir l’authentification HTTP basique et PGP ont été dépréciés par la version 2 de SIP.

Méthodes d’authentification :

PSK Pre-Shared Key

PKI Public Key Infrastructure

Aut

hent

ifica

tion

Inté

grité

des

don

nées

Con

fiden

tialit

é

HTTP 1.0 Basic Authentification PSK - - Déprécié par SIPv2 Transmission non sécurisée du mot de passe

HTTP 1.1 Digest Authentification PSK - - Echange des challenges/réponses basé sur le hash MD5 d’un password, d’un username et d’un nonce.

PGP PKI Déprécié par SIPv2

S/MIME PKI Pour le chiffrement, la clef publique de l’UA de destination doit être connue.

SIPS URI (TLS) PKI Les applications et proxy SIP doivent supporter TLS.

IPSec PKI L’intégration avec des applications SIP n’est pas requise mais les proxy doivent être de confiance.

Tableau 4 - Securiser la session SIP

7.10.1 HTTP Basic Authentification

Cette authentification requiert la transmission d’un ‘username’ et de son ‘password’ correspondant à l’intérieur de l’entête de la requête SIP. Cette information utilisateur peut être utilisée par un proxy SIP ou par un UA de destination pour authentifier un client SIP ou le hop SIP précédent dans une chaîne de proxy. Puisque le ‘password’ en clair peut être très facilement capturé sur le réseau et que cela pose des risques de sécurité sérieux, l’utilisation de l’HTTP basic authentification a été dépréciée par SIPv2.


sur 107 05.04.2005

7.10.2 HTTP Digest Authentification

Cette authentification résout le problème de mot de passe en clair de l’HTTP basic authentification en transmettant un digest MD5 ou SHA-1 du mot de passe secret et d’une chaîne de caractère aléatoire à la place du mot de passe vulnérable uniquement. Bien que l’HTTP digest authentification à l’avantage que l’identité de l’utilisateur peut être établie sans la nécessité de transmettre le mot de passe en clair, cette procédure peut pourtant devenir une proie facile face aux attaques de dictionnaire off-line basées sur l’interception de valeurs de hash si des mots de passe faibles ou courts sont utilisés. Un autre grand désavantage est le manque de mécanisme de chiffrement pour assurer la confidentialité. Ni l’authentification basique ni l’authentification digest ne peut garantir une intégrité des messages SIP. Nous allons voir comment une requête SIP INVITE est authentifiée par le premier serveur proxy en utilisant ce type d’authentification (challenge d’authentification).

Figure 29 - Challenge d’authentification digest

Le proxy recevant le message SIP INVITE réponds immédiatement avec le challenge de la Figure 29 - Challenge d’authentification digest. Ce message contient un nonce [SA16] aléatoire et défini l’algorithme digest à utiliser (habituellement MD5 ou SHA-1) aussi bien que le domaine pour lequel l’utilisateur doit fournir une authentification. Sur réception du challenge, l’utilisateur renvoie un la requête INVITE d’origine mais sans oublier d’insérer la réponse au challenge dans l’entête du message SIP (voir Figure 30). La valeur de réponse contient le digest MD5 du ‘username’, du ‘password’, du ‘nonce’, de la méthode SIP et de l’URI de l’appelant. Ainsi le ‘password’ n’est pas transmis en clair. Cependant, le mot de passe doit être connu par le proxy afin d’être capable de vérifier la réponse d’authentification.


sur 107 05.04.2005

Figure 30 - Requête INVITE avec authentification digest

7.10.3 Pretty Good Privacy (PGP)

PGP peut être potentiellement utilisé pour authentifier et optionnellement pour chiffrer la cargaison MIME contenue dans les messages SIP mais la version 2 de SIP a déprécié l’utilisation de PGP en faveur de S/MIME.

7.10.4 Secure MIME (S/MIME)

Les messages SIP transportent des contenus MIME et ce standard inclut des mécanismes pour sécuriser les contenus MIME afin d’assurer aussi bien l’intégrité et la confidentialité grâce aux types MIME multipart/signed et application/pkcs7-mime. Des certificats X.509 sont utilisés pour identifier les utilisateurs finaux sur la base de leurs adresses emails, lesquelles sont une partie de l’URI SIP (par exemple : [email protected]). La signature des corps MIME est n’est pas vraiment un problème puisque chaque utilisateur est en possession de sa clef privée et que le certificat utilisateur peut être transmis au récepteur de manière incorporée dans les adjonctions pkcs7-mime ou multipart/signed. D’un autre côté, le chiffrement de contenus MIME, par exemple la cargaison SDP, requiert la préconnaissance de la clef publique du destinataire. Cette clef, habituellement certifiée par un certificat X.509 doit être obtenue soit au préalable depuis un répertoire public, soit peut être demandée de la part d’un agent via un message SIP spécial. Ceci induit de nouveaux problèmes de sécurité puisqu’il faut encore sécuriser ces éléments additionnels. La figure ci-dessous montre comment l’attachement SDP MIME incorporé dans la requête SIP INVITE de la Figure 30 peut être chiffré et signé avec S/MIME. La structure binaire envelopedData du type de contenu application/pkcs7-mime encapsule la cargaison SDP symétrique chiffrée et contient également la clef symétrique qui est chiffrée avec la clef publique du récepteur. Dans notre exemple, la cargaison chiffrée est également signée en utilisant la méthode multipart/signed. La signature plus le certificat X.509 optionnel du signataire sont contenus dans la structure binaire pkcs7-signature, laquelle est attachée après l’objet MIME à être signé. En tant qu’alternative, une structure binaire PKCS#7 signedData peut être utilisée pour transporter aussi bien les données à signer que la signature dans l’attachement.


sur 107 05.04.2005

Figure 31 - Attachement S/MIME chiffré et SDP MIME authentifié

Il est important de noter que l’utilisation de S/MIME pose des problèmes de temps de traitement des messages SIP/SDP. Lors de chaque réception, il faut extraire le corps et vérifier la signature de l’émetteur. Cela risque donc de ralentir la signalisation SIP. De plus, S/MIME ne protège pas contre des attaques de type man-in-the middle. Si quelqu’un arrive à se mettre entre les deux partenaires de signalisation SIP et que celui-ci possède un certificat valable il peut très bien intercepter les messages et injecter les siens pour une quelconque attaque.

7.10.5 SIPS URI (TLS)

L’implémentation de TLS pour SIP (qui rappelons le est dérivé de HTTP) est plus ou moins similaire à l’implémentation de SSL pour HTTP (HTTPS). Le protocole de chiffrement TLSv1 est dérivé de SSLv3. TLS fonctionne de manière indépendante par rapport aux applications qui l'utilisent. De plus, il est obligatoirement au dessus de la couche TCP. L’utilisation de TCP en lieu et place de UDP va légèrement diminuer la rapidité de la signalisation mais ceci est presque négligeable. L’utilisation d’URI SIPS de la forme sips:bob.bilboxy.com dans un message INVITE nécessite que TLS soit utilisé de façon générale comme URI SIPS de destination. Puisque chaque hop peut ajouter une information sur la route dans l’entête du messages SIP, la protection TLS doit être réalisée sur une base hop-by-hop sur chaque segment du chemin.


sur 107 05.04.2005

Voici ci-dessous l’architecture de TLS :

Figure 32 - Achitecture de TLS

Et ci-dessous le stack de sous-protocoles TLS :

Figure 33 - Sous protocoles TLS

La sous-couche Record a pour fonction de réceptionner les données des couches supérieures et de traiter les paquets de données (fragmentation en blocs de taille maximum de 214 bytes puis compression, calcul d’intégrité et chiffrement des données puis transmission des données au protocole TCP). La sous-couche CSS (Change Cipher Spec) à pour objectifs de signaler au protocole Record toute modification des paramètres de sécurité. La sous-couche Alert, quant à elle, signale les alertes (par exemple : fin de connexion, problème en cours de handshake, l’intégrité d’un message est douteuse, etc.).

Cou

che

TLS


sur 107 05.04.2005

La sous-couche Handshake est utilisée pour authentifier le serveur et le client. Il y a pour cela deux types d’authentification : l’authentification mutuelle et l’authentification simple. L’authentification mutuelle nécessite que le client et le serveur soient authentifiés. Dans le cas de l’authentification simple, seul le serveur est authentifié. L’authentification des entités est basée sur des certificats X.509, et l'authentification des données grâce aux MACs (Message Authentication Code) basé sur les fonctions de hashage MD5 (16 octets) ou SHA-1 (20 octets). Cette sous-couche a donc aussi pour objectif de négocier les algorithmes utilisés (cipher et MAC) et de générer la clef symétrique de session pour le chiffrement des données. Voici ci-dessous les principaux échanges lors d’un handshake TLS :

Figure 34 - Handshake TLS – Principaux échanges


sur 107 05.04.2005

Et ci-dessous une ouverture de session TLS :

Figure 35 - Handshake TLS - Ouverture de session

Exemple d’utilisation de TLS avec authentification simple : L’ouverture de session est ici un peu différente de la Figure 35. En effet, la demande de certificat de la part du serveur, l’envoi du certificat du client et la vérification de celui-ci par le serveur ne sont pas présents puisque l’authentification client n’est pas nécessaire. Le flux TCP suivant représente une connexion TLS à un hôte b.example.com. Notez que le client propose trois ensembles de protocole (y compris le protocole essentiel TLS_RSA_WITH_AES_128_CBC_SHA). New TCP connection #1: a.example.com(5071) <-> b.example.com(5081) 1 1 0.0015 (0.0015) C>SV3.1(49) Handshake ClientHello Version 3.1 random[32]= 3f 1d 41 76 31 6f af f1 42 fa 7b 57 c7 79 49 2b d4 21 9c be e9 8b 85 83 56 4b 36 cb f2 99 ef b2 cipher suites TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL


sur 107 05.04.2005

1 2 0.4307 (0.4292) S>CV3.1(74) Handshake ServerHello Version 3.1 random[32]= 3f 1d 41 77 92 f5 55 a3 97 69 cf b5 7a 0a 3c 00 bc 0c 59 91 1c 6b 2b 4a 0e 98 40 21 a9 b5 4b 6f session_id[32]= 10 3c 8c aa 75 d8 62 0b c3 5b ad 24 c1 7f 4f 80 25 b7 1c 40 a3 3c e1 85 0d b5 29 d3 15 40 51 d3 cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL 1 3 0.4307 (0.0000) S>CV3.1(822) Handshake Certificate Subject C=US ST=California L=San Jose O=sipit CN=b.example.com Issuer C=US ST=California L=San Jose O=sipit OU=Sipit Test Certificate Authority Serial 01 Extensions Extension: X509v3 Subject Alternative Name Extension: X509v3 Basic Constraints Extension: X509v3 Subject Key Identifier Extension: X509v3 Authority Key Identifier 1 4 0.4307 (0.0000) S>CV3.1(4) Handshake ServerHelloDone 1 5 0.4594 (0.0286) C>SV3.1(134) Handshake ClientKeyExchange 1 6 0.5498 (0.0903) C>SV3.1(1) ChangeCipherSpec 1 7 0.5498 (0.0000) C>SV3.1(48) Handshake 1 8 0.5505 (0.0007) S>CV3.1(1) ChangeCipherSpec 1 9 0.5505 (0.0000) S>CV3.1(48) Handshake

Une fois que la session TLS est active, le message SIP MESSAGE suivant est envoyé à b.example.com. Notez que l’URI est un SIPS URL et que le champ VIA indique que TLS est utilisé. MESSAGE sips:[email protected]:5081 SIP/2.0 To: <sips:[email protected]:5081> From: <sip:[email protected]>;tag=2639484b Via: SIP/2.0/TLS b.example.com:5071; branch=z9hG4bK-c87542-240491824-1-c87542- Call-ID: 7ba3572175b0f542 CSeq: 1 MESSAGE Contact: <sips:[email protected]:5071> Max-Forwards: 70 Content-Type: text/plain User-Agent: SIPimp.org/0.2.1 (curses) Content-Length: 2 >>>Hi<<<

La réponse 200 OK est envoyée depuis b.example.com à a.example.com sur les mêmes connexions TLS. La voici : SIP/2.0 200 OK To: <sips:[email protected]:5081>;tag=514db9e7 From: <sip:[email protected]>;tag=2639484b Via: SIP/2.0/UDP b.example.com; branch=z9hG4bK-c87542-240491824-1-c87542-;received=127.0.0.1 Call-ID: 7ba3572175b0f542 CSeq: 1 MESSAGE Contact: <sips:[email protected]:5081> Content-Length: 0


sur 107 05.04.2005

TLS avec authentification mutuelle : Ce type d’authentification nécessite que le client soit authentifié à l’aide de son certificat X.509 en plus de l’authentification du serveur. L’ouverture de session ressemble donc à la Figure 35. Voyons un peu plus en détails un certificat client et la clef associée. Le certificat d’Alice est représenté ci-dessous : Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Validity Not Before: Jul 20 14:29:54 2003 GMT Not After : Jul 19 14:29:54 2004 GMT Subject: C=US, ST=California, L=San Jose, O=sipit, [email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:f0:9f:91:9a:6d:6f:81:b9:9d:67:db:5f:be:95: 3a:29:8a:cc:73:dd:b9:7a:33:c8:f9:52:dd:99:13: 04:2b:f1:9b:c2:f5:93:72:7a:9b:e1:97:fc:c2:d2: 96:d0:76:db:b5:0e:47:b1:59:74:59:5b:b0:73:ad: c8:64:bd:59:1c:67:1a:82:2f:c2:cf:53:87:d3:2b: 5a:dc:e6:3c:8c:27:a0:ab:6e:7f:4d:86:dd:2b:9b: e3:69:3b:f0:aa:1b:ad:f2:ab:1e:44:46:b2:8a:ab: 85:2c:81:13:03:98:06:65:57:0c:ff:c3:4f:02:cb: ed:79:e5:81:19:c7:02:e2:1b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: email:[email protected] X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: DE:0C:46:FC:B7:4C:CE:6B:73:99:22:C2:3D:A9:DE:53:EC:BF:69:66 X509v3 Authority Key Identifier: keyid:6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 DirName:/C=US/ST=California/L=San Jose/O=sipit/ OU=Sipit Test Certificate Authority serial:00 Signature Algorithm: sha1WithRSAEncryption 95:2c:fb:26:83:35:4a:3c:da:20:be:74:1a:1f:80:7f:27:61: dc:27:f1:a9:7b:2e:a7:24:31:1f:f7:c9:77:cd:0f:bf:02:9b: 8d:d5:35:42:6d:90:60:30:4c:6b:f4:7f:11:4d:a0:3f:1e:9c: d2:2b:e0:4b:4f:fc:fa:37:43:68:e2:d8:32:29:bd:6e:22:e6: ef:0e:97:b0:d9:92:49:ae:46:95:38:ab:a5:11:de:fa:dc:1b: ae:30:6b:48:2c:a3:c5:26:71:a6:23:58:a2:d2:57:4a:b1:ae: d8:45:c6:9a:71:8b:01:e9:ac:95:5e:9a:2c:67:ae:c3:5d:2b: 7c:9d


sur 107 05.04.2005

Et voici la clef d’Alice : 0: 604 cons: SEQUENCE 4: 1 prim: INTEGER :00 7: 129 prim: INTEGER : F09F919A6D6F81B99D67DB5FBE953A298ACC73DDB97A33C8F952DD9913042BF19B C2F593727A9BE197FCC2D296D076DBB50E47B15974595BB073ADC864BD591C671A 822FC2CF5387D32B5ADCE63C8C27A0AB6E7F4D86DD2B9BE3693BF0AA1BADF2AB1E 4446B28AAB852C811303980665570CFFC34F02CBED79E58119C702E21B 139: 3 prim: INTEGER :010001 144: 128 prim: INTEGER : 4764C0F9D5E090D7F6E91AC0E4B638249D471E55BA3394EBDB7607C3E44D87904F 4BE03B586B229723D65E23C795A0BE7D90F81A99D518B248BF79DF8C6C55E4B135 6249D82F9B18C37525FA05D3562399E4912BC902FA92CF12D7AE653C3C0D851A4B B3DF35E8722006460FC076E02D012D3CF233D1934100FEC7EAC72DE989 275: 65 prim: INTEGER : FA5A76D62011E3A219B4D89CF2A392FF57A55BC4E1092EC67030E31ABEDC591485 C284250BC0195C33A92920B340B2636EBB880C3DC6E2748A6045A07FCC2E97 342: 65 prim: INTEGER : F60CEC61DB985C1AE0F927E831AADA2E1DF889D135E91A49B662B8094CF140075A 9C782DF6A28F538D2C51CC4910CB02B159894FB597D17A3FB69DDD37099D1D 409: 64 prim: INTEGER : 53E735A495A2E9334E823986801B2A0CC186FDB681E4DDF44B6D56EF83BFBD6B0F 591D887CE3A89C2A042B707622DCA64E5A33424701FCAB2A2511B0B4A3ED89 475: 65 prim: INTEGER : CBD8F91E39E888A65C2D103AF6AB2E07771D2A5101F115AE6C446D64873278719F 4872E8E1A4DC49C4742B70AC3815792DA598754965764F69E9C9F03460EAA1 542: 64 prim: INTEGER : 021CFC8DEC23F4B82BE937CD45B819AE8C5777BFF14C74F719FFBBF3EB567A563A 9B2256EC3563E764B269DC34BFEC772BE443484D974B8FF07C52D9BF95DC24

Pour résumer, on peut dire que TLS assure une authentification (client)/serveur ainsi que l’intégrité et la confidentialité des messages SIP. Mais son utilisation n’est pas gratuite. En effet, l’utilisation de TLS va induire un overhead [SA17] plus ou moins léger suivant le type d’authentification (mutuelle ou non) et du cipher choisi. Cet overhead est négligeable sur une petite quantité d’appels simultanés mais peut devenir important pour des grands ITSP par exemple. Il est important de noter que ce protocole est particulièrement intéressant à l’intérieur d’entreprises ne comportant pas de NAT. En effet, tout réseau d’entreprise nécessitant un NAT pour communiquer avec l’extérieur nécessite que les ports TCP utilisés sur le NAT pour les connexions TLS restent ouverts en permanence pendant les communications. D’un point de vue sécurité et de performance, ceci pose encore problème. Il est donc peut être préférable d’utiliser IPSec pour des datagrammes UDP bien que celui-ci induise un overhead très important et donc une altération de la QoS.

7.10.6 IP Security (IPSec)

IPSec est un mécanisme général qui peut être utilisé pour protéger les messages SIP proprement au niveau IP. Avec SIP, chaque proxy sur le chemin doit avoir un accès en lecture/écriture sur l’entête des messages SIP afin de pouvoir ajouter/retirer des valeurs VIA. L’utilisation d’IPSec ESP (Encapsulating Security Payload) ou AH (Authentification Header) en mode transport doit donc être utilisée sur une base hop-by-hop. Les associations de sécurité IPSec nécessaires peuvent être établies de manière permanente sans participation active des UAs SIP utilisant les connexions ou alors il est également possible de se faire à la volée par les UAs et les proxy eux-mêmes en étroite interaction avec le stack IPSec sous jacent.


sur 107 05.04.2005

Le protocole IKE (Internet Key Exchange) qui est utilisé pour mettre en place les associations de sécurité IPSec supporte aussi bien l’authentification basée sur PSK que PKI. Etant donné que les adresses IP des UAs SIP sont le plus souvent dynamiques et attribuées en accord avec le droit d’accès au réseau, IKE en mode principal (Main Mode) ne fonctionnera pas avec des PSS (pre-shared secrets) et qu’IKE en mode agressif (Aggressive Mode) est chargé de problèmes de sécurité (attaques de types man-in-the-middle, dictionnaire off-line sur le PSK, etc.), l’authentification basée sur une clef publique sera une méthode préférable. Cela veut dire que l’établissement d’un état de confiance globale dans les certificats X.509 est encore le problème récurent majeur. Il subsiste néanmoins des problèmes de NAT avec IPSec en ce qui concerne la modification des entêtes IP (niveau 3). Le problème vient du chiffrement de l'en-tête IP par les participants au tunnel IPSec. Si l'adresse IP est modifiée pendant le trajet du paquet, elle ne sera pas la même à l'arrivée que celle qui a été encryptée au départ, et après comparaison, le paquet sera détruit. Cependant, en se plaçant en mode ESP et en faisant du tunneling, c'est la totalité du paquet qui est chiffrée, et une nouvelle en-tête est ajoutée à celui-ci. Malheureusement, cette solution n'est pas toujours possible. Cependant, il existe une réelle solution pour parer à ce problème. Il s'agit d'encapsuler les données dans un tunnel UDP. Ainsi, de la même façon qu'en mode tunnel et ESP, l'en-tête modifiée par le NAT ne sera pas utilisée pour le test d'authentification. D'ailleurs la plupart des constructeurs ont créé leurs propres solutions IPSec pour traverser le NAT.


sur 107 05.04.2005

7.11 Sécuriser les flux de média temps réel

Les flux multimédia sont orientés paquets et sont transportés en utilisant le protocole RTP (Real-Time Transport Protocol) basé sur de l’UDP non fiable. Afin d’avoir un retour d’information sur la qualité du flux de paquets reçu, l’agent utilisateur retourne un rapport en utilisant RTCP (Real-Time Transport Control Protocol). Puisque les connexions audios et vidéos en temps réel sont très sensibles aux délais de temps (time delay) et aux larges variations de délais (gigue ou jitter), un quelconque chiffrement de paquet et un algorithme d’authentification ne devraient pas influencer ces paramètres de manière significative. A cause de ces contraintes temps-réel, la transmission doit être basée sur UDP. Ci-dessous (voir Tableau 5) sont listés uniquement deux mécanismes de sécurité actuellement utilisables.

Méthodes d’authentification : PSK Pre-Shared Key PKI Public Key Infrastructure

Aut

hent

ifica

tion

Inté

grité

des

don

nées

Con

fiden

tialit

é

Secure RTP (SRTP) PSK Utilise une clef maîtresse qui doit être distribuée par un moyen externe à SRTP (MIKEY ou paramètre k dans la cargaison SDP)

IP Security (IPSec) PKI L’intégration avec des applications SIP n’est pas requise mais les proxy doivent être de confiance.

Tableau 5 - Sécuriser les flux média temps réel (RTP)

7.11.1 Secure RTP (SRTP)

Le protocole SRTP est une extension du profil audio/vidéo de RTP qui fournit une confidentialité, une authentification de messages et une protection de répétition du trafic RTP et RTCP. L’utilisation d’AES en mode stream cipher garanti une grande sécurité tout en n’augmentant pas la taille de la cargaison chiffrée. Le tag d’authentification nécessité pour l’intégrité des données ajoute dix bytes à chaque paquet RTP/RTCP mais peut être réduit à quatre bytes si un canal de communications très lent est utilisé. Donc, aussi bien les paquets RTP que RTCP peuvent être respectivement sécurisés de manière cryptographique par SRTP et Secure Real-Time Transport Control Protocol (SRTCP). Voyons un peu plus en détail les formats de messages, la génération de clef de session et la distribution des clefs primaires.


sur 107 05.04.2005

Le format de paquet SRTP :

Figure 36 - Format de paquet SRTP

Le format de messages SRTP est représenté à la Figure 36. Comme on peut le voir, seul le corps de cargaison RTP est chiffré (en incluant un quelconque padding [SA18] RTP). Tant que toutes les transformations courantes de chiffrement n’ajoutent pas de padding, la taille de la cargaison RTP n’est pas augmentée par le chiffrement. Le champ de clef MKI (Master Key Identifier) est optionnel et identifie la clef primaire depuis laquelle les clefs de session sont dérivées. Le MKI peut être utilisé par le récepteur pour retrouver la clef primaire correcte quand le besoin d’un renouvellement de clefs survient. Le numéro de séquence sur 16 bits déjà présent dans le paquet RTP (voir Figure 10) est utilisé de manière simultanée avec le compteur de rollover de 32 bits (Roll Over Counter), qui se trouve être une partie du contexte cryptographique, pour la session SRTP afin de se prévenir contre des replay attacks. Le tag d’authentification est un checksum cryptographique calculé sur l’entête et le corps du paquet RTP. Son utilisation est fortement recommandée étant donné qu’il protège les paquets contre une quelconque modification non autorisée. La longueur par défaut du tag est de 10 bytes mais peut être réduit si le canal de transmission ne permet pas une grande augmentation de la taille des paquets RTP.


sur 107 05.04.2005

Le format de paquet SRTCP :

Figure 37 - Format de paquet SRTCP

La Figure 37 démontre que les paquets RTCP sont sécurisés de manière similaire que les paquets RTP. La seule différence réside en l’utilisation obligatoire du tag d’authentification. Sinon, il peut être possible pour un attaquant malveillant de terminer un flux média RTP en envoyant un message SIP BYE (DoS par injection de messages). Un champ supplémentaire est l’index SRTCP qui est utilisé en tant que compteur de séquence afin de se prémunir contre d’éventuelles replay attacks. Le bit de poids fort ‘E’ du champ index est utilisé en tant que flag de chiffrement qui est mis à 1 si le corps RTCP est chiffré. Algorithmes de chiffrement par défaut : En principe, n’importe quel schéma de chiffrement peut être utilisé avec SRTP. En tant qu’algorithmes par défaut, le cipher NULL (pas de confidentialité) et AES-CTR (Advanced Encryption Standard in Counter Mode) sont définis. En effet, le chiffrement par AES standard ne permet pas de chiffrer des flux. La définition du chiffrement par AES-CTR est représenté dans la Figure 38.

Figure 38 - Chiffrement en utilisant AES-CTR


sur 107 05.04.2005

Cet algorithme de chiffrement joue le rôle de générateur de clefs (sous forme de flux) qui produit une clef pseudo-aléatoire de longueur arbitraire qui va s’appliquer de manière bit-à-bit à la cargaison RTP/RTCP. Le chiffrement sera effectué à l’aide d’une fonction logique XOR de la clef de flux et de la cargaison RTP/RTCP, et travaillera ainsi en tant que cipher de flux. AES lui-même est un cipher avec un bloc de taille de 128 bits et une taille de clef de 128, 192 ou 256 bits. Afin de pouvoir fonctionner en tant que générateur pseudo-aléatoire, AES est chargé au début de chaque paquet RTP/RTCP avec un vecteur d’initialisation distinct (IV). Ce vecteur est obtenu en hashant une salt_key (clef propre à chaque utilisateur) de 112 bits, le champ SSRC du flux média et l’index du paquet. Le chiffrement de l’IV abouti en un output de 128 bits pseudo-aléatoires. Ensuite, le IV est incrémenté de 1 puis à nouveau chiffré, cela génère les 128 bits suivants de la clef sous forme de flux. En continuant de compter tout en incrémentant l’IV de 1, autant de blocs de clefs (sous forme de flux) peuvent être générés que nécessaire pour chiffrer la totalité de la cargaison RTP/RTCP. Un quelconque bit en reste du dernier bloc de clef sous forme de flux sera simplement jeté. AES utilisé en mode de comptage au lieu du mode le plus habituel cipher block chaining (CBC) a le grand avantage que la clef sous forme de flux peut être précalculée avant que la cargaison ne soit disponible et ainsi cela minimise les délais introduits par le chiffrement. De plus, en utilisant un cipher de flux au lieu d’un cipher de bloc, il n’y a pas besoin d’utiliser de bits de padding pour augmenter la taille de la cargaison à un multiple de la taille de bloc. Ceci devra ajouter 15 bytes d’overhead au paquet RTP/RTCP dans le pire des cas. Algorithme d’authentification par défaut :

Figure 39 - Authentification en utilisant HMAC-SHA-1

L’algorithme d’authentification de messages SRTP par défaut est HMAC-SHA-1. Celui-ci est basé sur la fonction de hash sur 160 bits SHA-1. La sécurité cryptographique est accomplie en hashant un secret auth_key de 160 bits dans un checksum qui est ensuite tronqué à 80 bits afin de réduire l’overhead du paquet et qui a, de plus, l’avantage de cacher l’état interne complet de la fonction de hash. Dans les applications où la transmission en bande de base est un problème, le tag d’authentification peut être réduit à 32 bits. Dérivation de la clef de session : Les deux algorithmes de chiffrement et d’authentification requièrent des clefs symétriques secrètes de session qui doivent être connues de tous les agents participant à la session SIP. Ceci augmente le problème logistique de la génération de clef de session et de la distribution. Le standard SRTP offre une solution partielle en dérivant tous les besoins de clefs de session depuis une clef commune principale mais laisse libre la distribution de la clef principale.


sur 107 05.04.2005

La Figure 40 représente comment les clefs de session sont calculées à partir de la clef primaire unique. A nouveau, le cipher de bloc AES est utilisé en mode comptage pour générer le keying material (clefs, certificats et vecteurs d’initialisations) nécessaire. La clef primaire, qui peut avoir une taille de 128, 192 ou 256 bits, joue le rôle de clef de chiffrement AES. Le générateur pseudo-aléatoire est chargé avec un IV qui est lui-même une fonction d’une valeur master_salt de 112 bits, un byte label et un numéro de clef de session (session key number). En appliquant les labels 0x00 à 0x05, le chiffrement, l’authentification et les salting keys pour RTP et RTCP sont dérivés depuis la même clef primaire. Si un taux de dérivation de clef (key derivation rate) a été défini alors à chaque fois qu’un nombre de paquets équivalent au taux de dérivation de clef ont été envoyés, un nouveau jeu de clefs de session RTP et RTCP sont calculés. Si le taux de dérivation de clef est mis à 0 alors le même jeu de clefs sera utilisé pour toute la durée de la session.

Figure 40 - Dérivation des clefs de session

Distribution de la clef primaire : Nous voici devant le problème crucial de distribution de la clef primaire aux UACs en tant que partie de l’initiation de session. Une approche possible est d’utiliser MIKEY (Multimedia Internet KEYing) pour établir le contexte cryptographique SRTP. MIKEY est un nouveau protocole global d’échange de clef similaire à IKE (Internet Key Exchange) d’IPSec mais qui a été taillé sur les demandes spécifiques d’environnements multimédia. Actuellement, MIKEY est très peu implémenté et, de ce fait, n’est donc pas une bonne solution étant donné le peu de références. Il existe un autre système plus simple pour l’échange de clefs. Le paramètre k ‘key’ définit par SDP peut être utilisé pour transmettre la clef primaire. La Figure 41 représente un message SIP INVITE classique qui convoie tous les paramètres nécessaires à l’établissement de sessions multimédia de manière incorporés dans le corps MIME application/sdp.


sur 107 05.04.2005

Figure 41 - Requête SIP INVITE convoyant un corps SDP MIME

Dans cet exemple, nous voyons apparaître le paramètre k contenant la clef primaire SRTP de 128 bits. Puisque nous arrivons à lire la clef vous comprenez bien quels problèmes de sécurité cela implique. C’est pourquoi il serait intéressant de mettre en place des mécanismes de chiffrement du protocole SIP (avec TLS) et du contenu SDP (avec S/MIME).

7.11.2 IP Security (IPSec)

En tant qu’alternative, les cargaisons temps-réel peuvent être correctement protégées au niveau réseau par IPSec en utilisant la même association de sécurité déjà négociée pour protéger les messages SIP échangés entre les UAs. Un sérieux inconvénient peut être le grand overhead encouru par l’encapsulation ESP qui peut être dans le pire cas au alentour de 37 bytes par paquet IPSec pour un chiffrement 3DES (8 bytes d’entête ESP, 8 bytes AES IV, 2 à 9 bytes de trailer ESP et 12 bytes de HMAC) et même jusqu’à 53 bytes pour un chiffrement AES (8 bytes d’entête ESP, 16 bytes AES IV, 2-17 bytes de trailer ESP et 12 bytes de HMAC). Par exemple, si un codec audio G.711 est utilisé, le codec génère un échantillon de parole de 8 bits chaque 125 µs et 10 ms de parole non compressée sont mappés en 80 échantillons contigus contenu dans un seul paquet RTP. Dans ce cas, l’overhead IPSec sera entre 30-50%.


sur 107 05.04.2005

7.12 RADIUS et AAA

RADIUS (Remote Authentication Dial In User Service) est un protocole et une application client/serveur qui permet d’authentifier des utilisateurs et autoriser leurs accès à tel ou tel système ou service. Ce système est un élément de sécurité très intéressant au niveau de l’entreprise. C’est pourquoi il serait intéressant de combiner RADIUS et SIP pour de la VoIP sécurisée. Malheureusement pour le moment, il n’existe pas de standard pour l’utilisation de RADIUS avec SIP. Actuellement, c’est l’authentification basique et digest qui sont utilisées dans SIP. Récemment, le groupe de travail AAA (protocole d’Authorizatrion-Authentifiction-Accounting) de l’IETF a beaucoup travaillé sur un protocole extensible d’authentification (Extensible Authentication Protocol) dans le protocole SIP. L’avantage est que de nouveaux modèles d’authentification peuvent être utilisés sans modifications du protocole SIP. Ceci est dû au fait que le paquet EAP, pour un modèle d’authentification particulier, est convoyé de manière transparente par le protocole SIP. Toutefois, l’utilisation des authentifications basique et digest sont actuellement préférables pour continuer à être utilisées directement dans le protocole SIP. D’ici un proche avenir, leur interopérabilité avec une authentification de type RADIUS sera une réelle nécessité. D’ailleurs, SER (SIP Express Router) dans sa dernière version nous donne la possibilité d’installer un module d’authentification RADIUS en collaboration avec le proxy SIP. Cela laisse à croire que l’utilisation de RADIUS en entreprise pour la VoIP n’est qu’une question de temps. La Figure 42 décrit un scénario générique où le UAC et le proxy SIP communiquent en utilisant le protocole SIP de manière standard alors que le Proxy SIP et le serveur RADIUS communiquent en utilisant RADIUS tout en restant transparent au UAC.

Figure 42 - Scénario d'authentification de UAC avec RADIUS


sur 107 05.04.2005

L’ordre d’envoi et de réception des messages est le suivant : - L’UAC envoie au proxy SIP une requête SIP (1) sans l’entête ‘authorization’ (voir point

7.10.2 "Digest Authentification"). - Ensuite le proxy demande à l’UAC à l’aide d’une réponse "407 Proxy Authentication

required" (2) (voir Figure 29) de renvoyer la requête SIP avec le champ ‘authorization’. - L’UAC envoie alors au proxy SIP la requête SIP avec l’entête ‘authorization’ (3). - Puis le proxy SIP envoieau serveur RADIUS un "RADIUS Access-Request" (4). - Le serveur RADIUS répond au proxy SIP avec une réponse "RADIUS Access-

Accept/Access-Reject" (5). Si les credentials sont acceptés, alors le proxy SIP reçoit une réponse "Access-Accept" et le message envoyé par l’UAC est considéré comme authentique.

- Si le proxy SIP reçoit une réponse "Access-Reject", le proxy SIP répondra alors à l’UAC

avec une réponse "407 Proxy Authentication required" (6). D’ici un avenir plus ou moins proche, le système de contrôle d’accès AAA (Authentication, Authorization et Accounting) pourra lui aussi être combiné avec le service de VoIP afin de garantir une sécurité d’accès au service la plus robuste que possible puisque AAA gère également l’accounting (contrairement à RADIUS).

7.13 Gestion d’accès à distance des serveurs de VoIP/SIP

Les accès logiques sur des ports d’administration par une personne non autorisée et peu scrupuleuse peuvent avoir comme résultante un impact négatif sérieux sur l’entièreté de l’environnement de VoIP/SIP. Un quelconque accès à distance sur les serveurs critiques supportant l’environnement de VoIP/SIP dans le but de les administrer ou de les gérer doit se faire de manière sécurisée. Il faut donc que tous ces accès se faire de manière chiffrée grâce à des protocoles et de mécanismes tels que VPN, SSH, SSL, etc.

7.14 Connexions VoIP/SIP WAN-à-WAN

Quand des connexions VoIP/SIP WAN-à-WAN sont établies, la confidentialité d’appel est lésée. Afin d’assurer le même respect de cette confidentialité que celle fournie par les PSTN existants, il faut chiffrer tous les appels WAN-à-WAN. Ceci peut se faire de plusieurs manières : Le chiffrement de bout-en-bout, lequel requiert que les téléphones IP aient beaucoup de puissance de traitement et la capacité de supporter le chiffrement, ce qui n’est pas toujours possible. Quant aux vendeurs de VoIP/SIP, ils ne fournissent pas tous la possibilité de chiffrer (tout du moins pour le moment, ces vendeurs sont actuellement une minorité) depuis le terminal abonné. Toutefois, le chiffrement peut être effectué au niveau liaison (link-layer) à travers l’utilisation de la technologie VPN. Les passerelles sont normalement désignées pour supporter de lourdes charges de traitement et sont également capable de fournir un chiffrement au niveau liaison. Si ceci est implémenté, alors les deux méthodes seront transparentes pour la communauté d’abonné.


sur 107 05.04.2005

7.15 Firmware et logiciels propriétaires des fabricants

Nous avons vu qu’il existe de nombreuses vulnérabilités au sein des OS constructeurs de téléphones IP et dans les logiciels qui sont utilisés pour la VoIP (CallManager, proxy SIP logiciels, SoftPhones, etc.). Il faut donc en permanence mettre à jour toutes les versions de firmware et de logiciel afin de limiter les risques d’attaques.

7.16 IDS/IPS SIP

L’utilisation d’un IDS/IPS spécialisé pour SIP permettre d’éviter la plupart des attaques de types buffer overflow au niveau du protocole SIP sur les serveurs de VoIP. Il est basé sur une vérification de validité des messages SIP en contrôlant que tous les champs principaux correspondent bien à la RFC. De plus, un bon IDS peut détecter des suites de messages hors contextes (par exemple : réception d’un message BYE sans qu’il n’y ait eu de requête INVITE). Ce mécanisme de défense convient aussi bien pour les attaques externes que pour des attaques internes.

7.17 NAT

L’utilisation de NATs permet à la fois de parer au manque flagrant d’adresses IP publiques mais aussi bien de cacher le réseau privé au réseau publique. C’est donc un élément de sécurité très intéressant. Mais cela n’est pas sans frais, en effet, l’utilisation d’un NAT avec de la VoIP crée des problèmes de translations d’adresses contenues dans la cargaison des messages SIP. Il est possible de contourner ce problème mais cela peut induire de nouvelles failles de sécurité. Si la méthode utilisée pour parer au problème du NAT nécessite la mise en place de systèmes sur le réseau publique (Turn, STUN, etc.), il faudra alors s’assurer que ces systèmes soient sécurisés de manières à ne pas compromettre la sécurité du réseau privé (voir annexe : Projet de semestre - Traversal Firewall/NAT).

7.18 Relais RTP

Si des relais RTP sont utilisés pour router les flux temps-réel à travers le réseau d’entreprise et à travers Internet, il faudra impérativement sécuriser ces relais afin que personnes de non autorisé ne puisse y avoir accès sous peine de pouvoir écouter toutes les communications transitant à travers les relais. La sécurisation de ces relais peut se faire de la même manière qu’un serveur de VoIP critique. Il faut déjà limiter l’accès physique à chaque relais et utiliser des mécanismes de contrôle à distance sécurisés.


sur 107 05.04.2005

7.19 Services de Voice Mail VoIP/SIP

Le service de boîte vocale de messages dans un environnement de VoIP/SIP peut se faire suivant différentes configurations. Par exemple, une plateforme voicemail peut se connecter à une passerelle de VoIP/SIP pour fournir les services aux utilisateurs de VoIP/SIP. En plus de fournir ce service, de nombreux systèmes de voicemail sont également capables de fournir une messagerie unifiée en interagissant avec les systèmes de messagerie e-mail existants. Avec la messagerie unifiée, le serveur de voicemail doit être logiquement connecté au réseau de donnée. La plateforme de voicemail doit être configurée pour être connectée à la passerelle VoIP/SIP à travers un firewall d’inspection statefull. Le firewall doit être configuré pour refuser tout le trafic entre le VLAN de voix et le réseau de donnée sauf le trafic nécessaire pour transférer et recevoir des appels vocaux et des messages entre les téléphones abonnés, la passerelle VoIP/SIP et la plateforme de voicemail. Cette configuration est nécessaire afin de limiter les risques d’attaques de type DoS sur le réseau de donnée et/ou le réseau de VoIP/SIP. Le fait de filtrer le trafic va également diminuer le risque d’exploits de vulnérabilités sur les OS supportant les services de téléphonie de VoIP/SIP. Le service de voicemail est généralement configuré pour s’exécuter sur des OS ordinaires, tels que Microsot Windows NT/2000 et Unix/Linux. La marche à suivre doit être faite de telle manière qu’elle assure que ces OS sont sécurisés. Les applications supportant le service de voicemail doivent aussi être sécurisés. Par exemple, MS SQL Server peut être utilisé pour supporter les droits d’accès des abonnés ou MS IIS (serveur Web de Microsoft) peut être utilisé pour permettre aux abonnés de changer leurs paramètres de voicemail en utilisant un navigateur Internet via un protocole sécurisé tel que SSL (telnet et HTTP doivent être désactivés).

7.20 Wireless LAN et VoIP/SIP

Au fil que la technologie de VoIP se développe, la combinaison de la VoIP et de la technologie sans fil est vite devenue un cas réel d’implémentation de grande envergure (il existe déjà des téléphones SIP sans fils, les HardPhones SIP wireless). Une relativement nouvelle possibilité dans le domaine du wireless est d’utiliser le standard 802.11 WLAN. Cette nouvelle technologie suscite encore d’avantage les intérêts de la VoIP tels que la QoS, la capacité du réseau, le dimensionnement, l’architecture et surtout la sécurité. Le succès de la VoIP/SIP sur la technologie WLAN sera lié à la capacité que les WLANs ont de supporter de manière adéquate la QoS. Beaucoup de gouvernements sont en train d’étudier les solutions mobiles de communication qui comprennent la VoIP/SIP sur WLAN, ce qui permet de définir des besoins critiques communs en ce qui concerne l’interopérabilité et la flexibilité.


sur 107 05.04.2005

8 LABORATOIRE : VULNÉRABILITÉS DE LA VOIP/SIP

8.1 Introduction

Le but est ici d’illustrer au mieux les différentes vulnérabilités d’un réseau VoIP/SIP à l’intérieur de l’entreprise. On va commencer nos tests avec une plateforme SIP non sécurisée. Cela va nous permettre d’effectuer des attaques de toute sorte. Par la suite, le but est de sécuriser le réseau afin de démontrer l’efficacité des mécanismes de défenses qui ont été mis en place.

8.2 Matériel nécessaire

• 1 station Windows XP qui fera office de serveur SIP proxy/registrar en un premier temps puis en un deuxième temps, cette station fera office de UAC avec un OS Linux Debian sur lequel sera installé un SoftPhone sécurisé

• 1 station Linux Debian qui, en un premier temps, fera office d’attaquant (on suppose que l’attaquant est employé dans l’entreprise et qu’il possède un SoftPhone comme ses collègues) pour les tests de vulnérabilités et en un deuxième temps, cette station fera office de UAC avec un OS Linux Debian sur lequel sera installé un SoftPhone sécurisé

• 2 HardPhones IP CISCO 7960 • 1 station Windows XP avec SoftPhone qui fera office d’attaquant (on suppose que

l’attaquant est employé dans l’entreprise et qu’il possède un SoftPhone comme ses collègues) pour les tests de vulnérabilités

• 1 switch CISCO Catalyst 1912 qui servira à simuler un réseau d’entreprise commuté • 1 hub 4 ports qui servira pour la captures des messages SIP et des flux RTP • 1 station Linux Debian qui fera office de serveur SIP proxy/registrar sécurisé.

8.3 Mise en place du réseau SIP

La première étape dans ce laboratoire est de mettre en place le réseau de test SIP non sécurisé. Afin d’éviter tout problème avec le reste du réseau, j’ai décidé de me séparer du réseau de l’école et ainsi de travailler sur mon petit sous-réseau local. Il faudra donc spécifier des adresses IP fixes pour tous nos éléments réseaux. Il faut donc tout d’abord installer le serveur SIP proxy/registrar. J’ai choisi d’utiliser un logiciel libre s’exécutant sous Windows (OnDoSipServer 1.2.7.0) Ce logiciel fait office de proxy et de registrar avec ou sans authentification (voir annexe Logiciels utilisés). Une fois l’installation terminée il faut tester si la communication peut s’établir. On installe donc deux SoftPhones sur une station Windows et Linux. J’ai choisi d’utiliser X-Lite qui est un logiciel très didactique fonctionnant soit avec Windows soit avec Linux. Après configuration des deux SoftPhones et la mise en place du switch on peut donc passer notre premier appel.


sur 107 05.04.2005

Ceci étant fait, il reste à installer les deux téléphones IP CISCO 7960. Il faut tout d’abord mettre à jour les versions du firmware SIP et ceci à l’aide des fichiers fournis par CISCO. Il suffit de mettre en place un serveur TFTP avec les fichiers concernés. J’ai choisi d’installer le serveur TFTP sur la même station que les serveurs proxy/registrar SIP. Après redémarrage des téléphones, la mise à jour du firmware SIP s’effectue automatiquement (il faut au préalable spécifier l’adresse du serveur TFTP dans les téléphones). Ensuite on teste la communication entre HardPhone <-> HardPhone et HardPhone <-> SoftPhone. Tout est parfait. Le réseau de base de laboratoire non sécurisé est représenté à la Figure 43 :

Figure 43 - Réseau de test SIP non-sécurisé


sur 107 05.04.2005

8.4 Quelques attaques au niveau interne du réseau

La première des attaques qui est à la fois simple et efficace à mettre en place est de type DoS. En effet, nous avons vu qu’il y a moyen d’effectuer des DoS rien qu’en injectant un ou des messages SIP dans le réseau au bon moment et à la bonne personne.

8.4.1 DoS – CANCEL :

Le but est ici de faire croire à un UAC appelé que son partenaire désire annuler son appel. L’annulation d’un appel auquel le partenaire n’a pas encore répondu se traduit par l’envoi d’une réponse CANCEL en SIP. Il faut donc que l’on fasse passer pour l’appelant en injectant un message CANCEL destiné à l’appelé tout en respectant les champs de l’entête SIP. Il est également possible de faire l’inverse. C'est-à-dire que l’on peut faire croire à l’appelant que l’appelé ne désire pas répondre à l’appel. Remarque : Pour toutes les attaques nécessitant l’injection de messages dans le réseau, il faut ABSOLUMENT respecter la conformité de plusieurs champs. En effet, seul six des champs contenu dans un message SIP sont contrôlés par le proxy ou le registrar. Ces champs sont les suivants : INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.0.102:5060;branch=z9hG4bK488667a0 From: "2222" <sip:[email protected]>;tag=000628d8a74600180d37cff2-4f11b716 To: <sip:[email protected]> Call-ID: [email protected] CSeq: 101 INVITE User-Agent: CSCO/7 Contact: <sip:[email protected]:5060> Expires: 180 Content-Type: application/sdp Content-Length: 249 Accept: application/sdp v=0 o=CISCO-SIPUA 18170 14660 IN IP4 192.168.0.102 s=SIP Call c=IN IP4 192.168.0.102 t=0 0 m=audio 28690 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Remarque : Si le système d’authentification du serveur d’enregistrement est activé alors le champ ’Authorization’ est également contrôlé. Il faut donc OBLIGATOIREMENT trouver un moyen de pouvoir sniffer les messages transitant entre les UAs (dans ce cas présent nous utilisons le hub) afin de pouvoir en extraire les informations contenues dans les champs contrôlés. En effet, si ces critères ne sont pas respectés alors notre attaque sera soldée par un message de réponse ‘481 Call/Transaction Does Not Exist’ venant du proxy.


sur 107 05.04.2005

Ceci étant compris, il nous est maintenant possible d’effectuer le DoS – CANCEL. Pour cela, il suffit d’initier une communication depuis un des téléphones mais sans décrocher à l’autre bout. C’est à ce moment là qu’il faut injecter le message CANCEL et l’envoyer au partenaire qui n’a pas encore décroché. Ceci étant fait, le partenaire appelé comprend que l’appelant désirait raccrocher alors que ce n’était pas le cas. De son côté, l’appelant continue d’attendre que son partenaire décroche (mais en vain, en fait jusqu’à la fin du ‘time out INVITE’ du proxy). C’est donc un DoS sur l’appelé et l’appelant. Voici un diagramme explicatif :

Figure 44 - DoS CANCEL


sur 107 05.04.2005

8.4.2 DoS – BYE :

Pour ce DoS il suffit à l’attaquant d’attendre que la communication soit établie entre les deux partenaires. A partir de ce moment là nous pouvons injecter un message BYE (attention, le message BYE étant considéré comme une requête le champ CSeq doit être incrémenté de 1 lors de l’injection du message) à l’attention d’un des deux partenaires. Celui qui va recevoir le message va donc couper la communication pendant que l’autre croit encore que celle-ci est établie. Voici un nouveau diagramme explicatif :

Figure 45 - DoS BYE


sur 107 05.04.2005

8.4.3 DoS – Bulk REGISTER :

Le fait d’envoyer une très grande quantité de messages REGISTER avec des URI différentes au serveur d’enregistrement cause le remplissage complet de la liste d’enregistrement. Ce qui veut dire que nos deux téléphones IP, s’ils ne sont pas déjà enregistrés, ne pourront donc plus s’enregistrer. Cela provoque donc un DoS sur tous les téléphones qui désireraient s’enregistrer auprès du serveur d’enregistrement. Les différentes requêtes REGISTER seront alors refusées par le serveur. Pour cette attaque, il n’est pas nécessaire de devoir sniffer les messages si l’on connaît déjà l’URI du proxy. Cette attaque est représentée à la Figure 46 :

Figure 46 - DoS Bulk REGISTER

Remarque : Il est également possible pour l’administrateur de détecter une attaque Bulk REGISTER en analysant la liste d’enregistrement (voir Figure 47).


sur 107 05.04.2005

Figure 47 - Extrait de liste d'enregistrement après attaque DoS - Bulk REGISTER

En effet, si les entrées ne correspondent pas aux téléphones IP autorisés, alors l’on sait qu’une attaque a lieu en ce moment ou il y a peu de temps. On peut même en tirer l’adresse IP de l’attaquant avec le champ ‘Requester’ qui est identique dans toutes les requêtes venant du pirate.


sur 107 05.04.2005

8.4.4 DoS – Bulk INVITE :

Il est possible d’effectuer un DoS sur un téléphone bien précis en envoyant depuis notre station attaquante une petite dizaine d’INVITE identiques à la même URI. Le téléphone va sonner et répondre à toute les invitation qu’il peut supporter. Après cela la communication au niveau du téléphone sera interrompue mais pas sur le proxy. En effet, c’est comme si la communication est bien réel mais qu’elle n’est pas visible pour le téléphone attaqué. Comme pour le DoS Bulk REGISTER sans authentification, cette attaque ne nécessite pas de pouvoir sniffer les messages SIP si on connaît l’URI du téléphone cible. Cette attaque est représentée à la Figure 48:

Figure 48 - DoS Bulk INVITE dirigé sur un téléphone

Il y a donc DoS sur [email protected] alors qu’en fait les messages INVITE proviennent d’un générateur de messages SIP. Seulement le partenaire ne le sais pas et crois qu’on l’a coupé. Dans notre cas l’appel a duré 30 secondes avant la coupure.


sur 107 05.04.2005

De plus, la session est encore réellement perçue par le proxy puisque le téléphone n’a pas arrêté correctement la session. Voici donc ce que voit le proxy :

Figure 49 - Session inexistante

Si le téléphone 2222 veut par la suite passer un appel et que la session est encore activée sur le proxy alors celui-ci lui répondra par un message ‘603 Decline’. Pour un utilisateur standard, il est impossible d’effacer cette session au niveau du proxy. Elle devra faire appel à l’administrateur du réseau. Il serait donc possible d’effectuer ce DoS sur un maximum de téléphones différents et ainsi de bloquer une grande partie des utilisateurs.

8.4.5 Débordement de tampon (buffer overflow) :

Il existe des programmes permettant de scanner les vulnérabilités de types Buffer Overflow (entre autres) d’un serveur SIP. Quelques unes de ces attaques peuvent conduire à une exposition aux exploits typiques de débordement de tampon, permettant l’exécution de code arbitraire ou la modification de système ciblé. Vous trouverez en annexe le résultat d’un scanning de vulnérabilités de notre proxy SIP (voir annexe Résultat du test de vulnérabilités de type Buffer Overflow).

8.4.6 Détournement d’appel (call hijacking) :

Il est très simple de détourner un appel SIP. Cela peut se faire au moyen d’un message 301 moved permanently ou 302 moved temporarily. En effet, ces messages sont utilisés lorsque le call forwarding est activé de manière permanente ou temporaire. Il suffit donc de faire croire à un UAC qui tente d’établir un appel que son partenaire à activé le call forwading tout en spécifiant dans le message SIP qu’il faut contacter l’attaquant. Notre générateur de messages ne supporte que le message 302. Il suffit donc d’intercepter un message INVITE venant d’un des téléphones et d’injecter notre message 302 en spécifiant dans le champ ‘contact’ qu’il faut transférer l’appel vers notre SoftPhone [email protected].


sur 107 05.04.2005

Voici le diagramme des communications lorsque la call forwarding est activé sur le téléphone appelé [email protected] (l’URI de transfert utilisée ici est [email protected]) et l’appelant est notre SoftPhone (qui ne joue pas ici son rôle d’attaquant mais de simple appelant) :

Figure 50 - Appel avec transfert d'appel temporaire au moyen du message 302 moved

temporarily

Voici le message 302 que nous allons injecter avec le champ contact qui nous intéresse (les valeurs de branch, tag, call-ID et CSeq seront mis à jour) : SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP 192.168.0.100:5060;branch=z9hG4bK5568dd8e2ae90, SIP/2.0/UDP 192.168.0.101:5061;rport;branch=z9hG4bK45B81468A81A4029890C5C65E0CB5E47 From: 1234 <sip:[email protected]:5061>;tag=1456031938 To: <sip:[email protected]>;tag=000628d8a7460006222bd7e0-2b9d81d1 Call-ID: [email protected] CSeq: 36174 INVITE Server: CSCO/7 Contact: <sip:[email protected]:5060> Record-Route: <sip:192.168.0.100:5060;lr> Content-Length: 0


sur 107 05.04.2005

Remarque : Il subsiste néanmoins un problème avec les champs ‘tag’ et ‘branch’. En effet, ces champs sont différents d’une session à l’autre. Cela ne nous permet donc pas de pouvoir injecter notre message 302 avant que le téléphone appelé sonne (messages 100 trying et 180 ringing). Voici deux appels successifs démontrant le changement de valeurs des champs ‘tag’ et ‘branch’ d’une session à l’autre : SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.0.100:5060;branch=z9hG4bK60e8995318052, SIP/2.0/UDP 192.168.0.102:5060;branch=z9hG4bK6e8aa5f5 From: "2222" <sip:[email protected]>;tag=000628d8a7460020284410f7-38952018 To: <sip:[email protected]>;tag=003094c3b55f002221002837-351f92e3 Call-ID: [email protected] CSeq: 101 INVITE Server: CSCO/7 Contact: <sip:[email protected]:5060> Record-Route: <sip:192.168.0.100:5060;lr> Content-Length: 0 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.0.100:5060;branch=z9hG4bK7d3de9488a07d, SIP/2.0/UDP 192.168.0.102:5060;branch=z9hG4bK0ea1a3f3 From: "2222" <sip:[email protected]>;tag=000628d8a746001f1a70e356-7102f646 To: <sip:[email protected]>;tag=003094c3b55f00210354a38a-2aa9d9e6 Call-ID: [email protected] CSeq: 101 INVITE Server: CSCO/7 Contact: <sip:[email protected]:5060> Record-Route: <sip:192.168.0.100:5060;lr> Content-Length: 0 Il nous faudra donc activer notre SoftPhone [email protected] et attendre son enregistrement auprès du serveur avec ou sans authentification afin de pouvoir recevoir l’appel détourné initié depuis le téléphone [email protected] au téléphone [email protected].


sur 107 05.04.2005

Voici ci-dessous le diagramme en flèche des communications avec l’attaque de détournement d’appel :

Figure 51 – Détournement d’appel à l'aide d'un message 302 moved temporarily

Rien ne nous empêche alors de nous faire passer pour quelqu’un d’autre au téléphone puisque l’appelant croit avoir atteint la personne qui désirait appeler. De plus, sur l’affichage du téléphone le nom d’utilisateur est celui que l’appelant désirait appeler. Il est de coutume en entreprise que lorsque quelqu’un est absent, il transfert tous les appels vers les secrétaires. En nous faisant passer pour un secrétaire nous pouvons sûrement en tirer des informations utiles. Remarque : Il faut absolument que la personne appelée ne réponde pas AVANT que l’on ait injecté le message 302 si l’on ne veut pas que notre tentative de détournement soit vouée à l’échec. Le temps que cela m’a pris est de quelques secondes, cela peut paraître long mais en général le téléphone sonne bien quelques secondes avant que l’on décroche et cela surtout si l’on est occupé. Si la personne répond APRES l’injection de notre message, alors elle se croira en communication avec la personne appelante alors que ce n’est plus le cas. Il y donc DoS sur la personne appelée.


sur 107 05.04.2005

8.4.7 Ecoute indiscrète d’autres communications (eavesdropping) :

L’écoute non autorisée de communication est possible avec SIP. En effet, le flux RTP n’est pas chiffré. Il suffit donc de se débrouiller pour capturer le flux RTP puis de le convertir en un fichier audio. Remarque : L’écoute de flux RTP est trop compliquée pour être effectuée en temps réel. Il va falloir enregistrer ce flux, puis le convertir et écouter la communication en différé. En ce qui concerne les messages instantanés SIP, le contenu du message instantané se trouve dans le payload du message SIP, et donc transite sur le réseau en clair. Pour pouvoir effectuer une écoute non autorisée, il faut donc considérer les deux cas suivants :

1. Nous nous trouvons physiquement sur le même hub que le téléphone IP cible ou sur le même hub que le proxy SIP. Dans ce cas il est vraiment très simple d’écouter la communication en différé ou de lire les messages instantanés. Voici à la Figure 52 un message instantané capturé sur notre hub :

Figure 52 - Message instantané transitant en clair sur le réseau

Et voici un flux RTP capturé également sur le hub : No. Time Source Destination Prot Info 15 2.68 192.168.0.101 192.168.0.102 RTP Payload type=ITU-T G.711 PCMU, SSRC=1605747604, Seq=52845, Time=8422592 16 2.70 192.168.0.101 192.168.0.102 RTP Payload type=ITU-T G.711 PCMU, SSRC=1605747604, Seq=52846, Time=8422752 18 2.72 192.168.0.101 192.168.0.102 RTP Payload type=ITU-T G.711 PCMU, SSRC=1605747604, Seq=52847, Time=8422912 20 2.74 192.168.0.101 192.168.0.102 RTP Payload type=ITU-T G.711 PCMU, SSRC=1605747604, Seq=52848, Time=8423072

Remarque : Attention ! Actuellement avec cette version d’Ethereal (0.10.7) seul le codec G.711 est utilisable. D’autres programmes effectuant la même conversion de flux ne fonctionnent qu’avec ce codec. D’ici quelques temps la plupart des codecs seront gérés.


sur 107 05.04.2005

2. Nous sommes connectés à un switch. Il va donc falloir trouver un moyen pour capturer le flux RTP. Il existe une technique d’attaque de switch qui consiste en l’envoi de trames avec chacune une adresse MAC source différente (CAM attack). La table CAM (paires adresse MAC-port) du switch arrivera vite à saturation. De cette manière le switch devrait avoir un comportement similaire à celui d’un hub.

Remarque : Cela fonctionne uniquement si l’attaquant se connecte sur le switch avant les téléphones IP dont on veut pouvoir écouter les conversations. Si ce n’est pas le cas alors les adresses MAC des téléphones associées aux différents ports du switch seront conservées dans la CAM. Il faut alors trouver un moyen de vider la CAM (ce qui n’est pas du tout trivial d’accéder au switch suivant le type de switch et les couches OSI implémentée – MAC, IP). Le mieux étant de déconnecter ou de redémarrer les téléphones (voir point 5.2.1 "Vulnérabilités des systèmes d’exploitation") et de remplir la CAM. Il suffit donc de connaître l’adresse MAC du switch pour pouvoir l’attaquer. Voici un extrait de la CAM après remplissage : Address Dest Interface Type Source Interface List ---------------------------------------------------------------------------- 0008.7447.187A Ethernet 0/4 Dynamic All 00C0.4F21.DA8C Ethernet 0/5 Dynamic All AAAA.AA00.0000 Ethernet 0/4 Dynamic All AAAA.AA00.0001 Ethernet 0/4 Dynamic All AAAA.AA00.0002 Ethernet 0/4 Dynamic All AAAA.AA00.0003 Ethernet 0/4 Dynamic All AAAA.AA00.0004 Ethernet 0/4 Dynamic All AAAA.AA00.0005 Ethernet 0/4 Dynamic All AAAA.AA00.0006 Ethernet 0/4 Dynamic All AAAA.AA00.0007 Ethernet 0/4 Dynamic All L’adresse MAC 00:08:74:47:18:7A est celle de l’attaquant et la 00:C0:4F:21:DA:8C est celle du registrar/proxy. La CAM est donc inondée au maximum (cette limite dépend du type et du constructeur du switch), cette valeur vaut 984 dans notre cas (switch CISCO Catalyst 1912), et nous pouvons maintenant capturer le trafic sur le switch. Pour récupérer la conversation, se référer au point précédent. La seule limitation est que ne pouvons écouter que le trafic transitant par les UA connectés au switch. Remarque : Il est possible de se faire passer pour le proxy à l’aide d’ARP spoofing (en spoofant l’adresse du vrai proxy et ceci uniquement si nous nous trouvons sur le même sous-réseau) ou de messages 30x. Nous devons alors modifier l’entête Via pour ajouter l’adresse IP et le port du proxy comme le fait un vrai proxy et nous devons également router tous les messages de signalisation SIP aux bon partenaires en parsant les messages afin de découvrir les adresses IP de destinations. Si ceci est effectué correctement alors nous ferons office de proxy comme convenu et nous obtiendrons tous les messages de signalisation (y compris les messages instantanés) mais aucun paquet RTP. En effet, le flux RTP n’est établit qu’entre les deux partenaires en communication (voir Figure 2).


sur 107 05.04.2005

Si nous voulons effectuer de l’ARP spoofing au moment ou le flux RTP est transmis afin de pouvoir récupérer le flux tout en le routant aux bons destinataires il y a un nouveau problème : en effet, lors d’envoi de paquets RTP les téléphones n’ont plus besoin d’effectuer des ARP request et cela nous rend impossible le détournement par ARP spoofing. Ceci est apparemment un problème spécifique aux téléphones CISCO Catalyst 7960. Il est également à noter que cette technique d’attaque de switch est valable pour toute les attaques nécessitant la capture de messages SIP sur le réseau (DoS CANCEL/BYE, Call Hijacking, etc.).

8.4.8 SPAM - INVITE :

Nous avons vu qu’il est possible d’effectuer du SPAM d’INVITE. En fait, il est très facile de faire sonner plusieurs téléphones en même temps avec SIP. Il s’agit ici pour l’attaquant de connaître les URI de tous les téléphones concernés ainsi que l’adresse du serveur proxy/registrar. Ensuite il suffit de créer un message par URI et de les envoyer en même temps. Tous les téléphones sonneront donc en même temps. Comme pour les attaques de type DoS - Bulk REGISTER sans authentification et DoS - Bulk INVITE, cette attaque ne nécessite pas forcément de pouvoir sniffer les messages SIP si l’attaquant connaît déjà les URI et l’IP du/des serveurs. Cette attaque est représentée à la Figure 53 :

Figure 53 - SPAM d'INVITE

Remarque : Si le nombre de téléphone que vous voulons spamer est supérieur à la limite de communications simultanées admise par le proxy/redirect (environ 25 dans notre cas) alors notre attaque se soldera, en plus du spam lui-même, par un DoS du proxy/redirect (et donc du réseau SIP complet sous contrôle de ce serveur) dû à un nouveau type d’attaque Bulk INVITE sur le serveur.


sur 107 05.04.2005

8.5 Prévention : mécanismes de sécurisation et réflexes utiles

Dans un premier temps nous allons continuer d’utiliser notre proxy OnDo SIP Server et nos HardPhones SIP. OnDoSip Server permet de d’utiliser l’authentification digest et également de créer des règles de filtrages d’appel. Les HardPhones CISCO 7960 supportent également l’authentification digest. La Figure 54 représente notre nouveau réseau de test :

Figure 54 - Réseau de test SIP sécurisé Digest Authentification, Filtrage d’appel et IDS/IPS

VoIP/SIP

Nous pouvons voir que le mécanisme Digest Authentification est utilisé au niveau des UACs. Il faut également éviter au maximum les hubs. Nous allons voir juste après quels sont les différentes utilités de sécurité des différents mécanismes de sécurisation.


sur 107 05.04.2005

8.5.1 Switch :

Comme vu précédemment, les attaques de types DoS CANCEL/BYE et Call Hijacking par injection de message 302 oblige l’attaquant de respecter les champs qui sont contrôlés ainsi que de savoir à quel moment il doit injecter ses messages malicieux. Il doit donc, pour cela, pouvoir capturer ces informations. L’attaquant doit donc se trouver sur le même hub que les différents partenaires visés par l’attaque ou éventuellement avec le proxy utilisé par ceux-ci. Il suffit donc de n’utiliser que des switchs afin de rendre ces données inatteignables à l’attaquant. Si celui-ci décide d’injecter des messages SIP par la force brute en testant toutes les possibilités de valeurs de champs afin que l’un de ses messages correspondent bien à la transaction concernée il est très peu probable qu’il y parvienne dans les temps. Dans le cas d’un DoS CANCEL, l’attaquant n’a comme temps que celui que met le partenaire appelé à décrocher le combiné. Dans le cas d’un DoS BYE, le temps imparti à l’attaquant est la durée de communication entre les deux partenaires. Mais attention ! Il est cependant possible que l’attaquant se procure un petit hub personnel qu’il se chargera de placer sur le réseau de manière judicieuse, comme par exemple entre les téléphones et le proxy/regitrar ou encore entre les téléphones et un switch (bien qu’encore faut-il qu’il aie physiquement accès à ces emplacements stratégiques sur le réseau). L’attaque de la CAM du switch est également possible mais difficile (voir point 8.4.7 " Ecoute indiscrète d’autres communications (eavesdropping)").

8.5.2 VLANs :

La configuration de deux VLANs séparés (un VLAN donnée et un VLAN VoIP) permet à la fois de cacher le réseau de VoIP aux utilisateurs du réseau de donnée uniquement mais cela évite également la propagation de collisions en dehors d’un VLAN. Nous gardons la plateforme de test sécurisée (voir Figure 54). La station Linux sera utilisée en tant que SoftPhone et la station Windows XP en tant qu’utilisateur standard sans téléphone IP. Il faut configurer les VLANs comme suit :

1. Un VLAN VoIP sur lequel sera connectés les deux HardPhones CISCO 7960, le serveur SIP proxy/registrar et le SoftPhone Linux Debian.

2. Un VLAN donnée sur lequel sera connectés la station Windows XP et le SoftPhone

Linux Debian. En effet, le SoftPhone doit faire partie des deux VLANs pour avoir accès aux services offerts par le réseau de donnée (Internet, DHCP, DNS, etc.) ainsi qu’au VLAN de VoIP. Il faut donc créer un trunk regroupant les deux VLANs pour connecter le SoftPhone.


sur 107 05.04.2005

Voici la configuration des VLANs sur le switch CISCO Catalyst 1912 : Dans le menu principal il faut choisir l’option [V] Virtual LAN. Voici le menu de configuration des VLANs : Catalyst 1900 - Virtual LAN Configuration ----------------------- Information ------------------------------------ VTP version: 1 Configuration revision: 9 Maximum VLANs supported locally: 1005 Number of existing VLANs: 7 Configuration last modified by: 192.168.0.3 at 00-00-0000 00:00:00 ----------------------- Settings --------------------------------------- [N] Domain name [V] VTP mode control Server [F] VTP pruning mode Disabled [O] VTP traps Enabled ----------------------- Actions ---------------------------------------- [L] List VLANs [A] Add VLAN [M] Modify VLAN [D] Delete VLAN [E] VLAN Membership [S] VLAN Membership Servers [T] Trunk Configuration [W] VTP password [P] VTP Statistics [X] Exit to Main Menu Ensuite il faut choisir [A] Add VLAN. Une question est ensuite posée à propos du type de VLAN à ajouter : This command selects the type of VLAN to be added. The following VLAN types can be added: [1]Ethernet, [2]FDDI, [3]Token-Ring, [4]FDDI-Net, or [5]Token-Ring-Net Select a VLAN type [1-5]: Il faut choisir [1] Ethernet. Ensuite est affiché le menu d’ajout de VLAN Ethernet : Catalyst 1900 - Add Ethernet VLAN ----------------------- Settings --------------------------------------- [N] VLAN Number 2 [V] VLAN Name VLAN0002 [I] 802.10 SAID 100002 [M] MTU Size 1500 [L] Translational Bridge 1 0 [J] Translational Bridge 2 0 [T] VLAN State Enabled [S] Save and Exit [X] Cancel and Exit


sur 107 05.04.2005

Le numéro par défaut du nouveau VLAN est 2. Nous allons changer le nom du VLAN pour l’appeler VoIP. Il faut donc sélectionner [V] VLAN Name. Nous pouvons maintenant saisir le nouveau nom : This command selects the unique name of a VLAN. Configuration change only takes effect when the VLAN SAVE command is executed. A string of up to 32 characters may be specified to name a VLAN. Example: Engineering, Manufacturing, Blue Enter VLAN name (32 characters max): Current setting ===> VLAN0002 New setting ===> VoIP Nous pouvons ensuite sauver le VLAN avec la commande [S] Save and Exit. La même marche à suivre est utilisée pour activer le VLAN "Donnee". Nous allons maintenant ajouter des ports au VLANs. Les trois premier ports seront dans le VLAN VoIP et le port 4 sera dans le VLAN Donnee. Il faut donc sélectionner le choix [E] VLAN Membership depuis le menu Virtual LAN Configuration. Ceci va lister les associations de VLAN de tous les ports : Port VLAN Membership Type ----------------------------- 1 1 Static 2 1 Static 3 1 Static 4 1 Static 5 1 Static 6 1 Static 7 1 Static 8 1 Static 9 1 Static 10 1 Static 11 1 Static 12 1 Static AUI 1 Static A 1 Static B 1 Static [M] Membership type [V] VLAN assignment [R] Reconfirm dynamic membership [X] Exit to previous menu Par défaut, tous les ports sont associés au VLAN 1 de manière statique. Le VLAN 1 est un VLAN par défaut. Nous avons créé le VLAN 2 VoIP et le VLAN 3 Donnee. Il faut donc maintenant associer les ports correspondants à l’aide du menu [V] VLAN assignment. Voici ce que nous obtenons : This command assigns or re-assigns ports to a VLAN. If the port is configured with dynamic VLAN membership, then assigning VLAN 0 causes the discovery of VLAN membership to start all over again. Port numbers should be separated by commas or spaces. A port number range may also be specified. The word ALL indicates all ports. Example: 1, 7-11, AUI, 4, A Enter port numbers: 1-3


sur 107 05.04.2005

Après sélection des ports 1-3, il faut sélectionner le VLAN auquel nous désirons associer ces ports : Identify VLAN 0 - VLAN 1005: Select [0-1005] 2 La configuration du port 4 se fait de manière analogue. Voici ce que nous obtenons après configuration complète des ports : Port VLAN Membership Type ----------------------------- 1 2 Static 2 2 Static 3 2 Static 4 3 Static 5 1 Static 6 1 Static 7 1 Static 8 1 Static 9 1 Static 10 1 Static 11 1 Static 12 1 Static AUI 1 Static A 1 Static B 1 Static Ensuite il faut quitter ce menu et revenir a la configuration des VLANs avec la commande [X] Exit to Previous Menu. Il faut maintenant configurer le trunk qui va être utilisé pour le SoftPhone. Ce trunk doit comprendre les VLANs 2 et 3. Il faut choisir l’option [T] Trunk Configuration. Il nous faut maintenant choisir le trunk à utiliser. Ce choix n’est pas important mais nous choisirons le trunk A : This command selects a trunk port. Select a trunk port [A, B] : A Nous arrivons maintenant dans le menu de configuration du trunk A : Catalyst 1900 - Trunk A Configuration Menu Trunking status: On Encapsulation type: ISL ----------------------- Information ------------------------------------ Transmit Flood traffic to VLANs N/A Receive Flood traffic from VLANs N/A Allowed VLANs 1 Pruning Eligible VLANs None ----------------------- Settings --------------------------------------- [T] Trunking On ----------------------- Actions ---------------------------------------- [S] List VLANs that Transmit Flood traffic [R] List VLANs that Receive Flood traffic [V] List Allowed VLANs [F] List Pruning Eligible VLANs [A] Add Allowed VLAN(s) [E] Add Pruning Eligible VLAN(s) [D] Delete Allowed VLAN(s) [C] Delete Pruning Eligible VLAN(s) [N] Next Trunk [P] Previous Trunk [X] Exit to Vlan Menu


sur 107 05.04.2005

Il faut ensuite utiliser l’option [A] Add Allowed VLAN(s) pour ajouter des VLAN au trunk A. Il ne reste plus qu’à choisir d’ajouter les VLANs 2-3 : This command adds one or more VLANs to the allowed VLAN list for this trunk. VLAN numbers should be separated by commas or spaces. A VLAN number range may also be specified. The word ALL indicates all VLANs. Example: 1, 2, 10-20 Enter VLAN numbers [1-1005] : 2-3 Ensuite nous pouvons quitter le menu et fermer la console. Maintenant nous pouvons tester les pings entre les différents éléments. Ce mécanisme est vraiment très intéressant. D’une part, son utilisation est "gratuite" à partir du moment ou le switch est déjà présent sur le réseau et qu’il permet d’utiliser des VLANs. D’autre part, les domaines de collisions sont séparés et ainsi le réseau fonctionne plus efficacement dans chaque VLAN. Mais surtout, ce mécanisme permet d’éviter toutes les attaques de VoIP/SIP visant directement un élément de VoIP (DoS par injection de messages, Buffer Overflow, SPAM, détournement d’appel, etc.) et venant de personnes qui ne font pas partie du VLAN de VoIP. Toutes les attaques de VoIP qui s’effectuent de manière indirecte (c'est-à-dire en passant par un élément réseau qui n’est pas forcément un éléments de VoIP), telles que l’épuisement de ressource DHCP et les attaques TFTP par exemple, ne peuvent pas être évitées sans devoir isoler ces éléments dans le VLAN de VoIP uniquement. Mais attention, cela n’est pas toujours possible puisque ces éléments sont souvent utilisés par des éléments du réseau de donnée (en particulier DHCP).

8.5.3 Digest Authentification :

Une façon de se prémunir contre les attaques de types DoS - Bulk REGISTER/INVITE est de configurer sur le serveur d’enregistrement que celui-ci doit utiliser le système d’enregistrement authentifié avec une liste des téléphones autorisés. Il faut donc spécifier dans le serveur les différentes associations ‘Username’ et ‘Password authentification’ (voir Figure 55). Le système d’authentification implémenté par notre proxy est celui décrit dans la nouvelle RFC 3261 SIPv2. Avec l’ancienne RFC le système est basé sur une authentification basique. C'est-à-dire que le ‘Username’ et le ‘Password’ transitaient en clair dans les messages SIP. Le nouveau système est, lui, basé sur une authentification digest, donc le ‘Username’ et le ‘Password’ font partie intégrante du digest et donc indéchiffrable à un attaquant qui cherche à capturer des messages SIP.


sur 107 05.04.2005

Figure 55 - Enregistrement avec authentification

Avec ce système de contrôle, aucun utilisateur non autorisé ne peut s’enregistrer dans le serveur. Même si l’attaquant possède un téléphone autorisé dans l’entreprise il ne pourra pas effectuer de nouvel enregistrement avec d’autres URI que celui de son téléphone (les enregistrement de même URI n’utilise qu’une place dans la liste). Il faudra bien sûr que le serveur d’enregistrement permette ce type d’authentification. Et voici ci-dessous le diagramme en flèche après avoir mis en place le système d’authentification :

Figure 56 - Système d'authentification du registrar


sur 107 05.04.2005

Voici un exemple de message requête REGISTER émis par le téléphone [email protected] avec authentification correcte : REGISTER sip:192.168.0.100 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.102:5060;branch=z9hG4bK1a2feb13 From: sip:[email protected] To: sip:[email protected] Call-ID: [email protected] CSeq: 391 REGISTER User-Agent: CSCO/7 Contact: <sip:[email protected]:5060> Authorization: Digest username = "2222", realm="192.168.0.100", uri="sip:192.168.0.100", response= "3235b0582e22587e93375e78d8fcbf57", nonce="3e2313d473fe71f824b0dbb3b15d52d666c05fa2",algorithm=md5 Content-Length: 0 Expires: 1000 Lorsqu’un téléphone tente de s’enregistrer sans spécifier le champ ‘Authorization’ ou avec une valeur incorrecte, le proxy va répondre par un message ‘401 Unauthorized’ contenant un nouveau champs ‘nonce’ spécifiant que l’enregistrement a échoué par faute de mauvaise authentification. Nous pouvons remarquer qu’un agent SIP lors d’un enregistrement agis par défaut comme suit (ceci s’appelle le challenge d’authentification, voir point 7.10.2 "http Digest Authentification") :

1. Emission au registrar d’une requête REGISTER sans le champ ‘Authorization’. a. Si l’authentification n’est pas gérée, alors l’UA SIP est enregistré (200 OK). b. Si il y a authentification, alors l’UA va émettre une nouvelle requête

REGISTER avec le champ ‘Authentification’. • Si l’UA est dans la liste d’authentification (voir Figure 55) et que son

‘User’ et ‘Password’ sont corrects alors l’UA est enregistré (200 OK). • Si l’UA ne fait pas partie de la liste ou que les informations sur le

‘User’ et ‘Password’ sont incorrectes alors l’enregistrement est refusé (401 UNAUTHORIZED).

Il est également à noter que le système d’authentification nécessite que les requêtes INVITE et CANCEL soient authentifiées. Cela veut dire que cette sécurité supplémentaire permet par exemple d’éviter le SPAM d’INVITE, le DoS CANCEL et le DoS Bulk INVITE venant de personnes non authentifiées. Par contre si ces personnes possèdent un téléphone IP avec autorisation rien ne les empêche de générer les messages adéquats (voir SPAM INVITE et DoS CANCEL) en se faisant passer pour le téléphone en question, c’est-à-dire avec tous les champs contrôlés y compris le champ ‘Proxy-Authorization’ des messages INVITE et CANCEL. Mais cela ne permet pas d’enregistrer des téléphones supplémentaires ne faisant pas partie de la liste d’enregistrement et de ce fait l’attaque Bulk REGISTER est impossible ! Ce système d’authentification rend également plus difficile les attaques de types SPAM d’INVITE. En effet, l’étonnante facilité de ce genre d’attaque en rend la défense d’autant plus ardue. Cependant, comme vu lors de l’eavesdropping, le système d’authentification oblige l’attaquant à faire partie de la liste autorisée avec son ‘User’ et ‘Password’. De ce fait, n’importe qui ne peut pas s’amuser à faire du SPAM d’INVITE sans être autorisé au niveau du serveur d’enregistrement.


sur 107 05.04.2005

Cependant, si l’attaquant a possibilité de capturer une requête REGISTER et une requête INVITE (et éventuellement un requête CANCEL) émise par un téléphone autorisé (que ce soit le sien ou un autre sur le même hub ou encore sur le même hub que le registrar ou le proxy et qu’il utilise un générateur de messages SIP pour s’authentifier alors l’attaquant se fera passer pour lui et pourra sans autre effectuer du SPAM d’INVITE et même envoyer des messages instantanés. Remarque : Cela fonctionne que le téléphone authentifié copié soit enregistré ou non mais curieusement le registrar ne réponds pas par un 200 OK alors que l’enregistrement est réellement effectué (voir Figure 57).

Figure 57 - SPAM d'INVITE en contournant l'authentification (spoofing)

Il est donc très difficile de pouvoir effectuer du SPAM d’INVITE avec le système d’authentification mais cela n’est pas impossible. En effet, une fois la requête INVITE autorisée capturée, l’attaquant peut alors la modifier pour l’envoyer à un ou plusieurs autre URI sur le réseau. Le système d’authentification agit donc comme une WhiteList avec les avantages et les inconvénients que cela entraîne. Pour chaque nouveau partenaire susceptible de pouvoir appeler dans l’entreprise il faut effectuer la mise à jour de la liste. Mais comme nous avons pu le remarquer, cette WhiteList est contournable et cela simplement en se faisant passer pour quelqu’un faisant partie de cette liste. Remarque : Le même principe est utilisable pour effectuer un DoS BYE/CANCEL ou du eavesdropping/call hijacking avec Digest Authentification.


sur 107 05.04.2005

8.5.4 Filtrage des appels :

Si le proxy le permet, il est possible d’établir des règles d’appels un peu à la manière d’un firewall. Ces règles permettent de définir des filtres de cause à effet sur la base de beaucoup d’informations. Notre serveur permet d’écrire les règles en utilisant les éléments suivants. La colonne "Matching Patterns" spécifie suivant quelle condition il faut agir : Nom de la variable de condition Définition $addr Adresse IP de l’appelant.

Ex : $addr=192\.168\.1\.100

$date Date à laquelle la requête d’appel a été reçue. ex： $date=2003/12/01

$localhost Si oui ou non l’appel est initié depuis localhost (OSS). ex： $localhost=true

$outbound Si oui ou non l’appel est en dehors du réseau local (où réside OSS). ex： $outbound=false

$port N° de port de l’appelant. ex: $port=5060

$registered Si oui ou non l’appelé est enregistré. ex： $registered=false

$request

Requête. ex：$request=INVITE sip:[email protected]:5060 SIP/2.0

$sid

Session ID (numéro de session utilise pour la maintenance interne). ex： $sid=23

$time

Heure à laquelle la requête d’appel a été reçue. ex： $time=15:02:30

Tableau 6 - Matching Patterns


sur 107 05.04.2005

La colonne "Deploy Patterns" spécifie quel traitement effectuer si une condition de la colonne "Matching Patterns" intervient : Nom de la variable de traitement Définition $action Code de réponse qui va être envoyé à l’appelant.

Ex : $action=404 $continue Si $continue=true, les procédures de contrôle des matching

patterns (conditions) ne seront pas finies après que les deploy patterns (traitements) adéquats ne soient exécutés. Ex : $continue=true

$ifdst Interface réseau (adresse IP) utilisée pour envoyer les paquets à l’appelé. Ex : $ifdst=192.168.1.100

$ifsrc Interface réseau (adresse IP) utilisée pour envoyer les paquets à l’appelant. Ex : $ifdst=192.168.2.1

$nat Si oui ou non la fonction traversal NAT est utilisée. Ex : $nat=true

$replaceurl Si oui ou non le SIP-URI du paquet SIP est remplacé. Ex :$replaceurl=false

$rtp Si oui ou non le tunneling du flux RTP est établi. Ex : $rtp=auto

$target Spécifie l’adresse de l’appelé. Ex : $target=192.168.0.2

Tableau 7 - Deploy Patterns

Voici les différents champs d’entête les plus fréquents sur lesquels on peut créer des règles de filtrage d’appel : Champs d’entête Définition TO Le SIP-URI de l’appelé ou le serveur SIP de routing FROM Le SIP-URI de l’appelant Max-Forwards Nombre maximum de sauts qu’une requête SIP peut passer jusqu’à

destination User-Agent Nom du user agent de l’appelant

Tableau 8 - Champs d'entête SIP

Et voici les méthodes principales de requêtes SIP : Méthode Définition REGISTER Enregistre l’information contact du user agent INVITE Invitation à participer à la session. Cela requiert une session ouverte ACK Quittancement à une réponse qu’une requête INVITE a été reçue CANCEL Annule la transaction en cours dans la session INFO Donne des informations de session OPTIONS Interrogation des capacités du serveur

Tableau 9 - Méthodes principales SIP


sur 107 05.04.2005

Imaginons que quelqu’un de non reconnu dont on connaît l’adresse IP désire utiliser le service de VoIP. Il suffirait alors d’établir une règle de filtrage qui interdit l’envoi de requêtes INVITE par la station 192.168.0.1 (la station en question) en y répondant par un messages 603 DECLINE. Cette règle est représentée à la Figure 58.

Figure 58 - Règle de filtrage d'appel

Après sauvegarde de la règle et redémarrage du serveur, nous allons tenter d’appeler le téléphone [email protected] depuis notre SoftPhone [email protected] (adresse IP : 192.168.0.1). Voici ce que nous obtenons :

Figure 59 - Appel filtré


sur 107 05.04.2005

8.5.5 IDS/IPS :

L’utilité d’un IDS/IPS SIP, placé devant un serveur SIP, est le contrôle de la validité des messages SIP à destination du serveur en question. L’IDS pourra alors détecter et éemttre une alerte lorsqu’un message SIP ne respecte pas la RFC 3261 et donc les champs spécifiques contrôlés au niveau des UAs SIP tel que nous l’avons vu dans les attaques de types injection de messages SIP. L’IPS quant à lui pourra jeter ces messages corrompus. Ceux-ci sont principalement utilisés pour des attaques de types Buffer Overflow ou DoS. Il est également possible pour l’IDS/IPS de détecter l’envoi de plusieurs messages INVITE sur le même téléphone ou encore de pouvoir analyser des suites de messages SIP afin d’éviter les attaques par injection de messages. En collaboration avec Mlle Kuhn, nous avons pu tester son IDS/IPS VoIP/SIP sur notre plateforme de test. Voici par exemple une requête INVITE sans l’entête To adressée au proxy. INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.0.102:5060;branch=z9hG4bK488667a0 From: "2222" <sip:[email protected]>;tag=000628d8a74600180d37cff2-4f11b716 Call-ID: [email protected] CSeq: 101 INVITE User-Agent: CSCO/7 Contact: <sip:[email protected]:5060> Expires: 180 Content-Type: application/sdp Content-Length: 249 Accept: application/sdp Cette requête ne parvient pas jusqu’au proxy car l’IPS l’a détecté et voici le log qu’il a généré : [**] [123:6:1] (spp_sip) security check failed: To Header missing [**] 11/26-10:59:10.884104 192.168.0.102:3518 -> 192.168.0.100:5060 UDP TTL:128 TOS:0x0 ID:13265 IpLen:20 DgmLen:403 Len: 375 Voyons maintenant ce qui se passe si l’entête To est bien présente mais avec un URI non valide : INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.0.102:5060;branch=z9hG4bK488667a0 From: "2222" <sip:[email protected]>;tag=000628d8a74600180d37cff2-4f11b716 To: [email protected] Call-ID: [email protected] CSeq: 101 INVITE User-Agent: CSCO/7 Contact: <sip:[email protected]:5060> Expires: 180 Content-Type: application/sdp Content-Length: 249 Accept: application/sdp Le proxy n’a jamais reçu ce message. Examinons plus en détail les logs générés par l’IDS/IPS : [**] [123:14:1] (spp_sip) process packet failed: malformed packet : parsing error [**] 11/26-11:00:24.583664 192.168.0.102:3524 -> 192.168.0.100:5060 UDP TTL:128 TOS:0x0 ID:13271 IpLen:20 DgmLen:427 Len: 399


sur 107 05.04.2005

8.5.6 SRTP : Le chiffrement du flux audio RTP avec le protocole Secure RTP (SRTP) est le meilleur moyen de contrer les attaques d’écoutes indiscrètes de communication (eavesdropping). En effet, même si l’attaquant parvient à capturer le flux audio, il lui faudra également connaître la clef de chiffrement pour décoder les paquets SRTP. Les HardPhones CISCO 7960 ne supportent actuellement pas SRTP. Il faut donc utiliser des SoftPhones qui implémentent ce protocole. Il en existe un en particulier, Minisip, qui supporte à la fois SRTP, TLS et le Digest Authentification. Nous avons donc besoin de deux stations Linux sur lesquelles installer les SoftPhones. Le portable fait toujours office d’attaquant. Les serveurs SIP seront un proxy/registrar SER 0.8.14 (Sip Express Router). La Figure 60 représente notre nouvelle plateforme de test avec les SoftPhones Minisip :

Figure 60 - Réseau de test SIP sécurisé SRTP, Digest Authentification, IDS/IPS VoIP/SIP

Remarque : Il est également possible de mettre en place des mécanismes supplémentaires tels que l’encapsulation TLS, S/MIME de SDP, IPSec entre les UAs, la mise en place d’un serveur d’authentification forte Radius, l’utilisation d’un NAT et d’un firewall VoIP/SIP mais ceux-ci ne seront pas abordé lors de ce laboratoire. Pour que les deux partenaires puissent communiquer, il faut qu’ils supportent SRTP et possèdent soit une clef PSK (voir Figure 61) identique soit une paire certificat/clef Diffie-Hellman valide (voir Figure 62Figure 63) pour l’authentification.


sur 107 05.04.2005

En effet, Minisip implémente un stack SRTP et MIKEY (Multimedia Internet KEYing RFC3830) comme solution de gestion de clef afin de pouvoir les échanger et associer des paramètres de sécurité. Il met également à disposition toutes les clefs et les certificats que nécessite TLS (au niveau du proxy) et Diffie-Hellman (au niveau des SoftPhones).

Figure 61 - Configuration de SRTP avec PSK

Figure 62 - Configuration de SRTP avec Diffie-Hellman

Figure 63 - Configuration des certificats

VoIP/SIP & Security Ludovic Maret

sur 107 05.04.2005

Voici un exemple de certificat : -----BEGIN CERTIFICATE----- MIIDUzCCArygAwIBAgIBADANBgkqhkiG9w0BAQQFADB/MQswCQYDVQQGEwJTRTES MBAGA1UECBMJU3RvY2tob2xtMQ4wDAYDVQQHEwVLaXN0YTEkMCIGA1UEChMbS3Vu Z2xpZ2EgVGVrbmlza2EgSG9nc2tvbGFuMSYwJAYDVQQLEx1UZWxlY29tbXVuaWNh dGlvbiBTeXN0ZW1zIExhYjAeFw0wMzA4MjUxMzUxMjhaFw0wNDA4MjQxMzUxMjha MH8xCzAJBgNVBAYTAlNFMRIwEAYDVQQIEwlTdG9ja2hvbG0xDjAMBgNVBAcTBUtp c3RhMSQwIgYDVQQKExtLdW5nbGlnYSBUZWtuaXNrYSBIb2dza29sYW4xJjAkBgNV BAsTHVRlbGVjb21tdW5pY2F0aW9uIFN5c3RlbXMgTGFiMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQCvx2HMVc7GGW7jgxPFYUdBsIPKXoYZWqpbQKFYdrbUMkuc OZCrNDS1uJYbzQhilszSv8O6mS3T2LvHRC1Sv72a5+gRqgq41VxNxQLlGQXN2Kit 15V44KGx2zu1HrqvqddTFVd7EjtOGlqRP3MxzQObg4nHjWSKqtYfENgD04kxdwID AQABo4HeMIHbMB0GA1UdDgQWBBQdwLHJsfCl+NjzdIgIvUlkepBKFzCBqwYDVR0j BIGjMIGggBQdwLHJsfCl+NjzdIgIvUlkepBKF6GBhKSBgTB/MQswCQYDVQQGEwJT RTESMBAGA1UECBMJU3RvY2tob2xtMQ4wDAYDVQQHEwVLaXN0YTEkMCIGA1UEChMb S3VuZ2xpZ2EgVGVrbmlza2EgSG9nc2tvbGFuMSYwJAYDVQQLEx1UZWxlY29tbXVu aWNhdGlvbiBTeXN0ZW1zIExhYoIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEB BAUAA4GBAFufvbXksRXbhVhMbUm3OW5uDc81XNQsAAvd15Uqhn/JhhyblWw+uxPi 1J5OSD5BY2K7Ru2oU//Zjam/CaROqp+3ERzWdGZ5GinRTx8eYhOgheU4WYqDQu2o F6rUyAmh60jnmntvqHyAtOP58lyPeiwq5GLfr74//tvcQvdHy187 -----END CERTIFICATE----- Et la clef RSA associée : -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQCvx2HMVc7GGW7jgxPFYUdBsIPKXoYZWqpbQKFYdrbUMkucOZCr NDS1uJYbzQhilszSv8O6mS3T2LvHRC1Sv72a5+gRqgq41VxNxQLlGQXN2Kit15V4 4KGx2zu1HrqvqddTFVd7EjtOGlqRP3MxzQObg4nHjWSKqtYfENgD04kxdwIDAQAB AoGAdZObQi+/YNjQSJR73BImtLTaYrn5Xuo7e1Bu3BqETsnZs4T51NrVyxvOJIhv 7GpMVUf6J02gzsxxRme/HVOuAdz7eF5jK+d3jFoymeRoYVtx7iTLCTPuLw8s4Eaz A6bPnsm8S0pyEPf5NM3TD5liM4QDTlNbEUYcqSihzAZshSkCQQDXtpms2jKAZNrg If5WE8HK2g054hzVTAzJWoJJrjaGSXpjRHgvf3pjPH30hwQGmKW6W9f7YuXORzPY j7knznx1AkEA0Jt9Dw5lKHPv7Q31/d+ctokGaVV9iSssAKWSR9iblUhs0gj78ZOQ nZczRXURRLF89vP0xo0AbccAuec36voouwJBAJlkfLUA2Eaa8VXOdnipRfZExoDx vEUk9ja8yMcyPg2R9JjgWIKWKOamXn7i/8bdB4SUyOo3MmlUEpcd5LFc0P0CQHNf a50mIwBqjqmW7RQJ1kyGIEulgpaYj++TowGlZPb9ZWIMofsL2BGwjCTACFrrpueW KSye0zvjsh0fKigFTv0CQQC/sUa8H4We1nRGzpN6BZNQuTkowgP2RK3R2QtCOzrV 8smJQPV27lKmBw6mZcVBK2yeLusT2E7Lq6cHwnN1IjN6 -----END RSA PRIVATE KEY-----


sur 107 05.04.2005

Et voici une communication SIP avec SRTP capturée sur le hub : No. Time Source Destination Protocol Info 1 0.000 192.168.0.2 192.168.0.200 SIP Request: REGISTER sip:192.168.0.200 2 0.000 192.168.0.200 192.168.0.2 SIP Status: 200 OK (1 bindings) 3 0.853 192.168.0.1 192.168.0.200 SIP Request: REGISTER sip:192.168.0.200 4 0.854 192.168.0.200 192.168.0.1 SIP Status: 200 OK (1 bindings) 5 35.24 192.168.0.2 192.168.0.200 SIP/SDP Request: INVITE sip:[email protected];user=phone, with session description 6 35.248 192.168.0.200 192.168.0.2 SIP Status: 100 trying -- your call is important to us 7 35.249 192.168.0.200 192.168.0.1 SIP/SDP Request: INVITE sip:[email protected]:5060;user=phone;transport=UDP, with session description 8 35.260 192.168.0.1 192.168.0.200 SIP Status: 180 Ringing 9 35.260 192.168.0.200 192.168.0.2 SIP Status: 180 Ringing 10 36.856 192.168.0.1 192.168.0.200 SIP/SDP Status: 200 OK, with session description 11 36.857 192.168.0.200 192.168.0.2 SIP/SDP Status: 200 OK, with session description 12 36.862 192.168.0.2 192.168.0.200 SIP Request: ACK sip:[email protected];user=phone 13 36.862 192.168.0.200 192.168.0.1 SIP Request: ACK sip:[email protected]:5060;user=phone;transport=UDP 14 36.878 192.168.0.1 192.168.0.2 RTCP Unknown packet type 15 36.898 192.168.0.1 192.168.0.2 RTCP Unknown packet type 16 36.929 192.168.0.2 192.168.0.1 RTCP Unknown packet type 17 36.929 192.168.0.2 192.168.0.1 RTCP Unknown packet type 18 36.931 192.168.0.1 192.168.0.2 RTCP Unknown packet type 19 36.932 192.168.0.2 192.168.0.1 RTCP Unknown packet type 20 36.968 192.168.0.2 192.168.0.1 RTCP Unknown packet type 21 36.981 192.168.0.2 192.168.0.1 RTCP Unknown packet type Actuellement l’analyseur réseau Ethereal (version 0.10.7) ne reconnaît pas le protocole SRTP. C’est pourquoi il détecte que ce sont des paquets RTCP dont le format est inconnu. Voyons maintenant plus en détail comment la signalisation a changé. Dans notre cas les informations se rapportant au chiffrement du flux audio se trouvent dans les corps SDP des messages INVITE et 200 OK : INVITE sip:[email protected];user=phone SIP/2.0 From: <sip:[email protected];user=phone>;tag=1610063018 To: <sip:[email protected];user=phone> Call-ID: [email protected] CSeq: 101 INVITE Contact: <sip:[email protected]:5060;user=phone;transport=UDP>;expires=1000 User-Agent: Minisip Content-Type: application/sdp Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK1853405426 Content-Length: 526 v=0 o=- 3344 3344 IN IP4 192.168.0.2 s=Minisip Session c=IN IP4 192.168.0.2 t=0 0 m=audio 1046 RTP/AVP 0 a=rtpmap:0 PCMU/8000/1 a=key-mgmt:mikey AQAFgHbd/XMCAAAS24zhAAAAAAAAAAAAAAAAAAsAxVm0Fs5U5uIBELOdsTk26kweFUoJDcIASdMAAADEDCH82DmVnyVDKndaIffjZD45zTgzYlGYxizqDhupCvk+pZrJRRSo4DHZvodmwN2o0LNExwzrfOhHMPUwvMVUd4NQeHwnHjGIexmsxEUR+sItJuOrNzEB9pskBtMoNJYKFBDNfh2iFGTk9m+4PW3zZWX8A6PW30+S7qQ+r3GX52K5DR62NZY/0SaAOFnQ7opwhg8YEY3jdLT1eI00KLObBkDUQMQfMFhrBzJ8ii2gVFCyb0NLm3KH/j1FTF3hxmd0XNTG5AA8Ict5u2mEs10vftKvcEcWdOJiog==


sur 107 05.04.2005

C’est le dernier champ a (zero or more session attribute lines) qui définit le type de gestionnaire de clef (key-mgmt). Remarque : SRTP protège donc contre l’écoute indiscrète mais pas contre les attaques utilisant des messages SIP sans corps SDP. Il est donc toujours possible de détourner des appels (si le téléphone de l’attaquant supporte SRTP seulement) et d’effectuer des DoS BYE/CANCEL par exemple. Il est intéressant de regarder les logs générés par Minisip en utilisant PSK : secure before create: 1 The call is secure, adding MIKEY header setSdpAnswer started Starting loop trying format 0 setSdpAnswer returns true OSSSoundDevice format set toOssSoundDevice: number of channels set to 16 OssSoundDevice: number of channels set to 2 DSP speed set to 8000 DSP speed set to 8000 SSRC: 1840872282 - TEK: e03c3c6dd524cfff6ca5b56d2ee76e16 SSRC: 1840872282 - SALT: 41f4f84b7c1d2bc4c33abb375fc9 SSRC: 365440058 - TEK: 9e681ea69cfc7077145187eb154c9460 SSRC: 365440058 - SALT: 1d5e97eb0f769ca72cd2664495a7 Puis avec Diffie-Hellman et les certificats du côté appelé : setSdpOffer started Authentification successful, controlling the certificate OSSSoundDevice format set toOssSoundDevice: number of channels set to 16 OssSoundDevice: number of channels set to 2 DSP speed set to 8000 OssSoundDevice: number of channels set to 2 DSP speed set to 8000 SSRC: 1525186955 - TEK: bdc65e0b9cef5acb4299cc8e23321923 SSRC: 1525186955 - SALT: 55d33ade178cc03f131341ef188a SSRC: 106317066 - TEK: 989eab5083b35bb16ce6855e69ff33ce SSRC: 106317066 - SALT: 7077132f23f9698b41d49b899be3 Remarque : Si le certificat n’est pas valide, le SoftPhone ne démarre pas. Et voici ci-dessous ce qui se passe si la clef PSK ne correspond pas à celle du partenaire appelé :

Figure 64 - Réponse 606 NOT ACCEPTABLE pour une clef PSK non valide


sur 107 05.04.2005

Voila ce qui apparaît dans le SoftPhone :

Figure 65 - Clef PSK différente

Voici ce qui se passe si l’on essaie d’appeler un téléphone supportant SRTP avec un téléphone RTP :

Figure 66 – Appel entrant non sécurisé sur un téléphone SRTP

Nous avons donc le choix de répondre à cet appel en mode non protégé RTP ou alors de rejeter l’appel. Ce choix doit faire partie des politiques de sécurité de l’entreprise. Il est fortement conseillé de ne pas accepter d’appels non sécurisés.

8.5.7 TLS :

Le chiffrement TLS (SSLv3) permet de sécuriser la signalisation au niveau transport (TCP). Les SoftPhones Minisip supportent TLS mais malheureusement je n’ai pas réussi à installer correctement un proxy gratuit qui supporte ce protocole (VOCAL, sipXpbx, sipd). De plus en plus de proxy supportent TLS mais la plupart sont encore payants (M5T, CISCO SIP Proxy Server, Ingate SIP proxy, etc.). D’ici quelques mois, l’utilisation de TLS au niveau des serveurs SIP sera chose aisée et peu chère, notamment grâce à l’open source.


sur 107 05.04.2005

9 CONCLUSION La VoIP est une technologie récente mais surtout très attractive. En effet, cet outil de communication est de plus en plus utilisé par les secteurs privé et public. Afin d’améliorer les services de télécommunications, telles que les communications unifiées, on prévoit une utilisation accrue de la VoIP en se fondant sur les avantages perçus : le coût, l’efficacité, la rentabilité et la capacité d’évolution de la VoIP. Toutefois, comme dans toutes les nouvelles technologies, les questions concernant la sécurité sont souvent soulevées seulement qu’une fois que son utilisation est très répandue. En outre, le système téléphonique est une cible très intéressante pour des personnes sans scrupules désireuses de profiter d’un tel service gratuitement ou simplement pour en gêner son utilisation. La téléphonie en entreprise est un véritable outil de travail. Les communications internes sont tout aussi importantes que les communications externes. Si le service de téléphonie de l’entreprise est attaqué, c’est tout le système de communication basé sur la téléphonie de l’entreprise qui est attaqué. Imaginons que le service de VoIP devienne inaccessible en interne et en externe pendant une journée. Cela aura de nombreux effets négatifs sur l’entreprise, notamment la perte de clients, une altération de l’image de marque de l’entreprise devenue inaccessible depuis l’extérieur, le vol d’informations sensibles concernant l’entreprise ou encore un retard supplémentaire lors de la transmission d’informations essentielles de l’entreprise entre les secteurs de travail qui utilisent le service téléphonique comme moyen primaire de communication. Actuellement, les mécanismes de sécurisation d’un réseau IP sont très connus et efficace. Mais cela ne s’est pas fait du jour au lendemain. C’est l’ancienneté du protocole IP et son immense utilisation qui en a fait une cible idéale d’attaque. Avec le temps, des outils de défense de plus en plus performants ont été mis en place partout dans le monde. C’est pourquoi il faut toujours avoir à l’esprit que la sécurisation de réseaux de VoIP/SIP est, de par son implémentation toute récente, de loin pas parfaite. De plus, beaucoup de vulnérabilités ne sont pas encore connues. C’est pourquoi, il faut apporter une attention toute particulière à la sécurisation du service de VoIP/SIP. La plus grande erreur que commettent généralement les entreprises est de déployer le service de VoIP le plus vite possible afin de pouvoir l’amortir et en profiter immédiatement. Ce principe est défendable du point de vue de l’efficacité et de la rentabilité de l’entreprise. Cependant, les coûts engendrés par la mise en place du service dans l’entreprise sont négligeables par rapport à ce que les attaques pourraient coûter. Il faut donc y réfléchir à deux fois avant de mettre le système en fonction. En effet, le meilleur moyen de se prémunir contre les attaques est de déployer le système de VoIP/SIP de manière indépendante du réseau de l’entreprise et instaurer les mécanismes de sécurisation que nous avons vu dans les prescriptions de sécurisation de la VoIP/SIP. Une fois cela fait, le service peut être étendu au niveau de l’entreprise en premier lieu, puis au niveau international en dernier lieu. Ensuite, il faut que les administrateurs du réseau soient perpétuellement à l’écoute des vulnérabilités de la VoIP/SIP afin de pouvoir y ajouter le mécanisme de sécurisation adapté. La recette miracle de la sécurisation d’un réseau de VoIP/SIP serait composée de trois éléments combinés : l’application de procédures de base relative à la sécurité du réseau IP, la mise en place des meilleures pratiques de sécurisation de la VoIP dans ce document et une perpétuelle mise à niveau de la sécurité du réseau global IP/VoIP.


sur 107 05.04.2005

10 RÉFÉRENCES Bill Douskalis : IP Telephony – The Integration of Robust VoIP Services. Edition Hewlett-Packard Professional Book Ofir Arkin : VoIP - The Next Generation of Phreaking http://www.sys-security.com/html/projects/VoIP.html DISA : VoIP - Security Technical Implementation Guide http://csrc.nist.gov/pcig/STIGs/VoIP-STIG-V1R1R-4PDF.pdf Bureau de la protection des infrastructures essentielles : Protection VoIP http://www.ocipep.gc.ca/opsprods/info_notes/IN03-001_f.pdf Pingtel : Secure IP Telephony For The Enterprise http://www.checkpoint.com/products/downloads/voip_whitepaper.pdf Inkra Networks Corp. : Securing enterprise voice over IP networks http://downloads.lightreading.com/wplib/inkra/Inkra_VoIP_Security.pdf By James P. Cavanagh : Secure Business Telephony With VoIP http://itresearch.forbes.com/detail/RES/1039129120_961.html TippingPoint Technologies : Intrusion Prevention - The Future of VoIP Security http://www.preferredcomputers.com/whitepapers/download/VoIPSecurity.pdf Ofir Arkin et Josh Anderson : Multiple Vulnerabilities with Pingtel xpressaSIP Phones http://lists.virus.org/vulnwatch-0207/msg00023.html Draft Rosenberg : The Session Initiation Protocol (SIP) and Spam http://www.jdrosen.net/papers/draft-rosenberg-sipping-spam-01.txt CISCO : Adding MSN Messenger Services to Cisco Packet Voice Networks http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a0080092946.shtml Andreas Steffen, Daniel Kaufmann, Andreas Stricker : SIP Security http://security.zhwin.ch/DFN_SIP.pdf Sécurisation des communications avec SSLv3 http://securit.free.fr/ressources/ssl_v3.pdf Johan Bilien : Key Agreement for Secure Voice over IP ftp://ftp.it.kth.se/Reports/DEGREE-PROJECT-REPORTS/031215-Johan-Bilien-report-final-with-cover.pdf Johan Bilien, Erik Eliasson and Jon-Olov Vatn : Call establishment delay for secure VoIP http://www.minisip.org/publications/secvoip.pdf Israel M. Abad Caballero, Gerald Q. Maguire Jr., Pedro G. Vilda - Royal Institute of Technology (KTH) : Secure Mobile Voice over IP ftp://ftp.it.kth.se/Reports/DEGREE-PROJECT-REPORTS/030626-Israel_Abad_Caballero-final-report.pdf C. Jennings : Example call flows using SIP security mechanims http://www.softarmor.com/wgdb/docs/draft-jennings-sip-sec-flows-01.html Draft Sterman : RADIUS Extension for Digest Authentication http://www.softarmor.com/wgdb/docs/draft-sterman-aaa-sip-00.txt


sur 107 05.04.2005

11 SYMBOLES ET ABRÉVIATIONS [SA01] SIP : Session Initiation Protocol. Protocole de signalisation multimédia (audio, vidéo,

autres) [SA02] RTP : Real-Time Transport Protocol. Protocole utilisé pour convoyer de l’information

temps réel (audio, vidéo, autres) [SA03] H.323 : Protocole de signalisation utilisé pour la communication audio/vidéo [SA04] ISDN : Integrated Services Digital Network. Modèle de téléphonie numérique qui permet

à des utilisateurs de se connecter à Internet sur une ligne téléphonique standard à des vitesses supérieures à 56K

[SA05] SS7 : Signalling System 7. Protocole de signalisation utilisé dans les réseaux

téléphoniques publics commutés (PSTN) [SA06] PSTN : Public Switched Telephony Network. [SA07] codec : Diminutif pour compressor/decompressor. Technologie pour compresser et

décompresser des données (audio, vidéo, autres [SA08] QoS : Quality of Service. Terme utilisé pour mesurer la “qualité de service” d’un produit

ou d’un service [SA09] MGCP : Media Gateway Control Protocol. Protocole de voix qui fonctionne en conjonction

avec SS7 et les protocoles IP tels que SIP ou H323. MGCP est utilisé en tant que passerelle entre les réseaux à circuits commutés et les réseaux de paquets. MGCP sépare la signalisation et le contrôle d’appel pour la passerelle de media.

[SA10] SDP : Session Description Protocol. SDP est utilisé pour décrire les paramètres de flux

utilisés dans les sessions multimédia [SA11] RTCP : RTP Control Protocol. RTCP fournit un feedback sur la qualité de la distribution

des données convoyées par RTP [SA12] DTMF : Dual Tone Multi-Frequency. Tonalité des touches lors d’appel téléphonique [SA13] PBX : Private Branch Exchange. Réseau téléphonique commute privé, souvent utilisé

en enterprise pour fournir une connectique téléphonique interne et un accès au PSTN

[SA14] IP-PBX : Internet Protocol Branch Exchange. Réseau téléphonique fonctionnant avec le

protocole IP. [SA15] TDM : Time Division Multiplexing. Technologie qui transmet des signaux multiples

simultanément sur un circuit de transmission unique [SA16] nonce : Terme cryptographique. Paramètre qui varie dans le temps, tel qu’un compteur, et

qui est utilisé dans les protocoles de gestion de clefs pour se prévenir contre les attaques message replay et d’autres types d’attaques

[SA17] overhead : En cryptographie, ce terme désigne l’augmentation de la taille d’une trame après

chiffrement. [SA18] padding : En téléinformatique, ce terme désigne les bits additionnels de bourrage ajoutés

pour finir le dernier paquet


sur 107 05.04.2005

12 FIGURES ET TABLEAUX

12.1 Figures [1 | 4-19] Ofir Arkin : VoIP - The Next Generation of Phreaking http://www.sys-security.com/html/projects/VoIP.html [20-24 | 27] DISA : VoIP - Security Technical Implementation Guide http://csrc.nist.gov/pcig/STIGs/VoIP-STIG-V1R1R-4PDF.pdf [25] Tutorial – VoIP/SIP & Security /I. Tutorial - VoIP-SIP Security/visio [26] CISCO : Adding MSN Messenger Services to Cisco Packet Voice Networks http://www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a0080092946.shtml [28] Projet de semestre Olivier Frider : CISCO CME [29-31 | 36-41] Andreas Steffen, Daniel Kaufmann, Andreas Stricker : SIP Security http://security.zhwin.ch/DFN_SIP.pdf [32-35] Sécurisation des communications avec SSLv3 http://securit.free.fr/ressources/ssl_v3.pdf [42] Draft Sterman : RADIUS Extension for Digest Authentication http://www.softarmor.com/wgdb/docs/draft-sterman-aaa-sip-00.txt [2-3 | 43-66] Laboratoire – Vulnérabilités et mesures de sécurité /III. Laboratoire - Vulnérabilités et mesures de sécurité/visio

12.2 Tableaux [1-3] DISA : VoIP - Security Technical Implementation Guide http://csrc.nist.gov/pcig/STIGs/VoIP-STIG-V1R1R-4PDF.pdf [4-5] Andreas Steffen, Daniel Kaufmann, Andreas Stricker : SIP Security http://security.zhwin.ch/DFN_SIP.pdf [6-9] Brekeke : OnDo SIP Server Tutorial – Dial plan http://www.brekeke-sip.com/download/oss/oss_tutorial_dialplan_e.pdf


sur 107 05.04.2005

13 ANNEXES [1] Tutorial : VoIP/SIP & Sécurité [2] GuideLine : Prescriptions de sécurisation de la VoiP/SIP [3] Projet de semestre : Traversal Firewall/NAT [4] Résultat du test de vulnérabilités de type Buffer Overflow [5] Logiciels utilisés [6] Journal de travail [7] Affichette Ludovic Maret

rapport maret

Documents