La protection des rseaux contre les

attaques DOS
Dany Fernandes et Papa Amadou Sarr
Mai 2010

Tuteur : Osman SALEM

Sommaire
Remerciements ................................................................ 3
Introduction .................................................................. 4
1. Une attaque connue : le dni de service ........................................... 5
1.1. Quest ce que le dni de service ............................................. 5
1.2. Dni de service distribu ................................................... 5
1.3. Les principaux types dattaque .............................................. 6
1.4. Historique des grandes attaques ............................................. 7
1.5. La nouvelle arme des pirates ................................................ 7
2. Le Syn Flooding ............................................................. 8
2.1. Nature de lattaque ....................................................... 8
2.2. Ralisation de lattaque .................................................... 9
2.3. Rsultats de lattaque .................................................... 11
2.4. Mesures de protection .................................................... 11
2.5. Dtection de lattaque .................................................... 17
2.6. Raction de lattaquant ................................................... 19
3. Les honeypots ............................................................. 20
3.1 Types de honeypots ...................................................... 20
3.2 Les honeynets........................................................... 21
3.3 Honeynets virtuels ....................................................... 21
3.4 Avantages et inconvnients des honeypots .................................... 22
3.5 Quelques solutions existantes .............................................. 22
3.6 Honeyd .................................................................. 23
4. Conclusion ................................................................ 25
Rfrences .................................................................. 26
Annexes .................................................................... 27

Remerciements

Avant dentamer ce rapport, nous tenons remercier le tuteur de notre projet, M. Osman
Salem pour toute laide quil nous a apport durant ces 5 mois de projets. Nous remercions
galement Dominique Seret pour lintrt port notre projet et galement pour son cours dSSIC
du premier semestre qui nous a donn envie de poursuivre dans la scurit informatique. Enfin,
nous remercions Ahmed Mehaoua pour son cours de rseau avanc qui nous a permis davoir les
bases de rseau ncessaire la ralisation du projet.

Introduction
Aujourdhui, les rseaux informatiques sont de plus en plus dvelopps, que se soit chez les
particuliers ou dans le domaine professionnel. Lexpansion des systmes informatiques mais surtout
de linternet ces dernires annes ont rendu les rseaux indispensables pour les entreprises.
Mais si toutes ces innovations ont apports de trs nombreux avantages aux entreprises, elles
sont accompagnes de nouveaux risques inhrents ces nouvelles technologies, le piratage
informatique. En effet, ces attaques sont de plus en plus nombreuses, efficaces et simple mettre en
uvre. Elles sont utilises pour lespionnage industrielle (vols dinformations confidentielles) ou
simplement du parasitage (destruction de donnes numriques ou arrt de service). Dans le cadre de
notre projet, nous nous intresserons aux attaques de types dnis de service, qui sont les plus
rependues. Ce type dattaque nest pas dangereux pour les donnes numriques du rseau, mais a
pour objectif de rendre indisponible un service propos par une entreprise, par exemple un site de
commerce en ligne ; une entreprise ne peut se permettre davoir son site indisponible pendant
plusieurs heures ou jours.
Dans un premier temps, nous allons dfinir ce quest le dni de service, pour comprendre
leur fonctionnement et leur mise en uvre. Nous verrons ensuite quels sont les moyens qui sont
notre disposition pour se prmunir de ce genre dattaque.

1. Une attaque connue : le dni de service

1.1. Quest ce que le dni de service
Un dni de service (Denial of Service ou DoS) est une attaque ralise dans le but de rendre
indisponible durant une certaine priode les services ou ressources dune organisation.
Gnralement, ce type dattaque lieu contre des machines et serveurs dune entreprise afin quils
deviennent inaccessibles pour leurs clients.
Le but d'une telle attaque n'est pas d'altrer ou de supprimer des donnes, ni mme de voler
quelconque information. Il sagit ici de nuire au fonctionnement d'un service ou la rputation
d'une socit qui offre un service sur Internet en empchant le bon fonctionnement de celui ci.
Raliser un dni de service est aujourd'hui simple, et galement trs efficace. Il est possible
dattaquer tout type de machine (Windows, Linux, Unix) car la plupart des dnis de service
exploitent des failles lies au protocole TCP/IP.
Il en existe principalement deux types :
1. Les dnis de service par saturation qui consistent submerger une machine de requtes, afin
qu'elle ne soit plus capable de rpondre aux requtes relles ;
2. Les dnis de service par exploitation des vulnrabilits qui consistent exploiter une faille
du systme afin de le rendre inutilisable.
Le principe de ces attaques est denvoyer des paquets ou des donnes de taille ou de constitution
inhabituelle, afin de provoquer une saturation ou un tat instable des machines victimes et de les
empcher ainsi d'assurer les services rseau qu'elles sont senses offrir. Dans certains cas extrmes,
ce type d'attaque peut conduire au crash de la machine cible.
Le dni de service est donc un type d'attaque qui cote trs cher puisqu'il interrompt le cours normal
des transactions dune organisation. Sachant qu lheure actuelle, les sommes et les enjeux dune
entreprise sont gnralement normes, cela peut poser de graves problmes si une telle situation se
produit ne ft-ce que quelques minutes.
Les contre-mesures sont compliques mettre en place et doivent tre spcifiques un type
dattaque. Etant donn que les attaques par dni de service utilisent les services et protocoles
normaux dInternet, s'en protger reviendrait couper les voies de communications normales,
sachant quil sagit de la raison d'tre principale des machines concernes (serveurs web, serveur
mail ...).
Il faut donc essayer se protger au mieux de certains comportements anormaux, ce qui implique
notamment la vrification de lintgrit des paquets, la surveillance du trafic, tablissement de
profils types et de seuils, etc. On est donc loin de la protection absolue, mais il est tout de mme
possible de se protger de faon intelligente et flexible.

1.2. Dni de service distribu

Lorsqu'un dni de service est provoqu par plusieurs machines, on parle alors de dni de service
distribu (Distributed Denial of Service, ou DDoS). Le but recherch du dni de service sont les
mmes que pour le DoS, la diffrence prs que plusieurs machines la fois sont l'origine de
lattaque (c'est une attaque distribue).
Lattaquant va donc se constituer un rseau o chacune des machines va attaquer la cible un
moment donn. Ce rseau se compose d'un matre et de nombreux htes distants, encore appels
dmons. Pendant le droulement de l'attaque, le hacker se connecte au matre qui envoie alors un
5

ordre tous les htes distants. Ensuite, ceux-ci vont attaquer la cible suivant une technique choisie
par le hacker. Il existe des attaques de type agressives , dont le but de faire crasher compltement
la cible, ou encore des attaques de type "stream" (TCP ACK sur des ports au hasard).
Les DDoS se sont dmocratises depuis quelques annes. En effet, leur dbut, ces attaques
ncessitaient de bonnes connaissances de la part des attaquants. Mais prsents, il existe des outils
pour organiser et mettre en place l'attaque. Ainsi le processus de recherche des htes secondaires
(ou zombies) a t automatis. En reprant certaines failles courantes sur les machines prsentes sur
Internet, l'attaquant finit par se rendre matre (accs administrateur) de centaines voir de milliers de
machines non protges. Il installe ensuite les clients pour l'attaque secondaire et essaye galement
d'effacer ses traces. Une fois le rseau en place, il n'y a plus qu' donner l'ordre pour inonder la
victime finale de paquets inutiles.
Il est intressant de noter que les victimes dans ce type d'attaques ne sont pas que celles qui
subissent le dni de service; tous les htes secondaires sont galement des machines compromises
jusqu'au plus haut niveau (accs root), tout comme l'hte matre. La menace provient du fait que les
outils automatisant le processus ont t trs largement diffuss sur Internet. Il n'y a plus besoin
d'avoir des connaissances pointues pour la mettre en place.
Ce type dattaque reste trs difficile contrer ou viter : il sagit donc dune menace que beaucoup
craignent. En effet, cette attaque est trs dvastatrice, et ne provient plus seulement dune seule
machine, mais dun rseau tout entier. Sachant le nombre de machines non scurises prsentes sur
Internet, on peut imaginer lampleur dune telle attaque.
Il nest donc pas vident de sen protger tant donn que l'identit des attaquants change souvent et
que le temps ncessaire pour organiser une protection adquate est bien souvent suprieur au temps
ncessaire pour mettre mal la victime. Il est donc avant tout primordial de localiser linitiateur et
de reprer sa signature. La dtection d'un trafic suspect peut servir de prvention.

1.3. Les principaux types dattaque

Il existe de nombreux types d'attaques par dni de service. Le simple fait dempcher un systme de
rendre un service peut tre qualifi de dni de service . En voici les principaux :
Ping flooding : cette attaque consiste envoyer un flux maximal de ping vers une cible.
Attaque Ping of Death : le principe est d'envoyer un paquet ICMP avec une quantit de
donnes suprieure la taille maximale d'un paquet IP. Si la cible nest pas adapte grer
ce type de paquet, il peut se produire un crash.
SYN flood : cette technique consiste saturer une machine en envoyant une multitude de
paquets TCP avec le flag SYN arm. Cela crera une multitude de connexions en attente,
demandant un grand nombre des ressources du systme.
UDP Flood : l'attaquant envoie un grand nombre de requtes UDP sur une machine. Le trafic
UDP tant prioritaire sur le trafic TCP, ce type d'attaque peut vite troubler et saturer le trafic
transitant sur le rseau.
Lattaque ARP : elle consiste s'attribuer l'adresse IP de la machine cible, c'est--dire faire
correspondre son adresse IP l'adresse MAC de la machine pirate dans les tables ARP des
machines du rseau. Pour cela il suffit en fait d'envoyer rgulirement des trames ARP
REPLY en diffusion, contenant l'adresse IP cible et la fausse adresse MAC. Cela a pour effet
de modifier les tables dynamiques de toutes les machines du rseau. Celles-ci enverront
donc leurs trames Ethernet la machine pirate tout en croyant communiquer avec la cible
Lattaque Teardrop : cette attaque utilise une faille propre certaines piles TCP/IP. Cette
vulnrabilit concerne la gestion de la fragmentation IP. Ce problme apparat lorsque la pile
reoit le deuxime fragment d'un paquet TCP contenant comme donne le premier fragment.
6

La pile TCP/IP peut s'avrer incapable de grer cette exception et le reste du trafic.
Smurfing : consiste envoyer un ping en diffusion sur un rseau (A) avec une adresse IP
source correspondant celle de la cible (B). Le flux entre le port ping de la cible (B) et du
rseau (A) sera multipli par le nombre de machines sur le rseau (A), conduisant une
saturation de la bande passante du rseau (A) et du systme de traitement des paquets de (B).
Lattaque land : consiste envoyer des paquets TCP comportant une adresse source IP et un
numro de port identiques ceux de la victime. Le host attaqu pense alors qu'il parle lui
mme ce qui gnralement provoque un crash.
Les bombes e-mail : le mail bombing consiste envoyer de gros ou de nombreux fichiers
un utilisateur pour saturer sa bote de rception de courrier lectronique.
Lattaque Unreachable Host : cette attaque envoie des messages ICMP "Host Unreachable"
une cible, provoquant la dconnexion des sessions et la paralysie de la victime, mme si ils
sont envoys faible cadence.

1.4. Historique des grandes attaques

Nuke en avril 1992 (Icmp_unreach)

Octopus en janvier 1996 (While connect)
Ping Of Death en dcembre 1996
Smurf en juillet 1997
Land en octobre 1997 (Windows 95, NT 4.O et 98)
Latierra en octobre 1997 (Plante Windows 95 et occupe 100% du CPU sur NT 4.0)
Teardrop / Overdrop en dcembre 1997 (Plante Linux, NT et 95)
Syndrop en juin 1998 (Teardrop en tcp avec le bit syn et des champs invalides)
Snork en septembre 1998 (Tueur de Windows NT, envoi de paquet RPC (135/UDP) de la
part d'un autre NT)
Smack en octobre 1998 (Inondation de paquets ICMP-UNREACHABLE alatoires)
Attaque sur le serveur de mise jour de Microsoft
Attaque de sites Web connus tels que Google, Microsoft, Apple Computer
Attaques de type ping flood en octobre 2002 sur les serveurs racines DNS

1.5. La nouvelle arme des pirates

Au del du fait quun dni de service occasionne beaucoup de problmes, on voit se profiler de plus
en plus une nouvelle technique de chantage que bons nombres de pirates exercent maintenant
allgrement. En effet, les socits dont la principale activit est base sur un flux dinformation sur
lInternet (souvent avec des sommes importantes en jeux) sont menaces, et susceptibles dtre
paralyses tout moment, occasionnant des pertes importantes, et cela, tout niveau.
Les pirates actuels utilisent donc les attaques par dni de service comme nouvelle arme pour exercer
un chantage contre les socits. Le message est clair : une ranon est demande en change de la
non-paralysie de leur activit. Il est vident que le ralentissement, voir mme le blocage de leurs
services pendant quelques minutes pourrait occasionner de grandes pertes dargent, ainsi que
beaucoup de dsagrments pour leurs clients. Ces socits ont donc tout intrt obir ou trouver
une parade pour sen protger, sans quoi les menaces seraient mises excution.
Cest le cas de la socit DoubleClick , qui en fit les frais le 28 juillet 2004. Son site s'est
retrouv fortement ralenti - voire paralys - pendant de longues heures, entranant dans son
infortune les sites de ses clients, qui dpendent de sa technologie pour grer leurs bannires de
publicit.

Ce cyber crime fut perptr par un groupe de trois pirates russes, jusqu' ce que la police locale ne
les arrte. Leurs cibles taient des banques et des socits de paris britanniques (bookmakers) que
les pirates soumettaient des dnis de service distribus et des extorsions de fonds en change de
leur arrt, soit entre 15 000 et 45 000 euros. Les attaques avaient lieu lors des pics d'audience des
sites de paris, perturbant fortement leurs activits.
Cet exemple ne fait quillustrer le fait que cette nouvelle arme est maintenant utilise de plus en
plus couramment. Toutes les socits grant de l'argent sont menaces, aucune n'est l'abri. Toute
socit accessible par Internet est ouverte est potentiellement en danger. On remarque dailleurs le
nombre d'attaques de ce genre augmente chaque anne.

2. Le Syn Flooding
Parmi les attaques prcdemment cites, nous nous sommes principalement focaliser sur les
attaques de type Syn Flood pour saturer un service en l'inondant de requtes. Sa mise en uvre a
requis l'utilisation d'attaques sous-jacentes comme l'IP-Spoofing, PING-Flood.

2.1. Nature de lattaque

Une connexion TCP s'tablit en trois phases (TCP Three Way Handshake). Le SYN Flooding
exploite ce mcanisme d'tablissement. Les trois tapes sont l'envoi d'un SYN, la rception d'un
SYN-ACK et l'envoi d'un ACK.

Figure 1 : Ouverture dune connexion en TCP (extraite de : www.commentcamarche.net).

Le principe est de laisser sur la machine cible un nombre important de connexions TCP en attentes.
Pour cela, le pirate envoie un trs grand nombre de demandes de connexion (flag SYN 1). La
machine cible renvoie alors les SYN-ACK en rponse au SYN reus. Le pirate ne rpondra jamais
avec un ACK, et donc pour chaque SYN reu, la cible aura une connexion TCP en attente dans une
file d'attente ou queue de message. Etant donn que ces connexions semi-ouvertes consomment des
ressources mmoires, au bout d'un certain temps, la machine est sature et ne peut plus accepter de
nouvelle connexion. Ce type de dni de service n'affecte que la machine cible.
Le pirate emploie gnralement l'IP Spoofing (cration de paquet IP avec une adresse source
falsifie) afin de masquer son identit. Cependant, puisqu'il usurpe l'identit d'une autre machine, il
lui faudra s'assurer que celle-ci ne rpondra pas aux SYN-ACK mis par la victime (on entend par
"rponse" une requte de type RESET prcisant que le SYN-ACK reu n'tait pas attendu).
Les machines vulnrables aux attaques SYN mettent en file d'attente, dans une structure de donnes
en mmoire, les connexions ainsi ouvertes, et attendent de recevoir un paquet ACK. Il existe un
8

mcanisme d'expiration permettant de rejeter les paquets au bout d'un certain dlai. Nanmoins,
avec un nombre de paquets SYN trs important, si les ressources utilises par la machine cible pour
stocker les requtes en attente sont puises, elle entre dans un tat o elle ne peut fournir le service.

2.2. Ralisation de lattaque

Nous avons mis en uvre une attaque SYN FLOODING par le biais d'un serveur web apache. Ce
dernier prsente l'avantage de fonctionner sous diffrentes plates-formes telles que Windows et
Linux, ce qui nous a permis de raliser des tests varis.
Lors du premier test, nous avons utilis apache sur une machine Linux. Le but tait de rendre ce
serveur indisponible lors de la demande de page web par des clients. Pour ce faire, nous avons
utilis l'outil HPING, un utilitaire gratuit (http://www.hping.org) qui permet de remplacer la
commande ping en lui rajoutant plusieurs fonctionnalits et notamment l'envoi de requtes TCP ou
UDP suivant diffrents paramtres :

intervalle entre les paquets,

adresse source,
adresse destination,
taille des paquets,
les flags,
etc.

Bien utilis, HPING permet d'effectuer un dni de service avec par exemple la commande suivante:
hping3 -i u10 192.168.0.11 -p 80 -S

qui envoi l'adresse 192.168.0.11, sur le port 80, des paquets de type SYN l'intervalle de 10
micro-secondes.
Mais avant tout, pour raliser une attaque, la premire tape consiste scanner les ports ouverts
d'une machine donne pour en chercher les vulnrabilits. Pour cela, nous avons utilis l'outil nmap:
nmap -p 1-100 192.168.0.11

Cette commande effectue le scan des ports 1 100 de la machine 192.168.0.11.

Comme nous l'avons dit prcdemment, un pirate masque gnralement son identit en falsifiant
l'adresse IP source des paquets qu'il envoie. Egalement il doit s'assurer qu'il n'y aura pas de rponse
de la part de la machine qui on a emprunt l'adresse IP.

Figure 2 : Attaque SYN Flood (extraite de http://www.student.montefiore.ulg.ac.be/).

Il a donc le choix d'usurper l'identit d'une machine existante, auquel cas il doit l'empcher de
rpondre ; ou d'employer une adresse qui n'est pas attribue, il n'y aura donc aucune machine pour
rpondre la victime.
Si une machine dont l'IP a t usurpe venait recevoir les SYN-ACK provenant de la victime,
cest dire des paquets inattendus, elle y rpondrait par un RST, ce qui mettrait fin la connexion
en attente et librerait les ressources (empchant donc l'attaque de se raliser correctement).
Pour s'en assurer, le pirate doit donc inonder la machine cible avec une norme quantit de SYN,
tout en sachant que la machine usurpe tait toujours active sur le rseau ; nous avons pu constater
que quelque soit le nombre de SYN envoy, la cible parvenait toujours traiter les RST reus et
donc librer les ressources, ce qui prouve en effet qu'il faut rduire au silence la machine usurpe
pour qu'elle n'envoie aucun RST.
Mise en pratique :
Notre environnement de travail se composait de 3 machines du rseau local 192.168.0.10 :
192.168.0.10 : la machine attaquante,
192.168.0.11 : la machine cible de l'attaque et son serveur web apache,
192.168.0.12 : une machine dont on usurpe l'identit,
Avec lutilitaire HPING, nous pouvons crer des paquets avec le flag SYN positionn et les envoyer
trs rapidement grce la commande suivante :
hping S i u10 p 80 a 192.168.0.12 192.168.0.11

Largument S demande le positionnement du flag. Le second argument i prcise lintervalle entre

deux envois (ici en micro secondes). Le troisime p spcifie le port destination. Le quatrime a
dsigne une adresse source. Le dernier, enfin, donne ladresse destination.
En pratique, pour une attaque grandeur nature, il faut viter que la machine dont nous avons
usurp l'identit ne puisse rponde la machine attaque. Mais dans le cadre de notre projet, nous
10

avons fait une attaque dans un rseau local, il nous a donc suffit de dconnecter la machine dont
nous avons usurp l'identit pour l'empcher de rpondre la machine attaque, et donc l'empcher
de librer de l'espace mmoire.

2.3. Rsultats de lattaque

Nous avons pu constater que, lorsque lattaque est bien effectue, le serveur Web est compltement
hors service, il est impossible dobtenir une page provenant de celui-ci. Lattaque demande
cependant un certain temps avant de consommer toutes les ressources du systme (durant nos tests,
cette priode t estime entre 5 et 20 secondes suivant la configuration de la machine). Cette
attaque fonctionne aussi bien sur Linux que sur Windows.
Il est ncessaire de se rendre compte de la simplicit de mise en uvre de cette attaque. Un utilitaire
disponible gratuitement et assez rpandu et simple d'utilisation permet de mettre hors service un
serveur non protg en seulement quelques secondes.

2.4. Mesures de protection

2.4.1. Paramtres rseaux du noyau linux
Le noyau utilise de nombreux paramtres qui peuvent tre ajusts en diffrentes circonstances. Bien
que les paramtres par dfaut puissent convenir, il peut tre avantageux d'en modifier certains pour
contrer, ou tout du moins limiter l'impact d'une attaque DOS sur une machine.
Une premire mesure pour diminuer l'impact d'une attaque DOS est de modifier certains paramtres
propres aux connexions TCP: le tcp_max_syn_backlog situ dans le fichier :
/proc/sys/net/ipv4/tcp_max_syn_backlog

Le tcp_max_syn_backlog correspond au nombre maximum de requtes d'une connexion

mmorise, qui n'avait pas encore reu d'accus de rception du client connect. La valeur par
dfaut est de 1024 pour des systmes avec plus de 128 Mo de mmoire et 128 pour des machines
avec moins de mmoire. Si un serveur souffre de surcharge, on peut essayer d'augmenter ce
nombre.
L'autre paramtre modifiable est le tcp_keepalive_intvl qui se trouve dans le fichier:
/proc/sys/net/ipv4/tcp_keepalive_probes

Ce nombre correspond au temps d'attente avant retransmission d'une requte qui n'a pas t
acquitt. Il est de 75 secondes par dfaut. On peut le paramtrer 30 secondes par exemple.
2.4.2. SYN-cookies
Le problme dans l'attaque de SYN FLOODING est le remplissage de la file d'attente des
connexions moitis ouvertes. A chaque fois qu'un paquet SYN est reu les informations
concernant la connexion sont stockes dans une file. Une fois que l'attaquant envoy un nombre
suffisant de paquets SYN la file se rempli compltement et de nouvelles connexions ne sont plus
possibles, ce qui engendre l'indisponibilit du service. Il faudrait donc supprimer cette file d'attente.
Le serveur n'a en fait pas besoin de stocker les informations de la connexion, contenues dans le
paquet SYN (adresse IP et port du client et du serveur), vu qu'elles sont galement prsentes dans le
paquet ACK envoy par le client.
Un paquet ACK doit avoir les caractristiques du paquet SYN/ACK envoy par le serveur aprs une
demande de connexion. Ces informations sont les suivantes : adresse IP et port du client, adresse IP
et port du serveur, numro de squence du client, numro de squence du serveur. Ce dernier est
choisi par le serveur. Le but est de choisir ce numro en fonction des autres informations qui restent
11

identiques pour le paquet SYN initial et le paquet ACK du client. Il suffit ensuite de ne traiter les
paquets ACK dont le numro de squence du serveur correspond une fonction des autres
informations prsentes dans ce paquet (adresses IP, ports). On a donc insr des informations dans
le numro de squence du serveur, il n'y a donc plus besoin de stocker les informations de la
connexion dans une file d'attente.
Le numro de squence est calcul de la manire suivante :
les 5 premiers bits valent t mod 32 o t est un compteur temporel allant de paire avec un
secret.
les 3 bits suivant correspondent au MSS (Maximum Segment Size) slectionn par le
serveur. Cet encodage est indispensable puisque le serveur ne conserve pas ltat de la
connexion en cours de compltion et oublie donc plusieurs options TCP comme le MSS, le
window scale etc.
les derniers 24 bits correspondent au secret slectionn par le serveur.
Ce secret est un hash MD5 de ladresse source, de ladresse de destination, du port source, du port
de destination et enfin du compteur t.
Les SYN-cookies ne sont en fait activ que lorsqu'un flood est dtect, c'est--dire lorsque la file
d'attente des paquets SYN est pleine. Avant cela les demandes de connexions sont traites de
manire tout fait classique. Grce cette technique le service inond de paquets SYN continuera
rpondre aux demandes de connexions licites.
Les SYN-cookies sont implments dans le noyau Linux ainsi que dans FreeBSD mais pas activs
par dfaut. Ils ne sont pas prsents sous Windows mais il existe d'autres faons de se protger de
cette attaque sur ce systme.
Malheureusement les SYN-cookies ne sont pas compatibles avec certaines options TCP, notamment
celles spcifies dans les paquets SYN d'tablissement de connexion, vu qu'ils ne conservent aucun
tat avant la compltion effective de la connexion. Par exemple, un encodage du MSS dans le
paquet SYN t adapt en utilisant 2 bits de numro de squence pour reprsenter 4 valeurs MSS
communes prdfinies. Il ne peut pas non plus retransmettre de paquet SYN/ACK en cas de
disparit d'tats entre le client et le serveur d des pertes par exemple. C'est principalement pour
cette raison qu'ils ne sont pas activs par dfaut. Ils ne devraient l'tre que sur des serveurs
susceptibles d'tre victime d'une attaque de SYN flooding.
Un autre inconvnient des SYN-cookies est qu'ils utilisent un peu plus le CPU qu'une connexion ne
les utilisant pas, vu quils doivent gnrer un numro de squence en utilisant certaines
informations du paquet SYN (adresses IP, ports). Mais cela reste raisonnable, ce n'est qu'une petite
contrainte.
Enfin, tant donn que l'authentification de la connexion est base uniquement sur la valeur du
champ d'acquittement du paquet ACK envoy par le client, si un attaquant arrive deviner le
protocole d'authentification utilis par le serveur, il peut se faire passer pour n'importe qui. De plus
il peut galement inonder de paquets ACK le serveur pour tenter de crer une connexion. Et enfin,
un serveur utilisant des syncookies ne pourra pas effectuer un filtrage de paquets ACK, ce qui peut
permettre ventuellement un attaquant de passer travers un pare-feu qui filtre les
paquets SYN de demande de connexion.
Pour activer les SYN-cookies :
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Pour les dsactiver :

echo 0 > /proc/sys/net/ipv4/tcp_syncookies

12

2.4.3. Firewall
Les firewalls sont des quipements rseaux qui permettent de filtrer les paquets entrants et
sortants afin de prvenir toutes attaques de lextrieur. Ils se basent sur un fonctionnement
squentiel et un ensemble de rgles pour autoriser seulement les connexions lgitimes. Dans le
cadre des DoS, le problme majeur est que les attaquant utilisent des connexions lgitimes pour
perptrer leurs attaques. De plus, les firewalls ne peuvent pas efficacement diffrencier les
connexions lgitimes et illgitimes. Par contre ils peuvent se rvler trs efficace pour contrer un
attaquant. En se basant sur les informations fournis par des quipements de dtections, on peut
appliquer des rgles trs prcises qui bloqueront uniquement les connexions malfaisantes, en se
basant sur le protocole, lIP ou le port.
De nombreux firewalls hardware ou software permettent de se prmunir contre les attaquants. Parmi
eux, un des plus courants est le firewall intgr au noyau Linux : Netfilter et son interface iptables.
Il prsente lavantage dtre open source donc gratuit et dtre assez facile apprhender. De plus,
cela na aucune influence sur sa puissance et sa modularit.
Quelques exemples de rgles simples pour bloquer certaines attaques :
TPC syn flood:
iptables -A INPUT -p tcp --syn -m limit --limit 1/second -j ACCEPT

UDP flood:
iptables -A INPUT -p udp -m limit --limit 1/second -j ACCEPT

PING flood:
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT

Bien matriser un firewall peut tre une trs bonne protection contre la majorit des attaques et des
attaquants. Il est ncessaire de surveiller les connexions qui transitent sur son rseau pour tre
capable de bien se protger contre toutes menaces.
2.4.4 Des moyens de prventions
2.4.4.1 La dtection
Nous avons vu prcdemment qu'il est trs facile de mettre en place une attaque de type dni de
service qui soit efficace. Pour se prmunir de ces attaques, on doit pouvoir tre capable de dtecter
de manire efficace une attaque. Cependant, il peut tre difficile d'identifier un paquet licite d'un
paquet provenant d'un attaquant. Mais il existe plusieurs outils qui permettent avec plus ou moins
d'efficacit de dtecter/bloquer une attaque.
2.4.4.2 Les IDS
Un IDS (Intrusion Detection System) est un outil ou un ensemble d'outil dont l'objectif est de
surveiller le trafic entrant et sortant du rseau, dans le but de dtecter une attaque ou une intrusion
dans le systme et dclencher diffrentes alertes en fonction de sa configuration. Un IDS analyse le
rseau en temps rel, il ncessite donc des ressources matriels mais aussi en bande passante.
Il existe deux types d'IDS:
Les NIDS (Network Based IDS) assure la scurit au niveau rseau. Il va donc couter tout le trafic
du rseau et gnrer des alertes en cas de comportement anormal. Il se peut que l'on place plusieurs
NIDS dans le rseau comme le montre le schma suivant:

13

Figure 3 : NIDS (extraite de : www.commentcamarche.net).

Le premier IDS analyse tout le rseau entrant pour dtecter toute tentative d'attaque, et la seconde
analyse les requtes qui ont franchis le premier IDS et le pare-feu, ou bien les requtes internes au
rseau.
Un NIDS ncessite donc beaucoup de ressources, en CPU notamment, ainsi qu'une force bande
passante capable de supporter l'ensemble du trafic du rseau.
Le HIDS (Host Based IDS) rside sur une machine en particulier et non sur tout un rseau. Il est
ainsi considr comme un simple service, ou un dmon d'un systme. Le HIDS analyse le trafic de
la machine hte pour dceler des intrusions ou des attaques (dni de service par exemple). A la
diffrence de l'NIDS, l'HIDS ncessite moins de ressources. Cependant, l'HIDS se basant sur l'tat
du systme l'installation, il faut donc que ce systme soit sain pour prvenir tout risque d'intrusion.
Un autre inconvnient, si l'on doit installer plusieurs machines, il faudra installer plusieurs HIDS.
En revanche, un HIDS dtecte peu de faux positifs.
Les IDS fonctionnent en plusieurs temps:
1re tape: la capture du trafic.
Pour capturer le trafic, les IDS utilise la librairie libcap qui rend compatible l'IDS toutes les
plates-formes. L'IDS copie tout le trafic entrant puis utilise un filtre (par exemple Berckley Packet
Filter) pour rcuprer les informations utiles l'analyse de celui-ci.
2ime tape: l'analyse.
Nous avons vu prcdemment qu'il existe de nombreux types d'attaques, l'IDS procde donc une
analyse des scnarios d'attaques possibles. Tout comme un antivirus qui utilise une base de
signature de virus pour les dtecter, l'IDS une base de signature d'attaques ou rgles qui vont dfinir
le comportement avoir dans le cas d'un scnario donn. Tout comme l'antivirus, il faut donc que la
base de signatures d'attaques soit mise jour rgulirement pour pouvoir contrer les nouveaux types
d'attaques. L'analyse des scnarios permet de dceler les paquets illicites, par exemple dans le cas
d'une attaque de type Ping-Of-Death o la taille du paquet ICMP n'a pas la taille conforme sa
dfinition dans le RFC. On peut galement analyser le nombre de paquets entrant dans un port
donn; s'il dpasse un certain seuil donn (notablement dans le cadre d'une attaque SYN-FLOOD),
alors l'IDS peut lancer une alerte.
3ime tape: l'alerte.
Aprs avoir dcel un comportement illicite, l'IDS gnre une alerte qui est gnralement stocke
dans un fichier de journalisation. Il peut galement informer l'administrateur par mail qu'il a
dtecte un comportement suspect.
Mais aujourd'hui, les IDS ont tendance laisser leur place aux IPS (Intrusion Prevention System).
14

LIPS est un Systme de protection contre les intrusions et non plus seulement de reconnaissance et
de signalisation des intrusions comme la plupart des IDS le sont.
2.4.4.3 Les IPS
Le fonctionnement d'un IPS est similaire celui d'un IDS. Il capture le trafic du rseau puis
l'analyse. Mais au lieu d'alerter l'utilisateur d'une intrusion ou d'une attaque, l'IPS bloque
directement les intrusions en supprimant les paquets illgitimes. Pour informer l'utilisateur, l'IPS
peut aussi remplir un fichier de journalisation qui contiendra la liste des paquets supprims et
ventuellement un message indiquant la raison de cette suppression.
Cet outil est trs efficace pour contrer les attaques ou intrusions extrieurs mais possdes quelques
inconvnient:
Puisque l'IPS bloque ou supprime directement les paquets qu'il considre illgitimes sans en
alerter l'administrateur, il se peut que des faux positifs soient rejets par erreur, notamment si
le service est utilis trs fortement, l'IPS peut considrer qu'il subit un dni de service si ces
rgles sont mal dfinies.
Un autre inconvnient rside dans le fait que, dans le cadre d'un NIPS, si l'attaquant arrive
spoofer l'adresse IP d'un quipement du rseau, alors l'IPS bloquera cet quipement lorsqu'il
dtectera l'attaque. Mais il existe maintenant des techniques qui permettent d'viter ce genre
de problme, en crivant une liste des adresses IP ne pas supprimer.
Dernier inconvnient, lorsqu'une attaque et lance et arrte par l'IPS, celui-ci est dtect par
l'attaquant qui va essayer de contourner l'IPS.
C'est pourquoi les IDS sont plus utiliss que les IPS, bien que certains IDS ont des fonctionnalits
qui permettent de bloquer le trafic illgitime comme un IPS. C'est notamment le cas de Snort, l'IDS
que nous avons utiliss dans le cadre de notre projet.
2.4.4.4 Snort
Dfinition de snort:
Snort est un systme de dtection d'intrusion libre sous licence GPL. l'origine crit par Martin
Roesch, il appartient actuellement Sourcefire (dont l'acquisition par Check Point avait t prvue
en 2005 mais a t annule par la suite). Des versions commerciales intgrant du matriel et des
services de supports sont vendues par Sourcefire.
Snort est capable d'effectuer aussi en temps rel des analyses de trafic et de logger les paquets sur
un rseau IP. Il peut effectuer des analyses de protocole, recherche/correspondance de contenu et
peut tre utilis pour dtecter une grande varit d'attaques et de sondes comme des dpassements
de buffers, scans, attaques sur des CGI, sondes SMB, essai d'OS fingerprintings et bien plus.
Cependant, comme tout logiciel, Snort n'est pas infaillible et demande une mise jour rgulire.
Snort peut galement tre utilis avec d'autres projets open sources tels que SnortSnarf, ACID, sguil
et BASE (Basic Analysis and Security Engine) afin de fournir une reprsentation visuelle des
donnes concernant les ventuelles intrusions.
Source: http://fr.wikipedia.org/wiki/Snort

Fonctionnement de Snort:
Snort est compos de 4 blocs:
1. Le sniffer de paquets et le dcodeur se basent sur la librairie libpcap pour lire les trames qui
circulent sur le rseau
2. Le prprocesseur peut ensuite reprer les malformations, anomalies, etc. et les rparer.
15

3. Le moteur de dtection se base sur les flux normaliss et r-assembls pour reprer
d'ventuelles
4. Enfin, les vnements sont inscrits (logs au format unifi, base de donnes, etc.).

Figure 4 : fonctionnement de Snort.

A l'origine, l'IDS Snort avait une version modifie appele snort_inline qui transformait l'IDS en
IPS. Mais aujourd'hui, les deux projets ont t fusionns et l'installation de Snort, on peut lui
ajouter des options pour qu'il se comporte comme snort_inline, c'est--dire comme un IPS. Voici un
schma rcapitulatif du fonctionnement de snort_inline (devenu Snort aujourd'hui).

Figure 4 : Interaction entre Snort et iptables (http://openmaniak.com)

16

NetFilter est un module du noyau de Linux disponible depuis la version 2.4 du noyau. Il fournit
trois principales fonctionnalits:
- Filter : filtrage de paquet (Accepter ou rejetter des paquets)
-NAT :
change
la
source
ou
la
destination
IP
d'un
paquet
rseau
-Packet Mangling : Modifie les paquets (utilis par exemple pour la qualit de service, QoS)
Iptables est un outil permettant de configurer NetFilter.
Netfilter met dans une queue de message les paquets vers Snort_Inline qui n'ont pas t rejets par
iptables, dans l'espace utilisateur (user space) avec l'aide du module du noyau Linux ip_queue et
libipq. Puis, si un paquet correspond une signature d'attaque de Snort_Inline, il est marqu par
libipq et revient vers le noyau o est rejet.

2.5. Dtection de lattaque

2.5.1. Snort et la rgle de dtection
Pour dbuter, nous avons examin la rgle prsente par dfaut dans Snort pour les attaques de Syn
Flood. Malheureusement celle-ci tait sans intrt dans le cadre de notre attaque. Nous avons alors
cr notre propre rgle de base, que voici :
drop tcp any any -> 192.168.1.17 80 (msg : "Syn flood sucks but our rule rules!"; flow: stateless;
flags: S; sid:1000001;)

Notre rgle permet Snort de dtecter tous les paquets de demande de connexion vers la cible. Dans
notre cas, les critres de ces paquets sont:

paquets de type TCP

provenant de nimporte quelle source
destination de la cible 192.168.1.17 et du port 80
paquets vrifis quelque soit ltat de la connexion (flow: stateless)
paquets dont le flag SYN est positionn (flags: S)

Grce cette rgle, Snort supprime tous les paquets correspondant aux critres prcits. Cependant,
la plupart de ces paquets sont probablement licites, car appartenant au trafic normal. Etant donn
que le but est de dtecter un comportement anormal, cest--dire une grande affluence de demande
de connexions, nous avons ajout notre rgle la dfinition dun seuil de tolrance :
drop tcp any any -> any 80 (msg : "Attention attaque synflloding"; flow: stateless; flags: S;
detection_filter: track by_dst,count 10,seconds 1; sid:1000001;)

Nous avons donc dfini ce seuil grce au paramtre detection_filter . Celui-ci possde les options
suivantes :
count: spcifie le nombre doccurrences provoquant lalerte
seconds: spcifie lintervalle de temps
track: by_dst , vrifie le nombre doccurrences par destination
Le choix des paramtres du seuil
Le choix des paramtres se rvle fort important, dautant plus quils sont troitement lis. En effet,
il existe 2 politiques :
la premire consiste minimiser la valeur des paramtres, cest--dire choisir un nombre
doccurrences trs petit pour un intervalle de temps peu lev. Dans ce cas, lattaque est trs

17

rapidement dtecte. Malheureusement, lemploi de cette politique soumet la cible une

attaque consistant envoyer un nombre de paquet lgrement infrieur au seuil pendant
lintervalle de temps afin de ne pas dclencher lalerte. Le timeout de connexion tant trs
certainement suprieur lintervalle de temps, ces connexions resteront demi ouvertes et
continueront consommer de lespace mmoire. La difficult de cette attaque pour le
piratage est dapprcier la valeur exacte de ces paramtres.
La seconde politique consiste choisir un intervalle de temps suprieur ou gal au timeout
des connexions. Une attaque est alors dtecte assez tard car le nombre doccurrences doit
tre suffisamment lev pour correspondre ce grand intervalle de temps. En revanche,
lattaque prcdente (premire politique) ne pourra jamais se produire. Un autre avantage est
quun pic momentan de connexions ne sera pas dtect comme une attaque.
Il faut trouver un juste quilibre entre ces deux politiques pour viter les inconvnients qui leur sont
lis, do toute la complexit du choix du seuil. Chaque administrateur devra se baser sur les
caractristiques de son rseau et sur les besoins de ses clients, ceux-ci fluctuant trs souvent. Il lui
faudra se mettre jour rgulirement, cette technique de dtection ntant pas fixe.
La dtection du seuil critique par le pirate
Une fois la rgle du seuil correctement dfinie, il est logiquement impossible pour lattaquant de
crer un Syn Flood provoquant la non disponibilit du serveur sans tre dtect. Le pirate devra
donc choisir une alternative son attaque : soit utiliser un autre type dattaque, soit la faire voluer.
Quelle que soit lvolution de lattaque, il est fort probable que le pirate devra chercher connatre
le seuil de dtection afin de ne pas se faire dtecter.
Dtecter ce seuil avec des moyens informatiques sans tre dtect est pratiquement impossible car
le pirate va devoir dclencher au moins une fois lalerte pour observer les mesures en action lors de
la dtection. Par exemple, la mesure prise lors de la dtection dun flood de Syn est lactivation des
Syn Cookies, le pirate va alors monter graduellement son attaque et chercher un signe de cette
activation dans les rponses. Le plus simple est certainement de faire passer cette dtection pour une
fausse alerte ou un flood licite. Il reste bien sur la possibilit de profiter dune faiblesse humaine
pour obtenir ce renseignement.
Le pirate pourrait galement vouloir connatre le seuil critique. Il est tout fait possible de se servir
de lattaque afin de trouver la valeur exacte de ce seuil.
Pour connatre ces valeurs, nous avons utilis notre attaque en envoyant un nombre arbitraire de
paquets SYN au serveur web ; tout juste aprs, nous avons essay de nous y connecter avec un
navigateur afin de vrifier si de nouvelles demandes de connexions taient toujours acceptes.
Aprs une recherche graduelle, nous sommes arrivs aux valeurs cites prcdemment.
Ensuite, nous avons voulu valuer la valeur du timeout. Pour ce faire, nous avons envoy un
nombre de paquets SYN suprieur au seuil critique afin quaucune autre demande de connexion ne
soit accepte. Nous avons ralis des demandes de connexion l'aide du navigateur jusqu' ce
qu'elles soient acceptes, et nous avons dtermin un timeout denviron 20 secondes, tant sous
Windows que sur Linux.
Il est donc facile de dterminer les valeurs de ces variables au moyen de la seule attaque.
2.5.2. La technique de dtection des connexions semi-ouvertes
Linconvnient de la technique prcdente est quelle ne diffrencie pas les demandes de
connexions normales de celles provenant dun pirate. La technique comptabilise le nombre de
paquets Syn reus, sans se soucier que la connexion ait t tablie ou non. Une alerte a donc une
18

certaine probabilit dtre un faux positif .

Une tape suprieure serait de pouvoir dtecter les demandes de connexions rsultant dune attaque.
Ce qui caractrise ces demandes est que les connexions sont demi-ouvertes et le restent. Les
demandes de connexions normales sont gnralement rapides et ne restent ltat semi-ouvertes
que trs peu de temps.
Notre ide est donc de tenir en mmoire un compteur de ces connexions semi-ouvertes. Un seuil
dfinit le nombre de connexions semi-ouvertes que le systme tolre. Lorsque le compteur atteint le
seuil, il est raisonnable de penser que lon est sujet une attaque et quune majorit des connexions
semi-ouvertes en attente sont utilises pour lattaque.
Cette technique permettrait didentifier plus prcisment les connexions frauduleuses et de limiter
fortement le nombre de fausses alertes. Il faut maintenant voir si le cot de mise en place est
rentable : dans le cas dutilisation dun logiciel de dtection tiers, cela peut savrer aussi coteux
de dtecter lattaque que de la subir car il faut maintenir jour une table des connexions, ce qui est
exactement ce que le systme attaqu fait.
2.5.3. Des rgles supplmentaires
La technique de dtection des connexions semi-ouvertes peut savrer difficilement applicable. Il
faut donc chercher une nouvelle orientation. Il sagit de trouver ce qui caractrise un Syn Flood
frauduleux (<> Syn Flood cr par une grande affluence de clients) ; nous ne cherchons
maintenant plus dtecter les effets immdiats mais plutt les effets secondaires.
Dans certains cas de figure, le pirate ne peut empcher compltement la machine usurpe de
rpondre. Il reste donc certains paquets RST trahissant la prsence dune attaque. Notre rgle
dtecte donc un seuil anormal de paquet RST :
alert tcp any any -> 192.168.1.14 80 (msg:"RST"; flow:stateless; flags:R; threshold: type both, track
by_dst, count 100, seconds 20; sid:1000003;)

De mme, si le pirate emploie une adresse qui ne soit pas prsente sur le rseau, certains routeurs
sont configurs pour rpondre par un paquet ICMP de type host unreachable (il se peut que le
routeur rponde aussi avec des RST, ce qui empche la bonne ralisation de lattaque, nanmoins il
peut tre intressant de dtecter cette tentative) :
alert icmp any any -> any any (msg:"Host unreachable"; itype: 3; icode: 1; threshold: type both,
track by_dst, count 100, seconds 20; sid:1000002;)

Ces rgles elles seules ne suffisent pas mais elles permettent daffiner la diffrenciation des
bonnes alertes des mauvaises.

2.6. Raction de lattaquant

Une fois ces trois rgles dfinies, lattaquant na pas normment de possibilits. Sil arrive
dtecter le seuil, il pourrait rester en dessous afin de ne pas tre dtect et simplement ralentir le
trafic. Ceci ne sera plus valable ds quun trop grand nombre de clients se connectera, ce qui fera
atteindre le seuil et donc dclencher lalerte. De plus, ralentir le trafic nest pas vraiment satisfaisant
; cela ressemblerait seulement une priode de plus forte affluence, chose laquelle un serveur est
prpar.
Connatre le seuil peut cependant lui permettre de gnrer des alertes semblant fausses afin de crer
un relchement au niveau de la surveillance.

19

3. Les honeypots
Dans le cadre de notre projet TER du second semestre, nous avons choisi de nous intresser aux
honeypots ou pots de miel .
Un honeypot est une ressource de larchitecture de scurit dont le but est de se faire passer pour
une cible relle afin dtre attaque ou compromise. Autrement dit les honeypots sont des machines
de production destines attirer les pirates. Ceux-ci, persuads davoir pntrer le rseau, ont tous
leurs faits et gestes contrls.
Les diffrentes implmentations des honeypots reposent sur leur niveau dinteraction. Le terme
interaction dsigne linteraction entre le pirate et le systme pirat. Les honeypots sont
principalement diviss en deux catgories : les honeypots faible interaction et les honeypots
forte interaction :
Les honeypots faible interaction sont les honeypots les plus simples. Ils ne fournissent pas
de vritables services, ils se contentent de les simuler par lintermdiaire de script comme
Honeyd le propose et que nous allons utiliser par la suite.
Les honeypots forte interaction par contre fournissent de vrais services sur une machine
plus ou moins scurise. Nanmoins les risques sont trs nombreux puisque la machine est
trs vulnrable. Il faut donc sassurer que larchitecture sous jacente soit bien scurise.

3.1 Types de honeypots

Selon ce quon attend de lui, un honeypot peut tre de production ou de recherche :
1) Honeypot de production
Ce type de honeypots a une utilit pour la scurit active du systme pour lequel il est install. Il
droute les attaques orientes vers les diffrents services de production du systme, en les attirant
vers lui. Ainsi les honeypots de production rduisent le risque, en renforant la scurit qui est
assure par les autres mcanismes de scurit comme les firewalls, les IDS (systmes de dtections
dintrusions).
2) Honeypot de recherche
Ce sont des honeypots dont le souci nest pas de scuriser un systme particulier. Ils sont introduits
dans un environnement de recherche pour comprendre et tudier les attaquants et leur faon de
procder. Les renseignements tirs vont servir pour amliorer les techniques de protection contre
ces attaques.
Les deux types de honeypots jouent un rle dans une ou plusieurs composantes de la scurit qui
sont la prvention, la dtection, et le recouvrement.
Les honeypots de production contribuent la prvention du systme, en provoquant une dception
chez les attaquants, aprs plusieurs tentatives choues pour atteindre les ressources du systme. Et
ils sont aussi bnfiques pour la dtection, dans la mesure que toute connexion tablie avec un
honeypot de production est considre comme tentative dintrusion au systme, il limine ainsi
toutes les fausses alertes (positives et ngatives). Le rle des honeypots de production dans le
recouvrement se traduit par les deux points suivants :
premirement, ils permettent une continuit des services aprs une attaque produite en leur
sein, en les mettant simplement hors service.
deuximement, linformation enregistre par les honeypots de production sera dun apport
considrable pour le recouvrement du systme.
Les honeypots de recherche ne servent pas la scurit des systmes (prvention, dtection et
20

recouvrement) dune manire directe, mais ils offrent des renseignements prcieux sur les
attaquants et leur comportement. Ces informations permettent une meilleure connaissance de la
communaut des attaquants (blackhat community), ce qui aide les professionnels de la scurit
informatique dans lamlioration de mthodes et mcanismes de protection.

3.2 Les honeynets

Un honeynet est un rseau de systmes honeypots et un ensemble de mcanismes de scurit
comme les firewalls, les IDS, les serveurs log, etc. Il donne apparence tout un environnement de
production avec des failles et des informations pertinentes utilises comme appt pour attirer et
piger les attaquants. Toutes les actions de la victime seront surveilles et enregistres. Sa structure
de rseau permet mme davoir des renseignements sur les communications entre les attaquants et
leurs mthodes de collaboration.
Le fonctionnement dun honeynet se dcompose en trois oprations : le contrle de donnes, la
collecte de donnes et lanalyse de donnes.
Le contrle de donnes signifie un contrle de toutes les donnes dans le systme, mais
surtout le trafic sortant (outbound traffic) qui peut contenir des attaques envers dautres
systmes rels. Cela est assur par exemple par un firewall dissimul derrire un routeur, qui
utilise plusieurs techniques comme le blocage du trafic aprs un nombre limit de
connections. Ainsi le routeur reprsente une deuxime couche de contrle du trafic sortant.
La collecte de donnes dsigne la capture de toutes les informations qui se rapportent sur
lattaquant et ses activits. Elle est effectue sur trois niveaux : le firewall, les IDS, et les
systmes honeypots eux mme.
Lanalyse de donnes est lopration qui consiste extraire les informations recherches, telles que
les outils, les mthodes et tactiques utilises par les hackers, ou bien celles qui rvlent les
vulnrabilits existantes dans le systme. Cest partir des donnes collectes pendant lattaque, et
aprs leur analyse quon parvienne avoir ce type dinformations recherches sur le pirate et le
systme pirat.
Afin quil soit efficace et rentable pour lorganisation lutilisant, un honeypot doit tre,
constamment, surveill, maintenu, et mis jour. Car il est en exposition permanente aux attaques
qui ne sont pas toutes faciles contenir, surtout que les attaquants essaient toujours de surpasser les
mesures de scurit mises en place.

3.3 Honeynets virtuels

Un honeynet virtuel est un honeynet dont tous ses systmes honeypots sont installs sur une mme
machine qui fonctionne sous un systme dexploitation hte. Le mot virtuel vient du fait que chaque
systme donne apparence quil est install dans sa propre machine indpendante.
Les honeynets virtuels peuvent tre indpendants ou hybrides. Un honeynet virtuel indpendant
regroupe tout ses composants sur un mme systme physique (typiquement un firewall lentre et
un ensemble de honeypots), ce qui rduit le cot et le dlai de son dveloppement et facilite sa
connexion limporte quel rseau informatique. Tandis que un honeynet hybride est un hybride de
honeynet classique et de honeynet indpendant : les lments de capture de donnes (exemple :
firewall) et les lments de contrle de donnes (exemple : IDS) sont installs sur des systmes
isols, et les honeypots sont regroups sous un mme systme. Cette dernire solution est plus sre,
du moment que lattaquant ne peut pas semparer du firewall et de lIDS, et elle prsente lavantage
de supporter une multitude de types de logiciels et de matriel.
Entre autres plusieurs technologies qui permettent limplmentation dun honeynet virtuel, on cite :
VMware et User Mode Linux (UML)
21

 VMware est un exemple dinfrastructure logicielle pour le dploiement dun honeynet

virtuel. Il permet partir dun systme dexploitation principal appel systme hte
(HostOS) dinstaller dautres systmes dexploitation mulant des machines virtuelles
appels systmes clients (GuestOS). Il existe deux possibilits de connexion dune machine
VMware : la premire appel bridge networking dans laquelle le systme hte peut paratre
comme lune des machines virtuelles et chaque machine virtuelle a une liaison directe au
rseau. La deuxime consiste connecter que le systme hte au rseau (host only
networking) et chaque machine cliente nest accde que via ce systme hte.
User Mode Linux (UML) est un dispositif open source dvelopp par Jeff Dike, permettant
dexcuter plusieurs versions virtuelles de Linux, en mme temps, sur un mme systme.
Ainsi, il permet d'avoir plusieurs machines virtuelles sur une seule machine physique hte
excutant Linux. UML est capable de crer plusieurs rseaux virtuels et mme des routeurs
virtuels, qui seront tous dans le rseau virtuel original. Du mme que VMware, UML
supporte les deux possibilits de connexion : bridge networking et host only networking.

3.4 Avantages et inconvnients des honeypots

1) Avantages
Le but dun honeypot est de capturer un pirate et/ou de loccuper pendant un certain temps, temps
pendant lequel il ne sattaquera pas aux vrais systmes de production. Cest dans cette optique quil
est important de rappeler que les honeypots ne sont pas une solution que lon place pour rsoudre
un problme mais un outil exploiter. Ce sont des allis trs efficaces pour les IDS et sont des
solutions trs rapides mettre en place.
Enfin, utiliser un honeypot au sein dun rseau interne dune entreprise se rvle tre un outil
redoutable pour la dtection des actes de malveillance provenant de lintrieur.
2) Inconvnients
Puisque les honeypots doivent simuler des services et des systmes utiliss par les vrais systmes de
production, ils doivent tre attractifs afin de susciter lintrt sinon il sera ignor donc par
consquent inutile.

3.5 Quelques solutions existantes

Les solutions dcrites ci-aprs reprsentent des exemples pris dune trs longue liste de honeypots
disponibles actuellement.
BackOfficer Friendly (BOF), un honeypot simple faible interaction, dvelopp par Marcus
Ranum, fonctionne dans un environnement graphique (Windows ou Unix), il mule
quelques services de base comme : http, ftp, Telnet, mail, ou Back Orifice. BOF est capable
de dtecter toute tentative de connexion ou de scan des ports, et il a loption faking replies
qui consiste donner lattaquant des fausses rponses.
Honeyd est une solution honeypot faible interaction. Cest un systme OpenSource
dvelopp par Niels Provos, il fonctionne sur les systmes Unix, et port mme sur
Windows. Ce honeypot simule des services et mme des systmes dexploitation rels sur
des adresses IP non utilises d'un rseau. Trs complet et simple dutilisation, grce ses
fichiers de configuration, Honeyd vous permet dmuler un grand nombre de services, de
personnaliser les rponses aux connections, de simuler diffrentes stack ip pour tromper
lattaquant sur la version du systme dexploitation. Pour utiliser Honeyd, les trois modules
22

libevent, libdnet et libpcap sont ncessaires.

Mantrap est un produit trs complet propos par Symantec. Ce honeypot est de haute
interaction qui met en uvre quatre systmes dexploitation logiquement spars et qui sont
installs sur une mme machine hte. Chacun de ces systmes supporte des applications
relles, et apparat comme systme indpendant avec sa propre interface rseau.
Ladministration du systme hte se fait par une interface utilisateur graphique Java.
Mantrap peut tre utilis comme honeypot de production, notamment pour la dtection et la
raction, et il est aussi rentable dans la recherche, mais avec un risque considrable.
Nous utiliserons Honeyd dans le cadre de notre projet.

3.6 Honeyd
1) Test avec une commande ping
Aprs l'installation d'honeyd (voir annexe), nous allons lancer Honeyd en mode interactif pour
vrifier si un de nos htes configurs rpond la commande ping. Lanons Honeyd en mode
interactif. Pour ce faire taper dans la console :
honeyd -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f
/etc/honeypot/honeyd.conf -i lo 10.0.0.0/8

Maintenant dans un autre terminal nous allons tenter de pinguer un de nos htes configurs. Pour
cela il suffit de taper la commande suivante :
ping 10.3.0.1

Nous nous rendons compte que Honeyd a bien reu notre ping grce au Reply quon voit au niveau
du terminal o on a lanc notre Honeyd :

Figure 5 : capture dcran pour le fct de Honeyd.

23

2) Test avec une commande ping

Honeyd permet lutilisation de scripts pour muler un service fonctionnant sur une machine
virtuelle. Ce service peut tre un service telnet, ftp etc. Ces scripts peuvent tre crit en langage
PERL ou mme directement en SHELL. Des exemples de scripts sont fournis avec linstallation de
Honeyd. Ils sont disponibles dans le rpertoire scripts disponibles ladresse suivante:
/usr/share/honeyd/scripts

Il est possible de trouver de nouveaux scripts sur le site officiel ladresse suivante :
http://www.honeyd.org/contrib.php Il est important de ne pas oublier tous les droits dexcutions
aux nouveaux scripts aprs leurs tlchargements.
A prsent nous allons lancer Honeyd et vrifier si un de nos htes que nous avons configurs rpond
lappel dun script. Nous avons choisi dmuler un service Telnet donc nous tenterons daccder
un de nos htes configurs par le port 23.
honeyd -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f /etc/honeypot/honeyd.conf i lo 10.0.0.0/8

Dans une autre console nous allons tenter daccder un de nos htes sur le port 23. Pour cela taper
dans la console :
telnet 10.3.0.1 23

Nous pouvons nous rendre compte queffectivement Honeyd a bien reu notre tentative daccs au
port 23. Honeyd est entirement mis en place il est alors possible de leurrer des attaquants
potentiels.

Figure 6 : capture dcran pour le Honeyd avec une tentative de telnet.

3) Rsultat
Grce son systme de script nous pouvons aisment nous rendre compte que Honeyd est un
honeypot trs souple. Attention tout de mme car Honeyd na pas t conu pour fonctionner dans
un systme de production mais plutt dans le domaine de la recherche pour pouvoir amliorer
lavenir la scurit dun rseau.
24

4. Conclusion
Les attaques par dni de services existent depuis de nombreuses annes et sont parfois mdiatiss.
Elles ont su se dvelopps au fur et mesure du dveloppement des systmes informatiques, tout en
tant simple mettre en uvre. Bien quaujourdhui, il existe des outils de dtections et de
protection contre le dni de service, ils sont toujours complexes mettre en place avec une
efficacit pas toujours optimale. Avoir une multitude doutil ne suffit pas, il faut surtout tre ractif
lorsque lon subit une attaque, mais aussi avoir une bonne politique de scurit, non pas pour
supprimer totalement les risques, car le risque zro nexiste pas, mais au moins limiter limpact
dune attaque de type dni de service face au service que lon protge. Mais aujourdhui, les pirates
ont accs des ressources de plus en plus importantes, leurs attaques sont donc de plus en plus
difficiles contrer. La lutte contre les pirates nest donc pas prte de sarrter.

25

Rfrences
http://www.honeynet.org/
http://www.ubuntu-fr.org/
http://openmaniak.com/
http://www.ouah.org/hpin2.htm
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-4/syn_flooding_attacks.html
http://www.symantec.com/connect/fr/articles/hardening-tcpip-stack-syn-attacks
http://www.linux-france.org
http://www.commentcamarche.net
http://tomicki.net/syn.flooding.php
http://emergingthreats.net/
http://www.student.montefiore.ulg.ac.be/

26

Annexes
Installation de snort :
1re tape Installation de Libnet
Libnet est une librarie requise par snort. La version de snort utilize requiert la version 1.0.x de
Libnet et nous avons choisi la version 1.0.2a :
cd /usr/src
wget http://www.packetfactory.net/libnet/dist/deprecated/libnet-1.0.2a.tar.gz
tar xzvf libnet-1.0.2a.tar.gz
cd Libnet-1.0.2a
./configure
make
make install

2me tape : installation de snort

Loption enableinline de la configuration est requise pour activer le mode inline de snort et
lutiliser comme un IPS :
cd /usr/src
wget http://www.snort.org/dl/current/snort-2.4.5.tar.gz
tar xzvf snort-2.4.5.tar.gz
cd snort-2.4.5
./configure --enable-inline --with-libipq-includes=/usr/include/libipq
make
make install
Etape 3 : configuration de linstallation de snort
Utilisez les commandes suivantes pour crer les dossiers contenant les fichiers de configuration, les
rgles, et les fichiers de log utiliss par snort.
mkdir /var/log/snort
mkdir /etc/snort
mkdir /etc/snort/rules
cp /usr/src/snort-2.4.5/etc/* /etc/snort

Editez le fichier /etc/snort.conf avec la commande

vi /etc/snort/snort.conf

Modifier le fichier snort.conf pour que la variable RULE_PATH rfrence le nouveau fichier de
stockage des rgles

27

# Path to your rules files (this can be a relative path)

# Note for Windows users: You are advised to make this an absolute path,
# such as: c:\snort\rules
var RULE_PATH /etc/snort/rules
Linstallation de snort est maintenant termine mais ce stade, snort na aucune rgles avec
lesquelles fonctionner. Le tlchargement des rgles ncessite linstallation de loutil Oinkmaster.

Installation dOinkmaster

Il est ncessaire d'installer les rgles de signature Snort et de les maintenir jour. Il existe plusieurs
site maintenant des liste de signature.
apt-get install oinkmaster
Site officiel de snort (http://www.snort.org) : Pour tlcharger les rgles Snort, nous avons besoin de
crer un compte gratuit sur le site web de Snort. Une fois connect avec votre compte Snort, vous
pouvez obtenir un code en bas de page.
Ouvrir le fichier /etc/oinkmaster.conf :
sudo gedit /etc/oinkmaster.conf
Modifiez le paramtre "url" :
url = http://www.snort.org/pubbin/oinkmaster.cgi/code/snortrules-snapshot-2.8.6.tar.gz
Ajoutez la ligne suivante:
modifysid * "^alert" | "drop"
Cration du dossier de sauvegarde.
mkdir /etc/snort_inline/backup
Ajouter un utilisateur appel oinkmaster :
useradd oinkmaster
Dfinir les permissions :
chown -R oinkmaster /etc/snort_inline/backup
chown -R oinkmaster /etc/snort_inline/rules
chown -R oinkmaster /var/run/oinkmaster
chmod 644 /etc/snort_inline/snort_inline.conf
28

Teste du script oinkmaster :

su oinkmaster
oinkmaster#oinkmaster -o /etc/snort_inline/rules -b /etc/snort_inline/backup 2>&1
Mise jour automatique (chaque jour 00:30) :
crontab -e -u oinkmaster
30 00 * * * oinkmaster -o /etc/snort_inline/rules -b /etc/snort_inline/backup 2>&1

Installation de Honeyd

Pour installer Honeyd, nous avons utilis Aptitude, en tapant la commande suivante : apt-get install
honeyd. Voici les principaux fichiers installs :
/etc/init.d/honeyd
/etc/logrotate.d/honeyd
/etc/default/honeyd
/usr/lib/honeyd
/usr/share/honeyd
/usr/share/doc/honeyd
/usr/include/honeyd
/usr/bin/honeyd
Nous tenons rappeler quon a utilis Ubuntu 9.10 qui est une distribution
GNU/Linux libre et gratuite.
Linstallation de Honeyd va aussi installer les dpendances suivantes :
-libpcap0.8
-rrdtool
-librrd4
- libdumbnetl
-farpd
-honeyd-common
La libpcap est une bibliothque de fonctions servant dinterface la capture de
paquets et est indpendante du systme.
RRDtool est un outil de gestion de base de donnes RRD permettant la sauvegarde
haute performance et le trac de graphiques, de donnes chronologiques.
Libdumbnetl est une bibliothque rseau, portative qui fournit une interface
simplifie pour plusieurs routines rseau
Farpd est un dmon ARP rpondant nimporte quel dmon ARP dun ensemble
dadresses Ip.

1- Fichier de configuration
Le fichier de configuration utilis est similaire au fichier install par dfaut. Pour le
29

visualiser cest simple. IL suffit de prciser dans la console avec quel diteur on souhaite
le visualiser (gedit par exemple) et prciser le chemin du fichier. Voici la commande :
gedit /etc/honeypot/honeyd.conf

2- Mise en place
Dans cette section nous allons utiliser la configuration par dfaut propose par
Honeyd dans le fichier honeyd.conf visualiser prcedemment.
route entry 10.0.0.1
route 10.0.0.1 link 10.2.0.0/24
route 10.0.0.1 add net 10.3.0.0/16 10.3.0.1 latency 8ms bandwidth 10Mbps
route 10.3.0.1 link 10.3.0.0/24
route 10.3.0.1 add net 10.3.1.0/24 10.3.1.1 latency 7ms loss 0.5
route 10.3.1.1 link 10.3.1.0/24
Pour faire fonctionner ce rseau virtuel ci-dessus il faudra au pralable dclarer une
route relle dans la table de routage pour latteindre. La passerelle utilise pour cette
route sera linterface lookpack (localhost) afin de ne pas perturber le rseau existant.
Pour cela il faudra taper dans la console la commande suivante :
route add -net 10.0.0.0 netmask 255.0.0.0 gw localhost
Voici un shema montrant la configuration actuelle :

30

Excution
Lexcution de fait laide la commande qui suit dans notre console :
honeyd -d -p /etc/honeypot/nmap.prints -l /var/log/honeypot/honeyd.log -f
/etc/honeypot/honeyd.conf -i lo 10.0.0.0/8
Attention : Avant lexcution il est ncessaire de crer le fichier honeyd.log et de lui administrer
tous les droits. Ceci est possible en tapant dans notre console la commande suivante :
touch honeyd.log
chmod 777 honeyd.log
Les dtails des paramtres de lexcution :
-d signifie quon lance notre honeyd en mode interactif
-p fichier des fingerprints
-f fichier de configuration

Voici ce quon voit lcran. Ceci signifie que tout fonctionne bien. Faisons un ctrl+C pour
arrter la commande. Puis nous allons maintenant lancer notre dmon honeyd. Mais avant cela nous
31

allons diter et modifier le fichier de configuration du dmon.

Pour ce faire nous allons diter le fichier laide de la commande suivante :
gedit /etc/default/honeyd
Dans ce fichier de configuration, il faudra modifier la commande RUN en
lattribuant la valeur yes afin de pouvoir dmarrer le dmon :
RUN= yes
Il faut aussi indiquer linterface rseau utiliser et prciser la plage dadresse
rseau utiliser :
INTERFACE="eth0"
NETWORK=10.0.0.0/8
Nous allons pouvoir enfin lancer notre dmon Honeyd laide de la commande
suivante :
/etc/init.d/honeyd start
Sil ya pas derreurs on doit obtenir le message suivant :
* Starting Honeyd daemon honeyd

32