BP VoIP Security

Best Practices for VoIP-SIP Security
Etat Auteurs Auteurs responsables Date de cration Version Dernire mise jour Chemin intranet
Document public HESSO Alistair Doswald (HEIG), Prof. Juergen Ehrensberger (HEIG), Xavier Hahn (HEIG), Prof. Stefano Ventura (HEIG) Sbastien Contreras (EIG), Prof. Grald Litzistorf (EIG) 27 avril 2006 1.3 20 dcembre 2006 http://extratic.rcso.ch/Vadese/Security/WP6
1 2
INTRODUCTION .................................................................................................................................2 ARCHITECTURE.................................................................................................................................3 2.1 2.2 2.3 RFRENCES VOIP-SIP ....................................................................................................................3 PROBLMATIQUE ..............................................................................................................................3 SCNARIOS .......................................................................................................................................5
3 4
PRINCIPAUX RISQUES .....................................................................................................................9 ELEMENTS DE SECURITE .............................................................................................................11 4.1 4.2 4.3 4.4 4.5 SCURIT DE BASE .........................................................................................................................11 SPARATION DES QUIPEMENTS DATA ET VOIP ...........................................................................12 AUTHENTIFICATION........................................................................................................................13 CHIFFREMENT ................................................................................................................................13 SCURIT PRIMTRIQUE ...............................................................................................................14
5 6
MATRICE ATTAQUES - SOLUTIONS ..........................................................................................16 ATTAQUES POTENTIELLES .........................................................................................................18 6.1 6.2 LISTE DES ATTAQUES......................................................................................................................18 REMARQUES CONCERNANT LES ATTAQUES LIEES A STUN (TIRE DE RFC3489 S. 12.2) .................36
NOS PROPOSITIONS DE BEST PRACTICES................................................................................40 7.1 7.2 7.3 7.4 7.5 SCURIT DE BASE .........................................................................................................................40 SPARATION DES QUIPEMENTS DATA ET VOIP ...........................................................................41 AUTHENTIFICATION........................................................................................................................45 CHIFFREMENT ................................................................................................................................47 SCURIT PRIMTRIQUE ...............................................................................................................52
REFERENCES ....................................................................................................................................55
BP_VoIP_Security.doc
56 pages
Dernire modification: 17.1.2007
Best Practice - Scurit VoIP
Introduction
Ce document a pour objectif principal d'aider les responsables IT et administrateurs rseau dans la mise en uvre d'une infrastructure VoIP (Voice over IP) et respecte la structure suivante : 2 Architecture Cette partie prcise la terminologie utilise (PBX, IPBX, IP-enabled PBX, ), tente une classification et propose 3 scnarios d'utilisation. 3 Principaux risques Ce paragraphe numre les risques majeurs (Denial of Service, coute clandestine, dtournement du trafic, vols de services, ) qui doivent tre valus avant toute mise en uvre. Seule une analyse rigoureuse des risques peut garantir le succs de cette infrastructure VoIP approprie aux besoins et au budget de l'utilisateur. Les attaques relatives sont dtailles au 6 4 Elments de scurit L'arsenal des moyens techniques (segmentation, authentification, chiffrement, ) est prsent bien que certaines mesures organisationnelles puissent donner des rsultats satisfaisants un cot diffrent. Voir 7 pour la liste de recommandations Best Practices. 5 Matrices Attaques - Solutions Cette matrice apporte une rponse technique du 4 chaque risque identifi au 3 6 7 8 Attaques potentielles Suite du 3 qui contient la liste des techniques utilises Nos propositions de Best Practices Suite du 4 qui explique le fonctionnement des divers systmes de dfense Rfrences
Ce document est ax sur les protocoles SIP (Session Initiation Protocol) et RTP (Real-Time Transport Protocol); alors que la mthodologie utilise doit lui permettre de convenir dautres architectures bases sur des protocoles VoIP tels que H.323, MGCP, Skinny, Il se veut indpendant des plate-formes utilises et ne traite, de ce fait, pas les mthodes spcifiques un type d'quipement (hardphone, ) Les mthodes de scurisation non spcifiques la VoIP ne seront pas dveloppes dans ce document. Cependant, des liens vers dautres documents de rfrence (Best Practices) sont inclus de manire couvrir la scurit de linfrastructure VoIP dans son ensemble.
2/56
Architecture
2.1 Rfrences VoIP-SIP

La bonne comprhension de ce Best Practice (BP dans la suite du document) ncessite la connaissance des bases de la VoIP, et plus particulirement du protocole SIP. Le document [TutoSIP] mentionn en rfrence est un tutorial SIP permettant de comprendre les bases de ce protocole. Pour des informations plus dtailles, voir [IPTelCook].
2.2 Problmatique
Nous proposons, face aux innombrables configurations possibles de rseaux VoIP, une classification base sur des tendances observes dans l'utilisation des systmes tels que : PBX : Private Branch eXchange (Autocommutateur tlphonique priv), installation prive de commutation pouvant transmettre la voix; elle est situe dans les locaux de l'organisme utilisateur final et offre sur place la connexion entre les terminaux qui y sont branchs, y compris le service de composition, et peut assurer les connexions entre ces terminaux et d'autres rseaux de communication, y compris le PTSN1. IP-PBX ou IPBX : Internet Protocol PBX, cette installation a toute les fonctions dun PBX, mais fonctionne avec la communication IP par paquets. Pour SIP il sagit du proxy, du registrar et du service de localisation. IP-enabled PBX : Un PBX hybride pouvant galement sinterfacer avec un systme VoIP IP Centrex : IP Centrex est un systme ASP. LIPBX est fourni par un tiers, avec ventuellement un gateway dans lentreprise pour fournir le service aux appareils non-VoIP2. IP Phones : Ce terme est utilis lorsque lon parle indiffremment de hardphones ou de softphones ASP (Application Service Provider) : Fournisseur de services
Un premier niveau de classification spare les socits qui dlguent la problmatique un ASP tel que Cablecom en Suisse (dsigns aussi comme des ITSP : Internet Telephony Service Provider) avec celles qui utilisent leur propre IPBX. Dans le premier cas, la situation est relativement simple tant donn quon ne trouve que des SIPphones dans lentreprise, et donc la scurisation ne se fera quau niveau de ces tlphones et de la connexion avec lASP. Les entreprises qui possdent leur propre IPBX et du matriel SIP prsentent une situation plus complexe.
1 2
Dfinition pris sur http://www.crtc.gc.ca/dcs/frn/glossary.htm Cf. http://www.ip-centrex.org/whatis/index.html 3/56
Scnarios
ASP
IPBX
Socit Mono -Site
Socit Multi-Site
Socit Mono -Site
Socit Multi -Site
Uniquement PBX SIP
Coexistence PBX
Uniquement PBX SIP 3
Coexistence PBX
Interconnexion PSTN via Gateway 1
Interconnexion PSTN via ITSP 2
Un deuxime niveau distingue les entreprises mono-site et multi-site. Bien que les emplacements individuels dune entreprise multi-site puissent souvent tre traits comme un cas mono-site, on ajoute les problmes supplmentaires de la communication entre les sites et du plan de numrotation local. Il est aussi possible que certains sites utilisent des services VoIP qui ne sont pas implments en local, mais qui sont utiliss depuis dautres sites (typiquement le site principal). Ce cas dans le scnario ASP multi-site nest pas significatif, car les services relatifs aux services de tlphonie sont fournis par le provider lui mme. Finalement, parmi les entreprises qui possdent leur IPBX, nous distinguons ceux qui avaient un systme de tlphonie avec PBX, et qui lont gard pour ne faire quune migration partielle vers la VoIP, et ceux qui nutilisent plus que la VoIP. Pour ces derniers, il subsiste la question de la communication vers lextrieur, qui peut se faire soit via un gateway vers le PSTN, soit par IP via un ITSP (Internet Telephony Service Provider). De la figure ci-dessus, nous conservons 3 scnarios marqus par un cercle.
4/56
2.3 Scnarios
Les 3 scnarios suivants nous semblent reprsentatifs des architectures utilises aujourd'hui.
2.3.1 Entreprise mono-site avec son propre IPBX, utilisant un gateway vers le PSTN pour ses communications vers lextrieur
Dans cette situation, lentreprise communique en interne via VoIP, mais ne dsire pas que ses communications passent par internet. Le firewall+NAT et linternet montrs ici ne concernent donc que les donnes traditionnelles, et non les donns VoIP. Toute communication entrante ou sortante passe donc via le gateway sur le PTSN.
Scnario 1 : Entreprise mono -site avec son propre IPBX , utilise un Gateway PSTN pour ses communications externes IPBX
Service de localisation
Registrar
Proxy SIP
Internet
Switch Firewall + NAT (data)
SIP Hardphones
PSTN
Gateway PSTN
Cette situation est un bon exemple pour une entreprise qui dsire profiter de la VoIP avec une communication gratuite au sein de lentreprise, mais sans faire passer ses communications VoIP sur internet. Lavantage rside dans le fait que les conversations ne peuvent pas se faire intercepter en dehors du rseau de lentreprise, et que lentreprise un contrle total sur la scurit de ses communications. Par contre lutilisation dun gateway prsente quelques risques (comme le vol de service ou le toll fraud). Mesures de base prendre pour scuriser ce scnario (voir 7) : IP Phones : S.01, S.02, S.07, S.06, S.10 ou S.11, (S.12 et/ou S.13) ou S.14 Rseau : S.03, S.04, S.05, S.08 IPBX : S.01, S.10 ou S.11, (S.12 et/ou S.13) ou S.14
5/56
2.3.2 Entreprise mono-site avec son propre IPBX, utilisant un ITSP pour ses communications vers lextrieur
Lentreprise maintient tous les services VoIP locaux dans lentreprise, mais fait partir toutes les communications sortantes vers un ITSP (cest le proxy SIP qui s'en occupe). Cet ITSP devra prendre des dcisions de routage, cest--dire dcider si le trafic doit continuer passer sur internet ou bien passer sur le PTSN. Pour des raisons de haute disponibilit, lentreprise peut disposer de serveurs (proxy, registrar et service de localisation) redondants.
Scnario 2 : Entreprise mono -site avec son propre IPBX , mais utilise un ITSP pour ses communications externes IPBX
Service de localisation
Registrar
Proxy SIP
Internet
Switch SBC
VPN
SIP Hardphones
PSTN
ITSP
Le facteur prix est un argument essentiel pour les entreprises qui dsirent router leur communication VoIP via internet. Utiliser un ITSP peut rduire le cot des communications vers lextrieur. Un inconvnient majeur de ce choix a pour consquence que lentreprise na aucun contrle sur la scurit et la QoS de ses communications entrantes et sortantes. Mesures de base prendre pour scuriser ce scnario (voir 7) : IP Phones : S.01, S.02, S.07, S.06, S.10 ou S.11, (S.12 et/ou S.13) ou S.14 Rseau : S.03, S.04, S.05, S.08 IPBX : S.01, S.10 ou S.11, (S.12 et/ou S.13) ou S.14 SBC : S.15
6/56
2.3.3 Entreprise nutilisant que SIP
multi-site
avec
un
ou
plusieurs
IPBX,
Une entreprise multi-site doit avoir une solution pour faire passer ses communications dun site lautre. La solution retenue utilise un rseau priv virtuel VPN (Virtual Private Network). Etant donn quun SVPN (Secure VPN) dgrade la communication, dautres solutions de VPN sont recommands. On voit bien dans cet exemple que certains sites doivent communiquer avec dautre pour pouvoir utiliser certains services.
Scnario 3 : Entreprise multi -sites, certains sites doivent communiquer avec dautres sites pour avoir accs certains services (comme laccs lextrieur ) IPBX
SIP Hardphone Switch Service de localisation Registrar Proxy SIP SBC
VPN
VPN
Internet
VPN
Switch SBC SIP Hardphones PSTN Service de localisation Registrar Portail PSTN Proxy SIP
IPBX
Switch SBC SIP Hardphones
Ce scenario est trs similaire au premier tudi. Toutes les communications au sein de lentreprise (quel que soit le site) sont gratuites, et il nest pas ncessaire que tous les sites dploient du matriel coteux pour profiter des diffrents services. De plus, si la communication inter-site est scurise, il ny a pas plus de risque que dans un cas mono-site. Mesures de base prendre pour scuriser ce scnario (voir 7) : IP Phones : S.01, S.02, S.07, S.06, S.10 ou S.11, (S.12 et/ou S.13) ou S.14 Rseau : S.03, S.04, S.05, S.08 IPBX : S.01, S.10 ou S.11, (S.12 et/ou S.13) ou S.14 SBC : S.15 Connexion inter-site : utiliser un VPN
7/56
2.3.4
Services supplmentaires
Le softphone, un tlphone SIP logiciel, est un lment problmatique quon peut trouver dans certains rseaux. Il a le dsavantage dobligatoirement lier le rseau VoIP avec le rseau de donns, et donc de rajouter toutes les vulnrabilits que lon peut trouver dans un PC. La mobilit va permettre un employ (tltravailleur) dutiliser le rseau tlphonique de lentreprise via internet depuis chez lui ou encore depuis un htel alors quil est en dplacement. Cette communication doit tre scurise, idalement via VPN. Des serveurs ENUM, de redirection, de prsence ou de confrence peuvent tre rajouts dans des rseaux afin daugmenter les fonctionnalits de la VoIP, ou permettre la messagerie instantane. Le voice-mail ou un systme de rponse interactive peut aussi tre rajout, mais ils ne sont pas ncessairement rajouts au systme VoIP. Il est possible pour un systme qui utilise toujours un PBX que ces services y soient connects. Les services tels que DNS, DHCP et NTP ne peuvent tre partags avec le rseau DATA. Ils doivent possder leurs propres serveurs sur le rseau VoIP (cf. p. 9 de [NsaGuid]). Des serveurs STUN ou TURN (ou les deux, cf. 4.5.2) peuvent tre utiliss pour traverser le firewall et le NAT. Ces serveurs se situent hors du rseau protg et risquent dintroduire de nouvelles vulnrabilits dans le rseau. De manire gnrale il est recommand davoir une certaine redondance. Ainsi il est possible quune entreprise dispose de plusieurs alternatives de transmission vers lextrieur, ou mme plusieurs providers en cas de problme. Cest aussi possible quune entreprise ait un gateway de secours en cas de panne pour pouvoir joindre les services durgence.
8/56
Principaux risques
DoS Attaques entranant l'indisponibilit d'un service/systme pour les utilisateurs lgitimes. Ecoute clandestine Attaques permettant d'couter l'ensemble du trafic de signalisation et/ou de donnes. Le trafic cout n'est pas modifi. Dtournement du trafic Attaques permettant de dtourner le trafic au profit de l'attaquant. Le dtournement peut consister rediriger un appel vers une personne illgitime ou inclure une personne illgitime dans la conversation. Identit Attaques bases sur la manipulation d'identit (usurpation, ). Vols de services Attaques permettant d'utiliser un service sans avoir rmunrer son fournisseur. Communications indsires Attaques permettant une personne illgitime d'entrer en communication avec un utilisateur lgitime.
L'numration suivante propose un premier niveau de classification des principaux risques connus lis l'utilisation de la VoIP en entreprise :
Le tableau ci-dessous dtaille ces risques avec la terminologie appropri. Il prcise dans la colonne de droite l'identifiant utilis au 6.1
Catgorie DoS
Sous-catgories
Mthode
Attaque
Interruption de la communication en cours Spoofed messages A.01 A.02 Empcher l'tablissement de la communication Spoofed messages A.03 Dgradation QoS A.04 A.05 A.06 Rendre la communication inaudible flux RTP parasite A.07 9/56
Epuisement de resources flooding A.08 A.09 Ecoute clandestine Conversation Reconstruction partir des paquets RTP A.10 Dchiffrement des paquets RTP A.11 Ajout d'un participant (INVITE) A.12 Obtention d'info. sur les proprits de la communication Sniffing de paquets SIP A.13 Obtention d'info. sur le contenu de la communication Rcupration du DTMF A.14 Dtournement du trafic d'appel Rerouting A.15 A.16 A.17 A.18 de signalisation Man in the Middle A.19 A.20 Identit Usurpation d'identit Spoofed messages A.21 Dissimulation d'identit A.22 Vols de services Tromper la taxation Tunneling RTP A.23 Usurpation d'identit A.24 Communications indsires Appel spam A.25 IM spam A.26 inscriptions dans la liste blanche A.27 10/56
Elments de scurit
La scurit de base contient des BP (en partie sous forme de liens vers des documents de rfrence) pas forcment spcifiques la VoIP qui permettent de partir sur une infrastructure saine La sparation des quipements DATA et VoIP permet elle seule de parer une grande partie des attaques, notamment les attaques concernant lcoute clandestine Lauthentification permet de sassurer de lidentit des interlocuteurs Le chiffrement doit garantir la confidentialit et lintgrit des donnes changes La scurit primtrique permet de protger le rseau VoIP de lentreprise face aux risques externes
Les mthodes de scurisation proposes s'appuient sur les lments suivants :
4.1 Scurit de base

4.1.1 Best Practices "scurit rseau"
La majorit des entreprises mettant en place une infrastructure VoIP choisissent un rseau IP converg (un mme rseau physique pour les donnes et la VoIP) pour des raisons conomiques et pratiques. Il est donc vident que la scurit de linfrastructure VoIP est fortement lie la scurit du rseau IP. Le document Network Infrastructure Security Technical Implementation Guide [DodNet] peut tre utilis comme rfrence pour scuriser un rseau IP, notamment le paragraphe 3.5 (Firewalls).
4.1.2
Scurit physique
La scurit physique est un des lments clefs permettant dobtenir une bonne scurit VoIP. Sa mise en uvre permet, entre autres, de diminuer fortement les risques dcoutes clandestines et les risques de DoS dus, par exemple, au dbranchement de lalimentation dun switch ou dun serveur. Laccs aux quipements rseaux (routers, switch,...) et aux serveurs VoIP devrait donc tre restreint aux seules personnes autorises. Les solutions choisies pour garantir la scurit physique dpendent du niveau de scurit requis (pices fermes clefs, lecteurs de cartes, biomtrie, gardes,). De plus, des mesures organisationnelles devraient tre prises de manire interdire aux employs de dconnecter un cble rseau (dun PC ou dun hardphone). En effet, un employ mal intentionn pourrait dconnecter son hardphone de manire connecter un ordinateur. Cet ordinateur se retrouverait donc connect au VLAN VoIP; ce qui est inadmissible (mme si laccs aux switches est scuris comme dcrit dans S.08). Sources : P. 5 de [NIST] & p. 34 3.2 de [DoD]
11/56
4.2 Sparation des quipements DATA et VoIP

La manire la plus efficace d'amliorer la scurit dun rseau VoIP est de sparer les quipements DATA des quipements VoIP en deux zones (DATA + VoIP) de scurit. Si le niveau de scurit requis est lev et que les moyens le permettent, il est recommand de subdiviser la zone VoIP en fonction des types dquipements VoIP (ex : zone serveurs VoIP, zone hardphones, zone softphones,). Cette sparation peut se faire de manire physique (deux rseaux physiquement indpendants avec switches spars) ou de manire logique. La sparation logique est souvent prfre pour des raisons budgtaires. En cas de prsence de softphones dans larchitecture, un VLAN softphones doit tre cr. Pour plus dinformations, concernant les zones de scurit pouvant tre mise en uvre, consulter les pages 2 et 3 de [NsaArch] Au 7, les solutions S.03 et S.04 permettent deffectuer une sparation logique des rseaux DATA et VoIP. Il est fortement conseill dappliquer ces deux solutions afin dobtenir une dfense en profondeur. Les solutions S.05, S.06, S.07, S.08 et S.09 permettent de prserver la sparation tablie grce S.03 et S.04.
4.2.1 Best Practices "Scurit du poste client" et notes sur les softphones
Ce paragraphe concerne les machines ayant un softphone car les softphones posent deux problmes majeurs ! Premirement, les softphones sont installs sur un Operating System (OS). Ces OS comportent des failles et de nouvelles vulnrabilits sont dcouvertes quotidiennement. La surface dattaque des softphones est donc beaucoup plus importante que celle des hardphones tant donn quelle est la somme de la surface dattaque du softphone et de celle de lOS. Le document Guide to securing Windows XP [NistXP] peut tre utilis comme rfrence pour scuriser un poste client Windows XP. Les principaux BP appliquer sont : Mise jour des patches de scurit de lOS (4.3 de [NistXP]) Politique de gestion des mots de passe (6.1 de [NistXP]) Installation dun anti-virus et mise jour rgulire de sa base de signature (8.5 de [NistXP])
De plus, ces softphones tant installs sur des machines (PC) relies au rseau DATA, la sparation prconise des rseaux DATA et VoIP devient difficile. Daprs les recommandations du [NIST], softphone systems should not be used where security or privacy is a concern . Si toutefois vous dcidez dintgrer des softphones dans votre architecture rseau, les best practices suivants sont recommands : S.09, S.10 ou S.11, (S.12 et/ou S.13) et S.14 voir 7
12/56
4.3 Authentification
Suite la sparation des quipements DATA et VoIP, lauthentification constitue le second point crucial pour la scurit. Plusieurs mthodes dauthentification sont possibles selon le niveau de scurit requis. La scurit minimale est obtenue en mettant en uvre une authentification HTTP Digest entre les IP phones et les serveurs VoIP. Cette mthode dauthentification est la plus rpandue et nest pas propritaire. Malheureusement, elle ne permet pas lauthentification mutuelle et est peu robuste face aux attaques offline de type brute force. Un meilleur niveau de scurit peut tre obtenu grce la mise en uvre dun protocole fournissant une authentification mutuelle (authentification de lIP Phone par le serveur et authentification du serveur par lIP Phone) tels que : SIPS IPSec protocoles propritaires
4.4 Chiffrement
Un chiffrement (partiel ou total) sera requis si la confidentialit des conversations l'exige. Plusieurs variantes peuvent tre mis en uvre : Note : Remarquons que l'coute est possible sur un rseau tlphonique classique (PBX PSTN) et que les risques dcoutes sont tout aussi importants que dans une entreprise mettant en uvre de la VoIP non chiffre. Le chiffrement des communications VoIP permet dobtenir un niveau de scurit (notamment en terme de confidentialit) bien suprieure un rseau tlphonique classique. Pour plus dinformations concernant les coutes clandestines sur le rseau tlphonique classique et sur la VoIP, consulter les pages 231-232 de [VoixSurIP]. Chiffrement des flux de signalisation (SIPS ou solution propritaire) Chiffrement des flux mdias (SRTP ou propritaire) IPSec
13/56
4.5 Scurit primtrique

La scurit primtrique concerne les quipements placs en bordure du rseau VoIP et permet de se protger contre les attaques externes.
4.5.1
SBC
est un dispositif plac en bordure de rseau
Prsentation Un SBC (Session Border Controller) sachant grer les flux VoIP.
Beaucoup de personnes comparent les SBC des firewalls VoIP-aware. Cependant les fonctionnalits quils offrent, bien que trs diffrentes suivant les marques, vont bien au-del du firewalling; par exemple : Call Admission Control Conversion de codec media Rcriture du trafic de signalisation Ouvrir sur le firewall les ports ncessaires aux communications VoIP NAT Traversal / STUN ALG
Architecture interne dun SBC Un SBC est compos de deux modules : Un module SBC Signalisation charg de contrler laccs des messages de signalisation VoIP au rseau Un module SBC Media charg de contrler laccs des paquets RTP au rseau. Ce module fait office de proxy RTP
Ces deux modules peuvent tre regroups dans un seul botier (single-box SBC) ou alors tre dans deux botiers spars (dual-box SBC). La solution single-box est plus simple mettre en uvre et devrait tre prfre pour les infrastructures VoIP de petite moyenne taille. La solution dual-box permet quand elle une plus grande souplesse dans son dploiement et permet de satisfaire aux besoins. Elle ncessite cependant la mise en uvre dun protocole tel que MEGACO/MGCP afin de permettre la communication entre le module SBC Signalisation (appel Call Agent dans la RFC de MGCP) et le(s) module(s) SBC Media (appel media gateway dans la RFC de MGCP). Avec ou sans firewall Etant donne qu'un SBC peut intgrer ou pas un firewall, il est conseill d'en ajouter un au besoin. Dans ce cas, il sera ncessaire de mettre en uvre un protocole tel que MEGACO/COPS pour la communication SBC - firewall ainsi que pour la configuration automatique du firewall.
14/56
4.5.2
STUN / TURN
STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators, RFC3489) est un protocole permettant aux applications de dcouvrir la prsence de firewalls+NAT entre elles et internet. Il permet aussi de dterminer quelle adresse IP publique a t alloue par le NAT. Cest un protocole de type client-serveur o une application, comme par exemple un softphone peut inclure un client STUN qui va envoyer des requtes un serveur STUN. Les rponses du serveur permettront au client NAT de dduire le type de NAT utilis ainsi que ladresse et le n de port qui lui auront t allous. TURN (Traversal Using Relay NAT) est un protocole permettant un lment situ derrire un NAT ou un firewall de recevoir des donnes entrantes. Dans les derniers drafts, TURN a t intgr STUN, devenant ainsi une nouvelle fonctionnalit de STUN. Son fonctionnement est lui aussi client-serveur; le client (inclus dans une application) fait une requte au serveur STUN, qui va lui rpondre ladresse par lequel il va pouvoir tre atteint (fonctionnement comme un relai de donnes).
15/56
Matrice attaques - solutions
Nous concluons par cette matrice qui synthtise la problmatique et met en relation les solutions de scurisation ( 7) avec les attaques potentielles ( 6). Pour l'utiliser : Colonnes de gauche = la liste des attaques, avec identifiant et nom. Partie suprieure = la liste des solutions, classes par type avec identifiant et nom. Une croix dans la matrice indique que lattaque est contre par la solution.
Pour une analyse plus dtaille : Cette matrice peut se lire de deux manires. Verticalement, elle permet de voir quelle(s) attaque(s) est(sont) contre(s). Horizontalement, elle permet de voir la(les) solution(s) approprie(s). Lgende
X X
La solution neutralise l'attaque. La solution couvre un des vecteurs de l'attaque. Cependant, d'autres vecteurs peuvent encore permettre de raliser l'attaque. La solution couvre l'attaque, mais il se peut qu'une personne se soit approprie des donnes d'authentification d'un utilisateur lgitime. Solution lie la solution comprenant une croix sa gauche.
(Matrice la page suivante)
16/56
Sparation rseaux DATA/VoIP
Auth. Chiffrement Scurit primtr.

S.18 Continuation de l'coute des rponses aprs la premire S.19 Limitation de la bande passante alloue par personne
S.01 Mise jour du logiciel (IPBX/softphone/hardphone)
S.16 Utilisation de serveurs ddis pour STUN
A.01 DoS SIP CANCEL A.02 DoS SIP BYE A.03 DoS SIP FAILURE
X X X X X X X
X X X X X X X
X X X X
X X X X
X X X X
X X X X X X X
DoS
A.04 QoS dgrad du rutilisation SSRC A.05 Injection de paquets RTP A.06 Modification du codec audio A.07 Rendre le flux audio inaudible A.08 Registration table overflow A.09 Proxy server flooding
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
X X
X X X X
X X X
X X
Ecoute clandestine
A.10 Physical eavesdropping A.11 Cassage de Cipher A.12 Re-INVITE / Session replay A.13 Suivi des appels (1) A.14 Suivi des appels (2) A.15 Hijacking thanks to registrar (1) A.16 Hijacking thanks to registrar (2) A.17 Hijack. registration by SIP REGISTER A.18 Hijacking registration A.19 Call redirection using 301/302 mess. A.20 Call redirection using 305 mess. A.21 Request spoofing A.22 Masquage d'appels
X X X
X X X X X X X X X X
Dtournement du trafic
X X X X
X X X X X X X
ID
Comm Vol Inds serv
A.23 Tromper la taxation A.24 Vol de service avec usurpation d'ident. A.25 Appel spam A.26 IM spam A.27 Presence spam X X X X X X X X X X X X X X X X X X
17/56
S.17 Vrification de lidentit du serveur STUN
S.12 Chiff. des flux de signalisation (SIPS,)
S.08 Scuriser l'accs aux ports des switchs
S.15 SBC : Call admission control / seuils
S.09 DMZ pour les services convergs
S.13 Chiff. des flux mdias (SRTP,)
S.07 Ports supp. : Dsact. ou 802.1q
S.10 HTTP Digest Authentication
S.14 Chiff. des flux (IPSec,)
S.11 Authentification mutuelle
BP Scurit du poste client
S.03 Sparation niveau 3
S.06 Carte rseau 802.1q
S.02 Verrouillage config.
S.05 Filtrage Inter-Vlan
S.04 Sparation VLAN
BP scurit rseau
Scurit Physique
Attaques potentielles
6.1 Liste des attaques

6.1.1 DoS en utilisant les messages de requte SIP CANCEL
Nom anglais : DoS using SIP CANCEL messages Identifiant : A.01 Source dattaque : LAN/VPN, externe avec SIP Cible : SIP But : impact sur la disponibilit Description : Cette attaque permet dannuler un appel entrant sur un terminal particulier ou dannuler un appel sortant initi par un terminal. Le message CANCEL est normalement utilis pour annuler une requte prcdemment envoye par un terminal. Lattaquant doit tout dabord couter le rseau afin de rcuprer un message de requte entre lappelant et lappel (la cible), en gnral un message INVITE si lon souhaite effectuer une attaque DoS. Aprs avoir analys le message afin de rcuprer suffisamment dinformations sur lappel, lattaquant peut faonner un faux message CANCEL et lenvoyer lappel afin dannuler le message INVITE. Aucun des deux partis ne peut placer dappel et le dessein de lattaquant a t accompli. Il est toutefois bon de remarquer que le message CANCEL na aucun effet sur une requte que lUAS (lappel) a dj accepte. Malgr tout, un message INVITE met un certain temps pour gnrer une rponse, ce sont donc des cibles faciles pour lattaque dcrite ci-dessus, puisque lattaquant a du temps pour analyser le message INVITE et faonner le message CANCEL. Ralisation : Lattaquant doit tre capable dcouter le rseau afin de reprer un message dinitialisation dune connexion SIP. Il doit aussi tre capable dinsrer un message CANCEL juste aprs la rception du message INVITE par la cible. Sources : Secure IP Telephony using Multi-layered Protection Brennen Reynolds and Dipak Ghosal Department of Computer Science - University of California http://www.isoc.org/isoc/conferences/ndss/03/proceedings/papers/3.pdf (Dernire visite le 11 mai 2006) RFC 3261 - SIP: Session Initiation Protocol
18/56
6.1.2
DoS en utilisant les messages de requte SIP BYE
Nom anglais : DoS using SIP BYE messages Identifiant : A.02 Source dattaque : LAN/VPN, externe avec SIP Cible : SIP But : impact sur la disponibilit Description : Cette attaque permet de couper une communication existante entre deux terminaux. Le message de requte BYE est normalement utilis pour terminer une session tablie par SIP. Lattaquant doit tout dabord couter le rseau afin de rcuprer un message de requte entre lappelant et lappel. Aprs avoir analys le message afin de rcuprer suffisamment dinformations sur la communication en cours, lattaquant peut faonner un faux message BYE et lenvoyer soit lUAC (lappelant), lUAS (lappel) ou les deux afin de terminer la communication. Le dessein de lattaquant a t accompli et les deux partis doivent effectuer un nouvel appel. Ralisation : Lattaquant doit tre capable dcouter le rseau afin de reprer un message dinitialisation dun appel. Il doit aussi tre capable dinsrer un message CANCEL juste aprs la rception du message INVITE par la cible. Sources : Secure IP Telephony using Multi-layered Protection Brennen Reynolds and Dipak Ghosal Department of Computer Science - University of California http://www.isoc.org/isoc/conferences/ndss/03/proceedings/papers/3.pdf (Dernire visite le 11 mai 2006) RFC 3261 - SIP: Session Initiation Protocol
6.1.3 (4xx)
DoS en utilisant les messages de rponse SIP FAILURE
Nom anglais : DoS using SIP FAILURE (4xx) messages Identifiant : A.03 Source dattaque : LAN/VPN, externe avec SIP Cible : SIP But : impact sur la disponibilit
19/56
Best Practice - Scurit VoIP Description : Cette attaque permet dempcher un appel daboutir. Les messages de rponse SIP Request Failure (4xx) sont normalement utiliss pour rpondre un message de requte SIP lorsque quelque chose ne sest pas pass correctement. Il faut noter que les rponses 4xx sont des rponses dfinitives dun serveur et le client ne devrait pas ressayer la mme requte sans une modification. Lattaquant doit tout dabord couter le rseau afin de rcuprer un message de requte entre lappelant et lappel (un message de requte de type INVITE serait le meilleur candidat pour ce genre dattaque). Aprs avoir analys le message afin de rcuprer suffisamment dinformations sur la communication qui va prendre place, il peut faonner un faux message de rponse 404 (Not Found) ou 410 (Gone) ou nimporte quel autre code possible (mais les messages 404 et 410 sont de bons exemples) et lenvoyer lUAC (lappelant) avant que lUAS (lappel) ait une chance de rpondre au message de requte SIP initial. Le dessein de lattaquant a t accompli et la communication ne peut prendre place puisque lUAC pense que lUAS nexiste pas (ou plus). Note : Des attaques similaires en utilisant des messages du type 5xx (Server failures) ou 6xx (Global failures) sont possibles. Ralisation : Lattaquant doit tre capable dcouter le rseau afin de reprer un message dinitialisation dune connexion SIP. Il doit aussi tre capable dinsrer un message FAILURE juste aprs la rception du message INVITE par la cible. Sources : Secure IP Telephony using Multi-layered Protection Brennen Reynolds and Dipak Ghosal Department of Computer Science - University of California http://www.isoc.org/isoc/conferences/ndss/03/proceedings/papers/3.pdf (Dernire visite le 11 mai 2006) RFC 3261 - SIP: Session Initiation Protocol
6.1.4
Perte de performance QoS en rutilisant la SSRC de RTP
Nom anglais : Drop of QoS Performance by reusing RTPs SSRC Identifiant : A.04 Source dattaque : LAN/VPN Cible : RTP But : impact sur la disponibilit Description : Cette attaque a pour but dutiliser une SSRC (synchronization source, source de synchronisation) dj existante afin de provoquer une perte dans la performance QoS (qualit de service).
20/56
Best Practice - Scurit VoIP Lattaquant devra tout dabord connatre la SSRC utilise par lappelant dune communication RTP mise en place par deux utilisateurs lgitimes en coutant le trafic RTP. Ensuite, lattaquant devra forger un paquet RTP en utilisant la mme SSRC afin de crer des collisions et ainsi une perte dans les performances QoS, car lappel devra dtecter la collision. Ralisation : Lattaquant doit tre capable dcouter le rseau afin de reprer une communication et ainsi savoir quel est la SSRC utilise. Sources : RFC 1889 - RTP: A Transport Protocol for Real-Time Applications RFC 3261 - SIP: Session Initiation Protocol
6.1.5
Injection de paquets RTP
Nom anglais : RTP packet injection Identifiant : A.05 Source dattaque : LAN/VPN Cible : Serveur registrar But : impact sur la disponibilit Description : Cette attaque a pour but de perturber une communication en cours. Lattaquant devra tout dabord couter un flux RTP de lappelant vers lappel, analyser son contenu et faonner un paquet RTP contenant un en-tte similaire mais avec un plus grand numro de squence et timestamp afin que ce paquet soit reproduit avant les autres paquets (sils sont vraiment reproduits). Ainsi la communication sera perturbe et lappel ne pourra pas se drouler correctement. Ralisation : Lattaquant doit tre capable dcouter le rseau afin de reprer une communication et ainsi reprer les timestamp des paquets RTP. Il doit aussi tre capable dinsrer des messages RTP forgs ayant un timestamp modifi. Sources : RFC 1889 - RTP: A Transport Protocol for Real-Time Applications RFC 3261 - SIP: Session Initiation Protocol
6.1.6
Modification du codec audio
Nom anglais : Audio codec modification Identifiant : A.06 Source dattaque : LAN/VPN
21/56
Best Practice - Scurit VoIP Cible : RTP / Terminaux : soft/hard phones But : impact sur la disponibilit et lintgrit des donnes Description : Cette attaque a pour but dutiliser labsence de contrle du flux mdia afin de changer certains de ses paramtres et crer plus de trafic que dsir. Lattaquant va profiter de la ccit de SIP par rapport au flux mdia, puisquil peut tre modifi sans que SIP soit au courant de ces changements. Ceci a pour rsultat quune interruption de la conversation ne sera pas (mais devrait tre) dtect par les proxies. Un changement de codec pourrais avoir comme rsultats lutilisation de plus gros paquets et donc dutiliser plus de bande passante et affamer les autres communications. Ralisation : Lattaquant doit tre capable de reprer un flux mdia et de le modifier. Sources : RFC 1889 - RTP: A Transport Protocol for Real-Time Applications
6.1.7
Rendre le flux audio inaudible
Nom anglais : Identifiant : A.07 Source dattaque : LAN/VPN Cible : RTP / Terminaux : soft/hard phones But : impact sur la disponibilit et lintgrit des donnes Description : Une communication lgitime est tablie entre les deux interlocuteurs. Lattaquant va envoyer un flux RTP parasite charg de se superposer au flux RTP lgitime. Pour ce faire, lattaquant doit avoir sniff le rseau afin de connatre le port UDP utilis par le flux RTP ainsi que le codec audio utilis. Une fois ses valeurs connues, il suffit dutiliser un logiciel tels que JM Studio [JMF] afin denvoyer le flux RTP parasite. Ralisation : Lattaquant doit tre capable de rcuprer le port UDP et le codec utilis par le flux RTP rendre inaudible. Sources : RFC 1889 - RTP: A Transport Protocol for Real-Time Applications
6.1.8
Dbordement de la table des enregistrements
Nom anglais : Registration table overflow Identifiant : A.08 Source dattaque : LAN/VPN, externe avec SIP Cible : SIP
22/56
Best Practice - Scurit VoIP But : impact sur la disponibilit Description : Cette attaque a pour but de provoquer un dbordement de la table des enregistrements afin dempcher les utilisateurs lgitimes de senregistrer sur le serveur registrar. Lattaquant envoie un grand nombre de messages de requte REGISTER (avec des URIs diffrentes) au serveur des enregistrements afin de remplir la table des enregistrements et ainsi empcher les utilisateurs lgitimes de senregistrer et dutiliser le service. Ralisation : Lattaquant doit tre capable denvoyer des messages denregistrement au serveur registrar. Sources : RFC 1889 - RTP: A Transport Protocol for Real-Time Applications
6.1.9
Inondation du serveur proxy
Nom anglais : Proxy server flooding Identifiant : A.09 Source dattaque : LAN/VPN Cible : SIP But : impact sur la disponibilit Description : Cette attaque a pour but dinonder les serveurs proxy avec des messages INVITE afin dempcher les utilisateurs lgitimes de placer des appels. Lattaquant envoie un gros volume de messages INVITE un proxy, qui doit normalement les transfrer vers le destinataire. Le problme est que le nombre de sessions concurrentes supportes par un serveur proxy est limit, les ressources sont donc rapidement puises, ce qui a pour consquence que les appels placs par des utilisateurs lgitimes en utilisant le proxy victime ne peuvent prendre place. Ralisation : Lattaquant doit tre capable dcouter le rseau afin de reprer un message dinitialisation dune connexion SIP. Il doit aussi tre capable dinsrer un message FAILURE juste aprs la rception du message INVITE par la cible. Sources : Security Considerations Jeremy George SIP.edu Cookbook http://mit.edu/sip/sip.edu/security.shtml (Dernire visite le 12 mai 2006)
23/56
6.1.10 Ecoute clandestine physique

Nom anglais : Physical eavesdropping Identifiant : A.10 Source dattaque : LAN/VPN, externe avec SIP Cible : RTP / Terminaux : soft/hard phones But : impact sur la confidentialit des donnes Description : Cette attaque a pour but dcouter ou denregistrer une conversation en cours. Lattaquant gagne laccs au rseau physique et utilises des outils pour espionner directement sur les cbles. Il peut le faire entre un UA et le switch ou entre deux switches. Il peut ensuite rejouer le contenu des paquets. Ralisation :
Lattaquant doit avoir un accs physique aux cbles rseau et tre capable dcouter le trafic. RFC 1889 - RTP: A Transport Protocol for Real-Time Applications
Sources :
6.1.11 Cassage de cipher

Nom anglais : Cipher breakage Identifiant : A.11 Source dattaque : LAN/VPN, externe avec SIP Cible : RTP / Terminaux : soft/hard phones But : impact sur la confidentialit des donnes Description : Cette attaque a pour but de connatre le contenu dun paquet en le dchiffrant. Ecouter les messages de signalisation SIP afin de rcuprer la cl DES (champ k) afin de pouvoir par la suite dchiffrer le contenu des paquets audio crypts avec le cipher et ainsi connatre le contenu de la conversation. Ralisation : Lattaquant doit tre capable dcouter le rseau et rcuprer des conversations chiffres ainsi que les messages SIP contenant la cl DES. Il doit aussi avoir une mthode pour tenter de dcrypter les messages. Mthodes de scurisation :
Utiliser un cipher plus fort. RFC 1889 - RTP: A Transport Protocol for Real-Time Applications
Sources :
24/56
6.1.12 Re-INVITE / Rptition de session Mid Session tricks

Nom anglais : Re-INVITE / Session Replay Mid Session tricks Identifiant : A.12 Source dattaque : LAN/VPN Cible : SIP But : impact sur la confidentialit, la disponibilit et lintgrit des donnes Description : Cette attaque a pour but denregistrer un appel ou modifier les paramtres de configuration dun appel. Lattaquant doit tout dabord couter le rseau et rcuprer un message INVITE entre un appelant et un appel. Il peut ensuite introduire un message INVITE faonn dans la conversation en cours de telle manire ce que les paramtres soient pris en compte (par exemple les paramtres de routage) et quun troisime parti soit introduit dans la conversation, par exemple pour faciliter lenregistrement de la conversation. Ralisation : Lattaquant doit pouvoir couter les messages SIP et en insrer des forgs. Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.13 Suivre des appels (1)

Nom anglais : Call Tracking (1) Identifiant : A.13 Source dattaque : LAN/VPN Cible : Terminaux : soft/hard phones But : impact sur la confidentialit des donnes Description : Cette attaque a pour but de connatre qui est en train de communiquer, quel est le timing et la longueur de la communication. Lattaquant doit rcuprer les messages INVITE et BYE en coutant le rseau et peut ainsi savoir qui communique, quelle heure et pendant combien de temps. Ralisation : Lattaquant doit tre capable dcouter le rseau et rcuprer les messages INVITE et BYE. Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.14 Suivre des appels (2)

Nom anglais : Call Tracking (2) 25/56
Best Practice - Scurit VoIP Identifiant : A.14 Source dattaque : LAN/VPN, externe avec SIP Cible : RTP / Terminaux : soft/hard phones But : impact sur la confidentialit des donnes Description : Cette attaque interlocuteurs. a pour but de capturer des informations sensibles sur les
Le but de lattaque est de rcuprer le DTMF (Dual Tone Multi Frequency) parmi lensemble du trafic vocal. Cela permettra lattaquant de rcuprer des informations qui peuvent aller des informations concernant la bote vocale (numro de tlphone, numro de la bote vocale, mot de passe) aux informations sur les cartes dappels voir mme des numros de carte de crdit. Toutes informations passes via DTMF peuvent tre rcupres par ce moyen. Ralisation : Lattaquant doit tre capable dcouter le rseau et rcuprer paquets RTP de la communication. La cible doit aussi tre en train dutiliser les tonalits DTMF sur quelque chose dintressant (mots de passes, etc.). Sources : VoIP - The Next Generation of Phreaking - Revision 1.1 Ofir Arkin - @stake http://blackhat.com/presentations/win-usa-02/arkin-winsec02.ppt (dernire visite le 15 mai 2006)
6.1.15 Dtournement dappel laide du serveur registrar (1)

Nom anglais : Call hijacking helped by the registrar server (1) Identifiant : A.15 Source dattaque : LAN/VPN Cible : Serveur registrar But : impact sur la confidentialit Description : Cette attaque a pour but de dtourner un appel en altrant les liaisons du serveur registrar. Lattaquant profite du rle du serveur registrar dans le systme tout dabord en rcuprant les liaisons dune URI particulire afin de rcuprer la liste des adresses lui correspondant. Ensuite, il va associer son URI avec tous les enregistrements corrects dans un message de requte REGISTER et en stipulant ces enregistrements une priorit plus leve en utilisant le paramtre q . Ce paramtre indique une prfrence relative pour ce champ Contact particulier par rapport aux autres liaisons pour cette adresse denregistrement. Ceci a pour consquence que le dessein de lattaquant a abouti car son URI sera utilise la place de celle de lutilisateur lgitime. 26/56
Best Practice - Scurit VoIP Ralisation : Lattaquant doit tre capable denvoyer et recevoir des donnes du serveur registrar. Il doit aussi tre capable de forger des requtes REGISTER truques. Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.16 Dtournement dappel laide du serveur registrar (2)

Nom anglais : Call hijacking helped by the registrar server (2) Identifiant : A.16 Source dattaque : LAN/VPN Cible : Serveur registrar But : impact sur la confidentialit et la disponibilit Description : Lattaquant profite du rle du serveur registrar dans le systme tout dabord en rcuprant les liaisons dune URI particulire afin de rcuprer la liste des adresses lui correspondant. Ensuite, il va associer son URI avec tous les enregistrements corrects dans un message de requte REGISTER et en stipulant ses enregistrements une priorit plus faible en utilisant le paramtre q . Ce paramtre indique une prfrence relative pour ce champ Contact particulier par rapport aux autres liaisons pour cette adresse denregistrement. Ensuite, lattaquant va effectuer une attaque DoS sur tous les enregistrements ayant une priorit plus leve afin que le proxy ne puisse pas leur envoyer de message et passe automatiquement lentre suivante, par exemple celles qui ont une priorit plus faibles (celles de lattaquant). Ralisation : Lattaquant doit tre capable denvoyer et recevoir des donnes du serveur registrar. Il doit aussi tre capable de forger des requtes REGISTER truques. Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.17 Dtournement de lenregistrement en faonnant des messages SIP REGISTER

Nom anglais : Registration hijacking by forging SIP REGISTER requests Identifiant : A.17 Source dattaque : LAN/VPN Cible : SIP / Serveurs registrar But : impact sur la confidentialit, la disponibilit et lintgrit des donnes Description :
27/56
Best Practice - Scurit VoIP Cette attaque a pour but de rediriger les appels vers lattaquant en sabotant le serveur registrar. Lattaquant doit tout dabord couter le rseau afin de rcuprer un message du type REGISTER. Ensuite, aprs avoir analys ce message, il peut faonner un message REGISTER et se renregistrer auprs du serveur registrar avec une nouvelle URI pour la victime. Ceci ayant comme rsultat de rediriger tous les appels entrants qui seront envoys vers la nouvelle URI (p.ex. celle de lattaquant) permettant ainsi lattaquant de plagier la cible de lattaque et ainsi mener bien son dessein. Ralisation : Lattaquant doit pouvoir couter les messages SIP REGISTER, lanalyser et renvoyer un message REGISTER truqu au serveur regitrar. Sources : Secure IP Telephony using Multi-layered Protection Brennen Reynolds and Dipak Ghosal Department of Computer Science - University of California http://www.isoc.org/isoc/conferences/ndss/03/proceedings/papers/3.pdf (Dernire visite le 11 mai 2006) RFC 3261 - SIP: Session Initiation Protocol
6.1.18 Dtournement denregistrement

Nom anglais : Registration hijacking Identifiant : A.18 Source dattaque : LAN/VPN Cible : SIP / Serveurs registrar But : impact sur la confidentialit, la disponibilit et lintgrit des donnes Description : Cette attaque a pour but de rediriger les appels vers lattaquant en sabotant le serveur registrar. En rcuprant sur le rseau un message de requte REGISTER, lattaquant est capable de le modifier et den envoyer un nouveau dans lintervalle de temps originellement dfinie par le timestamps spcifi dans le message REGISTER dorigine mais avec le champ expires contenant la valeur 0 afin de supprimer les liaisons de lutilisateur lgitime. Ainsi, la victime ne pourra plus enregistrer son tlphone comme tant une adresse de contact convenable et tous les appels pour la victime seront redirigs vers lattaquant. Ralisation : Lattaquant doit pouvoir couter les messages SIP REGISTER, lanalyser et renvoyer un message REGISTER truqu au serveur registrar.
28/56
Best Practice - Scurit VoIP Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.19 Redirection dappel en utilisant des messages de rponse du type 301/302

Nom anglais : Call redirection using 301/302 response messages Identifiant : A.19 Source dattaque : LAN/VPN Cible : Terminaux : soft/hard phones But : impact sur la confidentialit Description : Cette attaque a pour but de rediriger le trafic de signalisation vers un parti qui nest pas lappel. Lattaquant doit tout dabord couter le rseau afin de rcuprer un message de requte du type INVITE entre lappelant et lappel. Ensuite, aprs avoir analys le message et rcupr suffisamment dinformations sur la communication qui va prendre place, il peut faonner un faux message de rponse du type 301 (Moved Permanently) ou 302 (Moved Temporarly) et lenvoyer lUAC (lappelant) avant que lUAS (lappel) ait eu le temps de rpondre au message de requte SIP original. Une fois que lUAC aura reu le message de rponse susmentionn, il effectuera une nouvelle tentative dappel ladresse mentionne par lattaquant. Le dessein de lattaquant aura donc abouti. Ralisation : Lattaquant doit tre capable dcouter le rseau et de rcuprer un message du type INVITE. Il doit aussi tre capable de forger des messages de rponse du type 301 ou 302 et de lenvoyer avant la rponse lgitime. Sources : Secure IP Telephony using Multi-layered Protection Brennen Reynolds and Dipak Ghosal Department of Computer Science - University of California http://www.isoc.org/isoc/conferences/ndss/03/proceedings/papers/3.pdf (Dernire visite le 11 mai 2006) RFC 3261 - SIP: Session Initiation Protocol
6.1.20 Redirection dappel en utilisant les messages de rponse du type 305

Nom anglais : Call redirection attack using 305 response messages Identifiant : A.20 Source dattaque : LAN/VPN 29/56
Best Practice - Scurit VoIP Cible : SIP But : impact sur la confidentialit, la disponibilit et lintgrit des donnes Description : Cette attaque a pour but de rediriger le trafic de signalisation, afin de le modifier, vers un serveur proxy corrompu. Les messages de rponses de redirection (3xx) sont envoys par les UAS et donnent normalement des informations sur la nouvelle localisation de lutilisateur ou sur un des services alternatifs susceptibles de satisfaire lappel (ce qui est le cas du code 305, indiquant que la ressource demande doit tre accde travers le proxy donn dans le champ Contact). Lattaquant doit tout dabord couter le rseau afin de rcuprer un message de requte SIP entre lappelant et lappel. Aprs avoir analys le message afin de rcuprer suffisamment dinformations, il peut faonner un message de rponse du type 305 et lenvoyer lexpditeur du message rcupr. Ce dernier devra ensuite faire transiter le trafic de signalisation travers le proxy spcifi et les messages de rponse prendront automatiquement le mme chemin. Le dessein de lattaquant aura abouti puisque le trafic de signalisation aura t redirig travers un proxy (probablement compromis) lui laissant ensuite la possibilit de modifier les paquets le traversant. Ralisation : Lattaquant doit tre capable dcouter le rseau et de reprer un message de signalisation dune communication en cours. Il doit aussi tre capable de faonner un message de redirection et de lenvoyer avant la rponse lgitime. Enfin, il doit tre capable de se comporter comme un proxy SIP, afin de faire croire au client quil discute bien avec le serveur lgitime. Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.21 Contrefaon de requte

Nom anglais :Request spoofing Identifiant : A.21 Source dattaque : LAN/VPN Cible : SIP / Terminaux : soft/hard phones But : impact sur la confidentialit, la disponibilit et lintgrit des donnes Description : Cette attaque a pour but de modifier lidentit de lexpditeur dun message afin de faire croire au destinataire dun appel quil parle un utilisateur lgitime alors quen fait il parle lattaquant
30/56
Best Practice - Scurit VoIP Lattaquant va tout dabord couter le rseau afin de rcuprer un message de requte soit du type REGISTER, soit du type INVITE et modifie certains champs contenus dans len-tte avant denvoyer ce faux message de requte. Ceci a pour consquence que lappel pense quil parle un utilisateur spcifique alors quen fait il parle lattaquant. Ainsi, la victime ne pourra plus enregistrer son tlphone comme tant une adresse de contact convenable et tous les appels pour la victime seront redirigs vers lattaquant. Ralisation : Lattaquant doit pouvoir couter les messages SIP REGISTER ou INVITE, lanalyser, le modifier et le rexpdier une fois truqu. Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.22 Masquage dappel

Nom anglais : Call masquerading Identifiant : A.22 Source dattaque : LAN/VPN, externe avec SIP Cible : SIP / Terminaux : soft/hard phones But : impact sur la disponibilit des donnes Description : Cette attaque a pour but de dissimuler lidentit de lappelant afin que lappel prenne lappel. Lappelant cache son identit afin que lappel ne puisse pas savoir qui appelle et rponde au tlphone. Ceci a pour consquence que lutilisateur peut tre expos des tlprospecteurs, des publicits enregistres, etc. Ralisation : Lattaquant doit pouvoir appeler la cible en masquant son numro de tlphone. Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.23 Tromper la taxation

Nom anglais :Billing fooling Identifiant : A.23 Source dattaque : LAN/VPN Cible : SIP / Terminaux : soft/hard phones But : impact sur lintgrit des donnes Description : Cette attaque a pour but de passer des appels gratuits. 31/56
Best Practice - Scurit VoIP Lattaquant et son complice vont mettre en place un schma o les messages SIP seront dissimuls lintrieur de messages RTP/RTCP. Le proxy SIP sera incapable de dtecter le trafic de signalisation (SIP), alors que le flux de mdia (RTP/RTCP) continuera de transiter. Le CDR (Call Detail Recording) ne sera pas excut et ainsi, les deux partis peuvent effectuer des appels tlphoniques gratuits. Ralisation : Les attaquants doivent tre capable de modifier les paquets RTP/RTCP quils senvoient afin dajouter des informations de signalisation (SIP). Sources : RFC 3261 - SIP: Session Initiation Protocol
6.1.24 Vol de service lutilisateur lgitime

Identifiant : A.24 Source dattaque : LAN/VPN Cible : SIP But : impact sur lintgrit Description :
en
utilisant
les
accrditations
de
Nom anglais : Theft of service using a legitimate clients credentials
Cette attaque a pour but deffectuer des appels gratuits en utilisant les informations dun utilisateur lgitime. Lattaquant doit tout dabord couter le rseau afin de rcuprer un message de requte REGISTER partant dun UAC et allant vers le serveur registrar. Aprs avoir analys le message rcupr, lattaquant envoie un message de rponse du type 301 (Moved Permanently) pour faire croire lutilisateur que le serveur registrar SIP a t dplac en lui donnant comme nouvelle adresse un de ses serveurs. Ainsi, lutilisateur va senregistrer sur le proxy illgitime de lattaquant qui pourra ainsi rcuprer les informations de lutilisateur lgitime et les utiliser. Ensuite, lattaquant pourra usurper lidentit de lutilisateur lgitime et effectuer des appels gratuits ou rediriger le trafic vers un serveur denregistrement. Ralisation : Lattaquant doit tre capable dcouter le rseau et de rcuprer un message du type REGISTER entre la cible et le serveur registrar. Il doit aussi tre capable denvoyer un message de redirection la cible avant la rponse lgitime et singer le fonctionnement du serveur registrar afin de rcuprer les informations de lutilisateur lgitime. Enfin, il doit tre capable dutiliser les informations rcupres illgitimement pour senregistrer sur le vrai serveur registrar et effectuer des appels gratuits. Sources : RFC 3261 - SIP: Session Initiation Protocol 32/56
6.1.25 Appel spam

Nom anglais :Spam call Identifiant : A.25 Source dattaque : LAN/VPN, externe avec SIP, externe Internet Cible : Terminaux : soft/hard phones But : impact sur lintgrit des donnes Description : Cette attaque a pour but de jouer un message prenregistr la personne dcrochant le combin. Ce type de spam est dfini comme tant une srie dessais dinitiation de session (par ex. des requtes INVITE), essayant dtablir une session de communication vocale. Quand lappelant dcroche le combin, lattaquant (spammeur) relaie son message travers le media temps rel. Ralisation : Lattaquant doit tre capable dappeler la victime. Sources : The Session Initiation Protocol (SIP) and Spam draft-rosenberg-sipping-spam-02 J. Rosenberg, C. Jennings, Cisco, J. Peterson, Neustar 6 Mars 2006; Expire le 7 septembre 2006 http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-02.txt (Dernire visite le 15 mai 2006)
6.1.26 IM (messagerie instantane) spam

Nom anglais :Instant messaging spam (SPIM) Identifiant : A.26 Source dattaque : LAN/VPN, externe avec SIP Cible : Terminaux : soft/hard phones But : impact sur lintgrit des donnes Description : Cette attaque a pour but de gnrer un grand nombre de messages instantans (souvent publicitaires) sur les terminaux des utilisateurs. Lattaquant envoie un grand nombre de messages instantans non sollicits, contenant le message que le spammeur dsire passer. Le spam est envoy en utilisant le message de requte SIP MESSAGE. Toutefois, nimporte quel autre message de requte qui affiche automatiquement du contenu sur lcran dun terminal utilisateur pourrait fonctionner. Par exemple les requtes INVITE avec de larges en-ttes Subject (car le champ Subject est parfois affich lutilisateur) ou des INVITE contenant des corps du type texte ou HTML.
33/56
Ralisation : Lattaquant doit tre capable denvoyer des SIP MESSAGES la cible, voir des INVITE. Sources : The Session Initiation Protocol (SIP) and Spam draft-rosenberg-sipping-spam-02 J. Rosenberg, C. Jennings, Cisco, J. Peterson, Neustar 6 Mars 2006; Expire le 7 septembre 2006 http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-02.txt (Dernire visite le 15 mai 2006)
6.1.27 Prsence spam

Nom anglais : Presence spam Identifiant : A.27 Source dattaque : LAN/VPN, externe avec SIP Cible : Terminaux : soft/hard phones But : impact sur lintgrit des donnes Description : Cette attaque a pour but de se mettre sur la liste blanche (liste damis) dun utilisateur afin de lui envoyer des messages instantans ou dinitier dautres formes de communication. Lattaquant envoie une grande quantit de messages de requte de prsence (par exemple des requtes SUBSCRIBE), dans lespoir dentrer dans la liste blanche ou la liste damis dun utilisateur afin de lui envoyer des messages instantans ou dinitier dautres formes de communication. Contrairement aux spam messages instantans, le spam de prsence ne transporte pas rellement de contenu dans le message, il joue uniquement sur la patience de lutilisateurs qui finira par accepter la requte et mettra lutilisateur sur la liste blanche afin de ne plus recevoir la demande. Lattaque peut aussi se faire en envoyant la demande un grand nombre dutilisateurs, afin de maximiser les chances davoir une personne acceptant la demande. Ralisation : Lattaquant doit tre capable denvoyer des requtes (par exemple du type SUBSCRIBE) la cible. Sources : The Session Initiation Protocol (SIP) and Spam draft-rosenberg-sipping-spam-02 J. Rosenberg, C. Jennings, Cisco, J. Peterson, Neustar 6 Mars 2006; Expire le 7 septembre 2006 http://www.ietf.org/internet-drafts/draft-ietf-sipping-spam-02.txt (Dernire visite le 15 mai 2006)
34/56
6.1.28 Dnis de service distribu contre une cible

Nom anglais : Distributed Deny of Service (DDoS) Identifiant : A.28 Source dattaque : LAN/VPN, Externe Internet Cible : Nimporte quel ordinateur sur le rseau (via clients STUN) But : impact sur la disponibilit Description : Cette attaque a pour but de lancer une attaque dnis de service distribu laide de STUN Lattaquant distribue un grand nombre de clients une MAPPED-ADDRESS truque qui pointe sur la cible. Cela va faire croire aux clients STUN que leurs adresses sont gales celles de la cible. Les clients vont ensuite donner cette adresse afin dy recevoir du trafic (par exemple, des messages SIP ou H.323). Tout ce trafic va donc se focaliser sur la cible. Lattaque peut ainsi crer une grosse surcharge de trafic sur la cible, surtout lorsquelle est utilise avec des clients qui utilisent STUN pour initialiser des applications multimdia. Ralisation : Lattaquant doit tre capable de renvoyer une rponse STUN truque aux clients, la place du serveur STUN lgitime. Sources : RFC 3489 : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) section 12.1.1
6.1.29 Museler un client

Nom anglais : Silencing a Client Identifiant : A.29 Source dattaque : LAN/VPN, Externe Internet Cible : Client STUN But : impact sur la disponibilit Description : Cette attaque a pour but dempcher le client de communiquer avec le serveur quil souhaitait atteindre. Dans cette attaque, lattaquant cherche empcher un utilisateur daccder un service activ par STUN (par exemple, un client utilisant STUN pour activer du trafic multimdia bas sur SIP). Pour ce faire, lattaquant renvoie au client une MAPPEDADDRESS truque ne pointant vers rien du tout. Ceci a comme rsultat que le client ne recevra jamais les paquets attendus lorsquil mettra vers la MAPPED-ADDRESS. Il est important de remarquer que cette attaque nest pas trs intressante pour lattaquant. Elle nimpacte quun seul client, qui nest bien souvent pas la cible dsire. De plus, si lattaquant peut effectuer cette attaque, il pourrait aussi faire un
35/56
Best Practice - Scurit VoIP dni de service sur la cible par dautres moyens, comme lempcher de recevoir des rponses du serveur STUN, voir du serveur DHCP. Ralisation : Lattaquant doit tre capable de renvoyer une rponse STUN truque aux clients, la place du serveur STUN lgitime. Sources : RFC 3489 : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) section 12.1.2
6.1.30 Se faire passer pour un client

Nom anglais : Assuming the Identity of a Client Identifiant : A.30 Source dattaque : LAN/VPN, Externe Internet Cible : Client STUN But : impact sur la confidentialit Description : Cette attaque a pour but de faire transiter les paquets des clients STUN par soi afin deffectuer des coutes clandestines. Lattaquant utilise la mme technique que pour lattaque ST.2, c'est--dire retourner une rponse STUN forge avec une MAPPED-ADDRESS choisie par lattaquant. Ici la diffrence est quau lieu de spcifier une adresse nexistant pas, il va spcifier sa propre adresse. Il va ainsi recevoir tous les paquets de la cible. Il lui suffit ensuite de rexpdier les paquets quil reoit vers le client lgitime. Cette attaque lui permet alors dobserver tous les paquets envoys au client. Toutefois, afin de lancer cette attaque, lattaquant doit dj avoir russi observer des paquets du client vers le serveur STUN. Dans la plupart des cas (par exemple lorsque lattaque est lance dun rseau daccs), cela veut dire que lattaquant pourrait dj observer les paquets envoys au client. Cette attaque peut donc tre utile pour observer le trafic par des attaquants sur le chemin du client vers le serveur STUN, mais gnralement pas sur le chemin des paquets routs vers le client. Ralisation : Lattaquant doit tre capable de renvoyer une rponse STUN truque aux clients, la place du serveur STUN lgitime. Sources : RFC 3489 : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) section 12.1.4
6.2 Remarques concernant les attaques lies STUN (tir de RFC3489 s. 12.2)
Il est important de noter que les attaques de cette nature (injection de paquets avec une MAPPED-ADDRESS fausse) demandent que lattaquant soit capable dintercepter les requtes envoyes du client au serveur (ou deffectuer une attaque Man in the middle) car les requtes STUN contiennent un identifiant de transaction, 36/56
Best Practice - Scurit VoIP choisi par le client, qui est un nombre alatoire avec 128 bits dentropie. Le serveur remet cette valeur dans ses rponses et le client ignorera toutes les rponses nayant pas une ID de transaction correspondant. Cest pourquoi, pour quun attaquant donne une rponse truque accepte par le client, il doit connatre lID de transaction de la requte. La grande varit de nombres alatoires ainsi que la ncessit de connatre quand le client va envoyer une requte empche toute attaque tentant de deviner lID de transaction. Nous allons maintenant regarder quelques mthodes permettant de rcuprer cet ID de transaction. Mthode # : 1 Compromettre un serveur STUN lgitime Dans cette attaque, lattaquant va compromettre un serveur STUN lgitime laide dun virus ou dun cheval de Troie. Ceci permettra alors au lattaquant de contrler le serveur STUN et de contrler le type de rponses quil va gnrer. Compromettre un serveur STUN de la sorte peut aussi permettre de dcouvrir les ports ouverts. Cette connaissance peut amener la possibilit de crer des attaques de dni de service sur ces ports (voir de dnis de service distribus si le NAT est du type full cone). Ceci ne reprsente toutefois pas une menace majeure car la dcouverte de ports ouverts est relativement triviale en sondant les ports. Mthode # : 2 Attaques DNS Les serveurs STUN sont dcouverts en utilisant les enregistrements DNS SRV. Si un attaquant peut compromettre le DNS, il peut injecter de faux enregistrements qui mappent un nom de domaine vers ladresse IP dun serveur STUN contrl par l'attaquant. Ceci permettra ensuite d'injecter de fausses rponses. Mthode # : 3 Routeur ou NAT espion Plutt que de compromettre le serveur STUN, un attaquant pourrait faire gnrer un serveur STUN des rponses avec une mauvaise MAPPED-ADDRESS en compromettant un routeur ou un NAT sur le chemin du client au serveur STUN. Lorsque la requte STUN passe travers le routeur ou NAT espion, il rcrit ladresse source du paquet afin quelle devienne celle de la MAPPED-ADDRESS dsire. Cette adresse ne peut pas tre arbitraire. Si lattaquant est sur Internet (publique), et lattaquant ne modifie pas la requte STUN, ladresse doit avoir la proprit que les paquets envoys du serveur STUN vers cette adresse seront routs travers le routeur compromis. Ceci car le serveur STUN enverra directement les rponses ladresse source de la requte STUN. Avec une adresse source modifie, le seul moyen pour quil puisse atteindre le client est que le routeur compromis les dirige au bon endroit. Toujours si lattaquant est sur Internet mais peut cette fois-ci modifier les requtes STUN, il peut insrer un attribut RESPONSE-ADDRESS dans la requte, contenant ladresse source de la requte STUN. Ceci aura comme action de faire que le serveur renvoie les rponses au client, indpendamment de ladresse source que le serveur STUN voit. Ceci donne la possibilit lattaquant de forger une adresse arbitraire lorsquil transfre la requte STUN. Si lattaquant est sur un rseau priv (c'est--dire quil y a des NATs entre lui et le serveur STUN), lattaquant ne pourra pas forcer le serveur gnrer des MAPPEDADDRESS arbitraires dans les rponses. Il pourra uniquement forcer le serveur STUN 37/56
Best Practice - Scurit VoIP gnrer des MAPPED-ADDRESS qui routeront vers le rseau priv. Ceci car le NAT entre lattaquant et le serveur STUN rcrira ladresse source de la requte STUN, la liant ladresse publique routant vers le rseau priv. Malheureusement, il est possible quun NAT de mauvaise qualit veuille mapper une adresse publique alloue une autre adresse publique (par opposition une adresse prive interne), dans ce cas lattaquant pourrait forger ladresse source dans une requte STUN qui pourrait tre une adresse publique arbitraire. Toutefois, ce genre de comportements est plutt rare pour un NAT. Mthode # : 4 Man In The Middle Comme alternative la mthode 3, si lattaquant arrive placer un lment sur le chemin du client au serveur, llment peut agir comme un man in the middle . Dans ce cas, il peut intercepter une requte STUN et gnrer une rponse STUN directement avec nimporte quelle valeur dsire pour le champ MAPPED-ADDRESS. Comme alternative, il peut transfrer la requte STUN au serveur (aprs quelques modifications), recevoir la rponse et la transfrer au client. Sil transfre cette adresse, elle a les mmes limitations que pour la mthode 3. Mthode # : 5 Injection de rponse plus DoS Dans cette approche, lattaquant na pas besoin dtre un man in the middle (comme pour les mthodes 3 et 4). Il a uniquement besoin de pouvoir couter le segment rseau qui transporte les requtes STUN. Ceci peut tre fait aisment dans des rseaux accs multiple comme Ethernet ou un rseau 802.11 non protg. Pour injecter une rponse fausse, lattaquant coute le rseau pour rcuprer une requte STUN. Lorsquil en voit une, il lance simultanment une attaque DoS sur le serveur STUN, et gnre sa propre rponse STUN avec la valeur MAPPED-ADDRESS dsire. La rponse STUN gnre par lattaquant va atteindre le client et lattaque DoS contre le serveur va empcher la rponse lgitime du serveur de joindre le client. Il peut tre discut que lattaquant puisse le faire sans tre oblig de faire un DoS sur le serveur, tant que la rponse fausse arrive avant la rponse lgitime chez le client, et que le client nutilise que la premire rponse. Mthode # : 6 Duplication Cette mthode est similaire la 5, lattaquant coute le rseau et rcupre une requte STUN. Lorsquil la vue, il gnre sa propre requte STUN vers le serveur. Cette requte est identique celle quil a vue, mais avec une adresse source truque. Cette adresse truque est gale celle que lattaquant dsire avoir place dans la MAPPED-ADDRESS de la rponse STUN. En fait, lattaquant gnre un flood de ce genre de paquets. Le serveur STUN va recevoir la requte originale, suivie dune inondation de paquets dupliqus fausss. Si cette inondation est suffisamment puissante pour congestionner les routeurs ou dautres quipements, il y a une bonne probabilit de chance pour que la vraie rponse se perde, et le rsultat sera que seules les rponses truques seront reues par le client STUN. Ces rponses sont toutes identiques et contiennent toutes la MAPPED-ADDRESS que lattaquant souhaitait que le client utilise. Comme pour la mthode 5, il est possible de ne pas avoir besoin de crer une inondation de paquets, pour autant que la rponse fausse arrive plus rapidement que la rponse relle vers le client, et que le client ignore la seconde rponse (bien quelle soit diffrente).
38/56
Best Practice - Scurit VoIP Il est bon de noter que dans cette approche, lancer une attaque DoS contre le serveur STUN ou le rseau IP, afin dempcher la rponse valide dtre reue ou envoye, est problmatique. Lattaquant a besoin davoir le serveur STUN accessible pour grer ses propres requtes. A cause de la retransmission priodique de la requte du client, ceci laisse une toute petite fentre dopportunit pour lattaque. Lattaquant doit dmarrer lattaque DoS immdiatement aprs la requte du client, afin dliminer la rponse correcte, puis arrter lattaque DoS afin denvoyer ses propres requtes, le tout avant la prochaine retransmission du client. A cause de lespacement trs petit des retransmissions (entre 100ms et quelques secondes), ceci est trs difficile faire. Outre les attaques DoS, il peut y avoir dautres faons dempcher la requte du client datteindre le serveur. Une manipulation la couche 2, par exemple, pourrait tre efficace.
39/56
Nos propositions de Best Practices
7.1 Scurit de base

7.1.1 Mise jour du software (IPBX, hardphone et softphone)
Identifiant : S.01 Description de la solution : LIPBX, les hardphones et les softphones contiennent tous un logiciel. Le code de ces logiciels peut contenir des failles (buffer overflow,) et donc tre vulnrable diverses attaques. Il est donc trs important de maintenir jour la version de ces logiciels, notamment lorsquune faille de scurit les concernant a t dcouverte. Pour ce faire, il faut : Consulter rgulirement les sites des fabricants hardware/logiciel des quipements introduit dans linfrastructure VoIP, ou mieux, tre inscrit leurs newsletters de manire tre automatiquement informs si une nouvelle version/patch est disponible Tester le patch sur des quipements de test Mettre jour les quipements de production si le test prcdent est concluant P. 6 de [NsaGuid]
Sources :
7.1.2
Verrouillage de (hardphone/softphone)
la
configuration
Identifiant : S.02 Description de la solution : Une fois le hardphone/softphone configur, il est important de verrouiller par mot de passe sa configuration afin dempcher quun utilisateur ne puisse modifier les paramtres (dsactiver lauthentification,). De plus, des mesures organisationnelles devraient tre prises de manire interdire aux employs toute modification de la configuration des quipements de linfrastructure VoIP. Disponibilit de la solution : Sur tout hardphone/softphone possdant une fonction de verrouillage Sources : p. 34 de [DoD]
40/56
7.2 Sparation des quipements DATA et VoIP

7.2.1 Sparation au niveau IP (layer 3)
Identifiant : S.03 Description de la solution : Cette solution consiste attribuer une plage dadresses IP (ex : 192.168.1.x) au rseau DATA. Ce rseau comprendra tous les quipements qui taient prsents avant lintroduction de la VoIP : postes clients, serveurs (fileserver, Domain Controller,), etc. Une plage dadresses IP diffrente quipements VoIP. (ex : 192.168.2.x) sera attribue aux
Une fois cette sparation effectue, il est possible de dfinir des ACL sur les quipements de Layer 3 (switches L3/routers/firewalls) afin de nautoriser les communications quentre les adresses IP autorises. De plus, si des services tels que DNS, DHCP ou NTP sont ncessaires, le rseau VoIP doit possder ses propres serveurs (cf. p. 9 de [NsaGuid]). Disponibilit de la solution : Disponible sur tout type de rseau Sources : p. 37 [DoD]
7.2.2
Sparation grce aux VLAN (layer 2)
Identifiant : S.04 Description de la solution : La deuxime tape de notre dfense en profondeur consiste dfinir un VLAN DATA ddi aux quipements rseaux prsents dans le rseau DATA et un VLAN VoIP ddi aux quipements VoIP. Afin dobtenir une meilleure sparation, il est conseill de crer la place du VLAN VoIP, un VLAN pour chaque catgorie dquipement VoIP comme : Les hardphones Les softphones Les serveurs
VLAN DATA VLAN VoIP VLAN VoIP Servers
VLAN VoIP Hardphones VLAN VoIP Softphones VLAN VoIP Servers
VLAN VoIP Hardphones VLAN VoIP Softphones
41/56
Best Practice - Scurit VoIP Cela permet dtablir des rgles de filtrage plus fines et damliorer la QoS. De plus, si une attaque survient sur le VLAN VoIP Softphone, cela naffectera pas le bon fonctionnement des autres systmes VLAN VoIP. Sil nest pas possible (pour des raisons de fonctionnalit notamment) dinterdire toute communication entre les VLAN DATA et VoIP, un filtrage Inter-VLAN (au niveau des switchs et/ou des routers) et/ou des firewalls doivent tre mis en place afin de filtrer rigoureusement le trafic entre les VLAN. Disponibilit de la solution : Switches possdant la fonctionnalit de VLAN. Sources : p. 38 de [DoD]
7.2.3
Filtrage Inter-VLAN
Identifiant : S.05 Description de la solution : Les communications entre les VLAN mis en place en S.04 doivent tre rigoureusement filtres de manire nautoriser que les flux ncessaires. Le filtrage doit tre de type liste blanche (seuls les flux dfinis sont autoriss). Ce filtrage peut tre effectu : en dfinissant des ACL sur les switches et/ou les routers interconnectant les VLAN en plaant un firewall entre les VLAN
Les rgles de filtrage devraient tre bases sur les adresses IP, les numros de ports/protocoles et les flags TCP/IP de manire tre le plus strict possible et nautoriser que les communications ncessaires. Par exemple, les IP Phones nont pas besoin denvoyer un flux mdia (ex : RTP) aux serveurs VoIP. Donc, au lieu dautoriser toutes communications entre les VLAN VOIP Hardphones/Softphones et le VLAN VoIP Servers, seul le trafic concernant le protocole de signalisation (ex : SIP) devraient tre autoris. Disponibilit de la solution : Switches/routers/firewalls permettant de crer des rgles de routage Inter-VLAN Sources : fig. 3 et p. 10 de [NsaGuid]
7.2.4
Utilisation dune carte rseau supportant 802.1Q
Identifiant : S.06 Description de la solution : Le principal danger lorsque lon installe un softphone sur un ordinateur provient du fait que cet ordinateur, dj connect au rseau DATA, devient un terminal VoIP, ce qui est contraire au best practice S.04. Il existe cependant une solution pour maintenir la sparation des VLANS. Cette solution consiste quiper les ordinateurs dune carte Ethernet supportant le protocole 802.1q et de les configurer pour utiliser ce protocole. De telles cartes
42/56
Best Practice - Scurit VoIP Ethernet permettent de sparer le trafic DATA du trafic VoIP (issue du softphone) en mettant chaque type de trafic dans leur VLAN respectif. LOS, la carte Ethernet et le softphone doivent supporter 802.1q. Disponibilit de la solution : Ordinateur et softphone disposant dune carte 802.1q Sources : p. 43 de [DoD]
7.2.5 Dsactivation ou protection (802.1q) des ports rseaux supplmentaires

Identifiant : S.07 Description de la solution : Certains hardphones possdent un (ou plusieurs) port afin de permettre la connexion dun ordinateur ou dun autre quipement rseau. Ce port additionnel a pour but de nutiliser quune seule prise rseau pour connecter plusieurs quipements : le hardphone fonctionne donc comme un hub. Le hardphone et lordinateur se retrouve donc tout deux sur le mme rseau/vlan ce qui est contraire au best practice S.04. La solution consiste dsactiver le(s) port(s) supplmentaire(s) ou activer le protocole 802.1q sur le hardphone. La sparation entre les rseaux/vlan DATA et VoIP est ainsi maintenue. Disponibilit de la solution : Hardphone supportant 802.1q. Sources : p. 39 de [DoD]
7.2.6
Scuriser laccs aux ports des switches (ACL,)
Identifiant : S.08 Description de la solution : La sparation tablit grce aux solutions S.03 et S.04 peut tre compromise si un individu la possibilit de connecter une machine un port dun switch. Afin dviter cela, les scurits suivantes peuvent tre mise en place (classes par ordre croissant defficacit) : les ports non utiliss devraient tre dsactivs les ports non utiliss devraient tre placs dans un VLAN inutilis une ACL (place au niveau du port ou du switch entier) devraient tre cre afin de nautoriser laccs quaux adresses MAC dfinies une authentification 802.1x devrait tre mise en place (si les switches et les IP phones le permettent)
La solution base sur les ACL est celle prconise. Note : Les quatre scurits numres sont cumulables
43/56
Best Practice - Scurit VoIP Disponibilit de la solution : Switches possdant une fonction de filtrage par adresse MAC. Switches et IP phones permettant la mise en uvre de 802.1x. Sources : P. 9 de [NsaGuid] P. 40 3.5.2.2 de [DoD]
7.2.7
Placer les services convergs dans une DMZ
Identifiant : S.09 Description de la solution : Afin de ne pas compromettre la sparation des VLAN DATA et VoIP, les services convergs (services ncessitant un accs au VLAN DATA et au VLAN VoIP) doivent tre placs dans une DMZ. Les rgles du firewall doivent tre le plus strict possible afin de nautoriser que les flux ncessaires.
VLAN DATA VLAN VoIP VLAN VoIP Servers
VLAN VoIP Hardphones VLAN VoIP Softphones VLAN VoIP Softphones
DMZ Services convergs
Disponibilit de la solution : Firewall mis en place entre les VLAN Sources : p. 10 de [NsaGuid]
44/56
7.3 Authentification
7.3.1 Authentification HTTP Digest des messages SIP
Identifiant : S.10 Description de la solution : HTTP Digest Authentication permet au serveur dauthentifier les messages SIP REGISTER et/ou INVITE envoys par un IP Phone. Les attaques bases sur lusurpation didentit du client ne sont alors plus possibles (pourvu que la politique de gestion des mots de passes soit efficace). La mise en place de cette authentification ncessite de configurer HTTP Digest : sur le registrar sur les IP Phones dfinir le domaine dauthentification saisir le mot de passe (secret partag entre le registrar et lIP Phone)
Cette configuration consiste gnralement :
Cette mthode dauthentification tant sensible aux attaques offline de type brute force, il est recommand de dfinir une politique de mots de passes imposant la complexit et une longueur minimale au mot de passe. Disponibilit de la solution : IP phones et registrar supportant lauthentification HTTP Digest des messages SIP Sources : p. 42-43 de [NsaGuid] [Master]
7.3.2
Authentification mutuelle
Identifiant : S.11 Description de la solution : Lauthentification mutuelle permet au serveur dauthentifier le client et au client dauthentifier le serveur. Les attaques bases sur lusurpation didentit ne sont alors plus possibles. Les mthodes dauthentification mutuelles suivantes peuvent tre mise en uvre : SIPS H.235 pour H.323 Protocoles propritaires
La mise en place dune mthode dauthentification mutuelle ncessite de configurer la mthode choisie : sur lIPBX sur les IP Phones
45/56
Disponibilit de la solution : IPBX et IP Phones supportant au moins une mthode dauthentification mutuelle en commun. Sources : p. 42-43 de [NsaGuid]
46/56
7.4 Chiffrement
7.4.1 Chiffrement du flux de signalisation : SIPS,
Identifiant : S.12 Description de la solution : Le chiffrement du flux de signalisation permet de garantir la confidentialit et lintgrit des donnes changes. Les coutes clandestines sur ce type de flux sont donc prvenues. Les protocoles pouvant tre mis en uvre sont : SIPS (en remplacement de SIP) Protocoles propritaires
Il est toutefois important de remarquer que le chiffrement du flux va introduire un overhead. Cet overhead peut devenir important pour les serveurs VoIP si le nombre dappels simultans devient important. Il est donc important de tester la charge gnre par la mise en place du chiffrement de manire connatre les limites de linfrastructure VoIP et permettre de dimensionner les quipements VoIP. Concernant SIPS : SIPS est bas sur TLS. Lintgrit des donnes est garantie grce aux MACs (Message Authentification Code) bas sur les fonctions de hachage MD5 (16 octets) ou SHA-1 (20 octets). Il fournit, en plus du chiffrement, selon la configuration : lauthentification simple (serveur authentifi auprs de lIP Phone) lauthentification mutuelle entre les serveurs et les IP Phones.
Lauthentification des entits est base sur le protocole X.509, et elle a lieu durant la phase dhandshake de TLS. Cest aussi durant cette phase que sont ngocis les algorithmes utiliss (cypher et MAC) ainsi que la gnration de la cl symtrique de session pour le chiffrement des donnes. Le diagramme en flche suivant dtaille les principaux changes lors dun handshake TLS.
47/56
Disponibilit de la solution : Serveur et IP Phones supportant au moins une mthode de chiffrement du flux de signalisation en commun. Sources : P. 42-43 de [NsaGuid]
7.4.2
Chiffrement du flux mdia : SRTP,
Identifiant : S.13 Description de la solution : Le chiffrement du flux mdia permet de garantir la confidentialit et lintgrit des donnes changes. Les coutes clandestines sur ce type de flux sont donc prvenues. De plus, ce chiffrement fournit lauthentification mutuelle entre les IP Phones. Les protocoles pouvant tre mis en uvre sont : SRTP (en remplacement de RTP) H.235 pour H.323 Protocoles propritaires
Il est important de noter que le chiffrement du flux va introduire un overhead, ce qui peut nuire la qualit de la conversation. En effet, les flux temps rels comme 48/56
Best Practice - Scurit VoIP laudio sont trs sensibles aux dlais de temps (time delay) ainsi quaux variations de dlais (gigue ou jitter). Il faut donc tester que loverhead engendr par lalgorithme de chiffrement soit tolrable (par tolrable, on sous-entend que loverhead ne dgrade pas trop la qualit de la conversation). Concernant SIP (et plus prcisment, RTP) : Le protocole SRTP (Secured Real-Time Transport Protocol) est une extension du protocole RTP qui fournit la confidentialit, lauthentification et une protection contre la rptition aux trafics RTP et RTCP. Lutilisation dAES (Advanced Encryption Standard) en mode stream cipher garanti une bonne scurit tout en naugmentant pas la taille de la cargaison chiffre. Le tag dauthentification utilis pour vrifier lintgrit des donnes ajoute 10 octets chaque paquet RTP/RTCP mais peut tre rduit 4 octets si la transmission doit tre effectu sur un canal de communication lent. RTP et RTCP peuvent donc tre scuriss de manire cryptographique respectivement par SRTP et SRTCP (Secured Real-Time Transport Control Protocol) tout en ne provoquant pas de problmes significatifs sur la qualit de la transmission. Voici le format dun paquet SRTP :
On peut voir facilement que seul le corps de cargaison RTP est chiffr. Le champ MKI est optionnel et permet didentifier la cl primaire depuis laquelle les autres cls de sessions sont drives. Le MKI peut tre utilis par le rcepteur pour retrouver la cl primaire correcte lorsque le besoin dun renouvellement de cl survient. Le numro de squence sur 16 bits est utilis de manire simultane avec le compteur de rollover (Rollover Counter) de 32 bits qui se trouve tre une partie du contexte cryptographique, pour la session SRTP, afin de se prmunir contre les replay attacks.
49/56
Best Practice - Scurit VoIP Le tag dauthentification est un checksum cryptographique (HMAC SHA-1) calcul sur lentte et le corps du paquet RTP. Son utilisation permet de prmunir les messages contre une modification non autorise. La longueur par dfaut du tag est de 10 octets mais peut tre rduit si le canal de transmission ne permet pas une grande augmentation de la taille des paquets RTP. La scurisation des paquets RTCP se fait de manire similaire celle de RTP. Lunique diffrence est lobligation dutiliser le tag dauthentification afin dviter un attaquant de terminer un flux mdia RTP en envoyant un message SIP BYE. Disponibilit de la solution : IPBX et IP Phones supportant au moins une mthode de chiffrement du flux media en commun. Sources : P. 42-43 de [NsaGuid] Advanced Encryption Standard Wikipedia, the free encyclopedia Version du 18 mai 2006 http://en.wikipedia.org/wiki/Advanced_Encryption_Standard (Dernire visite le 19 mai 2006)
7.4.3
Chiffrement avec IPSec (ou autre technologie VPN)
Identifiant : S.14 Description de la solution : Le chiffrement des flux avec IPSec (ou une autre technologie VPN) permet de garantir la confidentialit et lintgrit des flux changs. Lauthentification mutuelle des protagonistes est galement assure. Les protocoles pouvant tre mis en uvre sont : IPSec Autre technologie VPN
Il est important de noter que le chiffrement du flux va introduire un overhead. Il faut donc tester que cette overhead est tolrable avant de mettre en uvre un VPN. Concernant SIP (et plus prcisment SIP protg par IPSec) : IPSec est un mcanisme gnral pouvant tre utilis pour protger les messages SIP au niveau IP. Avec SIP, chaque proxy sur le chemin doit avoir accs en lecture/criture sur lentte des messages SIP afin de pouvoir ajouter/retirer des enttes VIA. Afin de permettre lutilisation dIPSec ESP (Encapsulating Security Payload) ou AH (Authentification Header), son fonctionnement doit tre bas sur un mode Hop-By-Hop. IPSec est bas sur un assortiment de mcanismes protgeant les donnes changes sur le rseau. Il fonctionne la couche IP et traite tous les paquets IP. Ainsi, il protge toutes les applications et peut tre implment dans tous les appareils utilisant le rseau de manire point point voir lien lien. Son but est donc dviter lespionnage du flux de donnes et laccs illicite aux ressources. Il permet de garantir la confidentialit et lauthenticit des donnes 50/56
Best Practice - Scurit VoIP changes. Il fournit galement une protection contre les replays-attacks. Il est bon de remarquer quil permet un haut niveau de protection sil est utilis avec des algorithmes forts et dans un environnement scuris. Ces fonctionnalits sont fournies par des mcanismes cryptographiques : Message Authentication Code (MAC) = Authenticit des donnes Chiffrement des donnes = Confidentialit des donnes Numro de squence = protection contre les replays-attacks AH (Authentification datagrammes IP Header) qui permet dassurer lauthenticit des
Ces mcanismes sont implments laide de deux extensions du protocole IP :
ESP (Encapsulating Security Payload) qui assure la confidentialit des donnes et/ou leur authenticit
AH et ESP peuvent fonctionner avec plusieurs algorithmes cryptographiques, toutefois lIETF prconise lutilisation de triple DES (128 bits) pour le chiffrement et HMAC-MD5 ou HMAC-SHA1 pour lauthenticit. Disponibilit de la solution : IPBX et IP Phones supportant IPSec (ou autre technologie VPN) Sources : P.42 de [NsaGuid] Travail de diplme Ludovic Maret IPsec : des bases au protocole IKE Ghislaine Labouret HSC Intervention ralise au sminaire WebSec 2000, le 21 mars 2000 http://www.hsc.fr/ressources/presentations/websec2000/index (Dernire visite le 19 mai 2006)
51/56
7.5 Scurit primtrique

7.5.1 SBC : Dfinitions de seuils / Call Admission Control
Identifiant : S.15 Description de la solution : Les attaques DoS entranent par dfinition un nombre anormalement lev de transactions rseau. Grce au SBC, l'administrateur rseau a la possibilit de dfinir des seuils, bass sur divers critres, permettant de limiter le trafic entrant et/ou sortant d'un rseau. De cette manire, le SBC vite de surcharger les switchs et de mettre hors-service certains quipements et/ou le rseau. Il est recommand de placer les seuils sur les lments suivants : Limitation du trafic de signalisation VoIP par session Limitation du trafic de signalisation VoIP par utilisateur enregistr (subscriber) Limitation du trafic de signalisation VoIP par rseau Limitation globale volume de signalisation VoIP
Il est galement recommand de placer les mmes types de seuils non plus par rapport la signalisation VoIP en gnral, mais par rapport au type de message de signalisation VoIP. Disponibilit de la solution : SBC supportant les seuils pour faire du Call Admission Control Sources : P.40-41 de [SBCdc]
7.5.2
Utilisation de serveurs ddis pour STUN
Identifiant : S.16 Attaques prvenues : (rfrence leur identifiant) 12354, 23423 Description de la solution : Il est aussi recommand que les serveurs STUN tournent sur des serveurs ddis STUN, avec tous les ports TCP et UDP dsactivs except les ports STUN. Ceci permettra dviter des virus ou chevaux de Troie dinfecter les serveurs STUN, et ainsi empcher quils soient compromis. (permettant dviter la mthode 1 dcrite dans les attaques, voir chap. 3). Disponibilit de la solution : Possibilit davoir un serveur STUN ddi Sources : RFC 3489 : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
52/56
7.5.3
Vrification de lidentit du serveur STUN
Identitifant : S.17 Attaques prvenues : Description de la solution : STUN contient un mcanisme de vrification dintgrit des messages, demandant au client STUN de tout dabord faire une demande de secret partag envers le serveur STUN. Le serveur STUN va ensuite lui rpondre en lui indiquant un nom dutilisateur et un mot de passe. Lorsque le client va ensuite faire sa requte, il va y insrer un champ Message Integrity ainsi quun username, qui permettra au serveur de vrifier lintgrit du message. Les rponses vont ensuite contenir elles aussi un champs permettant de vrifier lintgrit des messages. Cette fonctionnalit nest pas obligatoire, elle est note SHOULD dans la RFC de STUN. Il faut donc vrifier quelle soit bien active et que les demandes et les rponses possdent bien ce champ Message Integrity et quelles soient bien vrifies chaque transaction. Disponibilit de la solution : Le serveur STUN utilis doit avoir la fonctionnalit de vrification de lintgrit des messages. Sources : RFC 3489 : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
7.5.4 Client STUN : Continuation de lcoute des rponses aprs rception de la premire rponse
Identifiant : S.18 Attaques prvenues : Description de la solution : La rception dune rponse de la part du serveur STUN (que ce soit une erreur ou une Binding Response) doit normalement terminer les transmissions de cette requte. Toutefois, les clients doivent continuer couter les rponses durant 10 secondes aprs la premire rponse. Si durant ces dix secondes une rponse contenant des informations autres est reue, il est probable quune attaque est en cours. Il est donc important de vrifier que les clients STUN utiliss fassent cette vrification et avertissent lutilisateur le cas chant. Cette solution ne rsout pas directement le problme, mais avertit lutilisateur en cas dattaque, qui pourra prendre ses dispositions pour la bloquer et/ou couper toute communication en cours. Disponibilit de la solution : Les clients STUN utiliss doivent faire cette vrification. Sources : RFC 3489 : STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
53/56
7.5.5 Relais STUN : Limitation de la bande passante alloue par personne

Identifiant : S.19 Attaques prvenues : Description de la solution : Puisque les serveurs STUN implmentant les fonctions de relais allouent des ressources, ils sont susceptibles dtre victimes dattaques du type dni de service, toutes les requtes dallocation sont authentifis ce qui permet dviter un attaquant inconnu de lancer une attaque. Toutefois, un attaquant authentifi pourrait gnrer de multiples requtes dallocation. Pour empcher un simple utilisateur malicieux dallouer toutes les ressources du serveur, il est recommand quun serveur implmente une limite modeste de bande passante qui peut tre alloue par personne. Toutefois, un tel mcanisme nempche pas un large nombre dutilisateurs mal intentionns de demander un faible nombre de ressources. Ce genre dattaques sont possibles en utilisant des botnets, et sont difficiles dtecter et empcher. Disponibilit de la solution : Le serveur STUN utilis doit avoir cette fonctionnalit Sources : Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN) anciennement TURN, version du 27 fvrier 2006, expire le 31 aot 2006 http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-04.txt (dernire visite le 12 octobre 2006)
54/56
Rfrences
L. Schweizer, Tutorial SIP,
[TutoSIP]
http://www.iict.ch/Tcom/Projets/VoIP/VoIP_and_Mobility/Tutoriaux/Tutorial_SIP.pdf
[IPTelCook] IP Telephony Cookbook,

http://www.terena.nl/activities/iptel/contents1.html
[DodNet] Network Infrastructure Security Technical Implementation Guide http://iase.disa.mil/stigs/stig/network-stig-v6r4.pdf [NistXP] Guide to securing Windows XP http://csrc.nist.gov/itsec/SP800-68.zip [NsaArch] Recommended IP Telephony Architecture http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/voip/I332-009R2006.pdf [NsaGuid] Security Guidance for Deploying IP telephony Systems http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/voip/I332-016R2005.PDF [NIST] NIST - Security Considerations for Voice Over IP Systems,
http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf
[DoD] IP Telephony & VoIP : Security technical implementation guide

http://csrc.nist.gov/pcig/STIGs/VoIP-STIG-V2R2.pdf
[Junip] Juniper Networks, Enterprise VoIP Security : Best Practices,

http://www.juniper.net/solutions/literature/white_papers/200179.pdf
[Digest] Study of Digest Authentication for Session Initiation Protocol

http://www.site.uottawa.ca/~bob/gradstudents/DigestAuthenticationReport.pdf
[VoixSurIP] La voix sur IP ISBN 2-10-007-480-6
55/56
Best Practice - Scurit VoIP [SBCdc] Data Connection, Session Border Controllers http://www.dataconnection.com/network/download/whitepapers/sessionbordercontr oller.pdf [RFCSip] RFC 3261: Session Initiation Protocol http://www.ietf.org/rfc/rfc3261.txt [IPTelScenar] IP-telephony scenarios, http://www.uninett.no/sip/scenarier.en.html
56/56

BP VoIP Security

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BP VoIP Security

Transféré par

Droits d'auteur :

Formats disponibles

Best Practices for VoIP-SIP Security

Dernire modification: 17.1.2007

Best Practice - Scurit VoIP

Best Practice - Scurit VoIP

2.1 Rfrences VoIP-SIP

Dfinition pris sur http://www.crtc.gc.ca/dcs/frn/glossary.htm Cf. http://www.ip-centrex.org/whatis/index.html 3/56

Best Practice - Scurit VoIP

Socit Mono -Site

Socit Mono -Site

Socit Multi -Site

Uniquement PBX SIP

Uniquement PBX SIP 3

Interconnexion PSTN via Gateway 1

Interconnexion PSTN via ITSP 2

Best Practice - Scurit VoIP

Switch Firewall + NAT (data)

Best Practice - Scurit VoIP

Best Practice - Scurit VoIP

2.3.3 Entreprise nutilisant que SIP

Switch SBC SIP Hardphones

Best Practice - Scurit VoIP

Best Practice - Scurit VoIP

Best Practice - Scurit VoIP

Best Practice - Scurit VoIP

Les mthodes de scurisation proposes s'appuient sur les lments suivants :

4.1 Scurit de base

Best Practice - Scurit VoIP

4.2 Sparation des quipements DATA et VoIP

Best Practice - Scurit VoIP

Best Practice - Scurit VoIP

4.5 Scurit primtrique

Best Practice - Scurit VoIP

Best Practice - Scurit VoIP

Matrice attaques - solutions

(Matrice la page suivante)

Best Practice - Scurit VoIP

Sparation rseaux DATA/VoIP

Auth. Chiffrement Scurit primtr.

S.01 Mise jour du logiciel (IPBX/softphone/hardphone)

S.16 Utilisation de serveurs ddis pour STUN

Comm Vol Inds serv

S.17 Vrification de lidentit du serveur STUN

S.12 Chiff. des flux de signalisation (SIPS,)

S.08 Scuriser l'accs aux ports des switchs

S.15 SBC : Call admission control / seuils

S.09 DMZ pour les services convergs

S.13 Chiff. des flux mdias (SRTP,)

S.07 Ports supp. : Dsact. ou 802.1q

S.10 HTTP Digest Authentication

S.14 Chiff. des flux (IPSec,)

S.11 Authentification mutuelle

BP Scurit du poste client

S.03 Sparation niveau 3

S.06 Carte rseau 802.1q

S.02 Verrouillage config.

S.05 Filtrage Inter-Vlan

S.04 Sparation VLAN

Best Practice - Scurit VoIP

6.1 Liste des attaques

Best Practice - Scurit VoIP

DoS en utilisant les messages de requte SIP BYE

DoS en utilisant les messages de rponse SIP FAILURE

Perte de performance QoS en rutilisant la SSRC de RTP

Injection de paquets RTP