Le noyau a ´et´e directement modifi´e. Cette approche conf`ere `a notre impl´ementation
une bonne transparence. L’observabilit´e, quant `a elle, est assur´ee de mani`ere `a
pou-voir rejouer l’activit´e de l’intrus. Il nous est aussi possible de sapou-voir quels ont ´et´e les
programmes ex´ecut´es sur le syst`eme. Par contre, cette impl´ementation poss`ede des
inconv´enients. Tout d’abord, il nous est impossible de d´etecter l’ex´ecution de
pro-gramme exploitant la m´ethodeuserland-exec[rp05]
1(la d´etection est alors `a r´ealiser
`a partir des traces r´eseaux). Ensuite, nous limitons l’observation `a des activit´esssh.
L’utilisation par un intrus d’une porte d´erob´ee (en anglais, backdoor) permettant le
lancement de programme doit faire l’objet d’un traitement suppl´ementaire, sur la base
des traces r´eseaux (sous r´eserve que les communications entre la machine de l’intrus
et la porte d´erob´ee ne se fassent pas de mani`ere chiffr´ee).
3.5.5 Le m´ecanisme de redirection des connexions
La technique de redirection des connexions dans le cadre des pots de miel a fait
l’objet de beaucoup de travaux[XJ04, DMC06, BCW
+04]. Par exemple,
l’architec-tureCollapse, pr´esent´ee dans [XJ04], int`egre un m´ecanisme pour transf´erer le trafic
malveillant ciblant un syst`eme d’un r´eseau, vers un pot de miel nomm´e Collapse
Center. Cependant, ce m´ecanisme ne traite pas le probl`eme de la redirection du
tra-fic ´emis depuis le pot de miel et `a destination d’Internet. La probl´ematique trait´ee
dans [DMC06] est similaire `a la nˆotre. Toutefois, la solution propos´ee n’est pas
adap-t´ee `a notre objectif. Elle se cantonne `a la redirection de connexions bas´ees sur le
protocole TCP en utilisant la technique de vol de connexions (en anglais, hijacking).
De plus, cette solution n´ecessite la modification de la pile IP du pot de miel. Notre
impl´ementation se destine `a ˆetre compl`etement conforme avec le standard IP et, de
plus, `a ˆetre plus g´en´erale en acceptant le traitement de divers protocoles : TCP, UDP,
. . . . Nous pouvons aussi mentionner l’architecture hybride de pot de miel, pr´esent´ee
dans [BCW
+04]. Le m´ecanisme de redirection pr´esent´e dans ces travaux se destine `a
l’analyse de malware et de leur propagation. Cependant, peu de d´etails sont fournis
sur la mani`ere dont l’impl´ementation a ´et´e r´ealis´ee.
Notre m´ecanisme de redirection des connexions permet de donner l’illusion `a
l’atta-quant de progresser dans son attaque sur Internet depuis un pot de miel en redirigeant
cet attaquant vers un autre pot de miel. Ce m´ecanisme est pr´esent´e, plus en d´etails,
dans [AAN
+07a]. Dans la suite, nous en expliquons l’impl´ementation r´ealis´ee sur un
syst`emeGnu/Linuxet dot´e d’un pare-feu. Pour ce dernier, notre choix s’est port´e sur
Netfilter, pare-feu du noyau install´e par d´efaut sur ces syst`emes.
Netfilter peut ˆetre vu comme un ensemble de 5 chaˆınes : INPUT, OUTPUT,
FOR-WARD,PREROUTINGetPOSTROUTING. Chacune correspond `a un point du parcours d’un
paquet dans la pile r´eseau du syst`eme d’exploitation. La chaˆıne qui nous int´eresse
correspond au traitement d’un paquet juste avant qu’il passe dans l’algorithme de
routage :PREROUTING. Lui attacher une extension nous permet le confinement de
l’ac-tivit´e des attaquants en redirigeant les connexions sortantes vers d’autres machines.
1
La technique userland exec permet la cr´eation d’un processus sur un syst`eme `a partir d’un fichier
ex´ecutable disponible sur un autre syst`eme. L’ex´ecution se fait via le r´eseau sans stocker le fichier ex´ecutable
sur la machine cible.
CHAPITRE 3. D´EVELOPPEMENT D’UN POT DE MIEL HAUTE INTERACTION
Cette extension est impl´ement´ee sous la forme d’un module de redirection (cf. figure
3.8). L’enregistrement de ces machines aupr`es du m´ecanisme est n´ecessaire. Il est
r´ea-lis´e depuis l’espace utilisateur pour plus de souplesse. De la sorte, le noyau n’a pas `a
ˆetre modifi´e pour ajouter une nouvelle machine dans le m´ecanisme de redirection. De
plus, l’utilisateur doit pouvoir configurer le m´ecanisme de redirection pour ne
trai-ter que certaines connexions. Pour chacune, le choix entre bloquer et rediriger et le
choix de la machine vers laquelle rediriger la connexion peuvent ˆetre d´eterministes ou
al´eatoires. Cette logique de fonctionnement est plus simple `a d´evelopper au niveau de
l’espace utilisateur qu’au niveau de l’espace noyau. L’impl´ementation est donc
r´epar-tie entre l’espace noyau et l’espace utilisateur. Le but de la parr´epar-tie de l’impl´ementation
localis´ee dans l’espace noyau est de d´eclencher la demande de redirection pour les
nouvelles connexions qui nous int´eressent. Quant `a la partie localis´ee au niveau de
l’espace utilisateur, son but est de d´eterminer la mani`ere de traiter la demande de
redirection. La figure 3.8 pr´esente l’architecture du m´ecanisme de redirection. Dans
la suite de cette section, nous expliquons plus en d´etails les deux parties constituant
le m´ecanisme.
La partie de l’impl´ementation localis´ee au niveau de l’espace utilisateur est
com-pos´ee de deux entit´es : le dialog tracker et le dialog handler. La premi`ere entit´e joue
le rˆole d’interface entre notre module de redirection et la logique de fonctionnement.
Plus pr´ecis´ement, elle traduit les informations envoy´ees depuis notre module de
re-direction pour les rendre compr´ehensible par la logique de fonctionnement. De cette
mani`ere, la portabilit´e vers d’autres syst`emes peut ˆetre envisag´ee. La deuxi`eme entit´e,
le dialog handler, correspond `a la logique de fonctionnement. Elle est responsable de
la prise de d´ecision du devenir d’une connexion : soit cette connexion est bloqu´ee, soit
elle est redirig´ee. Les machines potentiellement destinataires d’une redirection et des
r`egles de redirection sont enregistr´ees au niveau de cette entit´e. Les r`egles permettent
de guider la prise de d´ecision en fournissant la m´ethode `a employer, al´eatoire ou
d´eter-ministe, en fonction des caract´eristiques de la connexion. Ainsi, lorsqu’une connexion
est initi´ee depuis le pot de miel `a destination d’Internet, notre module de redirection
avertit le dialog tracker, qui traduit le message pour ledialog handlerqui, `a son tour,
d´ecide du devenir de cette d´ecision et de la machine vers laquelle rediriger si besoin.
Apr`es la prise de d´ecision, le dialog handlerinforme le dialog tracker du r´esultat qui,
`a son tour, informe notre module de redirection.
Aucune recompilation du noyau n’est n´ecessaire pour le d´eveloppement du
mo-dule de redirection. Il joue le rˆole d’interm´ediaire entre le pare-feu et la partie de
l’impl´ementation localis´ee au niveau de l’espace utilisateur. Il s’enregistre aupr`es du
pare-feu afin de traiter le premier paquet de chaque connexion. Le suivi de connexion
conntrack offert par le pare-feu nous assure que les paquets suivants subissent le
mˆeme traitement que le premier. Le m´ecanisme de translation d’adresses, nat, rend
effectif la demande de redirection d´eclanch´ee par le module de redirection. Pour les
autres connexions, ce module sollicite les entit´es de l’espace utilisateur, attend la
r`egle associ´ee et traite lui-mˆeme la connexion avec cette nouvelle r`egle. Pour faciliter
la communication depuis l’espace noyau vers l’espace utilisateur, nous utilisons la
li-brairielibnetfilter_queue. Pour la communication inverse, c’est-`a-dire pour l’ajout
de nouvelles r`egles, nous utilisons les socketsnetlink. A chaque retour d’information
depuis le dialog tracker, il m´emorise la r`egle `a utiliser. Ainsi, les connexions pour
les-quelles il est capable d’associer une r`egle sont directement trait´ees par lui-mˆeme, sans
Fig. 3.8 – Architecture du m´ecanisme de redirection des connexions
solliciter l’espace utilisateur. Les performances sont ainsi am´elior´ees.
3.6 D´eploiement
L’impl´ementation pr´esent´ee pr´ec´edemment `a permis la mise en place d’un
exp´e-rimentation au sein du laboratoire. L’objectif est d’analyser le comportement des
attaquants qui r´eussissent `a p´en´etrer le cœur du syst`eme. Le moyen qu’ils emploient
pour parvenir `a y entrer n’est donc pas aussi important que les activit´es qu’ils r´ealisent
dans ce syst`eme. Pour cette raison, nous avons choisi une vuln´erabilit´e simple : des
mots de passe simples pour les comptes accessibles par le service ssh. Aussi, le pot
de miel que nous avons d´eploy´e poss`ede un niveau de s´ecurit´e moyen. Si le niveau est
trop ´elev´e, nous empˆecherons l’observation de comportements int´eressants. Ensuite, si
le niveau de s´ecurit´e est trop faible, l’attaquant peut suspecter une anomalie et partir
sitˆot entr´e.
Pour le premier d´eploiement de notre pot de miel, nous avons uniquement mis en
Dans le document
Observation, caractérisation et modélisation de processus d'attaques sur Internet
(Page 96-99)