PPD

Pré-projet de diplôme

Système de Détection d’Intrusion VoIP :

IPS-1 Check Point
7 janvier 2008
 Table des matières

Introduction 4
Contexte et aperçus des activités . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1. IPS-1 Check Point 6

1.1. Description de l’IPS-1 Check Point . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Déploiement des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Installation et configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1. IPS-1 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2. IPS-1 Alerts Concentrator et IPS-1 Server . . . . . . . . . . . . . . . . . 10
1.4. L’IPS-1 Management Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2. Présentation de l’interface . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.3. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2. Packages et Backends 29
2.1. Configuration du policy group sipOnly . . . . . . . . . . . . . . . . . . . . . . . 31

3. Tests 36
3.1. Topologie du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2. Les attaques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1. ARP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.2. Injection de paquet SIP malformé . . . . . . . . . . . . . . . . . . . . . . 47

4. Synthèse et conclusion 58

5. Cahier des charges 60

5.1. Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.1. Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1.2. Description générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2. Travaux à réaliser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.1. Tutorial du langage N-code . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.2. Ecriture des règles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3. Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table des matières 3

5.3.1. Journal de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3.2. Outil de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A. Systeme de Détection d’Intrusion 63

A.1. Types d’IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.1.1. Network IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.1.2. Host IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.1.3. Les IDS “Hybrides” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2. Les méthodes de détection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.3. Où doit on placer l’IDS dans une topologie réseau . . . . . . . . . . . . . . . . . 65
A.4. Qu’est ce qu’un système de prévention d’intrusion ? . . . . . . . . . . . . . . . . 66
A.4.1. Présentation de l’IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
A.4.2. Les types d’IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B. Outils utilisés 68
B.1. Script permettant d’exécuter l’attaque BYE . . . . . . . . . . . . . . . . . . . . 68
B.2. Fichier de configuration : nfr ida.cfg . . . . . . . . . . . . . . . . . . . . . . . . . 68
B.3. Générateur de message SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.4. Tableau des Attaques SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

C. Journal de Travail 72
 Introduction

Contexte et aperçus des activités

Le projet dont il est question dans ce document s’inscrit dans le cadre du travail de diplôme
sanctionnant la fin des études d’ingénieur HES à la HEIG-vd. Le but de ce travail est d’effectuer
une série de tests pour des systèmes de détections d’intrusion (IDS) couvrant le trafic VoIP. Ce
projet traite un des domaines couvert par le projet de recherche Vadese (www.vadese.org). Ce
dernier a pour objectif d’étudier entre autre les aspects de sécurité de la VoIP et de proposer
des solutions qui aident les entreprises :
– à réaliser des solutions de sécurité pour les réseaux VoIP (Best Practices, IDS, analyse de
logs)
– à évaluer l’efficacité et le fonctionnement correct des solutions déployées (audit, système de
test).
Au départ il s’agissait de mettre en place la sonde Snort et d’écrire quelques règles pour les
filtres, cette idée a été abandonnée et a été remplacée par l’étude de l’IDS SourceFire. Celui-ci
sera rapidement abandonné car la société Check Point nous propose d’évaluer leur IDS appelé
IPS-1 Check Point.
La phase de pré-projet de diplôme a donc consisté à installer et à configurer l’équipement IDS
mis à disposition, à mettre en place le réseau de test et à effectuer une série de tests permettant
d’évaluer l’IPS-1 Check Point.

Organisation du document
Chapitre 1, l’IPS-1 Check Point
Une description de notre IDS sera présentée au lecteur ainsi que les étapes d’installation et de
configuration de chaque composant de l’IPS-1 Check Point.
Chapitre2, Packages et Backends
Dans ce chapitre sera défini les packages et backends qui contiennent les régles de filtrage
appliqués à notre sonde.
Chapitre 3, Tests
Il s’agira de mettre en place le réseau de travail et d’effectuer des attaques VoIP.
Table des matières 5

Chapitre 4, Synthèse
A partir des tests effectués dans le chapitre précédent une évalution de la sonde fera l’object de
ce chapitre.
Chapitre 5, Cahier des charges
Celui-ci sera consacré à une description de l’objectif principale du travail de diplôme qui se
déroulera du 18 septembre au 12 décembre 2007.
Annexes
Enfin la dernière partie regroupera les annexes dont une explication des IDS, une description
des outils utilisés et un journal de travail qui a accompagné l’auteur durant tout le projet.
 1
IPS-1 Check Point

La Voix sur IP (VoIP) est un sujet extrêmement en vogue actuellement et bon nombre de
travaux y relatif ont été menés à terme ou sont en cours de réalisation. En effet de nombreuses
entreprises adoptent ce mode de communication. Elle consiste à encoder la voix et à la faire
passer par un réseau IP, qui peut être internet ou un réseau privé. Malheureusement ce type de
service présente des failles au niveau de la sécurité. Des équipements appelés Intrusion Detection
System (IDS) sont équipés de fonctions spéciales appelées filtres qui permettront de surveiller
le réseau informatique et de détecter toutes anomalies. Dans le cadre de notre travail l’IDS
IPS-1 Check Point sera utilisé dans le but de détecter les attaques SIP et les vulnérabilités de
ce protocole.
Dans la présente section, une description de cet IDS, ses fonctionnalités ainsi que les étapes
d’installation et de configuration seront décrites.

1.1. Description de l’IPS-1 Check Point

L’IDS que nous étudierons est développé par la société Check Point spécialisée dans la fa-
brication des équipements pour améliorer la sécurité. L’IPS-1 Check Point comme son nom
l’indique est un système de prévention d’intrusion (IPS). Sa fonction principale est d’empêcher
toute activité suspecte au sein du réseau d’une entreprise. Mais il peut fonctionner en plusieurs
modes :
– mode Passif : Dans ce mode l’IPS-1 se comporte comme un système de détection d’in-
trusion. Sa fonction serait de surveiller uniquement le trafic et d’analyser toute tentative
d’effraction. Mais nous notons que dans ce mode l’IPS-1 reçoit une copie du traffic pour
l’analyse de détection d’intrusion et soulèvera des alertes en conséquence. Dans ce projet
c’est ce mode qui sera activé.
– mode Inline bridged : le mode bridge n’effectue pas de prévention en cas de détection
d’attaque. Il se comporte presque comme en mode passive. Ce mode fourni une transition
entre la détection et la prévention, l’utilisateur peux observer le fonctionnement de l’IPS-1
en évitant de rediriger ces attaques. Ce mode est utilisé pour l’équipe de gestion du réseau
dans le sens où il permet d’accéder depuis le réseau à la sonde sans que celle-ci ne soit en
mode de prévention.
1. IPS-1 Check Point 7

– mode Inline prevention : Contrairement aux autres modes, l’IPS-1 se comporte comme
un système de prévention d’intrusion. En plus de détecter une intrusion, il tente de la bloquer.
L’IPS-1 Check Point se décompose en quatre composants qui sont : IPS-1 Sensor, IPS-1 Alert
concentrator, l’IPS-1 Server et l’IPS-1 Management Dashboard.

IPS-1 Sensor
La sonde est chargée de surveiller le trafic sur le réseau afin d’analyser les flux de données
et d’émettre des alertes à destination du concentrateur (IPS-1 Alert concentrator ) en cas de
détection de paquets non-conformes. Comment fait-il cette distinction ? Il existe des packages
regroupant un ensemble de régles spécifiques à chaque type de protocole. Ces règles sont écrites
dans un langage de script N-code de telle sorte que si ces derniers sont violés le flux de données
est jugé non conforme ainsi la sonde enregistre l’évènement comme une attaque. Ces packages
sont subdivisés en sous catégories (Backends) qui permettent de cibler le type d’attaque.

IPS-1 Alert concentrator et IPS-1 Server

L’IPS-1 Alert concentrator et l’IPS-1 Server sont regroupés en un bloc qui permet de stocker
les alertes envoyés par la sonde. Cela permet également de répartir la charge du réseau et donc
de déployer si nécessaire un nombre de sondes plus important.

IPS-1 Management Dashboard

L’IPS Management Dashboard permet la visualisation et le traitement des informations fournies
par le système de détection d’intrusions. Les alertes sont affichées en temps réel et peuvent
être classées en fonction de leur gravité. Cet affichage permet également de naviguer entre les
différentes alertes. De plus il est possible de visualiser les caractéristiques de chaque alerte
(le nom de l’alerte, le package et les backends qui ont permet de générer l’alerte, les adresses
source et destination, les ports source et destination). D’autres manipulations sont égalements
possibles : génération de graphes, visualisation des alertes selon la date désirée, visualisation et
ajout des utilisateurs...
L’architecture du produit est repésentée sur le schéma-ci dessous :
1. IPS-1 Check Point 8

Fig. 1.1.: Architecture de l’IPS-1

1.2. Déploiement des scénarios

La mise en place des différents composants de l’IDS à l’interieur d’un réseau porte le nom de
scénario. Check Point en propose deux :
– Le small deployement : dans ce cas IPS-1 Alerts Concentrator et IPS-1 Server sont installés
sur la même plateforme.
– Le large deployement : dans celui-ci IPS-1 Alerts Concentrator et IPS-1 Server sont installés
sur des plateformes différentes.
Dans le cadre du travail de diplôme sera utilisé le small deployment.
1. IPS-1 Check Point 9

Fig. 1.2.: Small Deployement

1.3. Installation et configuration

L’installation de l’IPS-1 Check Point consiste à installer chacun de ses composants en suivant
l’ordre ci-dessous.
1. IPS-1 Sensor est une appliance pré-configurée. Il est le premier composant à être intallé.
2. IPS-1 Alerts Concentrator et IPS-1 Server : ces deux composants seront ensuite installés
simultanément sur une distribution linux CentOS version 4.
3. IPS-1 Management Dashboard est une application cliente développée java et sera installé
sur windows XP.

1.3.1. IPS-1 Sensor

L’IPS Sensor nommé IPS-1 50C est une appliance pré-configurée. Mais dans le cadre de notre
étude elle a été livrée sous forme de logiciel et a été installé sur un ordinateur (PC) ayant
comme distribution Linux Fedora.
Le principal objectif de la sonde est l’écoute du réseau et la capture des paquets suspects. Notre
PC possède deux cartes d’interface réseau qui lui permettront de voir tout ce qui transite par
le câble Ethernet. Un des ports sera utilisé pour la gestion de la sonde et l’autre sera défini
comme un port monitoring qui permettra de renvoyer sur ce port relié au switch la totalité du
trafic du réseau. Afin de renifler tous les paquets sur le réseau, notre sonde a été configurée en
mode passif donc se comportant comme un IDS furtif.
Avant que l’IPS Sensor soit opérationnel la configuration par défaut doit être remplacée pour
être adaptée aux caractéristiques de notre réseau de test. Elle peut s’effectuer de deux manières :
– Il est possible de configurer l’IPS-1 Sensor manuellement à travers le menu de l’interface de
l’IPS-1 Management Dashboard. Cette configuration vous sera présentée dans la section 1.4.3
aprés l’installation de l’IPS-1 Management Dashboard.
1. IPS-1 Check Point 10

– L’autre méthode s’effectue en créant une disquette de configuration qui sera utilisée pour la
configuration des autres IPS-1 Sensor. Il s’agira d’éditer un fichier texte “nfr ida.cfg”contenant
toutes les valeurs nécessaires à la configuration ainsi lors de la configuration d’une autre sonde
il suffira juste d’adapter ces variables par rapport au réseau défini.
Dans le cadre de notre projet nous avons utilisé la configuration manuelle cf. annexe les para-
mètres de la configuration.

1.3.2. IPS-1 Alerts Concentrator et IPS-1 Server

L’installation de ces deux composants nécessitent préalablement un compte utilisateur. C’est
par ce compte que nous pourrons nous connecter à l’interface cliente l’IPS-1 Management Da-
shboard. Celui-ci permettra d’effectuer les configurations du serveur et de la sonde, de visualiser
des alertes et d’effectuer d’autres manipulations. Cet utilisateur portera le nom “nfr” et comme
tout utilisateur, il ne possède pas tous les privilèges que l’administrateur (root). A l’emplace-
ment suivant :” etc ⇒ sudoers“ se trouve le fichier de configuration sudoers permettant de
modifier les droits de ce dernier en lui attribuant les mêmes privilèges que le root. Les étapes
décrites ci-dessus sont illustrées par les commandes ci-dessous qui devront être exécutées en
tant que root.

1. Créer un répertoire où sera installé le produit :

mkdir /usr/local/nfr
2. Créer le groupe nfr :
/usr/sbin/groupadd nfr
3. Créer un utilisateur nfr :
/usr/sbin/useradd -g nfr -d /usr/local/nfr nfr
4. Mot de passe pour l’utilisateur nfr :
passwd nfr
5. Modification du propriétaire :
chown -R nfr :nfr /usr/local/nfr

La première étape consiste à monter le CD d’installation puis à installer l’IPS-1 Alerts Concen-
trator et l’IPS-1 Server. Lors de cette étape nous définirons d’une part l’emplacement du fichier
de configuration (sentivist.conf ) et d’autre part l’emplacement du fichier log (IPS-1 install.log).
Ayant choisi de déployer le scénario “small deployement” nous préciserons alors que l’IPS-1
Alerts Concentrator et l’IPS-1 Server seront installés sur la même plateforme.

1. Monter le CD-ROM :
mount /media/cdrom
2. Se loguer sur l’utilisateur nfr :
su - nfr
3. Changer d’emplacement et se placer sur le répertoire CD-ROM :
cd /media/cdrom
4. Installation :
./install
1. IPS-1 Check Point 11

5. Création de l’emplacement et du nom du fichier de configuration :

default = /usr/local/nfr/sentivist.conf
6. Nom et emplacement du fichier log :
default = /tmp/IPS-1 install.log
7. Installation des différents composants du Check Point, le menu suivant apparait :
Combo (both servers)= 2 (Installs both) [0/1/2] (default =2) .
Cette instruction permet de préciser que l’alert concentrator et le serveur seront installés
sur la même plateforme et qu’une seule instalation suffit.
8. Emplacement de l’IPS :
default = /usr/local/nfr
9. Selection du type d’OS :
Enter the Operating System (Linux|SunOS) default = Linux.

Une fois exécutées les commandes ci-dessus vient une deuxième étape qui consiste à définir le
nom du serveur, l’adresse IP du serveur et les différents paramètres tels que le mot de passe
permettant d’accéder à la base de données et le numéro port de la base de données.

1. Première message qui apparait :

“Enter [Y/y] if you have a prior version of Alerts Concentrator (Sentivist Server) to
upgrade. Press any other key to continue with a fresh installation”. On sélectionne “N
(no) ”.
2. Nom du serveur :
“Enter the name of the IPS-1 Alerts Concentrator” ⇒ CP-Server
3. Adresse IP du serveur :
”Enter the IP address of the server.” ⇒ 10.192.73.79
4. Fournir un mot de passe à l’administrateur pour l’accés à la base de données MySQL :
“Enter the password for the Alerts Concentrator database admin (MySQL.)” ⇒ IPS-
1Sensor
5. Fournir un mot de passe à l’utilisateur nfr pour l’accés à la base de données MySQL :
“Enter the password for the Alerts Concentrator database user (MySQL.)” ⇒ IPS-1Sensor
6. Numéro de port de la base de donnée :
“Enter the port name for the IPS-1 database.”⇒ (default = 55555)

1.4. L’IPS-1 Management Dashboard

1.4.1. Installation
L’IPS-1 Management Dashboard a été installé sur Windows XP Professional avec SP2. Il peut
également être installé sur Windows 2000 Professional avec SP4, Red Hat Enterprise Linux 3
(ES/AS) et 4, CentOS 4 ou Solaris 9 et 10.
L’installation de celui-ci se fait en exécutant le fichier setupwin32.exe disponible sur le CD.
L’ensemble du processus est trés simple il suffit juste de suivre les instructions. Chaque étape
est illustrée ci-dessous par des captures d’écran.
1. IPS-1 Check Point 12

Etape 1

Double-cliquer sur le fichier exécutable setupwin32.exe. On obtient la fenêtre d’accueil de l’ins-

tallation de l’IPS-1 Management Dashboard suivante :

Fig. 1.3.: Fenêtre d’accueil pour l’installation

Etape 2

Choisir l’emplacement de l’installation sur le disque local, celui par défaut convient très bien.

Fig. 1.4.: Sélèction de l’emplacement de l’installation

1. IPS-1 Check Point 13

Etape 3

Quelques précisions concernant la destination des fichiers installés et sur la taille nécessaire.

Fig. 1.5.: Précision sur la taille requise

Etape 4

L’installation peut alors démarrer :

Fig. 1.6.: Ajout des composants nécessaire

1. IPS-1 Check Point 14

Etape 5

Le Management Dashboard est prêt à être utlisé.

Fig. 1.7.: Fin de l’installation

Pour lancer l’application il faut se rendre dans Démarrer ⇒ Programmes ⇒ Check Point
IPS-1 ⇒ IPS-1 Management Dashboard . On obtient la page d’accueil ci-dessous per-
mettant de se loguer sur le serveur afin de visualiser les alertes. L’utilisateur est celui créé
précédemment “nfr” avec le mot de passe IPS-1Sensor.
1. IPS-1 Check Point 15

Fig. 1.8.: Page d’accueil pour se logguer

1.4.2. Présentation de l’interface

Une fois connecté, la fenêtre principale de l’application cliente s’affiche comme illustré ci-
dessous :

Fig. 1.9.: Page principale

L’IPS-1 Management Dashboard dispose d’une barre d’outils contenant les menus suivants :
File, Tools, Alert Browser, windows et Management et plusieurs types de boutons per-
mettant d’effectuer plusieurs actions.
File : ce menu permet d’ouvrir, de sauver, de supprimer l’affichage des alertes. Il permet
également de fermer l’application.
Tools :
– Recorder Events permet de regarder les événements qui ont été produits lorsqu’une alerte a
été déclenchée.
– System Statuts permet de visualiser l’état du serveur et de la sonde.
1. IPS-1 Check Point 16

– User Preferences permet de modifier certaines fonctionnalités : marquer les alertes lues, les
détails des alertes.
– Change Password offre la possibilité à l’utilisateur de changer son mot de passe pour la
connexion à l’IPS-1 Management Dashboard.
– Statut log
Alert Browser : défini les différentes colonnes caractérisant les alertes lors de l’affichage.
Windows : permet de savoir les fenêtres actuellement ouvertes.
Management :
– Users : permet de créer, ajouter et supprimer des utilisateurs
– Policies : permet de créer, modifier et supprimer le serveur, la sonde et les packagess ou les
configurations de ces derniers.
– Space Management : permet de modifier l’espace disque de la base de données pour le stockage
des alertes.
La barre d’outils contient également un ensemble de boutons permettant plusieurs actions :

Interrompre le chargement de alertes.

Afficher les alertes en groupe et par ordre de priorité.

Marqueur permettant d’annoter les alertes lues.

Définir une date et afficher les alertes détectées à cette date.

Ouvrir une nouvelle fenêtre.

Visualiser le nombre des alertes en fonction du temps sous forme de graphe.

Etat du serveur et de la sonde.

Racourci de l’onglet policies.

Les alertes peuvent être visualisées sous deux formes soit comme montré lors de la présentation
de la page principale en fontion du temps de détection ou regroupées en fonction de leur gravité
comme ci-dessous.
1. IPS-1 Check Point 17

Fig. 1.10.: Affichage des alertes en fonction de leur gravité

Le centre de la fenêtre permet d’explorer les alertes détectées par la sonde. En double-cliquant
sur une alerte on peut visualiser les détails la concernant ( nom, adresses source et destination,
ports source et destination, protocole utilisé, packagess). Le bouton Show Raw Packets per-
met de sauvegarder dans un fichier les trafics qui ont provoqué cette attaque. Ce fichier peut
être visualiser par Ethereal.
1. IPS-1 Check Point 18

Fig. 1.11.: détails d’une alerte

Comme précisé ci-dessus il est également possible de voir l’état de la sonde et de l’alerte concen-
trator en double-cliquant sur l’icone bleue :

Fig. 1.12.: Etat de l’Alert concentrator et de la sonde

Possibilité de voir les caractéristiques de la sonde, les packages que contient l’alert concentrator :
Management ⇒ Policies :
1. IPS-1 Check Point 19

Fig. 1.13.: Caractéristique de l’Alert concentrator

Fig. 1.14.: Caractéristique de la sonde

1.4.3. Configuration
Une fois l’IPS-1 Management Dashboard opérationnel nous configurons l’IPS-1 Alert concen-
trator et l’IPS-1 Sensor puis dans un second temps nous importerons les packages contenant
les règles qui permettront à la sonde de considérer qu’un flux de données est non conforme
ou pas. Dès lors l’IPS-1 Management Dashboard est prêt à être utilisé. Vu que nous sommes
plusieurs à s’intéresser à ce projet nous créerons un compte pour chaque utilisateur et nous leur
associerons des droits bien spécifique selon leur besoin.
1. IPS-1 Check Point 20

Etape 1 : Ajout de l’IPS-1 Alert concentrator

Pour que l’IPS-1 Management Dashboard puisse afficher les alertes stockées dans notre serveur
nous allons ajouter l’IPS-1 Alert concentrator. Depuis la barre d’outils de l’IPS-1 Management
Dashboard : Management ⇒ Policies ⇒ Policy Manager ⇒Sever Configuration. La
fenêtre ci-dessous apparait où nous pouvons ajouter un nouveau serveur : “New Alert Concen-
trator”.

Fig. 1.15.: Ajout de l’Alert Concentrator

Nous configurons notre serveur en précisant son adresse IP, le nom d’utilisateur et son mot de
passe. Ces informations doivent être identiques à celles attribuées lors de son installation.
1. IPS-1 Check Point 21

Fig. 1.16.: Ajout de l’IPS-1 Server depuis l’IPS-1 Management Dashboard

Etape 2 : Ajout de l’IPS-1 Sensor

L’ajout de la sonde s’effectue exactement comme dans le cas du serveur : Management ⇒

Policies ⇒ Policy Manager ⇒Sever Configuration et nous sélectionnons l’option “Add
New Sensor”. Ainsi la fenêtre suivante apparait où nous préciserons le nom de la sonde, son
adresse IP et le mot de passe permettant l’accès.
1. IPS-1 Check Point 22

Fig. 1.17.: Ajout de l’IPS-1 Sensor depuis l’IPS Management

1 : Nom de la sonde doit être identique à celui qui lui été attribué lors sa configuration. Dans
notre cas il s’agit de : CP-Sensor-50
2 : Adresse IP doit être également identique à celle attribué à la sonde lors sa configuration.
Dans notre cas il s’agit de : 10.192.73.78
3 : Bien que notre IPS-1 se comporte en IDS la classification de la sonde doit être de type IPS.
4 : Password et la confirmation de ce dernier doit être le même que celui fournit à la sonde
lors sa configuration.

Etape 3 : Téléchargement des packagess

Le téléchargement des packages depuis un serveur distant est une étape très importante car
contenant les règles permettant de déclencher une alerte. Cela s’effectue très rapidement, il
suffit juste de préciser le nom du serveur et son port puis de démarer le téléchargement.
1. IPS-1 Check Point 23

Fig. 1.18.: Mise à jour des packagess

Une fois cette étape terminée nous préciserons la prochaine mise à jour de manière automatique
depuis la barre d’outils :
Management ⇒ Policies ⇒ Policy Manager ⇒ Update Packages

Fig. 1.19.: Mise à jour des packagess

1. IPS-1 Check Point 24

Dans la mesure où nous sommes plusieurs à être intéressé par ce projet nous avons dû créer un
compte pour chaque utilisateur : Management ⇒ User ⇒ New . Plusieurs options de ma-
nipulation des comptes sont offertes, notamment la possibilité d’attribuer à chaque utilisateurs
un des deux privilèges suivants :

1. Le privilège Normal donne à l’utilisateur uniquement la possibilité d’afficher les alertes.

Comme nous pouvons le constater sur le schéma ci-dessous (mis en évidence sur le menu
Management) seul le sous groupe view Policies apprait.

Fig. 1.20.: Utilisateur avec privilège “Normal”

a) A partir de view Policies cet utilisateur accède aux packages/backends du policy

group1 “ALL” et non les packages/backends configurés pour notre sonde. Comme
nous l’observons sur le schéma ci-dessous le “policy group” (SipOnly) lié à notre
sonde n’apparait pas.

1
Le policy group est une collection de packages et backends.
1. IPS-1 Check Point 25

Fig. 1.21.: Les packages accéssibles pour un utilisateur Normal

2. Le privilège administrateur fourni beaucoup plus de possibilités à l’utilisateur.

1. IPS-1 Check Point 26

Fig. 1.22.: Utilisateur avec privilège “Administrateur”

a) En ce qui concerne la gestion des utilisateurs, l’administrateur peut créer ou suppri-

mer des comptes à travers le menu Management ⇒ User . Il pourra également
dévérouiller un compte car celui-ci peut être bloqué au bout de trois tentatives d’au-
thentification erronées. Le cas échéant, le bouton “Unlock Account” est accessible
sinon grisé.
1. IPS-1 Check Point 27

Fig. 1.23.: Compte utilisateur

b) En étant administrateur, il est possible d’accèder à tous les policy group définis.
Depuis Management ⇒ Policy . L’administrateur peut par exemple sélectionner
les packages/backends dont il a besoin et sauvegarder ces changements en clickant
sur le bouton “Apply”.

Fig. 1.24.: Les Packages/Backends accéssibles pour un utilisateur admin

c) Management ⇒ Space Management permet d’accéder aux informations rela-

tives à l’espace disque réservé pour les différents composants de notre IDS.
1. IPS-1 Check Point 28

Fig. 1.25.: Caractéristique du composant IPS-1 Sever

 2
Packages et Backends

L’IPS-1 Sensor contrôle le réseau en se basant sur les packages et backends pour filtrer les
évènements. Les backends contiennent des règles écrites dans un langage de script appelé N-
Code et sont contenus dans un package qui porte le nom du protocole auquel il est rattaché.
Dans cette section nous définirons les différents packages et backends appliqués à notre sonde
ainsi que leurs configurations.
L’IPS-1 Sensor se comportera selon la configuration qui lui est appliquée. Parmi les critères de
configurations nous pouvons citer :
– Les types de packages et backends installés.
– L’état de ces packages/backends car ils peuvent être activés ou désactivés.
– La configuration des valeurs des différentes variables.
Dans la configuration par défaut notre sonde est rattachée à un “Policy Group” appelé ALL.
Celui-ci est une collection de Packages/Backends pouvant être appliqués à une sonde, tous
les autres policy créés seront des descendants du policy Group ALL. Comme mentionné dans
l’introduction, le but de ce travail est de tester la vunérabilité du protocole SIP. Pour cela nous
allons créer un nouveau “Policy Group” appelé sipOnly qui contiendra uniquement les packages
et backends utiles pour effectuer des tests SIP.
Pour créer un nouveau policy group il faut se rendre dans Management ⇒ Policies et
choisir l’onglet Package/Backend Configuration. Depuis le policy Group parent, effectuer un
click droit et choisir New Policy Group.
2. Packages et Backends 30

Fig. 2.1.: Création d’un nouveau Policy Group

Lors de la création d’un policy group, celui-ci hérite automatiquement de la configuration de

son parent. Le choix nous ait laissé de sélectionner et de désélectionner les packages/backends
utiles dans le cadre de notre étude. Vu que nous aimerions que notre sonde partage la même
configuration que sipOnly alors nous allons juste glisser la sonde sous le policy group sipOnly.
Pour appliquer ces packages à notre sonde il suffit depuis l’icône sipOnly d’effectuer un click
droit et choisir Configuration ⇒ Pass Down et ensuite un click sur le bouton Apply
pour sauvegarder ces changements. En appliquant le Pass Down depuis un policy group, ceci
applique la configuration du policy group à tous ses descendants. D’autres policy group bkp et
bkpSipOnly sont des sauvegardes de ALL et sipOnly respectivement.
2. Packages et Backends 31

Fig. 2.2.: Appliquer des packages/backends spécifiques l’IPS-1 Sensor

2.1. Configuration du policy group sipOnly

sipOnly est formé des packages suivants : attacks, authentification, badfiles, dhcp, dns, finger-
print, icmp, ip, scanner, sip, ssh, tcp, tftp, udp.
La configuration des valeurs des variables sont :

1. System wide contient quatres types de backends. Les backends dst_ignore_list et src_ignore_list
garde la configuration par défaut. La liste des adresses sources et destinations à ignorer
est vide tandis que les backends broadcast_addrs et my_network ont été modifiés en
fonction de notre réseau.
a) broadcast_addrs : comme son nom l’indique ce backend permet de définir une liste
contenant les adresses broadcasts des différents réseaux de notre système. Cette liste
est définie dans le champs Variable. Cette variable a été adapté en fonction de notre
réseau est égale à 192.168.0.255.
2. Packages et Backends 32

Fig. 2.3.: Définition de l’adresse broadcast

b) my_network contient la liste des réseaux de notre système. Dans notre cas les ser-
veurs de localisation, d’enregistrements , le proxy et les téléphones sont dans le réseau
192.168.0.0. Les adresses IP renferme le masque du réseau.

Fig. 2.4.: Définition du réseau local

2. Le package attack contient les backends qui permettent d’agir en cas de détection d’at-
taques. Les variables des régles CAPTURE CONFIG et GUARENTEE RESPONSES du
2. Packages et Backends 33

backends attack/capture ont été modifiés à 2 et 1 respectivement.

3. Dans le package dns la variable des serveurs dns ont été modifiés par rapport à notre
serveur dns (10.192.48.100, 10.192.48.101).
4. Le nombre d’hôtes maximals à scanner a été fixé à 57 par minute dans le backend ip/-
hostscan du package ip.
5. La variable de la régle TFTP MAX FILENAME du backend tftp/tftp a été fixé à 40.
Cette variable représente la taille limite des fichiers de configurations des téléphones cisco
qui utilisent le protocole tftp.
6. Le package SIP possède quatres backends qui contiennent chacune un fichier avec l’exten-
sion .desc donnant une description de cette règle (durant le travail de diplôme après se
familiariser avec N-code une description détaillée de tous les onglets sera fournie).
a) sip/compliance : est une règle liée à la structure des paquets. Une alerte sera dé-
clenchée si dans l’en-tête du paquet les messages sip (INVITE, BYE, CANCEL... )
sont écrits en minuscule ou la taille des paquets est supérieure à celle fixée. Elle est
à 1300 Bytes par défaut mais peut être éditée.

Fig. 2.5.: Description de SIP Compliance

b) Sip/logging : celle ci n’est pas une règle d’attaque lorsqu’elle est active elle permet
de sauvegarder les logs SIP.
2. Packages et Backends 34

Fig. 2.6.: Description de SIP Logging

c) Sip/multitech : cette règle permet de déceler une attaque utilisant plusieurs tech-
niques d’attaques.

Fig. 2.7.: Description de SIP Multitech

d) Sip/uservars : celle ci permet de déclencher une alerte si l’en-tête SIP n’est pas
conforme à la rfc et lorsque les messages sip sont inconues.

Fig. 2.8.: Description de SIP uservars

Aprés avoir sauvegardé toutes ces changements en clickant sur le bouton Apply, il est possible
de visualiser la configuration de la sonde depuis le serveur en se connectant non pas comme
root mais comme utilisateur nfr.

1. cd server
2. Packages et Backends 35

2. . .nfrrc
3. bin/get -n CP-Sensor-50 -x exec sysinfo
 3
Tests

3.1. Topologie du réseau

Une fois l’installation et la configuration de l’IPS-1 Check Point terminées, nous mettons en
place un réseau SIP (Session Initiation Protocol RFC 3261) de façon à pouvoir effectuer des
attaques VoIP. Le protocole SIP (Session Initiation Protocol) succède au standard H.323 grâce
à sa conception plus évoluée et plus adaptée au protocole IP. Ce protocole a été développé par
l’Internet Engineering Task Force (IETF) qui contribue à élaborer de nombreux standard que
l’on retrouve sur l’Internet à l’instar de H.323 qui est issu du monde des télécoms.
Le protocole SIP a pour principal objectif d’initialiser la session. Les requêtes SIP sont consti-
tuées par des en-têtes au sein desquels on retrouve une description de l’appel. La requête
contient aussi le corps du message. Cette partie décrit la demande de session. La topologie de
notre réseau est ainsi faite :
3. Tests 37

Comme le schéma ci-dessus le montre notre réseau SIP est composé des éléments suivants :

Les Terminaux

Ces terminaux sont des téléphones Cisco pouvant émettre et recevoir de la signalisation SIP.
SIP est un protocole point à point, les liaisons sont donc établies d’un terminal à un autre, il est
aussi client-serveur cela vient du fait qu’un terminal dit aussi Agent devient client lorsqu’il émet
des requêtes et reçoit des réponses (UAC User Agent Client) et donc son partenaire devient
serveur (UAS User Agent Serveur) puisqu’il répond à ces requêtes.

Serveur d’enregistrement

Ce serveur est essentiel dans tous les réseaux SIP. Il permet à un téléphone de pouvoir s’enre-
gistrer au moyen de la requête REGISTER, ce téléphone annonce sa position actuelle (adresse
IP) au serveur qui sera chargé de la transmettre au serveur de localisation.

Serveur de localisation

Ce serveur permet de mémoriser les différents utilisateurs, leurs droits, leur mot de passe ainsi
que leurs positions actuelles.
3. Tests 38

Proxy SIP

Un Proxy SIP sert d’intermédiaire entre deux User Agents qui ne connaissent pas leurs emplace-
ments respectifs (adresse IP). En effet, l’association URI-Adresse IP a été stockée préalablement
dans une base de données par un Registrar (serveur d’enregistrement). Le Proxy peut donc in-
terroger cette base de données pour diriger les messages vers le destinataire.
Le serveur d’enregistrement, de localisation et le proxy SIP sont basés sur un produit open
source appelé OpenSER.

3.2. Les attaques

L’informatique étant un domaine très vaste, le nombre de vulnérabilités présentes sur un système
peut donc être important. Ainsi, les attaques visant ces failles peuvent être à la fois très variées
et très dangereuses.
Tirés du document “Best Practrices for VoIP-SIP Security (BP)” (www.vadese.org) les princi-
paux risques connus liés à l’utilisation de la VoIP en entreprise sont :
Déni de Service (DoS) : Attaques entraı̂nant l’indisponibilité d’un service/système pour les
utilisateurs légitimes.
Ecoute clandestine : Attaques permettant d’écouter l’ensemble du trafic de signalisation
et/ou de données. Le trafic écouté n’est pas modifié.
Détournement du trafic : Attaques permettant de détourner le trafic au profit de l’attaquant.
Le détournement peut consister à rediriger un appel vers une personne illégitime ou à inclure
une personne illégitime dans la conversation.
Usurpation d’identité : Attaques basées sur la manipulation d’identité.
vols de services : Attaques permettant d’utiliser un service sans avoir à rémunérer son four-
nisseur.
communications indésirées : Attaques permettant à une personne illégitime d’entrer en
communication avec un utilisateur légitime.
La matrice d’attaque du document “Best Pactrice” (www.vadese.org) nous donne toute la pa-
noplie des Attaques SIP (et solutions).
Pour l’utiliser :
– Colonnes de gauche = la liste des attaques, avec identifiant et nom.
– Partie supérieure = la liste des solutions, classées par type avec identifiant et nom.
– Une croix dans la matrice indique que l ?attaque est contrée par la solution.
Pour une analyse plus détaillée :
– Cette matrice peut se lire de deux manières.
– Verticalement, elle permet de voir quelle(s) attaque(s) est(sont) contrée(s).
– Horizontalement, elle permet de voir la(les) solution(s) appropriée(s).
– Légende

1. X La solution couvre l’attaque.

3. Tests 39

2. X La solution couvre un des vecteurs de l’attaque. Cependant, d’autres vecteurs peuvent

encore permettre de réaliser l’attaque.
3. X La solution couvre l’attaque, mais il se peut qu’une personne se soit appropriée les
données d’authentification d’un utilisateur légitime.
4. Solution liée à la solution comprenant une croix à sa gauche.

Quelques attaques du Best Practice seront effectuées lors du travail de diplôme. Dans les sections
suivantes, seront testés les filtres développés sur l’IPS-1 pour cela nous mettrons en place l’ARP
3. Tests 40

Spoofing qui permettra de transformer notre switch en un “hub”. Des trames ARP vont être
envoyés vers le commutateur dans le but de l’inonder. Le switch ne sachant pas interpréter
les nouvelles adresses fonctionnant réellement sur le réseau, il les considère comme inconnues
et fonctionne donc comme un concentrateur. Il envoie donc les trames entrantes vers tous ses
ports. Ainsi l’attaquant pourra récupérer facilement les informations sur les paquets circulants.

3.2.1. ARP Spoofing

Cette attaque exploite une faiblesse du protocole ARP (Address Resolution Protocol) et consiste
à rediriger le trafic d’une machine vers une autre. Elle permet de retrouver l’adresse IP d’une
machine connaissant l’adresse physique (adresse MAC) de sa carte réseau.
Pour effectuer cette usurpation, la machine attaquante s’interpose entre deux machines du
réseau et transmet à chacune un paquet ARP falsifié indiquant que l’adresse MAC de l’autre
machine a changé, l’adresse MAC fournie étant celle de l’attaquant. Les deux machines cibles
vont ainsi mettre à jour leur table dynamique appelée Cache ARP. De cette manière, à chaque
fois qu’une des deux machines souhaitera communiquer avec la machine distante, les paquets
seront envoyés à l’attaquant.
Cette technique d’attaque appelé man in the middle (MITM) rend totalement transparent
l’attaquant et donc permet à ce dernier d’accéder à toutes les communications sans que les
machines cibles ne se rendent compte. Voici un schéma explicatif.
3. Tests 41

L’outil utilisé pour mettre en place les attaques MITM est Ettercap. Ce logiciel Open Source
permet de sniffer le trafic réseau. Pour mettre en place cette attaque nous effectuerons les étapes
suivantes :
Etape 1
Lancez l’exécutable et cliquer sur : Sniff ⇒ Unified sniffing

Fig. 3.1.: Lancement de ettercap

Etape 2
Une fenêtre s’affiche vous demandant le nom de l’interface utilisé (eth0 dans notre cas). Faire
un scan : Host ⇒ Scan for hosts. Double-cliquer sur Host ⇒ hosts list
3. Tests 42

Fig. 3.2.: Sélection de “Host list”

On obtient la fenêtre suivante avec tous les hosts :

Fig. 3.3.: Aperçu de la liste des “hosts”

Etape 3
Dès lors nous pouvons sélectionner les machines cibles dans la liste proposée et puis cliquer sur
Add to Target1 ou Add to Target2 .
3. Tests 43

Fig. 3.4.: Ajout des cibles

S’assurer que les cibles ont été bien sélèctionnées : Targets ⇒ Current Targets

Fig. 3.5.: Sélection de Current Targets

ce qui nous permet de visualiser les cibles.

3. Tests 44

Fig. 3.6.: Aperçu de toutes les cibles

Etape 4
Dès à présent nous pouvons choisir notre type d’attaque MITM : Mitm ⇒ Arp poisoning.
L’arp poison est une attaque par déni de service dont le but est de “tromper” des postes sur le
même réseau ethernet en falsifiant des adresses MAC pour des adresses IP données. L’attaque
peut porter sur deux axes.
– Le premier est une attaque massive sur un réseau afin de remplir les tables ARP des postes
sur le réseau. Ceci peut provoquer rapidement une saturation du réseau au niveau des re-
quètes ARP arp who-has (à quelle adresse correspond cette adresse ARP) et engendre des
disfonctionnements des communication sur le LAN.
– La seconde attaque vise une connexion entre deux postes en particulier sur lequel on va porter
une attaque pour couper la connexion.
3. Tests 45

Fig. 3.7.: Sélection de l’attaque ARP Poisoning

Laisser les options par défaut et click ok puis commencer le sniffing Start ⇒ Start Sniffing

Fig. 3.8.: Activation du sniffing

Remarque : A la fin de l’attaque ne pas oublier de fermer proprement l’application.

1. Mitm ⇒ Stop mitm attack

3. Tests 46

Fig. 3.9.: Arrêt de l’attaque

2. Start ⇒ Stop sniffing

Fig. 3.10.: Arrêt du sniffing

3. Tests 47

Fig. 3.11.: Sniffing avec Ethereal

Comportement de la sonde

Aprés avoir mis en place cette attaque nous constatons que la sonde reste indifférente car aucune
alerte n’a été décelée.

Fig. 3.12.: Alertes détetées par la sonde

Une fois cette attaque mise en place l’efficacité des filtres appliqués à IPS-1 Sensor est testée
dans la section suivante . Nous injecterons dans le réseau des faux paquets SIP (les méthodes SIP
en minuscule, des paquets SIP avec des méthodes inexistantes) et nous enverrons des paquets
de taille trop grandes par rapport aux valeurs des variables de configuration.

3.2.2. Injection de paquet SIP malformé

Le SIPNess messenger (www.ortona.com) est un outil qui fournit à l’utilisateur une manière
facile de construire et d’envoyer des messages personnalisées SIP à un interlocuteur distant,
et en même temps de recevoir et surveiller les messages SIP entrants. La version 1.06 utilisée
3. Tests 48

supporte les messages INVITE, CANCEL, BYE, REGISTER, RINGING, TRYING, ACK,
OK, OPTION.
Par ce logiciel sera façonné un message non conforme. Pourqoui cette appellation ?
Un des backends sip/compliance du package SIP de la sonde contient des régles permettant
de juger qu’un paquet est non conforme.

1. La première règle du backend sip/compliance est nommée ALERT ON BIG UDP PACKET.
Lorsque celle-ci est activée la variable de configuration nommée Variable Value est
à 1. Pour être conforme à la RFC, tout paquet UDP circulant sur le réseau, ayant
une taille supérieure à 1300 bytes fera l’objet d’une alerte nommée sip compliance :ex-
tra data in udp alert.

Fig. 3.13.: Description de la règle “Alert On Big UDP Packet”

En utilisant le générateur de message SIP (SIPNess) nous tenterons de déclencher cette

alerte en envoyant un paquet UDP supérieur à 1300 bytes.
3. Tests 49

Fig. 3.14.: Envoi d’un paquet UDP de taille supérieure à la taille maximale

Le champ d’en-tête Content-length, indiquant la taille du corps du message envoyé au

receveur (bob), est à 1999 bytes. Ce qui indique qu’une alerte doit être détectée.

Fig. 3.15.: Détection de l’alerte sip compliance :extra data in udp alert

Comportement de la sonde
En se connectant au Management Dashboard nous décelons sur le tableau des alertes
la présence de l’alerte de type sip compliance :extra data in udp alert ce qui montre la
validité de la régle ALERT ON BIG UDP PACKET.
2. Comme mise en évidence la description de l’alerte ALERT ON LOWERCASE METHODS,
indique que toute méthode SIP écrite en minuscule engendrera une alerte. En effet cette
règle est activée car la Variable Value est à 1.
3. Tests 50

Fig. 3.16.: Description de la règle “Alert On Lowercase Methods”

Une attaque de ce type sera provoquée en envoyant au proxy (192.168.0.219) un message

SIP suivant :

Fig. 3.17.: Envoi d’un message “invite” avec SIPNess

Comme nous pouvons l’observer sur la capture Ethereal ci-dessous la méthode SIP en-
voyée est écrite en minuscule.
3. Tests 51

Fig. 3.18.: Réception d’une requête INVITE écrit en miniscule

Comportement de la sonde
Dés l’envoie du paquet, la sonde détecte l’attaque en envoyant une alerte Lowercase SIP
Methods. En double cliquant sur cette alerte depuis l’interface du Management DashBoard
plus de détails sur l’attaque sont visuels : ID de l’alerte, adresses IP source et destination,
date de détection de l’alerte, le type de l’alerte, le nom de l’alerte...

Fig. 3.19.: Alerte visible depuis le Dashboard et détail de cette alerte

3. La régle MAX UDP PACKET SIZE est presque identique à ALERT ON BIG UDP PACKET
à la seule différence que la valeur de la variable de configuration est éditable et représente
la taille maximale d’un paquet, qui par défaut est fixée à 1300 bytes. Pour tester cette
règle nous fixons la Variable Value à 8 bytes qui représente la taille maximale des pa-
quets autorisés à circuler sur le réseau.
3. Tests 52

Fig. 3.20.: Description de la règle “Max UDP Packet Size”

Provoquons une attaque en envoyant sur le réseau grâce à SIPNess un paquet de taille
supérieure à 8 bytes.

Fig. 3.21.: Envoie d’un paquet de 296 bytes au proxy SIP

Comportement de la sonde
Aprés avoir mis en place cette attaque, la sonde émet une alerte de niveau moyen appelée
sip compliance :udp size alert.

Fig. 3.22.: Alertes détectées par la sonde

3. Tests 53

En double cliquant sur l’alerte depuis l’interface du Management Dashboard nous obte-
nons la fenêtre contenant le paquet générant cette alerte. Le bouton Show Raw Packets
de la fenêtre obtenue permet d’observer les paramètres de l’alerte (adresses source et des-
tination, ports source et destination, le package et backends qui contient la règle...).

Fig. 3.23.: Détails de l’alerte sip compliance : udp size alert

4. Une autre régle METOHDS définie une liste de méthodes SIP autorisées. Par défaut cette
liste contient les méthodes SIP suivantes :“REGISTER”,“INVITE”,”ACK”,”CANCEL”,”BYE”,
“OPTIONS”, “SIP/2.0”, “PRACK”, “SUBSCRIBE”, “NOTIFY”.

Fig. 3.24.: Description de la règle “Methods”

Ainsi en effectuant un appel où bob demande à initier une communication avec alice, la
sonde détecte une alerte à la suppression de la méthode INVITE dans la liste des variables
de configuration. L’alerte émise par la sonde est Unknown SIP methods.
3. Tests 54

Fig. 3.25.: Alerte de type Unknown SIP methods

Voici la capture Ethereal correspondante :

Fig. 3.26.: Alerte Unknown SIP methods

Le package SIP contient également un autre backend appelé sip/uservars où sont définies
d’autres règles.

1. La régle BAD METHODS consiste à rejeter des paquets contenant certaines méthodes sip.
3. Tests 55

Fig. 3.27.: Description de la règle “Bad Methods”

Ainsi tout paquet contenant une méthode définie dans la Variable Value engendre
une alerte de type sip uservars :bad method alert. Cette alerte est de haute importance
contrairement aux alertes ci-dessus qui sont d’importance moyenne. Cette liste de “mau-
vaises” méthodes SIP contient la méthode REGISTER. La durée de validité des URI est
de 3600 sec, après chaque heure nos contacts bob et alice envoie des requêtes REGISTER
vers le serveur de redirection.

Fig. 3.28.: Alerte de type sip uservars : bad methods alert

La figure 3.29 montre le paquet à l’origine de cette alerte.

Fig. 3.29.: Paquet contenant la méthode REGISTER

3. Tests 56

2. Un URI SIP contient des informations suffisantes pour initialiser et maintenir une session
de communication avec les ressources. Le schéma d’une URI a une forme similaire à l’URL
mailto, permettant la spécification d’en-têtes de champs de demande SIP. Par exemple
l’URI de l’utilisateur bob est “sip :bob@192.168.0.219”. La règle BAD REQUEST URI
constiste à détecter une alerte pour toute requête contenant un URI défini dans la liste des
variable de configuration. Pour tester cette règle nous placerons dans la Variable Value
l’URI de bob. Ainsi tout appel effectué par bob ou qui lui est adressé provoquera une
alerte .

Fig. 3.30.: Description de la règle “Bad Methods”

En initiant une communication avec bob une alerte de type sip uservars :bad uri alert
est émise.

Fig. 3.31.: Alerte de type “sip uservars :bad uri alert”

L’origine de cette alerte est due au fait que la rêquete contiennent l’URI de bob.

Fig. 3.32.: Paquet à l’origine de l’alerte sip uservars :bad uri alert
3. Tests 57

Face à toutes ces attaques SIP, l’IPS-1 Sensor est capable de détecter toutes attaques ne
respectant pas aux règles définies sur l’IPS-1.
 4
Synthèse et conclusion

La présente section consiste à effectuer une analyse générale du comportement de l’IPS-1 Check
Point. Les NIDS étant les IDS plus intéressants et les plus utiles du fait de l’omniprésence des
réseaux dans notre vie quotidienne, l’IPS-1 Check Point en est un et a pour principal objectif
d’aider les entreprises à combattre les intrusions. L’une des forces de l’IPS-1 Check Point réside
au niveau de l’affichage des alertes qui s’exécute en temp réel ce qui permettra de diminuer
les dommages causés par l’attaque. Le fait de pouvoir regrouper les alertes en fonction de leur
gravité est un avantage car donne la possibilité à l’administrateur du système de prendre les
mesures appropriées. Grâce à l’interface fournie par l’IPS-1 Management Dashboard l’utilisa-
teur accéde rapidement aux informations intéressantes et ce qui lui permettra de configurer
facilement le système afin que celui-ci réponde à ses besoins.
Suite aux différentes attaques VoIP mise en place cf chapitre 3, la sonde a détectée toutes les
attaques SIP dont les filtres ont été définis (Packages/Backends). Durant le travail de diplôme
sera définies de nouvelles régles en N-code face aux attaques sip les plus courants que nous
définirons.
Une session SIP entre 2 téléphones est établie de la façon suivante :

1. Le téléphone appelant envoie une invitation (Alice envoie une invitation à bob)
2. Le téléphone appelé renvoie une réponse informative 100 – Trying
3. Lorsque l’appelé commence à sonner une réponse 180 – Riging est renvoyée.
4. Lorsque l’appelant décroche le téléphone, le téléphone appelé envoie une réponse 200 –
OK
5. L’appelant répond par un acknowledgement ACK
6. Maintenant, la communication est transmise sous forme de données via RTP
7. Lorsque l’appelant raccroche, une requête BYE est envoyée au téléphone appelant.
8. Le téléphone appelant répond par un 200 – OK.

Toute session SIP est identifiée par un identificateur de session appelé Call-ID. Ce dernier
permet de définir comment les sessions SIP sont loggués. Les logs générés par l’IPS-1sont
accécibles depuis le menu Tool ⇒ Recorder Events. Depuis cette fenêtre choisir le serveur
(Management Server), le package, le backend sip/logging. En se basant sur les valeurs des
Call-ID, nous constatons que les logs ne sont pas répertoriés par session.
4. Synthèse et conclusion 59

Fig. 4.1.: logs SIP

 5
Cahier des charges

5.1. Présentation

5.1.1. Contexte
Ce projet s’inscrit dans le cadre du travail de diplôme de Mme Marie Thérèse Gomes, étudiant
en troisième et dernière année de la Haute Ecole d’Ingenerie et de Gestion du canton de vaud
(Heig-vd). Le projet est scindé en deux étapes :
Le pré-projet de diplôme du 15 mars au 22 juin 2007, à raison d’une demie-journée par
semaine. Durant cette période il est question d’installer, de configurer et de tester le compor-
tement de l’outil de travail (IPS-1 Check Point). A l’issu de cette période un rapport doit être
rendu.
Travail de diplôme A partir du 18 septembre l’emploi du temps de l’étudiant serait exclusi-
vement consacré à la réalisation du travail de diplôme. Le résultat final sera présenté dans un
rapport écrit à remettre le 7 décembre 2007, au cours des trois premières semaines de janvier
2008 le projet devra être soutenu oralement devant le jury.

5.1.2. Description générale

Le travail de diplôme dont il est question dans ce document consiste à effectuer un banc de test
pour un Système de Détection d’Intrusion (IDS) bien précis, couvrant le trafic VoIP. Ce projet
traite un des domaines couvert par le projet de recherche Vadese qui a pour objectif d’étudier
les aspects de sécurité de la VoIP et de proposer des solutions de sécurisation. L’IDS à évaluer
et à améliorer est fourni par la société Check Point.

5.2. Travaux à réaliser

5.2.1. Tutorial du langage N-code

Une des premières étapes du travail de diplôme est de comprendre le langage N-Code et de
réaliser un tutorial. L’IPS-1 Check Point regroupe les paquetages (par thème ou protocole).
5. Cahier des charges 61

Ceux-ci sont codés en N-code et contiennent des règles de telle sorte à reconnaı̂tre les paquets
non valides circulant sur le réseau.

5.2.2. Ecriture des règles

Après être familiarisé avec le langage N-code, il est question à présent d’écrire des règles pour
améliorer notre outil et renforcer la sécurité de notre réseau. Une dernière étape de tests (at-
taques VoIP) seront mis en place pour évaluer la sonde Check Point Si le temps nous le permet
des tests seront effectués sur d’autres IDS.

5.3. Organisation du travail

5.3.1. Journal de travail

L’étudiant facilitera son travail en tenant un journal de travail. Celui-ci pourra contenir une
trace de toutes les actions entreprises pour le projet. Datées et brièvement décrites, les actions
pourront ainsi être rapidement retrouvées, modifiées ou incriminées en cas de problème. Sites
internet pertinents et tout autre bibliographie pourront avantageusement y être conservés.

5.3.2. Outil de travail

Durant le travail de diplôme sera utilisé un dépôt SVN où sera stocker progressivement le
travail effectué. Ainsi mon assistante et professeur encadrants auront la possibilité de suivre
régulièrement l’avancement du projet.
 Bibliographie

[1] http ://www.fullsecurity.ch/.

[2] http ://www.hackingvoip.com.
[3] http ://www.vadese.org/node/6.
[4] Rfc 3261sip.
[5] Sécurité réseau avec Snort et les IDS.
[6] snort manual.
[7] Syngress snort.2.1(2004).
[8] Vadesewp8-idsstateofthemarket.
[9] Mme Lalaina Kuhn. Rapport travail de diplome.
[10] Check Point. IPS-1 5.0.6 Administration Guide.
[11] Check Point. IPS-1 5.0.6 Getting Started Guide.
[12] Check Point. ips-1 whitepaper.
[13] Prof. Stefano Ventura (HEIG) Prof. Juergen Ehrensberger (HEIG), Xavier Hahn (HEIG).
Best Practices for VoIP-SIP Security.
 A
Systeme de Détection d’Intrusion

Les systèmes d’information sont aujourd’hui de plus en plus ouverts sur Internet. Cette ou-
verture, a priori bénéfique, pose quelques problèmes au niveau de la sécurité : il en découle
un nombre croissant d’attaques. La mise en place d’une politique de sécurité autour de ces
systèmes est donc primordiale.
En plus des pare-feux et des systèmes d’authentification de plus en plus sécurisés, il est néces-
saire, pour compléter cette politique de sécurité, d’ajouter des outils de surveillance pour auditer
le système d’information et détecter d’éventuelles intrusions. Cet équipement de détection plus
communément appelé IDS (System Intrusion Detection) est un mécanisme qui examine le trafic
sur le réseau pour y rechercher les activités douteuses ou tout risque d’intrusion. La détection
d’intruision consiste simplement à essayer de déceler les signes d’un intrus sur le réseau avant
qu’il ne provoque des dégats, une coupure de service ou une perte de données.
Un IDS a quatre fonctions : L’analyse, la journalisation, la gestion et l’action.
– Analyse : Analyse des journaux pour identifier des motifs dans la masse de données recueillie
par l’IDS. Il y a deux méthodes d’analyse : une basée sur les signatures d’attaques, et l’autre
sur la détection d’anomalies.
– Journalisation : Enregistrement des évènements dans un fichier (un fichier log). Exemples
d’évènements : arrivée d’un paquet, tentative de connexion.
– gestion : Les IDS doivent êtres gérés de manière continue. Ils doivent êtres configurés,
vérifiés.. On peut assimiler un IDS à une caméra de sécurité.
– action : Alerter le personnel quand une situation dangereuse est détectée.

A.1. Types d’IDS

Il existe deux grandes familles distinctes d’IDS :
Les NIDS (Network Based Intrusion Detection System), ils assurent la sécurité au niveau du
réseau.
Les HIDS (Host Based Intrusion Detection System), ils assurent la sécurité au niveau des
hôtes.
A. Systeme de Détection d’Intrusion 64

A.1.1. Network IDS

Un NIDS nécessite un matériel dédié, qui permettra d’analyser les flux transitant sur un ou
plusieurs lien réseau et de détecter les intrusions en temps réel. Il fonctionne en mode furtif
c’est à dire qu’il écoute tout le trafic réseau, puis l’analyse et génère des alertes lorsque des
paquets suspects ont été détectés.
L’emplacement des NIDS est crucial car suivant son positionnement, il peut ne pas voir le trafic
réseau. Par exemple si seuls les NIDS situéss entre le firewall et Internet sont utilisés, le trafic
du réseau interne reste invisible. Une autre faiblesse des NIDS à prendre en considération est
lorsque les paquets sont cryptés, Il est impossible pour l’IDS de décrypter ces flux.

A.1.2. Host IDS

Par comparaison au NIDS, le HIDS se base sur une unique machine. En effet il n’analyse plus
le trafic réseau mais plutôt l’activité se passsant sur la machine en question. Le HIDS analyse
les paquets entrants et sortants de l’hôte dans le but de détecter des signes d’intrusions et de
générer des alertes qui seront stockées dans des fichiers de log.
Les HIDS possèdent quelques faiblesses, ils peuvent être victimes d’attaques, s’ils sont situés
sur l’ordinateur compromis de l’attaquant, leurs fichiers peuvent être effacés ou modifiés. Un
autre point faible est sa vision restreinte de ce qui se passe sur le réseau.

A.1.3. Les IDS “Hybrides”

Ils permettent de réunir les informations de diverses sondes placées sur le réseau. Leur ap-
pellation “hybride” provient du fait qu’ils sont capables de réunir aussi bien des informations
provenant d’un système HIDS qu’un NIDS. Un des IDS hybrides les plus connu dans le monde
Open-Source est Prelude. Il permet de stocker des alertes provenant de différents systèmes. Uti-
lisant Snort comme NIDS, et d’autres logiciels tels que Samhain en tant que HIDS, il permet
de combiner des outils puissants tous ensemble pour permettre une visualisation centralisée des
attaques.

A.2. Les méthodes de détection

Les systèmes de détection d’intrusions se divisent en deux catégories :
– basés sur les signatures.
– basés sur les anomalies.
Signatures : Les intrus possèdent des signatures, tout comme les virus, qui peuvent êtres
détectés par certains logiciels. La procédure consiste à trouver les paquets de données contenant
des signatures connues comme anormales et dangereuses. Basé sur un ensemble de signatures
et de règles, le système de détection peut trouver et loguer les activités suspectes et produire
des alertes. Cependant les IDS nécessitent des mises à jours de leur base de signatures pour
pouvoir détecter les nouveaux types d’attaques.
A. Systeme de Détection d’Intrusion 65

Anomalies : Les IDS basés sur la détection d’anomalies consiste à comparer les schémas
d’évènements en cours pris dans leur ensemble aux schémas d’évènements habituels pris dans
leur ensemble. Cela permet d’analyser beaucoup de choses comme par exemple des utilisateurs
accédant à des fichiers systèmes, des modifications de fichiers inhabituelles, de nombreux échecs
de connexion.. Cette méthode permet d’identifier des attaques inhabituelles. Mais il est difficile
de distinguer ce qui est normal de ce qui ne l’est pas, car les schémas d’activités varient très
largement.

A.3. Où doit on placer l’IDS dans une topologie réseau

Le placement des IDS dépend de la topologie réseau. Suivant celle ci, on peut les placer à un
ou plusieurs endroits. Cela dépend également de quels types d’intrusion on souhaite surveiller
et détecter : interne, externe , ou bien les deux.
Si l’entreprise veut détecter les intrusions externes uniquement, le meilleur endroit est juste
après le routeur relié à internet ou firewall.
Si elle veut aussi détecter les menaces internes, on peut placer un IDS dans chaque segment du
réseau.
Généralement, l’entreprise se limite aux secteurs sensibles du réseau. Plus il y a de systèmes de
détection d’intrusion, plus il y a de travail et plus il y a de coûts pour l’entretien.

Location 1 : A l’entrée du firewall externe, relié à internet. C’est le meilleur endroit pour
analyser les attaques externes contre l’entreprise.
Location 2 : Dans la zone des serveurs, une zone sensible pour l’entreprise et donc à surveiller.
location 3 : Sur chaque segment réseau. Il se concentre sur les attaques ayant passé le firewall
et s’étant introduites sur ce segment réseau.
location 4 : Sur un sous réseau , comme pour la location 3, vise à proteger un sous réseau
particulier.
Une autre famille d’outils pour la sécurité réseau existe : les systèmes de prévention des intru-
sions (IPS Intrusion Prevention System)
A. Systeme de Détection d’Intrusion 66

A.4. Qu’est ce qu’un système de prévention d’intrusion ?

A.4.1. Présentation de l’IPS

Un système de prévention d’intrusion est un dispositif aussi bien matériel que logiciel, qui
permet de détecter des attaques, connues et inconnues, et de les empêcher d’être réussies.
L’IPS fait partie du réseau ; il est placé en ligne et examine tous les paquets qui entrent et
sortent. Il surveille ce trafic et intervient par limitation ou supression du trafic qu’il juge dan-
gereux. Il réalise un ensemble d’analyses sur chaque paquet et sur les motifs du réseau, en
visualisant chaque transfert dans le contexte qui précède et suit.
Un IPS est composé principalement de 4 modules :
– Normalisation du traffic (Traffic normalizer)
– Scanner de service(Service scanner)
– traffic shaper
– Moteur de détection(Detection engine)
Le Traffic normalizer surveille le trafic, il analyse les différents paquets et exécute certaines
mesures contre les attaques, comme le blocage d’IP. Le trafic une fois analysé est passé au
Detection engine et au Service scanner. Celui ci établi une table de référence qui classe les
informations afin d’aider le Traffic shaper à gérer le flux de ces informations. Le Detection
engine compare les schémas d’évènements en cours avec ceux qui sont dans la table de référence.

A.4.2. Les types d’IPS

Il existe deux types d’IPS :
– Les NIPS (Network Intrusion Prevention System), un logiciel ou un matériel dédié qui est
connecté directement à un segment du réseau et qui protège les systèmes de ce segment.
– Les HIPS (Host Intrusion Prevention System), un programme système installé directement
sur l’ordinateur à surveiller.

Network IPS

Le Network IPS (NIPS) combine les caractéristiques d’un IDS standard avec celles d’un firewall.
On le qualifie parfois de firewall à inspection en profondeur (deep inspection).
Comme avec un firewall, le NIPS a au minimum deux interfaces réseau, une interne et une
externe. Les paquets arrivent par une des interfaces et sont passés au moteur de détection.
L’IPS fonctionne pour le moment comme un IDS, c’est à dire qu’il détermine si oui ou non le
paquet est malveillant. Cependant, en plus de déclencher une alerte dans le cas ou il détecte un
paquet suspect, il rejettera le paquet et marquera cette session ”suspecte”. Quand les paquets
suivant de cette session arriveront à l’IPS, ils seront jetés.
Les NIPS sont déployés en ligne avec le segment du réseau à protéger. Du coup, toutes les
données qui circulent entre le segment surveillé et le reste du réseau sont forcées de passer par
le NIPS.
A. Systeme de Détection d’Intrusion 67

Un NIPS déclenche des alarmes du type “tel ou tel trafic a été détecté en train d’essayer
d’attaquer ce système et a été bloqué”.
Un NIPS ne nécessite pas d’intervention humaine si la sécurité n’est pas primordiale pour
l’entreprise. Dans le cas contraire une intervention humaine est préférable pour surveiller les
intervention automatisées du NIPS.
Lesprincipaux avantages d’un NIPS sont :
– Un seul point de contrôle pour le trafic peut protéger tout les systèmes situés en aval du
dispositif.
– Le déploiement est facile car un seul dispositif IPS suffit pour des dizaines de systèmes.
– Il protège des autres dispositifs du réseau car toutes les attaques peuvent aussi être dirigées
contre des routeurs, des firewall..
– Il protège des attaques réseaux : DoS, SYN flood etc.. Travailler au niveau du réseau permet
à un NIPS de protéger contre ces attaques.

Host IPS

Le HIPS est un programme résidant sur un système tel que les serveurs ou les postes de travail.
Le trafic qui entre et sort de ce système est inspecté et les activités au niveau des applications
et du système d’exploitation peuvent être surveillées afin d’y trouver des signes d’une attaque.
Un HIPS peut détecter les attaques visant la machine, et arrêter le processus malveillant avant
qu’il ne s’exécute.
Le HIPS ne nécessite plus de service de journalisation des évènements (log). Quand une attaque
est détectée, le logiciel bloque l’attaque soit au niveau de l’interface réseau, soit en envoyant des
commandes à l’application ou au système d’exploitation, leur disant d’arrêter l’action lancée
par l’attaque.
Un HIPS possède une liste prédéfinie de règles, définie par le fabriquant et livrée avec le produit.
Ces règles savent comment un système d’exploitation ou une application doit se “comporter
normalement”. Si l’application entame une action suspecte, une des règles est activée et le
processus est tué avant de nuire au système.
D’autres systèmes HIPS emploient la méthode ”surveillance”. Un agent HIPS tourne sur l’or-
dinateur et se concentre sur les événement d’un système d’exploitation en observant tous les
appels système, les entrées de la base de registre.
Les principaux avantages d’un Host IPS :
– Protège les systèmes mobiles contre une attaque quand ils sont hors du réseau protégé.
– Protège des attaques locales, le personnel ayant un accès physique et voulant corrompre
certains systèmes à l’aide de disquette ou CD...
– Garantie une dernière défense contre les attaques ayant passer les autres systèmes de sécurité.
– Les attaques lancées entre les systèmes du même segment réseau ne peuvent être contrées
qu’avec le HIPS.
– Indépendant de l’architecture réseau
 B
Outils utilisés

B.1. Script permettant d’exécuter l’attaque BYE

1 #!/bin/sh
2
3 interface=eth0
4 domain=192.168.0.219
5
6 echo "attack teardown"
7 echo −n "target user (e.g.john.doe or 5000):"
8 read user
9 echo −n "from user (e.g.john.doe or 5000):"
10 read attacker
11 echo −n "IP address of target: "
12 read target
13 echo −n "Call ID: "
14 read callid
15 echo −n "From tag: "
16 read from
17 echo −n "To tag: "
18 read to
19 echo −n "IP address of source: "
20 read IPsource
21
22 echo
23
24 echo"Start teardown"
25 echo "parameters ...."
26 echo "interface:$interface target user:$user IP target domain:$domain IP target user:$target
Call ID:$callid From tag:$from To tag:$to IP source:$IPsource"
27 cd /home/vadese/workspace/voipsecurity/teardown
28 sudo ./teardown $interface $user $domain $target $callid $from $to −i $IPsource −a $attacker −v
29
30 read enter
31
32 exit 0

B.2. Fichier de configuration : nfr ida.cfg

Using any text editor, create a file containing the following entries. For each configuration
parameter, replace the value to the right of the equal sign with the specific value. To provide
the value for admin pass and admin pass2, paste the encrypted password from the previous
step.
admin pass=<paste encrypted password here>
B. Outils utilisés 69

admin pass2=<paste encrypted password here>

mngmtintf=em0
ipaddr0=nnn.nnn.nnn.nnn
netmask0=nnn.nnn.nnn.nnn
defroute=nnn.nnn.nnn.nnn
hostname=myhost
ip central=nnn.nnn.nnn.nnn
crypto=passphrase
ip central2=nnn.nnn.nnn.nnn
crypto2=passphrase
localtime=/nfr/zone/North America/United States/Eastern
ntphost1=nnn.nnn.nnn.nnn
ntphost2=nnn.nnn.nnn.nnn
ntpkeynum=5
ntpkey=sf709qw374@#$ !@#
Mode=inline fail-passthrough
Inline if1=em1
Inline if2=em2
Save the file as nfr ida.cfg to a Windows-formatted disk (VFAT file system).

B.3. Générateur de message SIP

Le SIPNess messenger d’ortena Network (www.ortona.com) est un outil qui fournit à l’uti-
lisateur une manière facile de construire et d’envoyer des messages personnalisées SIP à un
interlocuteur distant, et en même temps de recevoir et surveiller les messages SIP entrants. La
version 1.06 utilisée supporte les messages INVITE, CANCEL, BYE, REGISTER, RINGING,
TRYING, ACK, OK, OPTION.
B. Outils utilisés 70

Fig. B.1.: Générateur de message SIPNess Messager

B.4. Tableau des Attaques SIP

Le tableau ci-dessous tiré du BP détaille ces risques avec la terminologie approprié. Il précise
dans la colonne de droite l’identifiant qui sera utilisé pour représenter chaque attaque dans le
document.
B. Outils utilisés 71
 C
Journal de Travail

Description Date de début Estimation de la durée

Séance d’information 15/03/2007 1 heure
avec Mr. Ventura et Mme Kuhn
Documentation sur Snort 15/03/2007 4 jours

Séance d’information 22/03/2007 1 heure

avec Mr. Ventura et Mme Kuhn
Labo Asterisk : VoIP1 &VoIP2 22/03/2007 2 jours

Recherche sur le protocole SIP 24/03/2007 2 jours

Etude du Best Practice 29/03/2007 3 jours

Séance d’information 05/04/2007 1 heure

avec Mr. Ventura et Mme Kuhn
Etude du Best Practice 05/04/2007 2 jours

Documentation sur les IDS 12/04/2007 2 jours

Séance d’information avec Mr. Ventura,

Mme Kuhn et la société Check Point 19/04/2007 1 heure
Documentation sur les IDS 19/04/2007 3 jours

Lecture du Guide d’installation

de l’IPS-1 Check Point 26/04/2007 3 jours
Séance d’information
avec Mr. Ventura et Mme Kuhn 03/05/2007 1 heure
Lecture du Guide d’installation 10/05/2007 2 jours
de l’IPS-1 Check Point
Installation de l’IPS-1 Check Point :
Server, Management Dashboard 14/05/2007 2 heures
Lecture du l’Administrative
C. Journal de Travail 73

Guide de l’IPS-1 17/05/2007 2 jours

Séance d’information 24/05/2007 1 heure
avec Mr. Ventura et Mme Kuhn
Attaques sur la sonde 31/05/2007
au 07/06/2007
Rédaction du rapport à partir du 14 juin