Maroua Labidi

Maroua Labidi PFE 2012/2013
Je dédie ce travail
A ma chère mère, à mon cher père
A mes deux chères sœurs
A tous les membres de ma famille
A toutes les personnes chères à mon cœur
Etude et mise en place d’une solution Voix sur IP sécurisée 1

Remerciements
Je tiens à remercier particulièrement mon encadreur au sein de l’entreprise

Tunisie Télécom, Madame Yosra Mlayeh. Sa constante bonne humeur, sa
compétence, sa disponibilité tout au long de ces quatre mois, ces critiques et sa
confiance m’ont permis de mener à bien ce travail.
Un grand merci est adressé à mon encadreur à l’INSAT, Madame Hédia

Kochkar, pour ses précieux conseils, son aimable assistance au cours de ce
projet.
De plus je tiens à remercier tous les cadres et agents de la société Tunisie

Télécom qui m’ont aimablement accueillie durant quatre mois.
Je voudrais remercier vivement les membres de jury qui m’ont fait

l’honneur de juger ce travail de projet de fin d’études.
Enfin, j’adresse mes sincères remerciements à tous ceux qui ont su être
disponibles pour m’aider et me fournir les informations nécessaires pour le bon
déroulement de ce projet de fin d’études.

Table des matières

INTRODUCTION GENERALE ............................................................................................................................ 12
1 CHAPITRE 1 : ETUDE GENERALE DE LA VOIX SUR IP ................................................................................ 17
1.1 INTRODUCTION ........................................................................................................................................ 17
1.2 PRESENTATION DE LA VOIP ........................................................................................................................ 17
1.2.1 Définition ......................................................................................................................................... 17
1.2.2 Principe de fonctionnement de La VoIP ........................................................................................... 17
1.2.2.1 Mode de fonctionnement ...................................................................................................................... 17
1.2.2.2 Principaux Codecs utilisés....................................................................................................................... 18
1.2.3 Architecture de la VoIP .................................................................................................................... 19
1.3 LES PROTOCOLES DE LA VOIP ...................................................................................................................... 19
1.3.1 Le protocole H.323 .......................................................................................................................... 20
1.3.1.1 Description générale du protocole ......................................................................................................... 20
1.3.1.2 Les entités H.323 .................................................................................................................................... 20
1.3.1.3 Famille de protocoles H.323 ................................................................................................................... 21
1.3.2 Le protocole SIP (Session Initiation Protocol) .................................................................................. 22
1.3.2.2 Les fonctions SIP ..................................................................................................................................... 23
1.3.2.3 Les composants SIP ................................................................................................................................ 23
1.3.2.4 La pile de protocoles SIP ......................................................................................................................... 24
1.3.2.5 Les messages SIP .................................................................................................................................... 24
1.3.2.6 Transaction SIP ....................................................................................................................................... 26
1.3.3 Le protocole SCCP ............................................................................................................................ 27
1.3.3.2 Les Messages SCCP ................................................................................................................................. 29
1.3.4 Le protocole RTP .............................................................................................................................. 29
1.3.4.2 Les données RTP ..................................................................................................................................... 30
1.3.5 Le protocole RTCP ............................................................................................................................ 32


1.3.5.2 Les fonctions du RTCP ............................................................................................................................ 32
1.4 COMPARAISON ENTRE H.323, SCCP ET SIP .................................................................................................. 32
1.5 CONCLUSION ........................................................................................................................................... 33
2 CHAPITRE 2 : LA SECURITE DANS LA TELEPHONIE SUR IP ....................................................................... 34
2.1 INTRODUCTION ........................................................................................................................................ 34
2.2 LES RISQUES ET LES VULNERABILITES EN TOIP ................................................................................................. 34
2.2.1 Configuration par défaut des User Agents ...................................................................................... 34
2.2.2 Absence de confidentialité .............................................................................................................. 35
2.2.3 Les vulnérabilités des systèmes d’exploitation ................................................................................ 35
2.3 DESCRIPTION DES ATTAQUES ....................................................................................................................... 35
2.3.1 Attaque Google Voip ....................................................................................................................... 35
2.3.2 Call Hijacking ................................................................................................................................... 36
2.3.3 Dénis de service ............................................................................................................................... 36
2.3.3.1 DoS : couche réseau ............................................................................................................................... 37
2.3.3.2 DoS : couche transport ........................................................................................................................... 37
2.3.3.3 DoS : couche Application ........................................................................................................................ 37
2.3.4 Man In The Middle .......................................................................................................................... 38
2.4 LES SOLUTIONS DE LA SECURITE ................................................................................................................... 39
2.4.1 La sécurité physique ........................................................................................................................ 39
2.4.2 Sécurisation des serveurs ................................................................................................................ 40
2.4.3 La supervision .................................................................................................................................. 40
2.4.3.1 Syslog ...................................................................................................................................................... 40
2.4.3.2 NIDS et HIDS ........................................................................................................................................... 40
2.4.4 Les protocoles AAA : Radius ............................................................................................................ 41
2.4.5 La sécurisation des flux.................................................................................................................... 42
2.4.5.1 Firewalls.................................................................................................................................................. 42
2.4.5.2 ACL (Access Control Lists) ....................................................................................................................... 44
2.4.5.3 Sécurisation du flux média ..................................................................................................................... 44
2.4.5.4 Sécurisation de la session SIP ................................................................................................................. 48
2.5 CONCLUSION ........................................................................................................................................... 51
3 CHAPITRE 3 : CONCEPTION ET MISE EN PLACE D’UNE INFRASTRUCTURE VOIP SECURISEE ..................... 52
3.1 INTRODUCTION ........................................................................................................................................ 52
3.2 ENVIRONNEMENT DE TRAVAIL ..................................................................................................................... 52
3.2.1 Environnement matériel .................................................................................................................. 52

3.2.2 Environnement Logiciel ................................................................................................................... 53

3.3 ARCHITECTURE RÉSEAU SIP/TOIP DÉPLOYÉE ................................................................................................. 54
3.4 SIMULATION D’ATTAQUES AU NIVEAU INTERNE DU RESEAU ................................................................................ 58
3.4.1 Google VoIP Hacking ....................................................................................................................... 58

3.4.2 Man In The Middle .......................................................................................................................... 61
3.4.3 Dénis de Service – Invite FLOOD ...................................................................................................... 65
3.5 LES MECANISMES DE SECURISATION .............................................................................................................. 65
3.5.1 La sécurité dans le Cisco Unified Communications Manager .......................................................... 66
3.5.1.1 Utilisation du protocole TLS pour la signalisation .................................................................................. 66
3.5.1.2 Implémentation du protocole SRTP ....................................................................................................... 67
3.5.1.3 Modification des paramètres de la configuration par défaut des téléphones IP ................................... 67
3.5.2 Sécurité dans l’infrastructure réseau............................................................................................... 68
3.5.2.1 Implémentation du Cisco PIX Firewall .................................................................................................... 69
3.5.2.2 Configuration de l’authentification RADIUS sur un routeur Cisco C7200 .............................................. 70
3.5.2.3 Filtrage sur les routeurs : Définition des ACLs ........................................................................................ 72
3.6 CONCLUSION ........................................................................................................................................... 73
CONCLUSION GENERALE ................................................................................................................................ 74

Table des Figures
Figure 0-1: Organisation interne de Tunisie Télécom ............................................................. 14

Figure 0-2: Planning du projet ................................................................................................. 15
Figure 1-1: Architecture VoIP .................................................................................................. 19
Figure 1-2: Zone H.323 ............................................................................................................ 20
Figure 1-3: La pile protocolaire H.323 [6] ............................................................................... 22
Figure 1-4: La pile protocolaire SIP [11] ................................................................................. 24
Figure 1-5: Une transaction SIP ............................................................................................... 26
Figure 1-6: Trafic SCCP .......................................................................................................... 27
Figure 1-7: Trafic Skinny ......................................................................................................... 28
Figure 1-8: Paquet RTP ............................................................................................................ 31
Figure 2-1: Attaque DoS CANCEL [13].................................................................................. 38
Figure 2-2: Mécanisme d'attaque MITM [15] .......................................................................... 39
Figure 2-3: Scénario d'authentification entre UAC et serveur Radius ..................................... 42
Figure 2-4: Paquet SRTP [18] .................................................................................................. 45
Figure 2-5: Chiffrement par AES-CTR [14] ............................................................................ 46
Figure 2-6: Procédure de dérivation de clefs [18] .................................................................... 47
Figure 2-7: Structure TLS [14]................................................................................................. 49
Figure 2-8: Handshake TLS [14] ............................................................................................. 50
Figure 3-1: Interface Web de CUCM v8.6 ............................................................................... 54
Figure 3-2: Réseau de test SIP/ToIP non sécurisé ................................................................... 55
Figure 3-3: Configuration réseau du routeur R1 ...................................................................... 55
Figure 3-4: Configuration réseau du routeur R2 ...................................................................... 56
Figure 3-5: Configuration réseau du R3 ................................................................................... 56

Figure 3-6: Paramétrage du Cisco IP Communicator ............................................................. 56

Figure 3-7: La configuration par défaut du CIPC .................................................................... 57
Figure 3-8: Enregistrement des Cisco IP Communicator ......................................................... 57
Figure 3-9: Etablissement d'une conversation téléphonique entre les deux CIPC ................... 58
Figure 3-10: Configuration du CIPC 2 ..................................................................................... 59
Figure 3-11: Ping de la machine exécutant le service TFTP ................................................... 60
Figure 3-12: Nmap du serveur CUCM .................................................................................... 60
Figure 3-13: Fichier de configuration du 'SEP0026225FC0FD' .............................................. 61
Figure 3-14: Trafic RTP ........................................................................................................... 63
Figure 3-15: RTP Flooding ...................................................................................................... 63
Figure 3-16: Fonctionnalité ‘Telephony’ de Wireshark .......................................................... 64
Figure 3-17: Fonctionnalité 'VoIP Calls' de Wireshark ........................................................... 64
Figure 3-18: Ecoute de la conversation avec RTP Player ........................................................ 64
Figure 3-19: Configuration du TLS dans le profil de sécurité du CIPC .................................. 67
Figure 3-20: La nouvelle configuration des Cisco IP Communicators .................................... 68
Figure 3-21: Notre architecture VoIP sécurisée ....................................................................... 69
Figure 3-22: Configuration interface Outside PIX1 ................................................................. 69
Figure 3-23: Commande 'show ip' dans PIX1 .......................................................................... 70
Figure 3-24: Table de routage du PIX1 .................................................................................... 70
Figure 3-25: Configurer l'IDS dans PIX1 ................................................................................ 70
Figure 3-26: Ajout d'un client Radius Standard ....................................................................... 71
Figure 3-27: Stratégie d’authentification selon l'adresse IP du Client Radius ......................... 71
Figure 3-28: Condition de notre stratégie d'authentification .................................................... 72
Figure 3-29: Configuration AAA dans le routeur R3 ............................................................. 72
Figure 3-30: ACL interdisant le trafic HTTP entrant au routeur R2 ........................................ 72
Figure 3-31: ACL interdisant le trafic HTTP entrant au routeur R3 ........................................ 73
Figure 3-32: ACL autorisant le trafic SIP des deux CIPC uniquement vers le CUCM ........... 73

Table des Tableaux
Tableau 1-1 : Les codecs Voix [3] ........................................................................................... 19

Tableau 1-2 : Les requêtes SIP [11] ......................................................................................... 25
Tableau 1-3: Les requêtes SIP [11] .......................................................................................... 26
Tableau 1-4: Quelques messages Skinny ................................................................................. 29
Tableau 1-5: Correspondance Codec/Type Payload ................................................................ 30
Tableau 1-6: Comparaison H.323 et SIP .................................................................................. 33
Tableau 2-1: Types des Pare-feux ............................................................................................ 43
Tableau 2-2: Numéros des ports de quelques services ToIP .................................................... 44
Tableau 2-3: Mécanismes de sécurité du flux Média [14] ....................................................... 45
Tableau 2-4: Mécanisme de sécurité de session SIP [14] ........................................................ 48
Tableau 3-1: Les logiciels utilisés pour la réalisation .............................................................. 53

Acronymes
AAA Authentication, Authorization and Accouting

ACL Access Control List
AES Advanced Encryption Standard
AES-CTR Advanced Encryption Standard in Counter Mode
ARP Address Resolution Protocol
CAN Convertisseur Analogique Numérique
CBC Cipher Block Chaining
CDP Cisco Datagram Protocol
CIPC Cisco IP Communicator
CUCM Cisco Unified Communications Manager
DDoS Distributed Denial of Service
DoS Denial of Service
GARP Gratuitous Address Resolution Protocol
GK GateKeeper
HIDS Host Intrusion System Detection
HTTP Hyper Text Transfert Protocol
ICMP Internet Control Message Protocol
IDS Intrusion Detection System
IETF Internet Engineering Task Force
IP Internet Protocol
IP PBX Internet Protocol Private Automatic eXchange
ITU-T International Telecommunications Union
LDAP Lightweight Directory Access Protocol
MC Multipoint Controller

MCU Multipoint Control Unit

MIKEY Multimedia Internet KEYing
MITM Man In The Middle
MKI Master Key Identifier
MP Multipoint Processor
NIDS Network Intrusion System Detection
PABX Private Automatic Branch eXchange
PBX Private Automatic eXchange
PKI Public Key Infrastructure
PME Petites Moyennes Entreprises
PoE Power over Ethernet
PSK Pre Shared Key
PSTN Public Switched Telephone Network
QoS Quality of Service
RADIUS Remote Authentication Dial In User Service
RAS Registration Admission Status
RFC Requests For Comment
RG Registrar
RS Redirect Server
RSVP Resource Reservation Protocol
RTCP Real Time Control Protocol
RTP Real Time Protocol
RTPC Réseau Téléphonique Public Commuté
RTSP Real Time Streaming Protocol
RR Receiver Report
SCCP Skinny Client Control Protocol
SDES Source Description
SDP Session Description Protocol
SHA-1 Secure Hash Algorithm 1
SIP Session Initiation Protocol

SNMP Simple Network Manager Protocol

SR Sender Report
SRTCP Secure Real-time Transport Control Protocol
SRTP Secure RTP
SSL Secure Socket Layer
TACACAS+ Terminal Access Controller Access-Control System Plus
TCP Transmission Control Protocol
TFTP Trivial File Transfer Protocol
TLS Transport Layer Security
ToIP Telephony over IP
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
VoIP Voice over IP
VDA Voice Detection Activity

Introduction générale PFE 2012/2013
INTRODUCTION GENERALE
Depuis une dizaine d’années, la transmission de la voix sur le RTC (Réseau Téléphonique
Commuté) présentait une exclusivité dans les systèmes de télécommunications. Mais
aujourd’hui, est devenu possible de transmettre la voix sur un réseau IP, VoIP (Voice over IP)
qui est une technologie de communication vocale en pleine apparition. Au lieu de disposer
d'un réseau informatique et d'un réseau RTC, une entreprise peut donc, grâce à la VoIP, tout
fusionner sur un même réseau, puisque la voix est convertie en data et ceci entraîne, une
diminution de la logistique nécessaire à la gestion des deux réseaux, une chute considérable
des frais de communication et l’implémentation d’une variété de services offerts aux
utilisateurs.
Les fournisseurs des produits télécoms offrent certaines solutions qui permettent aux
entreprises de migrer vers la VoIP. Il y a des constructeurs de PABX (Private Automatic
Branch eXchange), prenant l’exemple de Siemens, et d’Alcatel qui optent pour la solution de
l’intégration progressive de la VoIP en ajoutant des cartes extensions IP. Cette solution
facilite l’adoption de la téléphonie sur IP (Telephony over IP, ToIP) surtout dans les
entreprises de grandes échelles qui possède une plateforme classique et voulant implémenter
de la VoIP. Cisco et Asterisk proposent le développement des IP PBX (Internet Protocol
Private Branch eXchange) software. Cette solution permet de bénéficier d’une grande
extensibilité, d’une très bonne assimilation au monde des données et de voix, et surtout d’un
prix beaucoup plus intéressant. Cette approche est totalement implémentée sur les réseaux IP,
donc elle est affectée par les failles de sécurité relatives au monde IP.
Le problème essentiel de la VoIP est la sécurité qui peut engendrer des ravages énormes
pour les entreprises, la sécurité de l’architecture VoIP n’est pas un choix à prendre mais plutôt

une exigence. Dans cette même optique et dans le cadre de mon projet de fin d’étude, Tunisie
Télécom m’a appelé à mettre en place une solution VoIP sécurisée.
Présentation de l’organisme d’accueil
L’office national des télécommunications est créé suite à la promulgation de la loi N°36 du
17 avril 1995. L’office a ensuite changé de statut juridique, en vertu du décret N°30 du 5 avril
2004, pour devenir une société anonyme dénommée « Tunisie Telecom ». En juillet 2006, il a
été procédé à l’ouverture du capital de Tunisie Telecom à hauteur de 35% en faveur du
consortium émirati TeCom-DIG. Cette opération vise à améliorer la rentabilité de Tunisie
Telecom et à lui permettre de se hisser parmi les grands opérateurs internationaux. Depuis sa
création, Tunisie Telecom œuvre à consolider l’infrastructure des télécoms en Tunisie, à
améliorer le taux de couverture et à renforcer sa compétitivité. Elle contribue également
activement à la promotion de l’usage des Technologies d’Informatiques et de
Communications et au développement des sociétés innovantes dans le domaine des télécoms.
Pionnière du secteur des télécoms en Tunisie, Tunisie Telecom a établi un ensemble de
valeurs définitoires qui place le client au centre de ses priorités. L’adoption de ces valeurs se
traduit en particulier par une amélioration continue des standards de l’entreprise et de la
qualité des services. Tunisie Telecom compte dans ses rangs plus de 6 millions abonnés dans
la téléphonie fixe et mobile.
Tunisie Telecom se compose de 24 directions régionales, de 80 Actels et points de vente et

de plus de 13 mille points de vente privés. Elle emploie plus de 8000 agents [1]. La figure 0-1
représente une vue d’ensemble de la structure fonctionnelle au sein de Tunisie Télécom.

Figure 0-1: Organisation interne de Tunisie Télécom
Description du projet
La VoIP apporte des économies importantes pour les PME (Petites/Moyennes Entreprises)
principalement et surtout celles multi-sites. Mais comme chaque technologie, la VoIP a des
points faibles dont le plus important est la sécurité. Donc l’objectif principal du stage étant la
mise en place d’une infrastructure VoIP en prenant en considération la sécurité des systèmes
Voix sur IP.
Les objectifs du notre projet étant :

 La réalisation d’une étude détaillée sur la VoIP,
 La réalisation d’une étude sur la sécurité dans le monde de la VoIP,
 La conception et la mise en place d’une architecture VoIP,
 La simulation des attaques les plus connus sur la VoIP,
 L’application des politiques de sécurité nécessaires pour protéger notre architecture
VoIP déployée.
Le planning du notre projet est indiqué dans la figure 0-2.

Figure 0-2: Planning du projet

Organisation du rapport
Notre rapport de Projet de Fin d’Etudes est réparti sur quatre chapitres. Les principaux
chapitres sont énumérés ci-dessous.
Le deuxième chapitre comporte une présentation détaillée sur la Voix sur IP. Nous nous
intéressons à son principe de fonctionnement, son architecture ainsi qu’une description de ses
principaux protocoles de signalisation H.323, SIP (Session Initiation Protocol) et SCCP
(Skinny Cisco Control Protocol) et les deux protocoles du transport RTP (Real-time Transport
Protocol) et RTCP (Real-time Transport Control Protocol). Ensuite, nous comparons entre
ces trois protocoles de signalisation afin de choisir le protocole le plus pertinent à utiliser dans
notre solution VoIP.
Dans le troisième chapitre nous nous intéressons à la sécurité des infrastructures VoIP.
Nous décrivons les principales failles de sécurité dans les solutions implémentant cette
technologie. Ensuite, nous expliquons le fonctionnement technique des attaques les plus
connus et qui ont un grave impact sur les PME convergeant vers VoIP. Enfin, nous citons les
mesures de sécurité que l’entreprise peut appliquer, afin de profiter des avantages de la VoIP
dans un environnement plus protégé.
Le quatrième chapitre s’intéresse à la conception et la mise en place de notre solution

VoIP, que nous réalisons avec le simulateur graphique des architectures réseaux GNS3. Cette
solution VoIP est basée sur l’IP PBX du Cisco « Cisco Unified Communications Manager »
dans sa version 8.6. Après, nous allons simuler quelques attaques sur notre infrastructure
déployée, ensuite nous implémentons des politiques de sécurité adéquates afin de protéger
notre infrastructure contre ces attaques.
Le dernier chapitre de ce rapport conclut les résultats que nous avons obtenus, ainsi que
des perspectives futures sur la sécurité dans les systèmes VoIP.

Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
1 CHAPITRE 1 : ETUDE GENERALE DE LA VOIX SUR IP
1.1 INTRODUCTION
En Tunisie aujourd’hui, la VoIP est en pleine émergence et elle devienne la première

solution à adopter par les PME, vu qu’elle leurs offrent une diminution considérablement
importante des frais de communications inter et intra-sites et une opportunité d’exploitation
de nouveaux services téléphoniques, indisponibles dans les réseaux téléphoniques classiques.
Dans ce premier chapitre, nous présenterons une étude détaillée sur la VoIP ; son
architecture, ses principaux standards et nous entamons par une comparaison entre les
différents protocoles de cette technologie.
1.2 PRESENTATION DE LA VOIP

1.2.1 DEFINITION
La Voix sur IP, comme est bien clair du son nom; est le fait de transmettre de la Voix sur
un réseau IP qui transporte les données sous forme de paquets. La voix est soumise à des
traitements spécifiques afin qu’elle peut être envoyée sur un réseau IP, elle est digitalisée,
compressée puis envoyée au récepteur par paquets de données. Les données reçues par la
destination sont décompressées et converties en voix audible.
1.2.2 PRINCIPE DE FONCTIONNEMENT DE LA VOIP

1.2.2.1 Mode de fonctionnement
La voix pour qu’elle soit transmise sur le réseau IP, elle aboutisse un certain nombre de
traitements physiques dans un ordre chronologique bien précis.

Acquisition de la Emission
Numérisation Compression Encapsulation
voix /Transport
 La numérisation : cette étape consiste à capturer des points à intervalles de temps réguliers
de la voix acquise, cette durée est fixée selon la fréquence d'échantillonnage choisie.
Chacun de ses échantillons est ensuite codé par un chiffre,
 La compression : le signal numérique ainsi formé, est compressé selon l’un des formats
des codecs et le principal but de la compression est de minimiser l’utilisation de la bande
passante,
 L’encapsulation : pour se convertir en des paquets, les données ainsi obtenues doivent être
enrichies par des entêtes avant d’être expédier sur le réseau IP.
Côté destination, [2] les paquets reçus sont décompressés; en utilisant le même format du
codec qu’à l’émission; puis converties en un signal analogique en utilisant un Convertisseur
N/A (Numérique/Analogique).
1.2.2.2 Principaux Codecs utilisés
Le mot Codec [3] vient du résultat de fusion des deux mots (Codeur/Décodeur), son rôle
est de compresser et décompresser un signal que ça soit analogique ou numérique, en un
format de données. La finalité d’utiliser un codec est de diminuer l’utilisation de la bande
passante lors du traitement d’un nombre important de données. Nous pouvons diviser les
codecs en deux grandes catégories, suivant leurs manières de compresser/décompresser les
données :
 La compression non-destructive : permet de retrouver le signal initial tel qu'il était

avant le codage,
 La compression destructive : prend en compte les caractéristiques des données à
compresser et peut retirer les informations les moins importantes du signal.
Le tableau 1-1 présente les principaux codecs de la voix.

Tableau 1-1 : Les codecs Voix [3]

Codec Débit Binaire (Kbits/s)
G.711 64
G.726 32
G.728 16
G.729 8
G.722.1 6.3
G.723.1 5.3
Le choix du codec [4] dépend essentiellement de la QoS (Quality of Service) souhaitée et

la capacité de la bande passante du réseau. Il existe aussi, le mécanisme VDA (Voice
Detection Activity) qui détecte les silences produits lors d'une communication téléphonique.
L’utilisation de ce mécanisme permet de réduire l’occupation de la bande passante jusqu’à
50%.
1.2.3 ARCHITECTURE DE LA VOIP
La topologie d’un réseau Voix sur IP, comprend [5] des terminaux, un serveur de
communication et si nous avons deux types de réseaux différents, l’utilisation d’une passerelle
devient nécessaire. La figure 1-1 présente la topologie générale d’une architecture ToIP.
Figure 1-1: Architecture VoIP
1.3 LES PROTOCOLES DE LA VOIP
Les protocoles de la Voix sur IP sont divisés en deux parties, ils existent des protocoles
pour la signalisation et l’établissement de connexions entre les entités VoIP et des protocoles

pour le transport des flux multimédia. Nous allons étudier les principaux protocoles de
signalisation VoIP; H.323 développé par l’UIT‐T, SIP (Session Initiation Protocol) qui est un
standard de l’IETF et SCCP (Skinny Client Control Protocol) qui est un protocole
propriétaire CISCO. Après l’établissement de la communication, le transport et le contrôle des
flux média sont assurés par les protocoles RTP (Real-time Transport Protocol) et RTCP
(Real-time Transport Control Protocol).
1.3.1 LE PROTOCOLE H.323

1.3.1.1 Description générale du protocole
La recommandation H.323 [6] a été spécifiée par l’ITU-T en 1996 dans le cadre de fournir
des communications audio, vidéo et de données sur les réseaux IP. H.323 est utilisé pour
aboutir à l’établissement d’une connexion multimédia sur un réseau IP et il présente un
ensemble de trois protocoles (H.225 RAS, H.225 Call Signaling et H.245) que nous allons les
voir en détail après.
1.3.1.2 Les entités H.323
Les composants H.323 [6] sont regroupés dans des zones. Une zone comme est illustrée
dans la figure 1-2, comprend un ensemble de terminaux, passerelles (gateways) et ponts de
conférence (Mulitpoint Control Unit, MCU) qui sont gérés par un seul portier (GateKeeper,
GK).
Figure 1-2: Zone H.323

 Terminal : qui permet d’établir des communications multimédia avec d’autres terminales.
Il peut être un PC ou un téléphone IP qui supporte au moins un codec audio et un codec
vidéo,
 Gateway : qui assure les communications entre des entités H.323 et d’autres entités (RTC,
RNIS, GSM, …),
 GateKeeper (GK) : est le « chef d’orchestre » du réseau H.323 car il présente le point
central pour tous les appels dans une zone H.323 et il contrôle les end-points,
 Multipoint Control Unit (MCU) : est une station sur le réseau qui permet aux trois entités
H.323 ou plus de participer à une conférence multipoints. Le MCU a deux fonctions,
contrôleur multipoint (Multipoint Controller, MC) et processeur multipoint (Multipoint
Processor, MP) :
MC : met en œuvre le contrôle et la signalisation pour le support de la conférence,
MP : reçoit les flux des terminaux, les traitent et les retourne aux terminaux
participants à la conférence.
1.3.1.3 Famille de protocoles H.323
Comme nous avons mentionné que H.323 est un ensemble de protocoles qui se divise en
trois grandes catégories. Notons que les codecs utilisés dans H.323 sont [7] G.711, G.723.1 et
G.729 pour la voix et pour la vidéo sont H.261 et H.263.
La signalisation H.323 est mise en œuvre par trois protocoles [7] :
 H.225 RAS (Registration, Admission and Status) : utilisé entre les end-points et le
GK. Il permet à ce dernier de contrôler les end-points présents dans sa zone H.323,
 H.225 Call Signaling : c’est la signalisation qui permet l’établissement et la libération
des connexions entre les end-points H.323,
 H.245 : Dés que l’appelé décroche, le protocole H.245 établit des canaux RTP/RTCP
pour le transport et le contrôle des données multimédia.
Les protocoles temps réel utilisé avec H.323 pour le transport de flux de données sont RTP
et RTCP.
RTP n’assure pas la réservation des ressources et ne se préoccupe pas de la QoS des
transferts tandis que RTCP fournit un minimum de contrôle, nous allons voir les

caractéristiques de ces deux protocoles dans les sections qui suivent. Le protocole RAS utilise
le protocole UDP alors que les protocoles Call Signaling et H.245 utilisent le protocole TCP.
La figure 1-3 présente la pile protocolaire H.323 :
Figure 1-3: La pile protocolaire H.323 [6]
1.3.2 LE PROTOCOLE SIP (SESSION INITIATION PROTOCOL)

SIP [8] est un protocole de signalisation VoIP, de la couche application. Son rôle est
l’établissement, la modification et la libération des sessions multimédias sur le réseau IP. Il
est basé à la fois sur le protocole de transfert d’hypertexte HTTP (Hyper Text Transport
Protocol) ; car il utilise des requêtes et des réponses pour les transactions entre ces entités ; et
sur le protocole de messagerie SMTP (Simple Mail Transport Protocol) car les messages
transmis entre les équipements SIP sont sous forme électronique (E-mails).
SIP [8] a été développé par l’IETF (), organisation de normalisation de l’IP, sa version la
plus récente est décrite dans la RFC 3261. SIP utilise généralement les ports 5060 et/ou 5061.
Il encapsule le protocole SDP 1 (Session Description Protocol) qui permet de décrire une
session SIP. Chaque utilisateur SIP est attribué à une identité unique URI (Uniform
Ressources Indicator), comparable à une adresse e-mail, qui est sous la forme suivante :
‘sip:Nom-Utilisateur@Addresse-Serveur-SIP’.
1
SDP (Session Description Protocol) : est un protocole qui permet aux entités SIP de négocier certains
paramètres sur la connexion à établir tel que le choix de codec, etc.

1.3.2.2 Les fonctions SIP
SIP a des fonctions multiples [9] :

 Fixation d’un compte SIP : un compte SIP identifiable par un nom unique et associé à
un serveur SIP d’adresse fixe, sera attribué à un utilisateur SIP pour qu’il soit toujours
joignable,
 Changement des caractéristiques durant une session : un utilisateur SIP peut
modifier les caractéristiques d’une session active, par exemple il peut changer la configuration
de la session de « voice-only » en « voice-video »,
 Gestion des participants : dans une session déjà active, de nouveaux participants
peuvent joindre cette session directement, en étant transférés ou en étant mis en attente,
 Adressage : chaque utilisateur dispose d’un compte SIP unique.
1.3.2.3 Les composants SIP
Dans un système SIP, on trouve deux types de composants, les Users Agents [4] (UA) et
les serveurs SIP [10] :
 UA : c’est l’utilisateur final, il peut être soit un Softphone (logiciel s’exécutant sur un
ordinateur qui offre à ce dernier les fonctionnalités d’un téléphone IP) soit un Hardphone.
L’UA est la combinaison d’agent d’utilisateur client (UAC : User Agent Client) et d’agent
d’utilisateur serveur (UAS : User Agent Server) :
UAC : est une entité qui envoie des requêtes SIP,
UAS : entité qui génère des réponses aux requêtes SIP. Ces réponses peuvent
être une acceptation, un refus ou une redirection de la requête reçue.
 Les Serveurs SIP : Il existe une multitude de serveurs SIP :
RG (le Registrar): il reçoit les requêtes REGISTER envoyées des UA pour
faire leurs inscriptions, après une éventuelle mobilité,
Proxy SIP : encore appelé serveur mandataire, le proxy est utilisé lorsque les
deux UA ne connaissent pas leurs emplacements. Il effectue des requêtes pour le
compte des UAC, il les route afin de les acheminer à une entité plus proche de
destination. Et pour ce faire il interroge la base de données (URI<->Adresse IP)
stockée dans le Registrar,

RS (Redirect Server) : il aide à localiser les UA SIP en fournissant une adresse

alternative à laquelle l’utilisateur appelé peut être joint,
LS (Location Server) : est un serveur qui fournit la position actuelle d’un
utilisateur SIP. Les informations mémorisées dans le LS sont utilisées par le RS ou le
Proxy SIP. Le LS peut être basé sur un serveur LDAP ou une base de données.
1.3.2.4 La pile de protocoles SIP
SIP définit un cadre de technologies complet pour les communications multimédia, fondé
sur les protocoles suivants [8] :
 SDP (Session Description Protocol),
 RTSP (Real Time Streaming Protocol),
 RSVP (ReSerVation Protocol) pour la réservation de la bande passante,
 RTP (Real-Time Transport Protocol)
La figure 1-4 présente la pile protocolaire du protocole SIP :
Figure 1-4: La pile protocolaire SIP [11]
1.3.2.5 Les messages SIP
Les messages SIP [4] sont codés en utilisant la syntaxe du message HTTP/1.1 et comme
nous avons déjà dit que SIP est basé sur un modèle d’architecture Client/Serveur, donc ces
messages sont divisés en deux parties ; les requêtes et les réponses. Les champs toujours
présents dans l’entête SIP sont:

 Call-ID: ce champ contient un identificateur unique pour un appel,

 From: est l’identificateur de l’appelant,
 To : est l’identificateur de l’appelé,
 Via : ce champ est utilisé pour enregistrer la route d’une requête, de manière à
permettre aux serveurs SIP intermédiaires de faire suivre aux réponses un chemin exactement
inverse,
 Encryption: ce champ spécifie que le corps du message et éventuellement certains en-
têtes ont été chiffrés,
 Content-Type: ce champ décrit le type de média contenu dans le corps du message,
 Content-Length : il s’agit du nombre d’octets du corps du message.
Le tableau 1-2 présente la liste des requêtes SIP.
Tableau 1-2 : Les requêtes SIP [11]

Requête Description
INVITE indique que l’UA d’URI spécifié est invité à participé à une session.
OPTIONS un Proxy Server en mesure de contacter l’UAS appelé, doit répondre à une
requête OPTIONS en précisant sa capacité à contacter l’UAS.
BYE utilisé par un appelé pour mettre fin à une session.
CANCEL envoyée par un UA à fin d’annuler une requête non valide.
ACK permet de confirmer que l’appelant a bien reçu une réponse définitive à une
requête INVITE.
REGISTER utilisée par le client pour s’enregistrer au prés du serveur SIP auquel il est relié.
Suite au traitement de la requête reçue de la part d’un UAC, l’UAS envoie une réponse
sous forme d’un code d’état, indiquant à l’UAC la façon avec laquelle sa requête a été traitée.
Ces codes sont découpés en 6 catégories qui sont décrites dans le tableau 1-3.

Tableau 1-3: Les requêtes SIP [11]

Code d’état Description Exemple
1xx Informations sur le statut de l’appel 180 RINGING
2xx Réussite 200 OK
3xx Redirection vers un autre serveur 301 MOVED TEMPORARILY
4xx Erreur côté client 401 UNAUTHORISED
5xx Erreur côté serveur 500 INTERNAL SERVER ERROR
6xx Echec global 606 NOT ACCEPTABLE
1.3.2.6 Transaction SIP
Le diagramme de séquence de la figure 1-5, présente un exemple du déroulement d’une

transaction SIP [8] entre deux User-Agents et un serveur SIP :
Figure 1-5: Une transaction SIP

1.3.3 LE PROTOCOLE SCCP

Anciennement développé par Selsius Corporation, SCCP (Skinny Client Control Protocol)
[12] fut racheté par Cisco System en 1998. SCCP est un protocole léger qui s’occupe de la
signalisation entre un téléphone IP et l’Unified Communications Manager de Cisco. Le
transport du flux média, comme est le cas dans H.323 et SIP, se base sur RTP. SCCP utilise le
port TCP 2000 pour la signalisation et RTP over UDP pour le trafic temps-réel.
Nous avons configuré deux téléphones IP pour capturer le trafic transitant entre ces deux
téléphones IP et le serveur Cisco Unified CM, sans nous intéresser à ce qui se passait en
arrière-plan. Le sniffeur utilisé pour la capture du trafic est Wireshark.
Figure 1-6: Trafic SCCP
A partir de la figure 1-6, nous pouvons voir qu’il existe une multitude de protocoles
présents dans ce trafic :

 CDP (Cisco Discovery Protocol) : le matériel CISCO envoie des messages CDP par
défaut, qui servent à réguler la puissance fournit par le switch PoE2,
 SKINNY : est le protocole qui gère la communication entre le téléphone IP et le
CUCM,
 TFTP (Trivial File Tranfert Protocol) : le téléphone utilise ce protocole pour
récupérer son fichier de configuration (dans notre cas est le fichier
SEP000C2942418DF.cnf.xml).
Après l’application d’un filtre « SKINNY » nous nous retrouvons uniquement avec des
paquets SCCP, comme est indiqué dans la figure 1-7:
Figure 1-7: Trafic Skinny
Nous avons donc une conversation entre notre téléphone IP d’adresse ‘192.168.1.20’ et
notre CUCM d’adresse ‘192.168.1.100’. Nous pouvons deviner le rôle de certains paquets :
RegisterMessage enregistre le téléphone auprès de CUCM.
2
PoE (Power over Ethernet): est une technologie utilisée pour alimenter des périphériques réseau tels que des
access points, des téléphones IP ou encore des caméras.

1.3.3.2 Les Messages SCCP
Il existe une dizaine de messages SCCP, qui transitent entre le client et le serveur de
téléphonie, mais, nous avons choisir les messages les plus courant pour les illustrer dans le
tableau 1-4 :
Tableau 1-4: Quelques messages Skinny
1.3.4 LE PROTOCOLE RTP

RTP (Real-time Transport Protocol) [7], standardisé en 1996, est un protocole qui a été
développé par l'IETF. Le but de RTP est de fournir un moyen de transfert des données
multimédia sur un réseau IP. RTP est un protocole de couche application et généralement
RTP se fait au-dessus d’UDP, vu que le protocole TCP est incompatible avec les flux temps-
réel car TCP prévoit une réduction automatique du débit accordé à l’émetteur en cas de
congestion du réseau. Le protocole RTP permet :
 d’identifier le type de l’information transportée,
 d’ajouter des marqueurs temporels permettant d’indiquer l’instant d’émission du
paquet,
 d’inclure des numéros de séquence à l’information transportée afin de détecter
l’occurrence des paquets perdus et d’envoyer les paquets en ordre vers la destination.

Mais, RTP n’effectue pas de la réservation des ressources et du contrôle de la QoS et ne

garantie pas la livraison du paquet à l’arrivée.
1.3.4.2 Les données RTP
 Codage des signaux
La destination doit savoir le codec utilisé par la source, dans la phase de codage, pour
qu’elle puisse décoder correctement le flux de données reçu. Cette information sur le type de
codec est contenue dans le champ « Type Payload » du paquet RTP. Chaque numéro du ce
champ est relatif à un codec spécifique définit dans le RFC 3551. Le tableau 1-5 présente
quelques correspondances entre type de codec et numéros du type de contenu.
Tableau 1-5: Correspondance Codec/Type Payload
 Format du paquet RTP
L’entête du paquet RTP est obligatoirement constitué de 12 Octets. La capture du trafic

RTP de la figure 1-8 permet de savoir les champs constituants une entête RTP :

Version [2bits]: le numéro de version RTP utilisé,

Padding [1bit]: s’il est à 1, indique que le champ de données a une partie de bourrage,
Extension [1bit]: s’il est à 1, indique que l’entête fixe a une partie d’entête supplémentaire,
Contributing Source Count [4bits]: indique le nombre de sources contributives liées à ce
paquet,
Marker [1bit] : Il s’agit d’un bit de signalisation,
Payload Type [7bits] : Ce champ identifie le type du contenu, qui représente le type de codage
d’information véhiculé dans le paquet,
Sequence Number [16bits] : la valeur de ce champ est incrémentée de 1 à chaque paquet RTP
envoyé, alors que sa valeur initiale est aléatoire,
Timestamp [32bits] : RTP utilise des estampilles temporelles pour dater les paquets émis,
Synchronization Source [32bits] : ce champ identifie la source ayant produit le paquet. Au
début chaque participant choisit un numéro de SSR [7].
Figure 1-8: Paquet RTP

1.3.5 LE PROTOCOLE RTCP

Le protocole RTCP (RTP Control Protocol) [7], défini dans la RFC 1889, permet de
contrôler le transfert. Il se base sur l’envoie périodique de paquets de contrôle à tous les
participants d’une session. C’est un protocole de contrôle de flux RTP, permettant [9] de
véhiculer des informations basiques sur les participants d’une même session et sur la QoS. Il
existe cinq différents types de paquets RTCP pour chaque type d’information:
 SR (Sender Report) contient des statistiques de réception et d’émission pour les
participants qui sont des émetteurs actifs,
 RR (Receiver Report) contient des statistiques de réception pour les participants qui ne
sont que des récepteurs d’une session,
 SDES (Source Description) décrit la source par son nom, e-mail, tél, etc.,
 BYE permet à une station d’indiquer la fin de sa participation à une session,
 APP est un paquet de signalisation spécifique à une application.
1.3.5.2 Les fonctions du RTCP
Parmi les principales fonctions qu’offre le protocole RTCP [8] :

 Une synchronisation supplémentaire entre les médias,
 L’identification des participants à une session,
 Le contrôle de la session : les participants indiquent leurs départs d’une conférence
téléphonique et ils donnent une indication sur leurs comportements.
1.4 COMPARAISON ENTRE H.323, SCCP ET SIP
Après avoir connu des détails techniques sur chacun des protocoles de signalisation H.323,
SCCP et SIP, nous devons choisir le protocole le plus pertinent pour l’utiliser dans la partie
pratique du notre projet.
Le point fort du protocole SCCP est dans sa simplicité, mais malgré ça nous avons choisi
de ne pas l’utiliser dans la partie pratique, car il est propriétaire Cisco et pour pouvoir

l’utiliser comme le protocole de signalisation dans une PME, cette dernière doit
obligatoirement posséder le serveur ToIP (Telephony over IP) du constructeur Cisco.
Nous restreignons alors la comparaison entre H.323 et SIP, les critères de cette
comparaison sont la complexité et l’éxtensibilité dans le futur.
Le tableau 1-6 résume les points faibles et les points forts de chacun de ces protocoles
selon un certain nombre de critères.
Tableau 1-6: Comparaison H.323 et SIP

H.323 SIP
Architecture Point à Point Client/Serveur

Protocole du transport TCP (Version 1,2) Utiliser n’importe quel
UDP (Version 3...) protocole de transport
Codage de message Binaire ASN.1 Texte
Maintenance de protocole Complexe Simple
Spécification 700 pages 130 pages
Extensibilité Non Oui
Il est bien clair que l’implémentation de protocole SIP est plus pertinente que celle de
H.323. Donc le protocole de signalisation que nous allons choisir pour élaborer la partie
pratique est le protocole SIP.
1.5 CONCLUSION
La VoIP est la technologie la plus pertinente dans le domaine des télécommunications. Sa
fiabilité en termes de diminution des coûts, de joignabilité des clients malgré leurs mobilités
font d’elle la solution optimale pour les PME.
Toutefois, cette technologie pose encore de nombreuses questions quant à sa sécurité.

Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
2 CHAPITRE 2 : LA SECURITE DANS LA TELEPHONIE SUR

IP
2.1 INTRODUCTION
Aujourd’hui le déploiement de la ToIP est en pleine évolution, mais malheureusement, son

implémentation s'accompagne de certaines failles de sécurité qui peuvent engendrer des
problèmes graves aux PME. En plus la couche IP, sur laquelle se base la VoIP, apporte en elle
de nouvelles menaces. Ce chapitre est divisé en trois parties, la première partie décrit les
principales vulnérabilités des systèmes implémentant la technologie Téléphonie sur IP, la
deuxième partie est consacrée pour présenter les attaques les plus connues sur la ToIP et la
dernière partie présente les mesures de sécurité à prendre pour protéger nos réseaux ToIP.
2.2 LES RISQUES ET LES VULNERABILITES EN TOIP

2.2.1 CONFIGURATION PAR DEFAUT DES USER AGENTS
Les équipements SIP (Softphones, Hardphones ou serveurs d’infrastructures) sont livrés

avec une configuration par défaut qui menace la sécurité de réseaux ToIP. La page de
configuration du téléphone IP, sur le serveur Web d’administration [13], contient le login et le
mot de passe relatifs à un UA donné, ces deux importantes informations peuvent être
récupérables directement à partir du code source de la page. Plusieurs dispositifs de la VoIP,
dans leur configuration par défaut, peuvent avoir une variété de ports TCP et UDP ouverts. Les
services fonctionnant sur ces ports peuvent être vulnérables à la divulgation d’informations et
aux attaques du type Buffer OverFlow.

2.2.2 ABSENCE DE CONFIDENTIALITE
En utilisant le protocole SIP pour la signalisation et le protocole RTP pour le transport de

flux de données, nous exposons notre système à des nombreuses menaces [13], car ces deux
protocoles n’implémentent aucune méthode de chiffrement ou de cryptage de données
échangées dans une communication ToIP. Si une personne malveillante connaisse le chemin
emprunté par les paquets RTP, il peut facilement savoir le contenu d’une communication
téléphonique entre deux User-Agents.
Le protocole SIP, transmet les entêtes et la charge utile du paquet en texte clair, si une
personne arrive à lire ces messages SIP, elle peut avoir des informations importantes sur le
serveur SIP et les UAs.
2.2.3 LES VULNERABILITES DES SYSTEMES D ’EXPLOITATION
Les équipements ToIP héritent les mêmes vulnérabilités du système d'exploitation sur lequel
ils tournent. Il existe une centaine de vulnérabilités exploitables à distance sur Windows et
même sur Linux. Un grand nombre de ces exploits sont disponibles librement et prêts à être
téléchargés sur l'Internet. Même en protégeant au mieux nos équipements ToIP, la sécurité de
notre réseau reste menacée si les systèmes d’exploitation ne sont pas bien protégés.
2.3 DESCRIPTION DES ATTAQUES
Les trois principes fondamentaux de sécurité de l’information sont la confidentialité,

l’intégrité et la disponibilité. Pour mettre à mal au moins l’un de ces piliers, nous pouvons se
baser sur trois autres principes la révélation d’informations, l’altération, et le déni de service.
2.3.1 ATTAQUE GOOGLE VOIP
Tout comme la technologie Web, les périphériques VoIP sont exposés sur les réseaux IP, ce
qui permet aux pirates de les trouver et de les exploiter facilement. Le « Footprinting » [14] est
une attaque de reconnaissance passive, qui a comme résultat la collecte de plusieurs
informations sur le déploiement réseau de la cible VoIP.
Il existe une variété de techniques et d’outils accessibles au public, qui permettent de réaliser
ce type d’attaque.

Egalement, lors de l'exécution d’une reconnaissance passive sur une cible potentielle,
l’attaquant possède diverses méthodes qui lui permettent d’exploiter les moteurs de recherche
et ceci en utilisant les fonctionnalités avancées d'un service donné tel que Google par exemple.
La plupart des périphériques VoIP fournissent une interface web pour la gestion administrative,
donnant ainsi aux utilisateurs la possibilité de modifier leurs paramètres personnels (la
messagerie vocale, le code PIN, les options de transfert, etc) via cette interface Web.
En réalisant cette attaque, l’agresseur possède en main des informations importantes sur
l’infrastructure réseau ToIP, les adresses MAC des téléphones IP, les adresses IP des serveurs
en relation avec le service de téléphonie, l’adresse IP des routeurs, etc.
2.3.2 CALL HIJACKING
Le Call hijacking [14] consiste au fait de détourner une conversation téléphonique vers une
personne malveillante. Plusieurs fournisseurs de service ToIP utilisent le web comme interface
permettant à l’utilisateur d’accéder à son système téléphonique. Un utilisateur authentifié peut
modifier les paramètres de sa configuration à travers cette interface web. C’est peut être
pratique, mais un utilisateur malveillant peut appliquer le même moyen pour mener une
attaque.
Par exemple, quand un agent SIP envoie un message INVITE pour initier un appel,
l’attaquant envoie un message de redirection 3xx indiquant que l’appelé s’est déplacé et par la
même occasion donne sa propre adresse de renvoie. A partir de ce moment, tous les appels
destinés à l’utilisateur sont transférés et c’est l’attaquant qui les reçoit. Un appel détourné en
lui-même est un problème, mais c’est encore plus grave quand il est porteur d’informations
sensibles et confidentielles.
2.3.3 DENIS DE SERVICE
Les attaques par DoS (Denial of Service) sur le réseau ToIP [13] exploitent la stratégie que
celles sur les réseaux d’informations, dont le principe est de lancer de nombreuses requêtes vers
un serveur de téléphonie jusqu’à sa saturation.

Si cette attaque est réalisée par une seule personne, il est facilement identifié et alors nous
pouvons l’isoler. Cependant si un attaquant décide de réaliser cette attaque en utilisant plusieurs
machines simultanément contre un même serveur de téléphonie, alors nous sommes en face
d’un déni de service distribué (DDoS, Distributed Denial of Service).
Cette technique utilise plusieurs machines appelées «machines zombies » et l’effet du DDoS
est de réduire le temps de l’attaque en amplifiant son effet. Les attaques par déni de service
peuvent se réaliser à plusieurs niveaux [11] :
 DoS dans la couche réseau,
 DoS dans la couche transport,
 DoS dans la couche application.
2.3.3.1 DoS : couche réseau
 IP Flooding : l’attaquant envoie un nombre très important de paquets IP vers une même
destination (station victime). La station victime se sature et devienne incapable de traiter les
paquets IP légitimes. «Teardrop» et «Ping of death» sont les attaques les plus connus de l’IP
Flooding.
2.3.3.2 DoS : couche transport
 UDP Flooding : a le même principe que l’IP Flooding, mais ce sont des requêtes UDP
qui sont envoyées en masse vers la victime. Le trafic UDP étant prioritaire sur le trafic TCP, ce
type d'attaque peut vite troubler et saturer le trafic transitant sur le réseau. Les équipements SIP
fonctionnent au dessus du protocole UDP, ce qui en fait d’elles des cibles. Les entités VoIP
peuvent être facilement paralysées grâce à des paquets UDP Flooding visant l’écoute du port
SIP (5060).
2.3.3.3 DoS : couche Application
 SIP Flooding : cette attaque de Dénis de Service, vise directement les entités finales
VoIP, telles que téléphones IP ou les serveurs de téléphonie. Nous allons citer dans ce qui suit
des exemples d’attaques DoS relatives au SIP Flooding.

« DoS CANCEL » : L’attaquant surveille l’activité du serveur SIP et attend qu’un appel
arrive pour un User Agent spécifique. Une fois que le dispositif de l’UA reçoit la requête
INVITE, l'attaquant envoie immédiatement une requête « CANCEL ». Cette requête produit
une erreur sur le dispositif de l’appelé et termine l'appel (voir figure 2-1). Ce type d'attaque est
employé pour interrompre la communication.
Figure 2-1: Attaque DoS CANCEL [13]
« SIP INVITE Flood » : Un déni de service plus traditionnel. L’attaquant envoie simultanément
un nombre important de requêtes INVITE vers le serveur de téléphonie de notre infrastructure,
ainsi ce dernier se sature et devient incapable de traiter les requêtes « INVITE» légitimes.
Ce qui va être nuisible au service de téléphonie et nous aboutissons à une situation de dénis
de service.
2.3.4 MAN IN THE MIDDLE
MITM [15] consiste à écouter une conversation téléphonique entre deux UAs au moyen d'un
empoisonnement ARP dans le but est de convaincre à la fois le serveur SIP et les téléphones IP
de communiquer avec l’attaquant et non entre eux. La figure 2-2 illustre l'aspiration d'une
transmission VoIP.

Figure 2-2: Mécanisme d'attaque MITM [15]
MITM est basé sur l’ARP Spoofing dont la succession des étapes est comme suit [16]:
 Etape n°1 : déterminer les adresses MAC des victimes par l’attaquant.
 Etape n°2 : envoi d’une requête ARP non sollicités au client, pour l’informer du
changement de l'adresse MAC du serveur VoIP à son adresse MAC.
 Etape n°3 : envoi d’une requête ARP non sollicités au serveur, pour l’informer du
changement de l'adresse MAC du client à son adresse MAC.
 Etape n°4 : désactiver la vérification des adresses MAC sur la machine d’attaque afin
que le trafic puisse circuler entre les deux victimes.
2.4 LES SOLUTIONS DE LA SECURITE
Comme nous avons vu dans la section précédente, qu’il existe une multitude d’attaques sur
le réseau ToIP. Pour se protéger contre ces dernières, nous devons mettre en place des
politiques de sécurité à plusieurs niveaux de notre architecture ToIP.
2.4.1 LA SECURITE PHYSIQUE
La sécurité physique est à la base du tout environnement sécurisé. Elle doit permettre la
limitation des accès aux bâtiments et aux équipements évitant ainsi les intrusions inopportunes
et les dommages accidentels. Une politique de contrôle d’accès pour restreindre l’accès aux
composants du réseau de ToIP permettra d’établir un premier périmètre sécurisé.

Lors de la mise en place d’un système de ToIP, l’alimentation électrique doit être étudiée en
détail pour éviter toute interruption de service due à une coupure de courant [15]. Deux
possibilités peuvent être utilisées pour alimenter le poste IP :
 brancher le téléphone sur le secteur via un transformateur,
 utiliser un switch PoE.
2.4.2 SECURISATION DES SERVEURS
Avant l’établissement de toute communication téléphonique, le serveur ToIP doit être

protégé et pour ce faire nous pouvons :
 supprimer les comptes inutiles,
 vérifier les droits associés à chaque utilisateur,
 supprimer les services inutiles.
2.4.3 LA SUPERVISION
Les moyens de surveillance active du réseau et de l’ensemble de ses périphériques ne

fournissent pas seulement un niveau de défense supplémentaire mais aussi des moyens de
récupérer des informations sur le déroulement des événements non prévus dans un
fonctionnement nominal.
2.4.3.1 Syslog
La fonctionnalité Syslog permet d’avoir une technique pour gérer les échanges de
notification au travers d’un réseau IP entre un client et un serveur. Les messages échangés ne
sont pas chiffrés par défaut puisqu’il s’agit d’un protocole très simple; il est donc nécessaire de
restreindre ce type d’application à un réseau interne ou protégé.
2.4.3.2 NIDS et HIDS
IDS (Intrusion Detection System) [13] est un mécanisme destiné à repérer des activités
anormales ou suspectes sur la cible analysée (un réseau ou un hôte). Il permet ainsi d'avoir une
connaissance sur les tentatives d'intrusion d'une entreprise.

L’IDS n’a que le rôle d’alerter qu’une intrusion a lieu, il faut donc que l’administrateur
réseau de l’entreprise intervienne afin de régler les problèmes.
Les systèmes de détection d’intrusion de réseaux [13] (Network-based Intrusion Detection

Systems, NIDS) leur principal rôle est d’alerter les administrateurs réseaux de l’infrastructure
lors d’une détection d’un trafic malicieux.
Les systèmes de détection d’intrusion d’hôte [13] (Host-based Intrusion Detection System,
HIDS) se basent sur les informations collectées sur les serveurs ou les machines utilisateurs,
par des logiciels spécifiques, pour les analyser. Cette technique nous permet d’avoir une vue
détaillée sur les différentes activités et ainsi elle nous permet de savoir les utilisateurs ayant des
activités non autorisées.
2.4.4 LES PROTOCOLES AAA : RADIUS
 Authentification : l’authentification consiste à vérifier qu’une personne/équipement est

bien celle/ celui qu’elle/il prétend être. Ceci est généralement réalisé en utilisant un secret
partagé entre l’utilisateur à l’aide de certificats (X.5093),
 Autorisation : l’autorisation consiste à permettre l’accès à certains services ou
ressources. Un utilisateur peut par exemple demander à avoir une certaine bande passante. Le
serveur AAA lui autorisera ou non cette demande,
 Compte : le serveur AAA a la possibilité de collecter des informations sur l’utilisation
des ressources. Ceci permet à un opérateur de facturer un utilisateur suivant sa consommation.
Radius [17] est un protocole qui permet d’authentifier des utilisateurs et de leurs autoriser
l’accès à un système ou à un service. Ce protocole est un élément de sécurité très pertinent et
qui doit être implémenté dans l’entreprise. Pour avoir une plateforme ToIP sécurisée, faire une
combinaison entre SIP et Radius est le bon choix à prendre.
La figure 2-3 décrit un scénario générique où l’UAC et le serveur SIP communiquent en

utilisant le protocole SIP de manière standard alors que le serveur SIP et le serveur Radius
communiquent en utilisant Radius tout en restant transparent à l’UAC.
3
X.509 : est une norme de cryptographie de l'UIT pour les infrastructures à clés publiques. X.509 établit entre
autres un format standard de certificat électronique et un algorithme pour la validation de chemin de certification.
(Wikipédia)

Figure 2-3: Scénario d'authentification entre UAC et serveur Radius
2.4.5 LA SECURISATION DES FLUX
Après la numérisation, la voix devienne identifiable et se confond avec les flux data sur le
réseau IP. Elle devienne ainsi victime des problèmes rencontrés couramment en data. Pour
protéger les paquets transitant dans un réseau ToIP, diverses mesures peuvent être
implémentées tels que la mise en place des Pare-feu, la définition des Access-list, le
chiffrement du flux, etc. [18].
2.4.5.1 Firewalls
Un pare-feu préserve le réseau des attaques en filtrant les paquets qui y circulent. Ce filtrage
doit offrir en toute transparence aux utilisateurs du réseau d’entreprise tous les services dont ils
ont besoin à l’extérieur. Il doit protéger les accès aux applications et aux données à l’intérieur
du réseau d’entreprise. Le pare-feu fonctionne principalement grâce à un ensemble de règles.
Celles-ci définissent les connexions autorisées (allow) et celles qui sont interdites (deny).
Dans certains cas, le pare-feu peut rejeter une demande extérieure, sans même prévenir
l’utilisateur concerné (drop).

Les règles de refus peuvent être implicites (interdire les communications qui n’ont pas été
expressément autorisées) ou explicites (ne pas interdire que ce qui a été spécifiquement
interdit). Si la première méthode est la plus sûre, elle oblige à une définition exhaustive et
précise des interdictions ; la seconde peut entraîner des failles de sécurité.
Les pare-feux se divisent en trois catégories (voir tableau 2-1) :
Tableau 2-1: Types des Pare-feux

Stateless Firewall Un Pare feu qui se base sur un filtrage simple de paquets. Il analyse les en-
têtes de chaque paquet de données échangé entre une machine du réseau
interne et une machine extérieure. Les champs d’en-têtes
systématiquement analysés par ce firewall sont l’adresse IP de la source et
de la destination, le type de paquet et le numéro de port
Stateful Firewall Un Pare-feu avec état a la capacité de faire une suivie des échanges, et ceci
en mémorisant l'état des anciens paquets pour appliquer les règles de
filtrage. De cette manière, à partir du moment où une machine autorisée
initialise une connexion à une machine située de l'autre côté du pare-feu,
l'ensemble des paquets transitant dans le cadre de cette connexion sera
implicitement accepté par ce pare-feu
Proxy Firewall Le filtrage applicatif permet, comme son nom l'indique, de filtrer les
communications application par application. Le filtrage applicatif suppose
donc une bonne connaissance des protocoles utilisés par chaque
application. Un firewall effectuant un filtrage applicatif est appelé
généralement “passerelle applicative” (ou “proxy”), car il sert de relais
entre deux réseaux en s'interposant et en effectuant une validation fine du
contenu des paquets échangés [15].
Le tableau 2-2 présente une liste de numéros de ports des services couramment utilisés dans
la technologie ToIP. Nous apporterons une attention particulière à la gestion des ports
dynamiques par les Pare-feu pour éviter d’ouvrir des plages de ports extrêmement importantes.

Tableau 2-2: Numéros des ports de quelques services ToIP

Service Ports
Skinny TCP 2000
TFTP UDP 69
SSL/HTTPS TCP 443
RTP 16384-32767
DNS UDP 53
SYSLOG UDP 514
SIP 5060
SIP/TLS 5061
2.4.5.2 ACL (Access Control Lists)
Les listes de contrôles d’accès (ACLs) permettent de filtrer des paquets suivant certains
critères définis par un administrateur réseau [19]. Il est ainsi possible de filtrer les paquets
entrants ou sortants d'un routeur en fonction de l’adresse IP de la source, de l’adresse IP de la
destination, des ports source et destination.
Il existe divers types d'ACL, parmi les quelles nous citons:

 Les ACLs standards : le filtrage est seulement suivant l’adresse IP de la source, les
ACL standards doivent être au plus près de la destination au risque de détruire un paquet trop
tôt,
 Les ACLs étendues : le filtrage se fait sur tous les champs d’entêtes IP, TCP et UDP, les
ACL étendues doivent être au plus près de la source du paquet pour le détruire le plus vite
possible [19].
2.4.5.3 Sécurisation du flux média
Les trafics multimédia sont sous forme des paquets et transportés en utilisant le protocole
RTP qui est basé sur de l’UDP non fiable. Pour avoir des informations relatives à la qualité de
service des paquets reçus, nous utilisons le protocole RTCP. Toutes connexions multimédia est
très sensible aux délais de temps (time delay) et aux larges variations de délais (gigue ou jitter).

Si nous voulons sécuriser le trafic multimédia, nous devons appliquer, une méthode de
chiffrement du trafic et un algorithme d’authentification qui n’ont pas une influence sur ces
paramètres de QoS [14].
Le tableau 2-3 donne les deux principaux mécanismes de sécurité du flux média.
Tableau 2-3: Mécanismes de sécurité du flux Média [14]
 Secure RTP est conçu pour sécuriser la multiplication à venir des échanges multimédias
sur les réseaux. SRTP est une extension du protocole RTP qui fournit la confidentialité du trafic
RTP et l’authentification des paquets RTP [14]. Contrairement au protocole IPsec (IP Security),
le mécanisme d'échanges de clefs par SRTP est léger. SRTP s’adjoint avec les services de
protocole de gestion de clef MIKEY (Multimedia Internet KEYing). Voyons un peu plus en
détails le format d’un paquet RTP dans la figure 2-4.
Figure 2-4: Paquet SRTP [18]

Le champ de clef MKI (Master Key Identifier) sert à identifier la clef primaire depuis
laquelle les clefs de session sont dérivées. Et le champ d’étiquette d’authentification est un
checksum cryptographique calculé sur l’entête et le corps du paquet RTP. Son utilisation est
fortement recommandée étant donné qu’il protège les paquets contre une quelconque
modification non autorisée.
 Algorithme de chiffrement par défaut
En principe, n’importe quel schéma de chiffrement peut être utilisé avec SRTP. En tant
qu’algorithme par défaut, AES-CTR (Advanced Encryption Standard in Counter Mode) est
défini. En effet, le chiffrement par AES standard ne permet pas de chiffrer des flux [18]. La
définition du chiffrement par AES-CTR est représentée dans la figure 2-5 :
Figure 2-5: Chiffrement par AES-CTR [14]
Cet algorithme de chiffrement joue le rôle de générateur de clefs (sous forme de flux) qui
produit une clef pseudo-aléatoire de longueur arbitraire qui va s’appliquer de manière bit-à-bit
au contenu RTP/RTCP. Le chiffrement sera effectué à l’aide d’une fonction logique XOR de la
clef de flux et du contenu RTP/RTCP. Pour pouvoir fonctionner comme un générateur pseudo-
aléatoire, AES-CTR est chargé au début de chaque paquet RTP/RTCP avec un vecteur
d’initialisation distinct (IV). Ce vecteur est obtenu en hashant une salt_key (clef propre à
chaque utilisateur) de 112 bits, le champ SSRC du flux média et l’index du paquet [14].
AES utilisé en mode de comptage au lieu du mode le plus habituel cipher block chaining
(CBC) a le grand avantage que la clef sous forme de flux peut être pré calculée avant que le
contenu ne soit disponible et ainsi cela minimise les délais introduits par le chiffrement.
De plus, en utilisant un cipher de flux au lieu d’un cipher de bloc, il n’y a pas besoin
d’utiliser débits de padding pour augmenter la taille du contenu.

 Algorithme d’authentification par défaut
L’algorithme d’authentification de messages SRTP par défaut est HMAC-SHA-1. Celui-ci

est basé sur la fonction de hash sur 160 bits SHA-1. L’authentification est accomplie en hashant
un secret ‘auth_key’ de 160 bits dans un checksum qui est ensuite tronqué à 80bits afin de
réduire l’overhead du paquet. Dans les applications où la transmission en bande de base est un
problème, le tag d’authentification peut être réduit à 32 bits [14].
 Dérivation de clef de session
Les deux algorithmes de chiffrement et d’authentification requièrent des clefs symétriques

secrètes de session qui doivent être connues de tous les agents participant à la session SIP. Une
seule clef maîtresse peut être utilisée à la fois pour le SRTP et SRTCP grâce à une fonction de
dérivation de clef de session (voir figure 2-6). La nécessité de la dérivation des clefs est facile à
comprendre [18]:
o seulement deux clefs sont transmises à l’initialisation : la clef maîtresse et la clef ”salt”,
o si une clef de session est découverte, il sera impossible de retrouver les autres clefs de
sessions.
Figure 2-6: Procédure de dérivation de clefs [18]
 Distribution de la clef primaire
Il existe un système simple pour l’échange de clefs. Le paramètre (k) ‘key’ définit par SDP
peut être utilisé pour transmettre la clef primaire.
Le paramètre k contient la clef primaire SRTP de 128 bits. Nous arrivons à lire la clef cela
implique des problèmes de sécurité, c’est pour cette raison que nous devons mettre en place des
mécanismes de chiffrement du protocole SIP (avec TLS) et du contenu SDP (avec S/MIME)
[18].

2.4.5.4 Sécurisation de la session SIP
Puisque la structure des messages SIP se base sur le modèle HTTP de requête/réponse, tous
les mécanismes de sécurité disponibles pour HTTP peuvent être appliqués aux sessions SIP. De
manière similaire à HTTPS : l’URI SIP correspondant à l’URI SIPS. Ceci va créer un tunnel
sécurisé au niveau transport en utilisant TLS (Transport Layer Security). IPSec est également
utilisable comme mécanisme général de chiffrement pour toutes les communications IP au
niveau réseau.
Les deux mécanismes de sécurité essentiels adaptés à la protection de la session SIP sont
représentés dans le tableau 2-4. Ils font partie de la liste des méthodes recommandées par la
version 1 du standard SIP.
Tableau 2-4: Mécanisme de sécurité de session SIP [14]

 TLS
L’implémentation de TLS pour SIP est presque similaire à l’implémentation de SSL 4 pour
HTTP. Le protocole de chiffrement TLSv1est dérivé de SSLv3.
TLS fonctionne de manière indépendante par rapport aux applications qui l'utilisent. De
plus, il est obligatoirement au dessus de la couche TCP [14]. L’utilisation de TCP en lieu et
place d’UDP va légèrement diminuer la rapidité de la signalisation mais ceci est presque
négligeable, et pour les systèmes trop exigeants en termes de QoS, il existe le DTLS 5
(Datagram TLS) [18].
La figure 2-7 décrit la structure de TLS :
Figure 2-7: Structure TLS [14]
La sous-couche ‘Record’ est la couche qui assure le transport des données basée directement
sur TCP et peut transporter 4 types de payload [18]:
o Les messages ‘Handshake’ sont utilisés pour authentifier le serveur et le client.
Il y a pour cela deux types d’authentification ; l’authentification mutuelle et l’authentification
simple. L’authentification mutuelle nécessite que le client et le serveur soient authentifiés. Dans
le cas de l’authentification simple, seul le serveur est authentifié,
o Les messages ‘CSS’ (Change Cipher Spec) utilisés pour signaler à la sous-
couche Record toute modification des paramètres de sécurité,
4
SSL : Secure Sockets Layer (SSL), est un protocole de sécurisation des échanges sur Internet, développé à
l'origine par Netscape (Wikipédia)
5
DTLS réemploie la plupart des éléments constituant le protocole TLS avec quelques changements pour le
fonctionnement avec le mode UDP.

o Les messages ‘Alert’, elles signalent les alertes (par exemple : fin de connexion,
problème en cours de ‘Handshake’, l’intégrité d’un message est douteuse, etc.),
o Les données de la couche applicative.
La figure 2-8 présente les principaux échanges d’un handshake TLS :
Figure 2-8: Handshake TLS [14]
Pour résumer, on peut dire que TLS assure une authentification client/serveur ainsi que
l’intégrité et la confidentialité des messages SIP. Cependant, l’utilisation de TLS va induire un
overhead [14] plus ou moins léger suivant le type d’authentification.
Cet overhead est négligeable sur une petite quantité d’appels simultanés ça ne sera pas le
cas avec un grand nombre d’appels.

2.5 CONCLUSION
En fin de ce chapitre, nous avons couvert le sujet de la téléphonie sur IP d’un point de vue
sécuritaire, les diverses attaques ToIP ont été décrites de façon détaillée et une partie des
bonnes pratiques de sécurité à adapter au sein du réseau ToIP ont été définies.

Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
3 CHAPITRE 3 : CONCEPTION ET MISE EN PLACE D’UNE

INFRASTRUCTURE VOIP SECURISEE
3.1 INTRODUCTION
Dans les chapitres précédents, nous avons réalisé une étude détaillée sur les principaux
standards de la VoIP, les attaques les plus connus sur cette technologie et nous avons définit
les mesures de sécurité à prendre pour protéger un réseau de téléphonie sur IP.
L’objectif du présent chapitre est d’illustrer au mieux les différentes vulnérabilités d’un
réseau ToIP/SIP à l’intérieur de l’entreprise. Nous commençons nos tests avec une plateforme
SIP non sécurisée, basée sur le serveur de téléphonie CUCM (Cisco Unified Communications
Manager). Vu que l’infrastructure sera non sécurisée, cela va nous permettre de réaliser les
attaques décrites dans le chapitre précédent. Et par la suite, le but est de sécuriser le réseau afin
de démontrer la fiabilité des mécanismes de défenses qui ont été mis en place.
3.2 ENVIRONNEMENT DE TRAVAIL
Dans cette section, nous présentons l’environnement matériel et logiciel utiles pour la
conception et la mise en place de notre architecture.
3.2.1 ENVIRONNEMENT MATERIEL
Machine 1: HP, processeur AMD V160, 2.4GHz avec 4Go de RAM, Windows Seven.
Machine 2: ACER, processeur ATOM, 1.6GHz avec 1Go de RAM, Windows Vista 32.

3.2.2 ENVIRONNEMENT LOGICIEL
Le tableau 3-1, présente les principaux logiciels utilisés pour l’élaboration et la réalisation
du notre projet :
Tableau 3-1: Les logiciels utilisés pour la réalisation

Nom de logiciel Description
GNS3 v0.8.3 GNS3 est un simulateur d'équipements Cisco capable de charger des vraies images
de l'IOS de Cisco permettant ainsi d'émuler entièrement des routeurs ou firewalls
Cisco et de les utiliser en simulation complète sur un simple ordinateur. A noter
simplement que GNS3 ne fournit pas d'IOS, il faut se les procurer à l'aide d'un
compte Cisco CCO.
GNS3 est fortement lié avec :
 Dynamips : un émulateur d'image IOS qui permet de lancer des images
binaires IOS provenant de Cisco Systems,
 Dynagen : une interface en mode text pour Dynamips,
 Pemu : émulateur PIX.
GNS3 est un logiciel libre qui fonctionne sur de multiples plateformes, incluant
Windows, Linux, et Mac OS.
VMWare v7.1.6 Il arrive que, dans certaines reproductions de topologies, l'ingénieur demande une
ou plusieurs machines virtuelles. Ils en ont besoin pour installer des logiciels
d'analyses, pour générer du trafic spécifique ou tout simplement pour tester des cas
de figures problématiques en s'approchant le plus possible de la topologie complète
d’un client. Ces machines virtuelles permettent, en plus d'une économie d'argent et
d'une plus grande disponibilité, une facilité de maintenance que des machines
classiques ne peuvent apporter. En quelques clics, on peut ajouter des interfaces
réseaux, les connecter dans différents VLAN ou réinitialiser la machine à son état
initial, etc.
Cisco IP Cisco IP Communicator est une application bureautique qui fournit à un ordinateur
Communicator toutes les fonctions d’un téléphone IP Cisco permettant de passer, recevoir et traiter
des appels [20].

3.3 ARCHITECTURE RÉSEAU SIP/TOIP DÉPLOYÉE
La première étape dans cette partie du projet est de mettre en place le réseau de test
SIP/ToIP non sécurisé. Pour commencer, nous devons installer le serveur SIP/ToIP, nous
choisissons le serveur de téléphonie propriétaire Cisco, le « Cisco Unified Communications
Manager v8.6» qui s’exécute sur une machine RedHat Entreprise Linux 3. « CUCM » est un
serveur de téléphonie compatible avec la plupart des protocoles de signalisation (H.323, SIP,
SCCP, etc.), il propose une interface Web très évoluée pour le paramétrage du système et il
rassemble plusieurs services téléphoniques (la vidéoconférence, la messagerie instantanée, le
renvoi d’appel, les E-mails, etc.).
La figure 3-1 montre l’interface Web du CUCM 8.6.
Figure 3-1: Interface Web de CUCM v8.6
Notre architecture réseau réalisée avec GNS3, comporte le serveur de téléphonie Cisco
Unified Communciations Manager, un attaquant, deux Softphones Cisco IP Communicator et
un contrôleur du domaine. Pour le routage, nous avons utilisé 3 routeurs d’IOS ‘C7200.bin’.
L’architecture est présentée dans la figure 3-2 :

Figure 3-2: Réseau de test SIP/ToIP non sécurisé
Les configurations réseau des routeurs R1, R2 et R3 sont données respectivement dans les
figures 3-3, 3-4 et 3-5.
Figure 3-3: Configuration réseau du routeur R1

Figure 3-4: Configuration réseau du routeur R2
Figure 3-5: Configuration réseau du R3
Après avoir installé CUCM et configurer les routeurs, nous devons établir une
communication VoIP. Maintenant, nous installons les deux SoftPhones CIPC (Cisco IP
Communicator) sur les deux stations Windows et procédons à les configurer. Pour ce faire,
allons vers l’onglet « Préférences » du téléphone IP avec un clic droit sur le CIPC, puis
« Network » et sélectionnons l’interface réseau de la machine sur laquelle notre téléphone
Cisco est installé, comme le montre la figure 3-6.
Figure 3-6: Paramétrage du Cisco IP Communicator

La définition du serveur TFTP (Trivial File Transfert Protocol), à partir duquel le téléphone
va extraire sa configuration à chaque démarrage, est nécessaire. Le serveur TFTP a la même
adresse que CUCM, puisque TFTP est intégré dans CUCM. Maintenant, côté CUCM, nous
ajoutons notre CIPC, avec SIP (port 5060) comme protocole de signalisation et TCP/UDP
comme protocoles du transport, tout en gardant la configuration que CUCM l’attribue par
défaut aux téléphones IP. Les principaux paramètres de cette configuration par défaut sont
présentés dans la figure 3-7.
Figure 3-7: La configuration par défaut du CIPC
Après l’ajout des deux CIPC et leurs configurations, nous allons les redémarrer, pour qu’ils
s’enregistrent au près du notre serveur Cisco Unified CM. L’enregistrement est fait, comme est
indiqué dans la figure 3-8.
Figure 3-8: Enregistrement des Cisco IP Communicator

Maintenant, nous pouvons établir une communication téléphonique entre CIPC1 et CIPC2
(voir figure 3-9).
Figure 3-9: Etablissement d'une conversation téléphonique entre les deux CIPC
3.4 SIMULATION D’ATTAQUES AU NIVEAU INTERNE DU RESEAU
3.4.1 GOOGLE VOIP HACKING
Cible : Les téléphones IP et le serveur TFTP.

But : Collecte des informations sur la configuration réseau des équipements ToIP.
Vulnérabilités exploitées :
 Dans la configuration par défaut du téléphone IP, attribuée par le CUCM, le paramètre
« Web Access » est activé,
 La faiblesse du protocole TFTP qui est conçu de façon non sécurisée.
Outils utilisés :
 Package TFTPC (un client Debian pour TFTP).
 Package Nmap

Simulation :
L’attaquant appartient à notre réseau local, donc il a l’information sur le nom du domaine
complet de notre infrastructure ‘maroua.local’. D’autre part, nous n’avons pas modifié la
configuration par défaut des téléphones IP, le paramètre « Web Access » est activé, donc toute
personne sachant le nom du domaine de notre infrastructure, peut avoir la configuration réseau
des téléphones IP.
Les étapes de cette attaque sont comme suit :

 Etape n°1 : L’attaquant tape la requête « inurl : ‘’Network Configuration’’ cisco
nom_domaine_réseau » dans la zone de recherche di Google.
 Etape n°2 : Le résultat de la requête, donne des liens vers tous les CIPCs autorisant
l’accès Web sur notre réseau. L’attaquant n’a qu’à faire un clic sur le premier lien et la page de
configuration du notre téléphone IP s’affiche, comme est présenté dans la figure 3-10 ci-
dessous :
Figure 3-10: Configuration du CIPC 2
 Etape n°3 : L’attaquant teste s’il peut atteindre la machine exécutant le service TFTP en
envoyant une requête ICMP (Ping) vers 192.168.1.100 (voir figure 3-11), et ensuite une simple
commande ‘nmap 192.168.1.100 ‘ va lui permettre de voir les ports ouverts sur cette machine
(voir figure 3-12).

Figure 3-11: Ping de la machine exécutant le service TFTP
Figure 3-12: Nmap du serveur CUCM
 Etape n°4 : Le port 69 du service TFTP est ouvert, Le nom du téléphone IP est
« SEP002622F5C0FD » (information extraite de la page Web de configuration du notre
téléphone IP). L’attaquant a en main toutes les informations nécessaires pour réaliser son
attaque, il lance le client TFTP et télécharge le fichier de configuration du
‘SEP0026225FC0FD’, comme est illustré dans la figure 3-13:

Figure 3-13: Fichier de configuration du 'SEP0026225FC0FD'
Le fichier de configuration SEP0026225FC0FD.cnf.xml contient d’autres informations

relatives à la ligne téléphonique (numéro DN, nom de la ligne, etc.). Avec ces informations
l’attaquant peut simuler d’autres attaques sur notre infrastructure ToIP.
3.4.2 MAN IN THE MIDDLE
Cible : Le serveur de téléphonie CUCM et les deux téléphones IP CIPC1 et CIPC2.

But : Ecoute d’une communication entre deux User-Agents.
Vulnérabilités exploitées :
 Dans la configuration par défaut du téléphone IP, le protocole SRTP est désactivé,
donc le contenu des paquets RTP est n’est pas chiffré.
 Faiblesse du protocole ARP (Address Resolution Protocol). En effet, ce protocole
n’a pas été conçu de façon sécurisée et les périphériques accepte des paquets
gratuitious ARP (GARP), ou autrement dit, des paquets contenant des informations
n’ayant jamais été réclamées. Et dans la configuration du téléphone IP, le paramètre
« GARP » est activé.
Outils utilisés :
 Wireshark : logiciel d’analyse de réseaux.
Simulation :

Pour pouvoir écouter une communication entre deux User-Agents SIP par l’attaquant, il faut
que le trafic transitant entre ces deux téléphones IP passe par la station de l’attaquant. Et une
fois que ce dernier se met dans la situation MITM, il peut capturer le trafic RTP et ainsi écouter
la communication entre les deux clients SIP. Les étapes d’attaque MITM sont comme suit :
 Etape n°1 : ‘ARP Spoofing’, l’attaquant envoie un paquet GARP vers la machine
177.17.17.50 afin qu'elle lui envoie ses paquets alors qu'ils étaient destinés à la machine
189.210.125.50. De même l'attaquant envoie un paquet GARP vers la victime 189.210.12.50
afin qu'elle lui envoie ses paquets au lieu de les envoyer à la machine 177.17.17.50. Enfin
l'attaquant doit router les paquets de 177.17.17.50 vers 189.210.125.50 et inversement pour
que la connexion, entre ces deux machines, peut continuer. L'attaquant voit ainsi toutes les
données qu'il reçoit.
Il existe des dizaines de logiciels Open Source réalisant ce type d’attaque, sur windows,
nous pouvons citer ‘Cain & Abel’ et sur Linux, le package ‘dsniff‘ fera l’affaire.
 Etape n°2 : Maintenant l’attaquant se situe bien dans la position de MITM, et il n’a qu’à
ouvrir le sniffeur ‘Wireshark’ pour commencer sa capture du trafic transitant entre nos deux
CIPCs. La capture qui vient d'être effectuée nécessite d'être nettoyée pour deux raisons. D'une
part, le trafic résiduel du réseau (broadcast, spanning-tree, routage, etc) a été capturé et viendra
dégrader la qualité de notre fichier sonore si nous ne le supprimons pas, et d'autre part, l’ARP
Spoofing a créé des paquets dupliqués (un en entrée, et un en sortie lors du forward). Donc un
nettoyage de la capture est préférable et pour ce faire l’attaquant utilise le mécanisme de
filtrage de Wireshark. Le filtrage se fait sur l'adresse MAC du téléphone CIPC2
’00:26:22:5F:C0:FD’ et sur le protocole RTP. Le résultat d’application du filtre est donné dans
la figure 3-14.

Figure 3-14: Trafic RTP
A partir de cette capture, l’attaquant peut extraire des informations très utiles (Sequence
number, Timestamp, Synchronization Source identifier) s’il a l’intention d’injecter du trafic
Voix lors de cette conversation, en cas d’un RTP Flooding il n’a qu’à exécuter la commande
suivante dans la console, comme est décrite dans la figure 3-15:
Figure 3-15: RTP Flooding
 Etape n°3 : Pour la reconstruction et l’écoute de la communication, l’attaquant utilise la

fonctionnalité de lecture des paquets RTP intégrée dans Wireshark. Les étapes sont citées dans
l’ordre, respectivement dans les figures 3-16, 3-17 et 3-18.

Figure 3-16: Fonctionnalité ‘Telephony’ de Wireshark
Figure 3-17: Fonctionnalité 'VoIP Calls' de Wireshark
Figure 3-18: Ecoute de la conversation avec RTP Player

3.4.3 DENIS DE SERVICE – INVITE FLOOD
Le déni de service est une attaque très fréquente sur les réseaux VoIP. L’attaquant va essayer
de créer un déni de service auprès du serveur Cisco Unified CM. L’attaquant envoie un nombre
très important de requêtes au serveur et ainsi il est possible de monopoliser ces ressources.
Comme le nombre de connexions est la plupart du temps limité, le serveur n'accepte plus de
nouveaux clients. Il est donc en déni de service.
Cible : Le serveur SIP, Cisco Unified Communications Manager.

But : L’attaquant veut saturer le serveur, pour qu’il ne traite plus les requêtes ‘INVITE’
légitimes.
Vulnérabilités exploitées : Les ports relatifs aux services SIP sont ouverts pour tout le
monde.
Outils utilisée : Package INVITE FLOOD.
Simulation :
La simulation de ce type d’attaque avec le package ‘inviteflood’ est simple, mais elle requit
une pré-connaissance de l’adresse IP du serveur CUCM. Donc les étapes à faire pour réaliser
cette attaque sont comme suit :
 Etape n°1 : Reconnaissance de l’adresse IP du serveur Cisco Unified CM. L’attaquant

peut extraire cette information suite à l’attaque du ‘Footprinting’
 Etape n°2 : L’attaquant n’a qu’à lancer la commande.

root@attaquant# ./inviteflood 177.17.17.51 192.168.1.100 1000
Avec l’envoi d’un grand nombre de requêtes INVITE, le serveur Cisco Unified CM, va
saturer et il ne sera plus possible de faire un appel du CIPC_1 vers CIPC_2 ou inversement. Le
flot des paquets INVITE peut être capturé par Wireshark.
3.5 LES MECANISMES DE SECURISATION
Dans la section précédente, nous avons simulé quelques attaques sur notre infrastructure
VoIP, mais maintenant nous devons minimiser l’impact de ces intrusions en implémentant les
mesures de sécurité nécessaires pour protéger notre infrastructure.

Cisco Unified Communications Manager présente une multitude des failles de sécurité, côté
configuration des téléphones IP, donc nous pouvons agir sur les paramètres de cette dernière
pour éliminer ces vulnérabilités.
L’infrastructure que nous avons réalisée, ne comprends pas des équipements de sécurité tels
que des Pare-feux, des systèmes de supervision, des serveurs d’authentification des utilisateurs
et des équipements. La mise en place de ces équipements éliminera certainement quelques
défaillances qui sont à l’origine des attaques, dont l’impact est très grave sur la sécurité de
notre réseau VoIP.
3.5.1 LA SECURITE DANS LE CISCO UNIFIED COMMUNICATIONS MANAGER
Cisco Unified Communications Manager, présente un grand nombre de vulnérabilités ; qui

peuvent être exploitées par un attaquant pour nuire à la sécurité du notre système VoIP ; telle
que la configuration par défaut des téléphones IP qui est à la base des attaques ; ARP Spoofing,
attaque Google, écoute clandestine, etc.
Alors, nous devons modifier les configurations relatives aux téléphones IP et au Cisco
Unified Communications Manager afin de les rendre moins vulnérables côté sécurité.
3.5.1.1 Utilisation du protocole TLS pour la signalisation
Puisque le protocole SIP présente une importante faille de sécurité, très exploitée par les
attaquants, est que les messages transitant entre le téléphone IP et le Cisco Unified
Communications Manager pour l’établissement d’appel, sont en texte clair.
Nous devons alors agir sur la configuration du téléphone IP pour qu’il utilise le protocole
TLS à la place du protocole SIP, voir la figure 3-19 :

Figure 3-19: Configuration du TLS dans le profil de sécurité du CIPC
3.5.1.2 Implémentation du protocole SRTP
L’attaque d’écoute clandestine n’aura jamais eu lieu, si le trafic média transitant entre les
deux User-agents était chiffré. Pour sécuriser le trafic RTP, nous devons utiliser le Secure RTP,
qui chiffrera la conversation et ainsi devient difficile à l’attaquant de convertir la
communication et de l’écouter.
3.5.1.3 Modification des paramètres de la configuration par défaut des téléphones IP
La configuration par défaut du téléphone IP, le laisse accepter directement les paquets
GARP qui sont à l’origine de l’attaque ARP Spoofing, et cette même configuration permet
l’accès Web au téléphone IP ce qui est à la base de l’attaque de reconnaissance passive (Google
Hacking).
Pour remédier à :
 ARP Spoofing : Nous devons désactiver l’acceptation implicite des paquets GARP par
les téléphones Cisco IP Communicator,
 Attaque Google : Nous devons désactiver l’accès Web aux téléphones IP.
Nous configurons les paramètres des téléphones IP, d’une manière sécurisée afin de rendre
un peu plus difficile à l’attaquant de s’introduire dans notre système VoIP. La nouvelle
configuration des téléphones Cisco IP Communicator est donnée dans la figure 3-20 :

Figure 3-20: La nouvelle configuration des Cisco IP Communicators
3.5.2 SECURITE DANS L’INFRASTRUCTURE RESEAU
Pour les attaques qui se basent sur la reconnaissance passive, active et sur les dénis de
services, nous devons mettre en place des Pare-feux bloquant l’accès à travers les ports
considérés comme vulnérables, utiliser un serveur pour l’authentification et également nous
devons définir des Access Lists pour avoir plus de protection dans notre infrastructure ToIP.
Notre architecture sécurisée est comme la présente la figure 3-17 :

Figure 3-21: Notre architecture VoIP sécurisée
3.5.2.1 Implémentation du Cisco PIX Firewall
Afin de renforcer la politique de sécurité de l’infrastructure et de restreindre l’accès aux

ressources du réseau, nous mettons en place le Pare-feu Cisco. Cisco PIX Firewall, considéré
comme le produit le plus performant, occupe la première place du marché. A ce titre, il est le
produit phare de Cisco en matière de sécurité depuis 1996. Installé sur un réseau, le PIX
détermine si le trafic est autorisé, dans un sens ou dans l’autre.
Nous allons configurer les interfaces des firewalls Cisco, voici un exemple de configuration
de l’interface outside et inside du PIX1 comme est montré dans la figure 3-22 et 3-23 :
Figure 3-22: Configuration interface Outside PIX1

Figure 3-23: Commande 'show ip' dans PIX1
Maintenant, nous devons configurer la table de routage de chacun des Firewall Cisco, voici
la table de routage relative au PIX1, voir figure 3-24 :
Figure 3-24: Table de routage du PIX1
Comme nous avons dit dans des sections précédentes, que si nous voulons sécuriser notre
infrastructure réseau, nous devons mettre en place un système de supervision tel qu’un serveur
Syslog ou un système de détection d’intrusion (IDS).
Le point fort du Cisco PIX est qu’il peut jouer le rôle d’un IDS, pour ce faire nous devons le
configurer pour qu’il nous alerte en cas d’une attaque ou même pour un niveau de notification
informationnel, il suffira juste de taper les commandes suivantes (voir figure 3-21) :
Figure 3-25: Configurer l'IDS dans PIX1
3.5.2.2 Configuration de l’authentification RADIUS sur un routeur Cisco C7200
Nous avons configuré le service d’authentification Radius sur la station ‘Contrôleur du

domaine’ vu qu’elle est d’OS « Windows 2003 Server » et le serveur Radius est intégré
implicitement dans toutes les versions Server du Windows. Les principales étapes de
configuration du Radius sont illustrées dans les figures 3-26 et 3-27 :

Figure 3-26: Ajout d'un client Radius Standard
Figure 3-27: Stratégie d’authentification selon l'adresse IP du Client Radius
Pour qu’un équipement s’authentifie, il doit satisfaire les conditions de notre stratégie
d’authentification (selon les adresses IP des clients). Pour notre cas, nous avons la stratégie
suivante (voir figure 3-28) :

Figure 3-28: Condition de notre stratégie d'authentification
Cette configuration est côté serveur, maintenant nous allons configurer nos routeurs pour
qu’ils utilisent ce serveur Radius pour l’authentification des utilisateurs et des équipements.
Prenons l’exemple de la configuration du routeur R3, les commandes de la figure 3-29
permettent au R3 d’interagir avec le serveur Radius lors de demande d’authentification d’un
équipement :
Figure 3-29: Configuration AAA dans le routeur R3
3.5.2.3 Filtrage sur les routeurs : Définition des ACLs
Nous allons maintenant utiliser les possibilités de filtrage offertes par le routeur CISCO,
nous n’allons utiliser qu’une petite partie de ces capacités, en se limitant au filtrage de niveau
réseau. Cette fonctionnalité est appelée Access Control List.
 Stratégie 1 : Nous allons interdire le trafic http entrant aux routeurs R2 et R3, pour
bloquer l’accès aux configurations des téléphones IP à travers le Web. Nous allons définir une
Access-list dans chacun de ces deux routeurs comme suit dans les figures 3-30 et 3-31.
Figure 3-30: ACL interdisant le trafic HTTP entrant au routeur R2

Figure 3-31: ACL interdisant le trafic HTTP entrant au routeur R3
 Stratégie 2 : Nous allons définir une ACL spécifique à nos besoins, nous autoriser le
trafic SIP entrant à notre serveur de téléphonie CUCM qu’à partir des deux Cisco IP
Communicators CIPC_1 et CIPC_2 d’adresses respectives 177.17.17.50 et 189.210.125.50,
comme est indiqué dans la figure 3-32:
Figure 3-32: ACL autorisant le trafic SIP des deux CIPC uniquement vers le CUCM
En utilisant le Pare-feu et les Access-List, nous pouvons diminuer l’accès aux équipements
critiques de notre infrastructure tel que le Cisco Unified Communications Manager et ainsi
nous évitons des dizaines d’intrusion qui peuvent amener à des grands ravages.
3.6 CONCLUSION
A la fin de ce chapitre, nous avons pu exploiter les failles de sécurité existantes dans notre
infrastructure, en simulant des attaques connus sur le VoIP. Nous avons ensuite mis en place
des politiques de sécurité qui diminueront l’impact des vulnérabilités et offrant un
environnement plus protégé pour les clients SIP. Mais il faut savoir qu’il est impossible d’avoir
une sécurité parfaite au niveau du réseau VoIP et généralement sur tous les réseaux.

Conclusion générale PFE 2012/2013
CONCLUSION GENERALE
Les avantages apportés par les services de téléphonie IP en termes de coûts, de facilité
d’utilisation, d’extension et de maintenance, séduisent de plus en plus d’utilisateurs, aussi bien
d’entreprises que particuliers.
Toutefois, le système de téléphonie sur IP est confronté à des contraintes liées

essentiellement à la sécurité et la qualité de service qui nuisent le bon fonctionnement de ses
services. En termes de sécurité, le système de téléphonie sur IP est ouvert à une variété
d’attaques allant de déni de service jusqu’à le vol d’identité. Plusieurs solutions et outils de
sécurité existent tels que les Firewalls, les IPS et d’autres mécanismes assurant la défense
contre ces vulnérabilités. L’enjeu serait de savoir bien combiner ces mécanismes ensemble afin
de dégager une politique de sécurité assez robuste et fiable.
De ce fait, l’objectif principal de notre projet était la conception et la mise en place d’une
infrastructure de services voix sur IP équipée d’un ensemble de mécanismes d’amélioration de
la qualité de service et de la sécurité.
A travers ce rapport, nous avons d’abord présenté la technologie VoIP ainsi ses protocoles
de signalisation et de transport. Ensuite, nous avons étudié les principaux problèmes et
vulnérabilités qui menacent cette technologie en termes sécurité. Pour résoudre ces problèmes,
nous avons conçu et mis en place une infrastructure qui intègre des mécanismes d’amélioration
de la sécurité.
Une évolution possible de notre projet consiste à développer une interface graphique
accessible par le Web permettant d’administrer l’ensemble des mécanismes déployés au niveau
de l’infrastructure VoIP.

Conclusion générale PFE 2012/2013
Bien que notre solution mise en place est assez fiable et complète, elle peut présenter des
vulnérabilités diverses. Une autre évolution possible consiste à effectuer un audit de sécurité de
la plateforme suivant une norme de sécurité

Références PFE 2012/2013
REFERENCES
[1] «A propos de TT,» [En ligne]. Available:
http://www.tunisietelecom.tn/tt/internet/fr/tunisietelecom/entreprise.
[2] A. Rezzeli et Y. Saile, La sécurité de la VoIP et les principales failles, 2007.
[3] «codec- AMV France Wiki,» [En ligne]. Available: http://wiki.amv-
france.com/wiki/Codec.
[4] Q. V. Dang et T. H. L. Nguyen, «Comparaison de la technologie de la norme H.323 et la
technologie SIP pour l'application au service de la voix sur IP(VOIP),» 2005.
[5] «Voix sur IP,» [En ligne]. Available: http://www.frameip.com/voip/. [Accès le 23
Octobre 2012].
[6] «H.323 Achitecture et Protocoles,» [En ligne]. Available: http://www.efort.com.
[7] EFORT, «RTP et RTCP,» [En ligne]. Available: www.efort.com.
[8] B. Ouattara et Y. P.-S. Bado, «Mise en place d'une solution Centrex IP,» Bobo-
Dioulasso, 2007.
[9] R. Guemri, «Réalisation d'une interface de communication entre PBXs via Asterisk,»
2006.
[10] F. Salque et X. Bruns, «La téléphonie sur IP,» Décembre 2004.
[11] R. Bouzaida, «Etude et mise en place d'une solution VoIP,» 2011.
[12] Etude et Implémentation d'une télephonie IP Mixte basée sur UCME, HEPL, 2008.
[13] Baillet, Cédric, «La sécurité de la téléphonie sur IP en entreprise,» [En ligne]. [Accès le 7
Novembre 2012].
[14] D. Endler et M. Collier, «Hacking Exposed VoIP,» Osborne, 2007.
[15] «ETTERCAP Usurpation ARP,» 1 Février 2008. [En ligne]. Available:
http://openmaniak.com/fr/ettercap_arp.php. [Accès le 1 Décembre 2012].

[16] «Serveur Radius,» [En ligne]. Available:

http://cric.grenoble.cnrs.fr/Administrateurs/Documentations/SiteWebAuthentification/Se
rveurRadius.php. [Accès le 10 Décembre 2012].
[17] D.-A. Nguyen, F. Merceron et C. L'olivier, «LA sécurisation du flux média pour la
VoIP,» Institut National des Télécommunications, Evry , 18 Mai 2005.
[18] «Les ACL Cisco,» Ardenne.
[19] «Secure RTP,» 2005. [En ligne]. Available:
http://fr.scribd.com/doc/17694343/29/Secure-RTP-SRTP. [Accès le 1 Décembre 2012].
[20] I. Cisco Systems, «Cisco IP Communicator Manuel de l'utilisateur Version 1.1,» [En
ligne]. [Accès le 21 Novembre 2012].
[21] J.-J. Allovena, G. Datrier et O. Merlin, Livre blanc VOIP & TOIP v1.02, Monégasque:
Calibri, 08 Juin 2005.
[22] A. Corenthin, Voix et Téléphonie sur IP: Protocoles et Standards, Dakar, 7 Juillet 2007.
[23] «Introduction de la Voix sur IP,» chez SIPPS VoIP By nero.
[24] «Convergence voix/Data VOIP,» [En ligne].
[25] J.-F. Rey et C. Thyrland, «La technologie SIP dans l'entreprise,» Brest, 2002.
[26] T. Arame, «TOIP (Telephony Over Internet Protocol),» 2009.
[27] M. Sengelé, «Le protocole SIP et la gestion des sources dynamiques dans une session de
groupe,» Illkirch.
[28] N. Dubée, «La voix sur IP (VoIP) une opportunité pour la sécurité?,» Secway.
[29] B. Reynolds et D. Ghosal, «Secure IP Telephony using Multi-layered Protection,»
California.
[30] M. Djouadi, «La sécurité de la VoIP,» El-Oued, 2010.
[31] H. Abdelnur Jorge, «Architecture de Sécurité sur la voix sur IP,» Lorraine, 26 Novembre
2009.
[32] R. 1889, RTP: A transport Protocol for Real-Time Application.
[33] R. 3261, SIP: Session Initiation Protocol.
[34] «NIST- Security considerations for voice Over IP Systems».

[35] A. Mehaoua, «Téléphonie sur IP et sécurité,» Paris, 2006.

[36] Cisco Systems, «Cisco IP Communicator - Manuel de l'utilisateur,» Cisco System, Inc.,
California, Etats-Unis.
[37] s. El Bahlouli et M. m. Fahmani, «UFR informatique SECURITE: Infrastructure & SI
Sécurité de la VoIP,» 2007.
[38] C. Pierre, «Configuration d'une authentification radius sur un ASA,» 26 Septembre 2010.
[En ligne]. Available: www.labo-cisco.com. [Accès le 10 Novembre 2012].
[39] G. Blum, F. LASOWY, C. Guerin et C. Pfeiffer, «AAA,» [En ligne]. Available:
http://www.loria.fr/~ichris/Teaching/ESIAL/ESIAL3/TPESR/AAA.pdf. [Accès le 2012
Décembre 5].

Maroua Labidi

Transféré par

Informations du document

Titre original

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

Maroua Labidi

Transféré par

Droits d'auteur :

Formats disponibles

Maroua Labidi PFE 2012/2013

A ma chère mère, à mon cher père

A mes deux chères sœurs

A tous les membres de ma famille

A toutes les personnes chères à mon cœur

Etude et mise en place d’une solution Voix sur IP sécurisée 1

Je tiens à remercier particulièrement mon encadreur au sein de l’entreprise

Un grand merci est adressé à mon encadreur à l’INSAT, Madame Hédia

De plus je tiens à remercier tous les cadres et agents de la société Tunisie

Je voudrais remercier vivement les membres de jury qui m’ont fait

Etude et mise en place d’une solution Voix sur IP sécurisée 2

Table des matières

Etude et mise en place d’une solution Voix sur IP sécurisée 3

1.3.5.1 Description générale du protocole ......................................................................................................... 32

Etude et mise en place d’une solution Voix sur IP sécurisée 4

3.2.2 Environnement Logiciel ................................................................................................................... 53

3.4.1 Google VoIP Hacking ....................................................................................................................... 58

Etude et mise en place d’une solution Voix sur IP sécurisée 5

Table des Figures

Figure 0-1: Organisation interne de Tunisie Télécom ............................................................. 14

Etude et mise en place d’une solution Voix sur IP sécurisée 6

Figure 3-6: Paramétrage du Cisco IP Communicator ............................................................. 56

Etude et mise en place d’une solution Voix sur IP sécurisée 7

Table des Tableaux

Tableau 1-1 : Les codecs Voix [3] ........................................................................................... 19

Etude et mise en place d’une solution Voix sur IP sécurisée 8

AAA Authentication, Authorization and Accouting

Etude et mise en place d’une solution Voix sur IP sécurisée 9

MCU Multipoint Control Unit

Etude et mise en place d’une solution Voix sur IP sécurisée 10

SNMP Simple Network Manager Protocol

Etude et mise en place d’une solution Voix sur IP sécurisée 11

Etude et mise en place d’une solution Voix sur IP sécurisée 12

Présentation de l’organisme d’accueil

Tunisie Telecom se compose de 24 directions régionales, de 80 Actels et points de vente et

Etude et mise en place d’une solution Voix sur IP sécurisée 13

Figure 0-1: Organisation interne de Tunisie Télécom

Les objectifs du notre projet étant :

Le planning du notre projet est indiqué dans la figure 0-2.

Etude et mise en place d’une solution Voix sur IP sécurisée 14

Figure 0-2: Planning du projet

Etude et mise en place d’une solution Voix sur IP sécurisée 15

Le quatrième chapitre s’intéresse à la conception et la mise en place de notre solution

Etude et mise en place d’une solution Voix sur IP sécurisée 16

1 CHAPITRE 1 : ETUDE GENERALE DE LA VOIX SUR IP

En Tunisie aujourd’hui, la VoIP est en pleine émergence et elle devienne la première

1.2 PRESENTATION DE LA VOIP

1.2.2 PRINCIPE DE FONCTIONNEMENT DE LA VOIP

Etude et mise en place d’une solution Voix sur IP sécurisée 17

1.2.2.2 Principaux Codecs utilisés

 La compression non-destructive : permet de retrouver le signal initial tel qu'il était

Le tableau 1-1 présente les principaux codecs de la voix.

Etude et mise en place d’une solution Voix sur IP sécurisée 18

Tableau 1-1 : Les codecs Voix [3]

Le choix du codec [4] dépend essentiellement de la QoS (Quality of Service) souhaitée et

1.2.3 ARCHITECTURE DE LA VOIP

Figure 1-1: Architecture VoIP

1.3 LES PROTOCOLES DE LA VOIP

Etude et mise en place d’une solution Voix sur IP sécurisée 19

1.3.1 LE PROTOCOLE H.323

1.3.1.2 Les entités H.323

Figure 1-2: Zone H.323

Etude et mise en place d’une solution Voix sur IP sécurisée 20