Professional Documents
Culture Documents
et introduction à ExaProtect
Romain Wenger
TR2007
1 Synthèse................................................................................................... 5
2 Introduction ............................................................................................. 5
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
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
10 Conclusion .......................................................................................... 27
11 Références.......................................................................................... 28
11.1 Sites Web ..................................................................................................... 28
1 Synthèse
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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 :
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.
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.
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.
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.
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.
6.2.5 Variables
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.
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é.
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.
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.
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
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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 ».
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.
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.
26
Illustration tirée du site Internet de la société (http://www.exaprotect.com).
Voici enfin quelques points sur les prochaines étapes importantes qui feront suite à ce rapport
lors du travail de diplôme :
• 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.
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.
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
• Snort http://www.snort.org
• Sourcefire http://www.sourcefire.com
• OpenSER http://www.openser.org
• Wikipedia http://www.wikipedia.org
Cette annexe contient les opérations de configuration effectuées pour l’utilisation de Sourcefire
telle que décrite dans ce rapport.
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 ».
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 ».
Comme indiqué dans la présentation des composants de Sourcefire, la règle suivante peut être
activée :
Elle est utile pour combler une faille de sécurité des téléphones mais reste de faible importance
pour ce projet.
La détection des portscans (menu « Portscan Detection ») peut se limiter dans notre cas au
réseau VoIP qui est le plus sensible.
192.168.0.10,192.168.0.11,192.168.0.219,192.168.0.220,192.168.0.221
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
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.
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.
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.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.
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.
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.
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.
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.
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).
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.
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).
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.
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.
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.
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.
SOURCEFIRE
Intrusion Sensor
(500/1000/2000/2100/3000)
Network based Yes
Deployment Host based
Network packets Yes
Characterization
Local Yes
Architecture Distributed Yes
Reports Yes
Technical component
Encryption options
Customizable Features Security Option
Broad Yes
Scalability Limited
Self-Monitoring
ability Protection
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
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
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
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