Rapport de projet professionnel Source Address Validation Improvement

Transcription

1 service émetteur : Télécom Bretagne date : 11 mars 2010 Contributeurs : David FAVA & Hervé MARTIN Rapport de projet professionnel Source Address Validation Improvement Projet professionnel réalisé dans le cadre des scolarités : Mastère spécialisé Réseaux et Services de Mobiles Mastère spécialisé Sécurité des Systèmes d Information

2

3 Sommaire SOMMAIRE... 3 A ETAT DE L ART SAVI CADRE Constat Modèle Optimisations MENACES DUES A L USURPATION D ADRESSE Vecteurs d attaque basés sur l usurpation Attaques aveugles Attaques non aveugles Solutions actuelles contre l usurpation Cas d un hôte vers un autre sur le même segment ou via un switch Cas des routeurs en amont Cas des PE Router Cas d un NNI Router vers un autre NNI Router Usurpation dans les segments de LAN Liage de l adresse à un port Techniques cryptographiques Considérations diverses Solutions actuelles pour la validation des adresses IP source UNE PREMIERE APPROCHE DE L IMPLEMENTATION DE SAVI Modèle conceptuel d un switch SAVI Proposition Implémentation dans une configuration DHCP Implémentation utilisant SEND (SEcure Neighbor Discovery) Implémentation utilisant ND (Neighbor Discovery) FIRST-COME FIRST-SERVE SOURCE ADDRESS VALIDATION FOR LOCALLY ASSIGNED ADDRESSES (FCFS-SAVI) Cadre d utilisation Spécifications de FCFS SAVI Structures de données Algorithme Traitement du trafic de transit Traitement du trafic local Configuration des ports Considérations de sécurité SOLUTION SAVI POUR DHCP Structures de données conceptuelles Attributs des binding anchors Mise en place des liens Définitions des états et des évènements Processus d espionnage des paquets de contrôle Machine à états finis Filtrage des paquets SEND-BASED SOURCE-ADDRESS VALIDATION IMPLEMENTATION

4 6.1 Structures de données Traitement du trafic Traitement du trafic de transit Traitement du trafic local à destination du dispositif SAVI Traitement du trafic local B MISE EN ŒUVRE DU PROJET INDUSTRIEL PROBLEMATIQUE ET EVOLUTIONS DU SUJET Problématique Evolution initiale du sujet Seconde évolution du sujet MISE EN PRATIQUE Choix logiciels Illustration association MAC/identifiant Illustration association MAC/IPv Mauvaise authentification Usurpation d adresse MAC Ajout d adresse IPv BILAN Difficultés rencontrés Difficultés d ordre matériel Difficultés d ordre logiciel Difficultés d ordre personnel Enseignements ANNEXES ANNEXE 1 - FCFS SAVI ANNEXE 2 - SAVI-DHCP ANNEXE 3 - SEND-SAVI ANNEXE 4 - LISTES DIVERSES Liste des illustrations Liste des références ANNEXE 5 - FICHIERS DE CONFIGURATION hostapd Fichier hostapd.conf Fichier hostapd.radius_clients freeradius Fichier eap.conf Fichier radiusd.conf Fichier users.conf Fichier wpa_supplicant.conf (client)

5 Il apparaît nécessaire aujourd hui, dans un souci constant d authentification et de nonrépudiation, de tenter de lier fortement l identité d un utilisateur à son adresse IP. L utilisation de différents protocoles et standards pourraient permettre de réaliser ce lien : le protocole Source Address Validation Improvement (SAVI), qui est en cours de définition à l Internet Engineering Task Force (IETF), a pour but principal d empêcher l usurpation d adresses IP («IP spoofing») en réalisant un lien «fort» entre l adresse logique (@IP) et le lien physique (numéro de port de raccordement et/ou adresse MAC de la station). Ce protocole permet également de filtrer les paquets IP sur l adresse source grâce à la création d un lien fort («binding anchor») entre l adresse IP de l utilisateur (rendu légitime grâce au «binding anchor») et le paramètre physique (numéro de port sur le switch de raccordement, adresse MAC, numéro de canal radio, index du VPN ) ; le Protocol for carrying Authentication for Network Access (PANA) défini notamment par les RFC 5191 et 5193 est un mécanisme de transport de l Extensible Authentication Protocol (EAP) au niveau réseau permettant l authentification de l accès au réseau entre un client et son réseau d accès. PANA est donc un protocole s appuyant sur la pile IP/UDP et permet de lier l identité d un utilisateur à plusieurs paramètres notamment à son adresse IP ; le port-based network access control (802.1X) défini par l Institute of Electrical and Electronics Engineers (IEEE) est un standard qui permet de restreindre l utilisation des ports d un réseau local afin de sécuriser les communications entre des dispositifs authentifiés et autorisés ; ce standard passe par l authentification de l accès au réseau lors de la connexion physique à ce réseau et permet de lier l identité d un utilisateur (celui qui s authentifie) à son port de connexion au réseau. L objectif du projet industriel est, dans un premier temps, d étudier théoriquement les protocoles mis en jeu afin de choisir l association la plus adaptée à la problématique, puis de mettre en place une maquette permettant d évaluer le protocole SAVI et enfin, en le couplant au protocole d authentification choisi entre le standard 802.1X et le protocole PANA, de tenter de lier une identité à une adresse IPv6. 5

6 A Etat de l art SAVI 1 CADRE Cette section est tirée du document draft-ietf-savi-framework-01(1) du 25 octobre 2010 publié sur le site de l IETF. 1.1 CONSTAT L usurpation (spoofing) d adresses IP source permet des phénomènes d imitation (impersonation) de dissimulation (concealment) et de redirection de trafic malveillant (malicious traffic redirection). Mais l architecture d internet ne permet pas d empêcher cette usurpation. De plus, l adresse IP source ne jouant aucun rôle dans l expédition d un paquet, elle peut être choisie par l expéditeur sans compromettre la délivrance du paquet. La validation de l adresse IP source peut avoir lieu à des granularités différentes : le filtrage d entrée (ingress filtering *BCP38+ (2)) est un standard pour la validation de l adresse IP source qui vérifie que le préfixe d une adresse IP source route vers le réseau en provenance duquel le paquet a été reçu. La validation plus fine de l adresse IP source serait bénéfique pour permettre de : localiser un hôte, l autoriser et l authentifier à partir de l adresse IP source identifier efficacement les hôtes au comportement déviant La méthode SAVI a été développée pour compléter l ingress filtering avec la validation, à une granularité la plus fine, d une adresse IP source individuelle et standardisée. Cette méthode empêche également un hôte d usurper les adresses IP source des autres hôtes attachés au même lien et se veut modulaire et reproductible (basée sur le réseau uniquement). 1.2 MODELE Une instance SAVI est placée sur le chemin des paquets envoyés par les hôtes et impose l utilisation par ces hôtes d adresse IP source légitimes conformément aux trois phases suivantes : identifier quelles adresses IP source sont légitimes pour un hôte en se basant sur la surveillance des paquets échangés par l hôte lier une adresse IP légitime à une propriété de la couche liaison sur laquelle fonctionne le réseau de l hôte ; cette propriété, appelée ancre de liaison (binding anchor) doit être vérifiable dans chaque paquet envoyé par l hôte et doit être plus difficile à usurper que l adresse IP source de l hôte imposer que les adresses IP source incluses dans les paquets correspondent aux binding anchors auxquelles elles ont été liées Point particulier : la méthode SAVI sera d autant plus efficace que l instance SAVI sera proche des hôtes ; par exemple, l instance SAVI pourra être placée dans le switch auquel sont attachés les hôtes dont les adresses IP source sont en cours de validation. Le déploiement de la méthode SAVI est conditionné par les deux aspects suivants : l identification des adresses IP source légitimes dépend de la méthode utilisée pour l attribution des adresses IP les binding anchors dépendent de la technologie d élaboration de la liaison sur laquelle elles sont utilisées Ainsi, la méthode SAVI possède de multiples variantes dépendantes de la méthode d attribution des adresses IP. Les cas traités dans ce document seront : First-Come First-Serve Source Address Validation for locally assigned addresses (FCFS-SAVI) (3) 6

7 SAVI Solution for DHCP (4) SEND-based Source-Address Validation Implementation (5) De même, la méthode SAVI supporte une gamme de binding anchors dont les impacts seront significativement différents quant à la sécurité qu elles fournissent. Ainsi, les binding anchor peuvent être : l identifiant unique (EUI-48 ou EUI-64) défini par l IEEE de l interface de l hôte le port d un switch Ethernet auquel un hôte est attaché l association de sécurité, sur une liaison sans fil, entre un hôte et la station de base d autres items non détaillés dans ce document 1.3 OPTIMISATIONS Afin de ne pas subir le facteur d échelle et donc réduire les exigences de mémoire pour les instances SAVI, chaque instance SAVI sera uniquement responsable de la validation des adresses IP source sur les ports auxquels les hôtes sont directement connectés (ou à travers de switch sans instance SAVI). Les switches implémentant SAVI forment alors un périmètre de protection. Remarques : la validation de l adresse IP source est activée sur tous les ports situés le long du périmètre de protection et désactivée sur les autres ports l intégration d un legacy switch dans le périmètre de protection permet que ce dernier soit unique et non partitionné ; les exigences en mémoire pour les instances SAVI sont ainsi minimisées car chaque lien n est stocké qu une seule fois par l instance SAVI relié à l hôte en cours de validation il est possible dans ce cas d intégrer le legacy switch dans le périmètre de protection car la topologie de niveau liaison représentée sur le schéma garantit que les paquets ne peuvent pénétrer le périmètre de protection via ce legacy switch 7

8 Figure 1 : concept de périmètre de protection Afin d être fiabilisée et de limiter les perturbations que peuvent engendrer des liens manquant pour des adresses IP légitimes, la méthode SAVI inclut un mécanisme pour la création réactive de liens à partir des paquets réguliers (data). Cette création a lieu lorsque des instances SAVI reconnaissent des suppressions excessives de paquets réguliers originaires de la même adresse IP : l instance SAVI vérifie alors si cette adresse IP est unique sur la liaison et si tel est le cas, elle lui crée un lien. 2 MENACES DUES A L USURPATION D ADRESSE Cette section est tirée du document draft-ietf-savi-threat-scope(6) du 8 septembre 2010 Le protocole internet (IPv4 [RFC0791](7) ou IPv6 [RFC2460](8)) emploie une méthode de transmission des paquets saut par saut en mode datagramme. Les hôtes générant des paquets à transmettre ont l opportunité de falsifier l adresse source figurant dans ces paquets et ainsi usurper une adresse source. La vérification des adresses source est devenue une nécessité afin de détecter et rejeter les paquets usurpés. Des solutions de filtrage d adresses source telles que BCP 38 [RFC2827](2) existent déjà mais ne font que du ingress filtering (filtrage à l entrée du réseau sur le préfixe de l adresse IP source). Les entreprises souhaiteraient mettre en œuvre cette protection localement et avec une meilleure traçabilité et ainsi empêcher les hôtes d un même sous-réseau local d usurper les adresses sources des autres hôtes. Cette partie dresse succinctement quelques détails concernant les vecteurs de menace basés sur l usurpation d adresse et traite des implications dues aux topologies des différents réseaux. 2.1 VECTEURS D ATTAQUE BASES SUR L USURPATION Deux classes de vecteurs d attaque sont à considérer : les attaques aveugles et les attaques nonaveugles 8

9 2.1.1 Attaques aveugles Les attaques aveugles ont lieu lorsque l attaquant n a pas accès à une source légitime ou au système cible. Quelques exemples d attaques aveugles sont listés ci-dessous : les attaques déni de service par paquet unique consistent à injecter une information usurpée dans le réseau dont la conséquence est soit un effondrement complet du système cible, soit une corruption de la configuration ou d une autre information du système cible de manière à impacter le réseau ou d autres services (exemples : LAND attack 1 ) les attaques déni de service par flooding (inondation) consistent à envoyer un grand nombre de paquets à travers un système cible afin de le rendre inaccessible ; ces paquets ont généralement une adresse IP source usurpée pour cacher la source réelle du système attaquant les vers et autres malware falsifient leurs adresses source avant de se propager vers d autres systèmes afin de cacher l adresse source du système qu ils ont infecté les attaques réfléchissantes qui utilisent une adresse source usurpée afin que les paquets envoyés engendrent des réponses multiples vers le système cible (exemple des attaques smurf : un message ICMP echo request avec une adresse IP source usurpée engendrant un grand nombre de messages ICMP echo response dirigés vers le système cible) Attaques non aveugles L attaque la plus connue dans cette partie est le Man in the Middle (MITM) 2.2 SOLUTIONS ACTUELLES CONTRE L USURPATION La première exigence est d éliminer d internet les datagrammes contenant des adresses source usurpées. Les sites pour lesquels une relation est possible entre l adresse source et la topologie du réseau ont l opportunité d identifier et d éliminer de tels datagrammes. Par exemple, certains dispositifs internet peuvent confirmer que : l adresse IP source est appropriée à l adresse de la couche inférieure (elles identifient le même système) l adresse IP source est appropriée au dispositif du port du switch de niveau 2 (l adresse a été attribuée au système qui utilise ce port) le préfixe auquel appartient l adresse IP source est appropriée à la partie de la topologie du réseau de laquelle le paquet provient 1 L'«attaque LAND» est une attaque réseau datant de 1997, utilisant l'usurpation d'adresse IP afin d'exploiter une faille de certaines implémentations du protocole TCP/IP dans les systèmes. Le nom de cette attaque provient du nom donné au premier code source (appelé «exploit») diffusé permettant de mettre en oeuvre cette attaque : land.c. L'attaque LAND consiste ainsi à envoyer un paquet possédant la même adresse IP et le même numéro de port dans les champs source et destination des paquets IP (source : 9

10 La figure 2 montre les quatre chemins sur lesquels une adresse source peut être validée : depuis un hôte vers un switch ou entre deux hôtes via le switch depuis un hôte vers le CPE router 2 de l entreprise depuis le CPE router vers le PE router 3 de l ISP 4 (et le chemin inverse) entre deux NNI router 5 de deux ISP différents En règle générale, les paquets contenant des adresses usurpées peuvent être détectés et détruits par des dispositifs qui autorisent les liens entre adresse IP et topologie du réseau. Le degré de confiance en l adresse source dépend de l emplacement de la détection de l usurpation et de l agrégation de préfixe mise en place entre cet emplacement et la source du paquet Cas d un hôte vers un autre sur le même segment ou via un switch Un paquet contenant une adresse usurpée peut être détecté au niveau du lien sur lequel la source du paquet est connectée : les adresses sources IP et couche liaison sont disponibles toutes les deux et peuvent être confrontées ; un paquet pour lequel l adresse IP source ne correspond pas à l adresse de la couche liaison peut alors être détruit. Quand deux hôtes sont connectés à travers un switch, l hôte source peut être précisément identifié en se basant sur le port à travers lequel le paquet est reçu ou sur l adresse MAC Cas des routeurs en amont Figure 2 : endroits où une adresse peut être validée Les routeurs situés en amont peuvent également filtrer le trafic en provenance des routeurs plus en aval. Cependant, comme ils n ont pas accès à l adresse couche liaison de l expéditeur du paquet, ils ne peuvent que confirmer que l adresse IP source contient un préfixe approprié aux routeurs en aval 2 Customer Premises Equipment Router : le routeur situé sur la bordure du réseau client (routeur de sortie) qui appartient soit au client soit au fournisseur d accès 3 Provider Edge Router : le routeur directement connecté au réseau du client d un fournisseur d accès 4 Internet Service Provider : fournisseur d accès internet 5 Network to Network Interface Router : le routeur d un ISP directement connecté au routeur d un autre ISP ou d un autre réseau plus vaste 10

11 et en provenance desquels le paquet a été reçu. Unicast RPF et Strict RPF 6 sont deux exemples de ce genre de filtrage et sont détaillés dans la RFC Cas des PE Router BCP 38(2) encourage spécifiquement les fournisseurs d accès à utiliser le filtrage d entrée (ingress filtering) pour limiter l incidence des adresses usurpées dans le réseau. Le problème est de savoir à quel point ils peuvent faire confiance aux routeurs des clients en aval et dans quelle mesure le fournisseur peut imposer à ses clients de mettre en œuvre le filtrage d entrée sur ses routeurs Cas d un NNI Router vers un autre NNI Router Les considérations sont ici les mêmes qu entre les routeurs d un fournisseur d accès et les routeurs d un client : chacun des fournisseurs d accès doit avoir la certitude que l autre fournisseur applique le filtrage d entrée et le fait appliquer à ses clients Usurpation dans les segments de LAN Dans un segment de LAN ou de multiples hôtes résident, il est nécessaire de lier l adresse IP à une adresse de niveau 2 (adresse MAC) afin de priver un attaquant de certains vecteurs d attaque tel que MITM Liage de l adresse à un port Une grande partie de la menace d usurpation d adresse dans un LAN peut être marginalisée en configurant les ports de manière à lier adresse IP et adresse MAC. Cette configuration peut être manuelle, automatique ou utiliser le protocole 802.1X(9) Techniques cryptographiques Le protocole SEND(10) emploie des techniques cryptographiques mais il est peu implémenté. Une méthode SAVI utilisant ce protocole est développée au paragraphe CONSIDERATIONS DIVERSES Les considérations suivantes sont à prendre en compte dans les éventuelles propositions d implémentation d une méthode SAVI : les différents mécanismes d attribution d adresse IP (manuel, dynamique ) les dispositifs avec plusieurs adresses (routeurs, NATs, hôtes multi-instances, hôtes multi- LAN, firewalls, hôtes mobiles ) concernant IPv6 : l auto configuration des adresses IP, l espace d adressage important 2.4 SOLUTIONS ACTUELLES POUR LA VALIDATION DES ADRESSES IP SOURCE Les techniques actuelles pour la validation des adresses IP source sont insuffisantes et possèdent toutes au mois l une des lacunes suivantes : faux-négatifs : ils permettent à un attaquant d utiliser une adresse IP source usurpée tout en réussissant la validation de l adresse IP source faux-positifs : ils causent une interruption de service pour les hôtes utilisant une adresse IP source légitime configuration non triviale : les risques d une mauvaise configuration décourage les opérateurs à utiliser une méthode de validation d adresse IP source propriétaire : les politiques des organisations encouragent les techniques standardisées et empêchent ainsi le développement de techniques propriétaires 6 Unicast Reverse Path Filtering et Strict Reverse Path Filtering 11

12 3 UNE PREMIERE APPROCHE DE L IMPLEMENTATION DE SAVI Cette section se réfère au document draft-baker-savi-one-implementation-approach-00 du 10 mai 2010 (EXPIRE le 11 novembre 2010). 3.1 MODELE CONCEPTUEL D UN SWITCH SAVI Figure 3 : niveau données d'un switch Ethernet Considérons le plan simplifié d un switch au niveau du traitement des données. Il y existe deux sortes de filtres : le port filter applique une politique aux datagrammes reçus sur un port, généralement en détruisant ou en autorisant les datagrammes sélectionnés la forwarding logic identifie l ensemble des ports vers lesquels une trame Ethernet d un port donné sera envoyée ; cet ensemble de ports peut être vide, ne correspondre qu à un seul port, un ensemble plus large ou même être constitué de tous les ports sauf celui par lequel est arrivé le datagramme Le modèle SAVI considère principalement le port filter. Son implémentation configure le port filter pour : identifier les datagrammes IPv6 [RFC2460](8) isoler les valeurs liées qui forment un sous-ensemble choisi parmi le port, l adresse MAC, et l adresse IPv6 source accepter les datagrammes IPv6 qui sont liés avec un des liens de la liste des liens spécifiés détruire tous les autres datagrammes IPv6 Tout dépend également des relations de lien entre les interfaces et les adresses qui peuvent être : configurées de manière statique dérivées de Stateless Address Autoconfiguration désignées par DHCPv6 12

13 3.2 PROPOSITION En temps normal, les tables de filtrage et de transfert ne requièrent aucune modification : le port filter et la forwarding logic s y réfèrent pour manipuler les datagrammes. Cependant, dans certains cas exceptionnels, le datagramme ou des informations le concernant sont mis en file d attente dans la control plane pour une analyse ultérieure. Ces cas pourraient inclure les informations concernant les échecs relatifs à SAVI sur les entrées du port filter. Figure 4 : les niveaux contrôle et données d'un switch Si le port filter ne reconnaît aucune concordance dans sa table, le datagramme est détruit mais une requête est mise en file d attente dans la Table Management Process afin de déterminer si une nouvelle concordance SAVI doit être ajoutée au port filter. Si c est le cas, le port filter est mis à jour par l ajout d un nouveau lien et quand le client retransmet son datagramme, il passe Implémentation dans une configuration DHCP Dans un réseau utilisant DHCPv6 [RFC3315](11), une source d information autorisée est disponible. L implémentation correcte dépend du traitement des informations données par DHCPv6 : la forwarding logic doit être configurée pour identifier les datagrammes DHCP et en envoyer des copies au table management process ; si le switch observe un datagramme en provenance du serveur DHCP autorisant un lien entre un port, une adresse MAC et une adresse IPv6 source, le lien est stocké dans le port filter du port considéré quand une adresse IPv6 source est utilisée par un client mais ne correspond à aucun lien, le table management process peut construire une DHCPv6 request semblant provenir du client pour l acquisition d une adresse ; si le serveur répond par l affirmative, l action précédente sera mise en œuvre Implémentation utilisant SEND (SEcure Neighbor Discovery) Dans un réseau utilisant SEND [RFC3971](10), un échange d informations autorisé est disponible. L implémentation correcte dépend du traitement des informations données par SEND : la forwarding logic doit être configurée pour identifier les messages SEND et en envoyer des copies au table management process ; si le switch observe une SEND Response prouvant les 13

14 certificats nécessaires pour autoriser un lien entre un port, une adresse MAC et une adresse IPv6 source, le lien est stocké dans le port filter du port considéré quand une adresse IPv6 source est utilisée par un client mais ne correspond à aucun lien, le table management process peut construire une Secure Neighbor Solicitation pour cette adresse : le client répondra au datagramme et l action précédente sera mise en œuvre Implémentation utilisant ND (Neighbor Discovery) Dans un réseau sans source d information autorisée, l implémentation correcte dépend de l observation d une implémentation correcte de Neighbor Discovery and Address Autoconfiguration [RFC4862](12). Quand une adresse IPv6 source est utilisée par un client mais ne correspond à aucun lien, le table management process devrait initier une multicast Neighbor Solicitation pour trouver le client utilisant cette adresse source ; trois cas peuvent survenir : aucun Neighbor Advertisement n est répondu : dans ce cas, l adresse n est pas une adresse IPv6 source et le lien ne doit pas être configuré un ou plusieurs Neighbor Advertisement sont répondus, dont au moins un est en provenance d un autre client : dans ce cas, l adresse source est usurpée et le lien ne doit pas être configuré un seul Neighbor Advertisement est répondu de la part du client considéré : dans ce cas, le switch stocke le lien indiqué par la réponse Remarque : ce modèle n est pas sécurisé mais il peut détecter des cas où une adresse ne possède aucun utilisateur actif ou de multiples utilisateurs 4 FIRST-COME FIRST-SERVE SOURCE ADDRESS VALIDATION FOR LOCALLY ASSIGNED ADDRESSES (FCFS-SAVI) Cette partie décrit un mécanisme pour fournir la validation de l adresse source dans un réseau Ipv6 en utilisant l approche «premier arrivé premier servi». Ce mécanisme est détaillé dans le document draft-ietf-savi-fcfs-05 du 25 octobre 2010(3). 4.1 CADRE D UTILISATION Le scénario d application de FCFS-SAVI est limité au lien local et à un trafic local ; les adresses sont configurées avec Stateless Address Autoconfiguration et aucun changement chez les hôtes ne doit être requis. La validation FCFS-SAVI est exécutée par la fonction FCFS-SAVI qui peut être implémentée dans un routeur ou un switch de niveau 2 mais doit être placée à des endroits clés de la topologie afin de pouvoir détruire les paquets non-conformes quant à l adresse source. La principale fonction effectuée par FCFS SAVI est de vérifier que l adresse source utilisée dans les paquets de données appartient réellement à l expéditeur du paquet. La preuve de la possession de l adresse est basée sur l approche «premier arrivé premier servi» (FCFS : first come first serve) : le premier hôte qui revendique une adresse source donnée devient le propriétaire de cette adresse puis un état est créé dans le dispositif implémentant la fonction FCFS SAVI qui lie l adresse source à l information de niveau 2 considéré (en l occurrence, les ports des switches du réseau pour FCFS SAVI). L approche FCFS SAVI repose sur quatre postulats : SAVI fournit une sécurité périmétrique : certaines interfaces d un dispositif SAVI sont connectées à la partie interne (fiable) de la topologie et les autres à la partie externe (non fiable) un dispositif SAVI vérifie uniquement les paquets venant par une interface non fiable un dispositif SAVI stocke uniquement les informations de lien pour les adresses source liées à des ancres de niveau 2 qui correspondent aux interfaces non fiables 14

15 SAVI utilise les messages NS (Neighbor Solicitation) et NA (Neighbor Advertisement) pour préserver la cohérence des états des liens SAVI distribués parmi les dispositifs SAVI à l intérieur d un domaine Dans la figure 5, le périmètre d application SAVI est fournit par les switches SAVI 1, SAVI 2, SAVI 3 et SAVI 4 qui vérifient les informations relatives à l adresse source dans les paquets de données et les paquets ND (Neighbor Discovery) et filtrent ces paquets en conséquence. Les dispositifs SAVI ont deux types de ports : les Validating Ports (VP) dans lesquels le traitement et le filtrage SAVI sont effectués ; les ports 1 et 2 de SAVI 1, 1 de SAVI 2, 4 de SAVI 3, 4 de SAVI 4 sont de VP les Trusted Ports (TP) dans lesquels le traitement SAVI n est pas effectué : les ports 3 et 4 de SAVI 1, 2 et 3 de SAVI 2, 1, 2 et 3 de SAVI 3, 1 de SAVI 4 sont de TP 4.2 SPECIFICATIONS DE FCFS SAVI Structures de données Figure 5 : périmètre d'application SAVI (FCFS SAVI) La fonction FCFS SAVI repose sur l information contenant l état du lien entre l adresse source des paquets de données et l information de niveau 2 que contient le premier paquet utilisant cette adresse IP source : cette information est stockée dans la FCFS SAVI Data Base (DB). Chaque entrée de la DB contient donc : l addresse IP source l information de niveau 2 (adresse de niveau 2, port) la durée de vie le status : tentative (provisoire), valid (valide) ou testing (en test) le moment de la création de l entrée (CT) FCFS SAVI doit également connaitre les préfixes directement connectés et tient donc à jour une FCFS SAVI prefix list contenant : le prefix 15

16 l interface sur lequel le préfixe est directement connecté Algorithme Point particulier : afin de différencier le trafic local du trafic de transit, le dispositif SAVI s appuie sur la FCFS SAVI prefix list et doit supporter les deux méthodes d attribution de préfixe que sont la configuration manuelle et la configuration par Router Advertisement [RFC4861](12) Traitement du trafic de transit Si le paquet de données est reçu par un Trusted Port, il est transmis et aucun traitement SAVI n est effectué sur le paquet. Si le paquet de données est reçu par un Validating Port, la fonction SAVI doit vérifier si le paquet de données appartient au trafic local ou de transit en cherchant dans la FCFS SAVI Prefix List : si l adresse IP source n appartient à aucun préfixe (trafic de transit), le paquet doit être détruit si l adresse source du paquet appartient à un des préfixes, le processus de validation SAVI pour le trafic local est exécuté conformément au paragraphe suivant Traitement du trafic local La description du traitement des paquets de données et de contrôle par le dispositif SAVI sera effectuée par une approche machine à états finis. Considérons une adresse IP donnée dans un dispositif SAVI donné. Notons : IPAddr : l adresse IP considérée (c est l attribut clé) L2A : l ancre de niveau 2 (layer 2 anchor) LT : lifetime Les différents états possibles (State) sont : NO_BIND : l entrée IPAdrr ne contient pas d ancre P TENTATIVE : un paquet de données ou un message DAD-NS concernant IPAddr vient d être reçu, la procédure DAD s exécute VALID : le lien pour IPAddr a été vérifié, il est valide et utilisable pour filtrer le trafic TESTING_TP-LT : soit un message DAD-NS a été reçu concernant IPAddr par un TP, soit le LT d IPAddr est sur le point d expirer TESTING_VP : un message DAD-NS ou un paquet de données est reçu par un VP autre que P La figure ci-dessous montre un schéma simplifié de la machine à états finis. 16

17 Des explications plus détaillées sont fournies dans le tableau figurant en annexe Configuration des ports La configuration des ports d un dispositif SAVI doit respecter les items suivants : les ports connectés à un autre dispositif SAVI doivent être configurés comme Trusted Ports (TP) les ports connectés aux hôtes doivent être configurés comme Validating Ports (VP) les ports connectés aux routeurs doivent être configurés comme Trusted Ports (TP) les ports connectés à une série d un ou plusieurs switches (non SAVI) ayant des hôtes connectés doivent être configurés comme Validating Ports (VP) les ports connectés à une série d un ou plusieurs switches (non SAVI) ayant des dispositifs SAVI ou des routeurs connectés mais pas d hôtes doivent être configurés comme Trusted Ports (TP) les ports connectés à une série d un ou plusieurs switches (non SAVI) ayant des dispositifs SAVI ou des routeurs connectés avec des hôtes doivent être configurés comme Validating Ports (VP) 4.3 CONSIDERATIONS DE SECURITE Avant tout, il est utile de rappeler qu une solution SAVI ne peut pas être plus sûre que l ancre de niveau inférieur qu elle utilise. Ainsi, si l ancre est falsifiable, la solution sera fragile. Attaques par déni de service : Envoi de paquets avec des adresses source différentes pour que le dispositif SAVI crée des entrées pour chaque adresse et gaspille de la mémoire : Recommandations : o Figure 6 : machine à états finis simplifiée lorsque le dispositif SAVI fonctionne en dehors de la mémoire affectée à la SAVI DB (data base), il doit créer de nouvelles entrées en effaçant les plus récentes, si bien que le coût de l attaque augmente fortement 17

18 o le dispositif SAVI doit réserver une quantité de mémoire minimale pour chaque port (4 liens par port) si bien qu un hôte connecté à un port garde de la mémoire disponible même en cas d attaque Création de liens dans un dispositif SAVI par un attaquant dont le résultat est de bloquer les paquets de données envoyés par le propriétaire légitime de l adresse source : peu probable en IPv6 5 SOLUTION SAVI POUR DHCP Cette partie, issue du document draft-ietf-savi-dhcp-07(4) du 26 novembre 2010 traitera de la procédure pour la création de liens entre une adresse attribuée par DHCP et une binding anchor. Ce mécanisme est déployé sur un dispositif d accès (switch, point d accès ) et fonctionne principalement par l espionnage de DHCP pour établir les liens entre les adresses IP source attribuées par DHCP et les binding anchors correspondantes. Cette solution est à considérer dans un scénario pour lequel seuls des serveurs DHCP peuvent attribuer des adresses globales valides. Figure 7 : scénario DHCP pour SAVI-DHCP 5.1 STRUCTURES DE DONNEES CONCEPTUELLES Deux structures de données redondantes sont utilisées pour enregistrer les liens et leurs états respectifs : le Binding State Table (BST) concerne le niveau contrôle, il est composé des champs : o Anchor : la binding anchor, premier attribut clé d une entrée o Address : l addresse IP source, deuxième attribut clé d une entrée o Lifetime : la durée de vie restante d une entrée o State : l état du lien 18

19 o Other : information temporaires (identifiant de transaction d une requête DHCP, durée de bail d une adresse) Anchor Address State Lifetime Other A IP_1 Bound A IP_2 Bound B IP_3 Start 1 le Filtering Table (FT) concerne le niveau données, il est utilisé pour filtrer les paquets (Anchor et Address sont les attributs clés) : Anchor A A Address IP_1 IP_2 5.2 ATTRIBUTS DES BINDING ANCHORS Une binding anchor peut avoir un ou plusieurs attributs configurables. Par défaut, elle n en a pas et les messages DHCP venant d une binding anchor sans attribut doivent être supprimés. Les attributs possibles sont : SAVI-Validation Attribute : pour une binding anchor sur laquelle les adresses source doivent être validées ; le processus de filtrage est décrit au paragraphe 5.4. SAVI-DHCP-Trust Attribute : pour une binding anchor située sur le chemin vers un serveur ou un relais DHCP de confiance ; les messages DHCP en provenant sont transmis SAVI-SAVI Attribute : pour une binding anchor à partir de laquelle le trafic ne doit pas être vérifié ; tous les messages en provenant sont transmis sans vérification SAVI-BindRecovery Attribute : pour une binding anchor requérant une reprise de lien (non décrit dans ce document) Les attributs suivant s excluent mutuellement : SAVI-Validation // SAVI-SAVI SAVI-SAVI // SAVI-BindRecovery Les attributs SAVI-SAVI et SAVI-Validation implémentent le concept de périmètre de sécurité décrit en figure MISE EN PLACE DES LIENS La procédure de mise en place des liens est basée sur l espionnage des paquets de contrôle et n est valable que pour les binding anchor possédant l attribut SAVI-Validation Définitions des états et des évènements Les liens peuvent être dans trois états différents : NO_BIND : avant que le lien ne soit mis en place INIT_BIND : une requête DHCP a été reçue de la part d un hôte et doit déclencher un nouveau lien BOUND : l adresse est autorisée pour le client Les évènements sont définis comme ci-dessous : EVE_ENTRY_EXPIRE : la durée de vie d une entrée a expiré EVE_DHCP_REQUEST : une requête DHCP est reçue de la part d une binding anchor avec l attribut SAVI-Validation et des entrées sont disponibles EVE_DHCP_CONFIRM : une confirmation DHCPv6 est reçue de la part d une binding anchor avec l attribut SAVI-Validation et des entrées sont disponibles 19

20 EVE_DHCP_OPTION_RC : une sollicitation DHCPv6 avec option Rapid Commit est reçue de la part d une binding anchor avec l attribut SAVI-Validation et des entrées sont disponibles EVE_DHCP_REPLY : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu de la part d une binding anchor avec l attribut SAVI-DHCP-Trust et doit être transmis à une binding anchor avec l attribut SAVI-Validation EVE_DHCP_REPLY_NULL : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu de la part d une binding anchor avec l attribut SAVI-DHCP-Trust EVE_DHCP_DECLINE : un message de refus DHCP est reçu de la part d une binding anchor avec l attribut SAVI-Validation EVE_DHCP_RELEASE : un message de libération DHCP est reçu de la part d une binding anchor avec l attribut SAVI-Validation EVE_DHCP_REPLY_RENEW : un accusé de réception DHCPv4 ou une réponse DHCPv6 est reçu et suggère une nouvelle durée de bail EVE_LEASEQUERY_REPLY : une réponse affirmative DHCP LEASEQUERY est reçu d une binding anchor avec l attribut SAVI-DHCP-Trust Processus d espionnage des paquets de contrôle Le processus détaillé d espionnage des paquets de contrôle est décrit en Annexe Machine à états finis Le processus est décrit plus simplement dans la figure ci-dessous avec les valeurs suivantes : REQ : EVE_DHCP_REQUEST CFM : EVE_DHCP_CONFIRM RC : EVE_DHCP_OPTION_RC RPL : EVE_DHCP_REPLY DCL : EVE_DHCP_DECLINE RLS : EVE_DHCP_RELEASE RNW : EVE_DHCP_REPLY_RENEW LQR: EVE_LEASEQUERY_REPLY Timeout : EVE_ENTRY_EXPIRE LQ_DLY : MAX_LEASEQUERY_DELAY 20

21 Figure 8 : machine à états finis pour l'espionnage DHCP 5.4 FILTRAGE DES PAQUETS Les paquets de données avec une binding anchor dont l attribut est SAVI-Validation doivent être vérifiés : si l adresse d un paquet et sa binding anchor sont dans la FT, le paquet doit être transmis ; sinon il doit être détruit (éventuellement après avoir enregistré l évènement). Concernant le filtrage des paquets de contrôle pour les binding anchor dont l attribut est SAVI- Validation, les messages suivant doivent être détruits : DHCPv4 Discovery dont l adresse source n est pas tout 0 DHCPv4 Request dont l adresse source n est ni tout 0 ni une adresse liée dans un FT DHCPv6 Request dont l adresse source n est pas liée avec la binding anchor correspondante DHCPv6 Confirm / Solicit dont l adresse source n est pas une LLA liée avec la binding anchor correspondante autres messages DHCP dont l adresse source n est pas liée avec la binding anchor correspondante IPv6 NS et gratuitous ARP dont l adresse source n est pas liée avec la binding anchor correspondante NA et ARP Replies dont l adresse cible et l adresse source ne sont pas liée avec la binding anchor correspondante Concernant le filtrage des paquets de contrôle pour les binding anchor dont l attribut n est pas SAVI- Validation, les messages DHCP Reply / Ack ne provenant pas d une binding anchor dont l attribut est SAVI-DHCP-Trust ou SAVI-SAVI doivent être détruits. 21

22 6 SEND-BASED SOURCE-ADDRESS VALIDATION IMPLEMENTATION Cette section décrit un mécanisme pour fournir la validation de l adresse source en se basant sur le protocole SEcure Neighbor Discovery (SEND)(10). Cette description se réfère au document draft-ietfsavi-send-04(5) du 25 octobre Pour valider le propriétaire d une adresse, SEND SAVI utilise les messages DAD_NS (Duplicate Address Detection Neighbor Solicitation), DAD_NA (Duplicate Address Detection Neighbor Advertisement), NUD_NS (Neighbor Unreachability Detection Neighbor Solicitation) et NUD_NA (Neighbor Unreachability Detection Neighbor Advertisement). Au même titre que FCFS SAVI (résistance au facteur d échelle), les dispositifs SEND SAVI doivent être disposer de façon à former un périmètre de protection comme le montre la Figure 5 : périmètre d'application SAVI (FCFS SAVI). La configuration des ports sur les dispositifs SEND SAVI est également identique à celle préconisée sur les dispositifs FCFS SAVI. 6.1 STRUCTURES DE DONNEES Les structures de données suivantes sont définies pour SEND SAVI : Port List contient une entrée par port d un dispositif SAVI ; cette entrée est formée des champs suivant : o o o le port son rôle (TP : Trusted Port ou VP : Validating Port) un bit router port (uniquement pour les VP) si un routeur est connecté au port Address List contient une entrée pour chaque adresse IP source utilisée sur un VP d un dispositif SAVI ; cette entrée est formée des champs suivants : o o o o l adresse IP source le VP auquel l hôte est connecté la durée de vie le status : TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, TESTING_VP Prefix List contient une entrée par préfixe ; cette entrée est formée des champs suivants : o o le préfixe la durée de vie Router List contient une entrée pour chaque routeur autorisé connecté sur un VP d un dispositif SAVI ; cette entrée est formée des champs suivants : o o l adresse IPv6 du routeur la durée de vie Un dispositif SAVI doit de plus être configuré avec : une adresse CGA valide au moins un TP pour valider les Certification Paths qui autorisent les opérations de routage des Certifications Paths (voir les spécifications SEND [RFC3971](10)) chaque port doit avoir un rôle défini dans Port List 6.2 TRAITEMENT DU TRAFIC Le trafic est divisé en trois catégories en analysant l adresse IP source des paquets : le trafic de transit si le préfixe de l adresse IP source n est pas dans Prefix List le trafic local destiné au dispositif SAVI lui-même 22

23 le trafic local Traitement du trafic de transit Le trafic de transit est traité de manière différente en fonction du port par lequel il est reçu : si le paquet est reçu par un TP, il est transmis et aucun traitement SAVI n est exécuté si le paquet est reçu par un VP, deux cas se présentent : o o si le port contient, dans Port List, le bit Router, le paquet est transmis sinon, le dispositif SAVI doit envoyer un message RS par le port Traitement du trafic local à destination du dispositif SAVI Le trafic local à destination exclusive du dispositif SAVI est traité de la manière suivante : Traitement du trafic local Le traitement du trafic local sera décrit par une machine à états finis. Les états suivants sont définis pour un port P lié à une adresse IP source IPAddr au sein d un dispositif SAVI : NO_BIND : aucun lien n existe pour IPAddr TENTATIVE_DAD : le dispositif SAVI a reçu un message DAD_NS validé et attend un éventuel DAD_NA ; les paquets avec l adresse source correspondant au lien ne sont pas transmis TENTATIVE_NUD : un paquet différent d un message DAD_NS est reçu par un port VP et le dispositif SAVI a envoyé un message NUD_NS au port ; les paquets avec l adresse source correspondant au lien ne sont pas transmis VALID : le lien pour l adresse source a été vérifié ; les paquets provenant de cette adresse sont transmis TESTING_VP : la durée de vie du lien a expiré, le dispositif SAVI a envoyé un message NUD_NS vers le port ou un DAD_NS a été reçu par un autre dispositif SAVI ; le dispositif SAVI attend un NA validé et les paquets avec l adresse source correspondant au lien sont autorisés à être transmis TESTING_VP : un message DAD_NS validé a été reçu par un VP d un dispositif SAVI ; le dispositif attend un DAD_NA venant de VP ou change le lien vers le port VP si aucune réponse n est reçu après TENT_LT ms ; les paquets venant de VP avec l adresse source correspondant au lien sont autorisés à être transmis Une description simplifiée de cette machine à états finis est illustrée dans la figure ci-dessous. 23

24 Figure 9 : machine à états finis SEND SAVI Une description plus détaillée figure en annexe 3. 24

25 B Mise en œuvre du projet industriel 1 PROBLEMATIQUE ET EVOLUTIONS DU SUJET 1.1 PROBLEMATIQUE Le protocole SAVI est actuellement en cours de standardisation. Il n'y actuellement aucun matériel avec IOS disponible pour pouvoir implémenter cette solution. Après avoir contacté Jean-Michel COMBES du Centre de Physique Théorique et Eric LEVY-ABEGNOLI de CISCO des membres éminents du workgroup SAVI, il s'est avéré que l'implémentation la plus proche dont dispose la société CISCO ne tourne que sur un Catalyst6000, et uniquement avec un superviseur Sup2T, qui n'est pas un équipement très courant. De plus il s'agit d'une implémentation très édulcorée de SAVI. Le protocole PANA n'est disponible qu'en version «Beta» non soutenue. Cela semble assez délicat à implémenter dans le cadre de ce projet. Après contact avec Maryline Laurent de l'institut Telecom Sud PARIS, les seuls logiciels disponibles afin d'implémenter PANA se trouvent dans le SP3 du projet VERICERT (pana-eap-tls)(13). En revanche, plus personne ne maintient le logiciel. Les protocoles SAVI et PANA ne pouvaient être mis en œuvre dans le cadre de ce projet. Il convient donc d'essayer d'atteindre le but initialement fixé qu'est l'association d'une adresse Ipv6 délivrée en mode Stateless avec un identifiant usager. 1.2 EVOLUTION INITIALE DU SUJET Après avoir effectué un état de l'art du protocole SAVI et étant dans l'incapacité d'implémenter cette solution, nous allons essayer de réaliser une architecture nous permettant d'atteindre le but fixé par le projet. Les pistes à exploiter sont les suivantes : Figure 10 : Binding anchor sur un réseau filaire La plate-forme présentée en figure 10 va permettre de créer une association sur un réseau filaire entre une adresse Ipv6, une adresse MAC, un numéro de port ainsi qu'un identifiant. Cela permettra donc l'association adresse Ipv6 et identifiant initialement souhaitée pour le projet. 25

26 Figure 11 : Binding anchor sur un réseau Wifi La plate-forme présentée en figure 11 va permettre de créer une association sur un réseau wifi entre une adresse Ipv6, une adresse MAC, un numéro de port ainsi qu'un identifiant (wpa et/ou nom d'authentification). Cela permettra donc l'association adresse Ipv6 et identifiant initialement souhaitée pour le projet. Figure 12 : architecture globale du projet L architecture globale présentée en figure 12 aurait permis d'atteindre le but initialement recherché que constitue l'association d'une adresse Ipv6 et d'un identifiant quelque soit la méthode d'accès. Le manque de moyens et de temps nous a conduits à réduire considérablement le champ d'action du projet. 26

27 1.3 SECONDE EVOLUTION DU SUJET Nous avons donc décidé de nous concentrer sur l'association en mode wifi entre une adresse Ipv6 et une identité. Pour ce faire, nous avons utilisé l'architecture suivante : Le principe de fonctionnement de la plate-forme présentée en figure 13 s'articule en 3 phases : la première consiste à réaliser l'authentification de l'utilisateur sur l'access point via le serveur freeradius intégré (récupération adresse MAC et identifiant) ; la seconde phase est réalisée par l'access point qui après avoir authentifié l'utilisateur lui permet d'accéder au routeur en relayant les Router Sollicitation ainsi que les Router Advertisement qui lui donneront les indications nécessaires pour construire son adresse globale ; la troisième phase consiste à capturer le DAD effectué par l'utilisateur après avoir construit son adresse globale (récupération adresse Ipv6 et adresse MAC de l'utilisateur). 2 MISE EN PRATIQUE 2.1 CHOIX LOGICIELS Figure 13 : architecture du projet après évolutions Nous avons fait le choix d'installer sur un système d'exploitation Ubuntu (UNIX) disposant d'un accès Wifi, le package Hostapd afin de réaliser manuellement un point d'accès Wifi sécurisé. Nous avons également installé sur cette même machine le package Freeradius qui nous permettra d'installer un serveur Radius effectuant l'authentification des utilisateurs souhaitant accéder au réseaux via le point d'accès. 2 utilisateurs ont été créer en local sur le serveur Radius ; ces utilisateurs sont 'dfava' et 'hmartin'. L'utilisation de serveur LDAP ou MySQL n'était pas nécessaire dans le cadre du projet. Nous avons utilisé airodump du package aircrack afin de vérifier le bon fonctionnement de notre point d'accès ainsi que ses paramètres radio. Nous avons choisi de réaliser une authentification par clé WPA2 pour les clients via EAP. Nous avons utilisé le package WPA-Supplicant sur la machine cliente afin de réaliser l'authentification de l'usager sur notre point d'accès. Afin de mettre en place le mode Stateless d'ipv6 nous allons raccorder notre point d'accès à un routeur CISCO Nous allons également mettre en place WIRESHARK sur notre serveur afin de capturer sur l'interface radio les DAD effectués par les clients après la création de leur adresse Ipv6 globale ce qui nous permettra d'associer cette fois l'adresse Ipv6 globale de l'utilisateur à son adresse MAC (on pourrait également associé à cela l'adresse lien local de l'usager). 27

28 2.2 ILLUSTRATION ASSOCIATION MAC/IDENTIFIANT Figure 14 : vue airodump du point d'accès Figure 15 : authentification par hostapd 28

29 La fenêtre présentée en figure 14 illustre l'émission du point d'accès créé pour le projet via airodump. On peut y retrouver la puissance, les canaux utilisés ainsi que les méthodes d'authentification. La vue présentée en figure 15 représente le traitement de la demande d'authentification en WPA de l'utilisateur auprès du point d'accès. On peut vérifier que l'authentification s'effectue via le protocole 802.1X sur le serveur RADIUS. On retrouve également l'adresse MAC, l'identité de l'utilisateur ainsi que les méthodes d'authentification utilisées. La vue présentée en figure 16 représente le traitement de la demande d'authentification relayée par le point d'accès au serveur RADIUS. On y retrouve l'identifiant et l'adresse MAC de l'utilisateur, ainsi que des informations sur la connexion et les challenges effectués. Figure 16 : traitement de l'authentification par le serveur radius La vue présentée en figure 17 illustre le dénouement final de l'authentification de l'utilisateur. On peut y voir différentes informations sur le point d'accès ainsi que le type d'authentification réalisée. 29

30 Figure 17 : résultat de l'authentification sur le poste de l'utilisateur Figure 18 : association sur le serveur radius 30

31 Nous pouvons utiliser l'association adresse MAC / Identifiant relevée sur le serveur radius (figure 18). Cette association peut également être enrichie des différents paramètres relevés sur les différentes captures précédentes via le serveur Radius et le point d'accès (numéro de session, message authenticator...). Le couple «adresse MAC/ Identifiant» étant réalisée, il nous faut maintenant leur associer une adresse Ipv6 que l'utilisateur obtiendra en mode Stateless. 2.3 ILLUSTRATION ASSOCIATION MAC/IPV6 Pour mettre en place le réseau avec un adressage Ipv6 en mode stateless nous avons configuré (figure 19) un routeur CISCO 1605 nous permettant d'attribuer au client les préfixes Ipv6. Le préfixe Ipv6 alloué aux clients est 2001:660:7301:BEBE::/64, ils construisent leur adresse globale automatiquement à partir de ce préfixe. Figure 19 : configuration routeur CISCO Une fois l'authentification via l'access point réalisée, celui-ci laissera passer les échanges de niveaux 3 (Router Sollicitation, Neighbor Sollicitation, Router Advertisement) entre l'abonné et le routeur. Pour se faire nous avons réalisé un pont entre l'interface filaire (reliée au routeur) et l'interface radio (utilisée pour l'access point). L'interface Br0 est ainsi créée, elle se construit une adresse IPV6 globale configurée dynamiquement (figure 20). 31

32 Figure 20 : configuration du pont L'abonné va donc réaliser après s'être authentifié et avoir récupéré le préfixe un Neighbor Sollicitation afin d'exécuter son DAD. Cette requête a été capturée avec Wireshark (on pourrait également utiliser Tcpdump). La fenêtre présentée en figure 21 montre que le DAD est effectué avec l'adresse multicast sollicitée FF02::1:FF06:81a9 mais l'adresse Ipv6 globale de l'abonné se trouve distinctement dans le champ «target». On y trouve également l'adresse MAC de l'abonné ( A) ainsi que l'adresse MAC sollicitée FF A. Le changement d'adresse Ipv6 dans le temps n'échappera pas au DAD effectué par le client ce qui permettra de mettra à jour les différentes tables afin de mettre en corrélation les nouveaux éléments. 32

33 Figure 21 : vue Wireshark du message DAD Les différentes associations permettent d'obtenir le Même si un utilisateur se connecte depuis plusieurs équipement ou dispose de plusieurs adresses, il est possible d'enrichir ces associations (un même identifiant peut avoir plusieurs adresses Ipv6 et plusieurs adresses MAC). 2.4 MAUVAISE AUTHENTIFICATION Il convient de vérifier le comportement de l'access point lors d'une mauvaise authentification. On peut vérifier sur le serveur radius que cette mauvaise authentification est réalisé avec le nom d'utilisateur entré et l'adresse MAC correspondante. Les figures 22 et 23 montrent qu'aucun RA n'est acheminé vers le client tant que celui-ci n'est pas authentifié. Le client ne peut obtenir de préfixe afin de configurer son adresse Ipv6 globale et donc accéder au réseau. 33

34 Figure 22 : échec de l'authentification sur le serveur radius Figure 23 : échec de l'authentification sur le poste de l'utilisateur 34

35 2.5 USURPATION D ADRESSE MAC Dans un premier temps, l attaquant se connecte de manière légitime. Il possède donc : un login et un mot de passe une adresse MAC une adresse IPv6 attribuée par le routeur L attaquant procède ensuite de deux façons différentes pour usurper une adresse MAC. La figure 24 présente les résultats d une tentative de connexion avec une adresse MAC usurpée : l attaquant a changé son adresse MAC alors que l interface est down. A la connexion, l usurpation est détectée. Figure 24 : détection du doublon adresse MAC La figure 25 présente les résultats de l usurpation d adresse MAC alors que l interface est up : l attaquant conserve alors ses adresses IPv6 précédentes mais n a plus d accès au réseau. 35

36 Figure 25 : déconnexion après usurpation d'adresse MAC 2.6 AJOUT D ADRESSE IPV6 Un client connecté de façon légitime tente d usurper une adresse IPv6 en la rajoutant sur son interface de connexion. Le DAD capturé par Wireshark en figure 26 montre que cette nouvelle adresse IP se retrouve associée à l adresse MAC du client. Figure 26 : ajout d'une nouvelle adresse IPv6 36