sages Router Advertisement et la r´eponse aux messages Router Solicitation sont laiss´ees `a la charge du d´emon radvd6.
6.2 Impl´ementation de NDprotector
6.2.1 Architecture des diff´erents composants
La Figure6.1illustre l’architecture de nos composants. Notre architecture est com-
pos´ee de plusieurs modules :
– le pare-feu netfilter redirige vers les diff´erents modules les messages NDP et les messages CPS/CPA. Cette redirection est configur´ee par le module de filtrage qui met en place les r`egles sur les diff´erentes interfaces ;
– un cache de voisinage local est mis en place. C’est dans celui-ci que sont stock´ees les informations suppl´ementaires relatives au voisin comme la valeur du dernier horodatage re¸cu. Comme nous avons d´ecid´e d’autoriser la cohabitation de nœuds s´ecuris´es et de nœuds non-s´ecuris´es (aussi appel´ee mode “mixte”), la duplication du cache de voisinage, d´ej`a pr´esent `a l’int´erieur du noyau du syst`eme d’exploi- tation, est n´ecessaire. Ainsi, nous pouvons garantir qu’un attaquant ne pourra mettre `a jour une entr´ee du cache de voisinage (du noyau) pour un nœud dont l’adresse est prot´eg´ee ;
– les messages NDP entrants sont envoy´es sur le module de traitement des messages NDP entrants. Les diff´erentes options de SEND y sont trait´ees et le message est v´erifi´e (v´erification de la CGA, de la signature, etc.). Si le message est valide, alors il est transf´er´e `a la pile r´eseau. Pour chaque message accept´e, l’entr´ee correspon- dante dans le cache de voisinage est mise `a jour. Si le mode “mixte” est activ´e, les messages non prot´eg´es ou dont la v´erification a ´echou´e seront ´egalement transmis `a la pile r´eseau et modifieront le cache de voisinage local, `a l’unique condition qu’ils n’´ecraseront pas une entr´ee existante dans la table de voisinage. Si le message re¸cu est un Router Advertisement, il peut donner lieu `a la cr´eation d’une adresse
CGA (proc´edure d’Autoconfiguration d’Adresse Sans ´Etat) qui sera r´ealis´ee par
le module de gestion des adresses CGA ;
– la g´en´eration, l’affectation, la suppression d’adresse CGA sur le nœud s’effectuent au sein du module de gestion d’adresses CGA. C’est ´egalement ce module qui lie l’adresse CGA `a la paire de cl´es associ´ee et qui inclut la g´en´eration de la signature num´erique ;
– les paquets NDP sortant sont redirig´es vers le module de traitement des messages NDP sortants. Le module ajoute les protections SEND aux messages (option CGA, option nonce, option horodatage, option signature RSA). Une fois cette op´eration effectu´ee, le message est r´eachemin´e vers la carte r´eseau ;
– le module de traitement du chemin de certification g`ere la partie concernant le chemin de certification. Si le nœud est un routeur, le module re¸coit les requˆetes 6. http://www.litech.org/radvd/
6 NDprotector : impl´ementation espace utilisateur des CGA et du protocole SEND CPS et ´emet les r´eponses CPA associ´ees. Si le nœud est un hˆote, il traite les r´eponses CPA re¸cues, les valide et les stocke dans le cache de certificats.
Système Messages NDP sécurisés Pile réseau Messages NDP Carte réseau Module de Filtrage NDprotector Trafic sortant Trafic non NDP
Trafic entrant Trafic non NDP
ip6tables
Messages NDP
Cache de voisinage (recopie locale)
Cache de certificats Messages CPS ou CPA (hôte ou routeur)
Module de traitement du chemin de certification
Module de gestion des adresses CGA
ip
Messages CPS ou CPA (hôte ou routeur) Module de traitement
des messages NDP sortants
Module de traitement des messages NDP entrants
Messages NDP
Netfilter
Figure6.1: Architecture de l’impl´ementation NDprotector
Le langage Python autorise la programmation orient´ee objet et la s´eparation du
code en modules. L’architecture pr´esent´ee Figure6.1se retrouve alors dans notre code
o`u chaque module est stock´e dans un fichier diff´erent.
D’un point de vue m´ethodologie, chaque module dispose d`es sa conception de tests unitaires. Ceux-ci sont effectu´es grˆace `a l’outil nose7. Ils nous permettent de d´etecter
tr`es rapidement des r´egressions dans le code et le logiciel de gestion de version git8
nous permet de d´eterminer quels changements r´ecents sont `a leurs origines.
6.2.2 Embryon de syst`eme de greffons
Comme nous le verrons dans le Chapitre8, certains de nos tests n´ecessitaient de mo- difier fortement le comportement de l’impl´ementation. Nous souhaitions ˆetre capables de fournir ces modifications `a l’utilisateur et lui laisser la possibilit´e d’activer ou non ces fonctionnalit´es.
L’ajout d’un syst`eme de greffons s’est tout naturellement impos´e. Dans la pratique, nous avons rajout´e des hooks dans chaque module afin de pouvoir ´etendre certaines fonctions cl´es.
7. http://somethingaboutorange.com/mrl/projects/nose/
6.2 Impl´ementation de NDprotector Notre syst`eme de plugins repose sur un jeu de capacit´es (ou capabilities) : chaque ca- pacit´e correspond `a l’ajout d’une ou plusieurs fonctions au sein d’un module sp´ecifique. Par exemple, la capacit´e filtering indique que le plugin modifie le module de filtrage. Un plugin peut disposer de plusieurs capacit´es, lui permettant d’ajouter des fonction- nalit´es dans autant de modules que n´ecessaire.
Le syst`eme de greffons ne pr´evoit des hooks et des capacit´es que dans les modules
o`u nous avons eu besoin de modifier pr´ec´edemment le comportement. Le syst`eme de
greffons s’´etendra alors au fur et `a mesure de la cr´eation de nouveaux greffons.
6.2.3 Distribution et packaging
Le code source de NDprotector est disponible sur un site web publique [NDp]. Nous
avons appliqu´e la licence BSD `a notre code. Ce choix permet `a n’importe quel individu de copier, modifier et redistribuer notre impl´ementation. Nous esp´erons que ce choix permettra `a terme l’inclusion de contributions ext´erieures.
Les archives incluent l’extension scapy6-send qui n’a, au moment de l’´ecriture de ces lignes, pas encore ´et´e int´egr´ee dans la branche principale du projet scapy.
Pour une installation facilit´ee, nous avons ´egalement g´en´er´e des paquetages pour les distributions Linux Gentoo, Debian et Ubuntu.
Paradoxalement, mˆeme si apr`es l’installation des paquets la configuration de ND- protector est tr`es simple, l’impl´ementation n’est pas encore prˆete `a ˆetre d´eploy´ee et manque actuellement de scripts d’initialisation.
6.2.4 Description du banc d’essai
Pour tester notre impl´ementation, nous avons mis en place un banc d’essai nous
permettant de tester les diff´erentes combinaisons de types de nœuds. La Figure 6.2
illustre la disposition du banc d’essai et indique les connexions entre les diff´erents nœuds. Ce banc d’essai est compos´e de :
– deux nœuds fonctionnant sous GNU/Linux configur´es en mode hˆote (hˆote 1 et hˆote 2), pour confirmer le bon fonctionnement des interactions d’hˆote `a hˆote ; – un nœud fonctionnant sous GNU/Linux configur´e en mode routeur (routeur 1),
pour tester les fonctionnalit´es avanc´ees de SEND, comme la d´ecouverte de che- min (´echange de messages Certificate Path Solicitation/Certificate Path Adverti- sement). Celui-ci repose sur le d´emon radvd pour le traitement des messages RS et l’´emission p´eriodique de messages RA ;
– un routeur Cisco plac´e en coupure nous permet de rester connect´e au r´eseau de T´el´ecom SudParis tout en bloquant les paquets IPv6 dans les deux sens (routeur Cisco). Cela permet d’´eviter que le r´eseau de T´el´ecom SudParis (disposant de l’IPv6) n’interf`ere avec nos tests mais ´egalement que nos tests ne perturbent pas nos voisins sur le r´eseau de T´el´ecom SudParis.
Le nœud assurant la fonction de routeur est connect´e `a l’Internet IPv6 via l’utilisa-
tion d’un tunnel IPv6 (encapsulation UDP). Ce tunnel est fourni par le broker SixXS9.
6 NDprotector : impl´ementation espace utilisateur des CGA et du protocole SEND
Hôte 1 Hôte 2
Internet IPv6 Internet IPv4
Routeur 1 (annonce préfixe IPv6) Routeur Cisco
(en coupure) d'accès IPv6Fournisseur Tunnel UDP/IPv4
Hub
Figure6.2: Configuration du banc d’essai
hˆote “mixte” hˆote non “mixte” routeur “mixte” routeur non “mixte”
hˆote “mixte” oui oui oui oui
hˆote non “mixte” oui oui oui oui
hˆote non SEND oui non oui non
routeur non SEND oui non - -
Tableau6.1: ´Echanges de messages test´es sur le banc d’essai (“oui” indique un succ`es de l’´echange ; “non” indique un ´echec)
Il nous permet d’annoncer via le d´emon radvd des pr´efixes sous-r´eseau routables et de v´erifier la connectivit´e des hˆotes `a plus d’un saut. De plus, cela nous permet de nous assurer que les hˆotes acqui`erent correctement la route vers le routeur par d´efaut apr`es la proc´edure d’Autoconfiguration d’Adresse Sans ´Etat.
Lors de l’utilisation du banc d’essai, nous avons pu v´erifier que notre impl´ementation
se comportait correctement. Le Tableau6.1montre que nous avons effectu´e des tests
entre chaque type de nœuds. Les ´echanges se comportent comme pr´evu : les nœuds “mixtes” communiquent avec les nœuds non prot´eg´es par SEND alors que les nœuds non “mixtes” ne communiquent pas avec les nœuds non prot´eg´es par SEND.