Rapport PFE VoIP

Maroua Labidi PFE 2012/2013

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

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



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.



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.

Acquisition de la voix

Numérisation Compression Encapsulation Emission

/Transport



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 SDP1 (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)

UDP (Version 3...) Utiliser n’importe quel

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)

http://fr.wikipedia.org/wiki/Norme

http://fr.wikipedia.org/wiki/Cryptographie

http://fr.wikipedia.org/wiki/Union_internationale_des_t%C3%A9l%C3%A9communications

http://fr.wikipedia.org/wiki/Infrastructure_%C3%A0_cl%C3%A9s_publiques

http://fr.wikipedia.org/wiki/Certificat_%C3%A9lectronique

http://fr.wikipedia.org/wiki/Algorithme



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 SSL4 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 DTLS5

(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.

http://fr.wikipedia.org/wiki/Protocole_de_communication

http://fr.wikipedia.org/wiki/Netscape_Communications_Corporation



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

Communicator

Cisco IP Communicator est une application bureautique qui fournit à un ordinateur

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].

Documents

Rapport PFE VoIP