Une infrastructure de voix sur IP introduit menaces et contraintes nouvelles auxquelles les équipes opérationnelles ne sont pas toujours préparées. Voici un tour d'horizon des divers risques et solutions pour assurer la sécurité de ce type d’infrastructure.
L'erreur est devenue classique: parce que la voix sur IP (VoIP) emprunte les réseaux IP parfaitement maîtrisés, les équipes opérationnelles pensent pouvoir lui appliquer les mêmes recettes de sécurité. Pourtant, une infrastructure de VoIP a des exigences et des contraintes très différentes du trafic de données traditionnel. Comme la nécessité d'assurer une qualité de service forte, ou l'allocation dynamique des ports incompatible avec les pare-feu existants, etc.

L'entreprise qui ne prend pas ces spécificités en compte dans le cahier des charges de son projet de VoIP, prend un risque. Elle a toutes les chances de se retrouver avec un réseau de téléphonie IP qui, certes, fonctionne correctement, mais est ouvert à tous et à tout. C'est d'ailleurs la conviction de Phil Zimmermann, auteur du célèbre outil de chiffrement PGP, qui travaille aujourd'hui à un "PGP pour VoIP". Pour lui, les entreprises sont aujourd'hui face à la téléphonie sur IP telles qu'elles étaient face à la messagerie il y a dix ans. Elles n'ont pas conscience des risques tant que cela fonctionne.

Les risques, justement, sont bien identifiés. À commencer par le spit (spam over IP telephony), pratique visant à encombrer les boîtes vocales de messages publicitaires. Il s'agit, avec les attaques par déni de service (interruption du trafic ou saturation de la capacité de stockage des boîtes vocales) de l'attaque la plus évidente. Celle à laquelle tout réseau de VoIP ouvert sur l'internet public n'échappera pas s'il n'est pas protégé.

Viennent ensuite des menaces plus complexes telles que l'interception des appels et le détournement du service (n'importe qui pouvant alors téléphoner via l'infrastructure de l'entreprise). Ou encore l'usurpation de l'identité de l'appelant (se faire passer pour le patron d'un grand groupe auprès de quelques employés importants peu s'avérer particulièrement tentant). La menace n'est cependant pas immédiate: la majorité des infrastructures de VoIP actuelles sont déployées sur le Lan (réseau local) de l'entreprise et ne sont pas accessibles de l'extérieur. Mais l'ouverture au réseau public est l'étape suivante, et elle se prépare aujourd'hui, dès la mise en oeuvre du projet.

Verrouiller son infrastructure VoIP

La sécurité d'un projet de téléphonie sur IP se joue à plusieurs niveaux: «Il faut sécuriser l'architecture de transport, puis les matériels eux-mêmes et enfin les communications», explique Michel Cugnot, consultant technique chez Cisco. Du côté de l'infrastructure, la solution la plus évidente est de séparer totalement le trafic VoIP du reste du réseau. La distinction se fait au niveau 2 en créant des VLAN dédiés. Mais cette solution n'est pas toujours très réaliste: «Cela suppose que le réseau ne fait que de la téléphonie. Mais il va souvent falloir aller vers des annuaires, vers des services web, etc. C'est-à-dire vers le système d'informations. Cela crée beaucoup de connexions qui peuvent potentiellement perturber la téléphonie sur IP», poursuit le consultant.

Sans renoncer à un réseau dédié à la téléphonie sur IP (ne serait-ce que parce qu'un VLAN spécifique permet de mieux gérer la QoS), il faut donc être capable de contrôler finement les échanges entre le VLAN VoIP et le VLAN de données. Tout d'abord grâce à une politique de sécurité adaptée: les postes de téléphonie IP autorisés à se connecter au réseau doivent être particulièrement contrôlés (notamment via le protocole d'authentification 802.1x et des listes de contrôle d'accès au niveau des équipements de routage).

Le réseau doit ensuite mettre en oeuvre des protections contre l'injection de fausses informations, comme les fausses requêtes ARP (adress resolution protocol), la manipulation des tables ARP des postes IP, l'injection de faux serveurs DHCP (dynamic host configuration protocol) ou l'usurpation d'adresses IP. Toutes pourraient contribuer à imiter l'identité d'un poste ou insérer un PC sur le réseau VoIP. Avec la possibilité ensuite de mener des attaques complexes contre le réseau ou d'enregistrer les communications.

L'autre grande pratique sécurité consiste à isoler les serveurs VoIP du reste du monde, et s'assurer qu'ils traitent uniquement des requête de VoIP, et dialoguent avec les seuls postes autorisés et authentifiés. Toutefois, les pare-feu traditionnels ne sont pas adaptés: les protocoles de téléphonie sur IP (SIP et H.323) exigent l'ouverture dynamique de ports et prennent certaines libertés lors de l'initialisation d'une communication.

«On peut s'en sortir en faisant de la translation d'adresse avec une adresse sortante spécifique et des règles entrantes, qui ouvrent une certaine plage de ports lorsque l'adresse de destination était celle des serveurs de VoIP. Mais il est quand même plus simple de s'appuyer sur un pare-feu qui reconnaît les protocoles VoIP», explique Karim Mousli, responsable technique et intégration chez l'éditeur de pare-feu Clavister.

La plupart des éditeurs de pare-feu prennent désormais en compte les protocoles SIP et H.323, le plus souvent grâce à une extension au niveau applicatif (ALG pour Application Layer Gateway) intégrée au produit. Mais il est également possible de confier cette tâche à une appliance dédiée.

La sécurité du matériel est également cruciale

La sécurité du matériel est ensuite l'autre chantier sécurité: les serveurs qui hébergent le coeur de l'infrastructure fonctionnent sous un système d'exploitation traditionnel (Windows le plus souvent) et sont donc vulnérables à toutes les attaques habituelles. Une attention toute particulière doit alors être portée à l'application de leurs correctifs de sécurité.

Les téléphones IP, quant à eux, devront être capables d'être mis à jour de manière sécurisée (firmware et système d'exploitation signés). Ils devront aussi pouvoir être authentifiés de manière forte, en embarquant par exemple un certificat X.509, de préférence installé en usine et stocké dans une mémoire non volatile.

Les communications, enfin, viennent en dernier lieu. Sur une infrastructure correctement protégée et isolée, il ne sera pas forcément nécessaire de les sécuriser. En revanche, lorsque les communications devront emprunter un réseau public (ou pour se protéger d'une écoute interne), il sera impératif de les faire circuler sur un tunnel chiffré.

Aujourd'hui, la solution la plus évidente est de leur créer un VPN IPsec. Cependant, IPsec amène de nouvelles difficultés dans un réseau VoIP: il ajoute un délai d'environ 3 secondes à la circulation des données. Et, surtout, rend impossible le travail des équipements nécessitant de lire les en-têtes SIP ou H.323, comme par exemple les ALG des pare-feu et des équipements de routage.

C'est, une fois encore, l'affaire d'un compromis entre confort d'utilisation et sécurité.

Source www.zdnet.fr

---