hakin9!4!2009 article 3
TRANSCRIPT
10
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
Cet artiCle explique...Les moyens mis en œuvre par l'éditeur Alcatel-lucent pour sécuriser sa solution de communication sur IP.
Ce qu'il faut savoir...Des connaissances de base sur les problématiques suivantes aideront à une bonne compréhension du contenu: téléphonie sur IP, technologies réseau de niveau 2 et 3 et le système
Si cette approche permet de faire vivre le sujet et de mettre en évidence les faiblesses des standards, elle ne permet
pas de prendre connaissance des éléments mis en œuvre dans les environnements professionnels. Il me paraît important aujourd'hui d'avoir une vision claire de ces éléments pour deux raisons :
• Il s'agit de systèmes que vous pouvez utiliser tous les jours si votre entreprise a réalisée la bascule vers la ToIP,
• Bien que souvent propriétaire, les mesures prises par les constructeurs apportent une sécurité intéressante et peuvent parfois faire évoluer les standards.
• Je me propose donc aujourd'hui de vous décrire les possibilités présentes dans la solution de ToIP du constructeur Alcatel Lucent. Cette solution est très fortement implantée Europe et continuer à se dif fuser, il est donc probable que vous soyez amenés à la croiser un jour.
présentation de la solution de toipOn commence par la présentation du serveur de communication.
Le serveur OXE, basé sur une architecture client-serveur, s'adresse aux moyennes et grandes entreprises dotées de configurations IP ou mixtes (IP/TDM).
CéDrIC BAILLet
Le choix d'une solution traditionnelle, mixte ou exclusivement IP dépend des objectifs, de l'organisation, des projets convergents voix/données ou encore du retour sur investissement attendu.
Cette offre comprend notamment: des terminaux numériques et des fonctions pour opérateur, une application de messagerie vocale intégrée, de la téléphonie de groupe, des fonctions patron/secrétaire, de la téléphonie PC, etc., le tout conçu pour améliorer la productivité générale des entreprises.
Les solutions de communication d'entreprise du serveur OXE sont assimilées à des blocs constituant un modèle de communications ouvert comme on peut le découvrir en Figure 1.
Voici la liste des principaux éléments:
• Le serveur OXE, qui comprend une plate-forme de traitement et un logiciel de serveur de communication
• Un ensemble de passerelles multimédias• Un ensemble de clients IP: postes
téléphoniques, équipements, logiciels de bureau, fixes et mobiles
• Un ensemble de clients numériques: terminaux, appareils, logiciels de bureau, fixes ou/et mobiles
Tous ces éléments peuvent fonctionner indépendamment du réseau de données sous-jacent.
Degré de difficulté
sécurisation d'une solution de téléphonie
La sécurité des solutions de téléphonie sur IP est souvent abordée au travers des solutions libres, notamment Asterisk et ses dérivés, ou encore en évoquant les scripts permettant de jouer avec les protocoles de signalisation ou média.
11
Téléphonie sur ip
HAKIN9 4/2009
Le serveur OXE peut s'exécuter sur dif férentes plates-formes matérielles :
• IP Rack Server (IP RS) : serveur de communication :
• Installé au sein d'un châssis de module dédié Alcatel-Lucent rack 1 et connecté au réseau de données ou à des passerelles multimédias via une liaison Ethernet. Idéal pour les configurations IP comptant un maximum de 1000 utilisateurs.
• Hébergé sur une plate-forme de Media Gateway à module Alcatel-Lucent rack 3cavec d'autres cartes de ressource et d'inter face pour les configurations de type tout en un. Idéal pour les configurations comptant un maximum de 350 utilisateurs (IP et TDM).
• IP Crystal Server (IP CS): cartes CPU7-2 installées dans une alvéole Crystal. Idéal pour les configurations traditionnelles avec un nombre d'utilisateurs allant généralement de 250 à 5000.
• IP Appliance Server (IP AS): fonctionne sur une plate-forme matérielle standard et est connecté au système via une liaison Ethernet. Ce serveur est utilisé pour les installations IP évoluées, et configuré et livré par Alcatel-Lucent. C'est la solution idéale pour les configurations les plus importantes.
L'ensemble de cet article fera désormais référence à la plateforme matériel IP Appliance Server.
la média gatewayLes IP Media Gateways gèrent les accès et les interfaces d'une solution client. Elles sont contrôlées par le serveur OXE via une connexion IP.
La media gateway fournit les éléments suivants :
• Connexion à un réseau externe (public ou privé) : RNIS T0, RNIS E1-CCS (T2), E1-CAS, T1 CCS (PRI), T1 CAS, réseaux analogiques DDI / DID ou NDDI / Non-DID.
• Connexion à des téléphones numériques TDM, postes d'opérateurs (inter faces UA)
• Connexion à des équipements analogiques: télécopieurs, etc. (inter faces z-analogiques)
• Connexion de stations de base DECT• Connectivité IP• Canaux de compression vocale : G.711,
G.723, G.729A• Connexion des ressources DSP pour
services multimédias : guides vocaux, conférence, etc.
Une media gateway est connectée au serveur de communication par le biais d'une liaison Ethernet. Le serveur Oxe peut être mis en œuvre de trois façon dif férente exposé dans la Figure 3.
Les limites de la solution :
• le nombre d'utilisateurs par OXE est de 15 000 avec un maximum de 15 000 postes IP,
Figure 1. Un modèle de communication ouvert
Tableau 1. Comptes implémentés dans l'OXE
Compte Fonction Connexion FTp
Root Compte administrateur Oui Non
Swinst Installation du logiciel Oui Oui
Mtcl Maintenance client hors site Oui Oui
Client Maintenance réservée à l'utilisateur Oui
Bin Propriétaire de plusieurs binaires Non Non
Daemon Propriétaire de /var/spool/at Non Non
Ftp Accès ftp anonyme Non Oui
Httpd Propriétaire Http Non Non
Nobody Propriétaire de TFTP daemon Non Non
PPP Configuration de liaison IP sur V24 Non Oui
Adfexc Téléchargement des enregistrements des données des appels de 4670 Non Oui
12
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
• le nombre de Media Gateways est de 240 par serveur de communication,
• le nombre de serveurs de communication passifs est de 240 par serveur de communication,
• le nombre d'utilisateurs et de surveillance CSTA est de 20 000 par serveur de communication,
• le nombre d'entités est de 4 000 par nœud ou sous-réseau ABC,
• le nombre de lignes réseau est de 5 000 par serveur de communication,
• le nombre de faisceaux est de 500 par serveur de communication,
• le nombre de lignes réseau T0 est de 1 000 par serveur de communication,
• le nombre d'intervalles de traducteurs SDA est de 2 000,
• le nombre de tables de commande de numérotation est de 1 000,
• le nombre de mini-messages est de 32 000,
• le nombre de descripteurs de plan de numérotation est de 100,
• le nombre d'apparences multilignes est de 2 000.
la redondance spatialeLe serveur OXE offre un mécanisme de redondance pour les applications critiques qui exigent une fiabilité importante. La fonction de redondance du serveur permet de passer d'un serveur de à son serveur miroir via une liaison IP.
Dans ce type de configuration, deux serveurs coexistent dans le même système. L'un est actif, c'est le serveur principal. L'autre est constamment de surveillance en mode veille. En cas de défaillance du serveur principal, le second serveur prend automatiquement le relais. Le serveur de de secours (en veille) est
Tableau 2. Politique de sécurité pour les mots de passe
nombre de tentatives de connexion Défini dans la configuration système
Durée de vie minimale 10 jours
Durée de vie maximale De 11 à 365 jours
Message d'avertissement 5 jours avant (pour chaque connexion)
Nombre minimum de caractères Le nouveau mot de passe doit contenir au moins huit caractères. Les lettres majuscules/minuscules, les chiffres et les symboles de ponctuation sont admis.
Comparaison entre l'ancien et le nouveau mot de passe
Le nouveau mot de passe doit otre dif férent des trois précédents mots de passe établis pour le compte.
Figure 2. Les plateformes possibles pour l'OXE
continuellement mis à jour; il peut faire office de serveur principal à tout moment.
Avec le mécanisme de redondance du serveur OXE, toutes les données, bases de données, applications et logiciels de communication sont exécutés en parallèle sur les deux serveurs de communication. Le passage de l'un à l'autre est par conséquent fiable.
le serveur pCs (passive Communication server)Le serveur de communication passive (PCS) fournit des services de traitement d'appel à une Media Gateway ou un groupe de Media Gateways en cas d'indisponibilité du serveur OXE.
Si les liaisons IP avec le site qui héberge les serveurs de communication
sont rompues ou si les serveurs de com-munication sont hors service, le traitement des appels se poursuit en local.
Utilisations de serveurs PCS : Création d'un troisième serveur de communication de secours pour une meilleure disponibilité du système.
En conditions normales :
• les serveurs de communication contrôlent les appels au sein du réseau,
• les téléphones IP et / ou Media Gateways d'une région sont définis pour les serveurs,
• la synchronisation automatique ou manuelle de la région est effectuée sur les PCS de manière globale ou individuelle.
En cas de perte de liaison avec le serveur de communication :
• les services de téléphonie sont redémarrés localement,
• les services centralisés tels que la messagerie vocale ne sont plus disponibles,
• toutes les fonctions autonomes définies dans le traitement actif des appels sont maintenues par le serveur PCS, notamment les centres de contacts OmniTouch,
DOSSIER Téléphonie sur ip
13 HAKIN9 4/2009
• les justificatifs des détails d'appel, les performances et les tickets VoIP QoS sont enregistrés dans le serveur PCS.
En service normal, le serveur PCS peut être relancé manuellement. Au redémarrage :
• les téléphones IP et les Media Gateways sont redémarrés et recontrôlés par le serveur de communication du réseau,
• les justificatifs des détails d'appel, les performances et les tickets VoIP QoS sont stockés par l'application de gestion du réseau (4760).
signalisation de secours pour les Media GatewaysSi la liaison IP entre le serveur de communication et une passerelle IP Media Gateway de matériel traditionnel est perdue, une liaison de signalisation de secours est utilisée pour rétablir la voie de signalisation sur le réseau RTC. Ce service permet d'assurer la continuité des services téléphoniques sur les sites distants. Pendant la connexion avec le service de secours, l'utilisateur peut appeler et recevoir des appels sur la connexion réseau RTC locale et les appels Voix sur IP entre le site distant et tous les autres sites peuvent être redirigés par le biais du réseau public.
Un dialogue est établi entre le serveur de communication et chaque Media Gateway afin de surveiller les liaisons. Une interruption de cette boîte de dialogue informe le serveur OXE qu'une défaillance s'est produite. Le serveur OXE tente alors d'entrer en communication avec la passerelle multimédia distante sur le RTC (par l'intermédiaire de modems internes GD). Pendant ce temps, la Media Gateway distante redémarre.
En mode de secours, la Media Gateway interroge périodiquement le réseau IP. Lorsque la connexion au réseau IP est rétablie, la Media Gateway fait basculer la signalisation du serveur de communication sur la liaison normale. Tous les appels sont maintenus pendant la période où la signalisation du réseau IP normal est en cours de rétablissement.
En outre, lorsque le réseau IP est indisponible, les communications vocales intersites peuvent être établies via le
réseau public. Les numéros internes composés sont traduits automatiquement en numéros publics. Ce mécanisme peut également servir lorsque le contrôle d'admission des appels du site distant est atteint.
la sécurisation native de l'oxeOn commence par un système d`exploitation basé sur Linux.
L'OXE utilise un système d'exploitation basé sur Linux sécurisé par Alcatel pour n'avoir à maintenir que les programmes nécessaires. La taille du kit logiciel obtenu passe ainsi à 50 Mo, au lieu des 700 Mo du kit de la version destinée au public. Ainsi, les éléments présentés ci-dessous que l'on trouve généralement sur les distriburions complètes ont été suprimés :
• aucune interface graphique comme KDE, X11, Gnome, etc.,
• aucun partage réseau comme un partage via NFS ou Samba,
Le système d'exploitation Linux offre un niveau de sécurité natif intéressant et fournit les avantages du libre et de la communauté, à savoir:
• source totalement ouverte pour le noyau et les utilitaires des applications à venir,
• très grande base de données mondiale d'utilisateurs permettant d'identifier les problèmes de sécurité,
• vaste communauté de développeurs
permettant de résoudre rapidement les problèmes de sécurité.
Le serveur OXE a été renforcé pour résister aux attaques de flood. Un mécanisme de défense interne permet la réservation d’un temps de traitement minimum du processeur dédié à la gestion des communications.
sécurisation des échangesSi cette option est sélectionnée au moment de l'installation initiale, les échanges ef fectués entre les machines du réseau peuvent être chif frés à l'aide du protocole SSH. La transmission via SSH offre l'avantage de chif frer les données à l'initialisation. Les mots de passe ne sont donc pas transmis sur le réseau en clair.
Lorsque le protocole SSH est activé, les échanges sont chif frés entre les éléments suivants :
• les OXE sur un réseau ABC,• les OXE et les stations de gestion de
type 4760.
Pour que le chif frement des flux d'administration des CLI (Command Line Inter face) soient chif frés convenablement via le protocole SSH, il sera nécessaire d'activer ce dernier sur tous les nœuds du réseau ABC. De plus les stations d'administration susceptibles de se connecter à l'OXE devront être capable de prendre ce protocole en charge.
Figure 3. IP Media Gateway
14
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
Un environnement convenablement sécurisé permettra de prendre en charge les commandes suivantes :
ssh (secured shell) remplace telnet
ssh (secured shell) remplace rsh
(remote shell)
scp (secured copy) remplace rcp
(remote copy)
sftp (secured file transfer protocol)
remplace ftp (file transfer
protocol)
Enfin, les échanges applicatifs entre un poste client et l'OXE via une interface Web seront sécurisés via l'utilisation du protocole SSL. Je profite de cette remarque pour préciser que le serveur web utilisé est un serveur de type APACHE version 1.3.31.
utilisateurs et mot de passe par défautCertains comptes inutiles ou redondants proposés dans des versions obsolète de l'OXE (la version R9 est sortie cet automne) ont été supprimés dans le souci de limiter la surface d'exposition pouvant être exploitée. La liste des comptes comprend “mtcl, adm, halt, sync, shutdown, client et install.”
Ainsi, seuls onze comptes ont été maintenus. Les services FTP et de connexion sont désactivés sur les comptes pour lesquels ils ne sont pas nécessaires.
Les quatre principaux types de comptes sont :
• Root – super-utilisateur avec une connexion directe au por t de la console, FTP non valide,
• Swinst – assistant d'installation de logiciel avec une connexion et FTP valide,
• Mtcl – maintenance hors site pour les utilisateurs avec des droits restreints, connexion et FTP,
• Client – utilisateur pour une maintenance sélective. Ce compte est créé uniquement sur demande.
Pour voir plus de détails, veuillez consulter le Tableau 1.
Lors de l'installation initiale, si le niveau de sécurité sélectionné est suf fisant, une durée de validité est définie pour chaque mot de passe. Cette dernière aura une durée minimale de dix jours. Cinq jours avant la date d'expiration, un message d'avertissement est généré par le système pour chaque compte connecté. La limite de validité dans le temps d'un mot de passe peut être désactivée, ce qui of fre ainsi la possibilité de basculer dans un mode illimité (Tableau 1).
Pour finir, le système vérifie les tentatives de connexions infructueuses. Lorsque le nombre maximal d'échecs de connexion (défini dans la configuration) est at teint , un incident est généré. Et l'administrateur est informé qu'il se passe quelque chose d'anormal (potentiellement une attaque).
serveur d'authentificationL'OXE supporte l'authentification via un serveur d'authentification RADIUS pour les utilisateurs définis suivants: root, mtcl, swinst, adfexc, client. Le mécanisme d'authentification RADIUS est disponible pour :
• les applications Web (notamment l'outil d'administration Web),
• les modules additionnels Outlook/Lotus Notes,
• l'application 4980 Softphone,• l'application 4760.
Pour permettre la prise en charge des identifiants de connexion d'entreprise, le menu Swinst propose une inter face qui permet de déclarer ces données avec le profil du système associé.
Lorsqu'un utilisateur tente de se connecter à un serveur OXE avec ses propres identifiants d'entreprise au lieu des identifiants de connexion au système (root , mtcl, swinst , etc.) :
• les services (SSH, Telnet, Ftp, etc…) vérifient si l'utilisateur figure dans la base de données locale des utilisateurs du système,
• la demande d'authentification est transmise au serveur RADIUS,
• l'utilisateur reçoit le droit d'ouvrir une session,
• le serveur RADIUS enregistre l'heure de fermeture de la session (à des fins de facturation ou de statistiques).
les hôtes de confiancesLes systèmes Linux comprennent un fichier /etc/hosts.equiv qui répertorie les autres systèmes informatiques (Hôtes) reliés au réseau. Les adresses IP contenues dans ce fichier sont considérées comme fiables ; il s'agit du fichier hôtes de confiance.
Les systèmes répertoriés dans le fichier sont les seuls à être considérés comme fiables pour accéder au serveur de communication. Par défaut, cette fonction de sécurité refuse l'accès depuis toutes les autres adresses IP. Afin d'améliorer le système de sécurité, les connexions Ethernet sont traitées dif féremment des connexions PPP et SLIP sur l'interface EIA (RS232).Figure 4. Architecture globale avec PCS inclus
DOSSIER Téléphonie sur ip
15 HAKIN9 4/2009
Les hôtes de confiance incluent les postes IP, les Media Gateways et la gestion des postes. Il est possible d'intégrer la liste des adresses IP (pour les postes IP dans le fichier Hôtes de confiance).
le wrapper TCpLa fonction de Wrapper TCP fournit un service de filtre pour les serveurs Linux ou Unix. Lorsqu'un ordinateur Linux non protégé est connecté au réseau, le système informatique est exposé aux autres utilisateurs du même réseau. Un pirate peut réussir à détecter les utilisateurs connectés à un serveur spécifique et peuvent déterminer l'identité de chaque poste. Il peut savoir à quel moment le poste est au repos et accéder au contenu du système.
La fonction Wrapper TCP peut faire office de passerelle filtrante afin d'éviter tout accès indésirable.
Le Wrapper TCP intercepte et filtre toutes les demandes provenant du réseau Ethernet. Par exemple, si un ordinateur extérieur tente d'utiliser le service FTP, le Wrapper TCP vérifie si cet ordinateur dispose des droits nécessaires aux transferts de fichiers. En fonction du type d'autorisation, l'accès est refusé ou approuvé.
L'intégration du Wrapper TCP à l'offre accroît le niveau de sécurité en contrôlant l'accès Internet pour de nombreux services IP (FTP, telnet, shell, connexion et TFTP) qui sont liés au serveur de communication. Le client doit définir quelles sont les applications IP autorisées pour chaque adresse IP de la liste des hôtes de confiance.
Gestion des connexions à distance: rTCDans un environnement RTC, la solution RMA (Remote Maintenance Access) fournit un niveau de sécurité élevé pour le terminal de gestion à distance à un emplacement prédéterminé. Le dispositif RMA vérifie l'identité de l'administrateur distant au moyen d'un nom de connexion et d'un mot de passe, suivis d'un rappel. Lorsque le travailleur à distance est connecté au RMA, les nom de connexion et mot de passe sont de nouveau requis. La sécurité est garantie par cette double demande de nom de connexion / mot de passe.
Un rappel du travailleur distant est également possible.
Gestion des connexions à distance: rnisAvec une telle configuration, un travailleur distant peut atteindre directement le serveur de communication par l'intermédiaire d'une connexion RNIS. Ce type d'accès est principalement utilisé pour des opérations de maintenance à distance.
L'OXE contrôle la ligne par l'intermédiaire de la fonction CLIP (identification de la ligne appelante) envoyée par le réseau commuté public. Le travailleur distant envoie une identification de la ligne de l'appelant lors d'une demande de connexion. Si l'identification de la ligne de l'appelant correspond à celle configurée dans l'OXE, l'appel est accepté. Si l'identification de la ligne de l'appelant est inconnue, l'appel est refusé et le système génère une alarme.
la sécurisation des ip Media GatewaysLe firmware embarqué dans les media gateways est un micro kernel Linux composé uniquement des fonctions nécessaires au bon fonctionnement de la solution. Il ne s’agit en aucun cas d’un OS traditionnel avec les vulnérabilités inhérentes à ces derniers.
Gestion des attaques de type DosDes fonctions permettant de réduire au maximum les ef fets d’attaques de type dénis de service ont été directement intégrés à l’instar du travail ef fectué sur le firmware des IP Phones :
• limitation du trafic de type broadcast à 300 pps. Tout le trafic en excédent est supprimé,
• rejet de paquets pouvant être identifiés comme du trafic IP fragmenté.
L’accès à la console de la media gateway via le monde IP est uniquement réservé à l'OXE. Tout accès venant d’une autre source sera refusé.
séparation des mondes TDM et ipLe micro kernel linux utilisé par Alcatel-Lucent dans ses media gateways offre un lien unique entre le monde TDM et IP qui a aussi été conçu pour servir de barrière entre les deux mondes pour tout ce qui ne concerne pas directement la voix. On notera par ailleurs que la media gateway ne travaille pas comme un élément actif sur la solution de téléphonie, mais se contente de transférer au serveur OXE ou aux éléments actifs sur le réseau TDM la signalisation et le flux media. C’est pourquoi, les fonctions de routage IP, de
Figure 5. Signalisation de secours des media gateways
16
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
redirection de trafic IP ou de redirection ICMP ne sont pas implémentées, car inutiles pour les fonctions retenues.
On notera par ailleurs qu'il n’a été implémenté aucun service permettant d’autoriser un accès depuis les ressources TDM (ISDN, PSTN, etc …) vers les ressources IP. Les fonctions IP sont complètement isolées des trafics voix et signalisation.
Les seuls services supportés utilisant les technologies TDM et IP sont les suivantes :
• Création d’un tunnel vers le serveur OXE pour le trafic de signalisation (ISDN, CAS, etc …) permettant la gestion des dif férents appels. Tous les paquets n’étant pas en stricte concordance avec cette règle seront supprimés.
• Le flux voix est encapsulé dans des trames RTP pour être transporté par le réseau IP. Les destination des ces flux RTP sont sous contrôle de l'OXE et seuls les périphériques enregistrés sur ce dernier pourront recevoir ce flux.
• Les interfaces publiques ou privées (PRA) de la Media Gateway sont seulement capables de traiter la signalisation et de transférer le flux voix vers les fonctions interne de la Media Gateway le retraitant.
• Les ressources ToIP de la Media Gateway sont seulement capables d’adresser les protocoles de signalisations (H323, H245, H225, SIP, RAS, etc …) supportés par la solution OXE et de transférer les flux voix vers le LAN (respectivement de les recevoir).
signature des binairesLa release 8.0 de l’OXE a intégré un nouveau mécanisme au sein des media gateways permettant de valider la signature et l’intégrité des fichiers binaires reçus du serveur TFTP lors de la phase de démarrage avant leur prise en compte par le système.
Ainsi, lorsqu’un nouveau binaire est développé par Alcatel Lucent, il est signé à l’aide de la clé privé Alcatel Lucent. A la réception de ce nouveau binaire, la media gateway va vérifier l’intégrité du fichier à l’aide de la clé publique d’Alcatel Lucent (SHA1 et ECC 384 b). Si le contrôle
est négatif, le binaire est ignoré et la média gateway redémarre sur l’ancienne version.
Attention cependant, cette fonctionnalité ne sera disponible dans la solution que si cette dernière a été implémentée avec un module SSM.
la sécurisation des ip phonesIl existe plusieurs types de sécurisation des IP Phones.
le contrôle des VlAnLe paramètre strict vlan permet de filtrer les trames entrantes. Il sera activé dès qu’un VLAN est configuré sur les téléphones IP (soit au travers de l’AVA, soit de façon manuelle).
Si le paramètre strict vlan est activé, le téléphone rejettera les trames arrivant avec un mauvais tag (pas de VLAN ou un numéro de VLAN différent). Dans le cas ou le téléphone n’utiliserait pas l’option strict vlan, toutes les trames marquées seront rejetées.
la gestion du port pCLes téléphones IP ont deux ports ethernet, l’un d’entre eux étant destiné à accueillir un poste de travail. Le serveur d’appel possède plusieurs options permettant de le contrôler :
• L’option pc port security n’est pas activée (comportement par défaut), l’ensemble du trafic est transféré vers et depuis le port pc de façon transparente.
• L’option pc port security est bloquée: tout le trafic réseau de ce port est bloqué.
• Le mode filter vlan est retenu: le téléphone IP remplace tous les tag 802.1q des trames provenant du PC au profit du vlan ID 0. Le PC ne peut plus alors accéder au VLAN voix, bloquant ainsi toutes possibilités d’intrusion ou d’interruption de service par ce biais.
Ces éléments de configuration ne sont pas accessibles depuis les menus de configurations des téléphones.
Création d'une relation de confiance entre un ip phone et son oXeTrois mécanismes ont été implémentés pour améliorer le niveau de confiance entre téléphones IP et serveurs d’appel :
• Vérification de la requête TFTP : Lors de la phase d’initialisation, la première action réalisée par un téléphone IP est d’envoyer une requête au serveur TFTP contenant son adresse MAC. Le mécanisme présent au niveau
Figure 6. Architecture de l'authentification 802.1X
18
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
du serveur d’appel va vérifier si cette MAC adresse est déjà connue du système et en cours d’utilisation par le protocole de signalisation. Dans le cas ou l’adresse MAC serait connue et en cours d’utilisation, il est fort probable qu’il s’agit d’une attaque ou un pirate cherche à usurper l’identité d’un téléphone existant sur le système. Le serveur d’appel rejettera alors la requête TFTP.
• Vérification des messages de connexion : Lors de la phase d’initialisation, un téléphone IP va recevoir un message de connexion en provenance du serveur d’appel visant à établir la communication. Il est vital d’éviter une attaque de type MITM à ce moment pour éviter que le téléphone soit contrôlé par un serveur pirate. Pour protéger le téléphone, l’adresse source du message de connexion est comparée à l’adresse réelle du serveur d’appel (identifiée grâce au fichier de configuration). Si la comparaison est négative le paquet sera refusé par le téléphone.
• Protection contre le MAC spoofing : il s’agit ici d’un contrôle additionnel effectué sur le serveur d’appel. Lors de l’initialisation d’un téléphone, le serveur d’appel demande l’adresse MAC au travers d’un message spécifique. La réponse du téléphone est comparée à l’adresse précédemment identifiée (via le message startnoe). Si la comparaison est négative, une demande de ré initialisation du téléphone est envoyée par le serveur d’appel.
Gestion des attaques détournant le protocole ArpUn téléphone IP peut être attaqué au travers de deux axes principaux :
• ARP Spoofing (falsification de la réponse ARP après une requête ARP du téléphone) : ce type d’attaque se produit après une requête ARP du téléphone en envoyant une réponse ayant des informations visant à rediriger le trafic vers une destination dif férente. Le téléphone n’ayant pas d’entrée dans son cache ARP au moment de la requête, il n’a pas moyen
de contrôler la validité de l’information qui lui est envoyée pour dif férentier le bon grain de l’ivraie.
• ARP cache poisonning (injection de paquet detype gratuitous ARP) : dans ce cas de figure, un téléphone IP reçoit une réponse de type de type ARP reply sans avoir envoyé de ARP request. Si aucun mécanisme de protection n’est présent, le téléphone mettra son cache ARP à jour avec les informations reçues et sera donc empoisonné permettant la redirection du trafic vers un poste tierce.
Les protections mise en place au sein même du firmware des IP Phones répondent à ces deux problématiques :
• La fonction anti ARP spoofing : les téléphones IP sont capables de détecter la présence de réponses ARP multiples pouvant mettre en évidence une attaque. Une fois la détection réalisée, un log contenant les informations caractérisant l’attaque (à savoir adresse MAC, adresse IP et heure) est envoyé au serveur d’appel et peut éventuellement être relayé vers
Figure 8. Intégration des modules SSM et MSM
Figure 7. Automatic VLAN Assignment
DOSSIER Téléphonie sur ip
19 HAKIN9 4/2009
une plateforme de supervision au travers de traps SNMP.
• La fonction anti ARP cache poisonning : les téléphones IP ne réaliseront des mises à jour du cache ARP qu’à partir de paquets ARP Reply clairement demandés (ce qui n’est pas le cas des paquets gratuitous ARP). Les paquets gratuitous ARP seront ignorés, éliminant ainsi les risques de succès de ce type d’attaque.
Validation de l'intégrité des binairesLes téléphones IP utilisent le protocole TFTP pour télécharger les nouveaux binaires lors de la phase d’initialisation. Avant la prise en compte de ces derniers, un test d’intégrité via le CRC Checksum sera effectué. Si ce test est négatif, le nouveau binaire sera écarté au profit des anciens.
Dans un environnement sécurisé, les binaires des téléphones IP sont signés au moment de la mise en production avec la clé privé Alcatel Lucent. Le téléphone IP pourra alors valider l’intégrité des fichiers en utilisant la clé publique d’Alcatel Lucent.
Attention, même lorsque les mécanismes de chiffrement seront implémentés sur la solution d'Alcatel, les échanges TFTP resteront en clair.
protection du MMiL’interface home machine des téléphones IP permettant de gérer les paramètres réseau peut être protégée grâce à un mot de passe. Ce dernier est géré au niveau du serveur d’appel et doit avoir une longueur minimale de six caractères. Il est le même pour l’ensemble des terminaux de la solution de ToIP.
le 802.1XDepuis la release 7.0 de l’OXE, la gamme x8 des IP Touch (4008, 4018, 4028, 4038 & 4068) supporte le protocole 802.1X en version EAP MD5. La fonction générale du 802.1x peut être considérée comme une est une porte logique ON/OFF dans les commutateurs Ethernet. Cette porte est en position OFF au démarrage et gère uniquement les demandes de 802.1x jusqu'à la décision de donner un accès au téléphone IP. A ce stade, la porte est placée en position ON de sorte que l'ensemble du trafic du LAN peut être relayé entre le téléphone IP et le réseau en
amont. Eventuellement, une temporisation peut expirer ou le téléphone IP être déconnecté, ramenant la porte en position OFF. Cette authentification intervient avant tout autre échange.
L'architecture 802.1x comprend trois composants clés :
• le système à authentifier (demandeur), tel qu'un poste IP Touch,
• le serveur d'authentification (serveur) : un serveur d'authentification, d'autorisation et de taxation (AAA). Typiquement, un serveur RADIUS (Remote Access Dial-In User Security server),
• le système authentificateur: l'équipement réseau qui assure le contrôle d'accès (tel qu'un commutateur/routeur IP Ethernet).
La demande d’authentification devant être validée par le téléphone proviendra toujours du commutateur sur lequel il est raccordé. Elle interviendra dans les cas suivants :
• le téléphone IP est physiquement branché sur le réseau,
• redémarrage logique du téléphone IP (suite à perte de communication avec le serveur d’appel par exemple),
• re-authentification périodique configurée au niveau du commutateur.
Si aucune réponse ne provient au commutateur après la demande d’authentification du téléphone IP, un message authentication failure sera envoyé au téléphone IP. Ce dernier continuera alors la phase d’initialisation et re-essayera
20
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
de s’authentifier 30 s plus tard. Après trois tentatives infructueuses, le téléphone réinitialisera complètement le processus de démarrage.
Si un PC est connecté derrière le téléphone IP au travers du port PC dédié, une seconde authentification 802.1X aura lieu si les équipements de l’infrastructure supportent le multi session. Il faudra par ailleurs attendre la fin de la phase d’initialisation du téléphone IP pour pouvoir initialiser celle du PC.
la gestion dynamique des vlaNAlcatel utilise l'AVA (Automatic Vlan Assignment) pour placer chaque téléphone IP sur son VLAN. Ce mécanisme utilise les marques de trame (telles que définies dans la norme IEEE 802.1q) afin de placer le téléphone sur un VLAN (sous-réseau IP) spécifique.
Le mécanisme AVA (Figure 7) :
• la première demande DHCP vérifie le numéro VLAN. Cette demande est envoyée au VLAN par défaut,
• le serveur AVA répond à la demande avec le numéro VLAN et une adresse IP non utilisée. Certains routeurs vérifient la demande DHCP et une adresse IP non utilisée permet aux messages, de transiter correctement par le routeur,
• le téléphone IP, qui n'accepte que les offres du serveur Alcatel, reçoit l'offre et envoie une nouvelle demande DHCP avec une marque 802.1q. Cette marque place le poste dans le bon sous-réseau avec la bonne adresse IP,
• a réception de la deuxième offre, le poste accepte l'offre du serveur DHCP,
• cette offre contient toutes les informations (adresse IP et adresse IP du serveur TFTP) pour démarrer le poste IP.
le chiffrement dans la solution alcatel lucentLe chiffrement impose de lourdes contraintes de traitement sur les systèmes IP, un traitement contraignant se traduisant généralement par un allongement des délais. Il est important que, pour des communications VoIP en temps réel, le chif frement n'ait pas de répercussion sur
les délais. Pour rappel, les trois critères essentiels à respecter pour assurer une bonne qualité de la voix sont: la gigue, la latence et les pertes de paquets.
Afin de permettre d'établir des communications VoIP de qualité et chif frées, Alcatel et Thales ont choisi une solution de chiffrement matériel pour le serveur OXE et les Media Gateways, capable de traiter simultanément des milliers de sessions de signalisation et des dizaines de flux RTP VoIP avec un retard de transit inférieur à 1ms.
Le chiffrement matériel est 20 à 100 fois plus rapide que son équivalent logiciel, en fonction de la taille des paquets.
En ce qui concerne les téléphones de la gamme IP Touch, le chif frement s'effectue dans le microcode et n'a pas d'impact sur les délais. Par ailleurs, la gamme IP Touch a été conçue avec une mémoire de secours afin de pouvoir prendre en charge les lourdes contraintes du chiffrement si nécessaire.
les modules de sécuritéLes modules de sécurité SSM et MSM sont des composants cryptographiques qui se
trouvent entre le réseau local non sécurisé/sécurisée et la connexion sécurisée/non sécurisée pour les composants de l'infrastructure de téléphonie sur IP :
• SSM : protège le serveur de communication
• MSM : protège les passerelles IP Media Gateways
Bien que proches par leur aspect physique, les modules SSM et MSM ne fonctionnent pas de la même manière.
le module ssMLe module SSM est le composant central de la solution de sécurité IP Touch. Il est relié par un cordon de raccordement croisé RJ45 au serveur de communication sur le port non chiffré et au réseau non sécurisé sur le port chiffré. Ce module négocie et établit des sessions de signalisation chiffrées avec des téléphones IP ou des passerelles IP Media Gateways (via MSM), ou encore d'autres serveurs OXE eux mêmes protégés par ce composant. Il est transparent pour l'identifiant QoS (802.1p/DiffServ) à partir
22
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
des passerelles IP Media Gateways ou du serveur de communication. Du point de vue IP, il agit comme un pont (sans routage). Il gère également l'identifiant QoS basé sur la couche 3 et rend le trafic téléphonique (multimédia ou signalisation de contrôle des appels) prioritaire par rapport au trafic dif féré.
le module MsMLa passerelle IP Media Gateway (carte GD ou INTIP) est connectée au port non chiffré du module multimédia à l'aide d'un cordon de raccordement croisé RJ45. Le module MSM est chargé de chiffrer le trafic de signalisation IP Media Gateway vers le serveur OXE. Il chif fre également le trafic multimédia (vers d'autres modules multimédia, des téléphones IP, etc.) à l'aide de clés de session.
le chiffrement du flux médiaLes données multimédia (voix) sont chif frées à l'aide du protocole SRTP utilisant l'algorithme de chiffrement AES. L'avantage apporté par SRTP est l'absence de surcharge de la largeur de bande sur réseau WAN par rapport à un trafic non chiffré. Aucune complexité n'est ajoutée à la configuration des services réseau.
Des clés symétriques sont utilisées; elles changent à chaque session RTP. Elles sont transmises par le serveur OXE aux
points d'extrémité par le biais de sessions de signalisation cryptées. Le chiffrement transparent des modems (et télécopieurs) est également assuré (avec des contraintes par rapport aux délais).
Un appel passé entre deux téléphones IP enregistrés dans deux systèmes différents peut être chif fré si les deux nœuds sont sécurisés. Le chiffrement sur le réseau se fait également entre la passerelle IP Media Gateway d'un nœud et les téléphones IP ou entre deux passerelles IP Media Gateways.
le chiffrement de la signalisationLes téléphones IP et les passerelles IP Media Gateways sont contrôlés via des protocoles propriétaires appelés respectivement UA Noe et IP Link. La signalisation de contrôle des appels (du serveur vers les téléphones IP et du serveur vers les passerelles IP Media Gateways) est protégée à l'aide d'IPSec en mode ESP par l'algorithme de chiffrement AES.
Des clés symétriques sont négociées entre le téléphone IP et le module SSM et changées régulièrement. La signalisation de contrôle des appels se trouve ainsi protégée au niveau de la confidentialité et de l'intégrité. Les notions d'intégrité (non modification des messages) sont implémentées au travers d'une signature HMAC SHA1 du flux.
Pour gérer le cas d'une installation multi-nœuds, Alcatel a amélioré la fonction IP Security à partir de la release R7.1, de manière à permettre la mise en œuvre du chiffrement de la signalisation et des flux media en environnement ABC-F.
Les pré-requis suivants devront être respectés pour un bon fonctionnement:
• le noeud local, le noeud de transit et le noeud distant doivent tous être sécurisés,
• le lien hybride entre les noeuds devra être déclaré comme sécurisé.
Attention, la sécurité d'une communication est réévaluée à chaque fois que le processus de distribution des appels est invoqué. Ainsi, une communication pourra démarrer de façon sécurisée et continuer avec une sécurité dégradée si un transfert impliquant un nœud non sécurisé à lieu.
évaluation du niveau de sécurité par les utilisateursLe niveau de sécurité d'une conversation téléphonique est négocié dynamiquement entre deux téléphones. Par conséquent, il est extrêmement important que l'on puisse évalué d'un coup d'œil le niveau mis en œuvre pour une conversation donnée. Un utilisateur ayant besoin de cette fonction à un instant T doit absolument être capable de savoir si sa conversation est sécurisée.
Pour répondre à cette problématique, une signalitique visuelle est mise en place. Un cadenas sera présent sur l'écran en mode sécurisé, tandis qu'une bonhomme apparaitra en mode non sécurisé.
Focus sur une erreur de jeunesseComme évoqué ci-dessus, la solution IP Touch Security est basée pour les flux de signalisation sur l’établissement d’un lien IPSec grâce au mécanisme IKE. Au démarrage du système, les demandes de négociation IKE sont envoyées massivement au boîtier SSM-BOX. Sur les versions 1.5 et antérieures, le boîtier SSM-BOX essaie de satisfaire toutes ces négociations, et chaque nouvelle négociation ralentit les négociations déjà en cours. Par conséquent, le temps d’aboutissement d’une négociation IKE complète peut être relativement long et le poste IP Touch concerné peut redémarrer
DOSSIER Téléphonie sur ip
23 HAKIN9 4/2009
avant même la fin de sa négociation. Pour réguler les demandes, un limiteur du nombre de négociations entamées est mis en place à partir de la version 1.6. Ce limiteur a été calibré afin d’optimiser une mise en service complète pour un système jusqu’à à 3500 postes IP.
Les graphiques de la Figure 10 montrent l’impact du limiteur de négociation sur les temps de démarrage. Pour le démarrage d’un système de 3500 postes, à gauche, la version 1.5 n’a pas permis la stabilisation après 9h, et à droite, la mise en système est terminée en moins d’une heure avec la version 1.6.
Les IP Touch Security Module traitent les messages reçus dans l’ordre chronologique grâce à une file de traitement. Cette dernière intègre des mécanismes de QoS pour la protection des flux indispensable au fonctionnement du système. Son dimensionnement, pour les versions 1.5 et antérieures, est basé sur une répartition semi-aléatoire des flux. La synchronisation des flux nécessite l’augmentation de la taille de cette file. Cela permet d’absorber les pics de trafic prioritaire, et réduit ainsi la perte de trames provoquant le redémarrage intempestif des IP Touch mais, en contrepartie, cela peut augmenter la latence maximum pour traiter une trame. La solution mise en œuvre, à partir des versions 1.6 des SSM-BOX, consiste en un redimensionnement des files de traitements allié à des optimisations de traitement permettant ainsi la prise en compte de la double contrainte d’absorption des pics de trafic prioritaire, et de minimisation de la latence maximale.
Les ajustements réalisés pour la version 1.6 ont ramené les mises en service dans un comportement prédictible pour tous les types de parc, le temps de mise en service sécurisé étant de moins d’une seconde par poste, soit environ 50 min pour un parc de 3500 postes. Ces ajustements corrigent aussi les phénomènes de redémarrage aléatoire de poste IP Touch et prennent en compte les phénomènes de synchronisation du parc.
La Figure 11 basée sur des tests avec une version de firmware 2.0.6, montre une optimisation permettant de descendre à 25 mn.
Mise en évidence pratique du rôle des éléments de sécurisationD`abord on commence par le script AlcatelCallBreaker et la mise en évidence du rôle du chiffrement de la signalisation. Le chiffrement des dif férents flux d'une solution de ToIP peut rester un peu abscons vis à vis d'un utilisateur externe. Pour démontrer ces fonctionnalités, après des recherches infructueuses sur le web, j'ai été amené à développer le script AlcatelCallbreaker pour mettre en évidence l'importance de ce rôle sur la signalisation.
Ce script a été créé pour mettre en œuvre un déni de service sur les postes IP avec le protocole de signalisation propriétaire d'Alcatel. L'idée est tout simplement d'envoyer la séquence de raccroché à un poste téléphonique lorsque l'on détecte qu'il est actif sur le réseau. Ceci se déroule en trois étapes principales:
• réalisation d'un man in the middle pour voir passer la signalisation,
• écoute des paquets de signalisation,• envoi de la charge pour réaliser un
dénis de service sur les IP Phones.
Une fois la charge envoyée, le poste va l'interpréter si les compteurs du protocole de signalisation sont correctement implémentés. Après acceptation des paquets, le téléphone va se retrouver synchrone avec les compteurs du poste attaquant et non plus de l'OXE, ce qui va provoquer un gel du poste dans un premier temps, puis un redémarrage après une à deux minutes d'inactivité.
La mise en pratique du concept énoncé ci-dessus a été réalisé à l'aide des éléments suivants :
• vconfig pour se placer dans le vlan voix,
• ettercap pour réaliser le man in the middle,
• scapy pour la génération des paquets de la charge.
Si vous utilisez ce script sur un environnement sécurisé, vous pourrez constater qu'il est devenu totalement inoffensif. En ef fet, en mode sécurisé, notre téléphone ip utilise IPSec pour sécuriser son flux. Les messages envoyés par l'attaquant arrivant en clair, ils ne seront pas pris en compte et l'attaque aura ainsi échoué.
• Rq1 : Il me semble important de préciser que pour que cette démonstration prenne forme, il est absolument nécessaire de supprimer toute les possibilités de combattre les MITM via ARP cache poisonning. En ef fet, si le script ne voit pas le flux de signalisation passé, il sera totalement inoffensif.
• Rq2 : même si nous réussissons un MITM dans un environnement chif frant les flux, le script sera incapable d'interpréter la signalisation protégée par IPSEC. Sans interprétation cohérente, il n'y aura donc aucun envoi de charge offensive.
• Rq3 : le même type d'expérience pourra être mis en œuvre sur le flux
24
DOSSIER
HAKIN9 4/2009
Téléphonie sur ip
média avec des utilitaires permettant d'insérer des messages dans le flux RTP (RTPInsertSound, RTPInject ou RTPMix).
Mise en évidence de l'intérêt du 802.1XPour mettre en évidence l'importance des contrôles d'accès au réseau dans un environnement de téléphonie sur IP, je vous propose de jouer avec l'accès au VLAN voix. Pour cette démonstration, j'ai repris l'excellente idée ayant donné naissance au script Voip Hopper en environnement Cisco et l'ai adapté au monde Alcatel-Lucent. Cela a donné naissance à Plawava (Playing with AVA).
Comme évoqué précédemment dans cet article, les téléphones IP reçoivent l'information VLAN voix au travers de l'option propriétaire 43 distribuée par le DHCP. L'idée ici est donc de prendre le câble reliant un téléphone IP au réseau et d'émuler son comportement pour faire réagir le DHCP et recevoir une réponse.
Pour arriver à ce résultat, il suffit de créer un paquet de type DHCP discover reprenant le formalisme des IP Touch. La Figure 13 montre la mise en application dans plawava.
Une fois le DHCP discover émis sur la vlan data, le poste de l'attaquant va
réceptionner la réponse, l'analyser et se placer dans le VLAN voix en utilisant le protocole 802.1q. Le résultat final du script est présenté en Figure 14.
La mise en œuvre de plawava a été réalisée au travers des outils suivants :
• la langage perl,• le module perl net::dhcp:packet .
Les commandes systèmes vconfig et dhclient.
Un script comme plawava montre que l'utilisation de vlan ne résout pas toutes les problématiques de sécurité. Si une fois sur le réseau, cela permet une bonne séparation des flux, jouer avec en amont pour se placer directement dans le VLAN voix peut permettre de contourner cet élément.
Le paramétrage du 802.1x sur les ports des utilisateurs permettra de bloquer totalement ce type de script. En effet, sans une authentification positive, aucun accès réseau ne sera ouvert sur le lien. Les possibilités d'attaques sont donc alors très fortement réduites.
pour conclureVous aurez pu voir dans cet article que l'éditeur Alcatel Lucent a réellement fait l'effort de fournir une solution de téléphonie sur IP intégrant la sécurité de bout en bout.
Néanmoins, la solution présentée est réduite à son minimum et n'intègre par un écosystème évolué. Il sera souvent nécessaire de refaire tout ce travail soi même pour obtenir un environnement sain et sécurisé, les écosystème n'arrivant que rarement sous forme d'appliance. Cette remarque peut paraître anodine au premier abord, cependant, il n'est pas rare de constater que cet aspect des choses n'est pas toujours pris en compte par des équipes de téléphonistes n'ayant pas les cultures systèmes et réseaux nécessaires pour avoir une vision globale des problématiques de sécurité. Ceci montre bien la nécessité de désormais travailler avec des équipes pluridisciplinaires.
Par ailleurs, n'oublions pas non plus que la sécurité dépend aussi très fortement de deux éléments qui n'ont pas été abordés, à savoir l'infrastructure et les processus. Le LAN me semble très important à prendre en compte pour apporter la sécurité au plus près des ports utilisateurs et sécuriser ainsi le périmètre le plus en amont possible. Un certain nombre d'articles traitant de ce sujet sont parus dans le hors série Cisco, l'un d'entre eux étant disponible en téléchargement gratuit sur le site du journal. Je ne peux que vous recommander de les lires si ce n'est déjà fait.
Cédric BailletAprès avoir travaillé pendant quatre années sur les technologies réseaux Cisco en tant qu'ingénieur de production, Cédric Baillet a été consultant sur les solutions de ToIP et les problématiques sécurité afférentes de 2004 à 2007. Il a aujourd'hui intégré une des équipes marketing d'Orange Business Services pour travailler sur les offres de services sécurité autour des nouvelles solutions de communications.
sur internet• Alcatel-Lucent : http://www.alcatel-lucent.com• RTPInsertSound : http://www.voipsa.com/Resources/
tools.php• RTPMix : http://www.voipsa.com/Resources/
tools.php• RTPInject : http://www.voipsa.com/Resources/
tools.php• AlcatelCallBreaker : http://www.cedric-baillet.fr/
spip.php?article11• Plawava : http://www.cedric-baillet.fr/
spip.php?article6