Rapport Maret

TRAVAIL DE DIPLME 2004
ETUDE DE CAS :
VOIP/SIP & SCURIT

LUDOVIC MARET
ETR
PROFESSEUR RESPONSABLE :
MR STEFANO VENTURA
Travail de diplme : VoIP/SIP & Scurit
Ludovic Maret
1 CAHIER DES CHARGES

Ce travail de diplme comprend les activits suivantes :
1. Tutorial prsentant les problmes lis la scurisation dun rseau dentreprise
ayant dploy la VoIP et proposant des solutions de scurisation. Il sagira dabord
de :
o
Dfinir et prsenter les diffrentes vulnrabilits de la VoIP lintrieur et

extrieure de lentreprise. Ne sera pris en considration que la problmatique
SIP.
Dfinir et prsenter les diffrentes architectures de dploiement possibles en
tenant compte dune configuration disposant dun propre GW ISDN et dune
connexion VoIP travers Internet pour communiquer avec dautres filiales ou
des collaborateurs itinrants
Dfinir les diffrentes stratgies et mcanismes de scurisation
2. Raliser un GuideLine de prescriptions de scurisation de la VoIP/SIP. Ce Guide

pourra tre utilis comme guide pour un Audit.
3. Ralisation dun laboratoire permettant de dmontrer les diffrentes vulnrabilits de
la VoIP et lefficacit des mesures dfensives prconises. Par exemple : coute de
communications, vol didentit, DoS, etc. Il ne sagit pas de traiter toutes les
attaques mais de les classer et traiter les plus reprsentatives pour chaque type.
4. Si le temps le permet, proposer et raliser un banc de test reproduisant les
configurations scurises les plus reprsentatives de linterfaage du service VoIP
avec Internet. Ce banc de test doit permettre de comparer lefficacit, les
performances ainsi que linteroprabilit de diffrentes mcanismes dinterconnexion
(STUN, Turn, FW/ALG). Les rsultas de ces observations feront lobjet dun rapport.
Page 2 sur 107
05.04.2005
Ludovic Maret
2 TABLE DES MATIRES

1
CAHIER DES CHARGES ______________________________________________________ 2
TABLE DES MATIRES_______________________________________________________ 3
RSUM ___________________________________________________________________ 5
INTRODUCTION _____________________________________________________________ 6
5
VULNRABILITS DE LA VOIP/SIP LINTRIEUR ET LEXTRIEUR DE
LENTREPRISE __________________________________________________________________ 7
5.1
VULNRABILITS LINTRIEUR DE LENTREPRISE __________________________________ 8
5.1.1 Vulnrabilits des protocoles _____________________________________________ 8
5.1.2 Vulnrabilits des systmes dexploitation ___________________________________ 9
5.1.3 Vulnrabilits dinfrastructure _____________________________________________ 9
5.1.4 Vulnrabilits humaines _________________________________________________ 9
5.2
VULNRABILITS LEXTRIEUR DE LENTREPRISE__________________________________ 9
6
ARCHITECTURES DE DPLOIEMENT DE LA VOIP/SIP _____________________________ 9

6.1
DPLOIEMENT COMPLET DUNE 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
PRESCRIPTIONS DE SCURISATION DE LA VOIP/SIP _____________________________ 9

7.1
SCURIT PHYSIQUE _______________________________________________________ 9
7.2
SPARATION 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
SCURISER 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
SCURISER LES FLUX DE MDIA TEMPS REL ______________________________________ 9
7.11.1
Secure RTP (SRTP)__________________________________________________ 9
7.11.2
IP Security (IPSec) ___________________________________________________ 9
7.12
RADIUS ET AAA _________________________________________________________ 9
7.13
GESTION DACCS DISTANCE DES SERVEURS DE VOIP/SIP __________________________ 9
7.14
CONNEXIONS VOIP/SIP WAN--WAN__________________________________________ 9
7.15
FIRMWARE ET LOGICIELS PROPRITAIRES 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
Ludovic Maret
LABORATOIRE : VULNRABILITS DE LA VOIP/SIP ______________________________ 9

8.1
INTRODUCTION ___________________________________________________________ 9
8.2
MATRIEL NCESSAIRE _____________________________________________________ 9
8.3
MISE EN PLACE DU RSEAU SIP _______________________________________________ 9
8.4
QUELQUES ATTAQUES AU NIVEAU INTERNE DU RSEAU ______________________________ 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 Dbordement de tampon (buffer overflow) : __________________________________ 9
8.4.6 Dtournement dappel (call hijacking) :______________________________________ 9
8.4.7 Ecoute indiscrte dautres communications (eavesdropping) :____________________ 9
8.4.8 SPAM - INVITE :_______________________________________________________ 9
8.5
PRVENTION : MCANISMES DE SCURISATION ET RFLEXES 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
CONCLUSION ______________________________________________________________ 9
10
RFRENCES ______________________________________________________________ 9
11
SYMBOLES ET ABRVIATIONS________________________________________________ 9
12
FIGURES ET TABLEAUX _____________________________________________________ 9

12.1
12.2
13
FIGURES ________________________________________________________________ 9
TABLEAUX ______________________________________________________________ 9
ANNEXES __________________________________________________________________ 9
Page 4 sur 107
05.04.2005
Ludovic Maret
3 RSUM
Avec l'mergence de rseaux convergents et de la VoIP, les systmes de voix,
traditionnellement isols du rseau de transmission de donnes, voluent pour devenir l'une
de ses applications principale. L'une des consquences de cette convergence est que le
trafic de voix et ses systmes associs sont devenus aussi vulnrables aux menaces de
scurit que n'importe quelle autre donne vhicule par le rseau.
En effet, le dploiement de la VoIP en entreprise est trs intressant. Pour de faibles cots
de mise en place, le service de VoIP permet de tlphoner au sein de lentreprise et sur
Internet "gratuitement". De plus, limplmentation de la VoIP avec le protocole de
signalisation SIP (Session Initiation Protocol) [SA01] fournit un service efficace, rapide et
simple dutilisation. Cependant, SIP est un protocole dchange de messages bas sur
HTTP. Cest pourquoi SIP est trs vulnrable face des attaques de types DoS (dnis de
service), dtournement dappel, trafic de taxation, etc. (voir point 5 " Vulnrabilits de la
VoIP/SIP lintrieur et lextrieur de lentreprise"). De plus, le protocole de transport
audio associ RTP (Real-Time Transport Protocol) [SA02] est lui aussi trs peu scuris
face de lcoute indiscrte ou des DoS.
Si vous souhaitez dployer une plateforme scurise de VoIP avec SIP, il faut agir comme
suit :
En premier lieu, il faut faire un choix sur le type darchitecture de VoIP/SIP que lentreprise
souhaite dployer. Cela dpend en grande partie de larchitecture actuelle du rseau de
lentreprise, des besoins de lentreprise et videmment de son budget (voir point 6
"Architectures de dploiement de la VoIP/SIP").
Une fois cela fait, il faut prendre des mesures de scurits plusieurs niveaux si nous
voulons que le service de VoIP/SIP soit scuris. Il faut donc avant toute chose scuriser le
rseau de donne avec les moyens standard connus de tous les administrateurs rseaux
tels que lutilisation de firewalls, de NAT, de chiffrement IP, VLAN, etc. Ensuite, il faut
scuriser le rseau de VoIP/SIP avec des mcanismes de chiffrement de la signalisation de
du flux audio, scuriser laccs tous les serveurs de VoIP, utiliser des VLANs, etc. Pour
finir, il faut russir combiner les deux types de rseaux (donne/VoIP) et scuriser les
accs au niveau de la passerelle entre les deux rseaux (voir point 7 "Prescriptions de
scurisation de la VoIP/SIP").
Page 5 sur 107
05.04.2005
Ludovic Maret
4 INTRODUCTION
Grce son mcanisme de cration de session simple et rapide, SIP a rapidement envahi
le march de la VoIP qui tait jusqu lors domin par les implmentations adhrant plutt
au standard complexe de tlphonie par Internet H.323 [SA03]. Tandis que H.323 a t
troitement modlis sur le standard des rseaux numriques intgration de services
RNIS [SA04] de niveau 3 pour la mise en place dappel et sur le standard de messages
binaires ASN.1 pour la signalisation, SIP est, lui, bas sur le modle de transaction HTTP
requte/rponse en utilisant des messages textes avec une syntaxe proche de HTTP/1.1
(voir Figure 1).
Figure 1 - Modle client-serveur (HTTP/SIP)
SIPv1 est un protocole de niveau application qui a t dfini par la RFC 2543 en mars 1999.
Il est bas sur UDP ou TCP et est utilis pour la cration de sessions participants
multiples, comme les applications de vido/audio confrence. Il remplit une fonction de
signalisation comparable SS7 [SA05] dans les rseaux commuts publics de tlphonie
PSTN [SA06]. En juin 2002, le standard SIPv2, dfini par la RFC 3261, remplace
compltement SIPv1. Actuellement, SIPv1 nest plus utilis puisque cette version ninclut
aucun mcanisme de dfense efficace.
Cependant, dun point de vue scurit, SIPv2 nest de loin pas parfait. En effet, SIPv2 est
autant, voir plus, vulnrable que HTTP. Comme tout systme de communication, la
simplicit est souvent lie des problmes de scurit. La clart des messages SIP en fait
un outil efficace et rapide mais galement lisible, comprhensible et modifiable par dautres
personnes que celles concernes 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 mdia RTP a t dfini par la RFC 1889 en Janvier
1996. RTP fournit RTP fournit des fonctions de transport rseau de bout-en-bout appropris
pour des applications de transmission de donnes temps-rel, tel que la voix, la vido ou
des donnes de simulation. RTP peut tout aussi bien utiliser les services rseaux unicast ou
multicast. En Juillet 2003, la nouvelle RFC 3550 remplace lancienne. 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] trs acceptable. Cependant, RTP nest pas labris
dventuelles attaques au niveau des donnes audio telle que la capture des paquets de
voix ou linjection de donnes audio extrieures la communication.
Nous sommes donc, ici, devant une combinaison de deux protocoles trs peu scuriss qui
fonctionnent au dessus dun protocole IP qui est, lui aussi, vulnrable face beaucoup
dattaques.
Voyons plus en dtail les diffrentes menaces inhrentes au dploiement de la VoIP avec
SIP auxquelles il faudra faire face aprs dploiement de ce service en entreprise.
Page 6 sur 107
05.04.2005
Ludovic Maret
5 VULNRABILITS DE LA VOIP/SIP LINTRIEUR ET

LEXTRIEUR DE LENTREPRISE
Les menaces de scurit associes la tlphonie sur IP sont beaucoup plus nombreuses
quavec un rseau commut traditionnel PSTN. En effet, tant que la VoIP reste un service
du rseau IP, les menaces de scurits sont celles du rseau IP additionnes celles du
rseau SIP. En effet, limplmentation de SIP fait intervenir des lments supplmentaires
(gateway(s), proxy(s), serveur(s) de redirection, serveur(s) denregistrement, serveur(s)
demplacement, terminaux, etc.) qui induisent de nouvelles vulnrabilits.
Certaines de ces vulnrabilits semblent tre due au fait que, jusqu rcemment, les
utilisateurs se sont davantage proccups 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 scurit et les protocoles appropris. Les proccupations envisageables
concernant la technologie VoIP comprennent les questions de scurit habituelles
associes aux technologies dInternet comme leur capacit protger les renseignements
personnels et de lentreprise, ainsi que de nouvelles proccupations causes par la cration
de dpendances entre les rseaux vocaux et de donnes.
La VoIP comprend deux types de vulnrabilits principales. La premire est celle
directement dpendante des protocoles utiliss dans limplmentation et la deuxime est
associe avec le systme dexploitation concern. Chaque protocole (SIP, H323 ou MGCP
[SA09]) ou service a ses propres vulnrabilits de scurit. A ces deux types de
vulnrabilits peuvent sajouter les vulnrabilits dinfrastructure/humaines. Nous pouvons
donc classer les types de vulnrabilits comme suit :
Vulnrabilits des protocoles

Vulnrabilits des systmes dexploitation
Vulnrabilits dinfrastructure
Vulnrabilits humaines
Comme dans tout rseau IP. Le rseau SIP doit principalement faire face trois types de
menaces :
Lacquisition de services
Linterruption de services
Linterception de services
La plupart des menaces de scurit peuvent tre classes dans ces trois catgories, mais il
y a toujours de nouvelles menaces prendre en compte.
La plupart des intrusions de scurit dans les entreprises ont t faites par les employs de
cette mme entreprise. En effet, il est dautant plus intressant pour un employ de mettre
son patron "sur coute" que pour une personne externe lentreprise. Il faut donc que la
personne malveillante se trouve physiquement lintrieur du rseau de VoIP/SIP et donc
lintrieur du rseau de donnes galement.
Cependant, une certaine catgorie de personnes malveillantes se trouvant lextrieur du
rseau peut tout aussi bien attaquer le service de VoIP pour plusieurs raisons qui leur
incombent. Gnralement ces raisons diffrent des raisons qui poussent des employs
attaquer leur propre entreprise.
Page 7 sur 107
05.04.2005
Ludovic Maret
5.1 Vulnrabilits lintrieur de lentreprise

5.1.1 Vulnrabilits des protocoles
Ce tutorial ne traitant que de limplmentation de la VoIP avec SIP, nous ne prendront donc
en compte que les protocoles suivants :
SIP Session Initiation Protocol (RFC 3261) de lIETF

SDP Session Description Protocol (RFC 2327) de lIETF [SA10]
RTP Real-Time Transport Protocol (RFC 3550) de lIETF
RTCP Real-Time Control Protocol (RFC 3605) de lIETF [SA11]
SIP est un protocole simple et flexible orient message bas sur les rendez-vous. Les
composants principaux dun systme bas sur SIP sont :
Terminal SIP (User Agent Client ou UAC) Peut tre aussi bien un SoftPhone
(logiciel) quun HardPhone (IP Phone). Les terminaux sont des appareils pouvant
mettre et recevoir de la signalisation SIP. Les autres lments sont communment
appels des User Agent Server UAS.
Serveur denregistrement Ce serveur essentiel reoit les inscriptions des utilisateurs
(adresse IP, port, username).
Serveur de localisation Mmorise les diffrents utilisateurs, leurs droits, leurs mots
de passe, position actuelle, etc.
Serveur de redirection Redirige les appels vers la position actuelle dun utilisateur.
Serveur proxy Effectue le mme travail que le serveur de redirection si ce nest que
le proxy nannonce pas lagent la localisation actuelle de lutilisateur mais se
charge de retransmettre les messages vers celui-ci.
Passerelle (gateway) PSTN/H323/ISDN/PSTN Permet linterconnexion de rseaux
diffrents en convertissant les paquets IP au format dsir.
Voici un rappel sur le principe de larchitecture trapzodale SIP :
Figure 2 - Architecture trapzodale SIP
Page 8 sur 107
05.04.2005
Ludovic Maret
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 problme de la scurit de la VoIP est donc double. Le fait que la voix et les donnes
partagent le mme rseau implique quaux vulnrabilits de scurit des rseaux de
donnes sajouteront les nouvelles vulnrabilits propres la VoIP.
Page 9 sur 107
05.04.2005
Ludovic Maret
Menaces hritant directement du modle rseau de donne IP :

Les rseaux IP sont de plus en plus dploys et donc de plus en plus connus. Ces rseaux
sont donc facilement accessibles et permettent de plus en plus de monde dtudier les
problmes de scurit auparavant trouvs et publis et ceci linverse de lobscurit qui
caractrise les rseaux PSTN. La tlphonie IP avoue volontiers parler de Phreaker afin
de dsigner toute personne mal intentionne qui sattaque des rseaux tlphoniques.
Voici donc une liste non exhaustive des vulnrabilits propres aux rseaux de donnes IP :
Denis de service (DoS) : Privation daccs un service rseau en bombardant les

serveurs (proxy, gateway, ) avec des paquets malveillants.
Intgrit de message (message integrity) : Vrification que le message reu na pas
t altr durant la transmission.
Capture de paquets (paquets sniffing) : Obtention dinformations (adresse IP/MAC,
protocoles utiliss).
Reconnaissance : Analyse des services sexcutant sur un serveur par exemple.
Mot de passe (password attack) : Casser des mots de passe afin dobtenir des
privilges.
Personne au milieu (man-in-the-middle) : Paquets modifis de manire usurper une
identit ou permettant la rcupration dinformation 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 rfrence des programmes crapuleux.
Exploits de vulnrabilit : Programme ou technique profitant dune vulnrabilit dans
un logiciel et qui peut tre utilis pour casser la scurit ou pour attaquer une station
travers le rseau.
Dtournement (hijacking) : Attaque dans laquelle lattaquant prend procession dune
connexion en cours entre deux entits en se faisant passer pour lune des deux
entits.
Mauvaise utilisation (misuse) : Modifier le but inhrent dune fonction ou autre afin de
pouvoir abuser du systme.
Coupure de courant
Autres
Page 10 sur 107
05.04.2005
Ludovic Maret
Menaces propres lutilisation de la VoIP/SIP :

La particularit de la VoIP face aux donnes IP standard est principalement associe la
notion de qualit de service. En effet, comme dans tout systme de tlphonie, la VoIP
apporte une trs importance la QoS. Ceci augmente notablement lexposition aux attaques
de types DoS. Cela affecte principalement :
Dlai/latence
Perte de paquet
Variation du dlai de transfert de l'information (jiter)
Bande passante
Techniques de codage de la parole
La QoS doit donc faire face ces nouvelles vulnrabilits propres au service de VoIP, les
lments SIP vulnrables sont :
1. La signalisation (SIP/SDP) : En sattaquant la signalisation, le pirate peut obtenir
des informations sur les utilisateurs et se faire passer pour quelquun dautre par
exemple. Cela permet galement de dtourner des appels et de manipuler la
taxation.
2. Les donnes (SIP-DATA) : En sattaquant aux donnes le pirate peut couter les
communications, modifier/insrer et supprimer de linformation.
Voici les diffrentes vulnrabilits propres au dploiement dune plateforme de VoIP avec le
protocole de signalisation SIP.
Page 11 sur 107
05.04.2005
Ludovic Maret
Dnis de service (DoS) :

Il sagit ici de la privation daccs un service rseau en bombardant les serveurs (proxy,
gateway, ) avec des paquets malveillants. Il existe plusieurs moyens deffectuer 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 rponses 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
Ludovic Maret
CANCEL sur Alice :
Figure 5 - DoS CANCEL sur Alice
BYE :
Figure 6 - DoS BYE
Page 13 sur 107
05.04.2005
Ludovic Maret
BYE Bob :
Figure 7 - DoS BYE Bob
BYE Alice :
Figure 8 - DoS BYE Alice
Page 14 sur 107
05.04.2005
Ludovic Maret
BYE (aux deux) :
Figure 9 - DoS BYE Bob et Alice
Utilisation des codes de rponses :

Un pirate peut utiliser diffrents codes de rponse afin dintroduire une condition de DoS :
Les rponses 4xx dfinissent les rponses dues un chec depuis un serveur
particulier. Le client ne doit pas ressayer la mme requte sans modification (par
exemple en ajoutant une autorisation particulire). Toutefois, la mme requte vers
un serveur diffrent peut russir.
Les rponses 5xx sont des rponses dchec mises quand un serveur a un
problme.
Les rponses 6xx indiquent quun serveur a une information dfinitive sur un
utilisateur particulier et pas juste une instance particulire indique dans la requteURI.
Bulk REGISTER :
Le fait denvoyer une trs grande quantit de messages REGISTER avec des URI
diffrentes au serveur denregistrement cause le remplissage complet de la liste
denregistrement. Ce qui veut dire que tous les tlphones IP non enregistrs ne pourront
senregistrer. Cela provoque donc un DoS sur tous ces tlphones.
Bulk INVITE :
Le but est ici dpuiser les ressources de sessions simultanes sur le proxy. Le nombre de
connexions simultanes maximum dpend du serveur et du rseau. Il nous suffit donc
dinitier plus de n connexions pour que le proxy soit devienne non fonctionnel. Le DoS
sapplique donc lentiret des tlphones SIP se servant de ce proxy pour communiquer.
Page 15 sur 107
05.04.2005
Ludovic Maret
Manipulation des collisions SSRC (RTP) :

En envoyant une commande utilisant le SSRC (adresse de la source de synchronisation
RTP) dun autre participant ou en revendiquant le SSRC dun autre (voir Figure 10), des
collisions additionnelles vont entrer en jeu (rduction de la QoS voire DoS).
Injection de paquet (RTP) :
En injectant des paquets avec le mme SSRC mais comportant un numro de squence et
un timestamp suprieur par rapport aux valeurs actuelles (voir Figure 10), le contenu truqu
inject sera lu avant les paquets rels. Cela entrane donc un DoS sur lutilisateur ayant le
SSRC considr.
Utilis par le
rcepteur pour
dtecter la perte de
paquet (peut tre
aussi utilis pour
restaurer la
squence de
paquet)
Indique linstant
auquel le premier
byte de la
cargaison RTP a
t gnr. Le
timestamp est
utilis pour placer
les paquets RTP
dans un ordre
temporel correct.
Identifie la
source dun flux
RTP
Figure 10 - Format de paquet RTP et vulnrabilits associes
Modification de codec audio :

Le fait de modifier lencodage audio RTP pendant une session peut tre utilis pour
sattaquer la QoS. En effet, aussi bien lutilisation dun codec de plus faible qualit va
provoquer non seulement une rduction de la qualit de la voix mais galement dautres
problmes tels que des DoS, des crashs du systme, etc.
Page 16 sur 107
05.04.2005
Ludovic Maret
Dtournement dappel (call hijacking) :

Le but est ici de dtourner lappel vers le pirate ou denregistrer les communications. Cela
permet galement de se joindre un appel (confrence audio). Ce type dattaque peut se
faire de plusieurs manires :
A travers le serveur denregistrement (voir Figure 11).
A laide dattaques de type MITM (Man-in-the-middle attack).
o A travers lutilisation de codes de rponse SIP 301 (voir Figure 12 et Figure
14) & 302 (dplacement permanent\temporaire, voir Figure 13). Ces codes
rponses peuvent tre spoofs comme des rponses venant de nimporte
quel lment SIP, tels que :
Serveur denregistrement Cela permet dusurper une identit (fake
identity).
Serveur proxy Ceci permet dobtenir toute la signalisation et donc la
modification, la suppression voir lajout de messages SIP permettant
de dtourner des appels.
Serveur de redirection De manire analogue un proxy, ceci permet
dobtenir toute la signalisation.
UAC SIP Cela permet de discuter avec le partenaire en se faisant
pour le vrai destinataire (coute du mdia).
o Ou plus cratif, travers lutilisation du code de rponse SIP 305 (utilisation
du proxy, voir Figure 15).
Tromper en milieu de session (mid-session tricks).
En effectuant une manipulation denregistrement :
Figure 11 - Dtournement d'appel en effectuant une manipulation d'enregistrement
On peut questionner le serveur denregistrement pour obtenir la liste des adresses dun URI
particulier. On peut ensuite donner la liste des adresses associes notre URI avec chaque
enregistrement correct. Mais est-ce que notre agent va le dvoiler aux autres ? Cela dpend
si le systme de notification est utilis ou non. En gnral cela nest 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
Ludovic Maret
Ou alors, on peut senregistrer avec une priorit plus faible et lancer un DoS sur les entres
de priorit haute. De cette manire, le proxy ne sera pas capable de dlivrer les messages
et va virer sur lentre suivante dans le serveur denregistrement. Le serveur
denregistrement peut sadresser lusager qui est en train de senregistrer (lusager peut
aussi bien tre un 3me usager) afin deffectuer une authentification avant de recevoir
linformation sur lenregistrement. Or, tant donn que les caractristiques denregistrement
avec SIP requirent un enregistrement chaque heure pour le mme URI (une heure est
spcifi par dfaut), il est peu probable quun utilisateur de tlphone SIP doive
sauthentifier au serveur denregistrement chaque heure.
Au lieu de cela, ce que la plupart des tlphones SIP font est de stocker les informations sur
le
username et le password avec le tlphone (cela implique dautres risques
dattaques) et excutent une authentification automatiquement pour lutilisateur quand
cela est requis.
MITM Attack - Utilisation des messages 30x :
Lemplacement de lentit malicieuse peut tre nimporte o (le rseau dAlice, le rseau de
Bob, voire entre les deux). Elle peut alors utiliser le code de rponse 301 (dplacement
permanent) ou 302 (dplacement temporaire) afin de dtourner des appels.
En effet, le client qui a mis la requte doit renvoyer la requte /aux nouvelle(s) adresse(s)
donne par lentte de contact. LURI de la nouvelle requte utilise la valeur du contact
obtenue dans la rponse 301 ou 302. Cette URI savre tre lURI de lattaquant.
La dure de validit de lURI du contact peut tre indique travers une entte dexpiration
ou alors laide dun paramtre dexpiration dans lentte du contact. Les deux proxy et
terminaux peuvent dissimuler cet URI pour la dure dexpiration. Si il ny a pas de dure
dexpiration, ladresse est uniquement valide une fois et ne doit pas tre cache pour les
transactions futures. Si lURI dissimule de lentte du contact choue, lURI de la requte
redirige doit tre ressaye une seule fois.
Page 18 sur 107
05.04.2005
Ludovic Maret
Figure 12 - Dtournement d'appel et utilisant un message 301 Moved Permanently
MITM attack - 302 Dplacement temporaire :
Figure 13 - Dtournement d'appel et utilisant un message 302 Moved Temporarily
Page 19 sur 107
05.04.2005
Ludovic Maret
MITM Attacks Envers le serveur denregistrement :
Figure 14 - Dtournement d'appel et utilisant un message 301 Moved Permanently afin

d'obtenir des credentials
En utilisant les credentials de Bob, Carol devient capable de sauthentifier auprs de

nimporte quel serveur de tlphonie IP. Lui permettant ainsi que pouvoir passer des appels
gratuits (voir free phone call) aussi bien que lhabilit excuter nimporte quelle
fonctionnalit autorise par les credentials de Bob dans le rseau de tlphonie IP. Par
exemple, elle peut senregistrer en tant que partenaire de destination avec un service
denregistrement, ce qui permet de pouvoir dtourner des appels facilement.
Page 20 sur 107
05.04.2005
Ludovic Maret
MITM Attacks 305 utilisation du proxy, ou lattaque du Qui est ton pre ? :
Figure 15 - Dtournement d'appel et utilisant un message 305 Use Proxy
Mid Session Tricks / Re-INVITE ou Session Replay :

Cette modification peut impliquer des changements dadresses et de ports, des
ajouts/suppressions de flux media etc. Ceci seffectue en envoyant une nouvelle requte
INVITE dans la mme communication qui a tabli la session. Ceci est aussi connu sous le
nom re-INVITE attack". En dtournant la voie de signalisation, il est possible dintroduire de
nouveaux routages dans la voie de signalisation dune session courante. Ceci permet de
refuser une signalisation venant de nimporte qui notre profit. Cela permet galement de
faire voluer la session en introduisant dautres participants. Lcoute non autorise
(eavesdropping) peut donc se faire de manire simple et en temps rel.
Dtournement denregistrement (registration hijacking) :
Si un attaquant peut capturer un message REGISTER correct mis par lun des tlphones,
alors il peut le modifier et renvoyer un nouveau message REGISTER au serveur
denregistrement pendant la priode dfinie dans le timestamp original. Il peut alors trafiquer
le serveur denregistrement de plusieurs manires.
Par exemple, lattaquant peut dsenregistrer lenregistrement existant en modifiant le champ
Expires avec la valeur 0. Dans ce cas, lappareil 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 requtes pour lutilisateur victime seront rediriges
vers lattaquant. Cela induit donc la fois un dtournement denregistrement et un DoS sur
la victime.
Page 21 sur 107
05.04.2005
Ludovic Maret
Modification didentit (request spoofing) :

Cette attaque est utilise pour modifier lidentit de lmetteur de messages SIP pour
trafiquer le rcepteur lgitime. Ceci peut tre fait pour diffrentes raisons (par exemple :
fraude ou taxation). En changeant les enttes du message, la personne malveillante peut
envoyer une requte forge qui fait en sorte que le rcepteur croit quil est en
communication avec une autre personne.
La modification didentit peut tre effectue sur nimporte quelle requte tel que REGISTER
et INVITE.
Trafic de taxation (fooling billing) :
Le serveur proxy SIP est habituellement celui qui produit lenregistrement du dtail dappel
ou CDR (call detail recording) pour la taxation. Ceci est d au fait que le serveur proxy est
capable dobliger toute la signalisation et la voix de passer travers le serveur proxy. Cela
signifie que les messages de signalisation dinitialisation 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
nest pas le cas quand nous traitons avec lactuel mdia de transport. Cela veut dire quil ny
a pas dacquisition de service dans les paquets RTP/RTCP.
Une manire simple de trafiquer ce mcanisme 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 modifies qui ont la possibilit de
parser les paquets RTP/RTCP.
Dans ce cas de figure, le serveur proxy SIP ne va voir aucune signalisation change entre
les deux partenaires de communication, bien que le flux audio va passer entre ces deux
utilisateurs. Un appel pourra donc tre lanc sans quaucune information de taxation ne soit
disponible.
Cet exemple met laccent sur le besoin de comprendre qui arrive en premier. Dans notre
cas, la signalisation arrive en premier, seulement nous avons besoin dautoriser les paquets
RTP changer. Ceci est une restriction qui ncessite dtre introduite dans nimporte quel
systme de VoIP bas sur SIP.
Rseaux sans fils (WLAN) :
Le fait de combiner la VoIP avec les rseaux sans fils afin dobtenir une trs grande libert
de mouvement avec des tlphones IP sans fils ouvre la porte de nouvelles vulnrabilits.
En effet, les rseaux sans fils ne sont pas parfaits et il existe plusieurs moyens de pouvoir
sintroduire dans un rseau sans fil plus facilement que dans un rseau IP standard. Cela
permet ensuite au Phreaker de lancer nimporte quelle attaque au niveau VoIP/SIP.
Page 22 sur 107
05.04.2005
Ludovic Maret
SPAM
Il existe trois types de SPAM diffrent avec la VoIP/SIP :
1. CALL SPAM : Ce type de SPAM est dfinit comme une masse non-sollicite de
tentatives dinitiation de session (avec des messages INVITE), afin de tenter dtablir
des sessions de communication audio. Si lutilisateur rpond, le spammer saffaire
relayer ses messages sur le mdia temps rel. 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 dfinit par
une masse non-sollicite de messages instantans, dont le contenu comprend le
message que le spammer cherche convoyer. Le spam IM est le plus souvent
envoy en utilisant les requtes SIP MESSAGE. Toutefois, une quelconque autre
requte qui provoquerait un affichage automatique du contenu sur lcran de
lutilisateur devrait galement suffire. Il est possible dinclure des requtes INVITE
avec des grandes enttes de sujet ou des requtes INVITE avec du texte ou un
corps HTML.
3. PRESENCE SPAM : Ce type de spam est similaire au spam IM. Il est dfinit par une
masse non-sollicite de requtes de prsence (c'est--dire des requtes SUSCRIBE
dans le but dtre sur la "white list" dun utilisateur afin de pouvoir lui envoyer des IM
ou pour initier dautres formes de communications). A la diffrence du spam IM, le
spam de prsence ne doit pas rellement convoyer le contenu dans le message. Il
nest donc pas vident de trouver lutilit ou la valeur dun tel type de spam.
Surveillance des appels (call tracking) :
La surveillance des appels permet de dterminer les partenaires faisant partie de lappel et
le nombre dutilisateurs en communication.
Si quelquun arrive capturer les DTMFs [SA12] (Dual Tone Multiple Frequencies) avec son
trafic de signalisation, il peut alors avoir lopportunit de capturer les mots de passes de
voicemail, des informations sur la carte de visite/crdit ou encore dautres donnes saisies
par DTMF. Cest pourquoi avec SIP tout ce que nous avons besoin de pister/surveiller est
les messages INVITE. Si le BYE est aussi enregistr, la dure de lappel peut galement
tre trace. Mais dautres informations ou parties dinformation peuvent tre surveille.
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
Ludovic Maret
Chiffrement :
Avec SIP, il subsiste encore des problmes lorsque nous dsirons chiffrer la signalisation.
En effet, le problme du chiffrement avec DES est que cet algorithme est cassable. De plus,
la clef DES est envoye en clair avec le paramtre k.
Et ceci sans compter le fait que le chiffrement entrane des dlais et des interfrences (jitter)
supplmentaire qui soppose trs clairement aux fondements de la QoS.
Ecoute secrte dautres communications (eavesdropping, sniffing, wiretapping) :
Lcoute secrte de communications peut tre facilement ralise avec un hub, un couteau,
un clipper et un sniffer. En fait, tous les moyens sont bons tant que lattaquant arrive se
placer sur le mme chemin que le flux audio avec un hub. Cela peut donc se faire de
plusieurs manires :
En se plaant entre le tlphone IP (ou le gateway client local) et le switch (voir

Figure 16).
Figure 16 - Eavesdropping entre le switch et le tlphone IP
En se plaant 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. Aprs avoir remis les paquets RTP dans le bon ordre et converti le flux
audio en un fichier, il est alors possible dcouter la communication bidirectionnelle en
diffr.
Lavantage en crackant le rseau tlphonique de cette manire est que le eavesdropper
peut galement passer des appels gratuits sans la connaissance de labonn (voir Figure
18).
Page 24 sur 107
05.04.2005
Ludovic Maret
Figure 18 - Possibilit d'appels gratuits
Une autre manire de procder est deffectuer dabord une attaque de type Call Hijacking
pour rediriger le flux vers lattaquant. Ceci aura pour effet de faire croire lappelant que
lattaquant est bien celui quil a voulu appeler. Avec un peu de savoir-faire lattaquant pourra
donc discuter avec lappelant et lui soustraire des informations. Notons tout de mme que
cette technique est dangereuse pour lattaquant puisque cest lui-mme qui va discuter et
quil fait probablement partie de lentreprise. Il se peut alors que lon reconnaisse sa voix.
Masquage dappelant (call masquerading) :
Le problme du masquage dappelant est que le partenaire appel ne peut authentifier
visuellement lappelant pendant un appel. Cela peut par exemple permettre des vendeurs
peu scrupuleux de faire leur petite publicit sans que lon puisse savoir qui lon a faire
(ou tout du moins jusqu ce que le partenaire appelant se prsente). Mais ce moment l,
la moiti du travail du vendeur est fait puisque notre curiosit nous a pouss rpondre.
Pas dintelligence/contrle 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 contrler la cration de flux mdias mais il ny pas de flux
mdia sans la signalisation approprie (problme de qui vient en premier, voir fooling
billing).
Si il y a une modification du flux mdia ( travers lutilisation 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 mdia 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 mdia serait
interrompu, les lments SIP participants la session (spcialement les serveurs SIP ou
UASs) nen seront en aucun cas inform jusquau moment ou lun des deux partenaires
raccroche le combin.
Il ny a galement pas de contrle du canal utilis pour le flux mdia. Nous avons vu quun
utilisateur malveillant peut changer le codec utilis travers le protocole de mdia et
spcifier un codec qui demande plus de bande passante (par consquent 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 contrle daucune sorte nest disponible pour le flux mdia. Ce qui favorise
grandement la manipulation de flux peu scrupuleuse en toute impunit.
Page 25 sur 107
05.04.2005
Ludovic Maret
Clients malveillants (malicious clients) :

Si on utilise un client malveillant (notre stack la place du stack du fabriquant ou un stack
modifi) et quon est le partenaire appel, on peut, par exemple, enlever les enttes des
routes enregistres sans problmes. Et cela aura pour rsultante que lappelant va devoir
envoyer des signaux au-del du "three-way handshake SIP" travers nimporte quel proxy
SIP que le client malveillant spcifi dans les routes. Cela ouvre la porte une multitude
dautres attaques (dtournement, DoS, etc.).
Par ailleurs, il est trs simple de connatre les routes utilises pour transmettre les
messages SIP (au travers des champs VIA dans lenttes des messages SIP, voir Figure
19). Cela peut par exemple permettre de se faire passer pour lun des proxy.
Figure 19 - Les clients sont malveillants
Dbordement de tampon (buffer overflow) :

Lutilisation de messages INVITE modifis ou fragments peut causer un dbordement de
tampon. Ceci est d une mauvaise implmentation de SIP chez les constructeurs de
matriels/logiciels de VoIP. Ce type dattaque peut permettre davoir un accs privilgi non
autoris (excution de code malicieux), un comportement instable du systme (interruption
de services) ou entraner un DoS sur lappareil recevant le message, le faisant ainsi tomber
en panne ou lobligeant redmarrer la plupart du temps.
Ceci nest pas toujours possible mais actuellement la plupart des tlphones IP, des
gateways, des firewalls et des logiciels serveurs SIP sont concerns. La validit de ces
vulnrabilits dpend du type de matriel/logiciel (propre aux constructeurs) de dploiement
SIP pour la VoIP ainsi que les diffrentes version de firmware et dIOS utilises (logiciel
systme des tlphones, routeurs et autres).
Page 26 sur 107
05.04.2005
Ludovic Maret
5.1.2 Vulnrabilits des systmes dexploitation

La majorit des vulnrabilits des systmes dexploitation des HardPhones sont les
dbordements de tampon (buffer overrun) qui peuvent permettre un pirate de prendre une
partie ou le contrle total de la station. Ce ne sont pas les seules et dautres vulnrabilits
sont utilisables par les pirates suivants les systmes dexploitation des constructeurs et leurs
versions (malwares). Ces vulnrabilits sont pour la plupart relatives un manque de
scurit dans la phase initiale de dveloppement du systme dexploitation et par
consquent sont dcouvertes aprs le lancement du produit.
Suivant les constructeurs et suivant les versions de firmware, les vulnrabilits suivantes
peuvent apparatre :
Mot de passe administrateur par dfaut :
Si le pirate a un accs physique au tlphone et que celui-ci na pas chang son mot de
passe administrateur par dfaut, il aura un accs total au tlphone et pourra, de ce fait,
faire ce quil veut (appels gratuits, changement de mot de passe, tlchargement de
firmware contenant des malwares, etc.).
Par exemple, il est possible dobtenir les droits administrateurs (Pingtel) en activant loption
more menu factory default le mot de passe par dfaut sera null. De cette manire
nous pouvons obtenir les droits administrateurs.
Fuite dinformations (information leakage - Pingtel) :
Nimporte quel utilisateur authentifi peut, en regardant le tlphone lors dun appel, dores
et dj rcuprer les informations sur le numro de tlphone et le plus souvent le nom du
participant. Il peut galement activer/dsactiver les logs de messages SIP ou encore en
lister le contenu et ainsi de dcouvrir beaucoup dinformations sur les autres partenaires
SIP.
Virus, vers (worms), codes malveillants (malicious codes) et exploits :
Comme tout logiciel, ceux qui sont utiliss en VoIP sont galement vulnrables aux
malwares et aux exploits. Par exemple, Nimda sattaque au Call Manager de Cisco et peux
engendrer des gros problmes de scurit.
Epuisement de ressources (resource exhaustion) :
Une attaque DoS base sur DHCP pourrait affamer le rseau dadresses IP en puisant le
pool dadresses IP du serveur DHCP dans un rseau VoIP. Et ainsi tous les tlphones ne
possdant pas encore dadresse IP ne pourront tlphoner. Par ailleurs, ceci peut
galement affecter toutes les stations qui dsireraient obtenir une nouvelle adresse IP de
manire dynamique et cela uniquement si il ny a quun seul serveur DHCP pour le rseau
de donne et le rseau de VoIP.
Page 27 sur 107
05.04.2005
Ludovic Maret
Abuser linterface Web (Pingtel) :
Manipulation de la signalisation : En utilisant le mot de passe administrateur, une

personne malveillante peut sauthentifier sur le serveur Web. Laccs administrateur
donne un contrle total sur les paramtres du tlphone. Ces paramtres incluent la
configuration dun serveur proxy/redirection SIP ou autre. En manipulant un ou plusieurs
de ces paramtres, il peut obtenir un contrle complet sur le flux audio VoIP. Ceci peut
tre fait spcifiant des serveurs malveillants.
Dtournement dappel (call hijacking) : En utilisant linterface Web authentifi en tant

quadministrateur, un utilisateur peut modifier les paramtres de transfert dappel.
Paramtrer tous les appels tre transfr un autre URI SIP ou numro de tlphone
permet lutilisateur malveillant de dtourner tout le trafic du tlphone vers un tiers.
Quand le "call forwarding" est activ, aucune notification nest prsente lutilisateur
dun quelconque appel entrant ou dtourn.
DoS : Un attaquant peut introduire une condition de DoS en manipulant nimporte lequel
des paramtres suivants :
o
Si la personne possde un accs administrateur :

1. Ports dcoute : SIP SIP_TCP_PORT = SIP_UDP_PORT (autre que zro).
2. Ncessit dauthentifier les appels entrants : SIP_AUTHENTICATE_SCHEME
soit Digest soit Basic.
3. Altrer le comportement du serveur Web : PHONESET_HTTP_PORT = 0 le
serveur steint.
Si la personne est simplement authentifie :

1. Redmarrer le tlphone : Pendant 45 secondes le tlphone est inutilisable.
2. Arrt de la communication tlphonique courante : Slection du partenaire puis
Hangup.
3. Neutraliser la sonnerie : Remplacer la sonnerie par un fichier vide ou silencieux.
Puis mettre la mthode ALERT sur ring only.
Attaques TFTP :
Les attaques TFTP sont inhrentes aux HardPhones. Les serveurs TFTP sont donc des
cibles intressantes pour des personnes mal intentionnes. Les attaques se font
communment en plusieurs tapes :
1. Les tlphones tlchargent le fichier de configuration sur le serveur TFTP.
2. Il faut ensuite dcouvrir les adresses MAC utilises par les tlphones IP sur le rseau.
Cela peut se faire de deux manires diffrentes :
En analysant les transactions rseaux :

o
Si le Phreaker est connect au(x) mme(s) switch(s) de distribution que les

tlphones, le Phreaker peut prendre connaissance facilement des adresses
MAC des tlphones parce que les rponses aux requtes TFTP des tlphones
contiennent galement les adresses MAC des tlphones.
Dautres techniques sont possibles pour rcuprer ces informations, par

exemple : balayement de requte SIP INVITE (SIP INVITE request sweep) ;
ping sweep, combiner des attaques ARP en sniffant le rseau, etc.
Page 28 sur 107
05.04.2005
Ludovic Maret
En utilisant un accs distant Telnet sur le tlphone :

o
Laccs Telnet au tlphone, si on utilise la commande show network permet de

rcuprer les informations suivantes :
a. Plateforme du tlphone
b. Serveur DHCP
c. Adresse IP et masque de sous-rseau
d. Passerelle par dfaut
e. Adresse IP du serveur TFTP
f. Adresse MAC
g. Nom de domaine
h. Nom du tlphone
3. Le tlphone va ensuite tlcharger les fichiers de configurations spcifiques depuis le

serveur TFTP :
Ladresse MAC dun tlphone IP pourrait probablement tre utilise pour construire
le nom de fichier de la configuration spcifique du tlphone. Lattaquant a
simplement besoin dexaminer le paramtre tftp_cfg_dir dans le fichier de
configuration gnrique afin de dterminer ou les fichiers de configuration spcifique
sont stocks. Rcuprer le fichier est doffice effectu tant donn que TFTP est un
protocole avec authentification.
Les informations les plus importantes stockes dans le fichier de configuration

spcifique sont les credentials utiliss par le(s) utilisateur(s) du tlphone utiliss
pour sauthentifier sur le rseau de tlphonie IP. Ces paramtres se trouvent sous
la ligne configuration parameters : linex_authname et linex_password.
4. Si il ny a pas daccs Telnet sur le tlphone, il est tout de meme possible de :
Utiliser la force brute sur les noms de fichier du serveur TFTP.
Ractiver le service Telnet.
Manipuler limage du firmware du tlphone.
Limage du firmware est tlcharge et installe sans authentification. Limage du

firmware nest signe en aucun cas afin de pouvoir vrifier sa validit. Une
quelconque image avec un numro de version suprieur la version actuelle est
tacitement considre de confiance. Pour compliquer la situation, pas dautorisation
nest requise depuis lutilisateur avant quune nouvelle image de firmware soit
installe. La combinaison du manque dauthentification et dautorisation de limage
de firmware veut dire quun attaquant avec un accs en criture sur le serveur TFTP
est capable de contrler compltement tous les aspects du tlphone IP.
5. Si une personne malveillante a un accs physique au tlphone :
Elle est capable de reconfigurer les paramtres rseaux du tlphone en utilisant

son interface utilisateur. Laccs aux paramtres peut se faire en utilisant la
combinaison de touches **# (Cisco IP Phone 7960).
Avec un accs physique au tlphone tout est possible (par exemple : redmarrer le
tlphone, rcuprer ladresse MAC, etc.).
Page 29 sur 107
05.04.2005
Ludovic Maret
Il existe encore une multitude de vulnrabilits propres aux systmes dexploitations des
constructeurs de tlphone IP. Il ne sagit ci-dessus que des cas les plus courants. Si vous
dsirez une liste exhaustive de ces vulnrabilits je vous invite aller directement sur les
sites Internet des fabricants.
5.1.3 Vulnrabilits dinfrastructure

Les rseaux de VoIP peuvent tre dploys en toute scurit dans un environnement
rseau scuris isol sans trop de risques. Ceci sadresse tous les protocoles, mais en
ralit si lentreprise besoin dtre connecte Internet comme cest souvent le cas
aujourdhui il faudra soccuper de tous les problmes additionnels associs. Nous ne devons
pas seulement nous inquiter de scuriser notre rseau de donne mais galement le
rseau de voix. Un des soucis principal est donc la disponibilit de nos rseaux.
A chaque fois quune panne survient avec notre rseau de donnes notre rseau de voix va
devenir une forme de rseau de sauvegarde pour notre rseau de donne. En combinant
les deux rseaux, la fragilit de la disponibilit augmente de manire drastique. Nimporte
quel businessman va immdiatement utiliser le tlphone de manire pouvoir continuer
les oprations, avec au moins le premier appel vers le technicien de service ou une
personne de soutien aussi bien en interne quen externe.
Cette situation cre un environnement qui pourrait devenir trs attirant pour les pirates. En
utilisant une attaque de type DoS par exemple, il devient trs facile dinterrompre deux
services la place dun seul, lesquels pourront permettre un pirate malveillant dexploiter
trs facilement cette opportunit si lentreprise nest pas protge.
5.1.4 Vulnrabilits humaines

Ce type de vulnrabilits comprend le problme de ladministrateur rseau et de
lorganisation de lentreprise. Il y a une bataille entre le "facile utiliser" et la scurit dun
rseau. Dans lenvironnement dune petite entreprise, le problme est complexe parce
quune minorit de personnes travaille sur plusieurs sujets diffrents afin de diminuer les
cots et parce quil n y a pas assez pour du travail temps plein sur un sujet. Lautre
problme est le cot dune personne plein temps avec beaucoup dexprience afin dviter
que lentreprise compte sur des consultants externes, des revendeurs et/ou installeurs.
Dans cette situation, la meilleure chose faire est de laisser les dcisions sur la scurit
un consultant ou un revendeur qui ne porte pas beaucoup dimportance consacrer du
temps supplmentaire pour scuriser et maintenir le rseau moins quil soit
spcifiquement engag pour le faire.
Page 30 sur 107
05.04.2005
Ludovic Maret
5.2 Vulnrabilits lextrieur de lentreprise

Si le rseau de donne de lentreprise nest pas scuris est quil possde un accs un
WAN (Internet par exemple), alors le rseau de VoIP/SIP devient une cible trs intressante
pour des personnes mal intentionnes.
Une telle personne qui parvient sintroduire dans le rseau de lentreprise peut tout autant
sattaquer au rseau de donne quau rseau de VoIP. Imaginons quune personne
malveillante se trouvant sur son rseau domestique avec un accs Internet via NAT-routeur
ait install son proxy SIP. Il suffit quil connaisse ladresse IP du outbound proxy de
lentreprise (avec une attaque de scanning de port et dadresses IP par exemple afin de
dtecter si le port 5060 est ouvert sur une station) pour pouvoir lutiliser en tant que
passerelle mdia (en admettant que le outbound proxy se trouve dans la DMZ par exemple).
Cette personne pourra ensuite sattaquer aux UAs du rseau qui sont grs par ce proxy. Il
peut par exemple utiliser des attaques de DoS Bulk INVITE, SPAM dINVITE ou dIM. En
vrit, toutes les attaques que lon a vu lintrieur de lentreprise qui ne ncessite pas de
se trouver physiquement sur le mme sous-rseau ou sur le mme hub sont possibles (IP
spoofing, registration hijacking, puisement de ressources DHCP, etc.). Il nest donc pas
possible dcouter des communications qui transiteraient au sein de lentreprise, de
dtourner des appels en injectant un message 302 Moved Temporarily ou encore dutiliser
de lARP spoofing pour dtourner les flux audio et la signalisation SIP.
Un autre danger dattaque peut survenir si lentreprise possde un NAT pour sa connexion
Internet et quelle a adopt un mcanisme de passage au travers du NAT (voir annexe
Projet de semestre : Traversal FW/NAT). Si ce mcanisme met contribution un lment
rseau se trouvant sur le rseau public, il suffit que lattaquant intercepte les messages
transitant entre cette entit et le rseau dentreprise. Grce ces messages, lattaquant
peut apprendre normment dinformations sensibles (notamment les adresses IP mappes
sur le NAT) qui peuvent lui permettre de sattaquer directement aux UAs du rseau
dentreprise.
Le plus grand danger reste lattaque du relais RTP de lentreprise. Si lattaquant parvient
capturer ou dtourner le trafic transitant travers le relais (avec de lIP spoofing par
exemple) alors il pourra couter toutes les communications entrantes et sortantes de
lentreprise. De manire analogue, il est possible de capturer tout le trafic de signalisation
entrant et sortant de lentreprise au niveau de la passerelle de signalisation.
En rsum, nimporte quelle personne stant introduite dans le rseau dune entreprise
ayant dploy le service de VoIP/SIP sans mcanismes de scurisation peut sattaquer
aussi bien au service de VoIP lui-mme (DoS) quaux UAs du rseau.
Page 31 sur 107
05.04.2005
Ludovic Maret
6 ARCHITECTURES DE DPLOIEMENT DE LA VOIP/SIP

Le but ici et de dfinir et de prsenter les diffrentes architectures de dploiement possibles
en tenant compte dune configuration disposant dun propre GW ISDN et dune connexion
VoIP travers Internet pour communiquer avec dautres filiales ou des collaborateurs
itinrants.
Voil ce quoi pourrait ressembler larchitecture globale du rseau considr ci-dessous :
Figure 20 - Architecture globale du rseau
Il existe deux stratgies de dploiement possible dun rseau tlphonique regroupant de la

VoIP et de la tlphonie ISDN ou PSTN avec ou sans PBX [SA13] : larchitecture IP centrale
(IP-centric) ou architecture IP hybride (IP-enabled) et larchitecture via ITSP (Internet
Telephony Service Provider). Ces deux types darchitecture se diffrencient essentiellement
par ces trois questions :
1. O le PBX de conversion IP va se trouver ? Do une transformation du PBX en PBX
routeur puis en IP-PBX [SA14] (seulement dans le cas o un PBX existe et est
ncessaire).
2. O soccuper des fonctions de centre dappel, 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 dun systme complet de tlphonie sur IP ou alors
simplement quelques tlphone IP utiliser. Dans ce cas, lutilisation dun ITSP est
prfrable.
Page 32 sur 107
05.04.2005
Ludovic Maret
6.1 Dploiement complet dune plateforme de VoIP :

6.1.1 Architecture IP-enabled
Un systme de ce type contient essentiellement le mme noyau darchitecture quun
systme PBX (une matrice switche TDM, un contrle CPU/commun et un logiciel de
traitement des appels) avec la possibilit supplmentaire de se servir aussi bien de
tlphones standards TDM [SA15] que de tlphones IP via diffrentes cartes ct stations
et ct terminaux du rseau IP. Le contrle CPU/commun et le logiciel de traitement des
appels peuvent rester dans la matrice switche TDM ou sur un serveur externe.
Dans un rseau de stations uniquement IP, larchitecture IP-enabled va influencer sur
linfrastructure de donnes de lentreprise aussi bien pour les tlphones IP que pour la
connectique des PCs. La plupart des tlphones IP permettent une connectique avec le PC
laide dun commutateur mini-Ethernet afin de nutiliser quun seul port sur le switch.
Ce type darchitecture convient particulirement bien aux entreprises qui dsirent migrer
vers la VoIP de manire progressive. Vous trouverez ci-dessous un exemple darchitecture
IP-enabled adapt un site unique :
Figure 21 - Dploiement d'un site unique suivant une architecture IP-enabled
Dans un environnement multi-sites, cette architecture simplifie la connectique inter-site. Les

deux communications spares utilises pour la voix et les donnes dans un monde TDM
sont combines en une infrastructure de donne uniforme.
Page 33 sur 107
05.04.2005
Ludovic Maret
Voici ci-dessous un exemple denvironnement multi-site IP-enabled.
Figure 22 - Dploiement d'un multi-site suivant une architecture IP-enabled
Ici, lquipement de localisation de la socit mre fournit toute lintelligence de routage de

lentreprise et dirige les appels entrants au bon emplacement sur le WAN. Il est noter que
dans cet exemple, lquipement du site B nest compos que du strict minimum, savoir un
routeur, un switch et des tlphones IP. Les appels destins au site B sont termins sur le
switch de la socit mre, convertis en IP la passerelle puis transports au site B via
linfrastructure rseau et le WAN.
Le site A peut recevoir des appels entrants depuis la socit mre travers le WAN de
manire analogue au site B ou alors directement depuis le PSTN avec un contrle dappel
distance fourni par le switch de la socit mre IP-enabled. Pour la plupart des vendeurs,
cette configuration requiert laddition dune passerelle mdia au site A.
Un WAN avec une QoS adquate est dcisif pour un dploiement de VoIP multi-site.
Puisqu Internet ne supporte pas la QoS, la plupart des providers de services privs 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
Ludovic Maret
Voici ci-dessous les avantages et les inconvnients des solutions bases sur une
architecture IP-enabled :
Avantages de IP-enabled
Inclut les composants TDM et le logiciel qui sont
considrs comme prouvs et de technologie
fiable.
Traitement efficace de lappelant avec des
services tels que la gestion des files dattentes,
les annonces, la musique en attente et autres.
Mise lchelle trs simple pour de grands
centres dappel qui doivent supporter un grand
nombre de clients appelant en file.
Permet la migration lente IP pendant que
linvestissement augmente et que les risques
diminuent.
Inconvnients de IP-enabled
Requiert des investissements importants dans la
technologie propritaire dun vendeur unique.
Les configurations multi-site peuvent requrir des
composants prioritaires additionnels (par ex :
passerelle mdia), par ailleurs linvestissement
augmente avec une solution de vendeur unique.
Larchitecture mixe incluant des composants
PBX et IP avec une complexit de gestion plus
grande quavec des architectures IP-centric (voir
point suivant).
Tableau 1 - Avantages et inconvnients de l'architecture IP-enabled
Page 35 sur 107
05.04.2005
Ludovic Maret
6.1.2 Architecture IP-centric

Les systmes IP-centric dcomposent compltement larchitecture du PBX. La matrice
switche TDM est remplace par linfrastructure de donne de lentreprise. Les
fonctionnalits de contrleur dappels, de gestion de la file dattente, des annonces et de la
musique de mise en attente sont fournies via des processus serveur spars qui peuvent ou
pas rsider sur des serveurs physiques spars.
Vous trouverez ci-dessous un exemple denvironnement de site unique suivant une
architecture IP-centric :
Figure 23 - Dploiement d'un site unique suivant une architecture IP-centric
Dans le dploiement dun site unique, un routeur doit jouer le rle de la passerelle mdia.
Par la suite, tout le traitement et la commutation des appels sont effectus avec des
paquets. La fonctionnalit de contrle dappel est habituellement accomplie par un serveur
spar et peut tre configure dans un cluster pour assurer la redondance. La gestion des
files dappels, la musique dattente et les annonces sont galement accomplies via un
serveur spar : le serveur de mdia. Des serveurs de mdia additionnels peuvent tre
requis en fonction du nombre de sessions/connexions simultanes. Actuellement, chaque
appel en file, que lon soit en train dcouter de la musique ou une annonce, est allou sur
un flux de VoIP ddi, lequel utilise des cycles CPU.
Un systme IP-centric se dcompose de la mme manire que prcdemment pour un
dploiement multi-site. Un serveur de contrle dappels centralis contrle les flux VoIP,
quils arrivent directement dans la socit mre principale ou les sites distants. Avec ce type
de dploiement, le serveur de contrle dappels (SIP proxy/registrar) de la socit mre
contrle toutes les communications entrantes indpendamment de la localisation.
Page 36 sur 107
05.04.2005
Ludovic Maret
Les appels PSTN entrants la socit mre sont convertis de TDM en IP via la passerelle
mdia (IP-PBX ou IPBX). Le serveur de contrle dappels tabli un flux VoIP avec le serveur
de mdia pour le traitement en file et ensuite connecte lappel avec le tlphone IP
appropri.
La communication entre la socit mre et les sites distants est similaire la solution IPenabled (voir Figure 24).
Figure 24 - Dploiement d'un multi-site suivant une architecture IP-centric
Voici ci-dessous les avantages et les inconvnients des solutions bases sur une
architecture IP-centric :
Avantages de IP-centric
Fourni une architecture flexible et logique pour le
routage des appels.
Donne un nouvel lan linfrastructure de
donnes et minimise les investissements en
composants TDM.
Fournis une meilleure flexibilit dans les
environnements distribus, spcialement dans
les configurations avec une redirection locale
dappels dans de multiples petits sites.
Fournis un choix dans lachat des lments
technologiques et autorise le mlange
denvironnements pour les routeurs, les serveurs,
les applications, etc.
Inconvnients de IP-centric
Une architecture dcompose requiert des
plateformes de serveurs multiples.
Requiert une trs grande fiabilit et robustesse
de linfrastructure de donne.
Mise lchelle difficile pour le traitement dun
trs grand nombre dutilisateurs appelants en file.
Peut tre considr moins fiable ; peut ne pas

tre trs bien adapt pour des oprations de
central dappel 24x7 (24h/24 7j/7).
Page 37 sur 107
05.04.2005
Ludovic Maret
Tableau 2 - Avantages et inconvnients de l'architecture IP-centric
6.2 Architecture via ITSP

Un provider de services de tlphonie par Internet (ITSP) utilise les rseaux IP pour fournir
des connexions de voix/fax bas prix travers la combinaison dInternet, des lignes loues
et du rseau de tlphonie public commut (PSTN).
Un ITSP utilise donc Internet comme mdia de transport principal pour convoyer les
donnes empaquetes de signalisation et de voix depuis et entre des abonns. LITSP et
ses abonns seront connects Internet ; lITSP via des liaisons rapides ddies tandis que
les abonns utilisent leurs connexions Internet habituelles (modems tlphoniques
standards, xDSL, etc.) via diffrents providers de service Internet (ISPs).
Un abonn a la possibilit dutiliser diffrentes mthodes afin de passer un appel, toutes ces
possibilits ncessitent que labonn prsente ses credentials avant que la requte dappel
puisse tre traite. Un abonn a moyen dutiliser un SoftPhone, un HardPhone ou dautres
appareils de tlphonies IP (par exemple des adaptateurs de tlphones pour pouvoir
utiliser un tlphone standard en tant que tlphone IP) afin de passer lappel.
Une infrastructure dITSP inclut un support dauthentification, de facturation et dautres
dispositifs indispensables. LITSP utilise des passerelles de voix places dans diffrents
pays et connectes au backbone IP de lITSP travers des lignes loues. LITSP va diriger
une requte dappel la passerelle de voix approprie en accord avec le numro compos.
La passerelle de voix va traduire les paquets de voix (si la requte dappel a t acquitte
par le partenaire appel) et les paquets dinformations de signalisation convoys par des
protocoles bass sur IP en informations pouvant tre convoyes par des protocoles utiliss
avec les rseaux de tlphonie traditionnelle (SS7 ou autres) et vice versa.
Vous trouverez ci-dessous un petit schma illustrant lutilisation dITSP pour communiquer
avec un tlphone se trouvant sur le PSTN :
Page 38 sur 107
05.04.2005
Ludovic Maret
Figure 25 - Dploiement de la VoIP via un ITSP
Voici ci-dessous un exemple dutilisation 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 dun abonnement chez un ITSP nest vritablement
adapte qua des particuliers ne possdant que trs peu de tlphones. En effet, il est vite
intressant, surtout du point de vue du prix, de mettre en place son propre systme de
VoIP/SIP au sein dune entreprise mais cela est probablement inutile dans le cas de
particuliers ne possdants que peu de tlphones.
Page 39 sur 107
05.04.2005
Ludovic Maret
Il subsiste nanmoins un problme avec ce type darchitecture de tlphonie. En effet

Internet nest utilis que comme une "partie" de linfrastructure de lITSP et par consquent
celui-ci est dans limpossibilit de garantir une QoS (bande passante suffisante, pas de
congestion, etc.), laquelle peut aboutir une qualit rduite de la voix.
6.3 Architecture finale

Etant donn que larchitecture IP-enabled nest quune tape plus ou moins longue de
transition vers une architecture IP-centric et que la souscription dun abonnement un ITSP
nest pas adapte pour une entreprise, on va prendre en considration ici uniquement
larchitecture finale de dploiement IP-centric en supposant que celle-ci possde dj un
PBX avec liaison PSTN et ISDN ainsi quune connexion Internet.
Il va donc falloir migrer vers une architecture SIP IP-centric simple. Larchitecture devra
peu prs sapparenter la Figure 24. Si nous le dsirons, il y a mme la possibilit de
connecter le gateway ISDN sur le IP-PBX et nous obtenons ainsi une architecture
entirement centralise.
Cest donc en fonction de cette architecture que lon va dfinir des stratgies et des
mcanismes de scurisation.
Page 40 sur 107
05.04.2005
Ludovic Maret
7 PRESCRIPTIONS DE SCURISATION DE LA VOIP/SIP

Dici un proche avenir, les mcanismes de scurit les plus courants (authentification,
chiffrage) feront partie intgrante des standards de VoIP/SIP. Toutefois, aujourdhui il existe
de nombreuses technologies de scurit IP-centric qui peuvent tre intgres afin
damliorer la scurit de lenvironnement de VoIP/SIP. La scurit de rseaux de VoIP/SIP
inclut la scurit au niveau des paquets de voix, laquelle se concentre sur les fonctionnalits
des applications, et la scurit IP qui, elle, se concentre sur la scurit du rseau ou du
transport. Contrler la scurit ces niveaux de lenvironnement de VoIP/SIP peut
ncessiter un redimensionnement et/ou une re-organisation technique du rseau. Ceci
pourrait affecter larchitecture du rseau supportant lenvironnement de VoIP/SIP. Quand un
systme de VoIP/SIP est dploy, certains aspects spcifiques demandent une attention
plus approfondie. Ce sont ces sujets que nous allons prendre en considration afin de
dployer la VoIP/SIP de manire scurise. Il est important de garder lesprit que
scuriser nimporte quel rseau est un processus continu qui ncessite dtre
continuellement lcoute des dernires vulnrabilits qui peuvent subsister dans les
composants de linfrastructure rseau (serveurs, OS, applications dployes travers
lentreprise).
Larchitecture de scurit suivante (voir Figure 27) dcrit un type gnrique de site
dentreprise avec le service de VoIP/SIP. Cette architecture peut tre considre comme la
rfrence de base lorsque lon dsire scuriser un rseau avec le service de VoIP/SIP.
Larchitecture ci-dessous est de type IP-centric. Il est galement possible de scuriser un
rseau de type IP-enabled de cette manire.
Figure 27 - Architecture de scurit logique
Page 41 sur 107
05.04.2005
Ludovic Maret
7.1 Scurit physique

Les routeurs, les switchs Ethernet, les passerelles de tlphonie et les serveurs dterminent
les limites du rseau de VoIP/SIP et peuvent jouer le rle dinterfaces avec dautres
rseaux. Ces lments de rseau peuvent fournir aussi bien la connectivit logique que
physique du rseau dentreprise complet et devraient tre considrs comme les cibles
particulires dfendre contre les attaques. Pour se prvenir contre les accs physiques
non autoriss ces lments, des mesures doivent tre prisent afin dassurer leur
protection. Ces prcautions comprennent des accs restreints aux salles des serveurs et les
installations rseaux doivent tre uniquement accessible au personnel autoris.
7.2 Sparation des adresses logiques

La VoIP/SIP fournit plusieurs moyens dincorporation de la tlphonie sur un rseau IP
existant. Toutefois, pour des raisons de QoS, de performance, de maniabilit et de scurit,
le dploiement des lments de tlphonie IP et dlments de donnes IP doivent tre
dploys sur deux segments logiques IP spars. La combinaison de segmentation
donnes/voix ainsi quune infrastructure switche attnue dj fortement les attaques de
types eavesdropping. De plus, la limitation de laccs logique aux composants de VoIP/SIP
est ncessaire afin de protger les applications de tlphonie sexcutant travers
linfrastructure. Le fait de contrler les accs aux lments de VoIP/SIP (serveurs et
terminaux) avec des filtres IP peut aider assurer une scurit et un soutient important pour
protger lenvironnement de VoIP/SIP des menaces externes.
Tous les lments de VoIP/SIP (serveur proxy, serveur denregistrement, terminaux, etc.)
devraient tre dploys sur leur propre rseau ou sous-rseau IP priv. Idalement, ces
sous-rseaux devraient utiliser un espace dadresses diffrent de celui utilis dans les
rseaux de donnes. Il faudrait, si possible, nutiliser que des adresses non routables
(prives) [rf. RFC 1918] afin de sparer de manire encore plus forte le rseau de
VoIP/SIP et le rseau de donnes.
Ceci permet de rduire les chances que le trafic de voix sorte en dehors du segment de
rseau tlphonique et inversement.
Des connexions rseau peuvent tre requises entre les segments rseau de VoIP/SIP et de
donnes afin de fournir des services tels quune bote vocale de messages (voir
"voicemail"). Dans ce cas de figure, afin daider protger le segment rseau de VoIP/SIP,
le NAT devrait tre implment sur le point de connexion du segment VoIP/donnes. Ceci
fournit une protection supplmentaire qui aura comme effet que les hackers situs en
dehors du segment rseau de VoIP/SIP seront incapables de scanner le segment de
VoIP/SIP afin den dcouvrir les vulnrabilits et ceci moins que le NAT ne soit pas
implment ou mal configur.
Page 42 sur 107
05.04.2005
Ludovic Maret
7.3 VLANs
Le trafic VoIP/SIP doit tre divis du rseau de donnes traditionnel en utilisant des rseaux
locaux virtuels (VLAN). Dans un environnement rseau switch, les VLANs crent une
sparation logique des domaines de collisions qui peut stendre aux multiples segments du
rseau physique. La sparation des domaines de collisions sert limiter le risque que des
attaques de type DoS ou packet sniffing sur le rseau de donnes puissent affecter le
rseau de voix et inversement. De plus, sparer la voix et le trafic de donnes dans des
domaines de collisions distincts va rduire la concurrence daccs pour le rseau et, de ce
fait, va rduire galement la latence (file/temps dattente) pour les services de transmission.
Il est inutile de rappeler que la VoIP/SIP est trs sensible cette latence (QoS). Cette
approche de segmentation est donc le moyen le meilleur march pour amliorer les
performances dans une infrastructure rseau existante.
Les VLANs peuvent donc accrotre la scurit de lenvironnement de VoIP/SIP en
segmentant la voix et les donnes pour les PCs qui sont connects via des tlphones
VoIP/SIP. Cette segmentation VLAN rduit galement les problmes de conflits potentiels
avec les vidophones quand tout ce qui est voix, donnes et vido vient de la mme source.
La mise en place des VLANs peut tre configure sur le principe du VLAN de ports. Les
ports de VLAN pour la VoIP/SIP peuvent tre scuriss en assignant une adresse MAC dun
tlphone sur un port simple. Les ports VLAN du switch qui ne sont pas utiliss par des
quipements de voix actifs doivent tre dsactivs ou assigns un diffrent VLAN. De
plus, certains tlphones VoIP/SIP possdent des ports rseaux "built-in" qui ont comme but
de pouvoir y connecter une station.
Ce type de tlphone VoIP/SIP se doit de supporter la configuration de son port rseau
dans un VLAN spar et doit galement permettre de dsactiver lutilisation de ce port. Le
fait de dsactiver les ports VLAN de VoIP/SIP non utiliss diminue le risque que des
lments rseau malveillants puissent tre ajouts dans le rseau de VoIP/SIP. Afin
daugmenter la protection contre ces lments, un port VLAN peut tre configur pour
uniquement connecter une adresse MAC bien prcise.
Lors de la mise en place de VLANs de segmentation des rseaux VoIP/donnes il est
important de se poser ces quelques questions concernant lattribution des adresses IP :
Faut-il utiliser des adresses IP fixes pour les HardPhones IP ?
o Oui. Dans ce cas, on rserve deux pools dadresses IP bien distincts pour les deux
VLANs. Ceci nest pas intressant si il y a sur le rseau des SoftPhones qui utilisent
dj un service DHCP.
o Non. Dans ce cas, faut-il ajouter un serveur DHCP ddi 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 mthode dun point de vue scurit. En effet, il est fortement
conseill dattribuer des adresses IP de pools diffrents pour les deux VLANs.
Ceci est possible spcifiant sur le serveur DHCP que lattribution des
adresses IP se fait de manire statique pour les tlphones IP (et ceci grce
aux adresses MAC). Il faut donc connatre toutes les adresses MAC des
tlphones et mettre sur place la liste dadresses statiques. Si le rseau de
VoIP est en perptuel mouvement (ajout/suppression de tlphones), cette
mthode devient vite trs lourde. Il vaut de mieux viter cette configuration au
profit de la mise en place dun serveur DHCP ddi la VoIP.
Page 43 sur 107
05.04.2005
Ludovic Maret
7.4 SoftPhones et HardPhones IP

Les agents de SoftPhones IP rsident par inhrence dans le segment de donnes mais
requiert un accs au segment de voix afin de pouvoir contrler des appels, passer des
appels et de laisser des messages vocaux. Toutefois, les SoftPhones ne sont pas
immuniss contre les attaques envers les HardPhones. Les SoftPhones PCs sont mme
plus vulnrables que les HardPhones et ceci pour la simple et bonne raison quil existe un
grand nombre daccs possibles dans un systme PC. Ces possibilits daccs dpendent
de lOS, des applications rsidentes et des services autoriss qui sont tous sujets aux vers,
aux virus, etc. De plus, les SoftPhones doivent rsider la fois sur le segment de donnes
et sur le segment VoIP et sont de ce fait sensibles aux attaques envers lentiret du rseau
et pas juste le PC lui-mme. Par contre, les HardPhones IP doivent tre situs dans le
segment de VoIP/SIP et sexcutent sur des OS propritaires implmentant des services
rseaux limits et ont donc certainement moins de vulnrabilits. Puisque le dploiement de
SoftPhones fournit une brche intressante pour des attaques malveillantes envers le
segment de voix, ces tlphones reprsentent un grand risque pour lentiret de
lenvironnement de VoIP/SIP.
De nombreux HardPhones IP fournissent un port de donne spar pour la connexion dun
PC. Donc, seul un cble est requis pour permettre la connectivit de donnes et de voix sur
le PC de lutilisateur. En outre, certains HardPhones IP sont uniquement capables de fournir
une connectivit basique de niveau 2. Ils jouent donc le rle dun hub en combinant les
segments rseau de donnes et de voix. Tandis que dautres tlphones IP offrent une
connectivit de niveau 2 tendue permettant lutilisation de la technologie VLAN afin de
placer le tlphone et le trafic de donnes sur deux diffrents VLANs. Pour assurer une
sparation logique de la voix et des donnes afin de maintenir la scurit de
lenvironnement de VoIP/SIP, uniquement les HardPhones implmentant le VLAN de niveau
2 tendu doivent tre utiliss.
Voici ci-dessous un rsum des trois diffrentes configurations possibles de tlphones IP :
Figure 28 - Configurations de connexions de tlphones IP
1. La premire configuration est appele daisy-chain. Le HardPhone est connect au

switch tandis le PC est connect au tlphone. La particularit de cette configuration
est que, sur le segment se trouvant entre le tlphone et le switch, deux types de
trafics VoIP/donne vont devoir cohabiter. Ceci implique que le port du switch doit
tre configur de manire pouvoir vhiculer les deux types de trafics
simultanment grce une encapsulation (trunk).
Page 44 sur 107
05.04.2005
Ludovic Maret
2. La deuxime ncessite autant de ports sur le switch qu'il y a de terminaux (PC ou

HardPhones).
3. La troisime est un SoftShone. La connectique se fait avec un cble par SoftPhone.
Il faut galement faire attention la connectique dans le cas o lon souhaite utiliser un
service de voicemail. En effet, nimporte quelles connexions entre les segments de voix et
de donne requises par les tlphones pour laccs la bote vocale de messages doivent
tre contrles en bloquant laccs direct des donnes au segment de rseau de voix afin
dviter que les vulnrabilits de donnes et les tunnels de donnes ne compromettent le
segment de voix. Ceci peut tre effectu en plaant un firewall entre les segments de voix et
de donne.
7.5 Firewalls
Les systmes de VoIP/SIP requirent que de nombreux ports soient ouverts dans le
firewall afin dviter un dlai sensible de remise des paquets. Le protocole utilis pour
convoyer le trafic (RTP/RTCP) de VoIP/SIP travers le rseau 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 lmission/rception dinformations utiles
dutilisateur, la voix dans notre cas. Louverture dun intervalle de ports aussi large va
assurment compromettre tout le rseau. Il y a deux mthodes qui peuvent tre utilises
pour aider surmonter cette vulnrabilit ; le mapping de ports dynamique et le mapping de
ports statique.
Le mapping de ports dynamique limite la palette de ports qui pourraient tre utilise pour le
trafic de VoIP/SIP. Ceci rduit le nombre de ports qui sont ouverts sur le rseau, mais avec
quatre ports (1023 et plus) requis par connexion, ce nombre pourrait trs vite augmenter.
Cette option de configuration requiert un firewall statefull soccupant 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
considrable de temps pour configurer les routeurs et doit tre modifie chaque fois quun
utilisateur de VoIP/SIP besoin dtre ajout ou retir. Sans un firewall statefull soccupant
de toutes les connexions entre les rseaux de donnes et de voix, nous devrions autoriser
de larges intervalles de ports.
Les firewalls, les routeurs et les switchs doivent tre implments de manire
compartimenter les serveurs de VoIP/SIP face aux accs non autoriss. Ceci est
indispensable pour limiter et contrler les accs depuis le rseau de donnes au rseau de
tlphonie IP. Les firewalls sont placer devant tous les rseaux et les composants
supportant les serveurs de VoIP/SIP. Il faut au minimum quun filtrage IP soit implment
entre les rseaux de donne/voix. Ceci va diminuer la possibilit dattaques qui pourraient
provenir depuis le rseau de donnes.
Page 45 sur 107
05.04.2005
Ludovic Maret
Le tableau ci-dessous contient tous les ports potentiels et les services qui doivent tre pris
en considration dans le filtrage du firewall pour les rseaux et les serveurs de VoIP/SIP :
SERVICE
Skinny
TFTP
SIP
TLS
IPSec
HTTP
MS Terminal Services
RTP/SRTP
SNMP
SNMPtrap
DNS
NTP
LDAP
Echo
Echo-reply
MS-SQL
SSL
SMB
SCCP
HID agent
ICCS
CTIM (CTI manager)
OSS
PORT
TCP 2000-2002
UDP 69
UDP/TCP 5060
TCP 5061
UDP/TCP 69, 161, 162,389
TCP 8080/80
TCP 3389
UDP/TCP 16384-32767
UDP 161
UDP 162
UDP 53
UDP 123
TCP 389
ICMP echo
ICMP echo-reply
TCP 1433
TCP 443
TCP 445
TCP 3224
TCP 5000
TCP 8002
TCP 8003
TCP 18080
Tableau 3 - Services et ports potentiellement utiliss par la VoIP/SIP
7.6 Gestion du firewall VoIP/SIP

Afin dassurer la scurit du firewall VoIP/SIP, il est impratif que les connexions
administrative/gestion et les accs aux appareils soient contrls. Ceci peut se faire en
accdant ces types dlments localement ou en utilisant des VPN (IPSec) ESP
(Encapsulated Secure Payload).
Par mesure de scurit il faudra donc dcrire de manire explicite ces quelques rgles dans
le firewall :
Soit bloquer les connexions administrative/gestion soit ouvrir IPSec en utilisant des
VPN (ports 69, 161, 162, 389) sur le primtre de scurit VoIP/SIP.
Bloquer MS-SQL (port 1433) sur le primtre de scurit VoIP/SIP.
Bloquer Network Time Protocol (NTP port 123) sur le primtre de scurit VoIP/SIP.
Tous les Remote Web Access (ports 80, 8080, 443, 8002, 8003, 18080, etc.) sur le
primtre de scurit VoIP/SIP sont proxis. Ceci dpend du matriel et du logiciel
de tlphonie SIP.
Chiffrement des connexions Web sur le primtre de scurit VoIP/SIP.
Page 46 sur 107
05.04.2005
Ludovic Maret
7.7 Serveurs de VoIP/SIP critiques

Les serveurs de VoIP/SIP dit "critiques" (proxy, registrar, redirect, etc.) ont besoin dtre
scuriss et traits avec les mmes prcautions que tout autre serveur contenant de
linformation sensible. Les systmes de VoIP/SIP fournissent des dispositifs puissants de
gestion, lesquels peuvent tagger les appels enregistrs de plusieurs manires afin daider
pour les recherches futures. La mise en place des serveurs de VoIP/SIP est cruciale pour
scuriser lenvironnement de traitement de la voix. Ces composants systme doivent se
trouver sur un segment rseau spar et protg par un firewall VoIP/SIP.
Ddier et scuriser les serveurs de VoIP/SIP critiques est la clef de vote de la scurisation
de lenvironnement de tlphonie IP. Certains vendeurs fournissent des services de
tlphonie IP sur leurs propres systmes propritaire tandis que dautres fournissent ces
services sur les systmes standard Unix/Linux et Windows. Par consquent, la scurisation
du traitement de la voix et des plateformes de signalisation pour y inclure leurs applications
est vitale dans la protection de lenvironnement de VoIP/SIP contre les attaques. De plus,
afin de minimiser les risques potentiels, ces serveurs sont ddis aux applications de
tlphonie IP requises pour les oprations de VoIP/SIP.
7.8 Scalabilit
Les serveurs SIP sont limits en nombre de communications simultanes. Cest pourquoi la
notion de scalabilit est trs importante en tlphonie. En effet, si le nombre dutilisateurs
augmente passablement, il faut que le service soit toujours accessible tous les utilisateurs
et cela sans modification majeure du rseau. Il est par exemple possible, si le nombre de
tlphones le permet, de simuler un trs grand nombre de communications SIP de manire
simultanes. Si le serveur ne supporte pas un grand nombre de communications
simultanes, il va saturer et ceci va crer un DoS au niveau de tous les utilisateurs grs
par ce serveur.
Il faut donc utiliser des serveurs SIP pouvant grer un trs grand nombre de
communications simultanes 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 rgles bien
prcises un peu la manire dun firewall. Cela permet, par exemple, dinterdire certaines
adresses IP ou URI dmettrent des messages INVITE ou REGISTER. Cela peut galement
faire en sorte quune certaine adresse IP ait le droit dappeler sans tre authentifie auprs
du serveur denregistrement.
Un peu prs toutes les rgles de niveau 3, 4 et plus sont applicables. Il faut donc faire
attention bien scuriser la plateforme de VoIP et pas le contraire.
Page 47 sur 107
05.04.2005
Ludovic Maret
7.10 Scuriser la session SIP
Authentification
Intgrit des donnes
Confidentialit
Puisque la structure des messages SIP dcoule directement du modle HTTP de

requte/rponse, tous les mcanismes de scurit disponibles pour HTTP peuvent tre
appliqus aux sessions SIP. Dun autre ct, lutilisation de containers MIME (Multi-purpose
Internet Mail Extension) dans les messages SIP suggre lutilisation potentielle de
mcanismes de scurit demail tels que PGP (Pretty Good Privacy) ou S/MIME
(Secure/MIME). De manire similaire HTTPS : lURI sip correspondant sera lURI SIPS.
Ceci va crer un tunnel scuris au niveau transport en utilisant TLS (Transport Layer
Security). IPSec est galement utilisable comme mcanisme gnral de chiffrement pour
toutes les communications IP au niveau rseau.
Les mcanismes de scurit essentiels adapts la protection de la session SIP sont
reprsents dans le Tableau 4. Ils concident avec la liste de mthodes recommandes par
la version 1 du standard SIP. Pour le moment, deux de ces mthodes, savoir
lauthentification HTTP basique et PGP ont t dprcis par la version 2 de SIP.
HTTP 1.0 Basic Authentification
PSK
Dprci par SIPv2

Transmission non scurise du mot de passe
HTTP 1.1 Digest Authentification
PSK
Echange des challenges/rponses bas sur le hash

MD5 dun password, dun username et dun nonce.
PGP
PKI
Dprci par SIPv2
S/MIME
PKI
Pour le chiffrement, la clef publique de lUA de

destination doit tre connue.
SIPS URI (TLS)
PKI
Les applications et proxy SIP doivent supporter

TLS.
IPSec
PKI
Lintgration avec des applications SIP nest pas

requise mais les proxy doivent tre de confiance.
Mthodes dauthentification :
PSK Pre-Shared Key
PKI Public Key Infrastructure
Tableau 4 - Securiser la session SIP
7.10.1 HTTP Basic Authentification

Cette authentification requiert la transmission dun username et de son password
correspondant lintrieur de lentte de la requte SIP. Cette information utilisateur peut
tre utilise par un proxy SIP ou par un UA de destination pour authentifier un client SIP ou
le hop SIP prcdent dans une chane de proxy. Puisque le password en clair peut tre
trs facilement captur sur le rseau et que cela pose des risques de scurit srieux,
lutilisation de lHTTP basic authentification a t dprcie par SIPv2.
Page 48 sur 107
05.04.2005
Ludovic Maret
7.10.2 HTTP Digest Authentification

Cette authentification rsout le problme de mot de passe en clair de lHTTP basic
authentification en transmettant un digest MD5 ou SHA-1 du mot de passe secret et dune
chane de caractre alatoire la place du mot de passe vulnrable uniquement. Bien que
lHTTP digest authentification lavantage que lidentit de lutilisateur peut tre tablie sans
la ncessit de transmettre le mot de passe en clair, cette procdure peut pourtant devenir
une proie facile face aux attaques de dictionnaire off-line bases sur linterception de valeurs
de hash si des mots de passe faibles ou courts sont utiliss. Un autre grand dsavantage
est le manque de mcanisme de chiffrement pour assurer la confidentialit. Ni
lauthentification basique ni lauthentification digest ne peut garantir une intgrit des
messages SIP.
Nous allons voir comment une requte SIP INVITE est authentifie par le premier serveur
proxy en utilisant ce type dauthentification (challenge dauthentification).
Figure 29 - Challenge dauthentification digest
Le proxy recevant le message SIP INVITE rponds immdiatement avec le challenge de la

Figure 29 - Challenge dauthentification digest. Ce message contient un nonce [SA16]
alatoire et dfini lalgorithme digest utiliser (habituellement MD5 ou SHA-1) aussi bien
que le domaine pour lequel lutilisateur doit fournir une authentification.
Sur rception du challenge, lutilisateur renvoie un la requte INVITE dorigine mais sans
oublier dinsrer la rponse au challenge dans lentte du message SIP (voir Figure 30). La
valeur de rponse contient le digest MD5 du username, du password, du nonce, de la
mthode SIP et de lURI de lappelant. Ainsi le password nest pas transmis en clair.
Cependant, le mot de passe doit tre connu par le proxy afin dtre capable de vrifier la
rponse dauthentification.
Page 49 sur 107
05.04.2005
Ludovic Maret
Figure 30 - Requte 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 dprci
lutilisation 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 mcanismes
pour scuriser les contenus MIME afin dassurer aussi bien lintgrit et la confidentialit
grce aux types MIME multipart/signed et application/pkcs7-mime. Des certificats X.509
sont utiliss pour identifier les utilisateurs finaux sur la base de leurs adresses emails,
lesquelles sont une partie de lURI SIP (par exemple : alice@atlanta.com). La signature des
corps MIME est nest pas vraiment un problme puisque chaque utilisateur est en
possession de sa clef prive et que le certificat utilisateur peut tre transmis au rcepteur de
manire incorpore dans les adjonctions pkcs7-mime ou multipart/signed. Dun autre ct,
le chiffrement de contenus MIME, par exemple la cargaison SDP, requiert la
prconnaissance de la clef publique du destinataire. Cette clef, habituellement certifie par
un certificat X.509 doit tre obtenue soit au pralable depuis un rpertoire public, soit peut
tre demande de la part dun agent via un message SIP spcial. Ceci induit de nouveaux
problmes de scurit puisquil faut encore scuriser ces lments additionnels.
La figure ci-dessous montre comment lattachement SDP MIME incorpor dans la requte
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
symtrique chiffre et contient galement la clef symtrique qui est chiffre avec la clef
publique du rcepteur. Dans notre exemple, la cargaison chiffre est galement signe en
utilisant la mthode multipart/signed. La signature plus le certificat X.509 optionnel du
signataire sont contenus dans la structure binaire pkcs7-signature, laquelle est attache
aprs lobjet MIME tre sign. En tant qualternative, une structure binaire PKCS#7
signedData peut tre utilise pour transporter aussi bien les donnes signer que la
signature dans lattachement.
Page 50 sur 107
05.04.2005
Ludovic Maret
Figure 31 - Attachement S/MIME chiffr et SDP MIME authentifi
Il est important de noter que lutilisation de S/MIME pose des problmes de temps de
traitement des messages SIP/SDP. Lors de chaque rception, il faut extraire le corps et
vrifier la signature de lmetteur. Cela risque donc de ralentir la signalisation SIP. De plus,
S/MIME ne protge pas contre des attaques de type man-in-the middle. Si quelquun arrive
se mettre entre les deux partenaires de signalisation SIP et que celui-ci possde un
certificat valable il peut trs bien intercepter les messages et injecter les siens pour une
quelconque attaque.
7.10.5 SIPS URI (TLS)

Limplmentation de TLS pour SIP (qui rappelons le est driv de HTTP) est plus ou moins
similaire limplmentation de SSL pour HTTP (HTTPS). Le protocole de chiffrement TLSv1
est driv de SSLv3. TLS fonctionne de manire indpendante par rapport aux applications
qui l'utilisent. De plus, il est obligatoirement au dessus de la couche TCP. Lutilisation de
TCP en lieu et place de UDP va lgrement diminuer la rapidit de la signalisation mais ceci
est presque ngligeable.
Lutilisation dURI SIPS de la forme sips:bob.bilboxy.com dans un message INVITE
ncessite que TLS soit utilis de faon gnrale comme URI SIPS de destination. Puisque
chaque hop peut ajouter une information sur la route dans lentte du messages SIP, la
protection TLS doit tre ralise sur une base hop-by-hop sur chaque segment du chemin.
Page 51 sur 107
05.04.2005
Ludovic Maret
Voici ci-dessous larchitecture de TLS :
Figure 32 - Achitecture de TLS
Couche TLS
Et ci-dessous le stack de sous-protocoles TLS :
Figure 33 - Sous protocoles TLS
La sous-couche Record a pour fonction de rceptionner les donnes des couches

suprieures et de traiter les paquets de donnes (fragmentation en blocs de taille maximum
de 214 bytes puis compression, calcul dintgrit et chiffrement des donnes puis
transmission des donnes au protocole TCP).
La sous-couche CSS (Change Cipher Spec) pour objectifs de signaler au protocole
Record toute modification des paramtres de scurit. La sous-couche Alert, quant elle,
signale les alertes (par exemple : fin de connexion, problme en cours de handshake,
lintgrit dun message est douteuse, etc.).
Page 52 sur 107
05.04.2005
Ludovic Maret
La sous-couche Handshake est utilise pour authentifier le serveur et le client. Il y a pour

cela deux types dauthentification : lauthentification mutuelle et lauthentification simple.
Lauthentification mutuelle ncessite que le client et le serveur soient authentifis. Dans le
cas de lauthentification simple, seul le serveur est authentifi. Lauthentification des entits
est base sur des certificats X.509, et l'authentification des donnes grce aux MACs
(Message Authentication Code) bas sur les fonctions de hashage MD5 (16 octets) ou SHA1 (20 octets). Cette sous-couche a donc aussi pour objectif de ngocier les algorithmes
utiliss (cipher et MAC) et de gnrer la clef symtrique de session pour le chiffrement des
donnes.
Voici ci-dessous les principaux changes lors dun handshake TLS :
Figure 34 - Handshake TLS Principaux changes
Page 53 sur 107
05.04.2005
Ludovic Maret
Et ci-dessous une ouverture de session TLS :
Figure 35 - Handshake TLS - Ouverture de session
Exemple dutilisation de TLS avec authentification simple :

Louverture de session est ici un peu diffrente de la Figure 35. En effet, la demande de
certificat de la part du serveur, lenvoi du certificat du client et la vrification de celui-ci par le
serveur ne sont pas prsents puisque lauthentification client nest pas ncessaire.
Le flux TCP suivant reprsente une connexion TLS un hte 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_3DES_EDE_CBC_SHA
compression methods
NULL
Page 54 sur 107
05.04.2005

1 2
1 3
1 4
1 5
1
1
1
1
6
7
8
9
Ludovic Maret
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
compressionMethod
NULL
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
0.4307 (0.0000) S>CV3.1(4) Handshake
ServerHelloDone
0.4594 (0.0286) C>SV3.1(134) Handshake
ClientKeyExchange
0.5498 (0.0903) C>SV3.1(1) ChangeCipherSpec
0.5498 (0.0000) C>SV3.1(48) Handshake
0.5505 (0.0007) S>CV3.1(1) ChangeCipherSpec
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 lURI 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-c87542Call-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 rponse 200 OK est envoye depuis b.example.com a.example.com sur les mmes
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
Ludovic Maret
TLS avec authentification mutuelle :

Ce type dauthentification ncessite que le client soit authentifi laide de son certificat
X.509 en plus de lauthentification du serveur. Louverture de session ressemble donc la
Figure 35. Voyons un peu plus en dtails un certificat client et la clef associe.
Le certificat dAlice est reprsent 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
Ludovic Maret
Et voici la clef dAlice :

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 rsumer, on peut dire que TLS assure une authentification (client)/serveur ainsi que
lintgrit et la confidentialit des messages SIP. Mais son utilisation nest pas gratuite. En
effet, lutilisation de TLS va induire un overhead [SA17] plus ou moins lger suivant le type
dauthentification (mutuelle ou non) et du cipher choisi. Cet overhead est ngligeable sur
une petite quantit dappels simultans mais peut devenir important pour des grands ITSP
par exemple.
Il est important de noter que ce protocole est particulirement intressant lintrieur
dentreprises ne comportant pas de NAT. En effet, tout rseau dentreprise ncessitant un
NAT pour communiquer avec lextrieur ncessite que les ports TCP utiliss sur le NAT
pour les connexions TLS restent ouverts en permanence pendant les communications. Dun
point de vue scurit et de performance, ceci pose encore problme. Il est donc peut tre
prfrable dutiliser IPSec pour des datagrammes UDP bien que celui-ci induise un
overhead trs important et donc une altration de la QoS.
7.10.6 IP Security (IPSec)

IPSec est un mcanisme gnral qui peut tre utilis pour protger les messages SIP
proprement au niveau IP. Avec SIP, chaque proxy sur le chemin doit avoir un accs en
lecture/criture sur lentte des messages SIP afin de pouvoir ajouter/retirer des valeurs
VIA. Lutilisation dIPSec ESP (Encapsulating Security Payload) ou AH (Authentification
Header) en mode transport doit donc tre utilise sur une base hop-by-hop. Les
associations de scurit IPSec ncessaires peuvent tre tablies de manire permanente
sans participation active des UAs SIP utilisant les connexions ou alors il est galement
possible de se faire la vole par les UAs et les proxy eux-mmes en troite interaction
avec le stack IPSec sous jacent.
Page 57 sur 107
05.04.2005
Ludovic Maret
Le protocole IKE (Internet Key Exchange) qui est utilis pour mettre en place les
associations de scurit IPSec supporte aussi bien lauthentification base sur PSK que
PKI. Etant donn que les adresses IP des UAs SIP sont le plus souvent dynamiques et
attribues en accord avec le droit daccs au rseau, IKE en mode principal (Main Mode) ne
fonctionnera pas avec des PSS (pre-shared secrets) et quIKE en mode agressif
(Aggressive Mode) est charg de problmes de scurit (attaques de types man-in-themiddle, dictionnaire off-line sur le PSK, etc.), lauthentification base sur une clef publique
sera une mthode prfrable. Cela veut dire que ltablissement dun tat de confiance
globale dans les certificats X.509 est encore le problme rcurent majeur.
Il subsiste nanmoins des problmes de NAT avec IPSec en ce qui concerne la modification
des enttes IP (niveau 3). Le problme vient du chiffrement de l'en-tte IP par les
participants au tunnel IPSec. Si l'adresse IP est modifie pendant le trajet du paquet, elle ne
sera pas la mme l'arrive que celle qui a t encrypte au dpart, et aprs comparaison,
le paquet sera dtruit. Cependant, en se plaant en mode ESP et en faisant du tunneling,
c'est la totalit du paquet qui est chiffre, et une nouvelle en-tte est ajoute celui-ci.
Malheureusement, cette solution n'est pas toujours possible.
Cependant, il existe une relle solution pour parer ce problme. Il s'agit d'encapsuler les
donnes dans un tunnel UDP. Ainsi, de la mme faon qu'en mode tunnel et ESP, l'en-tte
modifie par le NAT ne sera pas utilise 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
Ludovic Maret
7.11 Scuriser les flux de mdia temps rel

Les flux multimdia sont orients paquets et sont transports en utilisant le protocole RTP
(Real-Time Transport Protocol) bas sur de lUDP non fiable. Afin davoir un retour
dinformation sur la qualit du flux de paquets reu, lagent utilisateur retourne un rapport en
utilisant RTCP (Real-Time Transport Control Protocol). Puisque les connexions audios et
vidos en temps rel sont trs sensibles aux dlais de temps (time delay) et aux larges
variations de dlais (gigue ou jitter), un quelconque chiffrement de paquet et un algorithme
dauthentification ne devraient pas influencer ces paramtres de manire significative.
Authentification
Intgrit des donnes
Confidentialit
A cause de ces contraintes temps-rel, la transmission doit tre base sur UDP. Ci-dessous
(voir Tableau 5) sont lists uniquement deux mcanismes de scurit actuellement
utilisables.
Secure RTP (SRTP)
PSK
IP Security (IPSec)
PKI
Mthodes dauthentification :
PSK Pre-Shared Key
PKI Public Key Infrastructure
Utilise une clef matresse qui doit tre distribue par

un moyen externe SRTP (MIKEY ou paramtre k
dans la cargaison SDP)
Lintgration avec des applications SIP nest pas
requise mais les proxy doivent tre de confiance.
Tableau 5 - Scuriser les flux mdia temps rel (RTP)
7.11.1 Secure RTP (SRTP)

Le protocole SRTP est une extension du profil audio/vido de RTP qui fournit une
confidentialit, une authentification de messages et une protection de rptition du trafic
RTP et RTCP. Lutilisation dAES en mode stream cipher garanti une grande scurit tout en
naugmentant pas la taille de la cargaison chiffre. Le tag dauthentification ncessit pour
lintgrit des donnes ajoute dix bytes chaque paquet RTP/RTCP mais peut tre rduit
quatre bytes si un canal de communications trs lent est utilis.
Donc, aussi bien les paquets RTP que RTCP peuvent tre respectivement scuriss de
manire cryptographique par SRTP et Secure Real-Time Transport Control Protocol
(SRTCP). Voyons un peu plus en dtail les formats de messages, la gnration de clef de
session et la distribution des clefs primaires.
Page 59 sur 107
05.04.2005
Ludovic Maret
Le format de paquet SRTP :
Figure 36 - Format de paquet SRTP
Le format de messages SRTP est reprsent 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 najoutent pas de padding, la taille
de la cargaison RTP nest pas augmente 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 drives. Le MKI peut tre utilis par le rcepteur pour
retrouver la clef primaire correcte quand le besoin dun renouvellement de clefs survient.
Le numro de squence sur 16 bits dj prsent dans le paquet RTP (voir Figure 10) est
utilis de manire simultane 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
prvenir contre des replay attacks.
Le tag dauthentification est un checksum cryptographique calcul sur lentte et le corps du
paquet RTP. Son utilisation est fortement recommande tant donn quil protge les
paquets contre une quelconque modification non autorise. La longueur par dfaut du tag
est de 10 bytes mais peut tre rduit si le canal de transmission ne permet pas une grande
augmentation de la taille des paquets RTP.
Page 60 sur 107
05.04.2005
Ludovic Maret
Le format de paquet SRTCP :
Figure 37 - Format de paquet SRTCP
La Figure 37 dmontre que les paquets RTCP sont scuriss de manire similaire que les
paquets RTP. La seule diffrence rside en lutilisation obligatoire du tag dauthentification.
Sinon, il peut tre possible pour un attaquant malveillant de terminer un flux mdia RTP en
envoyant un message SIP BYE (DoS par injection de messages). Un champ supplmentaire
est lindex SRTCP qui est utilis en tant que compteur de squence afin de se prmunir
contre dventuelles 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 dfaut :
En principe, nimporte quel schma de chiffrement peut tre utilis avec SRTP. En tant
qualgorithmes par dfaut, le cipher NULL (pas de confidentialit) et AES-CTR (Advanced
Encryption Standard in Counter Mode) sont dfinis. En effet, le chiffrement par AES
standard ne permet pas de chiffrer des flux. La dfinition du chiffrement par AES-CTR est
reprsent dans la Figure 38.
Figure 38 - Chiffrement en utilisant AES-CTR
Page 61 sur 107
05.04.2005
Ludovic Maret
Cet algorithme de chiffrement joue le rle de gnrateur de clefs (sous forme de flux) qui
produit une clef pseudo-alatoire de longueur arbitraire qui va sappliquer de manire bit-bit la cargaison RTP/RTCP. Le chiffrement sera effectu laide dune 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-mme 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 gnrateur pseudo-alatoire,
AES est charg au dbut de chaque paquet RTP/RTCP avec un vecteur dinitialisation
distinct (IV). Ce vecteur est obtenu en hashant une salt_key (clef propre chaque
utilisateur) de 112 bits, le champ SSRC du flux mdia et lindex du paquet. Le chiffrement de
lIV abouti en un output de 128 bits pseudo-alatoires. Ensuite, le IV est incrment de 1
puis nouveau chiffr, cela gnre les 128 bits suivants de la clef sous forme de flux. En
continuant de compter tout en incrmentant lIV de 1, autant de blocs de clefs (sous forme
de flux) peuvent tre gnrs que ncessaire 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 prcalcule avant que la
cargaison ne soit disponible et ainsi cela minimise les dlais introduits par le chiffrement. De
plus, en utilisant un cipher de flux au lieu dun cipher de bloc, il ny a pas besoin dutiliser de
bits de padding pour augmenter la taille de la cargaison un multiple de la taille de bloc.
Ceci devra ajouter 15 bytes doverhead au paquet RTP/RTCP dans le pire des cas.
Algorithme dauthentification par dfaut :
Figure 39 - Authentification en utilisant HMAC-SHA-1
Lalgorithme dauthentification de messages SRTP par dfaut est HMAC-SHA-1. Celui-ci est
bas sur la fonction de hash sur 160 bits SHA-1. La scurit cryptographique est accomplie
en hashant un secret auth_key de 160 bits dans un checksum qui est ensuite tronqu 80
bits afin de rduire loverhead du paquet et qui a, de plus, lavantage de cacher ltat interne
complet de la fonction de hash. Dans les applications o la transmission en bande de base
est un problme, le tag dauthentification peut tre rduit 32 bits.
Drivation de la clef de session :
Les deux algorithmes de chiffrement et dauthentification requirent des clefs symtriques
secrtes de session qui doivent tre connues de tous les agents participant la session
SIP. Ceci augmente le problme logistique de la gnration de clef de session et de la
distribution. Le standard SRTP offre une solution partielle en drivant 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
Ludovic Maret
La Figure 40 reprsente comment les clefs de session sont calcules partir de la clef
primaire unique. A nouveau, le cipher de bloc AES est utilis en mode comptage pour
gnrer le keying material (clefs, certificats et vecteurs dinitialisations) ncessaire. La clef
primaire, qui peut avoir une taille de 128, 192 ou 256 bits, joue le rle de clef de chiffrement
AES. Le gnrateur pseudo-alatoire est charg avec un IV qui est lui-mme une fonction
dune valeur master_salt de 112 bits, un byte label et un numro de clef de session (session
key number). En appliquant les labels 0x00 0x05, le chiffrement, lauthentification et les
salting keys pour RTP et RTCP sont drivs depuis la mme clef primaire. Si un taux de
drivation de clef (key derivation rate) a t dfini alors chaque fois quun nombre de
paquets quivalent au taux de drivation de clef ont t envoys, un nouveau jeu de clefs
de session RTP et RTCP sont calculs. Si le taux de drivation de clef est mis 0 alors le
mme jeu de clefs sera utilis pour toute la dure de la session.
Figure 40 - Drivation des clefs de session
Distribution de la clef primaire :

Nous voici devant le problme crucial de distribution de la clef primaire aux UACs en tant
que partie de linitiation de session. Une approche possible est dutiliser MIKEY (Multimedia
Internet KEYing) pour tablir le contexte cryptographique SRTP. MIKEY est un nouveau
protocole global dchange de clef similaire IKE (Internet Key Exchange) dIPSec mais qui
a t taill sur les demandes spcifiques denvironnements multimdia. Actuellement,
MIKEY est trs peu implment et, de ce fait, nest donc pas une bonne solution tant
donn le peu de rfrences.
Il existe un autre systme plus simple pour lchange de clefs. Le paramtre k key dfinit
par SDP peut tre utilis pour transmettre la clef primaire. La Figure 41 reprsente un
message SIP INVITE classique qui convoie tous les paramtres ncessaires
ltablissement de sessions multimdia de manire incorpors dans le corps MIME
application/sdp.
Page 63 sur 107
05.04.2005
Ludovic Maret
Figure 41 - Requte SIP INVITE convoyant un corps SDP MIME
Dans cet exemple, nous voyons apparatre le paramtre k contenant la clef primaire SRTP
de 128 bits. Puisque nous arrivons lire la clef vous comprenez bien quels problmes de
scurit cela implique. Cest pourquoi il serait intressant de mettre en place des
mcanismes de chiffrement du protocole SIP (avec TLS) et du contenu SDP (avec S/MIME).
7.11.2 IP Security (IPSec)

En tant qualternative, les cargaisons temps-rel peuvent tre correctement protges au
niveau rseau par IPSec en utilisant la mme association de scurit dj ngocie pour
protger les messages SIP changs entre les UAs. Un srieux inconvnient peut tre le
grand overhead encouru par lencapsulation ESP qui peut tre dans le pire cas au alentour
de 37 bytes par paquet IPSec pour un chiffrement 3DES (8 bytes dentte ESP, 8 bytes AES
IV, 2 9 bytes de trailer ESP et 12 bytes de HMAC) et mme jusqu 53 bytes pour un
chiffrement AES (8 bytes dentte 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 gnre un
chantillon de parole de 8 bits chaque 125 s et 10 ms de parole non compresse sont
mapps en 80 chantillons contigus contenu dans un seul paquet RTP. Dans ce cas,
loverhead IPSec sera entre 30-50%.
Page 64 sur 107
05.04.2005
Ludovic Maret
7.12 RADIUS et AAA

RADIUS (Remote Authentication Dial In User Service) est un protocole et une application
client/serveur qui permet dauthentifier des utilisateurs et autoriser leurs accs tel ou tel
systme ou service. Ce systme est un lment de scurit trs intressant au niveau de
lentreprise. Cest pourquoi il serait intressant de combiner RADIUS et SIP pour de la VoIP
scurise. Malheureusement pour le moment, il nexiste pas de standard pour lutilisation de
RADIUS avec SIP.
Actuellement, cest lauthentification basique et digest qui sont utilises dans SIP.
Rcemment, le groupe de travail AAA (protocole dAuthorizatrion-Authentifiction-Accounting)
de lIETF a beaucoup travaill sur un protocole extensible dauthentification (Extensible
Authentication Protocol) dans le protocole SIP. Lavantage est que de nouveaux modles
dauthentification peuvent tre utiliss sans modifications du protocole SIP. Ceci est d au
fait que le paquet EAP, pour un modle dauthentification particulier, est convoy de
manire transparente par le protocole SIP.
Toutefois, lutilisation des authentifications basique et digest sont actuellement prfrables
pour continuer tre utilises directement dans le protocole SIP. Dici un proche avenir, leur
interoprabilit avec une authentification de type RADIUS sera une relle ncessit.
Dailleurs, SER (SIP Express Router) dans sa dernire version nous donne la possibilit
dinstaller un module dauthentification RADIUS en collaboration avec le proxy SIP. Cela
laisse croire que lutilisation de RADIUS en entreprise pour la VoIP nest quune question
de temps.
La Figure 42 dcrit un scnario gnrique o le UAC et le proxy SIP communiquent en
utilisant le protocole SIP de manire standard alors que le Proxy SIP et le serveur RADIUS
communiquent en utilisant RADIUS tout en restant transparent au UAC.
Figure 42 - Scnario d'authentification de UAC avec RADIUS
Page 65 sur 107
05.04.2005
Ludovic Maret
Lordre denvoi et de rception des messages est le suivant :

-
LUAC envoie au proxy SIP une requte SIP (1) sans lentte authorization (voir point
7.10.2 "Digest Authentification").
Ensuite le proxy demande lUAC laide dune rponse "407 Proxy Authentication
required" (2) (voir Figure 29) de renvoyer la requte SIP avec le champ authorization.
LUAC envoie alors au proxy SIP la requte SIP avec lentte authorization (3).
Puis le proxy SIP envoieau serveur RADIUS un "RADIUS Access-Request" (4).
Le serveur RADIUS rpond au proxy SIP avec une rponse "RADIUS AccessAccept/Access-Reject" (5). Si les credentials sont accepts, alors le proxy SIP reoit une
rponse "Access-Accept" et le message envoy par lUAC est considr comme
authentique.
Si le proxy SIP reoit une rponse "Access-Reject", le proxy SIP rpondra alors lUAC
avec une rponse "407 Proxy Authentication required" (6).
Dici un avenir plus ou moins proche, le systme de contrle daccs AAA (Authentication,
Authorization et Accounting) pourra lui aussi tre combin avec le service de VoIP afin de
garantir une scurit daccs au service la plus robuste que possible puisque AAA gre
galement laccounting (contrairement RADIUS).
7.13 Gestion daccs distance des serveurs de VoIP/SIP

Les accs logiques sur des ports dadministration par une personne non autorise et peu
scrupuleuse peuvent avoir comme rsultante un impact ngatif srieux sur lentiret de
lenvironnement de VoIP/SIP. Un quelconque accs distance sur les serveurs critiques
supportant lenvironnement de VoIP/SIP dans le but de les administrer ou de les grer doit
se faire de manire scurise. Il faut donc que tous ces accs se faire de manire chiffre
grce des protocoles et de mcanismes tels que VPN, SSH, SSL, etc.
7.14 Connexions VoIP/SIP WAN--WAN

Quand des connexions VoIP/SIP WAN--WAN sont tablies, la confidentialit dappel est
lse. Afin dassurer le mme 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
manires : Le chiffrement de bout-en-bout, lequel requiert que les tlphones IP aient
beaucoup de puissance de traitement et la capacit de supporter le chiffrement, ce qui nest
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 lutilisation de la technologie VPN. Les passerelles sont
normalement dsignes pour supporter de lourdes charges de traitement et sont galement
capable de fournir un chiffrement au niveau liaison. Si ceci est implment, alors les deux
mthodes seront transparentes pour la communaut dabonn.
Page 66 sur 107
05.04.2005
Ludovic Maret
7.15 Firmware et logiciels propritaires des fabricants

Nous avons vu quil existe de nombreuses vulnrabilits au sein des OS constructeurs de
tlphones IP et dans les logiciels qui sont utiliss 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 dattaques.
7.16 IDS/IPS SIP

Lutilisation dun IDS/IPS spcialis pour SIP permettre dviter la plupart des attaques de
types buffer overflow au niveau du protocole SIP sur les serveurs de VoIP. Il est bas sur
une vrification de validit des messages SIP en contrlant que tous les champs principaux
correspondent bien la RFC. De plus, un bon IDS peut dtecter des suites de messages
hors contextes (par exemple : rception dun message BYE sans quil ny ait eu de requte
INVITE). Ce mcanisme de dfense convient aussi bien pour les attaques externes que
pour des attaques internes.
7.17 NAT
Lutilisation de NATs permet la fois de parer au manque flagrant dadresses IP publiques
mais aussi bien de cacher le rseau priv au rseau publique. Cest donc un lment de
scurit trs intressant. Mais cela nest pas sans frais, en effet, lutilisation dun NAT avec
de la VoIP cre des problmes de translations dadresses contenues dans la cargaison des
messages SIP. Il est possible de contourner ce problme mais cela peut induire de
nouvelles failles de scurit. Si la mthode utilise pour parer au problme du NAT
ncessite la mise en place de systmes sur le rseau publique (Turn, STUN, etc.), il faudra
alors sassurer que ces systmes soient scuriss de manires ne pas compromettre la
scurit du rseau priv (voir annexe : Projet de semestre - Traversal Firewall/NAT).
7.18 Relais RTP

Si des relais RTP sont utiliss pour router les flux temps-rel travers le rseau dentreprise
et travers Internet, il faudra imprativement scuriser ces relais afin que personnes de non
autoris ne puisse y avoir accs sous peine de pouvoir couter toutes les communications
transitant travers les relais. La scurisation de ces relais peut se faire de la mme manire
quun serveur de VoIP critique. Il faut dj limiter laccs physique chaque relais et utiliser
des mcanismes de contrle distance scuriss.
Page 67 sur 107
05.04.2005
Ludovic Maret
7.19 Services de Voice Mail VoIP/SIP

Le service de bote vocale de messages dans un environnement de VoIP/SIP peut se faire
suivant diffrentes 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 systmes de voicemail sont galement capables de
fournir une messagerie unifie en interagissant avec les systmes de messagerie e-mail
existants.
Avec la messagerie unifie, le serveur de voicemail doit tre logiquement connect au
rseau de donne. La plateforme de voicemail doit tre configure pour tre connecte la
passerelle VoIP/SIP travers un firewall dinspection statefull. Le firewall doit tre configur
pour refuser tout le trafic entre le VLAN de voix et le rseau de donne sauf le trafic
ncessaire pour transfrer et recevoir des appels vocaux et des messages entre les
tlphones abonns, la passerelle VoIP/SIP et la plateforme de voicemail. Cette
configuration est ncessaire afin de limiter les risques dattaques de type DoS sur le rseau
de donne et/ou le rseau de VoIP/SIP. Le fait de filtrer le trafic va galement diminuer le
risque dexploits de vulnrabilits sur les OS supportant les services de tlphonie de
VoIP/SIP.
Le service de voicemail est gnralement configur pour sexcuter sur des OS ordinaires,
tels que Microsot Windows NT/2000 et Unix/Linux. La marche suivre doit tre faite de telle
manire quelle assure que ces OS sont scuriss. Les applications supportant le service de
voicemail doivent aussi tre scuriss. Par exemple, MS SQL Server peut tre utilis pour
supporter les droits daccs des abonns ou MS IIS (serveur Web de Microsoft) peut tre
utilis pour permettre aux abonns de changer leurs paramtres de voicemail en utilisant un
navigateur Internet via un protocole scuris tel que SSL (telnet et HTTP doivent tre
dsactivs).
7.20 Wireless LAN et VoIP/SIP

Au fil que la technologie de VoIP se dveloppe, la combinaison de la VoIP et de la
technologie sans fil est vite devenue un cas rel dimplmentation de grande envergure (il
existe dj des tlphones SIP sans fils, les HardPhones SIP wireless). Une relativement
nouvelle possibilit dans le domaine du wireless est dutiliser le standard 802.11 WLAN.
Cette nouvelle technologie suscite encore davantage les intrts de la VoIP tels que la
QoS, la capacit du rseau, le dimensionnement, larchitecture et surtout la scurit. Le
succs de la VoIP/SIP sur la technologie WLAN sera li la capacit que les WLANs ont de
supporter de manire adquate la QoS. Beaucoup de gouvernements sont en train dtudier
les solutions mobiles de communication qui comprennent la VoIP/SIP sur WLAN, ce qui
permet de dfinir des besoins critiques communs en ce qui concerne linteroprabilit et la
flexibilit.
Page 68 sur 107
05.04.2005
Ludovic Maret
8 LABORATOIRE : VULNRABILITS DE LA VOIP/SIP

8.1 Introduction
Le but est ici dillustrer au mieux les diffrentes vulnrabilits dun rseau VoIP/SIP
lintrieur de lentreprise. On va commencer nos tests avec une plateforme SIP non
scurise. Cela va nous permettre deffectuer des attaques de toute sorte. Par la suite, le
but est de scuriser le rseau afin de dmontrer lefficacit des mcanismes de dfenses
qui ont t mis en place.
8.2 Matriel ncessaire
1 station Windows XP qui fera office de serveur SIP proxy/registrar en un premier

temps puis en un deuxime temps, cette station fera office de UAC avec un OS
Linux Debian sur lequel sera install un SoftPhone scuris
1 station Linux Debian qui, en un premier temps, fera office dattaquant (on suppose
que lattaquant est employ dans lentreprise et quil possde un SoftPhone comme
ses collgues) pour les tests de vulnrabilits et en un deuxime temps, cette station
fera office de UAC avec un OS Linux Debian sur lequel sera install un SoftPhone
scuris
2 HardPhones IP CISCO 7960
1 station Windows XP avec SoftPhone qui fera office dattaquant (on suppose que
lattaquant est employ dans lentreprise et quil possde un SoftPhone comme ses
collgues) pour les tests de vulnrabilits
1 switch CISCO Catalyst 1912 qui servira simuler un rseau dentreprise 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 scuris.
8.3 Mise en place du rseau SIP

La premire tape dans ce laboratoire est de mettre en place le rseau de test SIP non
scuris. Afin dviter tout problme avec le reste du rseau, jai dcid de me sparer du
rseau de lcole et ainsi de travailler sur mon petit sous-rseau local. Il faudra donc
spcifier des adresses IP fixes pour tous nos lments rseaux.
Il faut donc tout dabord installer le serveur SIP proxy/registrar. Jai choisi dutiliser un logiciel
libre sexcutant sous Windows (OnDoSipServer 1.2.7.0) Ce logiciel fait office de proxy et
de registrar avec ou sans authentification (voir annexe Logiciels utiliss).
Une fois linstallation termine il faut tester si la communication peut stablir. On installe
donc deux SoftPhones sur une station Windows et Linux. Jai choisi dutiliser X-Lite qui est
un logiciel trs didactique fonctionnant soit avec Windows soit avec Linux. Aprs
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
Ludovic Maret
Ceci tant fait, il reste installer les deux tlphones IP CISCO 7960. Il faut tout dabord
mettre jour les versions du firmware SIP et ceci laide des fichiers fournis par CISCO. Il
suffit de mettre en place un serveur TFTP avec les fichiers concerns. Jai choisi dinstaller
le serveur TFTP sur la mme station que les serveurs proxy/registrar SIP.
Aprs redmarrage des tlphones, la mise jour du firmware SIP seffectue
automatiquement (il faut au pralable spcifier ladresse du serveur TFTP dans les
tlphones).
Ensuite on teste la communication entre HardPhone <-> HardPhone et HardPhone <->
SoftPhone. Tout est parfait.
Le rseau de base de laboratoire non scuris est reprsent la Figure 43 :
Figure 43 - Rseau de test SIP non-scuris
Page 70 sur 107
05.04.2005
Ludovic Maret
8.4 Quelques attaques au niveau interne du rseau

La premire des attaques qui est la fois simple et efficace mettre en place est de type
DoS. En effet, nous avons vu quil y a moyen deffectuer des DoS rien quen injectant un ou
des messages SIP dans le rseau 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 dsire annuler son appel.
Lannulation dun appel auquel le partenaire na pas encore rpondu se traduit par lenvoi
dune rponse CANCEL en SIP. Il faut donc que lon fasse passer pour lappelant en
injectant un message CANCEL destin lappel tout en respectant les champs de lentte
SIP.
Il est galement possible de faire linverse. C'est--dire que lon peut faire croire lappelant
que lappel ne dsire pas rpondre lappel.
Remarque :
Pour toutes les attaques ncessitant linjection de messages dans le rseau, il faut
ABSOLUMENT respecter la conformit de plusieurs champs. En effet, seul six des champs
contenu dans un message SIP sont contrls 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 systme dauthentification du serveur denregistrement est activ alors le

champ Authorization est galement contrl.
Il faut donc OBLIGATOIREMENT trouver un moyen de pouvoir sniffer les messages
transitant entre les UAs (dans ce cas prsent nous utilisons le hub) afin de pouvoir en
extraire les informations contenues dans les champs contrls. En effet, si ces critres ne
sont pas respects alors notre attaque sera solde par un message de rponse 481
Call/Transaction Does Not Exist venant du proxy.
Page 71 sur 107
05.04.2005
Ludovic Maret
Ceci tant compris, il nous est maintenant possible deffectuer le DoS CANCEL. Pour cela,
il suffit dinitier une communication depuis un des tlphones mais sans dcrocher lautre
bout. Cest ce moment l quil faut injecter le message CANCEL et lenvoyer au partenaire
qui na pas encore dcroch. Ceci tant fait, le partenaire appel comprend que lappelant
dsirait raccrocher alors que ce ntait pas le cas. De son ct, lappelant continue
dattendre que son partenaire dcroche (mais en vain, en fait jusqu la fin du time out
INVITE du proxy). Cest donc un DoS sur lappel et lappelant. Voici un diagramme
explicatif :
Figure 44 - DoS CANCEL
Page 72 sur 107
05.04.2005
Ludovic Maret
8.4.2 DoS BYE :

Pour ce DoS il suffit lattaquant dattendre 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 considr comme une requte le champ CSeq doit tre incrment de
1 lors de linjection du message) lattention dun des deux partenaires. Celui qui va
recevoir le message va donc couper la communication pendant que lautre croit encore que
celle-ci est tablie.
Voici un nouveau diagramme explicatif :
Figure 45 - DoS BYE
Page 73 sur 107
05.04.2005
Ludovic Maret
8.4.3 DoS Bulk REGISTER :

Le fait denvoyer une trs grande quantit de messages REGISTER avec des URI
diffrentes au serveur denregistrement cause le remplissage complet de la liste
denregistrement. Ce qui veut dire que nos deux tlphones IP, sils ne sont pas dj
enregistrs, ne pourront donc plus senregistrer. Cela provoque donc un DoS sur tous les
tlphones qui dsireraient senregistrer auprs du serveur denregistrement. Les diffrentes
requtes REGISTER seront alors refuses par le serveur.
Pour cette attaque, il nest pas ncessaire de devoir sniffer les messages si lon connat dj
lURI du proxy.
Cette attaque est reprsente la Figure 46 :
Figure 46 - DoS Bulk REGISTER
Remarque : Il est galement possible pour ladministrateur de dtecter une attaque Bulk
REGISTER en analysant la liste denregistrement (voir Figure 47).
Page 74 sur 107
05.04.2005
Ludovic Maret
Figure 47 - Extrait de liste d'enregistrement aprs attaque DoS - Bulk REGISTER
En effet, si les entres ne correspondent pas aux tlphones IP autoriss, alors lon sait
quune attaque a lieu en ce moment ou il y a peu de temps. On peut mme en tirer ladresse
IP de lattaquant avec le champ Requester qui est identique dans toutes les requtes
venant du pirate.
Page 75 sur 107
05.04.2005
Ludovic Maret
8.4.4 DoS Bulk INVITE :

Il est possible deffectuer un DoS sur un tlphone bien prcis en envoyant depuis notre
station attaquante une petite dizaine dINVITE identiques la mme URI. Le tlphone va
sonner et rpondre toute les invitation quil peut supporter. Aprs cela la communication
au niveau du tlphone sera interrompue mais pas sur le proxy. En effet, cest comme si la
communication est bien rel mais quelle nest pas visible pour le tlphone attaqu.
Comme pour le DoS Bulk REGISTER sans authentification, cette attaque ne ncessite pas
de pouvoir sniffer les messages SIP si on connat lURI du tlphone cible.
Cette attaque est reprsente la Figure 48:
Figure 48 - DoS Bulk INVITE dirig sur un tlphone
Il y a donc DoS sur 2222@192.168.0.100 alors quen fait les messages INVITE proviennent
dun gnrateur de messages SIP. Seulement le partenaire ne le sais pas et crois quon la
coup. Dans notre cas lappel a dur 30 secondes avant la coupure.
Page 76 sur 107
05.04.2005
Ludovic Maret
De plus, la session est encore rellement perue par le proxy puisque le tlphone na pas
arrt correctement la session. Voici donc ce que voit le proxy :
Figure 49 - Session inexistante
Si le tlphone 2222 veut par la suite passer un appel et que la session est encore active
sur le proxy alors celui-ci lui rpondra par un message 603 Decline. Pour un utilisateur
standard, il est impossible deffacer cette session au niveau du proxy. Elle devra faire appel
ladministrateur du rseau.
Il serait donc possible deffectuer ce DoS sur un maximum de tlphones diffrents et ainsi
de bloquer une grande partie des utilisateurs.
8.4.5 Dbordement de tampon (buffer overflow) :

Il existe des programmes permettant de scanner les vulnrabilits de types Buffer Overflow
(entre autres) dun serveur SIP. Quelques unes de ces attaques peuvent conduire une
exposition aux exploits typiques de dbordement de tampon, permettant lexcution de code
arbitraire ou la modification de systme cibl.
Vous trouverez en annexe le rsultat dun scanning de vulnrabilits de notre proxy SIP
(voir annexe Rsultat du test de vulnrabilits de type Buffer Overflow).
8.4.6 Dtournement dappel (call hijacking) :

Il est trs simple de dtourner un appel SIP. Cela peut se faire au moyen dun message 301
moved permanently ou 302 moved temporarily. En effet, ces messages sont utiliss lorsque
le call forwarding est activ de manire permanente ou temporaire. Il suffit donc de faire
croire un UAC qui tente dtablir un appel que son partenaire activ le call forwading tout
en spcifiant dans le message SIP quil faut contacter lattaquant.
Notre gnrateur de messages ne supporte que le message 302. Il suffit donc dintercepter
un message INVITE venant dun des tlphones et dinjecter notre message 302 en
spcifiant dans le champ contact quil faut transfrer lappel vers notre SoftPhone
1234@192.168.0.100.
Page 77 sur 107
05.04.2005
Ludovic Maret
Voici le diagramme des communications lorsque la call forwarding est activ sur le
tlphone appel 2222@192.168.0.100 (lURI de transfert utilise ici est
1111@192.168.0.100) et lappelant est notre SoftPhone (qui ne joue pas ici son rle
dattaquant 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 intresse (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
Ludovic Maret
Remarque :
Il subsiste nanmoins un problme avec les champs tag et branch. En effet, ces champs
sont diffrents dune session lautre. Cela ne nous permet donc pas de pouvoir injecter
notre message 302 avant que le tlphone appel sonne (messages 100 trying et 180
ringing).
Voici deux appels successifs dmontrant le changement de valeurs des champs tag et
branch dune session lautre :
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 auprs du serveur avec ou sans authentification afin de pouvoir recevoir
lappel dtourn initi depuis le tlphone 1111@192.168.0.100 au tlphone
2222@192.168.0.100.
Page 79 sur 107
05.04.2005
Ludovic Maret
Voici ci-dessous le diagramme en flche des communications avec lattaque de

dtournement dappel :
Figure 51 Dtournement dappel l'aide d'un message 302 moved temporarily
Rien ne nous empche alors de nous faire passer pour quelquun dautre au tlphone
puisque lappelant croit avoir atteint la personne qui dsirait appeler. De plus, sur laffichage
du tlphone le nom dutilisateur est celui que lappelant dsirait appeler. Il est de coutume
en entreprise que lorsque quelquun est absent, il transfert tous les appels vers les
secrtaires. En nous faisant passer pour un secrtaire nous pouvons srement en tirer des
informations utiles.
Remarque :
Il faut absolument que la personne appele ne rponde pas AVANT que lon ait inject le
message 302 si lon ne veut pas que notre tentative de dtournement soit voue lchec.
Le temps que cela ma pris est de quelques secondes, cela peut paratre long mais en
gnral le tlphone sonne bien quelques secondes avant que lon dcroche et cela surtout
si lon est occup. Si la personne rpond APRES linjection de notre message, alors elle se
croira en communication avec la personne appelante alors que ce nest plus le cas. Il y donc
DoS sur la personne appele.
Page 80 sur 107
05.04.2005
Ludovic Maret
8.4.7 Ecoute indiscrte dautres communications (eavesdropping) :

Lcoute non autorise de communication est possible avec SIP. En effet, le flux RTP nest
pas chiffr. Il suffit donc de se dbrouiller pour capturer le flux RTP puis de le convertir en
un fichier audio.
Remarque : Lcoute de flux RTP est trop complique pour tre effectue en temps rel. Il
va falloir enregistrer ce flux, puis le convertir et couter la communication en diffr.
En ce qui concerne les messages instantans SIP, le contenu du message instantan se
trouve dans le payload du message SIP, et donc transite sur le rseau en clair.
Pour pouvoir effectuer une coute non autorise, il faut donc considrer les deux cas
suivants :
1. Nous nous trouvons physiquement sur le mme hub que le tlphone IP cible ou sur
le mme hub que le proxy SIP. Dans ce cas il est vraiment trs simple dcouter la
communication en diffr ou de lire les messages instantans. Voici la Figure 52
un message instantan captur sur notre hub :
Figure 52 - Message instantan transitant en clair sur le rseau
Et voici un flux RTP captur galement sur le hub :

No. Time Source
Destination
Prot
15 2.68 192.168.0.101 192.168.0.102
SSRC=1605747604, Seq=52845, Time=8422592
16 2.70 192.168.0.101 192.168.0.102
SSRC=1605747604, Seq=52846, Time=8422752
18 2.72 192.168.0.101 192.168.0.102
SSRC=1605747604, Seq=52847, Time=8422912
20 2.74 192.168.0.101 192.168.0.102
SSRC=1605747604, Seq=52848, Time=8423072
Info
RTP
Payload
type=ITU-T
G.711
PCMU,
RTP
Payload
type=ITU-T
G.711
PCMU,
RTP
Payload
type=ITU-T
G.711
PCMU,
RTP
Payload
type=ITU-T
G.711
PCMU,
Remarque :
Attention ! Actuellement avec cette version dEthereal (0.10.7) seul le codec G.711
est utilisable. Dautres programmes effectuant la mme conversion de flux ne
fonctionnent quavec ce codec. Dici quelques temps la plupart des codecs seront
grs.
Page 81 sur 107
05.04.2005
Ludovic Maret
2. Nous sommes connects un switch. Il va donc falloir trouver un moyen pour

capturer le flux RTP. Il existe une technique dattaque de switch qui consiste en
lenvoi de trames avec chacune une adresse MAC source diffrente (CAM attack).
La table CAM (paires adresse MAC-port) du switch arrivera vite saturation. De
cette manire le switch devrait avoir un comportement similaire celui dun hub.
Remarque :
Cela fonctionne uniquement si lattaquant se connecte sur le switch avant les
tlphones IP dont on veut pouvoir couter les conversations. Si ce nest pas le cas
alors les adresses MAC des tlphones associes aux diffrents ports du switch
seront conserves dans la CAM. Il faut alors trouver un moyen de vider la CAM (ce
qui nest pas du tout trivial daccder au switch suivant le type de switch et les
couches OSI implmente MAC, IP). Le mieux tant de dconnecter ou de
redmarrer les tlphones (voir point 5.2.1 "Vulnrabilits des systmes
dexploitation") et de remplir la CAM.
Il suffit donc de connatre ladresse MAC du switch pour pouvoir lattaquer. Voici un
extrait de la CAM aprs remplissage :
Address
Dest Interface
Type
Source
Interface
List
---------------------------------------------------------------------------0008.7447.187A
Ethernet 0/4
Dynamic
All
00C0.4F21.DA8C
Ethernet 0/5
Dynamic
All
AAAA.AA00.0000
Ethernet 0/4
Dynamic
All
AAAA.AA00.0001
Ethernet 0/4
Dynamic
All
AAAA.AA00.0002
Ethernet 0/4
Dynamic
All
AAAA.AA00.0003
Ethernet 0/4
Dynamic
All
AAAA.AA00.0004
Ethernet 0/4
Dynamic
All
AAAA.AA00.0005
Ethernet 0/4
Dynamic
All
AAAA.AA00.0006
Ethernet 0/4
Dynamic
All
AAAA.AA00.0007
Ethernet 0/4
Dynamic
All
Ladresse MAC 00:08:74:47:18:7A est celle de lattaquant et la 00:C0:4F:21:DA:8C

est celle du registrar/proxy.
La CAM est donc inonde au maximum (cette limite dpend 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 rcuprer la
conversation, se rfrer au point prcdent. La seule limitation est que ne pouvons
couter que le trafic transitant par les UA connects au switch.
Remarque :
Il est possible de se faire passer pour le proxy laide dARP spoofing (en spoofant
ladresse du vrai proxy et ceci uniquement si nous nous trouvons sur le mme sousrseau) ou de messages 30x. Nous devons alors modifier lentte Via pour ajouter
ladresse 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 dcouvrir 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
instantans) mais aucun paquet RTP. En effet, le flux RTP nest tablit quentre les
deux partenaires en communication (voir Figure 2).
Page 82 sur 107
05.04.2005
Ludovic Maret
Si nous voulons effectuer de lARP spoofing au moment ou le flux RTP est transmis
afin de pouvoir rcuprer le flux tout en le routant aux bons destinataires il y a un
nouveau problme : en effet, lors denvoi de paquets RTP les tlphones nont plus
besoin deffectuer des ARP request et cela nous rend impossible le dtournement
par ARP spoofing. Ceci est apparemment un problme spcifique aux tlphones
CISCO Catalyst 7960.
Il est galement noter que cette technique dattaque de switch est valable pour
toute les attaques ncessitant la capture de messages SIP sur le rseau (DoS
CANCEL/BYE, Call Hijacking, etc.).
8.4.8 SPAM - INVITE :

Nous avons vu quil est possible deffectuer du SPAM dINVITE. En fait, il est trs facile de
faire sonner plusieurs tlphones en mme temps avec SIP. Il sagit ici pour lattaquant de
connatre les URI de tous les tlphones concerns ainsi que ladresse du serveur
proxy/registrar. Ensuite il suffit de crer un message par URI et de les envoyer en mme
temps. Tous les tlphones sonneront donc en mme temps. Comme pour les attaques de
type DoS - Bulk REGISTER sans authentification et DoS - Bulk INVITE, cette attaque ne
ncessite pas forcment de pouvoir sniffer les messages SIP si lattaquant connat dj les
URI et lIP du/des serveurs. Cette attaque est reprsente la Figure 53 :
Figure 53 - SPAM d'INVITE
Remarque :
Si le nombre de tlphone que vous voulons spamer est suprieur la limite de
communications simultanes admise par le proxy/redirect (environ 25 dans notre cas) alors
notre attaque se soldera, en plus du spam lui-mme, par un DoS du proxy/redirect (et donc
du rseau SIP complet sous contrle de ce serveur) d un nouveau type dattaque Bulk
INVITE sur le serveur.
Page 83 sur 107
05.04.2005
Ludovic Maret
8.5 Prvention : mcanismes de scurisation et rflexes utiles

Dans un premier temps nous allons continuer dutiliser notre proxy OnDo SIP Server et nos
HardPhones SIP. OnDoSip Server permet de dutiliser lauthentification digest et galement
de crer des rgles de filtrages dappel. Les HardPhones CISCO 7960 supportent
galement lauthentification digest.
La Figure 54 reprsente notre nouveau rseau de test :
Figure 54 - Rseau de test SIP scuris Digest Authentification, Filtrage dappel et IDS/IPS
VoIP/SIP
Nous pouvons voir que le mcanisme Digest Authentification est utilis au niveau des
UACs. Il faut galement viter au maximum les hubs. Nous allons voir juste aprs quels sont
les diffrentes utilits de scurit des diffrents mcanismes de scurisation.
Page 84 sur 107
05.04.2005
Ludovic Maret
8.5.1 Switch :
Comme vu prcdemment, les attaques de types DoS CANCEL/BYE et Call Hijacking par
injection de message 302 oblige lattaquant de respecter les champs qui sont contrls ainsi
que de savoir quel moment il doit injecter ses messages malicieux. Il doit donc, pour cela,
pouvoir capturer ces informations. Lattaquant doit donc se trouver sur le mme hub que les
diffrents partenaires viss par lattaque ou ventuellement avec le proxy utilis par ceux-ci.
Il suffit donc de nutiliser que des switchs afin de rendre ces donnes inatteignables
lattaquant. Si celui-ci dcide dinjecter des messages SIP par la force brute en testant
toutes les possibilits de valeurs de champs afin que lun de ses messages correspondent
bien la transaction concerne il est trs peu probable quil y parvienne dans les temps.
Dans le cas dun DoS CANCEL, lattaquant na comme temps que celui que met le
partenaire appel dcrocher le combin. Dans le cas dun DoS BYE, le temps imparti
lattaquant est la dure de communication entre les deux partenaires.
Mais attention ! Il est cependant possible que lattaquant se procure un petit hub personnel
quil se chargera de placer sur le rseau de manire judicieuse, comme par exemple entre
les tlphones et le proxy/regitrar ou encore entre les tlphones et un switch (bien
quencore faut-il quil aie physiquement accs ces emplacements stratgiques sur le
rseau). Lattaque de la CAM du switch est galement possible mais difficile (voir point 8.4.7
" Ecoute indiscrte dautres communications (eavesdropping)").
8.5.2 VLANs :
La configuration de deux VLANs spars (un VLAN donne et un VLAN VoIP) permet la
fois de cacher le rseau de VoIP aux utilisateurs du rseau de donne uniquement mais
cela vite galement la propagation de collisions en dehors dun VLAN.
Nous gardons la plateforme de test scurise (voir Figure 54). La station Linux sera utilise
en tant que SoftPhone et la station Windows XP en tant quutilisateur standard sans
tlphone IP. Il faut configurer les VLANs comme suit :
1. Un VLAN VoIP sur lequel sera connects les deux HardPhones CISCO 7960, le
serveur SIP proxy/registrar et le SoftPhone Linux Debian.
2. Un VLAN donne sur lequel sera connects la station Windows XP et le SoftPhone
Linux Debian.
En effet, le SoftPhone doit faire partie des deux VLANs pour avoir accs aux services offerts
par le rseau de donne (Internet, DHCP, DNS, etc.) ainsi quau VLAN de VoIP. Il faut donc
crer un trunk regroupant les deux VLANs pour connecter le SoftPhone.
Page 85 sur 107
05.04.2005
Ludovic Maret
Voici la configuration des VLANs sur le switch CISCO Catalyst 1912 :

Dans le menu principal il faut choisir loption [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 pose 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 dajout de VLAN Ethernet :
Catalyst 1900 - Add Ethernet VLAN
----------------------- Settings
[N] VLAN Number
[V] VLAN Name
[I] 802.10 SAID
[M] MTU Size
[L] Translational Bridge 1
[J] Translational Bridge 2
[T] VLAN State
[S] Save and Exit
--------------------------------------2
VLAN0002
100002
1500
0
0
Enabled
[X] Cancel and Exit
Page 86 sur 107
05.04.2005
Ludovic Maret
Le numro par dfaut du nouveau VLAN est 2. Nous allons changer le nom du VLAN pour
lappeler VoIP. Il faut donc slectionner [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 mme
marche suivre est utilise 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 slectionner 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
A
B
1
1
1
Static
Static
Static
[M] Membership type

[R] Reconfirm dynamic membership
[V] VLAN assignment

[X] Exit to previous menu
Par dfaut, tous les ports sont associs au VLAN 1 de manire statique. Le VLAN 1 est un
VLAN par dfaut. Nous avons cr le VLAN 2 VoIP et le VLAN 3 Donnee. Il faut donc
maintenant associer les ports correspondants laide 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
Ludovic Maret
Aprs slection des ports 1-3, il faut slectionner le VLAN auquel nous dsirons associer
ces ports :
Identify VLAN 0 - VLAN 1005:
Select [0-1005] 2
La configuration du port 4 se fait de manire analogue. Voici ce que nous obtenons aprs
configuration complte 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
A
B
1
1
1
Static
Static
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 loption [T] Trunk
Configuration. Il nous faut maintenant choisir le trunk utiliser. Ce choix nest 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)
[D] Delete Allowed VLAN(s)
[N] Next Trunk
[E] Add Pruning Eligible VLAN(s)

[C] Delete Pruning Eligible VLAN(s)
[P] Previous Trunk
[X] Exit to Vlan Menu
Page 88 sur 107
05.04.2005
Ludovic Maret
Il faut ensuite utiliser loption [A] Add Allowed VLAN(s) pour ajouter des VLAN au trunk A. Il
ne reste plus qu choisir dajouter 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 diffrents lments.
Ce mcanisme est vraiment trs intressant. Dune part, son utilisation est "gratuite" partir
du moment ou le switch est dj prsent sur le rseau et quil permet dutiliser des VLANs.
Dautre part, les domaines de collisions sont spars et ainsi le rseau fonctionne plus
efficacement dans chaque VLAN. Mais surtout, ce mcanisme permet dviter toutes les
attaques de VoIP/SIP visant directement un lment de VoIP (DoS par injection de
messages, Buffer Overflow, SPAM, dtournement dappel, etc.) et venant de personnes qui
ne font pas partie du VLAN de VoIP. Toutes les attaques de VoIP qui seffectuent de
manire indirecte (c'est--dire en passant par un lment rseau qui nest pas forcment un
lments de VoIP), telles que lpuisement de ressource DHCP et les attaques TFTP par
exemple, ne peuvent pas tre vites sans devoir isoler ces lments dans le VLAN de
VoIP uniquement. Mais attention, cela nest pas toujours possible puisque ces lments
sont souvent utiliss par des lments du rseau de donne (en particulier DHCP).
8.5.3 Digest Authentification :

Une faon de se prmunir contre les attaques de types DoS - Bulk REGISTER/INVITE est
de configurer sur le serveur denregistrement que celui-ci doit utiliser le systme
denregistrement authentifi avec une liste des tlphones autoriss. Il faut donc spcifier
dans le serveur les diffrentes associations Username et Password authentification (voir
Figure 55).
Le systme dauthentification implment par notre proxy est celui dcrit dans la nouvelle
RFC 3261 SIPv2. Avec lancienne RFC le systme est bas sur une authentification
basique. C'est--dire que le Username et le Password transitaient en clair dans les
messages SIP. Le nouveau systme est, lui, bas sur une authentification digest, donc le
Username et le Password font partie intgrante du digest et donc indchiffrable un
attaquant qui cherche capturer des messages SIP.
Page 89 sur 107
05.04.2005
Ludovic Maret
Figure 55 - Enregistrement avec authentification
Avec ce systme de contrle, aucun utilisateur non autoris ne peut senregistrer dans le
serveur. Mme si lattaquant possde un tlphone autoris dans lentreprise il ne pourra
pas effectuer de nouvel enregistrement avec dautres URI que celui de son tlphone (les
enregistrement de mme URI nutilise quune place dans la liste). Il faudra bien sr que le
serveur denregistrement permette ce type dauthentification.
Et voici ci-dessous le diagramme en flche aprs avoir mis en place le systme
dauthentification :
Figure 56 - Systme d'authentification du registrar
Page 90 sur 107
05.04.2005

Voici un exemple de message requte REGISTER
2222@192.168.0.100 avec authentification correcte :
mis
Ludovic Maret
par
le
tlphone
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
Lorsquun tlphone tente de senregistrer sans spcifier le champ Authorization ou avec

une valeur incorrecte, le proxy va rpondre par un message 401 Unauthorized contenant
un nouveau champs nonce spcifiant que lenregistrement a chou par faute de mauvaise
authentification.
Nous pouvons remarquer quun agent SIP lors dun enregistrement agis par dfaut comme
suit (ceci sappelle le challenge dauthentification, voir point 7.10.2 "http Digest
Authentification") :
1. Emission au registrar dune requte REGISTER sans le champ Authorization.
a. Si lauthentification nest pas gre, alors lUA SIP est enregistr (200 OK).
b. Si il y a authentification, alors lUA va mettre une nouvelle requte
REGISTER avec le champ Authentification.
Si lUA est dans la liste dauthentification (voir Figure 55) et que son
User et Password sont corrects alors lUA est enregistr (200 OK).
Si lUA ne fait pas partie de la liste ou que les informations sur le
User et Password sont incorrectes alors lenregistrement est
refus (401 UNAUTHORIZED).
Il est galement noter que le systme dauthentification ncessite que les requtes INVITE
et CANCEL soient authentifies. Cela veut dire que cette scurit supplmentaire permet
par exemple dviter le SPAM dINVITE, le DoS CANCEL et le DoS Bulk INVITE venant de
personnes non authentifies. Par contre si ces personnes possdent un tlphone IP avec
autorisation rien ne les empche de gnrer les messages adquats (voir SPAM INVITE et
DoS CANCEL) en se faisant passer pour le tlphone en question, cest--dire avec tous les
champs contrls y compris le champ Proxy-Authorization des messages INVITE et
CANCEL. Mais cela ne permet pas denregistrer des tlphones supplmentaires ne faisant
pas partie de la liste denregistrement et de ce fait lattaque Bulk REGISTER est impossible !
Ce systme dauthentification rend galement plus difficile les attaques de types SPAM
dINVITE. En effet, ltonnante facilit de ce genre dattaque en rend la dfense dautant
plus ardue. Cependant, comme vu lors de leavesdropping, le systme dauthentification
oblige lattaquant faire partie de la liste autorise avec son User et Password. De ce fait,
nimporte qui ne peut pas samuser faire du SPAM dINVITE sans tre autoris au niveau
du serveur denregistrement.
Page 91 sur 107
05.04.2005
Ludovic Maret
Cependant, si lattaquant a possibilit de capturer une requte REGISTER et une requte

INVITE (et ventuellement un requte CANCEL) mise par un tlphone autoris (que ce
soit le sien ou un autre sur le mme hub ou encore sur le mme hub que le registrar ou le
proxy et quil utilise un gnrateur de messages SIP pour sauthentifier alors lattaquant se
fera passer pour lui et pourra sans autre effectuer du SPAM dINVITE et mme envoyer des
messages instantans.
Remarque : Cela fonctionne que le tlphone authentifi copi soit enregistr ou non mais
curieusement le registrar ne rponds pas par un 200 OK alors que lenregistrement est
rellement effectu (voir Figure 57).
Figure 57 - SPAM d'INVITE en contournant l'authentification (spoofing)
Il est donc trs difficile de pouvoir effectuer du SPAM dINVITE avec le systme
dauthentification mais cela nest pas impossible. En effet, une fois la requte INVITE
autorise capture, lattaquant peut alors la modifier pour lenvoyer un ou plusieurs autre
URI sur le rseau.
Le systme dauthentification agit donc comme une WhiteList avec les avantages et les
inconvnients que cela entrane. Pour chaque nouveau partenaire susceptible de pouvoir
appeler dans lentreprise 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 quelquun faisant partie de cette liste.
Remarque : Le mme principe est utilisable pour effectuer un DoS BYE/CANCEL ou du
eavesdropping/call hijacking avec Digest Authentification.
Page 92 sur 107
05.04.2005
Ludovic Maret
8.5.4 Filtrage des appels :

Si le proxy le permet, il est possible dtablir des rgles dappels un peu la manire dun
firewall. Ces rgles permettent de dfinir des filtres de cause effet sur la base de
beaucoup dinformations. Notre serveur permet dcrire les rgles en utilisant les lments
suivants.
La colonne "Matching Patterns" spcifie suivant quelle condition il faut agir :
Nom de la variable de condition
Dfinition
$addr
Adresse IP de lappelant.
Ex : $addr=192\.168\.1\.100
$date
Date laquelle la requte dappel a t reue.

ex $date=2003/12/01
$localhost
Si oui ou non lappel est initi depuis localhost (OSS).

ex $localhost=true
$outbound
Si oui ou non lappel est en dehors du rseau local (o rside

OSS).
ex $outbound=false
$port
N de port de lappelant.
ex: $port=5060
$registered
Si oui ou non lappel est enregistr.

ex $registered=false
$request
Requte.
ex$request=INVITE sip:11@192.168.1.200:5060 SIP/2.0
$sid
Session ID (numro de session utilise pour la maintenance

interne).
ex $sid=23
$time
Heure laquelle la requte dappel a t reue.

ex $time=15:02:30
Tableau 6 - Matching Patterns
Page 93 sur 107
05.04.2005
Ludovic Maret
La colonne "Deploy Patterns" spcifie quel traitement effectuer si une condition de la

colonne "Matching Patterns" intervient :
Nom de la variable de traitement
$action
Dfinition
Code de rponse qui va tre envoy lappelant.
Ex : $action=404
$continue
Si $continue=true, les procdures de contrle des matching

patterns (conditions) ne seront pas finies aprs que les deploy
patterns (traitements) adquats ne soient excuts.
Ex : $continue=true
$ifdst
Interface rseau (adresse IP) utilise pour envoyer les

paquets lappel.
Ex : $ifdst=192.168.1.100
$ifsrc
Interface rseau (adresse IP) utilise pour envoyer les

paquets lappelant.
Ex : $ifdst=192.168.2.1
$nat
Si oui ou non la fonction traversal NAT est utilise.

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
Spcifie ladresse de lappel.

Ex : $target=192.168.0.2
Tableau 7 - Deploy Patterns
Voici les diffrents champs dentte les plus frquents sur lesquels on peut crer des rgles
de filtrage dappel :
Champs dentte
TO
FROM
Max-Forwards
User-Agent
Dfinition
Le SIP-URI de lappel ou le serveur SIP de routing
Le SIP-URI de lappelant
Nombre maximum de sauts quune requte SIP peut passer jusqu
destination
Nom du user agent de lappelant
Tableau 8 - Champs d'entte SIP
Et voici les mthodes principales de requtes SIP :

Mthode
REGISTER
INVITE
ACK
CANCEL
INFO
OPTIONS
Dfinition
Enregistre linformation contact du user agent
Invitation participer la session. Cela requiert une session ouverte
Quittancement une rponse quune requte INVITE a t reue
Annule la transaction en cours dans la session
Donne des informations de session
Interrogation des capacits du serveur
Tableau 9 - Mthodes principales SIP
Page 94 sur 107
05.04.2005
Ludovic Maret
Imaginons que quelquun de non reconnu dont on connat ladresse IP dsire utiliser le
service de VoIP. Il suffirait alors dtablir une rgle de filtrage qui interdit lenvoi de requtes
INVITE par la station 192.168.0.1 (la station en question) en y rpondant par un messages
603 DECLINE. Cette rgle est reprsente la Figure 58.
Figure 58 - Rgle de filtrage d'appel
Aprs sauvegarde de la rgle et redmarrage du serveur, nous allons tenter dappeler le

tlphone 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
Ludovic Maret
8.5.5 IDS/IPS :
Lutilit dun IDS/IPS SIP, plac devant un serveur SIP, est le contrle de la validit des
messages SIP destination du serveur en question. LIDS pourra alors dtecter et emttre
une alerte lorsquun message SIP ne respecte pas la RFC 3261 et donc les champs
spcifiques contrls au niveau des UAs SIP tel que nous lavons vu dans les attaques de
types injection de messages SIP. LIPS quant lui pourra jeter ces messages corrompus.
Ceux-ci sont principalement utiliss pour des attaques de types Buffer Overflow ou DoS.
Il est galement possible pour lIDS/IPS de dtecter lenvoi de plusieurs messages INVITE
sur le mme tlphone ou encore de pouvoir analyser des suites de messages SIP afin
dviter 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 requte INVITE sans lentte To adresse 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 requte ne parvient pas jusquau proxy car lIPS la dtect et voici le log quil a
gnr :
[**] [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 lentte To est bien prsente 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 na jamais reu ce message. Examinons plus en dtail les logs gnrs par
lIDS/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
Ludovic Maret
8.5.6 SRTP :
Le chiffrement du flux audio RTP avec le protocole Secure RTP (SRTP) est le meilleur
moyen de contrer les attaques dcoutes indiscrtes de communication (eavesdropping). En
effet, mme si lattaquant parvient capturer le flux audio, il lui faudra galement connatre
la clef de chiffrement pour dcoder les paquets SRTP.
Les HardPhones CISCO 7960 ne supportent actuellement pas SRTP. Il faut donc utiliser
des SoftPhones qui implmentent 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
dattaquant. Les serveurs SIP seront un proxy/registrar SER 0.8.14 (Sip Express Router).
La Figure 60 reprsente notre nouvelle plateforme de test avec les SoftPhones Minisip :
Figure 60 - Rseau de test SIP scuris SRTP, Digest Authentification, IDS/IPS VoIP/SIP
Remarque :
Il est galement possible de mettre en place des mcanismes supplmentaires tels que
lencapsulation TLS, S/MIME de SDP, IPSec entre les UAs, la mise en place dun serveur
dauthentification forte Radius, lutilisation dun NAT et dun firewall VoIP/SIP mais ceux-ci
ne seront pas abord lors de ce laboratoire.
Pour que les deux partenaires puissent communiquer, il faut quils supportent SRTP et
possdent soit une clef PSK (voir Figure 61) identique soit une paire certificat/clef DiffieHellman valide (voir Figure 62Figure 63) pour lauthentification.
Page 97 sur 107
05.04.2005
Ludovic Maret
En effet, Minisip implmente un stack SRTP et MIKEY (Multimedia Internet KEYing

RFC3830) comme solution de gestion de clef afin de pouvoir les changer et associer des
paramtres de scurit. Il met galement disposition toutes les clefs et les certificats que
ncessite 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
Page 98 sur 107
Figure 63 - Configuration des certificats
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 associe :

-----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
VoIP/SIP & Security
Ludovic Maret
Et voici une communication SIP avec SRTP capture 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
15 36.898 192.168.0.1
192.168.0.2
RTCP
Unknown packet type
16 36.929 192.168.0.2
192.168.0.1
RTCP
Unknown packet type
17 36.929 192.168.0.2
192.168.0.1
RTCP
Unknown packet type
18 36.931 192.168.0.1
192.168.0.2
RTCP
Unknown packet type
19 36.932 192.168.0.2
192.168.0.1
RTCP
Unknown packet type
20 36.968 192.168.0.2
192.168.0.1
RTCP
Unknown packet type
21 36.981 192.168.0.2
192.168.0.1
RTCP
Unknown packet type
Actuellement lanalyseur rseau Ethereal (version 0.10.7) ne reconnat pas le protocole

SRTP. Cest pourquoi il dtecte que ce sont des paquets RTCP dont le format est inconnu.
Voyons maintenant plus en dtail 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
VoIP/SIP & Security
Ludovic Maret
Cest le dernier champ a (zero or more session attribute lines) qui dfinit le type de
gestionnaire de clef (key-mgmt).
Remarque : SRTP protge donc contre lcoute indiscrte mais pas contre les attaques
utilisant des messages SIP sans corps SDP. Il est donc toujours possible de dtourner des
appels (si le tlphone de lattaquant supporte SRTP seulement) et deffectuer des DoS
BYE/CANCEL par exemple.
Il est intressant de regarder les logs gnrs 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 ct 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 nest pas valide, le SoftPhone ne dmarre pas.

Et voici ci-dessous ce qui se passe si la clef PSK ne correspond pas celle du partenaire
appel :
Figure 64 - Rponse 606 NOT ACCEPTABLE pour une clef PSK non valide
Page 101 sur 107
05.04.2005
VoIP/SIP & Security
Ludovic Maret
Voila ce qui apparat dans le SoftPhone :
Figure 65 - Clef PSK diffrente
Voici ce qui se passe si lon essaie dappeler un tlphone supportant SRTP avec un
tlphone RTP :
Figure 66 Appel entrant non scuris sur un tlphone SRTP
Nous avons donc le choix de rpondre cet appel en mode non protg RTP ou alors de
rejeter lappel. Ce choix doit faire partie des politiques de scurit de lentreprise. Il est
fortement conseill de ne pas accepter dappels non scuriss.
8.5.7 TLS :
Le chiffrement TLS (SSLv3) permet de scuriser la signalisation au niveau transport (TCP).
Les SoftPhones Minisip supportent TLS mais malheureusement je nai pas russi 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.). Dici quelques mois, lutilisation de TLS au niveau des
serveurs SIP sera chose aise et peu chre, notamment grce lopen source.
Page 102 sur 107
05.04.2005
VoIP/SIP & Security
Ludovic Maret
9 CONCLUSION
La VoIP est une technologie rcente mais surtout trs attractive. En effet, cet outil de
communication est de plus en plus utilis par les secteurs priv et public. Afin damliorer les
services de tlcommunications, telles que les communications unifies, on prvoit une
utilisation accrue de la VoIP en se fondant sur les avantages perus : le cot, lefficacit, la
rentabilit et la capacit dvolution de la VoIP. Toutefois, comme dans toutes les nouvelles
technologies, les questions concernant la scurit sont souvent souleves seulement quune
fois que son utilisation est trs rpandue. En outre, le systme tlphonique est une cible
trs intressante pour des personnes sans scrupules dsireuses de profiter dun tel service
gratuitement ou simplement pour en gner son utilisation.
La tlphonie en entreprise est un vritable outil de travail. Les communications internes
sont tout aussi importantes que les communications externes. Si le service de tlphonie de
lentreprise est attaqu, cest tout le systme de communication bas sur la tlphonie de
lentreprise qui est attaqu. Imaginons que le service de VoIP devienne inaccessible en
interne et en externe pendant une journe. Cela aura de nombreux effets ngatifs sur
lentreprise, notamment la perte de clients, une altration de limage de marque de
lentreprise devenue inaccessible depuis lextrieur, le vol dinformations sensibles
concernant lentreprise ou encore un retard supplmentaire lors de la transmission
dinformations essentielles de lentreprise entre les secteurs de travail qui utilisent le service
tlphonique comme moyen primaire de communication.
Actuellement, les mcanismes de scurisation dun rseau IP sont trs connus et efficace.
Mais cela ne sest pas fait du jour au lendemain. Cest lanciennet du protocole IP et son
immense utilisation qui en a fait une cible idale dattaque. Avec le temps, des outils de
dfense de plus en plus performants ont t mis en place partout dans le monde. Cest
pourquoi il faut toujours avoir lesprit que la scurisation de rseaux de VoIP/SIP est, de
par son implmentation toute rcente, de loin pas parfaite. De plus, beaucoup de
vulnrabilits ne sont pas encore connues. Cest pourquoi, il faut apporter une attention toute
particulire la scurisation du service de VoIP/SIP.
La plus grande erreur que commettent gnralement les entreprises est de dployer le
service de VoIP le plus vite possible afin de pouvoir lamortir et en profiter immdiatement.
Ce principe est dfendable du point de vue de lefficacit et de la rentabilit de lentreprise.
Cependant, les cots engendrs par la mise en place du service dans lentreprise sont
ngligeables par rapport ce que les attaques pourraient coter. Il faut donc y rflchir
deux fois avant de mettre le systme en fonction. En effet, le meilleur moyen de se prmunir
contre les attaques est de dployer le systme de VoIP/SIP de manire indpendante du
rseau de lentreprise et instaurer les mcanismes de scurisation que nous avons vu dans
les prescriptions de scurisation de la VoIP/SIP. Une fois cela fait, le service peut tre
tendu au niveau de lentreprise en premier lieu, puis au niveau international en dernier lieu.
Ensuite, il faut que les administrateurs du rseau soient perptuellement lcoute des
vulnrabilits de la VoIP/SIP afin de pouvoir y ajouter le mcanisme de scurisation adapt.
La recette miracle de la scurisation dun rseau de VoIP/SIP serait compose de trois
lments combins : lapplication de procdures de base relative la scurit du rseau IP,
la mise en place des meilleures pratiques de scurisation de la VoIP dans ce document et
une perptuelle mise niveau de la scurit du rseau global IP/VoIP.
Page 103 sur 107
05.04.2005
VoIP/SIP & Security
Ludovic Maret
10 RFRENCES
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
Scurisation 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-withcover.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-finalreport.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
VoIP/SIP & Security
Ludovic Maret
11 SYMBOLES ET ABRVIATIONS
[SA01] SIP :
Session Initiation Protocol. Protocole de signalisation multimdia (audio, vido,

autres)
[SA02] RTP :
Real-Time Transport Protocol. Protocole utilis pour convoyer de linformation

temps rel (audio, vido, autres)
[SA03] H.323 :
Protocole de signalisation utilis pour la communication audio/vido
[SA04] ISDN :
Integrated Services Digital Network. Modle de tlphonie numrique qui permet

des utilisateurs de se connecter Internet sur une ligne tlphonique standard
des vitesses suprieures 56K
[SA05] SS7 :
Signalling System 7. Protocole de signalisation utilis dans les rseaux

tlphoniques publics commuts (PSTN)
[SA06] PSTN :
Public Switched Telephony Network.
[SA07] codec :
Diminutif pour compressor/decompressor. Technologie pour compresser et

dcompresser des donnes (audio, vido, autres
[SA08] QoS :
Quality of Service. Terme utilis pour mesurer la qualit de service dun produit
ou dun 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 rseaux circuits commuts et les rseaux de paquets.
MGCP spare la signalisation et le contrle dappel pour la passerelle de media.
[SA10] SDP :
Session Description Protocol. SDP est utilis pour dcrire les paramtres de flux
utiliss dans les sessions multimdia
[SA11] RTCP :
RTP Control Protocol. RTCP fournit un feedback sur la qualit de la distribution

des donnes convoyes par RTP
[SA12] DTMF :
Dual Tone Multi-Frequency. Tonalit des touches lors dappel tlphonique
[SA13] PBX :
Private Branch Exchange. Rseau tlphonique commute priv, souvent utilis

en enterprise pour fournir une connectique tlphonique interne et un accs au
PSTN
[SA14] IP-PBX :
Internet Protocol Branch Exchange. Rseau tlphonique fonctionnant avec le

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

simultanment sur un circuit de transmission unique
[SA16] nonce :
Terme cryptographique. Paramtre qui varie dans le temps, tel quun compteur, et
qui est utilis dans les protocoles de gestion de clefs pour se prvenir contre les
attaques message replay et dautres types dattaques
[SA17] overhead : En cryptographie, ce terme dsigne laugmentation de la taille dune trame aprs
chiffrement.
[SA18] padding :
En tlinformatique, ce terme dsigne les bits additionnels de bourrage ajouts

pour finir le dernier paquet
Page 105 sur 107
05.04.2005
VoIP/SIP & Security
Ludovic Maret
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]
Scurisation 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 Vulnrabilits et mesures de scurit
/III. Laboratoire - Vulnrabilits et mesures de scurit/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
VoIP/SIP & Security
Ludovic Maret
13 ANNEXES
[1] Tutorial : VoIP/SIP & Scurit
[2] GuideLine : Prescriptions de scurisation de la VoiP/SIP
[3] Projet de semestre : Traversal Firewall/NAT
[4] Rsultat du test de vulnrabilits de type Buffer Overflow
[5] Logiciels utiliss
[6] Journal de travail
[7] Affichette
Ludovic Maret
Page 107 sur 107
05.04.2005

Rapport Maret

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Maret

Transféré par

Droits d'auteur :

Formats disponibles

TRAVAIL DE DIPLME 2004

VOIP/SIP & SCURIT

Travail de diplme : VoIP/SIP & Scurit

1 CAHIER DES CHARGES

Dfinir et prsenter les diffrentes vulnrabilits de la VoIP lintrieur et

2. Raliser un GuideLine de prescriptions de scurisation de la VoIP/SIP. Ce Guide

Page 2 sur 107

Travail de diplme : VoIP/SIP & Scurit

2 TABLE DES MATIRES

CAHIER DES CHARGES ______________________________________________________ 2

TABLE DES MATIRES_______________________________________________________ 3

ARCHITECTURES DE DPLOIEMENT DE LA VOIP/SIP _____________________________ 9

PRESCRIPTIONS DE SCURISATION DE LA VOIP/SIP _____________________________ 9

Page 3 sur 107

Travail de diplme : VoIP/SIP & Scurit

LABORATOIRE : VULNRABILITS DE LA VOIP/SIP ______________________________ 9

FIGURES ET TABLEAUX _____________________________________________________ 9

Page 4 sur 107

Travail de diplme : VoIP/SIP & Scurit

Page 5 sur 107

Travail de diplme : VoIP/SIP & Scurit

Figure 1 - Modle client-serveur (HTTP/SIP)

Page 6 sur 107

Travail de diplme : VoIP/SIP & Scurit

5 VULNRABILITS DE LA VOIP/SIP LINTRIEUR ET

Vulnrabilits des protocoles

Page 7 sur 107

Travail de diplme : VoIP/SIP & Scurit

5.1 Vulnrabilits lintrieur de lentreprise

SIP Session Initiation Protocol (RFC 3261) de lIETF

Voici un rappel sur le principe de larchitecture trapzodale SIP :

Figure 2 - Architecture trapzodale SIP

Page 8 sur 107

Travail de diplme : VoIP/SIP & Scurit

Figure 3 - Appel SIP standard

Page 9 sur 107

Travail de diplme : VoIP/SIP & Scurit

Menaces hritant directement du modle rseau de donne IP :

Denis de service (DoS) : Privation daccs un service rseau en bombardant les

Page 10 sur 107

Travail de diplme : VoIP/SIP & Scurit

Menaces propres lutilisation de la VoIP/SIP :

Page 11 sur 107

Travail de diplme : VoIP/SIP & Scurit

Dnis de service (DoS) :

Figure 4 - DoS CANCEL sur Bob

Page 12 sur 107

Travail de diplme : VoIP/SIP & Scurit

CANCEL sur Alice :

Figure 5 - DoS CANCEL sur Alice

Figure 6 - DoS BYE

Page 13 sur 107

Travail de diplme : VoIP/SIP & Scurit

Figure 7 - DoS BYE Bob

Figure 8 - DoS BYE Alice

Page 14 sur 107

Travail de diplme : VoIP/SIP & Scurit

BYE (aux deux) :

Figure 9 - DoS BYE Bob et Alice

Utilisation des codes de rponses :

Page 15 sur 107

Travail de diplme : VoIP/SIP & Scurit

Manipulation des collisions SSRC (RTP) :

Figure 10 - Format de paquet RTP et vulnrabilits associes