UFR informatique SECURITE : Infrastructure & SI
Sécurité de la VoIP
12/12/2007 UFR informatique M2 SIR
Par : EL BAHLOULI saad
FAHMANI Mohamed mahdi
SOMMAIRE
Introduction……….……….……….……….P 3 I- Architecture des communications VoIP……… ……….P 4 a) Fonctionnement de la téléphonie IP……….………. .P 4 b) Protocoles de signalisation :……… ………. .P 5 1- Protocole H323……….……….………. ...P 5 2- Protocole SIP……….……….………P 5 C) Protocoles de Données : RTP……….………...P 7 II- Vulnérabilités des réseaux VoIP……….………...P 7
a) Vulnérabilités du protocole……….……….…………...P 7 1- Attaques DoS……….……….………..P 8 2- Attaque CALL Hijacking……….………P 10 3- Attaque Man In the Middle……….……….P 11 4- Spam……….……….………..P 11 b) Vulnérabilités de l’infrastructure (hardware & software) ………P 12
1- L’infrastructure hardware ……….……….……P 12 2- L’infrastructure software……….……….……..P 13 III- Mesures de sécurité……….……….………..P 13
1- Sécurité des couches bases……….……….……….P 14
a) Sécurité d’accès……….……….……….P 14
b) Sécurité par vlan……….……….………P 14
2- Filtrage des adresses MAC par port……….……….P 15
3- Protection contre les attaques ARP……….………..P 15
4- Sécurisation des réseaux……….……….………….P 16
a) Sécurité des serveurs et filtrage……….………..P 16
b) Sécurité par réseau privé virtuel……….……….P 16
c) Sécurité du DNS……….……….………P 17
5- protection contre les attaques DoS……….………..P 17
6- Sécurité applicative……….……….……….P 17
Conclusion……….……….……….………P 22
Annexe A : Sécurité du H323……….……….………P 23
Annexe B : recommandations techniques pour sécuriser le réseau…………P 28
Bibliographie……….……….……….……….P 31
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 3
Introduction :
Plus qu’une évolution technologique, la téléphonie sur IP est aujourd’hui une application majeure du monde des réseaux. Son atout le plus important provient en partie de son intégration dans les réseaux de données, qui rend son cout très compétitif.
A l’inverse des communications classiques, facturées en fonction de la durée et de la distance, les communications sur internet sont quant à elles facturées en fonction du débit offert et de ce fait toutes les communications dont le flux transite sur le réseau internet sont comprise dans le prix.
Durant les 10 dernières années la technologie ToIP a évolué parallèlement aux autres technologies réseaux subissant de multiples standardisations qui la rendent prête pour un déploiement à grande échelle à condition toutefois de maitriser la sécurité et son intégration de l’entreprise.
Les vulnérabilités permettant les attaques peuvent avoir 5 origines :
• les protocoles
• les logiciels
• le système d’exploitation
• l’infrastructure physique
• l’erreur humaine
Il convient donc d’étudier avec précaution chacune de ces sources de failles lors de la mise en place d’une solution ToIP.
L’objectif d’une attaque peut être soit :
• Acquisition de services : afin de s’approprier des droits et fonctionnalité qui n’ont pas été attribués à l’attaquant.
• Interception du service : pour compromettre la confidentialité du service et vise à en analyser ou modifier le contenu.
• Interruption du service : l’objectif et de nuire au bon déroulement du service en cherchant à le mettre hors usage.
I- Architecture des communications VoIP
Nous n’approfondirons pas dans le cadre de ce travail de TER les principes de
fonctionnement des protocoles intervenant lors des communications IP mais nous proposerons un bref rappel des principes de base.
Pour plus d’ample détails nous vous ramenons au sujet de TER qui traite spécifiquement de la communication sur les réseaux IP.
a) Fonctionnement de la téléphonie IP
Les postes de téléphones traditionnels sont reliés directement à des autocommutateurs publics pour les particuliers ou à travers des autocommutateurs privés dans les entreprises.
C'est l'autocommutateur qui fournit par la ligne le courant de l'alimentation de l'appareil.
Le signal transmis est un signal analogique.
Les autocommutateurs publics sont reliés entre eux par des réseaux spécialisés pour le transport de la voix. Le numéro de téléphone correspond donc physiquement à une ligne téléphonique sur l'autocommutateur désigné. Pour établir une communication téléphonique, il faut donc établir une connexion, un circuit, entre la ligne appelante et la ligne appelée au travers de ces autocommutateurs.
La téléphonie sur IP est un ensemble de fonctions téléphoniques qui utilise l’envoie de paquets du protocole IP pour transmettre de la voix et gérer les fonctions téléphoniques.
la voix, numérisée et compressée, est transmise sous forme de paquets routés de la même manière que les paquets de données. Il n'y a donc plus de commutation de circuits.
Pour prétendre remplacer la téléphonie fixe, il faut un ensemble de fonctions évoluées.
Le premier protocole à fournir ces fonctions est le standard H323 développé par l'ITU-T, qui copiait les principes de la téléphonie classique.
Un nouveau protocole, beaucoup mieux adapté à l'Internet a été développé par l'IETF: SIP.
C'est ce protocole qui va permettre le développement des fonctions téléphoniques. Il permet aussi de développer des "téléphones SIP" qui permettent de se connecter directement à l'Internet en se passant du PC.
b) Protocoles de signalisation :
1- Le protocole H323
Plus qu'un protocole, H.323 ressemble davantage à une association de plusieurs protocoles différents et qui peuvent être regroupés en trois catégories : la signalisation, la négociation de codec, et le transport de l’information.
Figure 1 : L’association de protocoles H323.
Le protocole H323, bien qu'implémenté dans nombre de logiciels commerciaux et dans la plupart des solutions de visioconférence "tout en un", passe pour un "mauvais protocole".
Ceci est en fait dû à la liberté qu'ont prisent les fabricants dans l'implémentation des
différentes normes du protocole. Ce qui fait qu'un protocole qui se devait d'être interopérable ne l'est plus vraiment. Au point qu'il est relativement difficile de faire fonctionner deux solutions propriétaires différentes entrent-elles.
2- Le protocole SIP
SIP, Session Initiation Protocol, est un protocole qui permet de créer et gérer des sessions entre participants pour échanger des données. Il est indépendant de la nature des données et du protocole de transport. Il peut donc servir à établir de conversations téléphoniques et des conférences.
L’adresse qu’utilise le protocole SIP pour identifier un utilisateur prend la forme :
« sip:etudiant@univ-lyon1.fr ».
Il existe une version sécurisée du protocole « sips » qui utilise TLS comme protocole sécurisé comme le protocole https vis à vis de http.
SIP possède cinq grandes fonctions pour établir et terminer des communications multimédia.
1. Adresse de l'utilisateur
pour déterminer le système terminal qui doit être utilisé pour la communication.
2. Disponibilité de l'utilisateur
pour déterminer si l'utilisateur a envie de participer à la communication.
3. Moyens de l'utilisateur
pour déterminer le média dont dispose l'utilisateur et ses caractéristiques 4. La mise en route de la session
"sonnerie" et établissement des paramètres de la session 5. Gestion de la session
incluant le transfert et la fin de session, la modification des paramètres de la session ou l'appel de services
Toutes ces fonctions sont assurées par un réseau de machines appelées des "Serveur Proxy".
Les utilisateurs s'adressent à ces serveurs proxy pour s'enregistrer ou demander l'établissement de communications.
Ce qui fait la simplicité de ce système et que l’on peut s'enregistrer sur le proxy de son choix indépendamment de sa situation géographique. Une entreprise avec plusieurs centaines d’implantations physiques différentes n'a besoin que d'un serveur proxy quelque part sur l'Internet pour établir "son" réseau de téléphonique "gratuit" sur l'Internet un peu à la manière de l'émail.
Une communication via SIP se déroule comme suit :
Figure 2 : Les trames de signalisation SIP.
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 7
Méthodes Principe
INVITE Débute une communication SIP. Création du Call-ID et éventuellement du tag sur le champ From.
ACK Confirmation de l'établissement de la session SIP.
Call-ID identique à celui du paquet INVITE associé.
Ajout éventuel du tag sur le champ To du paquet INVITE
relatif.
REGISTER Enregistre un utilisateur auprès d'un noeud VoIP (non utilisé en communication directe entre 2 clients)
BYE Met fin à la communication. Même Call-ID que les
paquets précédents. Idem si utilisation des tags.
CANCEL Annule un SIP INVITE (appel). Même Call-ID et éventuellement tag du champ From du SIP INVITE.
c) Protocoles de Donnée RTP
Concernant les protocoles de données, un monopole de fait existe au profit de RTP, le Realtime Transport Protocol. Conçu par le groupe Audio/Video de l’IETF.
RTP définit un protocole de transport de données temps réel (voix, video) au dessus d’UDP.
Les données en question sont transmises dans des paquets UDP, précédées d’un en-tête applicatif minimal, contenant des informations de synchronisation du flux. Les informations de contrôle qualité sont véhiculées dans des paquets RTCP (Realtime Transport Control Protocol).
RTCP n’a aucun rapport avec TCP et n’est aucunement la version (TCP) du RTP.
Ni RTP ni RTCP n’offrent de garanties quant aux délais de transmission ; c’est aux protocoles de niveaux inférieurs et aux équipements traversés de s’en charger.
Outre son application en unicast dans la voix sur IP, RTP a de nombreuses autres utilisations sur les réseaux IP, certaines multicast, comme dans la video des offres Internet triple-play.
II- Les vulnérabilités des réseaux VoIP
La vulnérabilité de VoIP, par rapport au service téléphonique ordinaire, s'explique en partie par l'utilisation d'un média partagé, donc aucune ligne destinée à la transaction d'un appel n'est disponible, mais seulement un réseau exploité par de nombreux utilisateurs et un grand nombre d'applications différentes. Ce qui permet bien sûr à une personne malveillante de s'introduire plus facilement dans la communication, au moyen des systèmes informatiques.
a) Vulnérabilité du protocole :
Il existe deux principales vulnérabilités sur un environnement VoIP :
La première dépend des protocoles utilisés (SIP, H323…) et la deuxième est reliée aux systèmes d’exploitation sur lesquels les éléments VoIP sont implémentés.
Chaque protocole ou service a ces propres vulnérabilités.
Etant donné que SIP et le protocole au cœur de l’architecture des réseaux VoIP, ne nous traiterons dans ce qui suit que les failles s’y rapportant.
Comme évoquer plus haut, une communication VoIP est établie en deux étapes : signalisation qui instaure l’appel, et les flux de médias, qui transportent la voix .
La signalisation en SIP transmet les entêtes et la charge utile du paquet en texte claire, ce qui permet à un attaquant de falsifier facilement les paquets. Elle est donc vulnérable aux faussaires qui essaient de voler ou perturber le service téléphonique et à l’écoute clandestine qui recherche des informations sur un compte utilisateur valide, pour passer des appels gratuits par exemple. La signalisation utilise, en général, le port par défaut UDP/TCP 5060.
Le firewall doit être capable d’inspecter les paquets de signalisation et ouvre ce port afin de leur autoriser l’accès au réseau créant un trou pour des attaques contre les éléments qui écoutent l’activité sur ce port.
Le protocole RTP présente également plusieurs vulnérabilités dues à l’absence d’authentification et de chiffrage. Chaque entête d’un paquet RTP contient un numéro de séquence plus élevé. En conséquence, ces paquets seront diffusés à la place des vrais paquets.
Les protocoles de la VoIP utilisent TCP et UDP comme moyen de transport et par conséquent sont aussi vulnérable à toutes les attaques de bas niveau contre ces protocoles, telles que le détournement de la session TCP, la mystification UDP ( spoofing),..etc.
1- Attaques DoS :
Il existe deux sortes d’attaques Dos :
• Celles qui exploite les erreurs de programmation pour faire tomber routeurs et serveurs.
• Celles causées par une attaque de saturation.
L’attaque par saturation a pour but de rendre un élément particulier du réseau
indisponible, en dirigeant une quantité excessive du trafic réseau à ses interfaces. Elle peut être distribuée en implémentant la collaboration de plusieurs ordinateurs.
Les phases d’une telle attaque peuvent être résumées comme suit :
Phase 1 : l’installation des logiciels maitres et zombie. les zombies livrent concrètement l’assaut contre la victime, tandis que les logiciels maitres, installés sur d’autre ordinateurs, déclenchent l’attaque.
Phase 2 : Lancement de l’offensive.
Dans le cas de SIP, une attaque DoS peut être directement dirigée contre les utilisateurs finaux ou les dispositifs tels que téléphone IP, routeur, proxy SIP..etc.
L’attaque DoS peut prendre différentes formes
a. CANCEL
C’est un déni de service qui vise l’utilisateur et conduit à l’interruption de la communication.
L’attaquant guette l’arrivé d’un appel pour un utilisateur spécifique sur le proxy SIP et dès que le dispositif de l’utilisateur reçoit la requête INVITE, l’attaquant envoie immédiatement une requête CANCEL ce qui termine l’appel comme présenter dans le figure ci-dessous :
Figure 3 : mécanisme de l’attaque CANCEL
le proxy SIP du domaine a intercepte l’invitation pour l’établissement d’appel et la redirige vers s le Proxy du domaine B qui à son tour la transmet à l’appelé. L’attaquant qui surveille l’activité du serveur proxy du domaine B envoie une requête CANCEL avant que l’appelé n’ait eu le temps d’envoyer la réponse OK qui accepte l’appel. Cette requête annulera la requête en attente (INVITE) et donc l’appel n’aura pas lieu.
b. BYE
Cette attaque lancé aussi contre l’utilisateur entraine un déni de service mais cette fois ci en utilisant la requête BYE qui est envoyé soit a l’appelant soit à l’appelé, il est ainsi possible de perturber la communication à n’importe quel moment.
Figure 4 : mécanisme de l’attaque BYE
A la différence de l’attaque précédente, l’attaquant attend que l’appelé envoie une requête d’acceptation de la communication (OK) avant de décider d’envoyer une requête BYE vers
l’une des deux extrémités de la communication ce qui aura pour effet de couper la communication à l’insu des utilisateurs.
c. SIP INVITE flood
Un déni de service plus traditionnel et des attaques de dénie de service distribué sont possibles en utilisant les caractéristiques du protocole SIP. Envoyer simultanément une requête INVITE à un grand nombre d’utilisateurs en falsifiant l’adresse source est un exemple. En conséquence, tout les dispositifs répondent simultanément au même dispositif créant une situation de dénie de service.
d. Requêtes manipulées :
Dans de nombreuses architectures, les proxys SIP sont placés face à internet afin d’accepter les requêtes depuis le monde entier. Cette situation fournit un certain nombre d’opportunités potentielles en faveur des attaques de dénie de service.
Les attaquants peuvent créer des fausses requêtes qui contiennent une adresse IP source falsifiée et un entête via qui identifient l’hôte cible. Ils envoient cette façon, un User Agent SIP ou un proxy SIP est utilisé pour produire du trafic DOS visant la cible.
Les attaquants peuvent également essayer d’épuiser la mémoire disponible et les ressources du disque d’un registre en enregistrant un énorme nombre de liaisons (Binding).
A savoir aussi qu’une attaque DOS peut priver le réseau d’adresse IP en épuisant le poole d’adresses IP d’un serveur DHCP dans un réseau VoIP. Cette situation est plus connue sous le nom d’épuisement de ressources.
On constate que le dénie de service peut être accompli par divers moyens. Le DoS plus traditionnel et les attaques DDoD demandent en général l’inondation d’un hôte par un grand nombre de requêtes de service pour qu’aucune requête légitime ne puisse être traitée.
2- Call hijacking
Le Call hijacking consiste à détourner un appel. Plusieurs fournisseurs de service VoIP utilisent le web come interface permettant à l’utilisateur d’accéder à leur système
téléphonique. Un utilisateur authentifié peut changer les paramètres de ses transferts d’appel à travers cette interface web. C’est peut être pratique, mais un utilisateur malveillant peut utiliser le même moyen pour mener une attaque.
Exemple : Quand un agent SIP envoie un message INVITE pour initier un appel, l’attaquant envoie un message de redirection 3xx indiquant que l’appelé s’est déplacé et par la même occasion donne sa propre adresse de renvoie. A partir de ce moment, tous les appels destinés à l’utilisateur sont transférés et c’est l’attaquant qui les reçoit.
Un appel détourné en lui-même est un problème, mais c’est encore plus grave quand il est porteur sensibles et confidentielles.
3- Attaque Man In the Middle:
Cette attaque consiste à écouter l'appel entre un l’appelant et l’appelé au moyen d'un empoisonnement ARP dans le but de convaincre à la fois le serveur mandataire et les téléphones VoIP des deux utilisateurs de communiquer avec l’attaquant et non entre eux.
la figure suivante illustre l'aspiration d'une transmission VoIP.
Figure 5 : mécanisme de l’attaque MIM
Tout d'abord, l'appel est paramétré. L’appelant A envoie la requête pour appeler B au serveur mandataire SIP. Ce message est intercepté puis transmis à la personne malveillante. Le serveur mandataire SIP tente désormais de joindre Bob pour lui indiquer que A souhaite l'appeler. Ce message est également intercepté puis transmis à la personne malveillante. Après une initialisation de l'appel réussie, l'appel actuel (qui a recours au protocole RTP) entre A et B commence. Cette communication RTP est également interceptée puis transmise par la personne malveillante. L’utilisation d’à un outil comme Ethereal pour aspirer une
communication, permet de recevoir également les données utiles RTP en continu. Si vous souhaitez retenter.
4- Attaque SPAM:
Trois forme principales de spams jusqu’à maintenant identifiés dans SIP :
Call Spam : Ce type de spam est défini comme une masse de tentatives d’initialisation de session (des requêtes INVITE) non sollicitées.
Généralement c’est un UAC (User Agent Client : ex Soft phone, téléphone IP…) qui lance, en parallèle, un grand nombre d’appels. Si l’appel est établi, l’application spammeuse génère un ACK, joue une annonce préenregistrée, et ensuite termine l’appel.
IM (Instant Message) Spam : Ce type de spam est assemblable à celui de l’émail.
Il est défini comme une masse de messages instantanés non sollicitées. Les IM spams sont pour la plupart envoyés sous forme de requête SIP. Ce pourraient être des requêtes INVITE avec un entête subject très grand, ou des requêtes INVITE avec un corps en format texte ou HTML. L’IM spam est beaucoup plus intrusif que le spam email, car dans les systèmes actuels, les IMs apparaissent automatiquement (pop-up) à l’utilisateur.
Présence Spam : Ce type de spam est semblable à l’IM spam. Il est défini comme une masse de requêtes de présence (des requêtes SUBSCRIBE) non sollicitées.
L’attaquant fait ceci dans le but d’appartenir à la «white list » d’un utilisateur afin de lui envoyer des messages instantanés ou d’initier avec lui d’autres formes de communications.
L’IM Spam est différent du présence Spam dans le fait que ce dernier ne transmet pas réellement du contenu dans les messages.
b) Vulnérabilité de l’infrastructure (hardware &software)
Les composant d’une infrastructure VoIP sont divers de la Gateway, au serveurs (proxy, register, location ) chacun dispose d’un processeur sur lequel tourne un logiciel qui peut être la cible d’une attaque ou le point de départ d’une attaque
.
1- L’infrastructure hardware :
Un pirate peut compromettre un dispositif de téléphonie sur IP, par exemple un téléphone IP, un Soft phone, ou d’autres programmes ou matériels client.
Généralement il obtient les privilèges qui lui permettent de commander complètement la fonctionnalité du dispositif.
Compromettre un point final (téléphone IP) peut être fait à distance ou par un accès physique au dispositif.
Le pirate pourrait modifier les aspects opérationnels d’un tel dispositif :
- La pile du système d’exploitation peut être changée pour masquer la présence de l’attaquant.
- Un Frimeware modifié de manière malveillante peut avoir été téléchargé et installé. Les modifications faites à la configuration des logiciels de téléphonie IP peuvent permettre :
• Aux appels entrants d’être réorientés vers un autre point final sans que l’utilisateur soit au courant.
• Aux appels d’être surveillés.
• A l’information de la signalisation et/ou les paquets contenant de la voix d’être routés vers un autre dispositif et également d’être enregistrés et/ou modifiés.
• De compromettre la disponibilité du point final.
Les softphones ne réagissent pas de même façon aux attaques comparés à leur homologues téléphone IP. Ils sont plus susceptibles aux attaques dues au nombre de vecteur inclus dans le système, à savoir les vulnérabilités du système d’exploitation, les vulnérabilités
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 13 de l’application, les vulnérabilités du service, des vers, des virus, etc… En plus, le softphone demeure sur le segment de données, est ainsi sensible aux attaques lancées contre ce segment et pas simplement contre l’hôte qui héberge..
Les téléphones IP exécutent quant à eux leurs systèmes d’exploitation avec un nombre limité de services supportés, possèdent donc moins de vulnérabilité.
Un autre élément du réseau vulnérable est le serveur fournisseur du réseau de téléphonie sur IP, qui est peut être la cible d’attaques pour mettre en péril tout le réseau.
Si un serveur de signalisation est compromis un attaquant peut contrôler totalement l’information de signalisation pour différents appels ce qui permettra à un attaquant de changer n’importe quel paramètre relatif à l’appel. Pour finir, il faut préciser qu’un serveur de téléphonie IP est installé sur un système d’exploitation, il peut donc être une cible pour les virus, les vers, ou n’importe quel code malveillant.
2- L’infrastructure software :
Une des principales vulnérabilités du système d’exploitation est le buffer overflow qui permet à un attaquant de prendre le contrôle partiel ou complet de la machine.
Elle n’est pas la seule vulnérabilité et elle varie selon le fabricant et la version de l’OS.
Ces attaques visant l’OS sont pour la plupart relative au manque de sécurité de la phase initiale de développement du système d’exploitation et ne sont découvertes qu’après le lancement du produit.
Les dispositifs de la VoIP tels que les téléphonies IP, Call Managers, Geteways et les serveurs proxy,… héritent les mêmes vulnérabilités du système d’exploitation ou du firmware sur lequel ils tournent.
On déduira qu’une application de la VoIP est vulnérable dès que le système d’exploitation sur lequel elle tourne est compromis.
III- Mesures de sécurité
La sécurité dans la téléphonie classique est très forte. La disponibilité du réseau y atteint 99,999 % du temps. Avec la téléphonie sur IP il faut introduire des éléments et des mécanismes de sécurité supplémentaires puisque le support est partagé.
Au terme de la première partie de cette étude nous aboutissant au constat que tous les éléments de l’architecture VoIP sont vulnérables et sont visés par des attaques aussi nombreuses que variées, qu’il s’agisse des éléments matériels ou encore des éléments logiciels.
Donc protéger l’architecture Voip revient, comme pour chaque sécurisation d’une architecture réseaux, à sécuriser les couches qu’elle implémente en commençant par le niveau le plus bas.
1- Sécurité des couches bases a) Sécurité d’accès
La sécurité physique doit permettre la limitation des accès aux bâtiments et équipements (ainsi qu’à toutes les informations qu’ils contiennent) évitant ainsi les intrusions inopportunes, le vandalisme, les catastrophes naturelles, et les dommages accidentels (pic d’intensité électrique, température trop élevée…).
A moins que le trafic Voix ne soit chiffré sur le réseau, toute personne ayant un accès physique au réseau d’une société peut potentiellement se connecter à tout moment et intercepter des communications. Les lignes téléphoniques classiques peuvent certes subir le même type d’attaque, mais les prises LAN présentes dans la plupart des bureaux permettent non seulement un accès beaucoup plus simple au réseau, mais évitent aussi et surtout au pirate de se faire remarquer. Même avec le chiffrement des communications mis en place, un accès physique aux serveurs Voix ou aux passerelles peut permettre à un attaquant d’observer le trafic (qui appelle qui ? à quelle fréquence ? etc.). Une politique de contrôle d’accès pour restreindre l’accès aux composants du réseau de ToIP via des badgeuses, serrures, service de sécurité, etc., permettra d’établir un premier périmètre sécurisé
b)
Sécurité par VLAN
Séparer les flux vocaux des flux de données est conseillé pour assurer une meilleure qualité de service. La mise en place d'un VLan de niveau 2 pour la voix et un autre pour les données constitue un minimum. Un VLan par poste téléphonique IP avec routage de niveau 3 peut aussi être envisagé. L’ ajout d’un filtre en frontal des matériels et serveurs de téléphonie sur IP, par le biais d'un routeur ou d'un pare-feu est aussi envisageable.
Figure 7 : le cloisonnement des VLAN (séparation data et voix)
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 15
2- Filtrage des adresses MAC par port
Pour éviter que n’importe qui se connecte sur les ports d’un switch, il est possible de faire un contrôle sur les adresses MAC des machines connectées sur chaque port.
Une simple commande permet d’activer cette sécurité sur l’interface concernée.
La définition des adresses MAC autorisées sur un port donné peut se faire de deux façons :
• Par adresse MAC fixée en spécifiant explicitement l’adresse MAC à qui l’on souhaite donner l’accès dan la commande au switch.
• Par apprentissage de l’adresse MAC source de la première trame qui traversera le port via le "sticky MAC".
Par défaut, une seule adresse MAC est autorisée sur un port. Il est possible d’augmenter ce nombre . chez CISCO on se sert de la commande :
Switch(config-if) # switchport port-security maximum nombre
3- Protection contre les attaques ARP :
La première parade consiste donc à empêcher le pirate de se connecter au réseau.
Pour un réseau filaire, il faut empêcher l’accès physique au réseau. En Wi-Fi, avec le WEP, tous les paquets sont rejetés si le pirate ne connaît pas la clé secrète. Malheureusement, il n’est pas très compliqué pour un pirate de trouver la clé WEP (en utilisant des outils disponibles gratuitement sur Internet), donc de profiter pleinement de la connexion Wi-Fi. En revanche, le WPA et le 802.11i offrent une protection très efficace : un pirate peut bien s’associer à un AP (Access Point), mais l’ensemble des paquets qu’il émet est rejeté tant qu’il ne s’est pas identifié avec le protocole 802.1x.
Installer un pare-feu qui sait détecter ces attaques et les empêcher: l’idéal pour les connexions 802.11 est que ce type de pare-feu soit intégré à chaque AP, de sorte que le pirate ne puisse pas attaquer les autres stations associées au même AP.
Sinon, on devra se contenter d’un pare-feu installé entre l’AP et le réseau filaire, pour au moins protéger le réseau filaire contre les attaques provenant du réseau sans fil.
Implémenter des tables ARP statiques : Une autre parade, assez contraignante, consiste à interdire qu’une association de la table ARP puisse être modifiée. En supposant que les tables ARP soient déjà figées au moment où le pirate arrive, il ne pourra empoisonner aucune station. Malheureusement, il est souvent nécessaire que les associations changent : en particulier, si les stations obtiennent leur adresse IP dynamiquement (par DHCP), alors il peut arriver fréquemment qu’une même adresse IP soit attribuée à un moment donné à une station, et un peu plus tard à une autre (avec une autre adresse MAC). Dans ce cas, il faut que toutes les stations du réseau mettent à jour leur table ARP pour prendre en compte ce changement.
Analyser les historiques : Les stations peuvent souvent conserver un historique de leur table ARP. On peut alors analyser les historiques ARP des stations (manuellement ou grâce à un logiciel spécialisé) dans le but de trouver les traces d’attaques passées, pour mieux prévoir et prévenir les prochaines.
4- La sécurisation du réseau
a) Sécurité des serveurs et filtrage
L’ensemble des serveurs participant à une solution de ToIP doit respecter une procédure de mise en place standard et être sécurisé avant toute connexion au réseau. Une seule équipe au sein de l’entreprise doit être en charge de la rédaction des procédures d’installation et de sécurisation des serveurs et cela quel que soit le type de système (Windows, Linux, Unix propriétaire, etc.).
La sécurisation des serveurs comprend notamment :
• la suppression des comptes inutiles,
• la vérification du bon niveau de droit des différents comptes,
• la suppression des services inutiles,
• la suppression des logiciels ou modules inutiles,
• le bon niveau de correction par rapport aux publications des éditeurs/constructeurs.
Les serveurs de gestion VoIP (surtout installés par défaut) quant à eux ont un nombre de ports ouverts par défaut très conséquent et de ce fait un contrôle d’accès par filtrage IP est nécessaire.
Il est donc fortement recommandé de filtrer les ports accessibles sur les serveurs depuis le réseau des utilisateurs, au niveau des routeurs. Pour cela, il peut être utile de placer les serveurs sur un sous réseau dédié.
Il convient de lister les services et les ports associés qui doivent être pris en considération lors de l’implémentation d’une politique de filtrage sur un réseau VoIP.
Finalement, il est recommandé un audit régulier des serveurs en production par la même équipe. Celle-ci vérifiera le bon fonctionnement des serveurs et s’assurera que les utilisateurs ne détournent pas les serveurs de leurs fonctionnalités initiales, provoquant alors une baisse du niveau de sécurité de l’entreprise.
b) Sécurité par réseau privé virtuel
Pour les utilisateurs distants, la mise en place d'un réseau privé virtuel (ou VPN), généralement basé sur le protocole IPSec, s'impose aussi.
IPSec, qui travaille sur la couche réseau, permet d'assurer une plus grande fiabilité des informations. Notons par exemple que le problème des en-têtes SRTP modifiables (nous reviendrons sur le protocole SRTP dans la section suivante) n'est plus un souci.
Cependant, le coût de cette solution est parfois considérable, tant sur le plan des ressources matérielles que sur le trafic réseau. IKE (Internet Key Exchange) permet alors de remplacer MiKEY et d'assurer la gestion des clefs pour l'ensemble des communications VoIP.
La surcharge engendrée par IPSec peut être minimisée en configurant le tunnel pour traiter uniquement les flux de voix sur IP (pour des machines/protocoles fixés).Un atout intéressant est la possibilité d'utiliser la totalité des soft phones disponibles puisqu'ils n'ont plus à gérer la sécurité des échanges (via SRTP/MiKEY...).
UDP limite les types de tunnels utilisables, notamment SSL ou SSH, même s'il reste possible d'utiliser vtun (ou un équivalent) pour faire de l'UDP over TCP, mais les performances deviendraient rapidement médiocres !
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 17 Donc pour résumer on conclura que les tunnels simplifient le déploiement de la VoIP sécurisée, mais ne peuvent pas être employés sur de larges infrastructures ou sur des soft phones peu puissants.
c) Sécurité du DNS
L’utilisation de DNSSEC est une démarche sécurité supplémentaire. Il permet de sécuriser les données envoyées par le DNS. Contrairement à d'autres protocoles comme SSL, il ne sécurise pas juste un canal de communication mais il protège les données, les
enregistrements DNS, de bout en bout. Ainsi, il est efficace même lorsqu'un serveur intermédiaire trahit.
DNSSEC signe cryptographiquement les enregistrements DNS et met cette signature dans le DNS. Ainsi, un client DNS méfiant peut donc récupérer la signature et, s'il possède la clé du serveur, vérifier que les données sont correctes. La clé peut être récupérée via le DNS lui- même (ce qui pose un problème d'œuf et de poule) ou bien par un autre moyen (diffusée via le Web et signée avec PGP par exemple).
5- La protection contre les attaques DoS
Les contre-mesures sont très compliquées à mettre en place, d'un point de théorique, la plupart des attaques visant à créer des dénis de service sont basées sur des services ou protocoles normaux sur Internet. S'en protéger reviendrait à couper les voies de communications normales avec Internet, alors que c'est bien là la raison d'être principale des machines concernées (serveurs web, etc...).
Il reste tout de même la possibilité de se protéger contre certains comportements anormaux, (comme une tentative de flooding, un trop grand nombre de paquets ou de requêtes de connexion provenant d'un petit nombre de machines…).
Pour cela : il faut monitorer le trafic (ce qui est loin d'être simple, du fait de la quantité de données qui transitent), établir des profils types de comportement et des écarts tolérables au- delà desquels on considérera que l'on a affaire à une attaque; il faut également définir les types d'attaques auxquelles on souhaite se protéger (analyses de risques à l'appui) car il est impossible de toutes les prévoir.
C'est ce que l'on retrouve à l'heure actuelle dans la plupart des systèmes de protection contre les dénis de service. Ainsi Cisco propose des produits incluant à différents niveaux des services spécifiques :
• test de la taille des paquets ;
• test des adresses source et destination (ainsi que loop-back, unicast, multicast...) ; • test de la fragmentation ;
• utilisation d'adresses IP virtuelles pour validation de sessions et ACK (contre attaques TCP) ;
• test du nombre de SYN (contre attaques TCP) ; • contrôles de flux ;
• contrôles de contenus (port, tag, url, extensions de fichiers) ;
• autres fonctions de firewall, le tout basé sur du load-balancing et de la redondance.
L'accent est mis sur la sécurité du système de protection en lui-même pour qu'il puisse faire face à des situations extrêmes (trafic énorme, etc...) La plupart des contre-mesures visent à protéger contre un type d'attaque particulier.
La localisation de l'attaque est très souvent obscure parce que les adresses des paquets SYN envoyés ne sont très souvent pas plausibles. Quand le paquet arrive au serveur victime, il n'y a pas de moyen de déterminer sa véritable source. Comme Internet fait suivre les paquets basés sur une adresse de destination, le seul moyen de valider la source d'un paquet est d'utiliser le filtrage.
6- La sécurité applicative :
Comme expliquer plus haut le protocole RTP encode, transporte et décode la voix. La qualité du flux étant essentielle dans le domaine de la VoIP, tant sur le plan de la vitesse que sur la qualité, le compromis sécurité/utilisation est donc essentiel : débit, qualité de la voix, temps d'établissement des communications, etc.
Certaines solutions classiques ne sont donc pas viables et le meilleur compromis se détermine au cas par cas selon le nombre de clients, les débits souhaités, le niveau de sécurité requis, la vitesse du média utilisé, les types de données…
Les contraintes d'intégrité, de confidentialité et d'authenticité ne tenaient pas une place de choix dans les premières solutions et les protocoles clefs ne disposaient d'aucune protection fiable (SIP, RTP, RTCP, ...). Les problèmes s'accentuaient avec l'utilisation massive d'UDP pour accélérer les échanges, entre autres avec les problèmes évidents de spoofing.
La VoIP permet de remplacer la totalité des lignes RTC classiques (avec l'utilisation de PABX-IP), et c'est alors que la sécurité de l'architecture est rentrée dans le cahier des charges.
Plusieurs protocoles sont apparus avec notamment les équivalents chiffrés de RTP et RTCP : SRTP et SRTCP (respectivement Secure Real-Time Transport Protocol et Secure Real-Time Transport Control Protocol).
Les paquets SRTP se différencient des paquets RTP par 3 champs :
• un champ additionnel pour le type d'algorithme utilisé : Authentification tag ;
• un deuxième contenant différentes informations sur la clef : Master Key, Identifier (MKI) ;
• et bien sûr un payload chiffré.
SRTP et SRTCP ont été développés dans un souci de performances, le but étant de sécuriser au maximum les échanges à moindre coût en minimisant la surcharge liée au chiffrement du payload.
…
Synchronization source (SSRC) identifier Contributing Source (csrc) identifiers RTP extension
PYLOAD (chiffré) MKI
Authentification tag
.
Figure 6 : Paquet SRTP
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 19 Comme le montre la figure, seul le payload est chiffré dans un paquet SRTP, ce qui ne permet donc pas d'assurer à 100% l'intégrité des paquets transmis : l'en-tête du paquet SRTP pourrait être modifié, voire les champs optionnels MKI ou Authentification tag.
Quand SRTP est utilisé conjointement avec SIP, le déroulement chronologique des transactions est le suivant :
• Appelant : établissement de la communication (ringing) avec un paquet SIP INVITE.
• Appelé : accord du tiers distant avec une réponse 200 (OK).
• Appelant : paquet SIP de type ACK pour confirmer la réception du paquet précédent et établir la session SIP.
Une fois la communication établie, et si les deux participants se sont préalablement mis d'accord sur l'algorithme de chiffrement utilisé, alors la communication sécurisée est établie.
Dans le cas contraire, si une négociation des clefs est nécessaire, un protocole de gestion des clefs s'impose sur le même principe, par exemple, qu’IKE pour IPSec.
C'est dans ce but que MiKEY (Multimédia Internet Keyring) a été développé : Il s'agit d'un protocole récent à l’état de draft et encore très rarement implémenté.
MiKEY est encapsulé dans les paquets SIP et permet d'utiliser :
• un secret commun (PSK pour Pre-Shared Key), généralement sous forme de mot de passe ;
• des protocoles Diffie-Hellman d’échange de clés ;
• une PKI.
Cette dernière alternative n'a pas encore été implémentée et ses performances globales sont très controversées à l’heure actuelle.
MiKEY, tout comme SRTP/SRTCP, tente de minimiser les coûts et les impacts de la protection. Il doit assurer une sécurité optimale des transactions de clefs sans affecter de façon significative la rapidité des échanges.
Le projet minisip, bien qu'encore trop jeune pour être utilisé en production, est l'un des plus avancés dans ce domaine à l’heure actuelle. Il s'agit d'un client implémentant MiKEY et SRTP avec au choix une authentification PSK ou Diffie-Hellman. Il supporte également l’utilisation de TLS pour sécuriser les échanges SIP.
Il existe un jeune projet minisip pas encore utilisé en production, est c’est l'un des projets les plus avancés le domaine de la sécurisation de SIP à l’heure actuelle.
Il s'agit d'un client implémentant MiKEY et SRTP avec au choix une authentification PSK ou Diffie-Hellman. Il supporte également l’utilisation de TLS pour sécuriser les échanges SIP.
MiKEY s'encapsule dans SIP avec le champ a=key-mgmy qui permet d'assurer l'authentification qui permettra de faire transiter un flux SRTP par la suite avec des algorithmes et des clefs adéquats :
INVITE sip:lolo@rstack.org;user=phone SIP/2.0
From: <sip:mp@domain.org;user=phone>;tag=1017556314 To: <sip:lolo@rstack.org;user=phone>
Call-ID: 1664131130@rstack.org CSeq: 101 INVITE
Contact: <sip:mp@rstack.org:5060;user=phone;transport=UDP>;expires=900 Content-Type: application/sdp
INVITE sip:lolo@rstack.org;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.0.1:5060
[…]
m=audio 32945 RTP/AVP 0 97
a=key-mgmt:mikey AQAFgAAAAsAxNbayXB+WngBEH (…) jPANqgLOmmfPvB+/f56vA==
a=rtpmap:0 PCMU/8000/1 a=rtpmap:97 iLBC
Figure 7 : Paquet SIP INVITE + MiKEY
En utilisant des relais SIP, lorsque mp@rstack.org cherche à contacter lolo@rstack.org, le relais sortant effectue une requête DNS de type SRV pour connaître l'IP du serveur SIP distant, par exemple celle de sip.domaine.org.
Cette requête est une cible idéale pour un pirate, par exemple via une attaque de spoofing sur le DNS ID ou de cache poisoning afin de renvoyer l’adresse d’un proxy SIP qu’il contrôle.
L'utilisation de DNSSEC pourrait donc être envisagée à ce niveau.
Comme nous l’avons vu, MiKEY repose sur SIP : toute attaque sur ce dernier remet donc en cause la sécurité.
Il est indispensable de veiller à l'intégrité et l'authenticité des paquets SIP. La nécessité pour certains intermédiaires d'accéder, voire de modifier des portions de paquets (proxies, registrars, redirecteurs...) rendent la tâche délicate. Minisip propose l’utilisation de TLS pour limiter ces risques.
La figure suivante représente une solution sécurisée d'architecture de VoIP :
Figure 8 : Solution sécurisée retenu pour le projet SIP
La VoIP faisant appel à de nombreux processus (SIP, DNS, SRTP, voire SRTCP pour le contrôle du flux SRTP : CODECs, timing, etc.), il est indispensable de sécuriser chaque étape de la communication. Les nombreuses contraintes imposées par cette technologie ne facilitent pas la tâche : il est aussi parfois nécessaire de traverser des pare-feux, de fonctionner avec des translations d'adresses (NAT), et certains choix sont alors limités.
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 21 Les systèmes de détection d’intrusion réseau ou NIDS (Network-based Intrusion Detection Systems) ont pour but d’alerter les administrateurs de la solution en cas de trafic anormal ou jugé malicieux.
Un trafic qualifié de malicieux peut correspondre à la propagation d’un ver ou d’un exploit connu (programme développé spécifiquement pour exploiter une faiblesse clairement identifiée dans un logiciel donné), tandis qu’un trafic anormal fait plutôt référence à une utilisation détournée du réseau (par rapport à son but premier) et aux règles de sécurité définies (une connexion en Peer-to-Peer par exemple).
La détection d’intrusion système ou HIDS (Host-based Intrusion Detection System) fait référence à une famille de logiciels collectant des informations sur les serveurs ou encore les postes utilisateurs pour les analyser. Ce type d’action permet d’avoir une vue détaillée sur les différentes activités et d’identifier les processus ou les utilisateurs ayant des activités non autorisées.
La mise en place de ces deux types de systèmes est conseillée.
L’utilisation de sondes NIDS aux points clés du réseau – accès internet, DMZ, etc. – permet de superviser une partie importante du trafic aux points sensibles de l’infrastructure.
La gestion courante de ces sondes est réalisée autant que possible via des liens sécurisés (chiffrés). On notera que pour une efficacité maximum, et donc un minimum d’erreur de qualification dans les incidents (“false positive”), des mises à jour régulières et une configuration précise et détaillée seront nécessaires .
Les sondes d’intrusion système doivent être mises en place sur l’ensemble des serveurs participant aux infrastructures ToIP (DNS, DHCP, TFTP, RADIUS, NTP, LDAP…) et suivre un processus de supervision en temps réel au sein de l’entreprise.
Conclusion
La téléphonie sur IP s’impose comme étant une solution salvatrice pour la maitrise des couts pour les entreprises. De nombreuse étude sont menées pour améliorer et diversifier les services offerts.
Un projet de voix sur IP est complexe, car il n’existe pas de solution générique, et une étude au cas par cas s'impose avant la mise en œuvre de cette technologie. Le facteur sécurité doit être pris en compte avant même la phase de conception étant donné que tous les éléments de cette architecture sont vulnérables à une multitude d’attaques et peuvent ouvrir des brèches de sécrété sur tout le réseau de l’entreprise.
Une autre problématique qu’on se doit de solutionner lors de la conception d’une solution VoIP est : Comment trouver un compromis entre la QOS et la sécurité ?
Malheureusement c’est deux objectifs ne vont pas dans le même sens.
Globalement, la sécurité de la technique VoIP doit, consister en la protection des protocoles VoIP, des systèmes d’exploitation sur lesquels les solutions VoIP sont basées, la protection des couches réseaux contre les attaques de type DoS, et finalement la protection de la bande passante dédiée à la voix sur le réseau.
Toute sécurité impose des contraintes nécessaires, certes ; mais la question est de savoir, à quel point peut-on sécuriser sans dégrader la qualité de la voix sur le réseau. C’est dans ce sens qu’argumentent les partisans du VoP pour Voice over packet associés au NGN (next
generations network) et donc déjà concurrente de la VoIP avant même que cette dernière soit bien en place.
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 23
Annexe A : sécurité sur H323
Pourquoi créer un nouveau protocole ?
La décision de travailler sur l'H.325 est essentiellement venue du fait qu'une nouvelle architecture appelée NGN est sous développement et que cette nouvelle architecture pourrait bénéficier du développement de nouveaux systèmes multimédia.
Actuellement, deux types de terminaux sont déployés dans les architectures VoIP :
• Des dispositifs contrôlés par un agent sur le réseau
• Des dispositifs dits « intelligents » car ces terminaux ne sont pas contrôlés par un agent
Terminaux contrôlés par agent :
- Avantage : De nouveaux services peuvent être offerts sans exiger une mise à jour du terminal contrôlé.
- Inconvénient : Quasiment chaque action nécessite une interaction avec l'agent de contrôle.
Terminaux intelligents :
- Avantage : Les terminaux intelligents sont plus adaptés et robustes.
- Inconvénient : L'intelligence est dans le téléphone donc l'entreprise est dépendante du constructeur de téléphone pour ajouter un nouveau service. Les anciens téléphones peuvent rapidement poser problème et un renouvellement de parc régulier est préférable. Enfin, chaque téléphone du marché implémente les services différemment. Ces inconvénients génèrent une importante augmentation des coûts !
Note : Le problème a été soulevé en 1999 lors d'un meeting de l'ETSI à Tel Aviv. Certains participants ont exprimé leur désaccord avec la direction que prenait l'H.323. L'argument était que la logique devait être sous le contrôle du fournisseur de service. Néanmoins, l'H.323 est resté sur cette voie et SIP a suivi sous le même modèle.
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 25 Modèle hybride :
H.325 va adopter un modèle hybride dans lequel l'intelligence pour mettre en place un appel et maintenir l'appel sera dans le terminal final, et la plupart des services logiques seront en dehors du téléphone et dans le réseau. Une interface de contrôle de service devrait être définie pour autoriser des services basiques tels que le parquage d'appels, etc...
- Avantage : De nouveaux services pourront être ajoutés sans faire de changement dans le terminal.
Exigences pour ce protocole
A partir des protocoles existants, notamment SIP et H.323, le SG16 de l'ITU a dressé une liste d'exigences pour l'H.325. Cette liste de recommandations a été établie en étudiant les
problèmes des protocoles présents sur le marché afin des les résoudre et de ne pas les reproduire.
L'H.325 n'est encore qu'à l'état de projet, les solutions techniques ne sont pas toutes mises au point ou dévoilées dans les documents existants. Une version du protocole devrait être définie en 2008. Néanmoins, l'ITU travaille activement sur le projet et les points importants retenus pour la conception de l'H.325 par le groupe d'études sont :
1. Complexité minimale dans le terminal
Il faut permettre aux terminaux H.325 d'établir des appels, de maintenir ces appels, et de fournir des services avec une complexité minimale dans le terminal. Une forte complexité peut exister dans des dispositifs de réseau qui réalisent des services, mais une telle complexité doit nécessairement résider en dehors du terminal.
2. Accentuation/Intensité de l'interface utilisateur
Actuellement, il y a de nombreux designs de téléphones IP avec un très large nombre de designs d'interfaces utilisateur. Certains téléphones IP offrent une interface utilisateur graphique, certains avec des interfaces tactiles ou un simple écran LCD, d'autres ont des touches services, et il y a de nombreuses combinaisons de celles-ci. Il est proposé de définir un moyen par lequel le réseau pourrait diriger l'interface utilisateur et spécifier les
fonctionnalités des touches services sur le téléphone. Alors que le style du téléphone peut varier de manière significative, les aspects opérationnels de l'interaction avec le réseau pour mettre en place des services seront constants.
3. Flux Media
H.325 devrait avoir un simple et puissant mécanisme de capacité de négociation. Il devrait fournir les fonctionnalités utiles de l'H.245 mais les rendre plus simples en supprimant ce qui n'a pas été accepté dans le marché. De l'importance devrait être donné à l'établissement du média afin de fournir de la sécurité, de la QoS, et pour éviter les coupures de média. Ceci n'exclut pas à un constructeur de téléphones de définir une fonctionnalité spéciale qui est indépendante de l'H.325, tel que passer en revue le Web ou prendre des photos.
4. Robustesse
H.325 devrait être défini pour résister à la panne d'un ou plusieurs dispositifs. La panne d'un élément du réseau ne devrait pas avoir d'impact sur les autres aspects du système. Par exemple, la panne d'un serveur de fonctionnalités devrait uniquement affecter la capacité du terminal pour invoquer ces fonctionnalités précises et ne devraient pas impacter l'appel.
Quand les problèmes sont détectés, les terminaux devraient avoir un moyen de reporter ces problèmes au réseau afin de localiser la panne. Il devrait aussi y avoir un moyen pour reporter les informations concernant la QoS et les problèmes de routage de paquets. Le système devrait également avoir un moyen de détection des pannes de terminaux. Alors que la suppression d'un terminal d'un réseau ne peut pas être considérée comme une panne, les problèmes de routage de paquets au terminal ou opérations inhabituelles d'un terminal devraient être détectés.
5. Management et approvisionnement
Le Management et l'approvisionnement sont des zones fragiles des réseaux VoIP actuels.
Aujourd'hui, il est impossible de se rendre dans un magasin, d'acheter un téléphone IP et de l'amener à la maison ou au bureau, le brancher et s'attendre à ce qu'il fonctionne avec votre fournisseur de services. Il faut définir un moyen par lequel un dispositif pourrait apprendre ce dont il a besoin pour fonctionner correctement. L'utilisation des technologies comme des cartes SIM, l'utilisation du DHCP ou LLDP est envisagée. Différents environnements peuvent avoir différentes exigences en approvisionnement : un opérateur de câble pourra souhaiter employer un technique différente qu'un fournisseur de service en téléphonie IP. Il faut donc parvenir à définir des mécanismes qui pourront convenir à un large nombre d'utilisateurs et autoriser des variations pour s'accommoder à certains types d'accès réseaux spéciaux. Le NGN apparaît être un de ces réseaux qui pourraient avoir des exigences spéciales d'accès. Il faut définir un moyen pour que les dispositifs soient managés : avec des MIBs, SNMP ou autre.
6. QoS
Les clients attendent une haute qualité de service : de préférence une qualité de service aussi bonne que le RTC. Pour atteindre cet objectif, de la coordination devra être mise en place entre le terminal et le fournisseur d'accès. Les technologies devraient être considérées pour faciliter la création d'un système qui peut fournir des flux de haute qualité audio et vidéo.
7. Sécurité
H.325 devrait fournir la sécurité adéquate pour l'autorisation et l'authentification des dispositifs, aussi bien pour la sécurité de la signalisation que celle des flux média. Le
protocole SRTP sera utilisé pour la sécurité des flux média. La vie privée devrait être protégée bien que balançant contre les exigences de la loi.
8. Interconnexion RTC
Des dispositions doivent être prises pour faciliter l'interconnexion avec le RTC ou entre deux réseaux RTC. Cependant, il faudrait reconnaître que l'interconnexion RTC deviendra de moins en moins important mais il l'est aujourd'hui et le sera encore pendant plusieurs années.
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 27 9. Issues du réseau IP
Le support IPv6 est un plus, l'ITU souhaite mettre l'accent sur des dispositifs capables d'IPv6.
Les dispositifs NAT/FW resteront des obstacles à considérer. Une solution sera développée en améliorant les dispositifs de l'H.323 et de SIP.
10. Support de conférence
Les mécanismes de conférence multi-utilisateurs définis dans l'H.323 ont été souvent considérés comme trop complexes et les constructeurs ont choisi de ne pas implémenter la logique. L'objectif est ici de définir des mécanismes de conférences qui permettent de construire des systèmes de conférence simples à implémenter. Le groupe d'étude devrait étudier des moyens pour construire des architectures hautement évolutives qui n'ajoutent pas de complexité au terminal : laisser le terminal penser, la conférence est un simple appel point à point !
11. Accessibilité
L'accessibilité doit être considérée comme un protocole qui se développe. Ce devra être une exigence pour le support audio et vidéo. L'H.325 devrait mettre l'accent particulièrement sur l'assurance de la synchronisation du son et des lèvres, important pour les personnes ayant des problèmes d'audition. Il faudra donner de la considération à la taille vidéo, la qualité vidéo et audio.
12. Simplicité
Un des principes fondamentaux serait « Rester simple ».
Architectures proposées pour l'H.325
1) Architecture classique
Cette première alternative est une architecture basée sur celle de l'H.323 avec un certain nombre d'améliorations :
• Une séparation des applications de haut niveau et du réseau de bas niveau
• Permet aux applications du même niveau de fonctionner sur n'importe quel réseau (NGN, IP, Mobile, RNIS...) avec un transport optimisé pour chaque réseau.
• Une adaptation pour différents types de trafic : remplacer l'existant H.245 par un mécanisme très simple.
• Un nombre relativement faible de codecs qui réalisent la compatibilité avec les systèmes plus anciens (H.323, SIP,...).
• Utilise un maximum de ce qui a été appris dans les séries de H.3xx (certaines
fonctionnalités peuvent être gardées, modifiées et reconstruites afin d'éviter les erreurs du passé).
Annexe B : Recommandations techniques
Pour sécuriser le réseau
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 29 Voici les consignes techniques de base à appliquer pour sécurisé un réseau ToIP énuméré par jean-François Michonneau, responsable des offres de sécurité chez une société de service française :
1) Ne pas négliger la protection physique
L'autocommutateur doit rejoindre la salle informatique et bénéficier du même niveau de sécurité (alarme, anti-incendie, surveillance, accès badgé, etc.). Il est encore fréquent de trouver des PABX relégués dans un placard ou un simple réduit sans restriction d'accès.
2) Redonder les composants critiques
Coûteux, mais nécessaire lorsque la criticité de l'infrastructure de ToIP exige une forte disponibilité et/ou un rétablissement rapide en cas de panne. Les équipements critiques seront donc dupliqués et des mécanismes de partage de charge mis en place. Des tests réguliers doivent en outre être conduits pour contrôler les procédures de basculement et le bon fonctionnement des appareils redondants.
3) Durcir les OS et patcher
La sécurité du réseau voix, c'est à la fois les systèmes d'exploitation et les applications qui le composent. "Consolider les OS est indispensable, nécessaire et obligatoire. Les ports et les services inutiles seront désactivés. Les systèmes seront mis à jour pour corriger les vulnérabilités, des permissions sur les registres appliquées, etc. Tout ce qu'on fait dans un environnement standard", rappelle Jean-François Michonneau.
4) Sécuriser les bases de données
Les serveurs de ToIP s'appuient parfois aussi sur des bases SQL, dont la sécurisation est nécessaire. Cela passe notamment par la création de comptes administrateurs spécifiques, une politique de mots de passe forts, des permissions d'accès sur les objets SQL et l'activation des logs pour la traçabilité.
5) Compartimenter avec des VLAN
Trafics voix et données transiteront sur des réseaux distincts, des Virtual Local Area Network mis en place sur les commutateurs. Les différents flux seront ainsi étanchéifiés, ce qui empêchera une personne située sur le réseau données d'écouter le trafic voix. Les switchs assureront en outre la gestion des ACL (Access Control Lists = Listes de Contrôle d'Accès) et interdiront le port mirroring. Les ports non-actifs seront désactivés.
"Lorsqu'il est possible de le faire, il est recommandé de déployer la ToIP sur des plages IP spécifiques. Les serveurs DHCP et DNS seront dédiés à la voix, et distincts des serveurs data pour éviter un déni de service qui affecterait l'ensemble du réseau", précise aussi Jean-François Michonneau.
6) Protéger le poste de travail pour les softphones
L'utilisation d'un softphone, c'est-à-dire d'un logiciel de téléphonie installé sur le poste,
implique de protéger le poste contre les codes malveillants et l'usurpation d'identité. "Sur la base de nos retours d'expérience, j'aurais tendance à conseiller autant que possible de se passer des solutions de type softphone. Non pour des raisons de sécurité, mais de stabilité.
Le comportement de l'application est étroitement dépendant de la configuration du poste de travail, un élément difficile à maitriser", prévient l'expert de Spie Communications.
7) Placer les équipements derrière des pare-feu
Les firewalls seront mis en coupure, en amont des serveurs pour éviter le déni de service, et sur les segments critiques. Ils contrôleront que les flux des VLANs sont bien restreints aux protocoles de la VoIP. Les pare-feu supporteront à la fois les protocoles SIP (Session Initiation Protocol) et H.323.
8) Chiffrer de bout en bout
L'encryptage concernera les flux de signalisation (chargés de mettre en relation l'appelant et l'appelé) et média (transport de l'information). Ainsi le chiffrement de la voix s'appuiera sur TLS (Transport Layer Security), DTLS (Datagram TLS) ou SRTP (Secure RTP). Une entreprise peut également décider de recourir à IPSec. Les communications externes peuvent aussi être acheminées via des tunnels VPN.
9) Sécuriser les flux d'administration
L'administration des call manager s'appuiera sur l'utilisation de protocoles SSH, SSL ou encore IPsec. L'accès à l'IP PBX se fera depuis un poste protégé sur le plan logique et physique.
10) Monitorer le trafic
La surveillance du réseau avec des Sniffers et des IDS permettra de détecter le trafic anormal et les tentatives d'intrusion. L'analyse des logs pourra en outre révéler des attaques en brute force, des appels frauduleux (de nuit, vers des numéros surtaxés, etc.).
Tandis que des pics du trafic voix traduiront des spams vocaux (voice spam).
Toutefois, le risque zéro n'existe pas et les solutions de sécurité applicables à la ToIP peuvent s'avérer à la fois complexes et coûteuses à mettre en œuvre. L'entreprise devra donc arbitrer entre criticité, coût et niveau de risque jugé acceptable.
Par : El BAHLOULI Saad & FAHMANI Med El Mahdi Page 31
Bibliographie :
« Telephonie sur ip » de Laurent Oukil & Guy Pujolle edition EYROLLES.
« Tableaux de bord de la sécurité réseau »de Cedric Llorens & Laurent Levier & Denis Valois
Web :
Protocole SIP & H323 :
http:// www.figer.com/publication/sip.htm fr.wikipedia.org/
http://www.frameip.com/
www.commentcamarche.net
Attaques et vulnérabilité :
www.magicwandinc.net/hakin9/
http://www.orsys.fr/pdfCours/SVP.pdf http://www.securite.org/index2.html
Solution de sécurité :
http://www.journaldunet.com/solutions/0702/070205-securite-voip-toip.shtml http://www.securite.org/index2.html
http://wapiti.telecom-lille1.eu
