Professional Documents
Culture Documents
Pré-projet de diplôme
Introduction 4
Contexte et aperçus des activités . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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
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
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.
– 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.
– 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.
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
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.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
Etape 2
Choisir l’emplacement de l’installation sur le disque local, celui par défaut convient très bien.
Etape 3
Quelques précisions concernant la destination des fichiers installés et sur la taille nécessaire.
Etape 4
Etape 5
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
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 :
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
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
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 :
Possibilité de voir les caractéristiques de la sonde, les packages que contient l’alert concentrator :
Management ⇒ Policies :
1. IPS-1 Check Point 19
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
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”.
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
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.
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
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
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 policy group est une collection de packages et backends.
1. IPS-1 Check Point 25
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”.
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
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
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.
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
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
c) Sip/multitech : cette règle permet de déceler une attaque utilisant plusieurs tech-
niques d’attaques.
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.
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
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.
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.
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
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
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
S’assurer que les cibles ont été bien sélèctionnées : Targets ⇒ Current Targets
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
Laisser les options par défaut et click ok puis commencer le sniffing Start ⇒ Start Sniffing
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.
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.
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.14.: Envoi d’un paquet UDP de taille supérieure à la taille maximale
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
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
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...
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
Provoquons une attaque en envoyant sur le réseau grâce à SIPNess un paquet de taille
supérieure à 8 bytes.
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.
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...).
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”.
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
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
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.
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 .
En initiant une communication avec bob une alerte de type sip uservars :bad uri alert
est émise.
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
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.
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.
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.
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.
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
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