You are on page 1of 43

Pré-projet de diplôme 2007

Détection d’intrusions VoIP avec Sourcefire

et introduction à ExaProtect

Romain Wenger
TR2007

Professeur : Stefano Ventura


Expert : Sylvain Maret
Assistante : Lalaina Kuhn

Date : 29 juin 2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Table des matières

1 Synthèse................................................................................................... 5

2 Introduction ............................................................................................. 5

3 Objectifs du projet .................................................................................... 6

4 Réseau de test .......................................................................................... 7

5 OpenSER ................................................................................................... 9
5.1 Présentation .................................................................................................... 9
5.2 Logs ............................................................................................................... 9

6 Sourcefire ............................................................................................... 10
6.1 Présentation .................................................................................................. 10
6.2 Composants .................................................................................................. 10
6.2.1 Policies ................................................................................................................... 11
6.2.2 Rules ...................................................................................................................... 12
6.2.3 Preprocessors .......................................................................................................... 13
6.2.4 Portscan Detection ................................................................................................... 15
6.2.5 Variables................................................................................................................. 16
6.2.6 Alerting................................................................................................................... 17
6.2.7 Affichage des évènements ......................................................................................... 18
6.3 Tests ............................................................................................................ 18
6.3.1 Méthode.................................................................................................................. 18
6.3.2 Résultats................................................................................................................. 18
6.4 Problématique VoIP ........................................................................................ 19
6.4.1 Stateful inspection.................................................................................................... 19
6.4.2 Autres protocoles VoIP.............................................................................................. 19
6.5 Evaluation ..................................................................................................... 20

7 Bases de corrélation ............................................................................... 22


7.1 Problématique ............................................................................................... 22
7.2 Idées et orientation VoIP................................................................................. 23

8 ExaProtect .............................................................................................. 24
8.1 Présentation .................................................................................................. 24
8.2 Security Management Solution (SMS) ............................................................... 24
8.2.1 Security Management Agent (SMA) ............................................................................ 24
8.2.2 Security Management Platform (SMP) ......................................................................... 25
8.2.3 Security Management Console (SMC) ......................................................................... 25

Romain Wenger -2- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

9 Suite du travail et projet de diplôme....................................................... 27

10 Conclusion .......................................................................................... 27

11 Références.......................................................................................... 28
11.1 Sites Web ..................................................................................................... 28

12 Annexe A : Configuration de Sourcefire .............................................. 29


12.1 Nouvelle policy .............................................................................................. 29
12.2 Activation des règles ...................................................................................... 29
12.3 Détection des portscans .................................................................................. 30
12.4 Configuration des variables ............................................................................. 30

13 Annexe B : Attaque VoIP SIP/BYE et détection .................................. 31


13.1 Portscan ....................................................................................................... 31
13.2 Man-in-the-middle (MITM) .............................................................................. 32
13.2.1 Description .......................................................................................................... 32
13.2.2 Réalisation........................................................................................................... 33
13.2.3 Détection............................................................................................................. 34
13.3 Message SIP/BYE DoS .................................................................................... 35
13.3.1 Description .......................................................................................................... 35
13.3.2 Réalisation........................................................................................................... 35
13.3.3 Détection............................................................................................................. 37

14 Annexe C : Tableau des caractéristiques de Sourcefire ....................... 40

Romain Wenger -3- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Table des figures

Figure 1 : Schéma du réseau de test................................................................................ 7


Figure 2 : Plan d’adressage du réseau .............................................................................. 8
Figure 3 : Affichage de la liste des policies...................................................................... 11
Figure 4 : Edition d'une policy ....................................................................................... 11
Figure 5 : Affichage de l’état d'activation des règles pour une policy .................................. 13
Figure 6 : Schéma de fonctionnement de Sourcefire ........................................................ 14
Figure 7 : Stream4 et Stateful Inspection ....................................................................... 14
Figure 8 : Détection des portscans................................................................................. 15
Figure 9 : Liste des variables d'une policy....................................................................... 16
Figure 10 : Configuration des alertes pour une policy ....................................................... 17
Figure 11 : Evaluation de Sourcefire .............................................................................. 21
Figure 12 : Architecture adaptée à la corrélation d'alertes ................................................ 22
Figure 13 : Schéma fonctionnel d'ExaProtect................................................................... 26
Figure 14 : Création d'une policy dans Sourcefire ............................................................ 29
Figure 15 : Configuration des variables dans Sourcefire.................................................... 30
Figure 16 : Affichage des évènements par adresse de destination...................................... 32
Figure 17 : Interface graphique d'Ettercap NG................................................................. 33
Figure 18 : Capture des paquets d'un ARP Spoofing......................................................... 34
Figure 19 : Capture des paquets de l’établissement d'un appel SIP .................................... 35
Figure 20 : Interface de l'application SIPNess Messenger.................................................. 36
Figure 21 : Création d'une règle Sourcefire ..................................................................... 38
Figure 22 : Affichage des détails d'un évènement détecté par Sourcefire ............................ 39

Romain Wenger -4- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

1 Synthèse

Ce rapport présente le travail effectué lors du pré-projet de diplôme, en préparation au


prochain travail de diplôme sur la corrélation d’évènements avec ExaProtect.

Après avoir mis en place le réseau de test VoIP composé de téléphones, d’un serveur SIP
OpenSER et d’un IDS Sourcefire, les différentes fonctionnalités et composants de celui-ci
seront présentés, également dans un point de vue VoIP. Puis, quelques attaques vont être
menées afin de déterminer les capacités de détection de l’IDS. Ceci conduira à une première
évaluation du produit pour ce type d’utilisation.

Ensuite, quelques bases de corrélation seront introduites, avec un exemple sur l’analyse
comportementale. Finalement, une description de l’architecture 3-tiers d’ExaProtect terminera
se rapport.

2 Introduction

Après plusieurs années de réflexion sur le bien fondé d’un passage intégral à la VoIP, dans les
entreprises et aussi de manière générale chez les particuliers, il n’y a dès à présent plus de
doute sur l’adoption massive de cette technologie à court ou à moyen terme.

Le fait que l’on soit sur un réseau informatique apporte les grands avantages de celui-ci,
comme le faible coût de l’infrastructure (généralement déjà existante) et donc des
communications ainsi que la possibilité d’échanger voix, vidéo et données sur un unique type
de réseau physique. Cependant, on reçoit par la même occasion les inconvénients de ce
réseau, et non des moindres : on parle ici de qualité de service, jusqu’alors très bonne avec les
réseaux téléphoniques conventionnels, mais aussi de sécurité au sens général allant de
l’écoute des communications aux surcharges et coupures parfois intentionnelles de celles-ci.

Ce travail va s’intéresser aux solutions que l’on peut mettre en œuvre pour détecter différents
cas où une intrusion est susceptible d’avoir été menée à bien, ceci à partir d’un composant
réseau de type IDS1 dont nous évaluerons les capacités. Puis nous introduirons un système de
détection situé un niveau au-dessus prenant compte des informations que peuvent fournir
d’autres composants du réseau, lesquelles pourront être rassemblées pour obtenir des
résultats efficaces et fiables.

1
IDS : Intrusion Detection System, système de détection d’intrusion.

Romain Wenger -5- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

3 Objectifs du projet

L’objectif du travail de diplôme est l’analyse du fonctionnement puis la mise en place d’une
solution de sécurité de type SIEM (Security Information and Event Management) dans un
environnement VoIP. Le produit concerné sera ExaProtect, solution propriétaire connue dans le
domaine de la sécurité de réseaux.

Le pré-projet de diplôme visera d’abord à étudier le fonctionnement de ce type de système


ainsi que les méthodes de sécurisation de réseaux avec un IDS, puis d’effectuer quelques tests
pratiques avec l’IDS Sourcefire afin d’en évaluer les possibilités de détection relatives à la
VoIP.

Après la mise en place d’ExaProtect, le travail de diplôme consistera à étudier les différentes
fonctionnalités de ce produit, ce qui aboutira à un premier rapport. La grande partie du travail
consistera alors, sur la base du pré-projet, d’établir une liste des attaques ou de situations
potentiellement dangereuses et d’implémenter leur détection à partir des informations reçues
des différents composants du réseau, cela de manière claire et fiable. Quelques
démonstrations pourront être mises en place par la suite. Enfin, une évaluation du produit
dans le cadre de la VoIP sera établie.

Romain Wenger -6- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

4 Réseau de test

L’environnement VoIP sur lequel seront effectuées les différentes manipulations suit une
architecture standard dont voici le schéma.

Figure 1 : Schéma du réseau de test

Autour d’un switch Cisco Catalyst, le réseau est séparé en deux VLANs : un pour le contrôle
(ports 1 à 16 du switch) et l’autre pour la voix (ports 17 à 32).

L’IPBX fonctionnant avec OpenSER (version 1.1.0) est composé de trois machines séparées
offrant les services de localisation, registrar et proxy SIP. Chaque machine dispose de deux
adresses, une par type de réseau.

Deux téléphones IP Cisco 7960 (firmware version 8.2) sont utilisés pour générer les appels, le
PC de l’attaquant étant branché sur le même VLAN.

Romain Wenger -7- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Enfin, l’IDS Sourcefire est connecté au port de monitoring du switch, lui permettant de voir
passer tout le trafic pour effectuer les différentes détections. Il est aussi connecté au VLAN de
contrôle pour son administration.

Le tableau suivant détail l’adressage utilisé.

VLAN VoIP VLAN Contrôle


Elément
192.168.0.0/24 10.192.72.0/23
IPBX – Proxy SIP (PC219 – OpenSER) 192.168.0.219 10.192.73.85
IPBX – Registrar (PC220 – OpenSER) 192.168.0.220 10.192.73.86
IPBX – Service de localisation (PC221 – MySQL) 192.168.0.221 10.192.73.87
Cisco 7960 SIP Hardphone 1 (Bob) 192.168.0.10 -
Cisco 7960 SIP Hardphone 2 (Alice) 192.168.0.11 -
PC attaquant 192.168.0.20 -
Sourcefire IS 1000 - 10.192.73.82
Figure 2 : Plan d’adressage du réseau

Pour le travail de diplôme, le réseau sera enrichi de l’appliance ExaProtect ainsi que d’autres
éléments tels qu’un accès à Internet (et donc d’une DMZ), de softphones permettant de
comparer leur comportement avec celui des téléphones Cisco et idéalement d’une Gateway
PSTN.

Romain Wenger -8- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

5 OpenSER

5.1 Présentation

OpenSER est un serveur SIP open source considéré comme très fiable et flexible. Le projet a
démarré avec une équipe de trois développeurs de SIP Express Router (SER) qui voulaient
améliorer ce dernier en apportant une plus grande ouverture aux contributions publiques.
Ainsi, dès la première année, ce sont plus de 60 contributeurs qui ont participé à l’ajout de
nouvelles fonctionnalités comme le support de TLS2 et NAPTR3.

Parmi les possibilités offertes actuellement par OpenSER, on peut citer la compatibilité avec
IPv4/IPv6, le support de UDP/TCP/TLS, ENUM4, AAA5 avec RADIUS6 et base de données, load
balancing, Call-Processing Language7 et NAT traversal.

De plus, selon le site officiel, OpenSER dispose de très bonnes performances à haute charge,
lui permettant de fonctionner sur des systèmes aux ressources limitées. Cela, tout en ayant
d’autre part la capacité de traiter plus de 5000 appels par secondes grâce au load balancing.

Ces différentes caractéristiques font que le produit est bien adapté pour les ITSP8 et les
opérateurs téléphoniques en général tout comme dans des environnements d’entreprises.

5.2 Logs

La corrélation que devra effectuer ExaProtect nécessitera d’avoir accès aux informations
générées par les composants clés du réseau dont le proxy SIP fait partie.

OpenSER est prévu pour générer des logs9 de debug et d’erreurs par le protocole syslog10. Les
messages sont produits uniquement si le niveau d’importance (log level allant de 4 à -3 en

2
TLS : Transport Layer Security est un protocole cryptographique permettant l’échange d’informations de manière
sécurisée, il est le successeur de SSL (Secure Sockets Layer).
3
NAPTR : Naming Authority Pointer est un nouveau type de DNS (Domain Name System) supportant les « regualar
expressions », qui permettent de décrire des chaines de caractères à partir d’une syntaxe définie.
4
ENUM : TElephone NUmber Mapping est une suite de protocoles pour l’inclusion des numéros de téléphones
conventionnels en tant que clé de recherche dans les DNS NAPTR Internet (par exemple : numéro > adresse SIP).
5
AAA : Authentication Authorization Accounting est un protocole réalisant ces 3 fonctions (authentification,
autorisation, traçabilité).
6
RADIUS : Remote Authentication Dial-In User Service est un protocole AAA dont les données d’authentification sont
stockées de manière centralisée.
7
Call-Processing Language (CPL) est un langage utilisé pour décrire et contrôler les services de téléphonie Internet.
8
ITSP : Internet Telephony Service Provider.
9
Une explication des messages est disponible sur la page http://www.voice-system.ro/docs/ser-syslog/
10
Syslog : standard pour l’envoi des messages de logs sur un réseau IP, indique aussi le service client qui récupère et
génère les messages.

Romain Wenger -9- 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

fonction de la gravité) dépasse le seuil défini. Le choix du seuil est paramétrable dans les
fichiers de configuration. Les logs se présentent par défaut ainsi :

log([level,] message)

Si le level n’est pas indiqué, le message est d’importance minimale.

La mise en place effective de ceci sera effectuée suite à l’installation d’ExaProtect.

6 Sourcefire

6.1 Présentation

Sourcefire est avant tout le nom de l’entreprise fondée en 2001 par Martin Roesch, le créateur
de Snort.

Snort est un IDS/IPS11 réseau open source, il utilise des règles de détection permettant de
combiner signatures et analyses de protocoles. Comptant plus de 3 millions de
téléchargements à ce jour, Snort est l’IDS/IPS le plus répandu dans le monde et dispose d’une
importante communauté d’utilisateurs et développeurs.

Sourcefire propose ainsi plusieurs produits commerciaux basés sur Snort, intégrant du matériel
et des services de supports. Le produit utilisé pour ce projet se nomme Sourcefire 3D Sensor
1000. Il se présente sous la forme d’une appliance12 remplissant les fonctions d’IDS ou IPS, le
tout administrable aisément via une interface Web.

Le nom Sourcefire régulièrement utilisé dans ce document se réfère bien entendu à l’appliance.

6.2 Composants

Cette partie s’intéresse aux différents composants de base à connaître pour la mise en route
d’une stratégie de sécurité avec Sourcefire, ainsi que les possibilités offertes par celui-ci en
rapport avec la VoIP.

11
IPS : Intrusion Prevention System, système de prévention d’intrusions.
12
Appliance : en informatique, élément matériel effectuant une fonction spécifique et dont la configuration est plus ou
moins restreinte.

Romain Wenger - 10 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

6.2.1 Policies

Chaque stratégie de sécurité avec SourceFire passe d’abord par la création d’une policy. Celle-
ci se base sur un detection engine13 et peut être en mode IDS ou IPS.

Figure 3 : Affichage de la liste des policies

La policy contient les différents composants de sécurité tels que les règles de détection, les
préprocesseurs, la détection de portscans14, les modes d’alerte, les variables et quelques
composants spécifiques à des protocoles d’application (HTTP, FTP, SMTP…) comme le montre
la figure suivante.

Figure 4 : Edition d'une policy

13
Detection engine : analyseur du réseau intégré à SourceFire et incluant l’interface réseau.
14
Portscan : envoi de multiples messages pour trouver les ports ouverts sur la cible.

Romain Wenger - 11 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

6.2.2 Rules

Les règles sont l’un des principaux éléments de filtrage, en effet chaque règle contient la
description de différents paramètres d’un paquet IP permettant une détection de celui-ci en
cas de correspondance.

La configuration par défaut comporte un grand nombre de règles préinstallées et activées.


Celles-ci sont classées par types d’attaques ou par protocoles.

Il n’y a cependant que peu de règles directement en rapport avec la VoIP. Mis appart la
détection possible de connexions Skype, on trouve deux règles concernant des vulnérabilités
des téléphones Cisco 7900 series :

• 1:1814 WEB-MISC CISCO VoIP DOS ATTEMPT


• 1:3467 WEB-MISC CISCO VoIP Portinformation access

La première, comme son nom l’indique, concerne un risque de deni de service (ici un
redémarrage du téléphone suite à une mauvaise requête http) avec les versions 3.0 à 3.2 du
firmware. Les téléphones utilisés étant en version 8.2 cette règle n’est donc pas utile dans
notre cas.

La seconde protège le téléphone contre un script ayant pour effet de révéler le contenu de sa
mémoire. Il n’y a pas plus d’informations concernant les systèmes vulnérables, cette règle
pourra donc être activée mais reste relativement peu pertinentes pour ce projet.

Aucune règle directement liée à la détection d’attaques ou le suivi des messages SIP n’existe.

Romain Wenger - 12 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Figure 5 : Affichage de l’état d'activation des règles pour une policy

A noter que la création de nouvelles règles est relativement aisée et entièrement graphique
comme présenté dans l’annexe B. Les règles ajoutées apparaissent sous la catégorie « Local ».

6.2.3 Preprocessors

Sourcefire dispose de préprocesseurs dont l’utilité est d’effectuer un prétraitement rapide des
paquets tel que le réassemblage de ceux-ci suite à la fragmentation, le décodage des
protocoles grâce à une analyse stateful15 et d’autres détections difficilement implémentables
par des règles comme les portscans par exemple. Les préprocesseurs permettent à l’IDS de
conserver de bonnes performances pour le traitement des paquets.

15
Stateful : suivi de l’état d’une connexion.

Romain Wenger - 13 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

La figure suivante montre le principe de fonctionnement de Sourcefire et l’emplacement des


préprocesseurs dans les étapes de détection.

Figure 6 : Schéma de fonctionnement de Sourcefire

L’un des principaux préprocesseurs pour Snort se nomme Stream4, il permet une analyse
stateful des connexions TCP. Il est aussi disponible dans Sourcefire, où il est possible de
configurer certaines options comme le montre la figure suivante.

Figure 7 : Stream4 et Stateful Inspection

Ce qui nous intéresse ici est avant tout le protocole SIP qui lui est basé sur UDP. Cependant,
les options disponibles dans l’interface ne permettent pas d’activer une inspection stateful sur
des flux UDP. Le User Guide de Sourcefire confirme que ce n’est valable que pour des session
TCP.

Romain Wenger - 14 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

6.2.4 Portscan Detection

Sourcefire dispose d’une page pour la configuration de la détection des portscans. C’est une
fonctionnalité intéressante sachant que beaucoup d’attaques commencent par ce type
d’opération. Différents paramètres sont configurables comme le choix des protocoles à
surveiller, le type de scan (en fonction du nombre de « scanneurs », de scannés et du nombre
de ports), le taux de sensibilité ainsi que les adresses IP à contrôler.

A noter que le choix de la sensibilité modifie la méthode de détection :


• En mode Low, la surveillance se base uniquement sur les réponses négatives des hosts,
• En mode Medium, les alertes seront basées sur le nombre de connexions à un host,
• En mode High, c’est une plus grande fenêtre temporelle qui est utilisées permettant de
détecter tout type de scan.

Figure 8 : Détection des portscans

Romain Wenger - 15 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

6.2.5 Variables

L’utilisation de variables permet l’identification précise de parties du réseau. Il est possible


d’affecter un sous-réseau complet, une liste d’adresses IP ou des ports spécifiques.

Ainsi, dans les différentes pages de configuration ce sont ces variables qui seront utilisées
plutôt que des éléments statiques. On trouve par exemple dans les règles à plusieurs reprises
des variables telles que $EXTERNAL_NET ou $HOME_NET définissant explicitement les réseaux
concernés.

Les variable peuvent être définies à deux endroits différents : dans la configuration de la policy
ou directement au niveau du detection engine (Opérations > Configuration > Detection
Engines). Sauf cas précis, il est généralement préférable de définir les variables au niveau de
la policy afin de conserver la flexibilité nécessaire lorsque plusieurs policies sont actives.

Figure 9 : Liste des variables d'une policy

Romain Wenger - 16 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

6.2.6 Alerting

Le menu « Alerting » permet de configurer plusieurs méthodes pour envoyer des alertes sur le
réseau lorsqu’un évènement est détecté.

Figure 10 : Configuration des alertes pour une policy

Il y a tout d’abord la possibilité d’informer un serveur syslog, simplement en indiquant son


adresse IP.

La seconde méthode consiste à passer par SNMP. Les versions 2 et 3 du protocole sont
proposées, sachant que SNMPv3 offre en plus une authentification sécurisée par mot de passe.

Enfin, il est également possible d’envoyer les alertes par email.

Romain Wenger - 17 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

6.2.7 Affichage des évènements

L’affichage des évènements est l’un des points forts de Sourcefire. Le menu « Analysis &
Reporting » propose plusieurs types d’affichages, comme des pages « summary » permettant
d’afficher les statistiques générales des évènements de manière textuelle et graphique, ou un
affichage restreint à un intervalle de temps donné. Il est aussi possible de générer
automatiquement des rapports personnalisés avec exportations aux formats PDF ou HTML.
L’annexe B présente plusieurs affichages d’évènements.

6.3 Tests

6.3.1 Méthode

Les tests ont été effectués dans une situation d’intrusion d’une communication VoIP et sont
donc orientés sur ce domaine. Le but étant d’avoir une première idée des capacités de
Sourcefire pour la détection d’attaques de ce type.

Il existe un certain nombre d’attaques répertoriées16, plus ou moins aisées à réaliser. L’une de
celles-ci est présentée dans l’annexe B : « Attaque VoIP SIP/BYE et détection » de manière
détaillée. C’est une attaque de type DoS17 relativement facile à réaliser mais qui peut causer
de sérieux soucis si elle est appliquée en situation réelle.

La configuration de l’IDS utilisée lors des tests est décrite dans l’annexe A : « Configuration de
Sourcefire ».

6.3.2 Résultats

Au terme de ces tests, bien que les possibilités de configuration initiales de Sourcefire ne
permettent pas de détecter ce type d’attaque SIP, comme nous l’avons vu, il est relativement
facile de mettre en place de nouvelles règles à mêmes de lever des évènements lorsque cela
est nécessaire.

Cependant, un point surprenant est l’impossibilité de détecter des attaques de la couche18 2


comme un ARP Spoofing. Snort dispose pourtant d’une solution qui consiste en l’activation du
préprocesseur « ARPspoof19 », encore au stade expérimental.

16
Le document « Best Practices – Sécurité VoIP-SIP » édité dans le cadre du projet VaDeSe (http://www.vadese.org)
décrit un nombre important d’attaques connues.
17
DoS : Denial of Service (déni de service) est un terme générique pour indiquer le fait de rendre une application
incapable de répondre aux requêtes des utilisateurs.
18
Couche « liaison de données » du modèle OSI.
19
Des informations sur les préprocesseurs de Snort dont ARPspoof sont disponibles sur la page
http://www.samspublishing.com/articles/article.asp?p=101148&seqNum=2&rl=1

Romain Wenger - 18 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Malheureusement, pour une raison semblable au problème rencontré plus bas dans la partie
« Stateful inspection », Sourcefire ne permet pas l’ajout de préprocesseurs. En outre, les
préprocesseurs installés n’ont pas d’option permettant d’effectuer ce type de détection.

6.4 Problématique VoIP

Cette partie s’intéresse à d’autres points concernant la VoIP et Sourcefire.

6.4.1 Stateful inspection

Par défaut, Sourcefire (par l’intermédiaire de Snort) n’est pas « stateful ». Aucune analyse
orientée connexion n’est faite, ce qui est souvent nécessaire. En effet, de la même manière
que pour un firewall, l’IDS ne lèvera pas d’alerte pour tout paquet qui peut être légitime
lorsqu’il est à l’intérieur d’une connexion TCP mais qui doit être détecté lorsqu’il est unique, car
dans ce cas il aura de grandes chances d’être potentiellement dangereux.

Comme vu plus haut, une analyse stateful des connexions TCP peut être activée par
l’intermédiaire du préprocesseur Stream4. Cependant, dans notre cas nous utilisons SIP qui
est basé sur UDP. De plus, ce dernier n’étant pas orienté connexion, il serait d’autant plus
nécessaire de pouvoir suivre un appel SIP.

Selon la documentation de Stream4 sur le site de Snort, il existe pourtant la possibilité


d’activer l’option « enable_udp_sessions » qui comme son nom l’indique suit l’état de sessions
UDP. Mais cela ne semble possible qu’avec une version « non-intégrée » de Snort. Le manuel
de Sourcefire ne spécifiant rien concernant l’ajout d’une telle option.

6.4.2 Autres protocoles VoIP

Bien que le projet se focalise principalement sur le protocole SIP, il faut savoir que d’autres
protocoles20 sont souvent utilisés, principalement en entreprise.

SCCP (Skinny Client Control Protocol)

Skinny est un protocol propriétaire appartenant à Cisco, utilisé entre un client et un serveur
Cisco CallManager. Les téléphones de la série 7900 de Cisco implémentent ce protocole qui a
la particularité d’être bien plus léger et moins gourmand en bande passante que H.323. Skinny
est basé sur TCP (port 2000) pour la communication avec le CallManager, lorsque l’appel est
établi avec le destinataire, la transmission audio utilise UDP.

20
Une description des principaux protocoles VoIP est disponible sur cette page :
http://www.protocols.com/pbook/VoIPFamily.htm

Romain Wenger - 19 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

L’utilisation de TCP permet donc une analyse stateful avec Sourcefire.

H.323

H.323 est un ensemble de protocoles recommandés par l’ITU-T pour les communications
audio-visuelles par paquets IP. C’est un dérivé du protocole H.320 utilisé dans ISDN. Il permet
dès lors un grand nombre de fonctionnalités et de configurations possibles.

Pour la signalisation des appels, c’est le protocole H.225.0/RAS qui est utilisé (H.245 pour les
communications multimédia), composé des messages suivants :

• Call Signaling, établissement et contrôle d’un appel H.323. La signalisation est basée
sur les procédures d’appel ISDN (voir Q.931) et utilise TCP.
• RAS Signaling Function, utilisé pour l’enregistrement, l’admission, le statut
(Registration, Admission and Status) et les modifications de bande passante entre les
clients. Le canal RAS est basé sur UDP.

Le fonctionnement n’étant pas simple, il est difficile de prévoir si Sourcefire serait capable
d’analyser une session de ce protocole.

MGCP

Media Gateway Control Protocol est un protocole spécialisé pour la VoIP orienté client-serveur.
Il est généralement basé sur UDP port 2427 dont chaque paquet est une commande ou une
réponse. Il est souvent utilisé par le providers fournissant un service triple-play (dont la VoIP).

Comme il est basé sur UDP, le problème devrait être semblable que pour SIP concernant
l’analyse stateful.

6.5 Evaluation

Sans avoir pu réellement comparer Sourcefire avec d’autres IDS, nous pouvons tout de même
affirmer que les possibilités offertes par ce produit sont nombreuses et relativement faciles à
utiliser grâce à l’interface entièrement graphique, également pour la création des règles.

Le nombre de règles initialement installées est impressionnant (plus de 10’000 !), cela permet
de disposer de solutions pour de nombreux protocoles. Néanmoins, nous avons pu voir que la
VoIP n’est pas un point fort et que peu de solutions existent autant au niveau des règles que
des préprocesseurs.

De plus, on peut s’étonner du fait que les développeurs se soient d’abord penchés sur les
risques liés à l’utilisation des téléphones VoIP de Cisco en créant des règles détectant des

Romain Wenger - 20 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

attaques sur des vulnérabilités des ces derniers plutôt que de prendre en compte des aspects
plus généraux tels que la sécurité de SIP.

Un autre point surprenant est l’impossibilité de voir des attaques ARP telles que les ARP
Spoofing. Nous avons pu contacter la société par email21 à ce sujet, qui a répondu clairement à
notre demande :

“Our IDSs are layer-3 and above, so adding ARP detection would be way down the road map if
it were to be implemented.”

Il n’est donc visiblement pas dans leurs projets d’ajouter cette fonctionnalité au produit.

Mis appart le problème d’ARP, Sourcefire est à même de pouvoir détecter les attaques de
couche 3 basées sur l’envoi de mauvais paquets SIP (ou autres protocoles comme RTP)
provenant d’adresses différentes que celles définies de manière statique dans la configuration
(grâce aux variables). Toutefois le problème peut devenir compliquer dans le cas où
l’attaquant prend directement la place d’un téléphone existant.

On peut également affirmer que toutes les attaques venant d’un autre réseau VLAN pourront
être détectées grâce à l’analyse de l’IP source.

Voici un tableau récapitulatif des principaux points relevés :

Avantages et inconvénients
+ Grand nombre de règles - Peu de règles pour SIP et la VoIP
préinstallées en général
+ Accessibilité et création aisée de - Pas d’analyse stateful des
nouvelles règles sessions SIP
+ Gestion intégrale par l’interface - Pas de détection des ARP
Web Spoofing
Figure 11 : Evaluation de Sourcefire

Pour plus de détail sur les caractéristiques complètes de Sourcefire, se reporter à l’annexe C.

21
Merci à Lalaina pour cette demande.

Romain Wenger - 21 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

7 Bases de corrélation

7.1 Problématique

Les reproches que l’on voit régulièrement concernant les IDS sont que ces derniers créent bien
trop d’alertes, trop souvent secondaires ou superflues, noyant ainsi les quelques évènements
importants dans la masse.

Les études22 réalisées sur ce sujet ont mené vers de nouvelles architectures de détection avec
des composants dédiés spécialement à la corrélation d’évènement (concentrateur d’alerte dans
le schéma ci-dessous). Celle-ci consiste à établir des liens entre des données venant de
plusieurs sources (sondes représentant des IDS ou autres générateurs d’évènements) pour en
ressortir les informations essentielles. Cette méthode permet de réduire le nombre d’alertes et
d’améliorer la qualité et la fiabilité des alertes.

Figure 12 : Architecture adaptée à la corrélation d'alertes23

C’est ce type d’architecture que nous retrouverons avec ExaProtect par exemple.

A noter que les sondes peuvent aussi, dans une moindre mesure, faire de la corrélation. Mais
la principale différence par rapport aux concentrateurs concerne le nombre de sources
d’informations. En effet, les sondes ne disposent que d’une unique source alors que celles des
concentrateurs sont multiples, ils assurent donc une meilleure analyse globale. Une sonde
pourra par exemple faire de l’agrégation, en groupant certaines alertes en relation directe.

22
Détection d’intrusions : corrélation d’alertes - Michael Rusinowitch – 2004 - http://www.rennes.enst-
bretagne.fr/~fcuppens/articles/tsi04.pdf
23
Illustration tirée du document ci-dessus.

Romain Wenger - 22 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

7.2 Idées et orientation VoIP

Le projet final devra être capable de détecter d’une part des attaques répertoriées mais aussi
prévenir de nouveaux types d’intrusions non basées sur des signatures connues ainsi que des
attaques de plus haut niveau comme le SPIT24 par exemple. C’est là qu’intervient l’analyse
comportementale qui permet de disposer d’un éventail bien plus large de détections possibles.

Nous pouvons également définir cela par la corrélation explicite et implicite. La première est
plus « standard », elle est basée avant tout sur des scénarios prédéfinis et généralement
connus à l’avance. C’est une suite d’évènements qui va mener à une alerte, ceux-ci pouvant
provenir bien entendu de sources différentes. Les attaques VoIP répertoriées sont souvent
détectables par cette méthode. La seconde est moins précise et consiste à établir des liens
entre des événements qui ne sont à priori pas liés par un schéma prédéfini. Pris dans leur
ensemble, ils peuvent cependant avoir une relation de type statistique, comme par exemple
une fréquence inhabituelle. Cela peut donner lieu à des attaques plus ou moins rusées et faire
intervenir des aspects mathématiques au problème.

Le suivi et la comptabilisation des appels seront des points essentiels à traiter. Par exemple,
avec le schéma classique d’un appel, nous auront un message INVITE suivit de la conversation
(visible peut-être uniquement par un autre IDS) et qui se termine par un message BYE. Les
messages de signalisation et de données étant séparés et n’empruntant pas forcément le
même chemin, il est donc possible qu’un seul IDS ne voit pas toutes les informations. Tout ceci
pourra être définit au final comme un seul évènement qui représente « un appel ».
L’agrégation correspond ici à l’une des méthodes envisageables pour y parvenir.

Ainsi, nous disposerons d’informations pertinentes sur les appels tels que leur nombre, leur
durée, la répartition dans la journée ou les principaux émetteurs et récepteurs réguliers. Ces
données devront être mémorisées dans une base de connaissances.

Il sera ensuite possible d’analyser certains comportements comme des changements soudains
de fréquence ou une brusque modification des destinataires appelés depuis un téléphone. Par
exemple, grâce à la prise en compte des attributs temporels, dix appels effectués depuis un
téléphone entre 10h et 11h n’auront rien d’anormal puisqu’ils correspondent à l’heure de la
journée la plus chargée en nombre d’appels. Cela n’aura pas la même importance s’ils sont
passés entre 2h et 3h du matin lorsque le trafic téléphonique est presque nul, où une alerte
pourrait alors être levée.

Dans cette optique, il pourra être nécessaire de faire appel à des personnes pouvant fournir
des informations générales sur les habitudes et statistiques téléphoniques des abonnés. Enfin,
suivant le niveau d’analyse, il pourrait y avoir des risques de confidentialité qu’il ne faudrait
pas négliger.

24
SPIT : SPam over Internet Telephony, les coûts d’un appel étant presque nul les communications indésirables
risquent d’exploser.

Romain Wenger - 23 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

8 ExaProtect

8.1 Présentation

ExaProtect est une entreprise française démarrée en 2001 spécialisée dans la sécurité des
réseaux informatiques. Disposant de bureaux dans 7 pays dont le siège est en France à Paris
et notamment aux Etats-Unis à Moutain View (Californie), la société est donc internationale.
Elle annonce plus de 300 clients, dont plusieurs sociétés du « Fortune 50025 », des opérateurs
de télécommunications internationaux et des organisations gouvernementales.

Son produit phare qui sera utilisé dans ce projet est une application de type SIEM (Security
Information and Event Management), qui permet une corrélation des informations et
évènements fournis par différents composants du réseau.

8.2 Security Management Solution (SMS)

Le produit, commercialisé avec une appliance, est composé d’une architecture 3-tiers sous
l’appellation ExaProtect Security Management Solution. Voici quelques points théoriques sur
ces composants suivis d’un schéma résumant le fonctionnement de l’application.

8.2.1 Security Management Agent (SMA)

Il existe une multitude de produits, de types et de fabricants divers, pouvant faire partie d’un
réseau et qui participent de manière plus ou moins active à sa sécurisation tels que les
firewalls, proxies, IDS… Ceux-ci fournissent généralement des journaux d’évènements (logs)
qui disposent souvent de leur propre syntaxe voir parfois de leurs propres protocoles. Il peut
être nécessaire de rassembler ces informations afin de disposer d’une vue globale de la
sécurité et de pouvoir lever des alertes efficaces.

L’agent SMA est une application permettant de récupérer les logs pour les convertir au format
standard IDMEF et les envoyer de manière sécurisée par SSL au SMP. Cette application peut
tourner sur plusieurs types de plateformes (Windows, Linux, Solaris...) à de multiples endroits
du réseau.

A noter que l’IDS Sourcefire n’est pas dans la liste des systèmes pris en charge, contrairement
à Snort. Ce dernier étant la base de Sourcefire, la compatibilité de devrait pas être un
problème.

25
Classement des 500 entreprises américaines qui réalisent le plus important chiffre d'affaires publié par le magazine
« Fortune ».

Romain Wenger - 24 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

8.2.2 Security Management Platform (SMP)

C’est le cœur du système, installé sur l’appliance. Les informations collectées par les agents
sont regroupées et corrélées, au besoin avec une base de connaissances, pour créer une vision
en temps réel de la sécurité du réseau. Ainsi, les évènements significatifs ne sont plus perdus
dans la masse d’informations mais enrichis et mis en évidence pour les personnes s’occupant
de la sécurité.

Le monitoring s’effectue par interface Web avec une authentification par certificat (voir SMC).
Les possibilités offertes sont intéressantes, on peut noter la présence d’un module « Forensic
Replay » permettant de définir des scénarios d’évènements à corréler afin d’améliorer la
détection en temps réel ainsi qu’une configuration des profiles de sécurité en fonction de
l’heure (jour, nuit, weekend...). Ce dernier point pourra être utile pour l’analyse
comportementale des appels VoIP.

8.2.3 Security Management Console (SMC)

C’est l’interface utilisateur qui permet d’une part d’administrer le SMP mais surtout de pouvoir
visualiser « l’état » du réseau. Ainsi, il est possible rechercher, trier et filtrer des alertes,
effectuer un suivi des agents ou générer des rapports personnalisés.

Ces éléments seront détaillés lors du travail de diplôme.

Romain Wenger - 25 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Figure 13 : Schéma fonctionnel d'ExaProtect26

26
Illustration tirée du site Internet de la société (http://www.exaprotect.com).

Romain Wenger - 26 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

9 Suite du travail et projet de diplôme

Voici enfin quelques points sur les prochaines étapes importantes qui feront suite à ce rapport
lors du travail de diplôme :

• Après l’installation du système ExaProtect, la première semaine consistera


principalement à la découverte du fonctionnement du produit.

• Il s’agira ensuite d’évaluer les possibilités offertes de manière générale par celui-ci, puis
établir des liens avec la VoIP.

• Le réseau de test sera agrandi, comprenant à priori un accès à Internet, et donc par la
même occasion un firewall, ainsi qu’une Gateway PSTN.

• Il deviendra alors nécessaire de proposer de nouvelles attaques VoIP non répertoriées


qui pourraient être qualifiées de « exotiques ». Cela pourra être fait en collaboration
avec Marie-Thérèse Gomez-Sanchez qui s’occupe plus particulièrement de la partie IDS.

Ces informations restent indicatives, la planification effective du travail de diplôme se fera sur
la base du futur cahier des charges.

10 Conclusion

Au terme de cette première « intrusion » dans le domaine des IDS et de la sécurité VoIP, on
voit que ce monde est vaste et que les méthodes de sécurisation ne sont pas évidentes, déjà
dans un petit réseau avec quelques éléments.

L’étude de l’IDS Sourcefire a montré la bonne qualité du produit, pouvant s’adapter facilement
à l’environnement dans lequel il est placé pour détecter rapidement une foule d’attaques très
diverses. Il lui manque néanmoins certaines fonctions bas-niveau et surtout une intégration
difficile dans un réseau VoIP qui ne va pas sans l’ajout de nombreuses règles.

C’est pourquoi, au regard des fonctionnalités proposées et des caractéristiques communes à


tout IDS, la détection d’attaques VoIP de type comportementales ou basées sur différents flux
(signalisation et données) ainsi que la réduction des alertes peu significatives nécessitera la
prise en compte d’informations provenant de divers endroits du réseau. Ces observations
demanderont alors une stratégie de corrélation que pourra fournir ExaProtect.

La suite de ce projet s’annonce donc captivante !

Romain Wenger - 27 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

11 Références

• Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions - David Endler, Mark
Collier - Novembre 2006

• Practical VoIP Security - Thomas Porter, Andy Zmolek, Jan Kanclirz - Mars 2006

• Best Practices - Sécurité VoIP-SIP - Alistair Doswald, Prof. Juergen Ehrensberger,


Xavier Hahn, Prof. Stefano Ventura (HEIG-VD) – Novembre 2006

• Snort 2.1 Intrusion Detection, Second Edition - Stephen Northcutt – Syngress


Publishing, Inc. – 2004

• Intrusion Sensor – User Guide - Sourcefire, Inc. – 2006

• SMA Installation Guide, version 2.7.2 - ExaProtect – Janvier 2007

• SMP Installation Guide, version 2.7.2 - ExaProtect – Janvier 2007

• SMC User Guide, version 2.7.2 - ExaProtect – Janvier 2007

11.1 Sites Web

• Snort http://www.snort.org

• Sourcefire http://www.sourcefire.com

• OpenSER http://www.openser.org

• Wikipedia http://www.wikipedia.org

Romain Wenger - 28 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

12 Annexe A : Configuration de Sourcefire

Cette annexe contient les opérations de configuration effectuées pour l’utilisation de Sourcefire
telle que décrite dans ce rapport.

12.1 Nouvelle policy

Une nouvelle policy doit être créée dans « Policy & Response > Intrusion Sensor > Detection &
Prevention ». Elle est basée sur la configuration par défaut de « Intrusion Detection Sensor -
Default Policy ». Nous la nommerons « Vadese IDS Policy ».

Figure 14 : Création d'une policy dans Sourcefire

A noter qu’une policy ne sera active qu’après avoir cliqué sur « Apply » dans la liste des policy.
L’opération prend environ une minute pour qu’elle soit en fonction. Les points suivants
s’appliquent tous à cette policy en allant dans « Edit ».

12.2 Activation des règles

Comme indiqué dans la présentation des composants de Sourcefire, la règle suivante peut être
activée :

• 1:3467 WEB-MISC CISCO VoIP Portinformation access

Elle est utile pour combler une faille de sécurité des téléphones mais reste de faible importance
pour ce projet.

Romain Wenger - 29 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

12.3 Détection des portscans

La détection des portscans (menu « Portscan Detection ») peut se limiter dans notre cas au
réseau VoIP qui est le plus sensible.

Il faut donc ajouter les adresses suivantes dans le champ « Watch IP » :

192.168.0.10,192.168.0.11,192.168.0.219,192.168.0.220,192.168.0.221

12.4 Configuration des variables

Une bonne configuration des variables est primordiale pour l’analyse correcte des évènements.
Elle doit être la plus restrictive possible pour les parties du réseau dites sensibles et le plus
large possible pour le reste. Nous configurons ici les variables au niveau de la policy.

La variable HOME_NET correspond précisément aux adresses des éléments du VLAN VoIP
(téléphones et OpenSER) et EXTERNAL_NET à tout ce qui ne fait pas partie de HOME_NET.
Deux autres variables SIP_PRIXY_IP et SIP_PROXY_PORT permettent de distinguer le serveur
proxy OpenSER, elles peuvent être ajoutées grâce à « Add Variable » en haut à droite de la
liste des variables.

Variable Valeur
HOME_NET [192.168.0.10, 192.168.0.11, 192.168.0.221,
192.168.0.220, 192.168.0.219]
EXTERNAL_NET !$HOME_NET
SIP_PROXY_IP 192.168.0.219
SIP_PROXY_PORT 5060
Figure 15 : Configuration des variables dans Sourcefire

Romain Wenger - 30 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

13 Annexe B : Attaque VoIP SIP/BYE et détection

Cette annexe présente, à la manière d’une marche à suivre, quelques attaques dont
notamment un DoS sur un appel VoIP en cours grâce à un message SIP forgé, puis une
méthode de détection avec Sourcefire.

Toutes les attaques sont effectuées à partir d’un PC connecté au VLAN VoIP avec l’adresse
192.168.0.20 comme indiqué sur le schéma du réseau.

13.1 Portscan

Cette manipulation ne fait pas partie de l’attaque à proprement dite mais permet de contrôler
le fonctionnement de l’IDS et la levée d’évènement.

L’idée est simplement d’envoyer des messages TCP/SYN sur tous les ports d’un des téléphones
en utilisant Nmap27. Si des réponses SYN/ACK viennent en retour cela indique qu’il y a un
service en écoute.

> nmap 192.168.0.10

Starting Nmap 4.20 ( http://insecure.org )


Interesting ports on 192.168.0.10:
Not shown: 1696 filtered ports
PORT STATE SERVICE
23/tcp open telnet
MAC Address: 00:06:28:D8:A7:0E (Cisco Systems)

Nmap finished: 1 IP address (1 host up) scanned in 24.828 seconds

On voit que le téléphone dispose du service telnet, ce qui est normal car il permet une
administration à distance.

Suite à cette commande, il est alors possible de visionner la détection sur l’IDS dans le menu
« Analysis & Reporting > Intrusion Sensor ». Après avoir mis à jour l’intervalle de temps pour
la visualisation, l’évènement « portscan : TCP Portscan » est levé avec l’adresse du téléphone
attaqué.

27
Nmap est un scanner de ports open source sous licence GNU GPL distribué officiellement sur le site
http://insecure.org/nmap, la version utilisée est la 4.20.

Romain Wenger - 31 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Figure 16 : Affichage des évènements par adresse de destination

On remarque donc que la détection d’un portscan TCP/SYN fonctionne, on trouve en plus des
alertes SNMP port 705, 161 et 162. En fait, un simple SYN sur l’un de ces 3 ports lève une
alerte.

Un autre élément important est à relever concernant les téléphones Cisco qui acceptent des
demandes de connexion sur le port 23 (telnet). C’est la réaction suite à cela qui est
surprenante : si la connexion n’abouti pas, c’est-à-dire qu’il n’y a pas de réponse au SYN-ACK
envoyé par le téléphone, celui-ci va envoyer infiniment des paquets SYN-ACK (environ un par
seconde) au PC qui a initié la connexion. Il est alors nécessaire de redémarrer le téléphone
pour stopper cela. Ce comportement inattendu montre un choix étonnant d’implémentation du
protocole…

13.2 Man-in-the-middle (MITM)

13.2.1 Description

Le réseau étant organisé autour d’un switch, l’écoute de paquets n’est pas directement
possible. Il est donc nécessaire, pour mener à bien certaines attaques, d’utiliser une méthode
pour remédier à ceci. Une des plus connues est l’attaque « Man-in-the-middle » qui permet
grâce à un ARP Spoofing de faire passer tout le trafic entre deux points par la machine de
l’attaquant.

Romain Wenger - 32 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

13.2.2 Réalisation

Il existe des programmes permettant de réaliser facilement cette attaque. Ettercap28 est un
bon exemple et propose de le faire à travers une interface graphique comme le montre la
capture suivante de la version Windows.

Figure 17 : Interface graphique d'Ettercap NG

Après l’ouverture du programme, il faut démarrer l’écoute du réseau en allant sur « Sniff >
Unified sniffing… » et choisir la carte réseau connectée. L’étape suivante consiste à récupérer
la liste des hosts du réseau à partir du menu « Hosts > Scan for hosts ». On affiche la liste en
allant sur « Hosts list » dans le même menu.

La sélection des « Targets » peut alors être faite : comme nous voulons voir les messages
entre un téléphone (192.168.0.10) et le proxy SIP (192.168.0.219), chacun correspondra à un
target. L’ajout se fait grâce aux boutons « Add to Target » au bas de la fenêtre.

Finalement, après avoir contrôlé les sélections dans le menu « Targets > Current Targets »,
l’attaque MITM peut être lancé par le menu « Mitm > Arp poisoning… ». Ci-dessous, une
capture montre les messages ARP envoyés par le PC attaquant.

28
Ettercap est un analyseur réseau, intercepteur de trafic offrant une fonction d’attaque MITM. Il est disponible sur
http://ettercap.sourceforge.net (version 0.7.3) en licence GNU GPL.

Romain Wenger - 33 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Figure 18 : Capture des paquets d'un ARP Spoofing

L’adresse MAC de l’attaquant est alors envoyée successivement aux deux interlocuteurs
comme étant celle correspondant à leur adresse IP respective. Cela toutes les 10 secondes
environ, afin de maintenir « l’effet » MITM. Ainsi, le switch sera trompé et redirigera tous les
paquets à destination de l’une ou l’autre de ces adresses sur le PC attaquant. Ce dernier se
chargera bien entendu de les rediriger ensuite aux véritables destinataires en plaçant la bonne
adresse MAC de destination.

Afin d’éviter tout problème par la suite, il est important de désactiver l’attaque lorsque celle-ci
n’est plus nécessaire en allant dans « Mitm > Stop mitm attack(s) ». Ettercap enverra alors
des messages ARP avec les adresses MAC correctes.

13.2.3 Détection

Cette attaque n’est pas détectée par l’IDS, ce dernier ne travaillant pas au-dessous de la
couche IP.

Romain Wenger - 34 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

13.3 Message SIP/BYE DoS

13.3.1 Description

Un déni de service par l’envoi d’un message SIP/BYE est une attaque VoIP aisément réalisable
qui a pour effet de couper un appel en cours. L’attaquant doit pour cela avoir accès aux
messages échangés par les deux interlocuteurs.

13.3.2 Réalisation

L’utilisation d’un analyseur de paquets tel que Wireshark29 est nécessaire afin de détecter
l’établissement d’un appel et ainsi récupérer ses différents paramètres.

Après un MITM appliqué entre un des téléphones (ici Bob, 192.168.0.10) et le proxy SIP
(192.168.0.219) il est possible de voir l’appel. C’est Alice qui va l’initier.

Figure 19 : Capture des paquets de l’établissement d'un appel SIP

29
Wireshark (anciennement Ethereal) est un sniffer et analyseur de protocole sous licence GNU GPL disponible sur
http://www.wireshark.org (version 0.99.5).

Romain Wenger - 35 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

C’est dès cet instant que peut être généré le message SIP/BYE. Le programme utilisé est
SIPNess Messenger30, lequel se compose d’une simple interface comportant les champs à
remplir.

Figure 20 : Interface de l'application SIPNess Messenger

Les différents champs à remplir sont les suivants :

Champ Description
Message Type Type de message SIP, ici ce sera BYE
UserName Utilisateur enregistré sur le proxy SIP à qui est destiné le
message, c’est un message pour Bob

30
SIPNess Messenger est un générateur de messages SIP, freeware distribué par Ortena Networks Ltd.
(http://www.ortena.com, version 1.06).

Romain Wenger - 36 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Domain Adresse du proxy SIP, 192.168.0.219


To Le destinataire avec le paramètre « tag », c’est une copie
du champ du message capturé
From L’émetteur avec le paramètre « tag », c’est une copie du
champ du message capturé
Via Chemin de la requête (pour éviter les boucles), ce champ
est rempli automatiquement
Call-ID L’identification de l’appel, à copier du message capturé
Cseq Numéro de séquence, celui-ci doit être incrémenté de 1
par rapport à celui du message capturé

Enfin, si tout est correct, un simple clic sur envoyer coupe instantanément l’appel.

13.3.3 Détection

Dans sa configuration de base, l’IDS ne lève pas d’alerte. Il est cependant possible de créer
une règle permettant de détecter cette attaque.

Une méthode réalisable serait de filtrer les messages SIP ne provenant pas du HOME_NET31 et
dont le destinataire est le proxy SIP (adresse VoIP). Pour plus de précision, la règle contrôle
aussi que le mot BYE se trouve dans le paquet.

Pour éditer une nouvelle règle, il faut passer par le menu « Policy & Response > Rules >
Create Rule ».

31
Variable configurée pour la policy contenant uniquement les adresses des téléphones, du proxy SIP, du Registrar et
du Service de localisation. Soit 192.168.0.10, 192.168.0.11, 192.168.0.221, 192.168.0.220 et 192.168.0.219.

Romain Wenger - 37 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Figure 21 : Création d'une règle Sourcefire

Les champs suivants doivent être remplis ainsi :

Champ Valeur
Message SIP BYE DoS
Classification Denial of Service
Source IPs $EXTERNAL_NET
Source Port any
Destination IPs $SIP_PROXY_IP
Destination Port $SIP_PROXY_PORT

Sous « Detection Options » on ajoute l’option « content » où l’on indique que le message doit
contenir le mot « BYE ».

Enfin, il reste à activer cette règle au niveau de la policy en la cochant sous la catégorie
« Local ». Sans oublier d’effectuer ensuite un « Apply » de la policy afin de prendre en compte
la modification. Cela peut prendre 1 à 2 minutes pour s’exécuter.

Romain Wenger - 38 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Lorsque l’attaque est réitérée, une alerte est maintenant levée par l’IDS. La figure suivante
montre le détail de l’évènement.

Figure 22 : Affichage des détails d'un évènement détecté par Sourcefire

Les informations données sont complètes et précises, ainsi on peut voir le payload32 du
message avec lequel on remarque que ce message venant de cette adresse IP n’était pas
légitime.

Nous terminerons par cette remarque : quelques secondes après cette attaque, lorsque le
deuxième téléphone raccroche, une nouvelle alerte est levée concernant un portscan UDP
venant de ce téléphone sur celui qui a reçu le BYE. Ce dernier ne répondant bien entendu pas
aux messages BYE légitimement émis, ceux-ci sont répétés plusieurs fois jusqu’à dépasser la
limite définie pour le portscan.

Cette observation est un bon exemple d’une alerte levée qui n’a que peu d’importance et qui
pourrait être mal interprétée. L’amélioration de ceci sera l’une des tâches du futur corrélateur
d’évènement.

32
Payload : charge utile, ici le contenu du paquet.

Romain Wenger - 39 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

14 Annexe C : Tableau des caractéristiques de Sourcefire

SOURCEFIRE

Intrusion Sensor
(500/1000/2000/2100/3000)
Network based Yes
Deployment Host based
Network packets Yes
Characterization

Information Source Others


Stateful Pattern Recognition Yes
Signature Yes
Protocol Decode Yes
Anomaly Detection Yes
Detection Method Heuristic Detection
Execution Real Time Yes
Active Yes
Response Passive Yes
Suitability

Local Yes
Architecture Distributed Yes

Local or Centralized (use


IDS Management Sourcefire Defense center)
Attack and misuse definition Yes
Attack and misuse response Yes
Network Protocols
Flexibility

Reports Yes
Technical component

Encryption options
Customizable Features Security Option
Broad Yes
Scalability Limited
Self-Monitoring
ability Protection

Stealth Technology Yes


Console security Yes
Communication Security Yes
Comprehen Interoper

Common Management Yes


Other Security Tools
Vulnerability Scanner
Encrypted Sessions
siveness

Additional Misuse System behavior


Monitoring Other
VoIP Security Signalization protocol filter 1

Romain Wenger - 40 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Media stream filter 1


Cross-protocol Detection
Correlation of signaling and media
stream
Managemen

Event Prioritization Yes


Event Merging 2 (Threshold)
t

Event Trace & Replay Yes


Additional Attack Information Yes
Session Hijacking
Response
Active

Session Termination Yes


Firewall or Switch Reconfiguration Yes
Sessions Logging Yes
& Forensic

Data Collection and correlation Yes (Data Collection)


Analysis

Forensic Analysis Yes


Central Storage of correlated information
Support a third party tool for correlation's process
Alarm display
E-mail, E-page Alerts Yes
Alarm

SNMP Traps Yes


Script execution
Alarm summarization Yes
Attacks Notification Syslog Yes
REGISTER Hijacks 1
SIP Based Attacks

CANCEL/BYE Attack 1
REDIRECT Attack 1
QoS abuse 1
Flood 1
Malformed Packet 1
SPAM
Others
Attack Protection

RTP Insertion
Attacks
Based

RTP Tampering
SDP Redirect
VoIP Other
Network ARP Attack
IP Spoofing
TCP/UDP/ICMP Flood Yes
TCP/UDP Replay Yes
TFTP/DHCP Insertion
DHCP Starvation
DoS/DDoS Yes
Virus / worms
WWW attacks Yes

Romain Wenger - 41 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

Buffer overflow
SMTP, POP attacks Yes
FTP, SSH, Telnet attacks Yes
TCP Hijacks Yes
TCP stream reassembly Yes
IP fragmentation reassembly Yes
IDS evasion protection Yes
Others protections Yes
Automatic Signature Updating Sourcefire's site
Update's Frequency
Hybrid Detection Method (Anomaly &
Pattern Matching Detection)
Zero Day Need an additional system
Interface Web-based
Reporting

Format PDF, HTML, CVS


Merging
Archiving
DNS Yes
HTTP Yes
FTP Yes
SMTP Yes
SNMP Yes
TELNET Yes
SSL/SSH Yes
SIP
Supported Protocols

H.323
MGCP
Specific Applicability

SDP
RTP/RTCP
Application Protocols Others
UDP Yes
TCP Yes
ICMP Yes
IP Yes
ISDN
NetBIOS Yes
AppleTalk
IPSec
Ethernet Yes
Network Protocols Others
OS Client
System
Target

OS Server
Operating System OS Detector
Network Topology 10/100 Mbs Ethernet Yes
T3 Links Yes

Romain Wenger - 42 - 29.06.2007


Détection d’intrusions VoIP avec Sourcefire et introduction à ExaProtect

FDDI Yes
ATM
ISDN
Others
Switched Nets
Software
Hardware
Acquisition

Both
Implementation Appliance Yes
>30K
20-30K
10-20K Yes (IS2000)
Cost ($US) <10K Yes (IS500, IS1000)

1 Pas pris en charge de base, mais cette fonctionnalité peut être implémentée
2 Est en partie possible

Romain Wenger - 43 - 29.06.2007

You might also like