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
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.
Page 2 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
Page 3 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
Page 4 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").
Page 5 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.
Page 6 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.
Page 7 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
Page 8 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.
Page 9 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…
Page 10 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.
Page 11 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
Page 12 sur 107 05.04.2005

CANCEL sur Alice :
Figure 5 - DoS CANCEL sur Alice

BYE :
Figure 6 - DoS BYE
Page 13 sur 107 05.04.2005

BYE à Bob :
Figure 7 - DoS BYE à Bob

BYE à Alice :
Figure 8 - DoS BYE à Alice
Page 14 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.
Page 15 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é.
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.
Identifie la
source d’un flux
RTP
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.
Page 16 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.
Page 17 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.
Page 18 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
Page 19 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.
Page 20 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.
Page 21 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.
Page 22 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:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
Page 23 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).
Page 24 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é.
Page 25 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).
Page 26 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.
Page 27 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.
Page 28 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.).
Page 29 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.
Page 30 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.
Page 31 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.
Page 32 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.
Page 33 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).
Page 34 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 Requiert des investissements importants dans la
considérés comme prouvés et de technologie technologie propriétaire d’un vendeur unique.
fiable.
Traitement efficace de l’appelant avec des Les configurations multi-site peuvent requérir des
services tels que la gestion des files d’attentes, composants prioritaires additionnels (par ex :
les annonces, la musique en attente et autres. passerelle média), par ailleurs l’investissement
augmente avec une solution de vendeur unique.
Mise à l’échelle très simple pour de grands L’architecture mixée incluant des composants
centres d’appel qui doivent supporter un grand PBX et IP avec une complexité de gestion plus
nombre de clients appelant en file. grande qu’avec des architectures IP-centric (voir
Permet la migration lente à IP pendant que point suivant).
l’investissement augmente et que les risques
diminuent.
Tableau 1 - Avantages et inconvénients de l'architecture IP-enabled
Page 35 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.
Page 36 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 Une architecture décomposée requiert des
routage des appels. plateformes de serveurs multiples.
Donne un nouvel élan à l’infrastructure de Requiert une très grande fiabilité et robustesse
données et minimise les investissements en de l’infrastructure de donnée.
composants TDM.
Fournis une meilleure flexibilité dans les Mise à l’échelle difficile pour le traitement d’un
environnements distribués, spécialement dans très grand nombre d’utilisateurs appelants en file.
les configurations avec une redirection locale
d’appels dans de multiples petits sites.
Fournis un choix dans l’achat des éléments Peut être considéré moins fiable ; peut ne pas
technologiques et autorise le mélange être très bien adapté pour des opérations de
d’environnements pour les routeurs, les serveurs, central d’appel 24x7 (24h/24 7j/7).
les applications, etc.
Page 37 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 :
Page 38 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.
Page 39 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.
Page 40 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
Page 41 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é.
Page 42 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.
Page 43 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).
Page 44 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.
Page 45 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.
Page 46 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.
Page 47 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.
Intégrité des données
Méthodes d’authentification :
Authentification
PSK Pre-Shared Key

Confidentialité
PKI Public Key Infrastructure
Déprécié par SIPv2

HTTP 1.0 Basic Authentification PSK - -
Transmission non sécurisée du mot de passe
Echange des challenges/réponses basé sur le hash
HTTP 1.1 Digest Authentification PSK - -
MD5 d’un password, d’un username et d’un nonce.
PGP PKI 3 3 Déprécié par SIPv2
Pour le chiffrement, la clef publique de l’UA de

S/MIME PKI 3 3
destination doit être connue.
Les applications et proxy SIP doivent supporter
SIPS URI (TLS) PKI 3 3
TLS.
L’intégration avec des applications SIP n’est pas
IPSec PKI 3 3
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.
Page 48 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.
Page 49 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 : alice@atlanta.com). 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.
Page 50 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.
Page 51 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 :

Couche 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.).
Page 52 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
Page 53 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
Page 54 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:bob@b.example.com:5081 SIP/2.0

To: <sips:bob@b.example.com:5081>
From: <sip:alice@example.com>;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:alice@a.example.com: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:bob@b.example.com:5081>;tag=514db9e7
From: <sip:alice@example.com>;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:bob@b.example.com:5081>
Content-Length: 0
Page 55 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,
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,
CN=alice@a.example.com
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:alice@a.example.com
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/
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
Page 56 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
4764C0F9D5E090D7F6E91AC0E4B638249D471E55BA3394EBDB7607C3E44D87904F
4BE03B586B229723D65E23C795A0BE7D90F81A99D518B248BF79DF8C6C55E4B135
6249D82F9B18C37525FA05D3562399E4912BC902FA92CF12D7AE653C3C0D851A4B
B3DF35E8722006460FC076E02D012D3CF233D1934100FEC7EAC72DE989
FA5A76D62011E3A219B4D89CF2A392FF57A55BC4E1092EC67030E31ABEDC591485
C284250BC0195C33A92920B340B2636EBB880C3DC6E2748A6045A07FCC2E97
F60CEC61DB985C1AE0F927E831AADA2E1DF889D135E91A49B662B8094CF140075A
9C782DF6A28F538D2C51CC4910CB02B159894FB597D17A3FB69DDD37099D1D
53E735A495A2E9334E823986801B2A0CC186FDB681E4DDF44B6D56EF83BFBD6B0F
591D887CE3A89C2A042B707622DCA64E5A33424701FCAB2A2511B0B4A3ED89
CBD8F91E39E888A65C2D103AF6AB2E07771D2A5101F115AE6C446D64873278719F
4872E8E1A4DC49C4742B70AC3815792DA598754965764F69E9C9F03460EAA1
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.
Page 57 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.
Page 58 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.
Intégrité des données
Méthodes d’authentification :
PSK Pre-Shared Key

Authentification
Confidentialité
PKI Public Key Infrastructure
Utilise une clef maîtresse qui doit être distribuée par

Secure RTP (SRTP) PSK 3 3 un moyen externe à SRTP (MIKEY ou paramètre k
dans la cargaison SDP)
L’intégration avec des applications SIP n’est pas
IP Security (IPSec) PKI 3 3
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.
Page 59 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.
Page 60 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
Page 61 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.
Page 62 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.
Page 63 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%.
Page 64 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
Page 65 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é.
Page 66 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.
Page 67 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é.
Page 68 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.
Page 69 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é
Page 70 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:1111@192.168.0.100 SIP/2.0

Via: SIP/2.0/UDP 192.168.0.102:5060;branch=z9hG4bK488667a0
From: "2222" <sip:2222@192.168.0.100>;tag=000628d8a74600180d37cff2-4f11b716
To: <sip:1111@192.168.0.100>
Call-ID: 000628d8-a7460005-2ea21b7e-341a28dd@192.168.0.102
CSeq: 101 INVITE
User-Agent: CSCO/7
Contact: <sip:2222@192.168.0.102:5060>
Expires: 180
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.
Page 71 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
Page 72 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
Page 73 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).
Page 74 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.
Page 75 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 2222@192.168.0.100 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.
Page 76 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
1234@192.168.0.100.
Page 77 sur 107 05.04.2005

Voici le diagramme des communications lorsque la call forwarding est activé sur le
téléphone appelé 2222@192.168.0.100 (l’URI de transfert utilisée ici est
1111@192.168.0.100) 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:1111@192.168.0.100:5061>;tag=1456031938
To: <sip:2222@192.168.0.100>;tag=000628d8a7460006222bd7e0-2b9d81d1
Call-ID: 7B8C5094-3D73-4B53-8D2B-D705F42638CF@192.168.0.101
CSeq: 36174 INVITE
Server: CSCO/7
Contact: <sip:1234@192.168.0.100:5060>
Record-Route: <sip:192.168.0.100:5060;lr>
Content-Length: 0
Page 78 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:2222@192.168.0.100>;tag=000628d8a7460020284410f7-38952018
To: <sip:1111@192.168.0.100>;tag=003094c3b55f002221002837-351f92e3
Call-ID: 000628d8-a746000b-0935d5d0-79ff3029@192.168.0.102
CSeq: 101 INVITE
Server: CSCO/7
Contact: <sip:1111@192.168.0.101:5060>
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:2222@192.168.0.100>;tag=000628d8a746001f1a70e356-7102f646
To: <sip:1111@192.168.0.100>;tag=003094c3b55f00210354a38a-2aa9d9e6
Call-ID: 000628d8-a746000a-15193266-5b3ac19e@192.168.0.102
CSeq: 101 INVITE
Server: CSCO/7
Contact: <sip:1111@192.168.0.101:5060>
Content-Length: 0
Il nous faudra donc activer notre SoftPhone 1234@192.168.0.100 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 1111@192.168.0.100 au téléphone
2222@192.168.0.100.
Page 79 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.
Page 80 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
SSRC=1605747604, Seq=52846, Time=8422752
SSRC=1605747604, Seq=52847, Time=8422912
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.
Page 81 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
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).
Page 82 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.
Page 83 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.
Page 84 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.
Page 85 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
Page 86 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
Page 87 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
Page 88 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.
Page 89 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
Page 90 sur 107 05.04.2005

Voici un exemple de message requête REGISTER émis par le téléphone

2222@192.168.0.100 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:2222@192.168.0.100
To: sip:2222@192.168.0.100
Call-ID: 000628d8-a7460002-23a43184-4f1b4369@192.168.0.102
CSeq: 391 REGISTER
User-Agent: CSCO/7
Contact: <sip:2222@192.168.0.102: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.
Page 91 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.
Page 92 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:11@192.168.1.200: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
Page 93 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
Page 94 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 2222@192.168.0.100 depuis notre SoftPhone 1234@192.168.0.100 (adresse IP :
192.168.0.1). Voici ce que nous obtenons :
Figure 59 - Appel filtré
Page 95 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:1111@192.168.0.100 SIP/2.0

CSeq: 101 INVITE
User-Agent: CSCO/7
Contact: <sip:2222@192.168.0.102:5060>
Expires: 180
Content-Length: 249
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:1111@192.168.0.100 SIP/2.0

To: 1111@192.168.0.100
CSeq: 101 INVITE
User-Agent: CSCO/7
Contact: <sip:2222@192.168.0.102:5060>
Expires: 180
Content-Length: 249
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
Page 96 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.
Page 97 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
Page 98 sur 107 05.04.2005

VoIP/SIP & Security Ludovic Maret
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-----
Page 99 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:3333@192.168.0.200;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:3333@192.168.0.1: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:3333@192.168.0.200;user=phone
13 36.862 192.168.0.200 192.168.0.1 SIP Request: ACK
sip:3333@192.168.0.1:5060;user=phone;transport=UDP
14 36.878 192.168.0.1 192.168.0.2 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:3333@192.168.0.200;user=phone SIP/2.0

From: <sip:4444@192.168.0.200;user=phone>;tag=1610063018
To: <sip:3333@192.168.0.200;user=phone>
Call-ID: 368500001@192.168.0.2
CSeq: 101 INVITE
Contact: <sip:4444@192.168.0.2:5060;user=phone;transport=UDP>;expires=1000
User-Agent: Minisip
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/XMCAAAS24zhAAAAAAAAAAAAAAAAAAsAxVm0Fs5U5uIBELOdsTk26kweFUoJDcIASdMAAADEDCH
82DmVnyVDKndaIffjZD45zTgzYlGYxizqDhupCvk+pZrJRRSo4DHZvodmwN2o0LNExwzrfOhHMPUwvMVUd4
NQeHwnHjGIexmsxEUR+sItJuOrNzEB9pskBtMoNJYKFBDNfh2iFGTk9m+4PW3zZWX8A6PW30+S7qQ+r3GX5
2K5DR62NZY/0SaAOFnQ7opwhg8YEY3jdLT1eI00KLObBkDUQMQfMFhrBzJ8ii2gVFCyb0NLm3KH/j1FTF3h
xmd0XNTG5AA8Ict5u2mEs10vftKvcEcWdOJiog==
Page 100 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
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
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
Page 101 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.
Page 102 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.
Page 103 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
Page 104 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
Page 105 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]
[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]
[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]
[4-5]
[6-9]
Brekeke : OnDo SIP Server Tutorial – Dial plan
http://www.brekeke-sip.com/download/oss/oss_tutorial_dialplan_e.pdf
Page 106 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
Page 107 sur 107 05.04.2005

Rapport Maret

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rapport Maret

Încărcat de

Drepturi de autor:

Formate disponibile

TRAVAIL DE DIPLÔME 2004

1 CAHIER DES CHARGES

1. Tutorial présentant les problèmes liés à la sécurisation d’un réseau d’entreprise

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

2. Réaliser un GuideLine de prescriptions de sécurisation de la VoIP/SIP. Ce Guide

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

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

Page 2 sur 107 05.04.2005

2 TABLE DES MATIÈRES

Page 3 sur 107 05.04.2005

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

Page 4 sur 107 05.04.2005

Page 5 sur 107 05.04.2005

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

Page 6 sur 107 05.04.2005

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

La VoIP comprend deux types de vulnérabilités principales. La première est celle

• Vulnérabilités des protocoles

Cependant, une certaine catégorie de personnes malveillantes se trouvant à l’extérieur du

Page 7 sur 107 05.04.2005

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

5.1.1 Vulnérabilités des protocoles

• SIP Session Initiation Protocol (RFC 3261) de l’IETF

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

Figure 2 - Architecture trapézoïdale SIP

Page 8 sur 107 05.04.2005

Voyons maintenant comment se passe un appel SIP :

Figure 3 - Appel SIP standard

Page 9 sur 107 05.04.2005

Menaces héritant directement du modèle réseau de donnée IP :

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

Page 10 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

1. La signalisation (SIP/SDP) : En s’attaquant à la signalisation, le pirate peut obtenir

Page 11 sur 107 05.04.2005

Dénis de service (DoS) :

CANCEL sur Bob :

Figure 4 - DoS CANCEL sur Bob

Page 12 sur 107 05.04.2005

CANCEL sur Alice :

Figure 5 - DoS CANCEL sur Alice

Figure 6 - DoS BYE

Page 13 sur 107 05.04.2005

Figure 7 - DoS BYE à Bob

Figure 8 - DoS BYE à Alice

Page 14 sur 107 05.04.2005

BYE (aux deux) :

Figure 9 - DoS BYE à Bob et Alice

Utilisation des codes de réponses :

Page 15 sur 107 05.04.2005

Manipulation des collisions SSRC (RTP) :

En envoyant une commande utilisant le SSRC (adresse de la source de synchronisation

Injection de paquet (RTP) :

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

Modification de codec audio :

Page 16 sur 107 05.04.2005

Détournement d’appel (call hijacking) :

En effectuant une manipulation d’enregistrement :

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

Page 17 sur 107 05.04.2005

MITM Attack - Utilisation des messages 30x :

Page 18 sur 107 05.04.2005

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

Manipulation de la signalisation : En utilisant le mot de passe administrateur, une

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

En analysant les transactions réseaux :

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

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

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

Elle est capable de reconfigurer les paramètres réseaux du téléphone en utilisant