Td Wenger Rapport.pre Projet

Pré-projet de diplôme 2007

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

Romain Wenger TR2007

Professeur Expert Assistante

: Stefano Ventura : Sylvain Maret : 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 5.2

6

Sourcefire ............................................................................................... 10 6.1 6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7

6.3 6.3.1 6.3.2

6.4 6.4.1 6.4.2

6.5

7

Présentation .................................................................................................. 10 Composants .................................................................................................. 10 Policies ................................................................................................................... 11 Rules ...................................................................................................................... 12 Preprocessors .......................................................................................................... 13 Portscan Detection ................................................................................................... 15 Variables................................................................................................................. 16 Alerting................................................................................................................... 17 Affichage des évènements ......................................................................................... 18

Tests ............................................................................................................ 18 Méthode.................................................................................................................. 18 Résultats................................................................................................................. 18

Problématique VoIP ........................................................................................ 19 Stateful inspection.................................................................................................... 19 Autres protocoles VoIP.............................................................................................. 19

Evaluation ..................................................................................................... 20

Bases de corrélation ............................................................................... 22 7.1 7.2

8

Présentation .................................................................................................... 9 Logs ............................................................................................................... 9

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

ExaProtect .............................................................................................. 24 8.1 8.2 8.2.1 8.2.2 8.2.3

Présentation .................................................................................................. 24 Security Management Solution (SMS) ............................................................... 24 Security Management Agent (SMA) ............................................................................ 24 Security Management Platform (SMP) ......................................................................... 25 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

12

Sites Web ..................................................................................................... 28

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

12.1 12.2 12.3 12.4

13

Nouvelle policy .............................................................................................. Activation des règles ...................................................................................... Détection des portscans .................................................................................. Configuration des variables .............................................................................

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

13.1 13.2

Portscan ....................................................................................................... 31 Man-in-the-middle (MITM) .............................................................................. 32

13.2.1 13.2.2 13.2.3

13.3

Description .......................................................................................................... 32 Réalisation........................................................................................................... 33 Détection............................................................................................................. 34

Message SIP/BYE DoS .................................................................................... 35

13.3.1 13.3.2 13.3.3

14

29 29 30 30

Description .......................................................................................................... 35 Réalisation........................................................................................................... 35 Détection............................................................................................................. 37

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 Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

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

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

-

-

10.192.73.82

Elément

Sourcefire IS 1000

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 5.1

OpenSER 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 6.1

Sourcefire 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. Appliance : en informatique, élément matériel effectuant une fonction spécifique et dont la configuration est plus ou moins restreinte. 12

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. Celleci 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 14

Detection engine : analyseur du réseau intégré à SourceFire et incluant l’interface réseau. 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 préinstallées

- Peu de règles pour SIP et la VoIP en général

+ Accessibilité et création aisée de nouvelles règles

- Pas d’analyse stateful des sessions SIP

+ Gestion intégrale par l’interface Web

- Pas de détection des ARP 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 7.1

Bases de corrélation 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.enstbretagne.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 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.

semaine

consistera

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

Deployment

Host based

Characterization

Network packets

Information Source

Detection Method

Suitability

Stateful Pattern Recognition

Yes

Signature

Yes

Protocol Decode

Yes

Anomaly Detection

Yes

Heuristic Detection

Response

Flexibility

Yes

Others

Execution

Architecture

Real Time

Yes

Active

Yes

Passive

Yes

Local

Yes

Distributed

Yes Local or Centralized (use Sourcefire Defense center)

IDS Management Attack and misuse definition

Yes

Attack and misuse response

Yes

Network Protocols Reports

Yes

Encryption options

Customizable Features

Security Option Broad

Scalability

Comprehen Interoper siveness ability Protection

Technical component

Yes

Romain Wenger

Yes

Limited

Self-Monitoring Stealth Technology

Yes

Console security

Yes

Communication Security

Yes

Common Management

Yes

Other Security Tools Vulnerability Scanner Encrypted Sessions

Additional Misuse Monitoring VoIP Security

System behavior Other Signalization protocol filter

- 40 -

1

29.06.2007

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

Media stream filter

1

Active Managemen Response t

Cross-protocol Detection Correlation of signaling and media stream

Event Prioritization

Yes

Event Merging

2 (Threshold)

Event Trace & Replay

Yes

Additional Attack Information

Yes

& Forensic Analysis

Session Hijacking Session Termination

Yes

Firewall or Switch Reconfiguration

Yes

Sessions Logging

Yes

Data Collection and correlation

Yes (Data Collection)

Forensic Analysis

Yes

Central Storage of correlated information Support a third party tool for correlation's process

Alarm

Alarm display E-mail, E-page Alerts

Yes

SNMP Traps

Yes

Script execution Alarm summarization

Yes

Syslog

Yes

REGISTER Hijacks

1

CANCEL/BYE Attack

1

REDIRECT Attack

1

QoS abuse

1

Flood

1

Malformed Packet

1

SPAM Others RTP Insertion

Based Attacks

Attack Protection

SIP Based Attacks

Attacks Notification

VoIP Network

RTP Tampering SDP Redirect Other 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

Romain Wenger

- 41 -

Yes

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)

Supported Protocols

Specific Applicability

Reporting

Zero Day

Need an additional system

Interface

Web-based

Format

PDF, HTML, CVS

Merging Archiving DNS

Yes

HTTP

Yes

FTP

Yes

SMTP

Yes

SNMP

Yes

TELNET

Yes

SSL/SSH

Yes

SIP H.323 MGCP SDP RTP/RTCP

Application Protocols

Others UDP

Yes

TCP

Yes

ICMP

Yes

IP

Yes

ISDN NetBIOS

Yes

AppleTalk IPSec Ethernet

Network Protocols

Yes

Others

Target System

OS Client

Romain Wenger

OS Server

Operating System

OS Detector

Network Topology

10/100 Mbs Ethernet

Yes

T3 Links

Yes

- 42 -

29.06.2007

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

FDDI

Yes

ATM ISDN Others

Switched Nets Software

Acquisition

Hardware Both

Implementation

Appliance

Yes

>30K 20-30K 10-20K

Cost ($US)

<10K

1 2

Romain Wenger

Yes (IS2000) Yes (IS500, IS1000)

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

- 43 -

29.06.2007