Vous êtes sur la page 1sur 17

1.

Périmètre du projet

Il s’agit de définir le périmètre du projet. Il concerne le cadre et la nature d’implémentation. Nous


utiliserons dans ce cas précis les simulateurs pour réaliser le projet afin d’avoir les résultats, faire les
analyses et tirer une conclusion par rapport aux objectifs attendus.

Figure 1: Architecture du réseau VoIP à réaliser

2. Matériels requis

Les équipements qui seront déployé dans notre cadre d’étude pour réaliser les tests sont :

- Un Serveur sur lequel sera installé le CUCM ;


- Un Serveur sur lequel sera installé Unity ;
- Un serveur Windows 2016 sur le quel seront installer le rôle AD, service NTP ;
- Deux (2) clients, sont des machines sur lesquelles sont installé le système
d’exploitation Windows et un client ZoiPer installé sur un Android.
3. Installation et configuration

3.1. Le Serveur Windows 2016

Voulant évoluer dans le même environnement de travail que celui de la banque, nous allons installer un
serveur Windows avec le rôle AD. La base de données des utilisateurs sur le serveur LDAP 1 sera rattaché
au serveur CUCM important automatiquement tous ces utilisateurs vers la base de donnée du CUCM.

Figure 2: Serveur Active Directory déployé sous Windows server 2016

3.2. Mise en place du CUCM et UNITY

Nous installons les serveurs le CUCM et UNITY:

- Cisco Unified Communications Manager est un logiciel gérant le traitement d'appel


au sein d'une solution Cisco Unified Communications. Elle permet à l'entreprise
d'étendre les services de téléphonie aux équipements réseaux comme les téléphones
IP, les passerelles VoIP ou encore les applications multimédia. Le CCM peut aussi
gérer les conférences multimédia, les boîtes vocales, les softphones, les logiciels de
messagerie instantanée ou encore les services SMS.
1
Lightweight Directory Access Protocol, RFC4511. Référence: J. Sermersheim, Ed., Novell, Inc., Lightweight Directory Access
Protocol (LDAP): The Protocol, https://tools.ietf.org/html/rfc4511, june 2006
- Cisco Unity reçoit des appels, diffuse les salutations, enregistre et code la messagerie
vocale. Lors de la réception d'un message vocal, Cisco Unity ajoute le fichier .wav à
un courrier électronique et l'envoie au compte de messagerie configuré. Cisco Unity
crée une boîte aux lettres d'abonné sur le serveur Microsoft Exchange à utiliser
comme serveur de magasin de courrier pour le stockage des messages.

Les serveurs qui hébergerons notre plate-forme CUCM est un VMware Workstation fonctionnant avec
l’IOS CSInstall_UCOS_11.5.1.10000-6. Une fois la plate-forme préparée, on boot le système avec son
fichier ISO. Une fois le système lancé, on suit les différentes étapes de d’installation et de paramétrage.

Figure 3: Fenêtre à la fin de l’installation du CUCM

Figure 4: Fenêtre à la fin de l’installation du CUCM


6.2.1. Configuration du CUCM et de UNITY
Les différentes phases de configuration effectuées sur le serveur CUCM :
- Enregistrement du serveur en mode Publisher ;
- Activation du serveur NTP et du Time-Zone ;
- Personnalisation des options de Enterprise Parameters Configuration ;
- Activation du serveur LDAP ;
- Activation des services supplémentaires tels que Ciso TFTP 2 et Cisco DirSync ;
- Configuration du LDAP Directory et synchronisations avec serveur AD de Windows ;
- Création des profils de téléphone (SIP Phone) ;
- Configuration du Voice Mail, du SIP Trunk Profile.

A cette étape, notre serveur peut recevoir des appels.

6.2.2. Paramétrage des Phones


Les protocoles SIP et SCCP sont utilisés pour les phone qui sont paramétrés dans le CUCM. Ci-dessus les
informations relatives aux protocoles :

Figure 5: Liste des téléphones

La figure 15 affiche les catégories de phone créés, le type d’utilisateur et les protocoles auxquels ils sont
affectés.

2
Trivial File Transfer Protocol, RFC783. Référence: K. Sollins, MIT, THE TFTP PROTOCOL (REVISION 2),
https://tools.ietf.org/html/rfc1350, july 1992
Figure 6: Profile du Phone avec le protocole SIP

La figure ci-dessus décrit le processus d’enregistrement d’un phone avec le protocole SIP. Dans les
options «  Device Security profile », choisir « Cisco IP Communicator – Stantard SIP Secure Profile  ».
Ensuite dans les options « SIP Profile », choisir « Standard SIP  Profile ».
Figure 7: Profile du Phone avec le protocole SCCP

La figure 17 décrit le processus d’enregistrement d’un phone avec le protocole SCCP. Dans les options
«  Device Security profile », choisir « Cisco IP Communicator – Stantard SCCP Secure Profile  ».
Figure 8: Softphone de l’utilisateur ‘‘comptabilité’’ (SIP)

La figure 18 décrit les phases de configurations d’un sopftphone fonctionnant avec le SIP pour qu’il
puisse s’authentifier sur le serveur call manager.

Figure 9: Softphone de l’utilisateur ‘‘juridique’’ (SCCP)

La figure 19 décrit les phases de configurations d’un sopftphone fonctionnant avec le SCCP pour qu’il
puisse s’authentifier sur le serveur call manager.

7. Sécurisation de la solution mise en en place

A cette étape, la communication entre les téléphones et le serveur CUCM est opérationnelle. Le voice
mail sur le serveur UNITY est disponible. La problématique est de savoir si les échanges entre ses
différentes entités sont réellement sécurisés.
Nous allons utiliser deux (2) approches pour vérifier le niveau de sécurisation de réseau :

- Approche physique ;
- Approche logicielle.
7.1. Vérification de l’interface du téléphone utilisateur

Il s’agit de l’approche physique. C’est une analyse qui permet de vérifier physiquement les
configurations que les téléphones ont présentées.

Figure 10: Les interfaces en mode "Non Secure" - un CTL File "Not Installed"

L’image à gaude de la figure 20 indique que le téléphone est enregistré sur la call manager mais le CTL 3
n’est pas installé. Par conséquent, la seconde image à gauhe indique que le phone est en mode en non
secure

7.2. Collecte d’informations sur le réseau

Nous utilisons Wireshark pour cette collecte. Cet outil permet de capturer des paquets directement sur
les interfaces du système utilisé ou de lire des fichiers de captures sauvegardées. Wireshark supporte les
formats de fichiers de capture les plus courants : libpcap/tcpdump, Sun's snoop/atmsnoop, LanAlyzer,
MS Network Monitor, HPUX nettl, AIX iptrace, Cisco Secure IDS.
Les extraits du résultat du test sont représentés par les figures 23 ; 24 et 25

3
Certificate Trust List
Figure 11: le résultat du test avec Wireshark

Une capture de paquet est réalisée sur la figure 21. Ce sont des paquets interceptés par l’outil Wireshark
sur le réseau. Les adresses IP, les protocoles et les ports utilisés sont affichés en texte clair. La
communication n’est pas sécurisée. Tout attaquant peut avoir accès facilement à ses informations.

Nous allons toujours avec le Wireshark, récuperer le flux audio dans la capture de paquets précédentes.

Figure 12: Communications téléphonique interceptées et décodées

Le flux audio récupéré sur la figure 22. Il est audible.


Figure 13: Flux RTP

Capture de flux RTP sur la figure 23 avec les adresses source, destinatin, ports et autres informations
qu’un pirate peut utiliser.

7.3. Choix et implémentation des bonnes pratiques de sécurité

Les analyses affichent des résultats qui montre un niveau de sécurité faible par ce que nous avions pu
écouter les communications juste avec l’outil Wireskark. Toute personne malicieuse en interne ou ayant
pu accéder au réseau de l’externe peut dans ces conditions récolter des informations ou effectuer des
attaques de tous types. Pour se protéger contre les attaques, nous avons choisi un ensemble de
solutions qui peuvent aider à minimiser les menaces, nous ne pouvons pas dire que les solutions
proposées et implémentées sont efficaces à cent pour cent parce qu’il existe toujours des problèmes de
sécurités.

7.3.1. Bonne pratiques contre les écoutes clandestines


La technologie offre une multitude de solutions pour sécuriser les réseaux VoIP et réduire les attaques.
La solution mise en place offre par défaut certains outils pour augmenter le niveau de sécurité. Il existe
des solutions payantes que nous pouvons ajouter. Nous avons :

- L’activation du Mixec-mode ;
- La création d’un Secure Phone Profile ;
- L’utilisation des Certificats.

7.3.1.1. Activation du mixed-mode dans Publiser

Entrer la commande suivante dans le CLI :

Redémarrer les services Callmanager et TFTP Aller dans les options « Cisco Unified Serviceability ».

Vérifier si le mixed-mode est activé Aller dans les options «  Enterprise Parameters Configuration ».

Après activation, le « Cluster security Mode » passe à l’état « 1  »

7.3.1.2. Créer un Secure Phone Profile

Dans les options paramètres du « Phone Security Profile » choisir :

- Mode : Encrypted
- authentication: mode sera "By Null String".
- L’algorithme: RSA
Figure 14: Phone Security Profile

Sur l’image ci-dessus (figure 24) le RSA 2048 bits est choisi. C’est le niveau le plus élevé. Sur le device des
Phone, il faut choisir le profil « Standard SIP Secure Profile » précédemment configuré dans le « Phone
Security Profile ».
Figure 15: Device information

7.3.1.3. Utilisation des Certificats

Les certificats d'importance locale (CAPF 4) ou (LSC5) sont signés localement. Il esr aussi possible d'utiliser
des LSC signés par une autorité de certification tierce (PKI 6).

7.3.2. Résultats après sécurisation


Pour sécuriser les communications et réduire une quelconque attaque, nous activons « mixed-mode » et
configurons le « Secure phone profile » dans notre call manager.aussi.

4
Certificate Authority Proxy Function
5
Locally Significant Certificates
6
Public Key Infrastructure
Figure 16 : Capture de paquet sur le réseau après sécurisation

Une fois les mesures de sécurité mise en place, une nouvelle tentative de capture de paquet est faite. Le
résultat affiché à la figure 26 indique zéro (0) paquet capturé. Les informations sont cryptées.

Vérifions à nouveau l’état des phone.

Figure 17: Phone sécurisé

L’image à gauche de la figure 27 montre qu’un certificat, le LSC dans notre cas est installé. Par
conséquent la seconde image à droite affiche un cadenas, cela signifie que les échanges ou données
entre le phone et le call manager sont cryptées.

Conclusion

Nous avons pu implémenter la phase pilote du projet dans ce chapitre. Les travaux suivant ont été
effectué:
- L'expression du besoin et définition d'une nouvelle architecture réseau VoIP
- L'installation et configuration des serveurs CUCM et Unity
- La Sécurisation de la solution mise en en place

C’est à l’issue de ces implémentations que nous sommes arrivés à bout de notre mission.

Vous aimerez peut-être aussi