N° d’ordre 21 / MP2 / STI / TCO Année universitaire : 2016 / 2017

UNIVERSITE D’ANTANANARIVO
----------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------
MENTION TELECOMMUNICATION

MEMOIRE DE FIN D’ETUDES

en vue de l’obtention

du DIPLOME de MASTER

Titre : Ingénieur
Domaine : Sciences de l’ingénieur
Mention : Télécommunication
Parcours : Système et Traitement de l’Information (STI)

par : RANOTRONARISON Nomena Arivony

IMPLEMENTATION D’UN HONEYPOT

POUR LA SECURISATION D’UN RESEAU D’ENTREPRISE

Soutenu le 10 Juillet 2018 devant la Commission d’Examen composée de :

Président : M. RAKOTOMALALA Mamy Alain

Examinateurs : M. RANDRIAMITANTSOA Andry Auguste

M. RAJAONARISON Tianandrasana Roméo
M. RATSIMBAZAFY Andriamanga

Directeur de mémoire : Mme RAMAFIARISONA Hajasoa Malalatiana

 REMERCIEMENTS

En premier lieu, je remercie Dieu pour m’avoir donné la force et le courage de pouvoir réaliser ce
mémoire.

Je tiens à exprimer toute ma gratitude à ceux qui ont contribué de près ou de loin, à son élaboration ;

Je remercie respectueusement :

Monsieur RAMANOELINA Armand René Panja, Président de l'Université d'Antananarivo,

Monsieur ANDRIANAHARISON Yvon, Directeur de l’Ecole Supérieure Polytechnique

d’Antananarivo,

Monsieur RAKOTOMALALA Mamy Alain, Chef du Département Télécommunication,

Madame RAMAFIARISONA Hajasoa Malalatiana, mon directeur de mémoire, Professeur et maitre

de conférences au sein du Département Télécommunication, pour ses conseils qui ont été d’une
importance majeure pendant la réalisation du présent mémoire,

Tous les membres du jury, enseignants du Département Télécommunication, dont :

 M. RANDRIAMITANTSOA Andry Auguste, Maitre de conférences

 M. RAJAONARISON Tianandrasana Roméo, Maitre de conférences
 M. RATSIMBAZAFY Andriamanga, Maitre de conférences

Tous les professeurs du Département Télécommunication qui ont su transmettre des connaissances
plus qu’importantes dans notre formation.

Je remercie aussi particulièrement mes parents, ma famille et mes amis qui m’ont soutenu durant
toute la préparation de ce mémoire

i
 TABLE DES MATIERES

REMERCIEMENTS ........................................................................................................................... I

TABLE DES MATIERES ................................................................................................................ II

LISTE DES ABREVIATIONS ......................................................................................................VII

INTRODUCTION GENERALE ....................................................................................................... 1

CHAPITRE 1 : LA SECURITE DES SYSTEMES D’INFORMATION ......................................... 2

1.1.1 La notion de politique de sécurité ............................................................................................ 3

1.1.2 Les systèmes de détection et de prévention d’intrusion IDS/IPS ............................................. 4
Les systèmes de détection d’intrusions (IDS) ..................................................................... 4
Les systèmes de détection d’intrusions réseaux (NIDS) ..................................................... 5
HostBased Intrusion Detection System (HIDS) .................................................................. 5
Les systèmes de détection d’intrusions hybrides ................................................................. 6
Les systèmes de prévention d’intrusions (IPS).................................................................... 7
Les systèmes de prévention d’intrusions « kernel » (KIPS) ................................................ 7
1.1.3 Les pare-feux (firewall) ............................................................................................................ 7
Les systèmes à filtrage de paquets sans état (stateless) ....................................................... 9
Les systèmes à filtrage de paquets avec état (stateful) ...................................................... 10
Pare-feu de type proxy ....................................................................................................... 10
1.1.4 La segmentation ..................................................................................................................... 11
La segmentation physique ................................................................................................. 11
La segmentation par VLANs ............................................................................................. 12
La segmentation en utilisant une DMZ ............................................................................. 13
Segmentation en fonction des services .............................................................................. 13

1.2.1 SQL injection .......................................................................................................................... 15

Injection SQL sur une chaîne de caractères ....................................................................... 16
Injection SQL sur un nombre ............................................................................................ 17
1.2.2 Remote file inclusion (RFI) et Local file inclusion (LFI) ....................................................... 17

ii
 Identification de la faille RFI et LFI .................................................................................. 18
Exploitation de la faille RFI ............................................................................................... 18
1.2.3 Cross-site scripting (XSS) ....................................................................................................... 19

CHAPITRE 2 : LES HONEYPOTS ................................................................................................ 22

2.1.1 Historique ............................................................................................................................... 22

2.1.2 Définition ................................................................................................................................ 22
2.1.3 Intégration du Honeypot dans la politique de sécurité du système d’information ................. 23

2.2.1 Honeypot de production.......................................................................................................... 24

La prévention ..................................................................................................................... 24
La détection ........................................................................................................................ 25
La réaction.......................................................................................................................... 25
2.2.2 Honeypot de recherche ........................................................................................................... 26
2.2.3 Classification des Honeypot ................................................................................................... 26
Honeypots à faible interaction ........................................................................................... 26
Avantages .................................................................................................................................... 27
Inconvénients ............................................................................................................................... 27
Honeypot à moyenne interaction ....................................................................................... 27
Avantages .................................................................................................................................... 28
Inconvénients ............................................................................................................................... 28
Honeypots à haute interaction ............................................................................................ 28
Avantages .................................................................................................................................... 29
Inconvénients ............................................................................................................................... 29

2.3.1 Honeypot placé devant le pare-feu ......................................................................................... 30

2.3.2 Honeypot placé dans une DMZ .............................................................................................. 31
1ère stratégie ................................................................................................................................. 32
2ème stratégie ................................................................................................................................ 32
2.3.3 Honeypot placé derrière un firewall ....................................................................................... 34

iii
2.4.1 Définition ................................................................................................................................ 35
2.4.2 Le concept de capture et de contrôle des données ................................................................. 35
2.4.3 Architecture des Honeynets .................................................................................................... 36
1ère génération .................................................................................................................... 36
2ème génération ................................................................................................................... 38
3ème génération ................................................................................................................... 39
2.4.4 Les Honeynets virtuels............................................................................................................ 39
Self-Contained Virtual Honeynet ...................................................................................... 39
Honeynet virtuel hybride ................................................................................................... 40

CHAPITRE 3 : DEPLOIEMENT D’UN HONEYPOT DANS UN RESEAU D’ENTREPRISE .. 43

3.2.1 Ressources matérielles ........................................................................................................... 44

3.2.2 Ressources logicielles............................................................................................................. 44

3.3.1 Le réseau interne .................................................................................................................... 45

3.3.2 Les zones démilitarisées (DMZ) ............................................................................................. 46
3.3.3 Le réseau externe.................................................................................................................... 47

3.4.1 Configuration du firewall Cisco ASAv 9.8.1 .......................................................................... 48

Configuration des interfaces .............................................................................................. 48
Configuration NAT............................................................................................................ 49
Configuration des ACLs .................................................................................................... 50
3.4.2 Configuration du LAN ............................................................................................................ 52
Attribution d’adresses ........................................................................................................ 52
Configuration du serveur DNS .......................................................................................... 53
3.4.3 Configuration du serveur web publique ................................................................................. 53
3.4.4 Le Honeypot web Glastopf ..................................................................................................... 54
Presentation du honeypot................................................................................................... 54
Fonctionnement de Glastopf .............................................................................................. 55
Configurations de Glastopf ................................................................................................ 55

iv
 Configuration de Glastopf-Analytics ................................................................................. 57

CHAPITRE 4 : SIMULATION D’UNE ATTAQUE SUR LE HONEYPOT GLASTOPF............ 59

4.1.1 Identification des vulnérabilités.............................................................................................. 59

4.1.2 Exploitation de la faille RFI ................................................................................................... 61
4.1.3 Visualisation des données récoltés par le honeypot ............................................................... 62

4.2.1 Les points forts ........................................................................................................................ 64

4.2.2 Les points faibles .................................................................................................................... 64
4.2.3 Amélioration de l’efficacité des Honeypots ............................................................................ 64
4.2.4 Estimation du cout de l’implémentation d’un Honeypot ........................................................ 65
Grandes entreprises ............................................................................................................ 65
Enterprise moyenne............................................................................................................ 65

CONCLUSION ................................................................................................................................ 67

ANNEXES ....................................................................................................................................... 68

ANNEXE 1: LE MODELE OSI ...................................................................................................... 68

A1.1 Les 7 couches du modèle OSI................................................................................................. 68

A1.2 Les protocoles de chaque couche du modèle OSI .................................................................. 69

ANNEXE 2 : LES SERVICES LES PLUS UTILISES ................................................................... 70

ANNEXE 3 : LES COMMANDES SQL......................................................................................... 71

A3.1 Base de données ...................................................................................................................... 71

A3.2 Tables ...................................................................................................................................... 71
A3.2.1 Création d’une table simple .................................................................................................. 71
A3.2.2 Manipulation des tables ........................................................................................................ 72

ANNEXE 4 : FICHIER DE CONFIGURATION PHP (PHP.INI) .................................................. 74

ANNEXE 5 : LES PLAGES D’ADRESSES IP .............................................................................. 75

A5.1 Les plages d’adresses IP privées et publiques ......................................................................... 75

v
A5.2 Quelques plages d’adresses IP publiques attribuées à Madagascar ........................................ 75

ANNEXE 6 : LES FICHIERS DE CONFIGURATION DE GLASTOPF ..................................... 77

BIBLIOGRAPHIE ........................................................................................................................... 82

FICHE DE RENSEIGNEMENTS ................................................................................................... 83

RESUME ........................................................................................................................................... 1

ABSTRACT....................................................................................................................................... 1

vi
 LISTE DES ABREVIATIONS

ACL: Access Control List

AfriNIC: African Network Information Centre
ARP: Address Resolution Protocol
ASA: Adaptive Security Appliance
AT&T: American Telephone & Telegraph
BDD: Base De Données
BPF: Berkeley Packet Filter
CD: Compact Disk
CDROM: Compact Disk – Read Only Memory
DHCP: Dynamic Host Configuration Protocol
DNS: Domain Name Server
GSoC: Google Summer of Code
HTML: Hypertext Markup Language
ICMP: Internet Control Message Protocol
IDMEF: Intrusion Detection Message Exchange Format
IDS: Intrusion Detection System
IP: Internet Protocol
IPS: Intrusion Prevention System
ISP: Internet Service Provider
KIDS: Kernel Intrusion Detection System
LAN: Local Area Network
LFI: Local File Include
NAT: Network address translation
NIDS: Network Intrusion Detection System
OS: Operating System
OSI: Open Systems Interconnection
PHP: PHP Hypertext Preprocessor
Psad: port scan attack detection
RAM: Random Access Memories

vii
RFI: Remote file inclusion
RFC: Requests For Comment
SGBD: Système de Gestion de Base de Données
SQL: Structured Query Language
TCP: Transmission Control Protocol
TTL: Time To Live
UDP: User Datagram Protocol
URL: Uniform Resource Locator
VLAN: Virtual Local Area Network
XSS: Cross-Site Scripting

viii
 INTRODUCTION GENERALE

La croissance et le développement continus des technologies de l'information et leur intégration dans

la vie quotidienne de la population mondiale ont apporté des avantages significatifs, des progrès
économiques, culturels et sociaux, mais ont également donné un terrain favorable à la
cybercriminalité. Des études récentes ont révélé qu'à l'heure actuelle, un grand nombre d'entreprises
sont victimes d’infection par des logiciels malveillants (malware) et sont exposées à la perte de
données, ce qui peut causer des dommages importants et même conduire à l’arrêt total de la
production d’une entreprise.

Les décideurs de stratégie dans le monde entier axent leurs recherches et leurs travaux sur l'état de
l'infrastructure d'information. Ils souhaitent s'assurer que les utilisateurs des réseaux emploient les
meilleures pratiques en matière de technologie et de processus afin de rendre les réseaux le plus
sécurisé possible.

Plusieurs mécanismes de sécurité ont été développés pour se protéger des menaces et des
vulnérabilités, tels que : Les pare-feux, les IDS (Intrusion Detection System), les routeurs filtrants,
les protocoles et applications sécurisées (IPv6, IPSec, etc.), les VPN (Virtual Private Network), etc.
Cependant, malgré tous ces outils, les intrusions dans les systèmes informatiques sont encore
fréquentes, car ces derniers sont surtout de type préventif dont le fonctionnement est basé sur des
signatures d’attaques déjà connues et laissent de ce fait la porte grande ouverte à des attaques
inconnues. Il est donc très important et nécessaire de découvrir au plus tôt les nouvelles méthodes
que les pirates informatiques emploient pour compromettre les systèmes cibles et affronter ainsi ces
attaques. Pour assurer ce besoin, technologie de sécurité informatique appelée "Honeypots" ou pot
de miel est apparue.

Afin de mieux comprendre l’utilité mais aussi la mise en place de la technologie Honeypot, ce
mémoire intitulé « Implémentation d’un Honeypot pour la sécurisation d’un réseau
d’entreprise » va se composer de quatre chapitres. Dans la première partie, il sera surtout question
de l’aspect général de la sécurité informatique et des menaces sur le web. Ensuite, la deuxième partie
concernera la technologie « Honeypot ». Puis, la troisième partie se tournera vers le déploiement de
la technologie en entreprise. Et enfin, la quatrième et dernière partie consistera à simuler et évaluer
le système mis en place.

1
 CHAPITRE 1

LA SECURITE DES SYSTEMES D’INFORMATION

Aspects de la sécurité informatique

Durant les dernières décennies, les systèmes informatiques ont enregistré une évolution considérable
et offrent d’énormes possibilités de traitement automatique de l’information. Mais l’accroissement
de ces possibilités a aussi entrainé une hausse des risques de divulgation d’informations. En outre,
cette évolution a affecté plusieurs aspects des réseaux :

 Les architectures sont de plus en plus distribuées ;

 Les tailles des dispositifs de stockage d’information sont devenues immenses ;
 La nécessité de partager des ressources est de plus en plus croissante ;
 etc…

Devant de telles exigences, plusieurs dispositifs ne sont plus adéquats pour assurer une bonne
protection. Les réseaux sont ainsi exposés à des attaques si nombreuses qu’il serait presque
impossible de les décrire toutes. Il est cependant possible de les classer en fonction des objectifs des
pirates qui reposent sur les faiblesses de sécurité [1].

 Attaques permettant de dévoiler le réseau : Ces attaques visent souvent à établir la cartographie
du réseau, identifier ses systèmes par des balayages ICMP (Internet Control Message Protocol)
ou TCP (Transmission Control Protocol), identifier ses routeurs, traverser ses équipements de
filtrage, etc.
 Attaques permettant d’écouter le trafic réseau : Ces attaques sont utilisées pour capturer des
informations telles que les mots de passe. Parmi elles, le sniffing.
 Attaques permettant d’interférer avec une session réseau : Ces attaques exploitent les faiblesses
des protocoles réseau. On peut en noter les usurpations d’adresses (ARP spoofing et IP spoofing)
et les attaques dites man-in-the middle (l’homme du milieu).
 Attaques permettant de tester une multitude de combinaison de lettres ou de symboles : Ces
attaques permettent d’essayer toutes les combinaisons d’identifiant ou de mot de passe possibles.
Ce type d’attaque sera utilisé plus tard dans la partie simulation de ce mémoire.

2
Cette liste d’attaques n’est pas exhaustive et est en perpétuel évolution due au fait que les pirates
aussi tentent de trouver de nouvelles failles exploitables dans les systèmes informatiques et
développent de nouvelles méthodes pour les exploiter.
Pour faire face à ces multitudes d’attaques, il faut mettre en place un ensemble de mécanismes de
protection pour assurer les propriétés suivantes :

 Confidentialité : La confidentialité est la protection des données contre toute forme de

divulgation. En d’autres termes, c’est l’assurance que l’information est inaccessible à une entité
ou un processus non autorisé.
 Intégrité : L’intégrité est la capacité de protéger les données contre toute modification non
autorisée.
 Disponibilité : Le système doit fonctionner sans faille durant les plages d'utilisation prévues et
garantir l'accès aux services et ressources installées avec le temps de réponse attendu.

Ces propriétés sont fondamentales à la sécurité de tout système informatique. On pourrait également
en ajouter d’autres telles que :

 L’authentification : S’assurer qu’une entité ou un processus est bien celui qu’il prétend être.
 La vérifiabilité : Fournir suffisamment d’informations relatives aux activités d’un système.
 La non-répudiation ou l’irrévocabilité : S’assurer qu’une entité ou un processus engagé dans une
communication ne pourra nier avoir reçu ou émis un message.

Toute action, volontaire ou accidentelle, pouvant porter atteinte à une de ces propriétés doit être
interceptée. D’où la nécessité de définir une politique globale de sécurité.

1.1.1 La notion de politique de sécurité

Une politique de sécurité d’un réseau est un ensemble de règles visant à protéger ses ressources
d’éventuels incidents de sécurité pouvant affecter négativement son activité. Elle détermine pour
chaque action entreprise si elle doit être autorisée ou non. Elle présente également une partie de
l'architecture de base de l'environnement de sécurité du réseau.

N. Stouls et M.-L. Potet définissent trois types de politiques dans leurs ouvrages [2]:

 Politique restrictive : Elle consiste à spécifier les actions qui sont autorisées. Tout ce qui n’est
pas explicitement autorisé est alors interdit.
 Politique permissive : À l’opposé de la restrictive, elle décrit les actions interdites. Tout ce qui
n’est pas explicitement interdit est alors autorisé.

3
 Politique combinatoire : Contrairement aux deux premières, une politique combinatoire consiste
à définir aussi bien les actions autorisées que celles interdites.

Une politique doit être complète et cohérente afin d’assurer qu’il n’y ait pas d’action qui soit ni
interdite ni autorisée ou interdite et autorisée par la même politique. Pour assurer de telles propriétés,
il faut analyser tous les éléments critiques du réseau et identifier les besoins en termes de sécurité.

1.1.2 Les systèmes de détection et de prévention d’intrusion IDS/IPS

Afin de détecter ou de prévenir les attaques informatiques, il est nécessaire, voir même primordiale
d’utiliser des logiciels permettant de surveiller les données circulant sur un système. Ces logiciels
sont capables de réagir dans le cas où ils détectent des flux de données suspects d’où leur nom,
système de détection d’intrusion (IDS : Intrusion Detection System) et système de prévention
d’intrusion (IPS : Intrusion Detection System).

Les premiers systèmes de détection d’intrusion ont été développés par l’armée américaine mais plus
tard, des projets open sources ont été lancés dont certains d’entre eux ont connu un grand succès
dont : Snort ou Prelude. Plusieurs autres entreprises réputées dans le domaine de l’informatique
telles qu’IBM Internet Security Systems, Symantec, Cysco Systems,… ont eux aussi développé leur
propre système.

Les attaques informatiques utilisées par les pirates sont très variées ; certaines exploitent des failles
réseaux tandis que d’autres utilisent des failles de programmation. De ce fait, cela implique
l’implantation de systèmes de détection et de prévention à plusieurs niveaux. Ainsi, il existe
différents types d’IDS dont les caractéristiques principales seront détaillées dans les parties
suivantes.

Remarque : Certains termes sont souvent employés quand on parle d’IDS et IPS :

 Faux positif : une alerte provenant d’un IDS/IPS mais qui ne correspond pas à une attaque réelle.
 Faux négatif : une intrusion réelle qui n’a pas été détectée par l’IDS/IPS.

Les systèmes de détection d’intrusions (IDS)

C’est un ensemble de composants logiciels et matériels dont la fonction est de détecter et analyser
toute tentative d’effraction (volontaire ou non) sur les politiques de sécurité dans un réseau. Ils
assurent principalement la détection des techniques de sondage (balayages de ports, fingerprinting),
des tentatives de compromission de systèmes, d’activités suspectes internes, des activités virales ou
encore audit des fichiers de journaux (logs).

4
Il existe différentes approches de détection utilisée par les IDS :

 Statistique : contrôle les données, le trafic réseau et le profil de l'utilisateur à la volée

 Motifs : recherche des schémas connus d'intrusion
 Règles : vérifie que les droits des systèmes sont bien respectés, que le comportement des
utilisateurs n'est pas anormal
 États : s'assure de la logique des actions et des données
 Heuristique : vérifie les données en utilisant des technologies basées sur l'apprentissage.

Les systèmes de détection d’intrusions réseaux (NIDS)

Les NIDS (Network Intrusion Detection System) sont des IDS qui se chargent de surveiller le trafic
sur le réseau en confrontant les paquets détectés à un ensemble de signatures ou de règles. Si les
règles sont violées, le NIDS enregistre l'événement comme une attaque [3]

Les fonctions du NIDS sont divisées en trois taches distinctes :

 La capture : Les paquets transitant au niveau de la couche réseau sont capturés en temps réel
puis filtrés à partir du BPF (Berkeley Packet Filter) afin d’en extraire les champs utiles tels que
les adresses IP ou les headers des paquets.
 L’analyse des signatures : Les informations récupérées sont comparées à des attaques déjà
répertoriées dans des bibliothèques de signatures afin d’en détecter l’existence d’anomalies.
 Les alertes : Des alertes sont générées puis stockées en cas de détection d’anomalies sur le réseau.
Le contenu de ces fichiers d’alertes est représenté sous le format IDMEF (Intrusion Detection
Message Exchange Format), RFC 4765, afin d’assurer l’interopérabilité entre les différentes
entités de sécurité.

Figure 1.01 : Technique utilisée par un NIDS

HostBased Intrusion Detection System (HIDS)

Les HIDS, aussi appelés « IDS systèmes » sont chargés de surveiller le système sur lequel ils sont
installés dans le but de constater les intrusions ou les tentatives. Les intrusions peuvent venir des
vers informatiques (worm), des chevaux de Troie (trojan), des virus, ou d’attaques visant des failles
spécifiques. Les HIDS n’analysent donc pas le trafic réseau mais les activités se produisant sur la

5
machine hôte. Ils se comportent comme un service (daemon) analysant les activités qui s’effectuent
sur son hôte en se basant sur des normes. Une alerte est générée lorsque les activités divergent de la
norme.

La surveillance d’une machine peut se faire de différentes manières :

 Contrôle des activités de la machine : nombre et listes de processus ainsi que d'utilisateurs,
ressources consommées, ...
 Contrôle des activités de l'utilisateur : horaires et durée des connexions, commandes utilisées,
messages envoyés, programmes activés, dépassement du périmètre défini...
 Contrôle des activités malicieuses d'un vers, virus ou cheval de Troie

Il existe un autre type d’HIDS qui est surtout basé sur la surveillance contre les intrusions et les
modifications effectuées dans le noyau (kernel). C’est pourquoi ils sont appelés KIDS (Kernel
Intrusion Detection System).

L’avantage du KIDS c’est qu’il agit plus rapidement par rapport aux autres IDS à cause du fait qu’il
ne se réfère pas à une base de signature et que les alertes sont plus pertinentes. En effet, le KIDS
présente rarement de faux positifs au niveau de ses alertes.

Les systèmes de détection d’intrusions hybrides

Généralement utilisés dans un environnement décentralisé, ils permettent de réunir les informations
de diverses sondes placées sur le réseau. Leur appellation « hybride » provient du fait qu’ils sont
capables de réunir aussi bien des informations provenant d’un système HIDS qu’un NIDS. Chaque
composant unifie son format d'envoi d'alerte (typiquement IDMEF) permettant à des composants
divers de communiquer et d'extraire des alertes plus pertinentes. L’architecture simplifiée d’un IDS
hybride est représentée par la figure 1.02 :

Figure 1.02 : Schéma simplifié d'un IDS hybride

Des sondes sont placées sur des points stratégiques du réseau, ou sur des machines. Chacune de ces
sondes remontera alors des alertes à une machine centrale, qui va agréger le tout.

6
 Les systèmes de prévention d’intrusions (IPS)
Les IPS sont un ensemble de composants logiciels et matériels dont la fonction principale est
d'empêcher toute activité suspecte détectée au sein d'un système. Contrairement aux IDS simples,
les IPS sont des outils aux fonctions actives, qui en plus de détecter une intrusion, tentent de la
bloquer.

Plusieurs stratégies de prévention d'intrusions existent :

 host-based memory and process protection : surveille l'exécution des processus et les tue s'ils
ont l'air dangereux (buffer overflow).
 session interception / session sniping : termine une session TCP avec la commande TCP Reset :
« RST ». Ceci est utilisé dans les NIPS (Network Intrusion Prevention System) ;
 Gateway intrusion detection : si un système NIPS est placé en tant que routeur, il bloque le trafic
; sinon il envoie des messages à d'autres routeurs pour modifier leur liste d'accès.

Un IPS possède de nombreux inconvénients. Le premier est qu'il bloque toute activité qui lui semble
suspecte. Or, il est impossible d'assurer une fiabilité à 100 % dans l'identification des attaques. Un
IPS peut donc malencontreusement bloquer du trafic inoffensif ! Par exemple, un IPS peut détecter
une tentative de déni de service alors qu'il s'agit simplement d'une période chargée en trafic. Les
faux positifs sont donc très dangereux pour les IPS [4].

Les systèmes de prévention d’intrusions « kernel » (KIPS)

Comme pour le cas du KIDS, évoqué plutôt dans la partie HIDS, l’utilisation d’un détecteur
d’intrusions au niveau noyau peut s’avérer parfois nécessaire pour sécuriser une station .Le KIPS
peut reconnaître des motifs caractéristiques du débordement de mémoire (buffer overflow), et peut
ainsi interdire l’exécution du code. Le KIPS peut également interdire le système d’exploitation
d’exécuter un appel système qui ouvrirait un « shell » de commandes.

Les KIPS analysent le plus souvent les appels systèmes, ce qui rend les exécutions assez lentes.
C’est pourquoi ce sont des solutions rarement utilisées sur des serveurs souvent sollicités.

1.1.3 Les pare-feux (firewall)

Un système pare-feu (firewall) est un dispositif conçu pour examiner et éventuellement bloquer les
échanges de données entre réseaux. Un pare-feu peut se présenter sous forme d’un routeur, d’un
ordinateur ou d’un matériel propriétaire.

7
Le pare-feu est un système permettant de filtrer les paquets de données échangés avec le réseau, il
s'agit ainsi d'une passerelle filtrante comportant au minimum les interfaces réseau suivante :

 une interface pour le réseau à protéger (réseau interne) ;

 une interface pour le réseau externe.

Figure 1.03 : Schéma de fonctionnement d'un pare-feu

Un système pare-feu contient un ensemble de règles prédéfinies permettant :

 D'autoriser la connexion (allow) ;

 De bloquer la connexion (deny) ;
 De rejeter la demande de connexion sans avertir l'émetteur (drop).

L'ensemble de ces règles permet de mettre en œuvre une méthode de filtrage dépendant de la
politique de sécurité adoptée par l'entité. On distingue habituellement deux types de politiques de
sécurité permettant :

 soit d'autoriser uniquement les communications ayant été explicitement autorisées :

 Tout ce qui n'est pas explicitement autorisé est interdit.
 soit d'empêcher les échanges qui ont été explicitement interdits.

La première méthode est sans nul doute la plus sûre, mais elle impose toutefois une définition précise
et contraignante des besoins en communication.

8
Le tableau ci-dessous donne des exemples de règles de pare-feu [5]:

Port Port
Règle Action IP source IP dest Protocol
source dest
1 Allow 192.168.10.20 194.154.192.3 tcp Any 25
2 Allow any 192.168.10.3 tcp Any 80
3 Allow 192.168.10.0/24 Any tcp Any 80
4 Deny any Any any Any any
Tableau 1.01 : Règles du pare-feu

Un pare-feu peut intervenir à différente couche du modèle OSI (voir Annexe A1.1), ce qui va définir
son type. En général il existe 3 types de pare-feu :

 Les systèmes à filtrage de paquets sans état (firewall stateless)

 Les systèmes à filtrage de paquets avec état (firewall stateful)
 Les firewalls de type proxy

Les systèmes à filtrage de paquets sans état (stateless)

Ils ne gardent en mémoire aucun contexte, ils traitent de façon identique tous les paquets IP qu'ils
voient passer, c'est à dire qu'ils analysent l'entête IP selon ses règles de filtrage. C'est le type de filtre
de paquet le plus couramment utilisé. Ce système agit sur les couches réseau et transport du modèle
OSI.

Le principe du filtrage consiste à configurer des règles généralement appelées ACL (Access Control
List) sur le firewall, permettant d’autoriser ou de bloquer les paquets d’un réseau à un autre en se
basant sur :

 L’adresse IP source ou destination ;

 Le numéro de port source ou destination ;
 Et le protocole (de couches 3 ou 4).

Malgré le fait que cette technique offre une défense simple et efficace, sa mise en place en termes
de protection réseau s’avère parfois bloquante pour le bon fonctionnement des systèmes du réseau
concerné. En effet, l’administrateur réseau est emmené à utiliser un trop grand nombre de règles
pour que le firewall puisse offrir la moindre connexion réelle. En plus de cela, la faiblesse de cette
technique reste aussi sa vulnérabilité aux attaques IP spoofing ou IP flooding.

9
 Les systèmes à filtrage de paquets avec état (stateful)
La technologie stateful est l’une des deux réponses possibles aux limites du filtre de paquets. Elle
inclut toutes les fonctionnalités d’un filtrage de paquet, auxquelles elle ajoute la capacité de
conserver la trace des sessions et des connexions dans des tables d’état interne. Elle agit donc
également au niveau de la couche session. Tout échange de données est soumis à son approbation et
adapte son comportement en fonction des états.

Cette technique convient aux protocoles de type connecté (TCP). Certains protocoles (UDP et
ICMP) posent un problème supplémentaire : aucune notion de connexion n’y est associée. Le
firewall est donc amené à examiner les paquets, et peut seulement gérer des timeout, souvent de
l’ordre d’une minute.

Cette approche apporte une amélioration certaine par rapport à la technique du filtrage simple de
paquets (stateless), elle se borne cependant à autoriser ou interdire l’accès à un service donné. Dès
lors que l’accès à un service est accordé, celui-ci est illimité. Elle n’est donc pas apte à détecter ou
à bloquer les attaques sur ces services autorisés.

D’autre part, un tel système ne protège aucunement un serveur contre les attaques s’appuyant sur
des failles du logiciel utilisé pour fournir le service.

Ce type de filtrage reste néanmoins la technique minimale pour une sécurisation réseau pour les
administrateurs réseau.

Pare-feu de type proxy

Le filtrage applicatif permet de filtrer les communications, application par application. Le filtrage
applicatif opère donc au niveau 7 (couche application) du modèle OSI, contrairement au filtrage de
paquets simple (niveau 4). Le filtrage applicatif suppose donc une connaissance des protocoles
utilisés par chaque application.

Le filtrage applicatif suppose donc une bonne connaissance des applications présentes sur le réseau,
et notamment de la manière dont elles structurent les données échangées (ports, etc.).

Un firewall effectuant un filtrage applicatif est appelé généralement passerelle applicative (ou
proxy), car il sert de relais entre deux réseaux en s'interposant et en effectuant une validation fine du
contenu des paquets échangés. Le proxy représente donc un intermédiaire entre les machines du
réseau interne et le réseau externe, subissant les attaques à leur place. De plus, le filtrage applicatif
permet la destruction des en-têtes précédant le message applicatif, ce qui permet de fournir un niveau
de sécurité supplémentaire.

10
Il s'agit d'un dispositif performant, assurant une bonne protection du réseau, pour peu qu'il soit
correctement administré. En contrepartie, une analyse fine des données applicatives requiert une
grande puissance de calcul et se traduit donc souvent par un ralentissement des communications,
chaque paquet devant être finement analysé.

Par ailleurs, le proxy doit nécessairement être en mesure d'interpréter une vaste gamme de protocoles
et de connaître les failles afférentes pour être efficace.

Enfin, un tel système peut potentiellement comporter une vulnérabilité dans la mesure où il
interprète les requêtes qui transitent par son biais. Ainsi, il est recommandé de dissocier le pare-feu
(avec état ou non) du proxy, afin de limiter les risques de compromission.

1.1.4 La segmentation
La segmentation est une technique couramment utilisée pour atténuer la congestion d’un réseau.
Cette technique consiste à diviser l’architecture du réseau en sections afin de réduire la taille des
domaines de diffusion (broadcast) et ainsi augmenter l’efficacité du réseau. Cette technique peut
aussi être utilisée pour augmenter la sécurité d’un réseau. En effet, elle permet d’implémenter des
dispositifs de sécurité entre les frontières des différents segments. Ce qui permet de mieux contrôler
le trafic en destination des ressources critiques.

Il existe plusieurs façons de segmenter un réseau [6] :

 La segmentation physique ;
 La segmentation par VLANs ;
 La segmentation en utilisant un DMZ ;
 La segmentation en fonction des services

La segmentation physique
La séparation physique des sous-réseaux est probablement la méthode de segmentation la plus
sécurisée, mais elle est également la plus coûteuse en termes de cartes réseau, d’infrastructures de
commutations additionnelles et intensifie l’administration.

11
 Figure 1.04 : Exemple de segmentation physique

La segmentation par VLANs

Un VLAN (Virtual Local Area Network ou Réseau Local Virtuel) est un réseau local regroupant un
ensemble de machines de façon logique et non physique. Il s’agit d’un dispositif de la couche 2
(liaison de données) qui fait ce que les VPNs font au niveau de la couche 3 (réseau). Le trafic au
sein d’un VLAN ne peut traverser un autre sans passer par un routeur. Ce qui permet de segmenter
un réseau sans infrastructures additionnelles. Cependant, la configuration des commutateurs
(switch) reliant les différents segments est d’une importance capitale car la sécurité d’un VLAN
dépend en partie de l’assignation des ports de ces commutateurs.

Figure 1.05 : Exemple de segmentation par VLAN

12
 La segmentation en utilisant une DMZ
Les administrateurs réseau se considèrent en guerre contre les attaquants et les utilisateurs même de
leurs systèmes. Il n’est pas surprenant qu’ils empruntent alors des termes militaires comme DMZ
(demilitarized zone). Une DMZ désigne une zone tampon d’un réseau, située entre ce dernier et
l’Internet (l’extérieur en général). Il s’agit d’un réseau intermédiaire protégé aussi bien contre
l’extérieur que le réseau interne. Le but est de pouvoir y regrouper les ressources du réseau offrant
des services accessibles de l’interne comme à l’externe afin d’éviter toute connexion directe au
réseau. Ces ressources sont souvent des serveurs publics tels que serveur HTTP, serveur DHCP, etc.

Tel que décrit ci-haut, une DMZ divise le réseau en deux. Ce principe est utilisé pour segmenter un
réseau en mettant en place une ou plusieurs DMZ.

Figure 1.06 : Exemple de réseau segmenté avec un DMZ

Segmentation en fonction des services

Une autre technique de segmentation est de considérer les services fournis par les différentes
ressources et segmenter le réseau en conséquence. Chaque segment est alors défini selon le service
fourni par ses ressources. Cette approche permet un contrôle très rigoureux entre les différents
segments du réseau, mais elle peut mener à un grand nombre de segments dépendamment des
services disponibles. Ce qui nécessite également des dispositifs de sécurités additionnels.

13
 Les attaques web
Sur internet des attaques ont lieu en permanence, à raison de plusieurs attaques par minute. Elles
peuvent provenir de n’importe où dans le monde, mais aussi, les cibles peuvent être n’importe qui
ayant un ordinateur ou un mobile connecté à internet. Internet n’est pas du tout un endroit sécurisé.
Afin de visualiser l’ampleur du danger, voici quelques statistiques sur les attaques web visant des
entreprises se produisant dans le monde [7]:

 Attaques web observées entre 06/04/2018 et le 13/04/2018 :

Nombre d’attaques recensées : 1.437.576

350 000 317 161 302 760

300 000 240 997
250 000
200 000 149 215 145 152
150 000 115 475
77 876 88 940
100 000
50 000
0

Figure 1.07 : nombre d’attaques web par jour

 Les types d’attaques utilisées :

Remote file
inclusion; 267 150;
19%

PHP injection; 11
732; 1%
Cross Site
Scripting; 151 376;
10%

Command
SQL Injection; 998 Injection; 8 389;
929; 69% 1%

Remote file inclusion PHP injection Cross Site Scripting

Command Injection SQL Injection

Figure 1.08 : tendances des types d’attaques

14
 Pays source et cible des attaques :

Pays Attaques Sources

United States 259 964 620
Netherlands 231 439 96
United Kingdom 175 603 105
Ukraine 136 509 68
China 129 171 348
Moldova, Republic of 53 055 9
Korea, Republic of 20 266 68
Germany 16 289 99
Taiwan, Province of China 15 388 11
Canada 12 144 39
Tableau 1.02 : Pays source et cible des attaques

A partir de ces statistiques, on constate le nombre important d’attaques visant les serveurs web de
différentes entreprises dans le monde. Les attaques à l'encontre des applications web sont toujours
nuisibles car elles donnent une mauvaise image de l'entreprise. Les conséquences d'une attaque
réussie peuvent notamment être une des suivantes :

 Défacement (modification non sollicité) de site web ;

 Vol d'informations ;
 Modification de données, notamment modification de données personnelles d'utilisateurs;
 Intrusion sur le serveur web.

Les trois attaques, dont SQL injection, Remote file inclusion et Cros-site scripting qui sont les plus
utilisées seront abordées dans les parties suivantes.

1.2.1 SQL injection

L'injection SQL est une technique où un pirate modifie une requête SQL existante pour afficher des
données cachées, ou pour écraser des valeurs importantes, ou encore exécuter des commandes
dangereuses pour la base. Cela se fait lorsque l'application prend les données envoyées par
l'internaute, et l'utilise directement pour construire une requête SQL.
Afin de bien comprendre le fonctionnement de ce type d’attaque, il est important de connaitre au
moins quelques bases fondamentales sur SQL (voir ANNEXE 3).

15
 Injection SQL sur une chaîne de caractères
Soit la requête suivante (Requête initiale):

1 $query = "SELECT id, titre, texte FROM articles WHERE titre LIKE '%".$_GET['titre']."%'";

Remarque : En langage SQL, une chaîne de caractère est entourée de guillemets (simples ou
doubles).

Cette requête va rechercher l'article dont le titre contient le terme envoyé par la variable titre,
variable de type GET (mais ça aurait pu être POST, cela ne change rien).

Soit un article intitulé « L'article de la semaine » qui sera recherché en utilisant le mot « L’article »

1 http://www.monsite.com/article.php?titre=L’article

Ce qui donnera la requête SQL suivante :

1 SELECT id, titre, texte FROM articles WHERE titre LIKE '%L’article%';

En validant l’URL, le navigateur va envoyer une erreur. Le responsable est en fait le guillemet
présent dans le terme recherché. Ce guillemet va être considéré comme la fin de la chaîne de
caractère et ce qui suit va être interprété comme du code SQL. La commande article%' n'existant
pas, cela produit une erreur.

Maintenant, considérons l’URL suivante :

1 http://www.monsite.com/article.php?titre=article’ AND 1=1 --

La requête SQL est la suivante :

1 SELECT id, titre, texte FROM articles WHERE titre=article AND 1=1 -- LIKE ‘%article%’;

Dans ce cas, il n’y a aucune erreur et l’article s’affiche. La commande « AND 1=1 » existe, donc
cette dernière sera interprêtée. Le AND exige que les 2 conditions renvoient TRUE pour que le tout
le soit. Ici, supposons que « article » existe donc retourne TRUE, « 1=1 » renvoie aussi TRUE car
1 est toujours égale à 1. La requête entière retourne donc TRUE.

Remarque : Le symbole « -- » à la fin de la requête fait en forte que la partie qui se trouve après soit
commentée et donc ne sera pas interprétée

Ceci étant dit la requête est syntaxiquement juste et la présence ou l'absence de résultat nous prouve
que le code SQL a bien été exécuté et qu'il est donc possible d'en injecter afin de détourner la requête
initiale.

16
 Injection SQL sur un nombre
Soit la requête suivante (Requête initiale):

1 $query = "SELECT id, titre, texte FROM articles WHERE id = ".$_GET['id'];

Cette requête va afficher l'article correspondant à l'id qu'on lui a passé en paramètre.

http://www.monsite.com/article.php?id=1

La requête correspondante est la suivante :

1 SELECT id, titre, texte FROM articles WHERE id = 1;

La principale différence avec une injection sur une chaîne de caractères réside dans le fait qu'un
nombre n'a pas forcément besoin d'être entouré de guillemets (bien qu'il puisse l'être). Le pirate n'a
donc ici plus besoin de chercher à fermer la chaîne. Il peut directement injecter du code SQL après
l'identifiant.

Voici un exemple d’injection:

1 http://www.monsite.com/article.php?id=1 AND 1=2 --

Ce qui donnera :

1 SELECT id, titre, texte FROM articles WHERE id = 1 AND 1=2 --

Aucun guillemet n'a été utilisé et la requête a bien été exécutée.

1.2.2 Remote file inclusion (RFI) et Local file inclusion (LFI)

RFI et LFI sont des types de vulnérabilités trouvées le plus souvent sur des sites web. Ils permettent
à un attaquant d'inclure un fichier distant ou sur la machine hôte du serveur web. La vulnérabilité
est due à l'utilisation de l'entrée fournie par l'utilisateur sans validation adéquate. Elle peut conduire
à:

 L'exécution de code sur le serveur web

 L'exécution de code sur le côté client comme le JavaScript qui peut conduire à d'autres attaques
comme Cross-site scripting (XSS)
 Déni de service (DoS)
 Le vol de données / Manipulation

Remarque : Dans ce mémoire, le langage de script utilisé sera PHP mais il est à noter que les attaques
RFI peuvent se produire avec n'importe quel langage de script (ASP, JSP, PHP...).

17
 Identification de la faille RFI et LFI
Il faut toutefois savoir que la vulnérabilité d’une application web au RFI/LFI découle directement
d’une fonctionnalité de PHP permettant de traiter des fichiers via une URL.

Ces options se retrouvent dans le fichier « php.ini » (voir Annexe 4) du serveur web Apache:

Figure 1.09: php.ini

Exploitation de la faille RFI

Le script PHP suivant est un exemple vulnérable à la faille RFI

Dans cet exemple, l’utilisateur est censé donner un fichier en entrée. L’url envoyée au serveur est
donc censé être la suivante :

Le script ne dispose pas de procédure de validation de type d’entrée. Un individu mal intentionné
pourra donc inclure une url pointant vers un fichier malveillant qui sera exécuté après sa
récupération.

Le code contenu dans le fichier scriptdangereux.php sera exécuté par le serveur.

Pour LFI, il suffit d’inclure un chemin se trouvant sur le serveur web du site dont voici un exemple.

Si le site est vulnérable, le contenu du fichier passwd devra s’afficher.

18
1.2.3 Cross-site scripting (XSS)
Les attaques de type Cross-Site Scripting (notées parfois XSS ou CSS) sont des attaques visant les
sites web affichant dynamiquement du contenu utilisateur sans effectuer de contrôle et d'encodage
des informations saisies par les utilisateurs. Les attaques Cross-Site Scripting consistent ainsi à
forcer un site web à afficher du code HTML ou des scripts saisis par les utilisateurs.

Grâce aux vulnérabilités Cross-Site Scripting, il est possible à un pirate de récupérer par ce biais les
données échangées entre l'utilisateur et le site web concerné. Le code injecté dans la page web peut
ainsi servir à afficher un formulaire afin de tromper l'utilisateur et lui faire saisir par exemple des
informations d'authentification.

Soit le code html suivant :

Ce bout de code affichera un simple formulaire demandant un nom sur le navigateur de l’utilisateur,
comme le montre l’image suivante :

Figure 1.10 : Rendu du formulaire

Un utilisateur normal saisira son nom, puis le voit affiché sur la page suivante :

Figure 1.11 : Page d’affichage du nom

19
Maintenant, au lieu de saisir un nom, le code suivant sera saisi à la place du nom puis validé:

Figure 1.12 : Page modifiée

En validant l’entrée, la page suivante affiche le texte en gras et en rouge. Ce qui veut dire que le
code entré a été exécuté et donc la page présente bien une faille XSS.

En général, on distingue deux types d’attaques XSS :

 Reflected XSS (non persistante) :

Les données sont envoyées par un client et sont affichées telles quelles dans la page résultante sans
être encodées en entités HTML.

Figure 1.13 : Les étapes d’une attaque XSS non persistante

 Stored XSS (persistante) :

Lorsque des données sont fournies depuis une source de données quelconques (BDD, fichiers, etc.)
et sont affichées telles quelles dans la page résultante sans être encodées en entités HTML. L’impact
d’une XSS stockée est d’autant plus grave car elle touche tous les visiteurs de la page piégée.

20
 Figure 1.14 : Les étapes d’une attaque XSS persistante

Remarque : La faille est d’autant plus grave si la saisie utilisateur est enregistrée en base de données
(ex: saisie d’un commentaire). En effet, le navigateur de chaque visiteur interprétera le code
malicieux sur la page infectée, il s’agit ici d’une XSS stockée (stored XSS).

Conclusion
Pour conclure, ce chapitre nous à permit d’avoir un aperçu des premiers éléments essentiels assurant
la sécurité des systèmes d’information, mais aussi de constater les risques sur internet, malgré les
mesures de sécurité pouvant être adoptées. Les pirates informatiques disposent d’une multitude
d’outils et de techniques devant être étudiés et contrées, ce qui nous amène au chapitre suivant.

21
 CHAPITRE 2

LES HONEYPOTS

Présentation
2.1.1 Historique
Le concept de Honeypot a été évoqué pour la première fois dans les années 1990 dans le livre de
l’ancien astronome Clifford Stoll intitulé, « The Cuckoo's Egg » [9]. Dans ce livre, il montre
comment il a créé un Honeypot de fortune le permettant de surveiller les intrusions dans le réseau
du laboratoire Lawrence Berkeley. L’idée lui est venue en remarquant plusieurs erreurs de
comptabilité causées par une intrusion dans le système informatique du labo. En tant
qu’administrateur réseau du laboratoire, Mr Clifford Stoll avait accès à quasiment tout le système.
A partir d’une machine piégée fournissant de fausses données à l’intrus, Clifford arrive à le garder
suffisamment longtemps en ligne pour pouvoir l’identifier et alerter la police. C’est de là que vient
l’idée de Honeypot ou pot de miel. Le 7 janvier 1991, Bill Cheswick implante et déploie le premier
Honeypot au sein des laboratoires de la division de recherche informatique et scientifique de AT&T
(American Telephone & Telegraph).

Quelques années plus tard, la technologie Honeypot devient de plus en plus évoluée. Des outils plus
sophistiqués sont développés, notamment : CyberCop en 1998 (Le premier Honeypot commercial),
Honeyd en 2002, Honeydrive, Cuckoo Sandbox et plusieurs autre projets.

Actuellement, le domaine des Honeypots se rue vers des projets plus complexes comme le Honeynet
Project qui se développe d’une manière très rapide depuis sa première apparition en 1999, et qui est
actuellement installé au niveau de plus de vingtaine de projets distribués sur plus de quinzaine de
pays du monde.

En 2004, des Honeypots virtuels ont été introduits permettant à plusieurs Honeypots de fonctionner
sur un seul serveur

2.1.2 Définition
 Définition 1 :

Un Honeypot est une ressource de l’architecture de sécurité dont le but est de se faire passer pour
une cible réelle afin d’être sondée, attaquée ou compromise. Autrement dit, les Honeypots sont des

22
machines de production destinées à attirer les pirates. Ceux-ci, persuadés d’avoir pénétré le réseau
ont tous leurs faits et gestes surveillés.

 Définition 2 :

Dans le jargon de la sécurité informatique, un Honeypot (en français pot de miel) est une méthode
de défense active qui consiste à attirer, sur des ressources (serveur, programme, service), des
adversaires déclarés ou potentiels afin de les identifier et éventuellement de les neutraliser.

2.1.3 Intégration du Honeypot dans la politique de sécurité du système d’information

La sécurité des réseaux informatiques devient un problème dès lors qu'on se connecte à

Internet, que ce soit par le biais d'un réseau d'entreprise ou par son FAI. Il faut alors faire face aux
tentatives d'intrusion, au déni de service, aux vers, aux virus... Des contre-mesures ont été créées
pour détecter les attaques ou les éviter. Ces systèmes sont basés sur des choses connues: techniques
d'attaques, failles etc. Afin de mieux combattre les attaquants, il faut apprendre à les connaître :
quelles sont leurs habitudes, quels outils utilisent-ils, que recherchent-ils? Si de tels facteurs sont
connus, les contre-mesures pourront être plus efficaces et de nombreuses attaques évitées.

D’après ce qui a été vu dans la partie « la notion de politique de sécurité » (Chapitre I – 1.1.1), La
politique de sécurité met en place des mécanismes permettant de garantir des services en termes
d'intégrité, de confidentialité, d'authentification, d'identification, de disponibilité et de contrôle
d'accès.

La spécificité du Honeypot réside dans le fait que le système est volontairement présenté comme
« non sécurisé » mais capable de retenir l'attention d'une personne mal intentionnée.

L'utilisation d'un tel système permet de définir un nouveau service en termes de sécurité: la
désinformation.

On distingue deux approches dans le déploiement d'un Honeypot :

 Confinement externe: se protéger contre les menaces externes.

 Confinement interne: se protéger contre les menaces internes :
- Lorsque les premiers mécanismes de sécurité sont déjoués ou compromis.
- Lorsque les attaques proviennent de zones normalement considérées sûres.

Dans tous les cas le confinement doit être imperméable: le Honeypot doit servir la politique de
sécurité et non y nuire.

23
 Les types de Honeypot
Selon son but principal, les Honeypots peuvent être divisés en deux catégories distinctes : Honeypot
de production et Honeypot de recherche.

2.2.1 Honeypot de production

Un Honeypot de production est utilisé pour sécuriser un réseau opérationnel. Il déroute les attaques
orientées vers les différents services de production du système, en les attirant vers lui, ce qui permet
de réduire le risque, en renforçant la sécurité qui est assurée par les autres mécanismes de sécurité
comme les firewalls, les IDS (Systèmes de Détections d’Intrusions), etc. Comme il peut aussi
détecter des attaques grâce à ses fichiers d’audit, qui peuvent être aussi utilisés pour corriger les
vulnérabilités.

Le but des Honeypots de production est d'émuler de vrais systèmes de production permettant aux
pirates de dépenser du temps mais aussi des ressources afin d'étudier la manière dont ils exploitent
les vulnérabilités dans les environnements de production. Les Honeypots de production émulent
principalement des services spécifiques et parfois des systèmes d'exploitation pour attirer des
attaquants. Ils peuvent également émuler différents backdoors, virus et trojans. Par exemple, pour
examiner les attaques sur les serveurs web, un Honeypot de production émulant un serveur web et
des faux services peuvent être déployés.

Un Honeypot de production joue un rôle important dans une ou plusieurs composantes de la sécurité
du système de production telles que :

 La prévention
 La détection
 La réaction

La prévention
Les Honeypots de production s'ajoutent aux capacités de prévention en fournissant des données
permettant de déterminer les manières dont un pirate peut pénétrer dans le réseau et accéder aux
ressources critiques de l'organisation. En analysant les attaques sur le Honeypot, il est possible de
déterminer les vulnérabilités exploitées par le pirate pour compromettre le Honeypot. Ces
vulnérabilités pouvant être présentes sur les systèmes réels, elles pourront ensuite être patchées pour
protéger ces systèmes des futures attaques. Les Honeypots de production permettent aussi aux
entreprises et organisation de connaitre les ressources que les pirates recherchent. Ainsi, ils pourront

24
adopter de meilleures pratiques telles que la désactivation de services non sécurisés, la correction
des failles exploitables, et l’utilisation de mécanismes d’authentification plus performants.

La détection
Les Honeypots de production ajoutent une valeur considérable à la capacité de détection de
l'organisation à laquelle ils sont destinés. Souvent, les entreprises sont tellement submergées par
leurs activités de production, qu'elles négligent le temps mais aussi les ressources nécessaire à la
surveillance des fichiers journaux (logs). Même s'il leur arrive de les contrôler, cela ne suffirait pas
à détecter complètement les attaques vu que les logs générés par les technologies de sécurité
souffrent souvent de faux positifs et de faux négatifs.

Les Honeypots de production sont conçus de telle sorte qu'il n'y ait pas de faux positifs ou très peu
car toutes les activités sur les pots de miel de production sont tous considérées comme dangers
potentiels, ce qui fait que tous les logs sont pertinents, importants et révèlent des problèmes, des
attaques ou des tentatives. Il en est de même pour le risque de faux négatifs, lorsque les IDS
n’arrivent pas à détecter les attaques. Certaines attaques sont aussi bien camouflées que la plupart
des systèmes de sécurité n’arrivent pas à les détecter. Le pot de miel, quant à lui gère très bien ce
problème car il arrive à détecter toute connexion qui lui est faite de manière cachée ou non en se
référant à l'activité du système virtuel mais pas à des signatures comme les IDS le font.

La réaction
Souvent, après qu'un système est compromis dans un environnement de production, les données ne
sont plus fiables. Ces données ne peuvent donc être utilisées pour d'autres analyses, rendant plus
difficiles, la détection et la recherche des preuves de l'attaque. Le deuxième défi auquel une
organisation est confrontée après un incident est que les systèmes compromis ne peuvent être
déconnectés immédiatement du réseau parce qu'ils peuvent affecter tout le processus de production
et que les services qu'ils offrent ne peuvent être facilement remplacés. L'équipe d'intervention en cas
d'incident aura donc des difficultés à mener une analyse criminalistique appropriée et à étudier le
système.

Les Honeypots de production permettent d’éliminer ces problèmes. Il n’y a pas de compromission
de données car ils ne contribuent pas à la chaine de production de l’entreprise et peuvent être
déconnectés sans problème.

Cependant, si un Honeypot était utilisé pour émuler le serveur de production avec des vulnérabilités
connues, alors les chances qu'il soit piraté seraient très élevées. Ceci à son tour aiderait l'équipe

25
d'intervention à mener une analyse médico-légale complète et à saisir les preuves comme preuve
légale.

2.2.2 Honeypot de recherche

Ce sont des outils complexes visant à collecter énormément d'informations sur les attaquants et leurs
méthodes. Ils ne sont pas directement chargés de la défense de l'entreprise, mais plutôt de découvrir
les dangers auxquels la société pourra et devra faire face dans le futur: qui sont les attaquants, quelles
sont leurs méthodes d'attaques, quels outils utilisent-ils, où ont-il trouvé ces outils etc. Ces
connaissances vont permettre à l'entreprise de mieux préparer ses systèmes de défense [11].

Le Honeypot de recherche s'inscrit donc dans une démarche à moyen ou long terme:

 Analyser avec précision les méthodes d'intrusion et de compromission utilisées par les
communautés de « hackers ».
 Corrélation des informations obtenues

Les Honeypots de recherche sont plus complets que les Honeypots de production. C’est en général
le système en entier qui peut être attaqué (et non pas seulement un seul service), ce qui en fait des
systèmes sensibles dans leur gestion et complexes pour l’analyse de leurs résultats.

2.2.3 Classification des Honeypot

Il existe trois catégories différentes de pots de miel disponibles aujourd'hui, faible interaction,
moyenne interaction et haute interaction. Ces catégories sont définies en fonction des services, ou
niveau d'interaction, fournis par le pot de miel aux pirates potentiels.

Honeypots à faible interaction

Un Honeypot à faible interaction est un Honeypot virtuel fournit comme le montre son nom une
interaction limitée (faible) avec le pirate, il est tout simplement un programme qui simule les services
d’un système réel par la mise en place par exemple des sockets d’écoute sur chaque port d’un service,
ces sockets ne font que logger les différents paquets qu’ils reçoivent comme le montre la figure
suivante :

26
 Figure 2.01 : Fonctionnement d’un Honeypot à faible interaction.

Le but principal de ce type de Honeypots est la détection des tentatives de connexions non autorisées.
Donc ce type est sans doute le plus utilisé dans les Honeypots de production.

Avantages
 La mise en place est très simple.
 La gestion complexe des logs du système est éliminée.
 La sécurité du système est conservée (mais uniquement s’il est bien configuré et que les faux
services implémentés ne possèdent pas eux même un trou de sécurité).

Inconvénients
 Sont faciles à détecter par les attaquants à cause d’absence de réponses attendues dues à
l’implémentation incomplète des services.
 Peu d’informations sur l’attaquant sont dérivées (le temps et la date d’attaque, adresse IP
(Internet Protocol) source et adresse IP destination de la connexion, port source et port
destination de la connexion), car le Honeypot n’offre aucune possibilité au pirate de s’introduire
dans le système.

Honeypot à moyenne interaction

Un Honeypot à moyenne interaction est un Honeypot semi-virtuel qui assure une simulation
améliorée des services d’un système par rapport à la simulation fournie par les Honeypots à faible
interaction, en lui ajoutant la possibilité de renvoi des réponses aux attaquants, ces réponses sont
généralement fausses de façon à leur donner des pistes ou à les dérouter sans forcément les intriguer,
comme le montre la figure 2.02. En plus des services simulés, il offre aussi quelques services réels,
mais sans donner la possibilité au pirate de prendre un contrôle total du système.

27
 Figure 2.02 : Fonctionnement d’un Honeypot à moyenne interaction

Avantages
 La gestion des logs du système est facile par rapport à celle des Honeypots à haute interaction et
un peu difficile par rapport à celle des Honeypots à faible interaction.
 Fournit beaucoup plus d’informations intéressantes à analyser, à cause de variété d’attaques
proposées aux pirates, ce qui s’avère plus intéressant pour eux.

Inconvénients
 Très dur à implémenter en terme de développement, car la fourniture d’un leurre parfait implique
une parfaite connaissance des protocoles de chaque faux service pour bannir toute faille de
sécurité.
 Sécurité du système difficile à contrôler, du fait que, plus le niveau de complexité d’un Honeypot
augmente, plus il y a de chance qu’il contienne lui-même un trou de sécurité qui peut être
exploité par le pirate.

Honeypots à haute interaction

Contrairement aux deux types précédents, les Honeypots à forte interaction ne sont pas basés sur
l’émulation de services ou de systèmes d’exploitation. Au contraire, ils reposent sur un vrai système
d’exploitation où de véritables services, vulnérables ou non, tournent et sont accessibles aux pirates.
Ainsi, la méthode d’approche est complétement différente puisque l’on offre au pirate la possibilité
de rentrer dans le système et de faire ce qu’il lui plaît une fois le système compromis.

Le fonctionnement général de ce type de Honeypot est illustré par la figure 2.03.

28
 Figure 2.03 : Fonctionnement d’un Honeypot à forte interaction

Le but est donc de contrôler les faits et gestes du pirate sans se faire démasquer. C’est le type
d’Honeypot le plus déployé pour faire de la recherche puisque ce sont les seuls qui permettent de
réellement d’étudier le comportement des pirates mais ce sont également les plus difficiles à
administrer. Différentes méthodes pour contrôler et capturer les données ont été élaborées par
l’organisation "The Honeynet Project". Ces méthodes seront abordées dans une autre partie de ce
mémoire.

Avantages
 Très difficile à détecter par les pirates.
 Fournit beaucoup d’informations sur les activités du pirate.

Inconvénients
 Introduit un grand risque dans le système hôte, à cause de la pénétration du pirate au système
réel avec une liberté totale, ce qui puisse engendrer une réinstallation périodique du système.
 La réactivité du monitoring est un facteur de complexité important.
 La gestion des logs est très compliquée (transférer les informations capturées sur le pirate à un
log distant sans se faire repérer par les attaquants).

Mise en place des Honeypots

Lors du déploiement des Honeypots, une des questions essentielles est de déterminer le meilleur
emplacement. Selon que le système est destiné à surveiller les attaques extérieures ou bien internes
au réseau de l’organisation, il existe trois positions possibles pour installer un Honeypot:

29
 Devant le pare-feu (ou "firewall")
 Dans une zone démilitarisée (DMZ)
 Derrière le pare-feu

2.3.1 Honeypot placé devant le pare-feu

Figure 2.04 : Honeypot installé devant le pare-feu

Cette position n’augmente pas le risque de compromission du réseau interne, le système de

Honeypot générera beaucoup de trafic et récoltera de nombreuses informations sur les modèles
d’attaques. Le principal avantage qui peut porter à choisir cette position est qu’il n’y a aucun
changement à faire au niveau des règles de filtrages du pare-feu qui protège le réseau interne et que
cette localisation n’introduit pas de nouveaux risques pour les machines du réseau interne. Le
désavantage est qu’il ne permet pas de détecter les attaques menées depuis l’intérieur du réseau
puisque généralement les flux sortant sont bloqués par le pare-feu.

30
2.3.2 Honeypot placé dans une DMZ

Figure 2.05 : Honeypot installé dans une DMZ

Cette position du Honeypot permet de pallier le défaut de la première position. Elle consiste à placer
un Honeypot dans une zone démilitarisée. L’intérêt de la DMZ est qu’elle permet de surveiller les
serveurs publics sur Internet de façon isolée du réseau interne. Cette DMZ peut être utilisée pour les
serveurs de production ou bien dédiée au Honeypot comme le montre la figure 2.05.

Dans le premier cas, le pare-feu laisse seulement passer les flux entrant vers la DMZ pour les
services disponibles. Ce qui permet d’analyser uniquement les tentatives d’attaques pour les services
en questions.

Dans un second cas, on peut envisager deux stratégies différentes.

31
 1ère stratégie
Elle a attribué une adresse publique au Honeypot (Figure 2.07) ; cette stratégie possède les avantages
suivants :

 Intégration facile du Honeypot au niveau du Firewall.

 Permet au Honeypot d'implémenter tous les services souhaités.
 Le risque de faux positifs est nul ; le trafic qui arrive sur le Honeypot est forcément suspect

Néanmoins, cette stratégie a l’inconvénient d’utiliser une (ou plusieurs) adresse(s)

publique(s) dédiée(s).

197.149.54.2

197.149.54.3

197.149.54.1

Figure 2.07 : Honeypot installé dans une DMZ dédiée – adressage publique

2ème stratégie
Elle attribue une adresse privée au Honeypot; tous les flux applicatifs non gérés par les serveurs de
production seront redirigés vers le Honeypot.

32
 197.149.54.10

192.168.1.2

192.168.1.3

192.168.1.1

Figure 2.08 : Honeypot installé dans une DMZ dédiée – adressage privé

Cette stratégie partage les mêmes avantages avec la première, tout en évitant le gaspillage
d’adresse(s) IP. Elle possède les inconvénients suivants :

 Le Honeypot n’est utilisé que pour certains types de services.

 Intégration plus compliquée ; la redirection et la translation vers le Honeypot se font uniquement
pour les services non gérés par les serveurs de DMZ1.

Une autre alternative de cette stratégie consiste à placer un IDS (Figure 9) et de rediriger les flux «
suspectés » par l’IDS vers le Honeypot via une règle de NAT sur le firewall comme le montre la
figure 2.09. Une adresse IP publique est attribuée à l’interface externe du firewall/IDS

33
 197.149.54.10

192.168.1.2

192.168.1.3

192.168.1.1

Figure 2.09 : Honeypot installé dans une DMZ dédiée derrière un IDS

2.3.3 Honeypot placé derrière un firewall

La dernière position (Figure 2.10) possible pour un Honeypot est derrière le pare-feu dans le réseau
interne. Dans le cas où le système Honeypot est utilisé pour détecter les attaques extérieures, cela
peut induire des risques de vulnérabilités plus importantes puisqu’une fois compromis, le Honeypot
pourra être utilisé par l’attaquant pour lancer d’autres attaques sur le réseau interne. D’autre part, le
pare-feu devra être configuré correctement pour laisser passer les flux entrants destinés au Honeypot.
En fait, le principal avantage de positionner un Honeypot derrière le pare-feu est qu’il permet de
détecter les attaques provenant des utilisateurs internes à l’organisation vers des services internes ou
bien de détecter une mauvaise configuration du pare-feu.

34
 Figure 2.10 : Honeypot installé derrière un pare-feu

Les Honeynets
2.4.1 Définition
Un Honeynet n’est autre qu’un réseau de systèmes Honeypots combiné avec un ensemble de
mécanismes de sécurité comme les firewalls, les IDS, les serveurs log, ...etc. Il donne apparence à
tout un environnement de production avec des failles et des informations pertinentes utilisées comme
appât pour attirer et piéger les attaquants afin de surveiller et d’enregistrer ensuite toutes leurs
actions. Sa structure de réseau permet même d’avoir des renseignements sur les communications
entre les attaquants et leurs méthodes de collaboration. A cause de la richesse des informations
collectées par lui, un Honeynet est considéré comme un outil très utile pour apprendre plus sur les
techniques d’attaques, et les comportements des attaquants, sur un réseau réel.

2.4.2 Le concept de capture et de contrôle des données

Il y a deux principes essentiels concernant le bon fonctionnement d'un Honeynet. Ces deux principes
sont le concept de capture de données et de contrôle des données. Ces deux principes doivent être
respectés pour que le Honeynet puisse être utilisé avec succès dans la protection d'un réseau.

35
Toutes les informations qui entrent ou sortent du Honeynet doivent être collectées pour être
analysées. Ces données doivent être collectées à l'insu des personnes qui mènent des activités
malveillantes contre le réseau à protéger. Les données collectées doivent être stockées dans un
emplacement différent du Honeynet. Ceci est fait de telle sorte que si le pirate compromet un système
Honeynet, les données ne peuvent être détruites ou modifiées. Le but est d'être capable de collecter
des données sur le pirate sans qu’il ne s’en rende compte.

Le principe de contrôle des données se porte sur la protection des autres réseaux d'être attaqués et
compromis par les ordinateurs du Honeynet. Si un pirate informatique compromet un système
Honeynet, il est impératif de l’empêcher d'utiliser ce système pour attaquer les systèmes de
production sur d'autres réseaux. Le processus de contrôle des données doit être automatisé afin
d’éviter que le pirate prenne conscience du fait que le système qu'il a compromis est sur un Honeynet
[12].

2.4.3 Architecture des Honeynets

Les architectures des Honeynets utilisées actuellement sont classifiées en trois générations, chacune
de ces générations se distingue principalement par l’architecture réseau mise en place pour assurer
les trois fonctionnalités du Honeynet (contrôle de données, collecte de données, analyse de données).

1ère génération
L’architecture de cette génération est une architecture multicouches, dont le contrôle et la capture
de données sont assurés par plusieurs dispositifs distincts (plusieurs couches : routeur, pare-feu,
IDS). Autrement dit, le routeur, le pare-feu et l’IDS de cette génération sont des éléments
indépendants comme le montre la figure 2.11.

36
 Figure 2.11 : Honeynet de 1ère génération

Dans cette architecture le contrôle de données est assuré par :

 Le firewall (la première couche) qui limite le nombre de connexions entrantes,

 Le routeur (la deuxième couche) qui limite toute connexion vers l’internet et cache le firewall
du réseau intérieur.
 Tandis que la capture et la collection des données sont assurées par :
 Le firewall (la première couche) qui garde un journal de toutes les connexions de l’Internet et
du Honeynet,
 L’IDS (la deuxième couche) qui garde aussi un log de toutes les activités du réseau de Honeynet.
(Il est accessible depuis le réseau de production mais non pas depuis le Honeynet),
 Les Honeypots (la troisième couche) qui exploitent les journaux du système (système logs).

Dans cette architecture, la panne d’une entité ne stoppe pas la surveillance et la capture des données.
Par contre, l’administration du système se montre un peu plus ardue à cause de la complexité de
l’architecture réseau.

37
 2ème génération
Dans cette architecture, les opérations de capture, de contrôle et d’analyse des données se fait par
une seule entité appelée « Honeywall ». Ce dispositif, est configuré en mode bridge (pont), le
permettant de fonctionner sur les deux couches basses du modèle OSI (Liaison et physique) ce qui
le rend difficilement détectable par les pirates, car il n’a pas d’adresse IP et il ne décrémente pas le
champ TTL (Time To Live). Le but du Honeywall est de router le trafic malveillant destiné au réseau
de production vers le réseau de Honeypots, contrôler et capturer des données relatives à ce trafic.
Dans cette architecture le contrôle de données est assuré par les deux modules IPTable et
Snort_Inline du Honeywall, le IPTable est utilisé comme une première couche qui permet de limiter
le nombre de trafic sortant du Honeynet, tandis que le Snort_Inline est utilisé comme une deuxième
couche qui assure la prévention des attaques connues (il bloque le trafic sortant lorsqu’il détecte une
attaque connue). La même chose pour la capture de données, elle est assurée au niveau de trois
couches du Honeywall : IPTable firewall, Sniffer, et Sebek. Sebek est un outil très important pour
capturer les données encryptées, ces derniers sont capturés au niveau des Honeypots par les clients
Sebeks, qui les envoient ensuite au Sebek server du Honeywall via un canal UDP.

Cette génération a permis d’améliorer les capacités des honeynets, mais ils restent toujours difficiles
à employer et à maintenir, à cause du nombre élevé de configurations requises (configuration des
Snort_Inline, Sebek, IPTables, ...etc.).

Figure 2.12 : Honeynet de 2ème génération

38
 3ème génération
L’architecture de la troisième génération a été conçue principalement pour régler le problème de la
difficulté de déploiement, de gestion et de maintenance des Honeynets de la deuxième génération,
en intégrant de nouveaux outils nécessaires pour la collection et l’analyse de données avec tous les
outils utilisés par le Honeywall de la deuxième génération dans un seul CD Bootable facile à installer
et à configurer. La première version de ce CD est appelée Eeyore. Cette version a été améliorée
ensuite (en 2005) à une nouvelle version appelée "Honeynet ROO CDROM". Les outils de contrôle
de données collectés dans ce CD sont les mêmes que ceux de la deuxième génération (IPTable,
Snort_Inline), tandis que ceux de capture et de collecte de données sont renforcés par de nouveaux
outils comme p0f et Argus. P0f est utilisé pour découvrir le système d’exploitation de la machine
du pirate et de celle attaquée, et Argus est un outil plus puissant dans le rapatriement d’informations
sur les échanges de données par le réseau. Argus permet de connaître l’heure de début et de fin d’une
connexion, le nombre d’octets et le nombre de paquets transmis dans chaque direction (cas d’une
connexion TCP bidirectionnelle). Le CDROM Honeywall contient aussi un outil en script Perl
appelé Hflow qui fusionne toutes les données récupérées par les outils de collection dans une base
de données centrale. L’analyse de données de cette génération a été aussi renforcée par une interface
web graphique appelée "walleye" qui peut être lancée à distance via une connexion web sécurisée
(https).

2.4.4 Les Honeynets virtuels

Dans un Honeynet virtuel, tout le système se réduit à deux machines, voire une seule. Bien que ce
dernier soit simple à déployer, l'architecture de la machine restreint la variété des services installés
dessus. D’autre part, la machine risque des attaques (dont le fingerprinting) pouvant entraîner la
perte du Honeynet dans son ensemble. Les Honeynets virtuels se servent d’un logiciel de
virtualisation (« Virtualization Software »), permettant de faire fonctionner plusieurs systèmes
d’exploitation sur un même matériel.

Il existe deux sous-types de Honeynets virtuels [13]:

 Honeynet purement virtuel (Self-Contained Virtual Honeynet)

 Honeynet virtuel hybride

Self-Contained Virtual Honeynet

Un Honeynet virtuel autonome est un réseau Honeynet entier condensé sur un seul ordinateur.
L'ensemble du réseau est virtuellement contenu sur un seul système physique. Un réseau Honeynet

39
se compose généralement d'une passerelle de pare-feu pour le contrôle des données et la capture de
données, ainsi que des pots de miel dans le Honeynet. Ce type de Honeynet est représenté par la
figure 2.13. Les Honeypots sont représentés par les « guest OS ». [14]

Figure 2.13 : Représentation simplifiée d’un Honeynet purement virtuel

Voici les avantages de ce type de Honeypot virtuel:

 très portable, ils peuvent être placés sur un ordinateur portable et branchés n'importe où.
 le déploiement est beaucoup plus facile, il ne suffit de connecter qu’un seul system au réseau.
 économique en termes de cout et d’espace, un seul ordinateur suffit.

Cependant, des limitations importantes doivent aussi être tenues en considération:

 N’importe quel problème matériel affecte tout le système Honeynet.

 La compromission du système hôte, implique la compromission de la totalité du système
Honeynet.
 La virtualisation d’un grand nombre de systèmes clients nécessite un hôte très performent.

Honeynet virtuel hybride

Dans cette classe de Honeynets virtuels, les dispositifs de contrôle et de capture des données sont
déployés sur une machine séparée de celle des Honeypots, ce qui permet d’éviter le problème de
compromission de tout le Honeynet au cas où un hacker parvient à prendre contrôle de l’hôte.

40
Cependant, tous les pots de miel sont pratiquement virtualités sur un seul système. La figure 2.14
montre l’architecture générale de ce type de Honeynet [15].

Figure 2.14 : Honeynet virtuel hybride

D’après la figure ci-dessus, le Honeynet est réparti sur deux machines physiques. La première
machine le « Honeynet gateway » s’occupe du contrôle et de la capture des données tandis que la
seconde machine va servir de système hôte aux Honeypots (Guest OS).

Les avantages de cette configuration sont :

 La sécurité: Contrairement aux Honeynets purement virtuels, il y a un risque qu'un attaquant

atteigne les autres parties du Honeynet (comme le pare-feu). Ici, le seul danger serait que
l'attaquant accède aux autres Honeypots.
 La flexibilité: il est possible d’utiliser une multitude de logiciels et de matériels pour les
éléments de contrôle et de capture de données du réseau Hybrid.
 Les inconvénients de cette configuration sont:
 La non portabilité due à l’utilisation de deux ou plusieurs machines.
 L’implémentation est plus couteuse, occupe d’espace, nécessite du temps, mais aussi plus de
ressources en termes d’énergie.

41
 Conclusion
En guise de conclusion, ce chapitre nous a permis d’en savoir beaucoup plus sur les Honeypots mais
aussi des Honeynets qui ne sont en fin de compte qu’un ensemble de dispositif de sécurité couplé à
un ou plusieurs Honeypots. Il est maintenant question de savoir comment l’implémenter dans un
environnement représentant les cas réels, ce qui va nous emmener au chapitre suivant.

42
 CHAPITRE 3

DEPLOIEMENT D’UN HONEYPOT DANS UN RESEAU D’ENTREPRISE

Présentation du projet
Le but de ce mémoire consiste à identifier les attaques et les ressources qui intéressent les pirates
informatiques afin de mieux sécuriser les infrastructures et les données dans un réseau d’entreprise.
En plus de cela, le Honeypot permettra aussi de récolter des informations sur les pirates responsables
des attaques. Afin de mettre en œuvre tout ce processus, ce mémoire proposera une émulation d’un
réseau d’entreprise et simulera les attaques couramment observés sur le web. La figure 3.15
représente l’architecture finale du réseau

Figure 3.01 : Architecture du réseau

43
 Les ressources requises
Pour émuler l’architecture réseau présenté dans la figure 3.15, des ressources matérielles et
logicielles sont requises.

3.2.1 Ressources matérielles

La seule ressource matérielle utilisée dans ce projet est un ordinateur, mais toutefois, l’émulation
d’une telle architecture requiert une quantité minimale de mémoire vive et de nombre de cœurs à ne
pas négliger pour le bon fonctionnement de la partie logicielle.

La configuration minimale requise est la suivante :

 RAM : 8Go ou plus

 Processeur : core i3 ou plus

3.2.2 Ressources logicielles

L’élément principal est d’abord un système d’exploitation. L’OS utilisé ici est Windows 10 mais il
est également possible d’utiliser des distributions Linux ou MacOs. Les logiciels suivant
s’occuperont de la simulation du réseau :

 GNS3 : Ce logiciel, permet de créer des architectures réseau, de les tester et même de connecter
une architecture à un réseau réel. Des bases GNS3 ne disposent pas de matériel réseau comme
les routeurs ou les firewalls mais toutefois, ils sont téléchargeables sur le web.
 VMware Workstation : Il permet de créer des machines virtuelles et de les exécuter en même
temps au-dessus d’un système d’exploitation hôte.
 L’architecture comprend en tout trois systèmes d’exploitation virtualités sur Vmware dont
Debian 8 qui servira de serveur web, Ubuntu server 14.04 qui va servir d’hôte au Honeypot et
Kali linux sera utilisé pour simuler les attaques informatiques.
 Le Honeypot web Glastopf : Glastopf est une solution évolutive de Web Honeypot capable de
s’adapter dynamiquement aux attaques inconnues. Il permet aussi d’émuler des failles telles que
XSS, RFI ou LFI. Glastopf Honeypot sera installé sur Ubuntu server.
 Glastopf Analytics : Cette application sera installée sur le même hôte que le Honeypot afin de
visualiser les données récoltées à partir d’une interface web.
 Le Firewall Cisco ASAv 9.8.1 : Il a pour rôle d’émuler le fonctionnement réel d’un Firewall
Cisco ASA.
 Le routeur Cisco 3725 : Il va émuler le fonctionnement réel d’un routeur Cisco 3725.

44
 Mise en place du réseau de l’entreprise
Dans un point de vue général, l’architecture se divise en trois parties distinctes : Le réseau interne
(INSIDE), les zones démilitarisées (DMZ et DMZH) et le réseau externe (OUTSIDE). Le firewall
est l’élément central qui va gérer la communication entre ces différentes parties du réseau.

3.3.1 Le réseau interne

Le réseau interne ou LAN est la partie qui représente l’environnement de production de l’entreprise.
L’essentiel du travail de l’activité de l’entreprise s’effectue dans cette partie c’est pourquoi, elle se
doit d’être la plus sécurisée possible. Le LAN n’est pas accessible depuis l’extérieur mais les
ordinateurs qui y sont peuvent accéder à internet.

Ici, cette partie va se composer de quelques postes de travail pour les employés (PC-1 à PC-4) et
une imprimante, qui seront connectées entre eux à l’aide du switch-1-1. Une autre partie du LAN
est consacré à l’administration du réseau et aux serveurs utiles aux travaux de production. Cette
deuxième partie du LAN se compose du serveur DHCP qui se chargera d’attribuer des adresses aux
postes de travail et en parallèle à cela, il aura aussi le rôle de serveur DNS qui traduira les URLs
dans l’intranet de l’entreprise. Ensuite il y a le serveur web qui va contenir les applications web de
l’intranet, le serveur de base de données qui va fournir les données utiles aux travaux de production.
Et enfin, il y a le poste de l’administrateur qui aura accès aux différents serveurs afin de gérer tout
le LAN de l’entreprise. Les équipements de cette partie du LAN sont rattachés au switch-1-2. Les
switch 1-1 et 1-2 seront à leurs tours connectés au switch qui est le switch central reliant le LAN au
firewall.

L’ensemble du réseau interne de l’entreprise est résumé dans la figure 3.16

45
 Vers le firewall

Figure 3.02 : Le réseau interne

3.3.2 Les zones démilitarisées (DMZ)

Deux zones démilitarisées ont été mises en place dans cette architecture. La raison est que le
Honeypot sera placé dans une DMZ appart pour plus de sécurité en cas de compromission du
système. La DMZ dédiée à l’Honeypot sera nommée DMZH. C’est une zone qui ne doit pas
communiquer avec les autres zones de l’entreprise.

L’autre DMZ, nommée DMZ tout court sera dédiée à un serveur web sur l’OS Debian 9 qui est ici
un serveur publique, et un serveur de base de données qui fournira des données au serveur web.
Cette zone est accessible depuis l’extérieur, donc accessible depuis internet. Mais toutefois, sur les
deux DMZ, seul le trafic http est autorisé.

La figure 3.17 illustre la topologie des deux DMZ.

46
 Figure 3.03 : Les zones démilitarisées

3.3.3 Le réseau externe

Le réseau externe, qui ne fait plus partie de l’entreprise, représente tout ce qu’il y a après le firewall.
Il comprend donc la partie internet, qui est un ensemble de plusieurs milliers de routeurs, de switchs,
de serveurs et autres équipements liés entre eux. Internet sera représenté par le petit nuage et
connecté à internet, il y a le pirate informatique qui se nommera « hacker » dont le rôle sera de tenter
des attaques sur le réseau de l’entreprise.

Le réseau externe est représenté par la figure suivante :

Figure 3.04 : Le réseau externe

Configuration des différentes entités du réseau

Afin d’assurer le bon fonctionnement du réseau en général, celui-ci devra être configuré selon le
type d’architecture. Il existe une multitude de type d’architecture réseau possible et chacun d’elles
peuvent avoir des configurations toutes différentes. La configuration du réseau est une étape cruciale
dans le déploiement d’un réseau d’entreprise car elle va déterminer la robustesse et la fiabilité du
réseau.

47
3.4.1 Configuration du firewall Cisco ASAv 9.8.1
Le firewall est l’entité qui assure le premier niveau de sécurisation du réseau, c’est pourquoi la
définition des règles doit se faire minutieusement.

Comme il a été vu sur l’architecture du réseau, le firewall dispose de quatre interfaces à configurer
dont :

 l’interface connectée au réseau interne (INSIDE) ;

 l’interface connectée au réseau externe (OUTSIDE) ;
 l’interface connectée aux serveurs dans la DMZ ;
 et l’interface connectée à l’Honeypot dans le DMZH.

Configuration des interfaces

La première étape de la configuration consiste à attribuer des adresses IP aux interfaces et à définir
leur niveau de sécurité.

L’interface « outside » se verra directement attribuée une adresse IP publique (l’annexe 5 donne plus
de détails sur les plages d’adresses privées et publiques) car elle est directement exposée au réseau
externe contrairement aux trois autres interfaces. Cette adresse IP publique est généralement fournie
par l’ISP (Internet Service Provider) et permet à la compagnie de se connecter à internet.

Les configurations des interfaces sont donc les suivantes :

 Interface « inside »

 Interface « outside »

 Interface « dmz »

48
 Interface « dmzh »

Remarques :

 Une interface ayant une valeur « security-level » inférieure ne peut envoyer du trafic à une
interface dont la valeur est supérieure. Une interface de « security-level » égale à 0 ne peut donc
pas faire passer du trafic vers une interface de « security-level » égale à 50, à moins qu’une ACL
ne l’y autorise.
 Une interface ayant une valeur de « security-level » supérieure peut envoyer du trafic à une
interface dont la valeur est inférieure, à moins qu’une ACL l’en empêche
 Le trafic entre deux interfaces de même « security-level » est systématiquement bloqué.

Configuration NAT
Les règles NAT vont permettre aux hôtes du réseau internet, et des DMZ de se connecter à internet.
Puisque les hôtes du réseau internet et des DMZ utilisent des adresses privées qui ne sont pas
routables sur internet (RFC 1918). Dans ce cas, ces adresses doivent être traduites afin qu’ils aient
la même forme que l’adresse de l’interface externe du firewall ASA.

Voici donc, les commandes relatives à ces opérations :

Ces configurations permettent aux adresses des hôtes de l’interface interne d’être traduites
dynamiquement lorsqu’ ils veulent accéder à l’interface externe.

Maintenant que les hôtes du LAN est des DMZ peuvent sortir vers internet, il faudra ensuite autoriser
la partie externe à accéder au serveur web et à l’Honeypot (qui n’est autre qu’un serveur web
configuré pour présenter des failles) via le port 80 (port http). Dans ce scénario, ceux qui veulent

49
accéder aux serveurs web devront se connecter à d’autres adresses IP faisant référence aux serveurs
respectifs, fournies par l’ISP. L’adresse attribuée au serveur web sous Debian sera 197.149.55.100
et celle attribuée à l’Honeypot sera 197.149.55.200. Les utilisateurs normaux d’internet pourront
donc accéder au site web de l’entreprise en se connectant à l’adresse 197.149.55.100 tandis que les
pirates seront plus tentés d’essayer de se connecter à l’adresse 197.149.55.200 qui présente des
failles qu’ils peuvent exploiter.

La configuration va ressembler à ceci :

Remarque : hpserver représente le serveur contenant le Honeypot.

Configuration des ACLs

Comme il a été dit plus haut, les ACLs peuvent outrepasser les règles établies par « security-level ».
Sans les ACLs, le trafic circule selon les règles suivantes :

 Les hôtes qui se trouvent dans inside (security-level 100) peuvent se connecter aux hôtes qui se
trouvent dans dmz et dmzh (security –level 50)
 Les hôtes qui se trouvent dans inside (security-level 100) peuvent se connecter aux hôtes dans
outside (security-level 0)
 Les hôtes dans dmz et dmzh (security-level 50) peuvent se connecter aux hôtes se trouvant dans
ouside (security-level 0)

Par contre :

 Les hôtes qui se trouvent dans outside (security-level 0) ne peuvent pas se connecter aux hôtes
qui se trouvent dans inside (security –level 50)
 Les hôtes qui se trouvent dans outside (security-level 0) ne peuvent se connecter aux hôtes qui
se trouvent dans dmz et dmzh (security –level 50)

50
 Les hôtes de dmz et dmzh (security-level 50) ne peuvent pas se connecter aux hôtes qui se
trouvent dans inside (security –level 100)
 Les hôtes de dmz (security-level 50) ne peuvent pas se connecter aux hôtes qui se trouvent dans
dmzh (security –level 50), et inversement

D’après ces règles, les personnes sur internet ne peuvent pas encore se connecter ni au site web de
l’entreprise ni à l’Honeypot. Il faudra donc autoriser ce trafic. L’adresse IP utilisée dans l’ACL sera
l’adresse privée mais pas l’adresse publique du serveur. Cela signifie que pour le serveur Debian 9,
la configuration doit autoriser le trafic destiné à 192.168.20.2 et NON le trafic destiné à
197.149.55.100 sur le port 80. Et il en est de même pour le Honeypot. Les objets webserver et
hpserver déjà définis dans la configuration NAT seront utilisés dans l’ACL. Il faudra ensuite
appliquer cette ACL sur l’interface inside.

Les configurations se présentent comme suit :

Remarque : A la place de l’adresse source, le mot clé any est utilisé car l’adresse IP du client n’est
pas connue avant qu’il se connecte au serveur.

Dans l’architecture réseau de l’entreprise, un serveur DNS se trouve dans le réseau inside à l’adresse
192.168.1.2. Le serveur web Debian a besoin de s’y connecter pour la résolution des adresses. Le
firewall devra donc autoriser le trafic DNS vers le serveur DNS et bloquer tout autre trafic sur
l’interface dmz.

Les configurations sont les suivantes :

Tout trafic venant de l’Honeypot est implicitement bloqué car aucune ACL ne l’autorise.

51
3.4.2 Configuration du LAN
Malgré le fait que le firewall autorise les hôtes du LAN à accéder à internet, ils ne pourront pas
encore le faire car leurs configurations réseau ne le permettent pas encore. Cette étape permet
d’attribuer les paramètres réseaux aux hôtes.

Attribution d’adresses
L’attribution d’adresse peut se faire de manière dynamique (DHCP) mais aussi manuellement. Un
routeur Cisco s’occupera de l’attribution des adresses des postes des employés avec DHCP tandis
que la partie serveur et administration sera configurée manuellement.

Les adresses seront réparties comme suit :

Adresses IP Hôtes Attribution Description

192.168.1.2 Serveur DHCP & Serveur DNS
192.168.1.3 Administrateur du réseau
192.168.1.4 Serveur de base de données
192.168.1.5 Serveur web
Réservées à l’administration du réseau,
192.168.1.6 Imprimante Manuelle
aux serveurs, et à l’imprimante
192.168.1.7
192.168.1.8
192.168.1.9
192.168.1.10
192.168.1.11 PC-1
192.168.1.12 PC-2
192.168.1.13 PC-3
DHCP Réservées aux machines des employés
192.168.1.14 PC-4
… …
192.168.1.254
Tableau 3.01 : Répartition des adresses IP

Les paramétrages du serveur DHCP sont les suivantes :

52
Les adresse 192.168.1.1 jusqu’à 192.168.1.10 sont exclues à cause du fait qu’elles seront
configurées manuellement.

Il faudra ensuite activer DHCP sur les postes employés afin qu’elles puissent obtenir ces
configurations automatiquement.

Remarque : L’adresse 192.168.1.255 n’est pas utilisée car c’est une adresse broadcast.

Configuration du serveur DNS

A partir de là, les hôtes du LAN sont capables de se connecter à internet mais seulement à l’aide des
adresses IP des sites qu’ils veulent visiter, il en est aussi de même pour l’accès à l’intranet. C’est dû
au fait que le serveur DNS n’est pas encore configuré donc il n’y a pas encore de résolution de noms
de domaine.

Pour des raisons d’économie d’adresses, le server DNS et DHCP seront sur le même hôte.

Les configurations DNS sont les suivantes

A partir de ce moment, les hôtes seront accessibles depuis leur nom d’hôte respectif. Pour que le
serveur dns.orinasa.intra puisse résoudre les noms de domaines publics, il faudra définir une/des
adresses de serveurs de noms publics. Le serveur de noms public est ici à l’adresse 197.149.55.1
(Service généralement fourni par le FAI).

3.4.3 Configuration du serveur web publique

Pour l’instant le serveur Debian 9 ne dispose encore d’aucune configuration réseau. Il sera configuré
de telles sortes que son adresse réseau soit statique. Pour les distributions linux en générale, le fichier
de configuration réseau se trouve dans /etc/network/interfaces.

Voici à quoi ressemble le fichier après configuration :

53
L’adresse IP doit concorder avec celle qui est déjà définie dans l’objet webserver du firewall.

Il ne reste plus qu’à redémarrer le service apache avec la commande systemctl restart apache2.

Quant aux adresses de serveurs DNS, elles se font dans le fichier /etc/resolv.conf. Deux adresses de
serveurs de noms seront ajoutées : l’adresse du serveur de nom public (197.149.55.1) et l’adresse du
serveur de nom local (192.168.1.2).

Le contenu du fichier est le suivant :

Les applications web contenues dans le serveur pourront accéder au serveur de base de données pour
stocker ou récupérer des données. Toutefois, le serveur de base de données n’est pas directement
accessible depuis l’extérieur. Seul le serveur web peut s’y connecter.

3.4.4 Le Honeypot web Glastopf

Presentation du honeypot
Le projet Glastopf a été fondé fin 2008 par Lukas Rist. C’est un projet open-source, répertorié dans
le « Honeypot project ». Glastopf est un Honeypot Web à faible interaction capable d'émuler des
milliers de vulnérabilités pour collecter des données à partir d'attaques ciblant des applications Web.
Son principe est très simple: répondre à l'attaque en utilisant la réponse attendue par l'attaquant en
exploitant l'application web. Les attaques seront ensuite transcrites dans un fichier log distant
pouvant être stocké sur l’hôte ou sur un autre serveur afin d’assurer son intégrité en cas de
compromission de la machine hôte.

Glastopf est téléchargeable gratuitement sur Github.com à l’adresse :

https://github.com/mushorg/glastopf.git.

54
 Fonctionnement de Glastopf
En principe, le pot de miel fonctionne comme un serveur web normal. Quelqu'un envoie une requête
au serveur Web, la requête est traitée, il se peut que quelque chose soit stockée dans une base de
données puis le serveur renvoie une réponse. Si la requête n'était pas correcte, une page d'erreur est
affichée.

Le diagramme suivant représente le fonctionnement de Glastopf :

Attaque

Emulation de vulnérabilité

Collecte de données

Base de données Stockage de fichiers

Réponse à l’attaque

Figure 3.05 : Fonctionnement général de l’Honeypot

Configurations de Glastopf
Tout d’abord, l’interface réseau de la machine hôte est configurée. Les procédés sont les mêmes que
ceux du serveur web Debian mais avec des adresses.

Les configurations sont les suivantes :

55
Avant l’installation de Glastopf, il est nécessaire de disposer de quelques paquets qui sont utiles à
son bon fonctionnement.

Les commandes d’installation de ces paquets sont les suivantes :

Maintenant que ces prérequis ont été satisfaits, Glastopf peut être installé. La procédure
d’installation est consultable dans ANNEXE 6.

Après l’installation, il faudra configurer le Honeypot web. Glastopf a été installé dans /opt/hp/ et le
fichier de configuration est glastopf.cfg. Le fichier de configuration complet est disponible dans
ANNEXE 6.

Le Honeypot dispose de plusieurs plugins utilisables mais les plus importantes dans le fichier de
configuration sont les suivantes :

L’adresse d’écoute du serveur web de Glastopf est 0.0.0.0 afin qu’il puisse être accessible sur toutes
les adresses IP dont dispose la machine. Ensuite, le port 80 est utilisé afin de remplacer le serveur
web apache.

Remarque : Apache doit être désactivé car il utilise par défaut le port 80. Il suffit d’exécuter la
commande : # service apache2 stop

Le plugin logging est très important car il va permettre de suivre les actions faites par le pirate. Il
sera donc activé afin qu’un fichier log soit généré et mis à jour. Ici, le fichier log se trouve dans
/opt/hp/log/glastopf.log.

56
Les données sont aussi récupérées sous forme de base de données SQLite dans
/opt/hp/db/glastopf.db. Le contenu de ce fichier pourra être visualisé à partir de n’importe quel
logiciel permettant d’administrer des bases SQlite mais dans ce mémoire, le logiciel utilisé sera
Glastopf-Analytics.

Avant de lancer Glastopf, il faut se placer dans le dossier où il a été installé. La commande est la
suivante :

Le Honeypot est maintenant prêt à accueillir les pirates à l’adresse 197.149.55.200.

Configuration de Glastopf-Analytics
Le dépôt officiel de Glastopf-Analytics se trouve sur Github à l’adresse
https://github.com/katkad/Glastopf-Analytics.git. Il y a également des prérequis qui seront installés
à partir des commandes suivantes :

Le dossier Glastopf-Analytics sera ensuite placé dans /opt/ et les configurations se font dans le
fichier /opt/Glastopf-Analytics/lib/MyWebb/App.pm. Il faudra modifier le login pour accéder à
l’interface web et le chemin vers glastopf.db qui sont aux lignes 9,10 et 11.

La commande pour lancer Glastopf-Analytics est la suivante :

Par défaut, l’interface web est disponible sur le port 3000 de la machine. Dans le cas où
l’administrateur du réseau voudrait avoir l’accès à cette interface web, ce qui est ici le cas, il faut
créer une ACL sur le firewall, autorisant le trafic sur le port tcp 3000 de l’interface dmzh. Cependant,
seul l’administrateur réseau aura accès à cette interface web.

57
 Conclusion
En guise de conclusion, le déploiement d’un réseau informatique contenant un Honeypot est une
tâche qui doit être effectuée minutieusement afin d’en tirer le maximum d’information possible sur
l’attaquant. Des négligences au niveau des configurations pourraient entrainer des conséquences
désastreuses. Maintenant, que tout le réseau est configuré, et que le Honeypot web Glastopf est en
place, le chapitre suivant se chargera de teste l’ensemble à partir d’une simulation consistant émuler
une attaque sur un réseau d’entreprise.

58
 CHAPITRE 4

SIMULATION D’UNE ATTAQUE SUR LE HONEYPOT GLASTOPF

Mise en œuvre de la simulation

4.1.1 Identification des vulnérabilités
La machine de l’attaquant qui est sous Kali linux est un OS spécialisé pour les tests de pénétration
réseau. Il dispose donc de plusieurs outils permettant de scanner les vulnérabilités mais aussi de les
exploiter.

Supposons que l’entreprise « Orinasa » souhaite savoir s’il y aurait des failles sur son site. Il déploie
donc un Honeypot avec comme url www.hp.orinasa.mg. Un individu malveillant commence par
scanner les ports et les plages d’adresses de l’entreprise à partir du logiciel nmap.

Commande nmap :

Voici le résultat du scan :

Figure 4.20 : Résultat du scan nmap

Le résultat du scan montre qu’il y a le port 80 (hhtp), ouvert pour l’adresse 197.49.55.200.

En tapant l’adresse ip 197.149.55.200 ou l’url www.hp.orinasa.org dans un navigateur, la page

suivante s’affiche :

59
 Figure 4.01 : Page d’accueil de Glastopf

A partir de ce moment, Le Honeypot commence à enregistrer toutes les actions effectuées par le
pirate.

Il va maintenant chercher les vulnérabilités sur le site le module unisacan de kali linux. Ce module
permet d’identifier si le site est vulnérable aux LFI et RFI.

Voici la commande à exécuter :

Les résultats du scan s’affichent sur la console mais pour un format plus clair, il faudra consulter le
fichier /usr/share/uniscan/report/www.hp.orinasa.mg.html. Le contenu est le suivant :

60
 Figure 4.02 : Résultat d’uniscan

Cette page affiche dans un navigateur tous les liens vulnérables à la faille RFI

4.1.2 Exploitation de la faille RFI

Si on tape un de ces liens dans la barre d’adresse d’un navigateur, le contenu du fichier passwd va
s’afficher comme le montre l’image ci-dessous :

Figure 4.03 : Contenu du fichier passwd

61
Le fichier /etc/passwd contient toutes les informations relatives aux utilisateurs (login, mots de
passe, ...). Seul le superutilisateur (root) doit pouvoir le modifier. L’obtention de ce fichier est donc
très dangereuse dans le cas où le serveur n’est pas un Honeypot. Ici, le fichier passwd n’est qu’un
fau fichier contenu dans le Honeypot.

Dans de vrais systèmes, les failles LFI peuvent aller jusqu’à prendre le contrôle du serveur en
exécutant une console de commande.

4.1.3 Visualisation des données récoltés par le honeypot

Comme il a été dit dans le chapitre précédent, seul l’administrateur aura accès à l’interface web de
Glastopf-Analytics. Pour y accéder, il doit saisir l’url http://192.168.200.2:3000. Le port doit être
spécifié car le navigateur utilise par défaut le port 80.

La page de login suivante s’affiche :

Figure 4.04 : Page de login de Glastopf-Analytics

Username et Password sont ceux qui étaient spécifiés dans le fichier /opt/Glastopf-
Analytics/lib/MyWebb/App.pm.

Depuis cette interface web, l’administrateur, aura accès aux données concernant les fichiers utilisés
pour les RFI, les derniers évènements, adresses IP et la nationalité des pirates, les vecteurs
d’attaques, les types d’attaques utilisées et les types de requêtes les plus utilisées.

En consultant le journal d’évènements, on peut constater que l’attaque LFI effectuée dans la partie
4.1.2 de ce chapitre a bien été répertoriée avec le pays source de l’attaque et l’adresse IP.

62
 Figure 4.05 : journal des évènements

La figure ci-dessous affiche les statistiques concernant les attaques les plus fréquentes, subies par le
Honeypot.

Figure 4.06 : Statistiques tipes d’attaques

Bilan de la simulation
Ce bilan se portera sur les Honeypot en général mais pas seulement sur le Honeypot Glastopf. Certes,
il existe plusieurs types de Honeypot mais le fonctionnement général reste plus ou moins le même,
c’est-à-dire, répondre de manière à satisfaire l’attaquant tout en collectant des données sur l’attaque.
Toutefois, une mauvaise administration de l’Honeypot pourrait nuire à l’intégrité de données

63
collectées par le Honeypot. Les niveaux d’interaction des Honeypot offrent des avantages mais
peuvent aussi parfois causer quelques problèmes.

4.2.1 Les points forts

 Le pirate n’aura jamais accès aux vraies données de l’entreprise.
 Alternative pour lutter contre le ransomware (rançongiciel) : le logiciel malveillant va crypter
des données qui sont trompeurs sur le Honeypot. Cela rendrait plus facile les enquêtes sur le
fonctionnement et la source du logiciel malveillant.
 Il n’y a pas de faux positifs car toute interaction avec le Honeypot est forcément une attaque.
 Le Honeypot permet d’étudier le déroulement de l’attaque avec précision
 Leur virtualisation permet une économie de ressources considérable au niveau de l’entreprise.
 Les Honeypots à faible interaction sont en général, des solutions rapidement implémentables et
peuvent se placer à n’importe quel endroit du réseau.

4.2.2 Les points faibles

 Les Honeypot à faible interaction sont parfois facilement reconnaissable malgré leur sureté.
 Un Honeypot à forte interaction offre plus de liberté à un pirate, ce qui peut être une source de
danger pour le système hôte.
 Il peut être la nouvelle base d’attaques du pirate en cas de détournement
 Le Honeypot est une solution qui ne peut assurer la sécurité à lui tout seul
 L’implémentation d’un Honeypot à forte interaction est souvent une tache très ardue et longue,
dû au fait qu’il imite un système d’exploitation entier avec plusieurs services.

4.2.3 Amélioration de l’efficacité des Honeypots

 Afin qu’un Honeypot soit plus efficace, il est primordial de bien penser à son emplacement. Un
Honeypot qui est mal placé ou trop isolé ne sert à rien car il ne pourra collecter aucune donnée.
 L’existence d’un Honeypot dans l’entreprise doit plus ou moins être secrète car dans le cas
contraire, il perd entièrement sont intérêt.
 Dans les entreprises souvent victimes d’attaques informatiques, il est préférable de réserver un
ou plusieurs postes dédiés entièrement à l’administration du Honeypot. Cette unité se chargera
de suivre et d’analyser consciencieusement les fichiers logs mais aussi de l’améliorer.
 Il est préférable de coupler le Honeypot avec d’autres systèmes de sécurité comme par exemple
l’IDS psad qui permet de détecter les scans de ports pour une compréhension encore plus
approfondie des attaques.

64
 Même si le Honeypot sert d’appât pour les pirates, en cas d’attaque, les responsables de la
sécurité informatique doivent être réactifs.

4.2.4 Estimation du cout de l’implémentation d’un Honeypot

La décision d’implémenter un Honeypot pour une entreprise est le plus souvent synonyme de
dépenses supplémentaires, que ce soit au point de vue matériel ou aussi humain (administrateur du
Honeypot).

Or, la sécurité est un point essentiel pour une entreprise surtout dans le cas ou son activité transite
beaucoup sur internet. On n’est jamais à l’abri des pirates ou des virus informatiques. Mais toutefois,
l’entreprise se doit aussi d’être raisonnable dans ses décisions. Une grande entreprise victime de
cents attaques par mois se doit d’investir plus qu’une autre qui ne subit que cinq à dix attaques par
ans.

Voici une estimation du cout de l’implémentation d’un Honeypot en fonction du volume de trafic
malicieux visant une entreprise :

Grandes entreprises
 Un ou plusieurs ordinateurs dédiés aux Honeypots : Un ordinateur suffisamment puissant (Core
i5 de quatrième génération ou plus), pouvant couter dans les environs de 2.000.000 à 4.000.000
d’Ariary. La machine doit être suffisamment puissante afin de gérer rapidement les informations
reçues par le Honeypot ou le Honeynet.
 Au moins un ingénieur spécialisé dans la sécurité informatique : Il faudra embaucher au moins
un Ingénieur spécialiste en cyber-sécurité qui supervisera le Honeypot et se chargera de son
entretien. En France, un ingénieur en cyber-sécurité est payé en moyenne aux environs de 50.000
Euros.

Enterprise moyenne
Le volume de trafic passant par le Honeypot est généralement assez faible donc il n’est pas
nécessaire d’utiliser ne machine surpuissante. Un Core i3 de deuxième ou troisième génération ferait
bien l’affaire, ce qui peut couter aux environs de 1.000.000 à 2.000.000 d’Ariary.

Un ingénieur spécialisé n’est pas forcément nécessaire, le travail peut être effectué par
l’administrateur du réseau.

65
 Conclusion
Pour conclure ce chapitre, ce chapitre a permis d’avoir un aperçu du fonctionnement d’un Honeypot
dans de cas réels mais aussi un bilan sur les Honeypot en générale, tout en proposant des solutions
d’amélioration et une idée du coût de l’investissement pour son implémentation.

66
 CONCLUSION

En guise de conclusion, le Honeypot s’avère être une solution adaptée aux menaces informatiques
ciblant les entreprises mais il faut tout de même prendre en compte que son implantation nécessite
un investissement supplémentaire. Il faut aussi considérer que le Honeypot à lui seul, n’est pas
l’élément qui va empêcher des attaques contre le réseau de l’entreprise. Il doit être couplé avec
d’autres éléments tels que les IDS/IPS et les pare-feu. Le Honeypot permettra de connaitre les
intentions des pirates mais aussi les techniques qu’ils utilisent. Il va donc faire en sorte de distraire
le pirate afin de l’étudier. Il est d’une importance primordiale pour une entreprise de disposer de
système de protection réseau performant. La protection des données est un enjeu qui n’est pas à
mettre à la légère dans une activité de production en entreprise. Le désastre causé par une attaque
dans un environnement de production pourrait être considérable surtout dans les cas où le pirate
cherche à corrompre ou voler des données sensibles.

Le secteur du Honeypot regroupe une communauté qui œuvre constamment pour l’amélioration des
capacités des produits développés, notamment grâce à l’organisation « The Honeynet Project ».
Toutes les années, le programme Google Summer of Code ou GSoC rassemble aussi des projets
venant d’organisations dont des projets sur les Honeypots. Tout cela montre que le Honeypot est
une solution de sécurité constamment en développement et sera pour un bon moment une alternative
adoptée par les entreprises pour déjouer les tentatives d’attaques informatique.

Pour finir, ce mémoire a permis d’affirmer que les technologies Honeypot sont des bonnes solutions
pour la sécurité réseau, avec bien sûr leurs propres particularités. Le Honeypot est une technologie
assez jeune et toujours en cours de développement, d’où son utilisation qui se montre encore moins
fréquente mais dans quelques années, il se trouve qu’il sera un des composants essentiels dans la
sécurisation des systèmes informatiques. Cela réduirait considérablement le nombre d’attaques
visant les réseaux des entreprises et améliorera la protection des données sensibles.

67
 ANNEXES

ANNEXE 1: LE MODELE OSI

A1.1 Les 7 couches du modèle OSI

Figure A1.01 : Les couches du modèle OSI

68
 A1.2 Les protocoles de chaque couche du modèle OSI
Couches Protocoles

BGP, DHCP, DNS, FTP, Gopher, H.323, HTTP, IMAP, IPP, IRC, LDAP,
MODBUS, NFS, NNTP, POP3, RDP, RTSP, SILC, SIMPLE, SIP, SMB-CIFS,
7. Application SMTP, SNMP, SOAP, SSH, TCAP, Telnet, TFTP, VoIP, WebDAV, XMPP

AFP, ASCII, ASN.1, MIME, NCP, TDI, TLS, TLV, Unicode, UUCP, Vidéotex,
6. Présentation XDR

5. Session AppleTalk, DTLS, H.323, NetBIOS, RPC, RSerPool, SOCKS

4. Transport DCCP, RSVP, RTP, SCTP, SPX, TCP, UDP

ARP, Babel, BOOTP, CLNP, ICMP, IGMP, IPv4, IPv6, IPX, IS-IS, NetBEUI,
3. Réseau OSPF, RARP, RIP, X.25

Anneau à jeton (Token Ring), Anneau à jeton adressé (Token Bus), ARINC 429,
AFDX, ATM, Bitnet, CAN, Ethernet, FDDI, Frame Relay, HDLC, I²C, IEEE
802.3ad (LACP), IEEE 802.1aq (SPB), LLC, LocalTalk, MIL-STD-1553, PPP,
2. Liaison STP, Wi-Fi, X.21

4B5B, ADSL, BHDn, Bluetooth, Câble coaxial, Codage bipolaire, CSMA/CA,

CSMA/CD, DSSS, E-carrier, EIA-232, EIA-422, EIA-449, EIA-485, FHSS,
HomeRF, IEEE 1394 (FireWire), IrDA, ISDN, Manchester, Manchester
différentiel, Miller, MLT-3, NRZ, NRZI, NRZM, Paire torsadée, PDH, SDH,
SDSL, SONET, T-carrier, USB, VDSL, V.21-V.23, V.42-V.90, Wireless USB,
1. Physique 10BASE-T, 10BASE2, 10BASE5, 100BASE-TX, 1000BASE-T

Tableau A1.01 : Couches et protocoles du modèle OSI

69
 ANNEXE 2 : LES SERVICES LES PLUS UTILISES

 9, pour le WoL, Wake-on-LAN, c'est-à-dire le démarrage à distance par un câble réseau ethernet.
Wake-on-LAN
 20/21, pour l'échange de fichiers via FTP
 22, pour l'accès à un shell sécurisé Secure Shell, également utilisé pour l'échange de fichiers
sécurisés SFTP
 23, pour le port telnet
 25, pour l'envoi d'un courrier électronique via un serveur dédié SMTP
 53, pour la résolution de noms de domaine en adresses IP : DNS
 67/68, pour DHCP et bootpc
 80, pour la consultation d'un serveur HTTP par le biais d'un navigateur web
 110, pour la récupération de son courrier électronique via POP
 123, pour la synchronisation de l'horloge : Network Time Protocol (NTP)
 143, pour la récupération de son courrier électronique via IMAP
 389, pour la connexion à un LDAP
 443, pour les connexions HTTP utilisant une surcouche de sécurité de type SSL : HTTPS
 465, pour l'envoi d'un courrier électronique via un serveur dédié utilisant une surcouche de
sécurité de type SSL : SMTPS
 500, port utilisé pour le canal d'échange de clés IPsec
 554, port utilisé pour accepter les connexions client RTSP entrantes et pour fournir des paquets
de données aux clients qui diffusent en utilisant RTSPT.
 636, pour l'utilisation d'une connexion à un LDAP sécurisé par une couche SSL/TLS
 1352, pour le protocole Lotus Notes Domino
 1433, serveur de base de données MS SQL
 1521, serveur de base de données Oracle Database
 1723, pour l'utilisation du protocole de VPN PPTP
 3306, serveur de base de données MySQL
 3389, pour la prise de contrôle à distance RDP
 5432, serveur de base de données PostgreSQL
 6667, pour la connexion aux serveurs IRC
 25565, port par défaut des serveurs Minecraft

70
 ANNEXE 3 : LES COMMANDES SQL

A3.1 Base de données

Nom de la base : base

 Création de base de données :

CREATE DATABASE base;

 Suppression de base de données :

DROP DATABASE base;

 Utilisation de la base de données base:

USE base;

A3.2 Tables
A3.2.1 Création d’une table simple

CREATE TABLE maTable

colonne1 type_donnees,

colonne2 type_donnees,

colonne3 type_donnees,

colonne4 type_donnees

Dans cette requête, 4 colonnes ont été définies. Le mot-clé « type_données » sera à remplacer par
un mot-clé pour définir le type de données (INT, DATE, TEXT …). Pour chaque colonne, il est
également possible de définir des options telles que (liste non-exhaustive):

 NOT NULL : empêche d’enregistrer une valeur nulle pour une colonne.
 DEFAULT : attribuer une valeur par défaut si aucune donnée n’est indiquée pour cette colonne
lors de l’ajout d’une ligne dans la table.
 PRIMARY KEY : indiquer si cette colonne est considérée comme clé primaire pour un index

71
A3.2.2 Manipulation des tables

 SELECT :

L’utilisation la plus courante de SQL consiste à lire des données issues de la base de données. Cela
s’effectue grâce à la commande SELECT, qui retourne des enregistrements dans un tableau de
résultat. Cette commande peut sélectionner une ou plusieurs colonnes d’une table.

Syntaxes: SELECT nom_colonne FROM maTable

 WHERE:

La commande WHERE dans une requête SQL permet d’extraire les lignes d’une base de données
qui respectent une condition. Cela permet d’obtenir uniquement les informations désirées.

Syntaxes: SELECT nom_colonne FROM maTable WHERE condition

Il existe plusieurs opérateurs de comparaisons. La liste ci-jointe présente quelques-uns des

opérateurs les plus couramment utilisés.

Opérateur Description

= Égale

<> Pas égale

!= Pas égale

> Supérieur à

< Inférieur à

>= Supérieur ou égale à

<= Inférieur ou égale à

IN Liste de plusieurs valeurs possibles

Valeur comprise dans un intervalle donnée (utile pour les

BETWEEN nombres ou dates)

LIKE Recherche en spécifiant le début, milieu ou fin d'un mot.

IS NULL Valeur est nulle

IS NOT NULL Valeur n'est pas nulle

Tableau A3.01 : Opérateurs de comparaison

72
 LIKE :

L’opérateur LIKE est utilisé dans la clause WHERE des requêtes SQL. Ce mot-clé permet
d’effectuer une recherche sur un modèle particulier. Il est par exemple possible de rechercher les
enregistrements dont la valeur d’une colonne commence par telle ou telle lettre. Les modèles de
recherches sont multiples.

Syntaxes: SELECT * FROM table WHERE colonne LIKE modèle

Remarque: Le signe * en SQL signifie « tout ».

Dans cet exemple le « modèle » n’a pas été défini, mais il ressemble très généralement à l’un des
exemples suivants:

 LIKE ‘%a’ : le caractère « % » est un caractère joker qui remplace tous les autres caractères.
Ainsi, ce modèle permet de rechercher toutes les chaines de caractère qui se termine par
un « a ».
 LIKE ‘a%’ : ce modèle permet de rechercher toutes les lignes de « colonne » qui commence par
un « a ».
 LIKE ‘%a%’ : ce modèle est utilisé pour rechercher tous les enregistrements qui utilisent le
caractère « a ».
 LIKE ‘pa%on’ : ce modèle permet de rechercher les chaines qui commence par « pa » et qui se
terminent par « on », comme « pantalon » ou « pardon ».
 LIKE ‘a_c’ : peu utilisé, le caractère « _ » (underscore) peut être remplacé par n’importe quel
caractère, mais un seul caractère uniquement (alors que le symbole pourcentage « % » peut être
remplacé par un nombre incalculable de caractères. Ainsi, ce modèle permet de retourner les
lignes « aac », « abc » ou même « azc ».

73
 ANNEXE 4 : FICHIER DE CONFIGURATION PHP (php.ini)

Le fichier php.ini est un fichier de configuration important de PHP. Les directives utilisées dans ce
fichier permettent de définir une valeur de certaines configurations de PHP pour remplacer leur
valeur par défaut. Le fichier php.ini permet notamment d'activer ou désactiver certaines fonctions,
de définir le temps d'exécution maximum d'un script ou bien encore de définir la taille maximum
d'un fichier lors d'un upload.

L'ensemble des configurations de PHP sur un serveur peuvent être affichées d'une façon simple. Il
suffit de créer une page web en PHP, d'utiliser la fonction phpinfo() et de lancer la page web qui
possède cette fonction. La page web affichera alors une longue page présentant tous les paramètres
importants, comme par exemple sur la figure A4.01.

Figure A4.01 : Résultat de la fonction phpinfo()

74
 ANNEXE 5 : LES PLAGES D’ADRESSES IP

A5.1 Les plages d’adresses IP privées et publiques

Les adresses IP privées représentent toutes les adresses IP de classe A, B et C que l’on peut utiliser
dans un réseau local (LAN) c'est-à-dire dans un réseau d’entreprise ou dans un réseau domestique.
De plus, les adresses IP privées ne peuvent pas être utilisées sur internet (car elles ne peuvent pas
être routées sur internet), les hôtes qui les utilisent sont visibles uniquement dans le réseau local. Les
classes A, B et C comprennent chacune une plage d’adresses IP privées à l’intérieur de la plage
globale.

 Les adresses privées de la classe A : 10.0.0.0 à 10.255.255.255

 Les adresses privées de la classe B : 172.16.0.0 à 172.31.255.255
 Les adresses privées de la classe C : 192.168.1.0 à 192.168.255.255

Contrairement aux adresses IP privées, les adresses IP publiques ne sont pas utilisées dans un réseau
local mais uniquement sur internet. Les routeurs disposent d’une adresse IP publique côté internet,
ce qui le rend visible sur internet. Mais aussi, lors de l’accès à un site web, l’adresse publique du
serveur web est utilisée.

Une adresse IP publique est unique dans le monde, ce qui n’est pas le cas des adresses privées qui
doivent être unique dans un même réseau local mais pas au niveau planétaire étant donné que ces
adresses ne peuvent pas être routées sur internet.

Les adresses IP publiques représentent toutes les adresses IP des classes A, B et C qui ne font pas
partie de la plage d’adresses privées de ces classes ou des exceptions de la classe A.

Remarque :

 Le réseau 127.0.0.0 est réservé pour les tests de boucle locale avec notamment l’adresse IP
127.0.0.1 qui est l’adresse « localhost » c'est-à-dire de boucle locale du PC.
 Le réseau 0.0.0.0 est lui aussi réservé (et utilisé notamment pour définir une route par défaut sur
un routeur).

A5.2 Quelques plages d’adresses IP publiques attribuées à Madagascar

Le tableau suivant représente une liste de différentes plages d’adresses publiques attribuées aux
opérateurs de télécommunications à Madagascar selon le site fr.wikiscan.org. Effectivement
plusieurs autres entreprises Malgaches possèdent leurs propres plages d’adresses, cette liste n’est

75
pas exhaustive. La plupart de ces adresses IP sont attribuées par l’organisme AfriNIC (African
Network Information Centre). Ces informations sont publiques et sont consultables sur le site
Wikiscan.org

Orange Madagascar Airtel Madagascar Telma Madagascar

41.74.208.0/20 41.77.16.0/21 41.188.0.0/18
197.215.192.0/20 41.77.16.0/24 197.149.0.0/18
41.63.128.0/19 196.192.32.0/20
80.12.72.0/24 41.207.38.0/24
193.251.141.0/24 41.207.40.0/24
41.207.41.0/24

Tableau A5.01 : Plages IP opérateurs de télécommunications

76
 ANNEXE 6 : LES FICHIERS DE CONFIGURATION DE GLASTOPF

[webserver]

host = 0.0.0.0

port = 80

uid = nobody

gid = nogroup

proxy_enabled = False

[ssl]

enabled = False

certfile =

keyfile =

#Generic logging for general monitoring

[logging]

consolelog_enabled = True

filelog_enabled = True

logfile = log/glastopf.log

[dork-db]

enabled = True

pattern = rfi,lfi

# Extracts dorks from a online dorks service operated by The Honeynet Project

# This service is down until further notice!

mnem_service = False

77
[hpfeed]

enabled = False

host = hpfriends.honeycloud.net

port = 20000

secret = 3wis3l2u5l7r3cew

# channels comma separated

chan_events = glastopf.events

chan_files = glastopf.files

ident = x8yer@hp1

[main-database]

#If disabled a sqlite database will be created (db/glastopf.db)

#to be used as dork storage.

enabled = True

#mongodb or sqlalchemy connection string, ex:

#mongodb://localhost:27017/glastopf

#mongodb://james:bond@localhost:27017/glastopf

#mysql://james:bond@somehost.com/glastopf

connection_string = sqlite:///db/glastopf.db

[surfcertids]

enabled = False

host = localhost

port = 5432

user =

78
password =

database = idsserver

[syslog]

enabled = False

socket = /dev/log

[mail]

enabled = False

# an email notification will be sent only if a specified matched pattern is identified.

# Use the wildcard char *, to be notified every time

patterns = rfi,lfi

user =

pwd =

mail_from =

mail_to =

smtp_host = smtp.gmail.com

smtp_port = 587

[taxii]

enabled = False

host = taxiitest.mitre.org

port = 80

inbox_path = /services/inbox/default/

use_https = False

use_auth_basic = False

79
auth_basic_username = your_username

auth_basic_password = your_password

use_auth_certificate = False

auth_certificate_keyfile = full_path_to_keyfile

auth_certificate_certfile = full_path_to_certfile

include_contact_info = False

contact_name = ...

contact_email = ...

[logstash]

enabled = False

host = localhost

port = 5659

handler = AMQP/TCP/UDP

[misc]

# set webserver banner

banner = Apache/2.0.48

[surface]

#https://www.google.com/webmasters/

google_meta =

#http://www.bing.com/toolbox/webmaster

bing_meta =

80
[sensor]

sensorid = None

[profiler]

enabled = False

81
 BIBLIOGRAPHIE

[1] D. Valois, C. Llorens, L. Levier, « Tableaux de bord de la sécurité réseau », 2e édition. Eyrolles,
octobre 2006.

[2] N. Stouls, M.-L. Potet, « Security policy enforcement through refinement process. In Proc. of
Formal Specification and Development in B », 7th International Conference of B Users (B2007),
LNCS 4355, pages 216–231. Springer-Verlag, Janvier 2007.

[3] L. Li, « Système de détection d'intrusions », Cours de l'Université de Marne-la-Vallée, 11 Avril

2018.

[4] J. Krier, « Les systèmes de détection d'intrusions »,https://dbprog.developpez.com/securite/ids/,

21 juillet 2006.

[5] V. Rakotomalala, « Les ACLs », extrait chapitre Filtrage de paquets Master II, 2017.

[6] B. Kenyon, S. Andrés et E. P. Birkholz, « Security Sage’s Guide to Hardening the Network

Infrastructure », chapter 10 et 11, publié par Syngress Publishing, Inc., Rockland, MA, 2004.

[7] « Visualisation des attaques Web », https://www.akamai.com/, 14 avril 2018.

[8] Que20, « Les injections SQL », https://zestedesavoir.com/articles/193/les-injections-sql/, 08

novembre 2015.

[9] C. Stoll, « The Cuckoo's Egg », Livre édité par Doubleday, 1989.

[10] A. Verma, « Production Honeypots: An Organization’s view », page 8, 23 octobre 2003.

[11] A. Fadlallah, J. Leneutre, A. Serhrouchni, « Les Honeypots », document de l’ENST-Paris, 16

avril 2018.

[12] « The Honeynet Project, Know Your Enemy », page 20, mars 2007.

[13] N. Sharma, « Detection of threats in Honeynet using Honeywall », International Journal on

Computer Science and Engineering, 10 octobre 2011.

[14] « Different types of Virtual Honeynets », http://old.honeynet.org/papers/virtual/, Honeynet

Project: Defining Virtual Honeynets, 27 janvier 2003.

82
 FICHE DE RENSEIGNEMENTS

Nom : RANOTRONARISON

Prénoms: Nomena Arivony

Adresse: IIE11S Ampandrianomby

arivonyran@gmail.com

0342606261

Titre du mémoire :

IMPLEMENTATION D’UN HONEYPOT

POUR LA SECURISATION D’UN RESEAU D’ENTREPRISE

Nombres de pages : 84

Nombres de tableaux : 06

Nombre de figures : 41

Directeur de mémoire : RAMAFIARISONA Hajasoa Malalatiana,

0341654248

83
 RESUME

Ce mémoire a pour but, l’implémentation d’un « pot-de-miel » dans un réseau d’entreprise pour y
renforcer la sécurité. Pour aborder ce sujet, il est important de connaitre en premier lieu, comment
se montre la sécurité informatique en entreprise et quelles sont les menaces auxquelles les systèmes
informatiques font face. La seconde partie parlera du Honeypot en lui-même ainsi que les techniques
d’implémentation. Ensuite, la partie suivante proposera une architecture réseau où le Honeypot web
Glastopf a été implémenté pour piéger les pirates informatiques. En dernier lieu aura lieu une
simulation d’attaque sur le Honeypot afin d’en tirer un bilan général sur les Honeypots.

ABSTRACT

This thesis aims to implement a Honeypot in a corporate network to enhance security. To address
this topic, it is important to know first of all, how is IT security in business and what are the threats
that IT systems face. The second part will talk about the Honeypot itself and the implementation
technics. Then the next part will propose a network architecture where the web Honeypot Glastopf
has been implemented to trap hackers. Finally, there will be an attack simulation on the Honeypot
in order to draw a general report on the Honeypots.

Mots clés / Keywords : Honeypot, sécurité, réseau, pirates, Honeynet