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...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 2
Remerciements
Je tiens à remerci...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 3
Table des matières
INTRODUCTION ...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 4
1.3.5.1 Description générale du ...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 5
3.2.2 Environnement Logiciel ......
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 6
Table des Figures
Figure 0-1: Or...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 7
Figure 3-6: Paramétrage du Cisco...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 8
Table des Tableaux
Tableau 1-1 :...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 9
Acronymes
AAA Authentication, Au...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 10
MCU Multipoint Control Unit
MIK...
Maroua Labidi PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 11
SNMP Simple Network Manager Pro...
Introduction générale PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 12
INTRODUCTION GENERALE
D...
Introduction générale PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 13
une exigence. Dans cett...
Introduction générale PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 14
Figure 0-1: Organisatio...
Introduction générale PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 15
Figure 0-2: Planning du...
Introduction générale PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 16
Organisation du rapport...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 17...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 18...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 19...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 20...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 21...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 22...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 23...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 24...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 25...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 26...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 27...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 28...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 29...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 30...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 31...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 32...
Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécurisée 33...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013
Etude et mise en place d’une solution Voix sur IP sécuris...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013
Etude et mise en place d’une so...
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Rapport PFE VoIP
Prochain SlideShare
Chargement dans…5
×

Rapport PFE VoIP

369 vues

Publié le

1 commentaire
1 j’aime
Statistiques
Remarques
  • slt, je vs félicite pr ce bon travail, j'arrive pas à télécharger votre pfe, si tu veux m'aider envoyer moi ton rapport à kechkar42@gmail.com merci :)
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
369
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
51
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Rapport PFE VoIP

  1. 1. 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
  2. 2. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 2 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.
  3. 3. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 3 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.1 Description générale du protocole......................................................................................................... 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.1 Description générale du protocole......................................................................................................... 27 1.3.3.2 Les Messages SCCP................................................................................................................................. 29 1.3.4 Le protocole RTP.............................................................................................................................. 29 1.3.4.1 Description générale du protocole......................................................................................................... 29 1.3.4.2 Les données RTP..................................................................................................................................... 30 1.3.5 Le protocole RTCP............................................................................................................................ 32
  4. 4. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 4 1.3.5.1 Description générale du protocole......................................................................................................... 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
  5. 5. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 5 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
  6. 6. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 6 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
  7. 7. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 7 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
  8. 8. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 8 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
  9. 9. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 9 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
  10. 10. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 10 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
  11. 11. Maroua Labidi PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 11 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
  12. 12. Introduction générale PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 12 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
  13. 13. Introduction générale PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 13 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.
  14. 14. Introduction générale PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 14 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.
  15. 15. Introduction générale PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 15 Figure 0-2: Planning du projet
  16. 16. Introduction générale PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 16 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.
  17. 17. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 17 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.
  18. 18. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 18  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
  19. 19. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 19 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
  20. 20. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 20 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
  21. 21. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 21  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
  22. 22. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 22 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) 1.3.2.1 Description générale du protocole 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.
  23. 23. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 23 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,
  24. 24. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 24 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:
  25. 25. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 25  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.
  26. 26. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 26 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
  27. 27. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 27 1.3.3 LE PROTOCOLE SCCP 1.3.3.1 Description générale du protocole 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 :
  28. 28. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 28  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.
  29. 29. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 29 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 1.3.4.1 Description générale du protocole 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.
  30. 30. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 30 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 :
  31. 31. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 31 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
  32. 32. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 32 1.3.5 LE PROTOCOLE RTCP 1.3.5.1 Description générale du protocole 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
  33. 33. Chapitre 1 : Etude générale de la voix sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 33 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é.
  34. 34. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 34 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.
  35. 35. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 35 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.
  36. 36. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 36 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.
  37. 37. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 37 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.
  38. 38. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 38 « 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.
  39. 39. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 39 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é.
  40. 40. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 40 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.
  41. 41. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 41 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)
  42. 42. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 42 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).
  43. 43. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 43 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.
  44. 44. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 44 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).
  45. 45. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 45 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]
  46. 46. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 46 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.
  47. 47. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 47  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].
  48. 48. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 48 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]
  49. 49. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 49  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 DTLS 5 (Datagram TLS) [18]. La figure 2-7 décrit la structure de TLS : Figure 2-7: Structure TLS [14] La sous-couche ‘Record’ est la couche qui assure le transport des données basée directement sur TCP et peut transporter 4 types de payload [18]: o Les messages ‘Handshake’ sont utilisés pour authentifier le serveur et le client. Il y a pour cela deux types d’authentification ; l’authentification mutuelle et l’authentification simple. L’authentification mutuelle nécessite que le client et le serveur soient authentifiés. Dans le cas de l’authentification simple, seul le serveur est authentifié, o Les messages ‘CSS’ (Change Cipher Spec) utilisés pour signaler à la sous- couche Record toute modification des paramètres de sécurité, 4 SSL : Secure Sockets Layer (SSL), est un protocole de sécurisation des échanges sur Internet, développé à l'origine par Netscape (Wikipédia) 5 DTLS réemploie la plupart des éléments constituant le protocole TLS avec quelques changements pour le fonctionnement avec le mode UDP.
  50. 50. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 50 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.
  51. 51. Chapitre 2 : La sécurité dans la téléphonie sur IP PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 51 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.
  52. 52. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 52 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.
  53. 53. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 53 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].
  54. 54. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 54 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 :
  55. 55. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 55 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
  56. 56. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 56 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
  57. 57. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 57 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
  58. 58. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 58 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
  59. 59. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 59 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).
  60. 60. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 60 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:
  61. 61. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 61 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 :
  62. 62. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 62 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.
  63. 63. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 63 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.
  64. 64. Chapitre 3 : Conception et mise en place d’une infrastructure VoIP sécurisée PFE 2012/2013 Etude et mise en place d’une solution Voix sur IP sécurisée 64 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

×