Travails Em Est Re

PPD Pr´e-projet de diplˆome

Syst`eme de D´etection d’Intrusion VoIP : IPS-1 Check Point 7 janvier 2008

Table des mati`eres

Introduction Contexte et aper¸cus des activit´es . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. IPS-1 Check Point 1.1. Description de l’IPS-1 Check Point . . . . . . . . 1.2. D´eploiement des sc´enarios . . . . . . . . . . . . . 1.3. Installation et configuration . . . . . . . . . . . . 1.3.1. IPS-1 Sensor . . . . . . . . . . . . . . . . . 1.3.2. IPS-1 Alerts Concentrator et IPS-1 Server 1.4. L’IPS-1 Management Dashboard . . . . . . . . . . 1.4.1. Installation . . . . . . . . . . . . . . . . . 1.4.2. Pr´esentation de l’interface . . . . . . . . . 1.4.3. Configuration . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

4 4 4 6 6 8 9 9 10 11 11 15 19

2. Packages et Backends 29 2.1. Configuration du policy group sipOnly . . . . . . . . . . . . . . . . . . . . . . . 31 3. Tests 3.1. Topologie du r´eseau . . . . . . . . . . . . 3.2. Les attaques . . . . . . . . . . . . . . . . 3.2.1. ARP Spoofing . . . . . . . . . . . 3.2.2. Injection de paquet SIP malform´e

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

36 36 38 40 47

4. Synth` ese et conclusion

58

5. Cahier des charges 5.1. Pr´esentation . . . . . . . . . . . . . 5.1.1. Contexte . . . . . . . . . . . 5.1.2. Description g´en´erale . . . . 5.2. Travaux `a r´ealiser . . . . . . . . . . 5.2.1. Tutorial du langage N-code 5.2.2. Ecriture des r`egles . . . . . 5.3. Organisation du travail . . . . . . .

60 60 60 60 60 60 61 61

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Table des mati`eres

3

5.3.1. Journal de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2. Outil de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. Systeme de D´ etection d’Intrusion A.1. Types d’IDS . . . . . . . . . . . . . . . . . . . . . . A.1.1. Network IDS . . . . . . . . . . . . . . . . . A.1.2. Host IDS . . . . . . . . . . . . . . . . . . . A.1.3. Les IDS “Hybrides” . . . . . . . . . . . . . . A.2. Les m´ethodes de d´etection . . . . . . . . . . . . . . A.3. O` u doit on placer l’IDS dans une topologie r´eseau . A.4. Qu’est ce qu’un syst`eme de pr´evention d’intrusion ? A.4.1. Pr´esentation de l’IPS . . . . . . . . . . . . . A.4.2. Les types d’IPS . . . . . . . . . . . . . . . . B. Outils utilis´ es B.1. Script permettant d’ex´ecuter B.2. Fichier de configuration : nfr B.3. G´en´erateur de message SIP B.4. Tableau des Attaques SIP . C. Journal de Travail

l’attaque BYE ida.cfg . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

61 61

. . . . . . . . .

63 63 64 64 64 64 65 66 66 66

. . . .

68 68 68 69 70 72

Introduction

Contexte et aper¸cus des activit´ es Le projet dont il est question dans ce document s’inscrit dans le cadre du travail de diplˆome sanctionnant la fin des ´etudes d’ing´enieur HES `a la HEIG-vd. Le but de ce travail est d’effectuer une s´erie de tests pour des syst`emes de d´etections 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’´etudier entre autre les aspects de s´ecurit´e de la VoIP et de proposer des solutions qui aident les entreprises : – a` r´ealiser des solutions de s´ecurit´e pour les r´eseaux VoIP (Best Practices, IDS, analyse de logs) – `a ´evaluer l’efficacit´e et le fonctionnement correct des solutions d´eploy´ees (audit, syst`eme de test). Au d´epart il s’agissait de mettre en place la sonde Snort et d’´ecrire quelques r`egles pour les filtres, cette id´ee a ´et´e abandonn´ee et a ´et´e remplac´ee par l’´etude de l’IDS SourceFire. Celui-ci sera rapidement abandonn´e car la soci´et´e Check Point nous propose d’´evaluer leur IDS appel´e IPS-1 Check Point. La phase de pr´e-projet de diplˆome a donc consist´e `a installer et `a configurer l’´equipement IDS mis `a disposition, `a mettre en place le r´eseau de test et `a effectuer une s´erie de tests permettant d’´evaluer l’IPS-1 Check Point.

Organisation du document Chapitre 1, l’IPS-1 Check Point Une description de notre IDS sera pr´esent´ee au lecteur ainsi que les ´etapes d’installation et de configuration de chaque composant de l’IPS-1 Check Point. Chapitre2, Packages et Backends Dans ce chapitre sera d´efini les packages et backends qui contiennent les r´egles de filtrage appliqu´es `a notre sonde. Chapitre 3, Tests Il s’agira de mettre en place le r´eseau de travail et d’effectuer des attaques VoIP.

Table des mati`eres

5

Chapitre 4, Synth`ese A partir des tests effectu´es dans le chapitre pr´ec´edent une ´evalution de la sonde fera l’object de ce chapitre. Chapitre 5, Cahier des charges Celui-ci sera consacr´e `a une description de l’objectif principale du travail de diplˆome qui se d´eroulera du 18 septembre au 12 d´ecembre 2007. Annexes Enfin la derni`ere partie regroupera les annexes dont une explication des IDS, une description des outils utilis´es et un journal de travail qui a accompagn´e l’auteur durant tout le projet.

1 IPS-1 Check Point

La Voix sur IP (VoIP) est un sujet extrˆemement en vogue actuellement et bon nombre de travaux y relatif ont ´et´e men´es `a terme ou sont en cours de r´ealisation. En effet de nombreuses entreprises adoptent ce mode de communication. Elle consiste `a encoder la voix et `a la faire passer par un r´eseau IP, qui peut ˆetre internet ou un r´eseau priv´e. Malheureusement ce type de service pr´esente des failles au niveau de la s´ecurit´e. Des ´equipements appel´es Intrusion Detection System (IDS) sont ´equip´es de fonctions sp´eciales appel´ees filtres qui permettront de surveiller le r´eseau informatique et de d´etecter toutes anomalies. Dans le cadre de notre travail l’IDS IPS-1 Check Point sera utilis´e dans le but de d´etecter les attaques SIP et les vuln´erabilit´es de ce protocole. Dans la pr´esente section, une description de cet IDS, ses fonctionnalit´es ainsi que les ´etapes d’installation et de configuration seront d´ecrites.

1.1. Description de l’IPS-1 Check Point L’IDS que nous ´etudierons est d´evelopp´e par la soci´et´e Check Point sp´ecialis´ee dans la fabrication des ´equipements pour am´eliorer la s´ecurit´e. L’IPS-1 Check Point comme son nom l’indique est un syst`eme de pr´evention d’intrusion (IPS). Sa fonction principale est d’empˆecher toute activit´e suspecte au sein du r´eseau d’une entreprise. Mais il peut fonctionner en plusieurs modes : – mode Passif : Dans ce mode l’IPS-1 se comporte comme un syst`eme de d´etection d’intrusion. 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¸coit une copie du traffic pour l’analyse de d´etection d’intrusion et soul`evera des alertes en cons´equence. Dans ce projet c’est ce mode qui sera activ´e. – mode Inline bridged : le mode bridge n’effectue pas de pr´evention en cas de d´etection d’attaque. Il se comporte presque comme en mode passive. Ce mode fourni une transition entre la d´etection et la pr´evention, l’utilisateur peux observer le fonctionnement de l’IPS-1 en ´evitant de rediriger ces attaques. Ce mode est utilis´e pour l’´equipe de gestion du r´eseau dans le sens o` u il permet d’acc´eder depuis le r´eseau `a la sonde sans que celle-ci ne soit en mode de pr´evention.

1. IPS-1 Check Point

7

– mode Inline prevention : Contrairement aux autres modes, l’IPS-1 se comporte comme un syst`eme de pr´evention d’intrusion. En plus de d´etecter une intrusion, il tente de la bloquer. L’IPS-1 Check Point se d´ecompose 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´ee de surveiller le trafic sur le r´eseau afin d’analyser les flux de donn´ees et d’´emettre des alertes `a destination du concentrateur (IPS-1 Alert concentrator ) en cas de d´etection de paquets non-conformes. Comment fait-il cette distinction ? Il existe des packages regroupant un ensemble de r´egles sp´ecifiques `a chaque type de protocole. Ces r`egles sont ´ecrites dans un langage de script N-code de telle sorte que si ces derniers sont viol´es le flux de donn´ees est jug´e non conforme ainsi la sonde enregistre l’´ev`enement comme une attaque. Ces packages sont subdivis´es en sous cat´egories (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´es en un bloc qui permet de stocker les alertes envoy´es par la sonde. Cela permet ´egalement de r´epartir la charge du r´eseau et donc de d´eployer si n´ecessaire 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`eme de d´etection d’intrusions. Les alertes sont affich´ees en temps r´eel et peuvent ˆetre class´ees en fonction de leur gravit´e. Cet affichage permet ´egalement de naviguer entre les diff´erentes alertes. De plus il est possible de visualiser les caract´eristiques de chaque alerte (le nom de l’alerte, le package et les backends qui ont permet de g´en´erer l’alerte, les adresses source et destination, les ports source et destination). D’autres manipulations sont ´egalements possibles : g´en´eration de graphes, visualisation des alertes selon la date d´esir´ee, visualisation et ajout des utilisateurs... L’architecture du produit est rep´esent´ee sur le sch´ema-ci dessous :

1. IPS-1 Check Point

8

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

1.2. D´ eploiement des sc´ enarios La mise en place des diff´erents composants de l’IDS `a l’interieur d’un r´eseau porte le nom de sc´enario. Check Point en propose deux : – Le small deployement : dans ce cas IPS-1 Alerts Concentrator et IPS-1 Server sont install´es sur la mˆeme plateforme. – Le large deployement : dans celui-ci IPS-1 Alerts Concentrator et IPS-1 Server sont install´es sur des plateformes diff´erentes. Dans le cadre du travail de diplˆome sera utilis´e 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 `a installer chacun de ses composants en suivant l’ordre ci-dessous. 1. IPS-1 Sensor est une appliance pr´e-configur´ee. Il est le premier composant `a ˆetre intall´e. 2. IPS-1 Alerts Concentrator et IPS-1 Server : ces deux composants seront ensuite install´es simultan´ement sur une distribution linux CentOS version 4. 3. IPS-1 Management Dashboard est une application cliente d´evelopp´ee java et sera install´e sur windows XP.

1.3.1. IPS-1 Sensor L’IPS Sensor nomm´e IPS-1 50C est une appliance pr´e-configur´ee. Mais dans le cadre de notre ´etude elle a ´et´e livr´ee sous forme de logiciel et a ´et´e install´e sur un ordinateur (PC) ayant comme distribution Linux Fedora. Le principal objectif de la sonde est l’´ecoute du r´eseau et la capture des paquets suspects. Notre PC poss`ede deux cartes d’interface r´eseau qui lui permettront de voir tout ce qui transite par le cˆable Ethernet. Un des ports sera utilis´e pour la gestion de la sonde et l’autre sera d´efini comme un port monitoring qui permettra de renvoyer sur ce port reli´e au switch la totalit´e du trafic du r´eseau. Afin de renifler tous les paquets sur le r´eseau, notre sonde a ´et´e configur´ee en mode passif donc se comportant comme un IDS furtif. Avant que l’IPS Sensor soit op´erationnel la configuration par d´efaut doit ˆetre remplac´ee pour ˆetre adapt´ee aux caract´eristiques de notre r´eseau de test. Elle peut s’effectuer de deux mani`eres : – Il est possible de configurer l’IPS-1 Sensor manuellement `a travers le menu de l’interface de l’IPS-1 Management Dashboard. Cette configuration vous sera pr´esent´ee dans la section 1.4.3 apr´es l’installation de l’IPS-1 Management Dashboard.

1. IPS-1 Check Point

10

– L’autre m´ethode s’effectue en cr´eant une disquette de configuration qui sera utilis´ee pour la configuration des autres IPS-1 Sensor. Il s’agira d’´editer un fichier texte “nfr ida.cfg”contenant toutes les valeurs n´ecessaires `a la configuration ainsi lors de la configuration d’une autre sonde il suffira juste d’adapter ces variables par rapport au r´eseau d´efini. Dans le cadre de notre projet nous avons utilis´e la configuration manuelle cf. annexe les param`etres de la configuration.

1.3.2. IPS-1 Alerts Concentrator et IPS-1 Server L’installation de ces deux composants n´ecessitent pr´ealablement un compte utilisateur. C’est par ce compte que nous pourrons nous connecter `a l’interface cliente l’IPS-1 Management Dashboard. 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`ede pas tous les privil`eges que l’administrateur (root). A l’emplacement suivant :” etc ⇒ sudoers“ se trouve le fichier de configuration sudoers permettant de modifier les droits de ce dernier en lui attribuant les mˆemes privil`eges que le root. Les ´etapes d´ecrites ci-dessus sont illustr´ees par les commandes ci-dessous qui devront ˆetre ex´ecut´ees en tant que root. 1. Cr´eer un r´epertoire o` u sera install´e le produit : mkdir /usr/local/nfr 2. Cr´eer le groupe nfr : /usr/sbin/groupadd nfr 3. Cr´eer 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´etaire : chown -R nfr :nfr /usr/local/nfr La premi`ere ´etape consiste `a monter le CD d’installation puis `a installer l’IPS-1 Alerts Concentrator et l’IPS-1 Server. Lors de cette ´etape nous d´efinirons 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´eployer le sc´enario “small deployement” nous pr´eciserons alors que l’IPS-1 Alerts Concentrator et l’IPS-1 Server seront install´es sur la mˆeme 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´epertoire CD-ROM : cd /media/cdrom 4. Installation : ./install

1. IPS-1 Check Point

11

5. Cr´eation 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´erents composants du Check Point, le menu suivant apparait : Combo (both servers)= 2 (Installs both) [0/1/2] (default =2) . Cette instruction permet de pr´eciser que l’alert concentrator et le serveur seront install´es sur la mˆeme 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´ecut´ees les commandes ci-dessus vient une deuxi`eme ´etape qui consiste `a d´efinir le nom du serveur, l’adresse IP du serveur et les diff´erents param`etres tels que le mot de passe permettant d’acc´eder `a la base de donn´ees et le num´ero port de la base de donn´ees. 1. Premi`ere 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´electionne “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 `a l’administrateur pour l’acc´es `a la base de donn´ees MySQL : “Enter the password for the Alerts Concentrator database admin (MySQL.)” ⇒ IPS1Sensor 5. Fournir un mot de passe `a l’utilisateur nfr pour l’acc´es `a la base de donn´ees MySQL : “Enter the password for the Alerts Concentrator database user (MySQL.)” ⇒ IPS-1Sensor 6. Num´ero de port de la base de donn´ee : “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 ´et´e install´e sur Windows XP Professional avec SP2. Il peut ´egalement ˆetre install´e 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´ecutant le fichier setupwin32.exe disponible sur le CD. L’ensemble du processus est tr´es simple il suffit juste de suivre les instructions. Chaque ´etape est illustr´ee ci-dessous par des captures d’´ecran.

1. IPS-1 Check Point

12

Etape 1 Double-cliquer sur le fichier ex´ecutable setupwin32.exe. On obtient la fenˆetre d’accueil de l’installation de l’IPS-1 Management Dashboard suivante :

Fig. 1.3.: Fenˆetre d’accueil pour l’installation Etape 2 Choisir l’emplacement de l’installation sur le disque local, celui par d´efaut convient tr`es bien.

Fig. 1.4.: S´el`ection de l’emplacement de l’installation

1. IPS-1 Check Point

13

Etape 3 Quelques pr´ecisions concernant la destination des fichiers install´es et sur la taille n´ecessaire.

Fig. 1.5.: Pr´ecision sur la taille requise Etape 4 L’installation peut alors d´emarrer :

Fig. 1.6.: Ajout des composants n´ecessaire

1. IPS-1 Check Point

14

Etape 5 Le Management Dashboard est prˆet `a ˆetre utlis´e.

Fig. 1.7.: Fin de l’installation Pour lancer l’application il faut se rendre dans D´ emarrer ⇒ Programmes ⇒ Check Point IPS-1 ⇒ IPS-1 Management Dashboard . On obtient la page d’accueil ci-dessous permettant de se loguer sur le serveur afin de visualiser les alertes. L’utilisateur est celui cr´e´e pr´ec´edemment “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´ esentation de l’interface Une fois connect´e, la fenˆetre principale de l’application cliente s’affiche comme illustr´e cidessous :

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 permettant d’effectuer plusieurs actions. File : ce menu permet d’ouvrir, de sauver, de supprimer l’affichage des alertes. Il permet ´egalement de fermer l’application. Tools : – Recorder Events permet de regarder les ´ev´enements qui ont ´et´e produits lorsqu’une alerte a ´et´e d´eclench´ee. – System Statuts permet de visualiser l’´etat du serveur et de la sonde.

1. IPS-1 Check Point

16

– User Preferences permet de modifier certaines fonctionnalit´es : marquer les alertes lues, les d´etails des alertes. – Change Password offre la possibilit´e `a l’utilisateur de changer son mot de passe pour la connexion `a l’IPS-1 Management Dashboard. – Statut log Alert Browser : d´efini les diff´erentes colonnes caract´erisant les alertes lors de l’affichage. Windows : permet de savoir les fenˆetres actuellement ouvertes. Management : – Users : permet de cr´eer, ajouter et supprimer des utilisateurs – Policies : permet de cr´eer, 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´ees pour le stockage des alertes. La barre d’outils contient ´egalement un ensemble de boutons permettant plusieurs actions :

Interrompre le chargement de alertes.

Afficher les alertes en groupe et par ordre de priorit´e. Marqueur permettant d’annoter les alertes lues.

D´efinir une date et afficher les alertes d´etect´ees `a cette date.

Ouvrir une nouvelle fenˆetre.

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 ˆetre visualis´ees sous deux formes soit comme montr´e lors de la pr´esentation de la page principale en fontion du temps de d´etection ou regroup´ees en fonction de leur gravit´e comme ci-dessous.

1. IPS-1 Check Point

17

Fig. 1.10.: Affichage des alertes en fonction de leur gravit´e Le centre de la fenˆetre permet d’explorer les alertes d´etect´ees par la sonde. En double-cliquant sur une alerte on peut visualiser les d´etails la concernant ( nom, adresses source et destination, ports source et destination, protocole utilis´e, packagess). Le bouton Show Raw Packets permet de sauvegarder dans un fichier les trafics qui ont provoqu´e cette attaque. Ce fichier peut ˆetre visualiser par Ethereal.

1. IPS-1 Check Point

18

Fig. 1.11.: d´etails d’une alerte Comme pr´ecis´e ci-dessus il est ´egalement possible de voir l’´etat de la sonde et de l’alerte concentrator en double-cliquant sur l’icone bleue :

Fig. 1.12.: Etat de l’Alert concentrator et de la sonde Possibilit´e de voir les caract´eristiques de la sonde, les packages que contient l’alert concentrator : Management ⇒ Policies :

1. IPS-1 Check Point

19

Fig. 1.13.: Caract´eristique de l’Alert concentrator

Fig. 1.14.: Caract´eristique de la sonde

1.4.3. Configuration Une fois l’IPS-1 Management Dashboard op´erationnel nous configurons l’IPS-1 Alert concentrator et l’IPS-1 Sensor puis dans un second temps nous importerons les packages contenant les r`egles qui permettront `a la sonde de consid´erer qu’un flux de donn´ees est non conforme ou pas. D`es lors l’IPS-1 Management Dashboard est prˆet `a ˆetre utilis´e. Vu que nous sommes plusieurs `a s’int´eresser `a ce projet nous cr´eerons un compte pour chaque utilisateur et nous leur associerons des droits bien sp´ecifique 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´ees 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ˆetre ci-dessous apparait o` u nous pouvons ajouter un nouveau serveur : “New Alert Concentrator”.

Fig. 1.15.: Ajout de l’Alert Concentrator Nous configurons notre serveur en pr´ecisant son adresse IP, le nom d’utilisateur et son mot de passe. Ces informations doivent ˆetre identiques `a celles attribu´ees 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´electionnons l’option “Add New Sensor”. Ainsi la fenˆetre suivante apparait o` u nous pr´eciserons le nom de la sonde, son adresse IP et le mot de passe permettant l’acc`es.

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 ˆetre identique `a celui qui lui ´et´e attribu´e lors sa configuration. Dans notre cas il s’agit de : CP-Sensor-50 2 : Adresse IP doit ˆetre ´egalement identique `a celle attribu´e `a 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 ˆetre de type IPS. 4 : Password et la confirmation de ce dernier doit ˆetre le mˆeme que celui fournit `a la sonde lors sa configuration. Etape 3 : T´ el´ echargement des packagess Le t´el´echargement des packages depuis un serveur distant est une ´etape tr`es importante car contenant les r`egles permettant de d´eclencher une alerte. Cela s’effectue tr`es rapidement, il suffit juste de pr´eciser le nom du serveur et son port puis de d´emarer le t´el´echargement.

1. IPS-1 Check Point

23

Fig. 1.18.: Mise `a jour des packagess Une fois cette ´etape termin´ee nous pr´eciserons la prochaine mise `a jour de mani`ere automatique depuis la barre d’outils : Management ⇒ Policies ⇒ Policy Manager ⇒ Update Packages

Fig. 1.19.: Mise `a jour des packagess

1. IPS-1 Check Point

24

Dans la mesure o` u nous sommes plusieurs `a ˆetre int´eress´e par ce projet nous avons dˆ u cr´eer un compte pour chaque utilisateur : Management ⇒ User ⇒ New . Plusieurs options de manipulation des comptes sont offertes, notamment la possibilit´e d’attribuer `a chaque utilisateurs un des deux privil`eges suivants : 1. Le privil` ege Normal donne `a l’utilisateur uniquement la possibilit´e d’afficher les alertes. Comme nous pouvons le constater sur le sch´ema ci-dessous (mis en ´evidence sur le menu Management) seul le sous groupe view Policies apprait.

Fig. 1.20.: Utilisateur avec privil`ege “Normal” a) A partir de view Policies cet utilisateur acc`ede aux packages/backends du policy group1 “ALL” et non les packages/backends configur´es pour notre sonde. Comme nous l’observons sur le sch´ema ci-dessous le “policy group” (SipOnly) li´e `a notre sonde n’apparait pas.

1

Le policy group est une collection de packages et backends.

1. IPS-1 Check Point

Fig. 1.21.: Les packages acc´essibles pour un utilisateur Normal 2. Le privil` ege administrateur fourni beaucoup plus de possibilit´es `a l’utilisateur.

25

1. IPS-1 Check Point

26

Fig. 1.22.: Utilisateur avec privil`ege “Administrateur” a) En ce qui concerne la gestion des utilisateurs, l’administrateur peut cr´eer ou supprimer des comptes `a travers le menu Management ⇒ User . Il pourra ´egalement d´ev´erouiller un compte car celui-ci peut ˆetre bloqu´e au bout de trois tentatives d’authentification erron´ees. Le cas ´ech´eant, le bouton “Unlock Account” est accessible sinon gris´e.

1. IPS-1 Check Point

27

Fig. 1.23.: Compte utilisateur b) En ´etant administrateur, il est possible d’acc`eder `a tous les policy group d´efinis. Depuis Management ⇒ Policy . L’administrateur peut par exemple s´electionner les packages/backends dont il a besoin et sauvegarder ces changements en clickant sur le bouton “Apply”.

Fig. 1.24.: Les Packages/Backends acc´essibles pour un utilisateur admin c) Management ⇒ Space Management permet d’acc´eder aux informations relatives `a l’espace disque r´eserv´e pour les diff´erents composants de notre IDS.

1. IPS-1 Check Point

Fig. 1.25.: Caract´eristique du composant IPS-1 Sever

28

2 Packages et Backends

L’IPS-1 Sensor contrˆole le r´eseau en se basant sur les packages et backends pour filtrer les ´ev`enements. Les backends contiennent des r`egles ´ecrites dans un langage de script appel´e NCode et sont contenus dans un package qui porte le nom du protocole auquel il est rattach´e. Dans cette section nous d´efinirons les diff´erents packages et backends appliqu´es `a notre sonde ainsi que leurs configurations. L’IPS-1 Sensor se comportera selon la configuration qui lui est appliqu´ee. Parmi les crit`eres de configurations nous pouvons citer : – Les types de packages et backends install´es. – L’´etat de ces packages/backends car ils peuvent ˆetre activ´es ou d´esactiv´es. – La configuration des valeurs des diff´erentes variables. Dans la configuration par d´efaut notre sonde est rattach´ee `a un “Policy Group” appel´e ALL. Celui-ci est une collection de Packages/Backends pouvant ˆetre appliqu´es `a une sonde, tous les autres policy cr´e´es seront des descendants du policy Group ALL. Comme mentionn´e dans l’introduction, le but de ce travail est de tester la vun´erabilit´e du protocole SIP. Pour cela nous allons cr´eer un nouveau “Policy Group” appel´e sipOnly qui contiendra uniquement les packages et backends utiles pour effectuer des tests SIP. Pour cr´eer 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´eation d’un nouveau Policy Group Lors de la cr´eation d’un policy group, celui-ci h´erite automatiquement de la configuration de son parent. Le choix nous ait laiss´e de s´electionner et de d´es´electionner les packages/backends utiles dans le cadre de notre ´etude. Vu que nous aimerions que notre sonde partage la mˆeme configuration que sipOnly alors nous allons juste glisser la sonde sous le policy group sipOnly. Pour appliquer ces packages `a notre sonde il suffit depuis l’icˆone 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 `a 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´ecifiques l’IPS-1 Sensor

2.1. Configuration du policy group sipOnly sipOnly est form´e des packages suivants : attacks, authentification, badfiles, dhcp, dns, fingerprint, 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´efaut. La liste des adresses sources et destinations `a ignorer est vide tandis que les backends broadcast_addrs et my_network ont ´et´e modifi´es en fonction de notre r´eseau. a) broadcast_addrs : comme son nom l’indique ce backend permet de d´efinir une liste contenant les adresses broadcasts des diff´erents r´eseaux de notre syst`eme. Cette liste est d´efinie dans le champs Variable. Cette variable a ´et´e adapt´e en fonction de notre r´eseau est ´egale `a 192.168.0.255.

2. Packages et Backends

32

Fig. 2.3.: D´efinition de l’adresse broadcast b) my_network contient la liste des r´eseaux de notre syst`eme. Dans notre cas les serveurs de localisation, d’enregistrements , le proxy et les t´el´ephones sont dans le r´eseau 192.168.0.0. Les adresses IP renferme le masque du r´eseau.

Fig. 2.4.: D´efinition du r´eseau local 2. Le package attack contient les backends qui permettent d’agir en cas de d´etection d’attaques. Les variables des r´egles CAPTURE CONFIG et GUARENTEE RESPONSES du

2. Packages et Backends

33

backends attack/capture ont ´et´e modifi´es `a 2 et 1 respectivement. 3. Dans le package dns la variable des serveurs dns ont ´et´e modifi´es par rapport `a notre serveur dns (10.192.48.100, 10.192.48.101). 4. Le nombre d’hˆotes maximals `a scanner a ´et´e fix´e `a 57 par minute dans le backend ip/hostscan du package ip. 5. La variable de la r´egle TFTP MAX FILENAME du backend tftp/tftp a ´et´e fix´e `a 40. Cette variable repr´esente la taille limite des fichiers de configurations des t´el´ephones cisco qui utilisent le protocole tftp. 6. Le package SIP poss`ede quatres backends qui contiennent chacune un fichier avec l’extension .desc donnant une description de cette r`egle (durant le travail de diplˆome apr`es se familiariser avec N-code une description d´etaill´ee de tous les onglets sera fournie). a) sip/compliance : est une r`egle li´ee `a la structure des paquets. Une alerte sera d´eclench´ee si dans l’en-tˆete du paquet les messages sip (INVITE, BYE, CANCEL... ) sont ´ecrits en minuscule ou la taille des paquets est sup´erieure `a celle fix´ee. Elle est `a 1300 Bytes par d´efaut mais peut ˆetre ´edit´ee.

Fig. 2.5.: Description de SIP Compliance b) Sip/logging : celle ci n’est pas une r`egle 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`egle permet de d´eceler une attaque utilisant plusieurs techniques d’attaques.

Fig. 2.7.: Description de SIP Multitech d) Sip/uservars : celle ci permet de d´eclencher une alerte si l’en-tˆete SIP n’est pas conforme `a la rfc et lorsque les messages sip sont inconues.

Fig. 2.8.: Description de SIP uservars Apr´es avoir sauvegard´e 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 2. . .nfrrc 3. bin/get -n CP-Sensor-50 -x exec sysinfo

35

3 Tests

3.1. Topologie du r´ eseau Une fois l’installation et la configuration de l’IPS-1 Check Point termin´ees, nous mettons en place un r´eseau SIP (Session Initiation Protocol RFC 3261) de fa¸con `a pouvoir effectuer des attaques VoIP. Le protocole SIP (Session Initiation Protocol) succ`ede au standard H.323 grˆace `a sa conception plus ´evolu´ee et plus adapt´ee au protocole IP. Ce protocole a ´et´e d´evelopp´e par l’Internet Engineering Task Force (IETF) qui contribue `a ´elaborer de nombreux standard que l’on retrouve sur l’Internet `a l’instar de H.323 qui est issu du monde des t´el´ecoms. Le protocole SIP a pour principal objectif d’initialiser la session. Les requˆetes SIP sont constitu´ees par des en-tˆetes au sein desquels on retrouve une description de l’appel. La requˆete contient aussi le corps du message. Cette partie d´ecrit la demande de session. La topologie de notre r´eseau est ainsi faite :

3. Tests

37

Comme le sch´ema ci-dessus le montre notre r´eseau SIP est compos´e des ´el´ements suivants : Les Terminaux Ces terminaux sont des t´el´ephones Cisco pouvant ´emettre et recevoir de la signalisation SIP. SIP est un protocole point `a point, les liaisons sont donc ´etablies d’un terminal `a un autre, il est aussi client-serveur cela vient du fait qu’un terminal dit aussi Agent devient client lorsqu’il ´emet des requˆetes et re¸coit des r´eponses (UAC User Agent Client) et donc son partenaire devient serveur (UAS User Agent Serveur) puisqu’il r´epond `a ces requˆetes. Serveur d’enregistrement Ce serveur est essentiel dans tous les r´eseaux SIP. Il permet `a un t´el´ephone de pouvoir s’enregistrer au moyen de la requˆete REGISTER, ce t´el´ephone annonce sa position actuelle (adresse IP) au serveur qui sera charg´e de la transmettre au serveur de localisation. Serveur de localisation Ce serveur permet de m´emoriser les diff´erents utilisateurs, leurs droits, leur mot de passe ainsi que leurs positions actuelles.

3. Tests

38

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

3.2. Les attaques L’informatique ´etant un domaine tr`es vaste, le nombre de vuln´erabilit´es pr´esentes sur un syst`eme peut donc ˆetre important. Ainsi, les attaques visant ces failles peuvent ˆetre `a la fois tr`es vari´ees et tr`es dangereuses. Tir´es du document “Best Practrices for VoIP-SIP Security (BP)” (www.vadese.org) les principaux risques connus li´es `a l’utilisation de la VoIP en entreprise sont : D´ eni de Service (DoS) : Attaques entraˆınant l’indisponibilit´e d’un service/syst`eme pour les utilisateurs l´egitimes. Ecoute clandestine : Attaques permettant d’´ecouter l’ensemble du trafic de signalisation et/ou de donn´ees. Le trafic ´ecout´e n’est pas modifi´e. D´ etournement du trafic : Attaques permettant de d´etourner le trafic au profit de l’attaquant. Le d´etournement peut consister `a rediriger un appel vers une personne ill´egitime ou `a inclure une personne ill´egitime dans la conversation. Usurpation d’identit´ e : Attaques bas´ees sur la manipulation d’identit´e. vols de services : Attaques permettant d’utiliser un service sans avoir `a r´emun´erer son fournisseur. communications ind´ esir´ ees : Attaques permettant `a une personne ill´egitime d’entrer en communication avec un utilisateur l´egitime. La matrice d’attaque du document “Best Pactrice” (www.vadese.org) nous donne toute la panoplie des Attaques SIP (et solutions). Pour l’utiliser : – Colonnes de gauche = la liste des attaques, avec identifiant et nom. – Partie sup´ erieure = la liste des solutions, class´ees par type avec identifiant et nom. – Une croix dans la matrice indique que l ?attaque est contr´ee par la solution. Pour une analyse plus d´etaill´ee : – – – –

Cette matrice peut se lire de deux mani`eres. Verticalement, elle permet de voir quelle(s) attaque(s) est(sont) contr´ee(s). Horizontalement, elle permet de voir la(les) solution(s) appropri´ee(s). L´egende 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´ealiser l’attaque. 3. X La solution couvre l’attaque, mais il se peut qu’une personne se soit appropri´ee les donn´ees d’authentification d’un utilisateur l´egitime. 4.

Solution li´ee `a la solution comprenant une croix `a sa gauche.

Quelques attaques du Best Practice seront effectu´ees lors du travail de diplˆome. Dans les sections suivantes, seront test´es les filtres d´evelopp´es 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 ˆetre envoy´es vers le commutateur dans le but de l’inonder. Le switch ne sachant pas interpr´eter les nouvelles adresses fonctionnant r´eellement sur le r´eseau, il les consid`ere comme inconnues et fonctionne donc comme un concentrateur. Il envoie donc les trames entrantes vers tous ses ports. Ainsi l’attaquant pourra r´ecup´erer 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 `a 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´eseau. Pour effectuer cette usurpation, la machine attaquante s’interpose entre deux machines du r´eseau et transmet `a chacune un paquet ARP falsifi´e indiquant que l’adresse MAC de l’autre machine a chang´e, l’adresse MAC fournie ´etant celle de l’attaquant. Les deux machines cibles vont ainsi mettre `a jour leur table dynamique appel´ee Cache ARP. De cette mani`ere, `a chaque fois qu’une des deux machines souhaitera communiquer avec la machine distante, les paquets seront envoy´es `a l’attaquant. Cette technique d’attaque appel´e man in the middle (MITM) rend totalement transparent l’attaquant et donc permet `a ce dernier d’acc´eder `a toutes les communications sans que les machines cibles ne se rendent compte. Voici un sch´ema explicatif.

3. Tests

41

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

Fig. 3.1.: Lancement de ettercap Etape 2 Une fenˆetre s’affiche vous demandant le nom de l’interface utilis´e (eth0 dans notre cas). Faire un scan : Host ⇒ Scan for hosts. Double-cliquer sur Host ⇒ hosts list

3. Tests

42

Fig. 3.2.: S´election de “Host list” On obtient la fenˆetre suivante avec tous les hosts :

Fig. 3.3.: Aper¸cu de la liste des “hosts” Etape 3 D`es lors nous pouvons s´electionner les machines cibles dans la liste propos´ee 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 ´et´e bien s´el`ectionn´ees : Targets ⇒ Current Targets

Fig. 3.5.: S´election de Current Targets ce qui nous permet de visualiser les cibles.

3. Tests

44

Fig. 3.6.: Aper¸cu de toutes les cibles Etape 4 D`es `a pr´esent nous pouvons choisir notre type d’attaque MITM : Mitm ⇒ Arp poisoning. L’arp poison est une attaque par d´eni de service dont le but est de “tromper” des postes sur le mˆeme r´eseau ethernet en falsifiant des adresses MAC pour des adresses IP donn´ees. L’attaque peut porter sur deux axes. – Le premier est une attaque massive sur un r´eseau afin de remplir les tables ARP des postes sur le r´eseau. Ceci peut provoquer rapidement une saturation du r´eseau au niveau des requ`etes ARP arp who-has (`a 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´election de l’attaque ARP Poisoning Laisser les options par d´efaut 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ˆet de l’attaque 2. Start ⇒ Stop sniffing

Fig. 3.10.: Arrˆet du sniffing

3. Tests

47

Fig. 3.11.: Sniffing avec Ethereal Comportement de la sonde Apr´es avoir mis en place cette attaque nous constatons que la sonde reste indiff´erente car aucune alerte n’a ´et´e d´ecel´ee.

Fig. 3.12.: Alertes d´etet´ees par la sonde Une fois cette attaque mise en place l’efficacit´e des filtres appliqu´es `a IPS-1 Sensor est test´ee dans la section suivante . Nous injecterons dans le r´eseau des faux paquets SIP (les m´ethodes SIP en minuscule, des paquets SIP avec des m´ethodes 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´ e Le SIPNess messenger (www.ortona.com) est un outil qui fournit `a l’utilisateur une mani`ere facile de construire et d’envoyer des messages personnalis´ees SIP `a un interlocuteur distant, et en mˆeme temps de recevoir et surveiller les messages SIP entrants. La version 1.06 utilis´ee

3. Tests

48

supporte les messages INVITE, CANCEL, BYE, REGISTER, RINGING, TRYING, ACK, OK, OPTION. Par ce logiciel sera fa¸conn´e un message non conforme. Pourqoui cette appellation ? Un des backends sip/compliance du package SIP de la sonde contient des r´egles permettant de juger qu’un paquet est non conforme. 1. La premi`ere r`egle du backend sip/compliance est nomm´ee ALERT ON BIG UDP PACKET. Lorsque celle-ci est activ´ee la variable de configuration nomm´ee Variable Value est `a 1. Pour ˆetre conforme `a la RFC, tout paquet UDP circulant sur le r´eseau, ayant une taille sup´erieure `a 1300 bytes fera l’objet d’une alerte nomm´ee sip compliance :extra data in udp alert.

Fig. 3.13.: Description de la r`egle “Alert On Big UDP Packet” En utilisant le g´en´erateur de message SIP (SIPNess) nous tenterons de d´eclencher cette alerte en envoyant un paquet UDP sup´erieur `a 1300 bytes.

3. Tests

49

Fig. 3.14.: Envoi d’un paquet UDP de taille sup´erieure `a la taille maximale Le champ d’en-tˆete Content-length, indiquant la taille du corps du message envoy´e au receveur (bob), est `a 1999 bytes. Ce qui indique qu’une alerte doit ˆetre d´etect´ee.

Fig. 3.15.: D´etection de l’alerte sip compliance :extra data in udp alert Comportement de la sonde En se connectant au Management Dashboard nous d´ecelons sur le tableau des alertes la pr´esence de l’alerte de type sip compliance :extra data in udp alert ce qui montre la validit´e de la r´egle ALERT ON BIG UDP PACKET. 2. Comme mise en ´evidence la description de l’alerte ALERT ON LOWERCASE METHODS, indique que toute m´ethode SIP ´ecrite en minuscule engendrera une alerte. En effet cette r`egle est activ´ee car la Variable Value est `a 1.

3. Tests

50

Fig. 3.16.: Description de la r`egle “Alert On Lowercase Methods” Une attaque de ce type sera provoqu´ee 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´ethode SIP envoy´ee est ´ecrite en minuscule.

3. Tests

51

Fig. 3.18.: R´eception d’une requˆete INVITE ´ecrit en miniscule Comportement de la sonde D´es l’envoie du paquet, la sonde d´etecte l’attaque en envoyant une alerte Lowercase SIP Methods. En double cliquant sur cette alerte depuis l’interface du Management DashBoard plus de d´etails sur l’attaque sont visuels : ID de l’alerte, adresses IP source et destination, date de d´etection de l’alerte, le type de l’alerte, le nom de l’alerte...

Fig. 3.19.: Alerte visible depuis le Dashboard et d´etail de cette alerte 3. La r´egle MAX UDP PACKET SIZE est presque identique `a ALERT ON BIG UDP PACKET `a la seule diff´erence que la valeur de la variable de configuration est ´editable et repr´esente la taille maximale d’un paquet, qui par d´efaut est fix´ee `a 1300 bytes. Pour tester cette r`egle nous fixons la Variable Value `a 8 bytes qui repr´esente la taille maximale des paquets autoris´es `a circuler sur le r´eseau.

3. Tests

52

Fig. 3.20.: Description de la r`egle “Max UDP Packet Size” Provoquons une attaque en envoyant sur le r´eseau grˆace `a SIPNess un paquet de taille sup´erieure `a 8 bytes.

Fig. 3.21.: Envoie d’un paquet de 296 bytes au proxy SIP Comportement de la sonde Apr´es avoir mis en place cette attaque, la sonde ´emet une alerte de niveau moyen appel´ee sip compliance :udp size alert.

Fig. 3.22.: Alertes d´etect´ees par la sonde

3. Tests

53

En double cliquant sur l’alerte depuis l’interface du Management Dashboard nous obtenons la fenˆetre contenant le paquet g´en´erant cette alerte. Le bouton Show Raw Packets de la fenˆetre obtenue permet d’observer les param`etres de l’alerte (adresses source et destination, ports source et destination, le package et backends qui contient la r`egle...).

Fig. 3.23.: D´etails de l’alerte sip compliance : udp size alert 4. Une autre r´egle METOHDS d´efinie une liste de m´ethodes SIP autoris´ees. Par d´efaut cette liste contient les m´ethodes SIP suivantes :“REGISTER”,“INVITE”,”ACK”,”CANCEL”,”BYE”, “OPTIONS”, “SIP/2.0”, “PRACK”, “SUBSCRIBE”, “NOTIFY”.

Fig. 3.24.: Description de la r`egle “Methods” Ainsi en effectuant un appel o` u bob demande `a initier une communication avec alice, la sonde d´etecte une alerte `a la suppression de la m´ethode INVITE dans la liste des variables de configuration. L’alerte ´emise 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 ´egalement un autre backend appel´e sip/uservars o` u sont d´efinies d’autres r`egles. 1. La r´egle BAD METHODS consiste `a rejeter des paquets contenant certaines m´ethodes sip.

3. Tests

55

Fig. 3.27.: Description de la r`egle “Bad Methods” Ainsi tout paquet contenant une m´ethode d´efinie 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 “mauvaises” m´ethodes SIP contient la m´ethode REGISTER. La dur´ee de validit´e des URI est de 3600 sec, apr`es chaque heure nos contacts bob et alice envoie des requˆetes REGISTER vers le serveur de redirection.

Fig. 3.28.: Alerte de type sip uservars : bad methods alert La figure 3.29 montre le paquet `a l’origine de cette alerte.

Fig. 3.29.: Paquet contenant la m´ethode 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´ema d’une URI a une forme similaire `a l’URL mailto, permettant la sp´ecification d’en-tˆetes de champs de demande SIP. Par exemple l’URI de l’utilisateur bob est “sip :[email protected]”. La r`egle BAD REQUEST URI constiste `a d´etecter une alerte pour toute requˆete contenant un URI d´efini dans la liste des variable de configuration. Pour tester cette r`egle nous placerons dans la Variable Value l’URI de bob. Ainsi tout appel effectu´e par bob ou qui lui est adress´e provoquera une alerte .

Fig. 3.30.: Description de la r`egle “Bad Methods” En initiant une communication avec bob une alerte de type sip uservars :bad uri alert est ´emise.

Fig. 3.31.: Alerte de type “sip uservars :bad uri alert” L’origine de cette alerte est due au fait que la rˆequete contiennent l’URI de bob.

Fig. 3.32.: Paquet `a l’origine de l’alerte sip uservars :bad uri alert

3. Tests

57

Face `a toutes ces attaques SIP, l’IPS-1 Sensor est capable de d´etecter toutes attaques ne respectant pas aux r`egles d´efinies sur l’IPS-1.

4 Synth`ese et conclusion

La pr´esente section consiste `a effectuer une analyse g´en´erale du comportement de l’IPS-1 Check Point. Les NIDS ´etant les IDS plus int´eressants et les plus utiles du fait de l’omnipr´esence des r´eseaux dans notre vie quotidienne, l’IPS-1 Check Point en est un et a pour principal objectif d’aider les entreprises `a combattre les intrusions. L’une des forces de l’IPS-1 Check Point r´eside au niveau de l’affichage des alertes qui s’ex´ecute en temp r´eel ce qui permettra de diminuer les dommages caus´es par l’attaque. Le fait de pouvoir regrouper les alertes en fonction de leur gravit´e est un avantage car donne la possibilit´e `a l’administrateur du syst`eme de prendre les mesures appropri´ees. Grˆace `a l’interface fournie par l’IPS-1 Management Dashboard l’utilisateur acc´ede rapidement aux informations int´eressantes et ce qui lui permettra de configurer facilement le syst`eme afin que celui-ci r´eponde `a ses besoins. Suite aux diff´erentes attaques VoIP mise en place cf chapitre 3, la sonde a d´etect´ee toutes les attaques SIP dont les filtres ont ´et´e d´efinis (Packages/Backends). Durant le travail de diplˆome sera d´efinies de nouvelles r´egles en N-code face aux attaques sip les plus courants que nous d´efinirons. Une session SIP entre 2 t´el´ephones est ´etablie de la fa¸con suivante : 1. Le t´el´ephone appelant envoie une invitation (Alice envoie une invitation `a bob) 2. Le t´el´ephone appel´e renvoie une r´eponse informative 100 – Trying 3. Lorsque l’appel´e commence `a sonner une r´eponse 180 – Riging est renvoy´ee. 4. Lorsque l’appelant d´ecroche le t´el´ephone, le t´el´ephone appel´e envoie une r´eponse 200 – OK 5. L’appelant r´epond par un acknowledgement ACK 6. Maintenant, la communication est transmise sous forme de donn´ees via RTP 7. Lorsque l’appelant raccroche, une requˆete BYE est envoy´ee au t´el´ephone appelant. 8. Le t´el´ephone appelant r´epond par un 200 – OK. Toute session SIP est identifi´ee par un identificateur de session appel´e Call-ID. Ce dernier permet de d´efinir comment les sessions SIP sont loggu´es. Les logs g´en´er´es par l’IPS-1sont acc´ecibles depuis le menu Tool ⇒ Recorder Events. Depuis cette fenˆetre 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´epertori´es par session.

4. Synth`ese et conclusion

59

Fig. 4.1.: logs SIP

5 Cahier des charges

5.1. Pr´ esentation 5.1.1. Contexte Ce projet s’inscrit dans le cadre du travail de diplˆome de Mme Marie Th´er`ese Gomes, ´etudiant en troisi`eme et derni`ere ann´ee de la Haute Ecole d’Ingenerie et de Gestion du canton de vaud (Heig-vd). Le projet est scind´e en deux ´etapes : Le pr´ e-projet de diplˆ ome du 15 mars au 22 juin 2007, `a raison d’une demie-journ´ee par semaine. Durant cette p´eriode il est question d’installer, de configurer et de tester le comportement de l’outil de travail (IPS-1 Check Point). A l’issu de cette p´eriode un rapport doit ˆetre rendu. Travail de diplˆ ome A partir du 18 septembre l’emploi du temps de l’´etudiant serait exclusivement consacr´e `a la r´ealisation du travail de diplˆome. Le r´esultat final sera pr´esent´e dans un rapport ´ecrit `a remettre le 7 d´ecembre 2007, au cours des trois premi`eres semaines de janvier 2008 le projet devra ˆetre soutenu oralement devant le jury.

5.1.2. Description g´ en´ erale Le travail de diplˆome dont il est question dans ce document consiste `a effectuer un banc de test pour un Syst`eme de D´etection d’Intrusion (IDS) bien pr´ecis, couvrant le trafic VoIP. Ce projet traite un des domaines couvert par le projet de recherche Vadese qui a pour objectif d’´etudier les aspects de s´ecurit´e de la VoIP et de proposer des solutions de s´ecurisation. L’IDS `a ´evaluer et `a am´eliorer est fourni par la soci´et´e Check Point.

5.2. Travaux ` a r´ ealiser 5.2.1. Tutorial du langage N-code Une des premi`eres ´etapes du travail de diplˆome est de comprendre le langage N-Code et de r´ealiser un tutorial. L’IPS-1 Check Point regroupe les paquetages (par th`eme ou protocole).

5. Cahier des charges

61

Ceux-ci sont cod´es en N-code et contiennent des r`egles de telle sorte `a reconnaˆıtre les paquets non valides circulant sur le r´eseau.

5.2.2. Ecriture des r` egles Apr`es ˆetre familiaris´e avec le langage N-code, il est question `a pr´esent d’´ecrire des r`egles pour am´eliorer notre outil et renforcer la s´ecurit´e de notre r´eseau. Une derni`ere ´etape de tests (attaques VoIP) seront mis en place pour ´evaluer la sonde Check Point Si le temps nous le permet des tests seront effectu´es sur d’autres IDS.

5.3. Organisation du travail 5.3.1. Journal de travail L’´etudiant facilitera son travail en tenant un journal de travail. Celui-ci pourra contenir une trace de toutes les actions entreprises pour le projet. Dat´ees et bri`evement d´ecrites, les actions pourront ainsi ˆetre rapidement retrouv´ees, modifi´ees ou incrimin´ees en cas de probl`eme. Sites internet pertinents et tout autre bibliographie pourront avantageusement y ˆetre conserv´es.

5.3.2. Outil de travail Durant le travail de diplˆome sera utilis´e un d´epˆot SVN o` u sera stocker progressivement le travail effectu´e. Ainsi mon assistante et professeur encadrants auront la possibilit´e de suivre r´eguli`erement 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´ecurit´e r´eseau 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´etection d’Intrusion

Les syst`emes d’information sont aujourd’hui de plus en plus ouverts sur Internet. Cette ouverture, a priori b´en´efique, pose quelques probl`emes au niveau de la s´ecurit´e : il en d´ecoule un nombre croissant d’attaques. La mise en place d’une politique de s´ecurit´e autour de ces syst`emes est donc primordiale. En plus des pare-feux et des syst`emes d’authentification de plus en plus s´ecuris´es, il est n´ecessaire, pour compl´eter cette politique de s´ecurit´e, d’ajouter des outils de surveillance pour auditer le syst`eme d’information et d´etecter d’´eventuelles intrusions. Cet ´equipement de d´etection plus commun´ement appel´e IDS (System Intrusion Detection) est un m´ecanisme qui examine le trafic sur le r´eseau pour y rechercher les activit´es douteuses ou tout risque d’intrusion. La d´etection d’intruision consiste simplement `a essayer de d´eceler les signes d’un intrus sur le r´eseau avant qu’il ne provoque des d´egats, une coupure de service ou une perte de donn´ees. 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´ees recueillie par l’IDS. Il y a deux m´ethodes d’analyse : une bas´ee sur les signatures d’attaques, et l’autre sur la d´etection d’anomalies. – Journalisation : Enregistrement des ´ev`enements dans un fichier (un fichier log). Exemples d’´ev`enements : arriv´ee d’un paquet, tentative de connexion. – gestion : Les IDS doivent ˆetres g´er´es de mani`ere continue. Ils doivent ˆetres configur´es, v´erifi´es.. On peut assimiler un IDS `a une cam´era de s´ecurit´e. – action : Alerter le personnel quand une situation dangereuse est d´etect´ee.

A.1. Types d’IDS Il existe deux grandes familles distinctes d’IDS : Les NIDS (Network Based Intrusion Detection System), ils assurent la s´ecurit´e au niveau du r´eseau. Les HIDS (Host Based Intrusion Detection System), ils assurent la s´ecurit´e au niveau des hˆotes.

A. Systeme de D´etection d’Intrusion

64

A.1.1. Network IDS Un NIDS n´ecessite un mat´eriel d´edi´e, qui permettra d’analyser les flux transitant sur un ou plusieurs lien r´eseau et de d´etecter les intrusions en temps r´eel. Il fonctionne en mode furtif c’est `a dire qu’il ´ecoute tout le trafic r´eseau, puis l’analyse et g´en`ere des alertes lorsque des paquets suspects ont ´et´e d´etect´es. L’emplacement des NIDS est crucial car suivant son positionnement, il peut ne pas voir le trafic r´eseau. Par exemple si seuls les NIDS situ´ess entre le firewall et Internet sont utilis´es, le trafic du r´eseau interne reste invisible. Une autre faiblesse des NIDS `a prendre en consid´eration est lorsque les paquets sont crypt´es, Il est impossible pour l’IDS de d´ecrypter 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´eseau mais plutˆot l’activit´e se passsant sur la machine en question. Le HIDS analyse les paquets entrants et sortants de l’hˆote dans le but de d´etecter des signes d’intrusions et de g´en´erer des alertes qui seront stock´ees dans des fichiers de log. Les HIDS poss`edent quelques faiblesses, ils peuvent ˆetre victimes d’attaques, s’ils sont situ´es sur l’ordinateur compromis de l’attaquant, leurs fichiers peuvent ˆetre effac´es ou modifi´es. Un autre point faible est sa vision restreinte de ce qui se passe sur le r´eseau.

A.1.3. Les IDS “Hybrides” Ils permettent de r´eunir les informations de diverses sondes plac´ees sur le r´eseau. Leur appellation “hybride” provient du fait qu’ils sont capables de r´eunir aussi bien des informations provenant d’un syst`eme 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´erents syst`emes. Utilisant 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´ee des attaques.

A.2. Les m´ ethodes de d´ etection Les syst`emes de d´etection d’intrusions se divisent en deux cat´egories : – bas´es sur les signatures. – bas´es sur les anomalies. Signatures : Les intrus poss`edent des signatures, tout comme les virus, qui peuvent ˆetres d´etect´es par certains logiciels. La proc´edure consiste `a trouver les paquets de donn´ees contenant des signatures connues comme anormales et dangereuses. Bas´e sur un ensemble de signatures et de r`egles, le syst`eme de d´etection peut trouver et loguer les activit´es suspectes et produire des alertes. Cependant les IDS n´ecessitent des mises `a jours de leur base de signatures pour pouvoir d´etecter les nouveaux types d’attaques.

A. Systeme de D´etection d’Intrusion

65

Anomalies : Les IDS bas´es sur la d´etection d’anomalies consiste `a comparer les sch´emas d’´ev`enements en cours pris dans leur ensemble aux sch´emas d’´ev`enements habituels pris dans leur ensemble. Cela permet d’analyser beaucoup de choses comme par exemple des utilisateurs acc´edant `a des fichiers syst`emes, des modifications de fichiers inhabituelles, de nombreux ´echecs de connexion.. Cette m´ethode 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´emas d’activit´es varient tr`es largement.

A.3. O` u doit on placer l’IDS dans une topologie r´ eseau Le placement des IDS d´epend de la topologie r´eseau. Suivant celle ci, on peut les placer `a un ou plusieurs endroits. Cela d´epend ´egalement de quels types d’intrusion on souhaite surveiller et d´etecter : interne, externe , ou bien les deux. Si l’entreprise veut d´etecter les intrusions externes uniquement, le meilleur endroit est juste apr`es le routeur reli´e `a internet ou firewall. Si elle veut aussi d´etecter les menaces internes, on peut placer un IDS dans chaque segment du r´eseau. G´en´eralement, l’entreprise se limite aux secteurs sensibles du r´eseau. Plus il y a de syst`emes de d´etection d’intrusion, plus il y a de travail et plus il y a de coˆ uts pour l’entretien.

Location 1 : A l’entr´ee du firewall externe, reli´e `a 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 `a surveiller. location 3 : Sur chaque segment r´eseau. Il se concentre sur les attaques ayant pass´e le firewall et s’´etant introduites sur ce segment r´eseau. location 4 : Sur un sous r´eseau , comme pour la location 3, vise `a proteger un sous r´eseau particulier. Une autre famille d’outils pour la s´ecurit´e r´eseau existe : les syst`emes de pr´evention des intrusions (IPS Intrusion Prevention System)

A. Systeme de D´etection d’Intrusion

66

A.4. Qu’est ce qu’un syst` eme de pr´ evention d’intrusion ? A.4.1. Pr´ esentation de l’IPS Un syst`eme de pr´evention d’intrusion est un dispositif aussi bien mat´eriel que logiciel, qui permet de d´etecter des attaques, connues et inconnues, et de les empˆecher d’ˆetre r´eussies. L’IPS fait partie du r´eseau ; il est plac´e 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 dangereux. Il r´ealise un ensemble d’analyses sur chaque paquet et sur les motifs du r´eseau, en visualisant chaque transfert dans le contexte qui pr´ec`ede et suit. Un IPS est compos´e principalement de 4 modules : – – – –

Normalisation du traffic (Traffic normalizer) Scanner de service(Service scanner) traffic shaper Moteur de d´etection(Detection engine)

Le Traffic normalizer surveille le trafic, il analyse les diff´erents paquets et ex´ecute certaines mesures contre les attaques, comme le blocage d’IP. Le trafic une fois analys´e est pass´e au Detection engine et au Service scanner. Celui ci ´etabli une table de r´ef´erence qui classe les informations afin d’aider le Traffic shaper `a g´erer le flux de ces informations. Le Detection engine compare les sch´emas d’´ev`enements en cours avec ceux qui sont dans la table de r´ef´erence.

A.4.2. Les types d’IPS Il existe deux types d’IPS : – Les NIPS (Network Intrusion Prevention System), un logiciel ou un mat´eriel d´edi´e qui est connect´e directement `a un segment du r´eseau et qui prot`ege les syst`emes de ce segment. – Les HIPS (Host Intrusion Prevention System), un programme syst`eme install´e directement sur l’ordinateur `a surveiller. Network IPS Le Network IPS (NIPS) combine les caract´eristiques d’un IDS standard avec celles d’un firewall. On le qualifie parfois de firewall `a inspection en profondeur (deep inspection). Comme avec un firewall, le NIPS a au minimum deux interfaces r´eseau, une interne et une externe. Les paquets arrivent par une des interfaces et sont pass´es au moteur de d´etection. L’IPS fonctionne pour le moment comme un IDS, c’est `a dire qu’il d´etermine si oui ou non le paquet est malveillant. Cependant, en plus de d´eclencher une alerte dans le cas ou il d´etecte un paquet suspect, il rejettera le paquet et marquera cette session ”suspecte”. Quand les paquets suivant de cette session arriveront `a l’IPS, ils seront jet´es. Les NIPS sont d´eploy´es en ligne avec le segment du r´eseau `a prot´eger. Du coup, toutes les donn´ees qui circulent entre le segment surveill´e et le reste du r´eseau sont forc´ees de passer par le NIPS.

A. Systeme de D´etection d’Intrusion

67

Un NIPS d´eclenche des alarmes du type “tel ou tel trafic a ´et´e d´etect´e en train d’essayer d’attaquer ce syst`eme et a ´et´e bloqu´e”. Un NIPS ne n´ecessite pas d’intervention humaine si la s´ecurit´e n’est pas primordiale pour l’entreprise. Dans le cas contraire une intervention humaine est pr´ef´erable pour surveiller les intervention automatis´ees du NIPS. Lesprincipaux avantages d’un NIPS sont : – Un seul point de contrˆole pour le trafic peut prot´eger tout les syst`emes situ´es en aval du dispositif. – Le d´eploiement est facile car un seul dispositif IPS suffit pour des dizaines de syst`emes. – Il prot`ege des autres dispositifs du r´eseau car toutes les attaques peuvent aussi ˆetre dirig´ees contre des routeurs, des firewall.. – Il prot`ege des attaques r´eseaux : DoS, SYN flood etc.. Travailler au niveau du r´eseau permet `a un NIPS de prot´eger contre ces attaques. Host IPS Le HIPS est un programme r´esidant sur un syst`eme tel que les serveurs ou les postes de travail. Le trafic qui entre et sort de ce syst`eme est inspect´e et les activit´es au niveau des applications et du syst`eme d’exploitation peuvent ˆetre surveill´ees afin d’y trouver des signes d’une attaque. Un HIPS peut d´etecter les attaques visant la machine, et arrˆeter le processus malveillant avant qu’il ne s’ex´ecute. Le HIPS ne n´ecessite plus de service de journalisation des ´ev`enements (log). Quand une attaque est d´etect´ee, le logiciel bloque l’attaque soit au niveau de l’interface r´eseau, soit en envoyant des commandes `a l’application ou au syst`eme d’exploitation, leur disant d’arrˆeter l’action lanc´ee par l’attaque. Un HIPS poss`ede une liste pr´ed´efinie de r`egles, d´efinie par le fabriquant et livr´ee avec le produit. Ces r`egles savent comment un syst`eme d’exploitation ou une application doit se “comporter normalement”. Si l’application entame une action suspecte, une des r`egles est activ´ee et le processus est tu´e avant de nuire au syst`eme. D’autres syst`emes HIPS emploient la m´ethode ”surveillance”. Un agent HIPS tourne sur l’ordinateur et se concentre sur les ´ev´enement d’un syst`eme d’exploitation en observant tous les appels syst`eme, les entr´ees de la base de registre. Les principaux avantages d’un Host IPS : – Prot`ege les syst`emes mobiles contre une attaque quand ils sont hors du r´eseau prot´eg´e. – Prot`ege des attaques locales, le personnel ayant un acc`es physique et voulant corrompre certains syst`emes `a l’aide de disquette ou CD... – Garantie une derni`ere d´efense contre les attaques ayant passer les autres syst`emes de s´ecurit´e. – Les attaques lanc´ees entre les syst`emes du mˆeme segment r´eseau ne peuvent ˆetre contr´ees qu’avec le HIPS. – Ind´ependant de l’architecture r´eseau

B Outils utilis´es

B.1. Script permettant d’ex´ ecuter l’attaque BYE 1

#!/bin/sh

2 3 4

interface=eth0 domain=192.168.0.219

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

echo echo read echo read echo read echo read echo read echo read echo read

"attack teardown" −n "target user (e.g.john.doe or 5000):" user −n "from user (e.g.john.doe or 5000):" attacker −n "IP address of target: " target −n "Call ID: " callid −n "From tag: " from −n "To tag: " to −n "IP address of source: " IPsource

21 22

echo

23 24 25 26 27 28

echo"Start teardown" echo "parameters ...." 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" cd /home/vadese/workspace/voipsecurity/teardown 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´es

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´ en´ erateur de message SIP Le SIPNess messenger d’ortena Network (www.ortona.com) est un outil qui fournit `a l’utilisateur une mani`ere facile de construire et d’envoyer des messages personnalis´ees SIP `a un interlocuteur distant, et en mˆeme temps de recevoir et surveiller les messages SIP entrants. La version 1.06 utilis´ee supporte les messages INVITE, CANCEL, BYE, REGISTER, RINGING, TRYING, ACK, OK, OPTION.

B. Outils utilis´es

70

Fig. B.1.: G´en´erateur de message SIPNess Messager

B.4. Tableau des Attaques SIP Le tableau ci-dessous tir´e du BP d´etaille ces risques avec la terminologie appropri´e. Il pr´ecise dans la colonne de droite l’identifiant qui sera utilis´e pour repr´esenter chaque attaque dans le document.

B. Outils utilis´es

71

C Journal de Travail

Description

Date de d´ ebut Estimation de la dur´ ee

S´eance d’information avec Mr. Ventura et Mme Kuhn Documentation sur Snort

15/03/2007

1 heure

15/03/2007

4 jours

S´eance d’information avec Mr. Ventura et Mme Kuhn Labo Asterisk : VoIP1 &VoIP2

22/03/2007

1 heure

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´eance d’information avec Mr. Ventura et Mme Kuhn Etude du Best Practice

05/04/2007

1 heure

05/04/2007

2 jours

Documentation sur les IDS

12/04/2007

2 jours

S´eance d’information avec Mr. Ventura, Mme Kuhn et la soci´et´e Check Point Documentation sur les IDS

19/04/2007 19/04/2007

1 heure 3 jours

26/04/2007

3 jours

03/05/2007 10/05/2007

1 heure 2 jours

14/05/2007

2 heures

Lecture du Guide d’installation de l’IPS-1 Check Point S´eance d’information avec Mr. Ventura et Mme Kuhn Lecture du Guide d’installation de l’IPS-1 Check Point Installation de l’IPS-1 Check Point : Server, Management Dashboard Lecture du l’Administrative

C. Journal de Travail Guide de l’IPS-1 S´eance d’information avec Mr. Ventura et Mme Kuhn Attaques sur la sonde R´edaction du rapport

73 17/05/2007 24/05/2007 31/05/2007 au 07/06/2007 `a partir du 14 juin

2 jours 1 heure