Agence nationale
de la sécurité des
systèmes d'information
No CERTA-2006-INF-004-004
| S . G . D . S . N Agence nationale de la sécurité des systèmes d'information |
|
Paris, le 09 janvier 2008 No CERTA-2006-INF-004-004 |
Affaire suivie par :
CERTA
Objet : Migration IPv6 : enjeux de
sécurité
| Conditions d'utilisation de ce document : | http://www.certa.ssi.gouv.fr/certa/apropos.html |
| Dernière version de ce document : | http://www.certa.ssi.gouv.fr/site/CERTA-2006-INF-004 |
Une gestion de version détaillée se trouve à la fin de ce document.
Ce document s'adresse donc aux personnes soucieuses de comprendre les enjeux de sécurité liés à l'introduction d'IPv6. Il demande aussi un minimum de connaissances du fonctionnement actuel de certains protocoles (IPv4, ICMPv4, ARP, etc).
Parmi les évolutions actuelles mal considérées par IPv4, on peut citer :
Le successeur naturel aurait pu logiquement être IP version 5, mais cette version a été attribuée à un protocole expérimental : ST (Internet Stream Protocol), défini pour le première fois en 1979 et qui n'a jamais atteint le grand public. Le successeur fut donc choisi sous le nom de IPv6.
Les détails techniques du protocole s'appuient sur le document [RFC3513]. Nous n'aborderons que sommairement ces derniers, l'objectif n'étant pas ici de décrire les subtilités du protocole, mais plutôt d'en comprendre les enjeux relatifs à la sécurité du réseau. IPv6 est voué à se déployer dans les prochains mois et les quelques années à venir. Il est donc capital de saisir les avantages qu'il apporte en terme de sécurité, mais aussi les points plus obscurs qui ne sont pas, aujourd'hui encore, complètement éclaircis.
Une section présentant les recommandations du CERTA se trouvent en section 6.
Enfin, ce document traitant de la migration IPv4 vers IPv6, il s'adresse particulièrement aux lecteurs qui ont une connaissance des protocoles courants IPv4, ARP et ICMP.
IPv6 est un protocole réseau, servant à véhiculer des paquets de données à travers différents éléments actifs (routeurs par exemple) du réseau. Tout comme IPv4, IPv6 doit envelopper (ou encapsuler) les données dans certains paquets, en ajoutant plusieurs informations. Celles-ci se trouvent dans un endroit particulier, appelé entête du paquet.
Elle précise entre autres l'adresse de l'émetteur du paquet, ainsi que celle du destinataire.
Sous IPv4, il est fréquent de voir une telle adresse sur 32 bits sous la forme W.X.Y.Z, avec chacune de ces lettres représentant des nombres entre 0 et 255. Par exemple :
Sous IPv6, le format d'une adresse change : elle fait
maintenant 128 bits (donc un stock de 
adresses, soit 
fois plus qu'avec IPv4), et se
présente en 8 mots de 16 bits (4 hexadécimaux)
séparés par le caractère « :
». La représentation du préfixe, reste,
elle, similaire à celle de la notation CIDR du RFC 1519
utilisée avec IPv4 [RFC1519]. Il s'agit des
fameux /24, /8, etc. Deux illustrations,
l'une étant l'adresse IPv6 d'une machine, l'autre celle
d'un réseau, sont représentées ci-dessous
:
Dans le cas où l'adresse IPv6 est directement mise dans le lien réticulaire d'un site (ou URL), celle-ci doit apparaître entre crochets : http://[XXX:XXXX:XXXX::XXXX:XXXX]/index.html, parce que «:» a une autre signification dans une URL. Enfin, tout comme pour IPv4, certaines plages sont réservées. De plus amples détails se trouvent dans les RFC 3513, 4048, 4193 et 3879.
Pour conclure cette section, il faut également mentionner que des adresses IPv6 sont en théorie réservée pour la documentation [RFC3849]. Il s'agit de la plage 2001:DB8::/32, à l'instar des adresses 192.0.2.0/24 définies sous IPv4 par le RFC 3330. Cette règle n'est cependant pas toujours respectée dans ce document.
L'entête d'un paquet est légèrement différente de celle mise en œuvre par le protocole IPv4, mais de nombreux points communs demeurent, comme l'illustrent les figures 1 et 2 : la figure 1 présente un paquet IPv6 dans sa globalité, et la figure 2 décrit les différents champs de l'entête IPv6.
Les standards se sont appuyés sur l'acquis d'IPv4 afin de simplifier les champs de l'entête, au bonheur des administrateurs réseaux et des routeurs.
En première remarque, il n'existe plus de champ checksum, qui vérifie l'intégrité du paquet : ainsi, IPv6 ne vérifie plus si une erreur est apparue au niveau de son entête au cours des différentes étapes de traitement du paquet. Il se pose alors le problème de savoir si le champ source ou destination du paquet ne contient pas d'erreur. IPv6 considère que cette tâche revient aux protocoles de niveau supérieur, qui devront mettre en place un mécanisme de vérification d'intégrité de bout-en-bout, incluant une pseudo-entête avec les adresses source et destination. Par exemple, UDP permet d'ajouter ces champs et vérifier les erreurs, mais ceux-ci sont facultatifs sous IPv4. Cependant, ce manque d'intégrité au niveau réseau peut poser des problèmes. D'une part, les routeurs ne faisant plus de contrôle d'intégrité, la détection d'une erreur dans le paquet ne se fera qu'à sa destination (lors de la lecture des protocoles des couches supérieures). D'autre part, il est plus difficile d'identifier les connexions réseau qui seraient à l'origine d'un taux anormal d'erreurs au cours du voyage des paquets.
ICMPv4 (pour Internet Control Message Protocol) est le protocole utilisé pour gérer des informations relatives à l'état du réseau des machines connectées. A la différence d'UDP, ICMPv4 ne vérifie que l'intégrité du message ICMP, et non la source et la destination du paquet original. Ceci a contribué à l'apparition d'un protocole équivalent mais plus adapté, nommé ICMPv6.
Comme pour IPv4, IPv6 prend en compte le nombre de sauts, ou
nombre de routeurs que le paquet est autorisé à
traverser. Dans IPv4, ce champ est appelé durée de vie, ou TTL (pour Time-to-Live). Il est
décrémenté à chaque noeud
traversé, normalement de 1. La valeur initiale de ce
champ devrait être donnée par l'IANA
(http://www.iana.org). Cette valeur, codée sur 8 bits,
n'est cependant pas encore attribuée, et la plupart des
mises en œuvre sont choisies au bon gré des
développeurs, tout comme pour IPv4. Il reste codé
sur 8 bits, donc IPv6 ne prévoit pas plus de 
sauts pour un
même paquet.
IPv4 réserve une place dans l'entête consacrée à différentes options (traceroute, timestamp, etc). Dans IPv6, ces options n'existent plus dans l'entête. Elles sont remplacées par des champs facultatifs, non intégrés à l'entête, et appelés extensions.
Les extensions sont prises en compte par les équipements destinataires du paquet. Le RFC 2460 donne plusieurs recommandations, mais ces champs restent de taille, de contenu et de signification variables. Il existe une recommandation concernant leur ordre d'apparition dans le paquet IPv6, mais la seule vraie restriction concerne une extension, nommée Proche-en-Proche (ou Hop-by-Hop).
Les extensions les plus significatives sont :
Une autre option intéressante de l'extension Proche-en-Proche est le jumbogramme [RFC2675]. Cette option signale aux éléments du réseau qu'ils doivent traiter un paquet de taille extrêmement grande. Quand la longueur des données dépasse 65535 octets, le champ de l'entête précisant la longueur (codé sur 2 octets) vaut alors 0, et cette option est employée. Bien que cette option semble offrir une optimisation au niveau de la bande passante, elle peut perturber un ensemble d'élèments dans le réseau qui n'ont pas la capacité de gérer de tels paquets (sondes IDSs, pare-feux).
Par ailleurs, IPv4 n'a jamais été créé dans le but de favoriser le multicast, c'est-à-dire la distribution simultanée d'information vers un groupe donné de destinataires. Cependant, le multicast présente un attrait certain pour les différents protocoles multimédia comme RTP (pour Real Time Protocol), et la diffusion de données multimédia (films, musique). IPv6 se doit donc d'intégrer ce moyen de communication, et ceci est rendu possible par le biais de certaines extensions.
Dans cette brève introduction au format IPv6, il apparaît que la structure globale de l'entête IPv6 ne diffère guère de celle d'IPv4. Cependant, l'entête possède des extensions offrant de nombreuses possibilités : cela conduit à la définition de nombreux champs, souvent optionnels. Les RFCs ne détaillent pas systématiquement les valeurs par défaut. Les mises en œuvre d'IPv6 pourraient donc être identifiables selon les valeurs choisies. Par ailleurs, certaines extensions peuvent également poser directement problème, comme c'est le cas pour l'une des options de l'extension Proche-en-Proche : Router Alert, qui demande au routeur suivant d'examiner le contenu des paquets qu'il relaie, comme certains protocoles l'exigent. Cette option permet d'inciter un routeur à interpréter les données d'un paquet, même si cela n'est pas sa fonction première, au risque d'augmenter sa charge de travail (déni de service) et de le voir effectuer une mauvaise interprétation.
En se bornant à cette présentation sommaire, il apparaît aussi que les extensions doivent rester intègres entre la source et la destination. Dans le cas contraire, il serait facile, pendant le trajet du paquet, de changer le message de l'extension à l'attention du destinataire.
Un équivalent du protocole ARP pour IPv4 est utilisé dans IPv6 pour établir le lien entre les adresses IPs et les adresses physiques MAC : le protocole de découverte des proches voisins NDP (ou Neighbor Discovery Protocol). Le protocole réalise différentes fonctions, comme la résolution d'adresses, la détection d'inaccessibilité, la configuration automatique des équipements, ou la découverte des routeurs et des préfixes. La principale différence vient de l'emploi de messages standards ICMPv6 en remplacement d'ARP. ARP n'existe donc plus sous IPv6 ! Parmi les simplifications, les adresses de diffusion (aussi appelées broadcast) n'existent plus : le champ «nombre de sauts» de l'entête IPv6 contient la valeur maximale (255), afin de vérifier que l'information provient du même lien physique1.
L'idée globale étant de simplifier la configuration du réseau dans les systèmes d'information, IPv6 spécifie deux méthodes distinctes mais non exclusives pour configurer une machine :
Ces deux méthodes sont illustrées par la figure 3.
Cette procédure d'autoconfiguration peut soulever des inquiétudes concernant la notion de «protection de la vie privée» (ou privacy). En effet, les adresses temporaires sont crées à partir de l'adresse MAC (qui identifie aussi le matériel réseau). Chaque machine, et donc chaque internaute, transmet un numéro de série unique sur l'Internet, et stable dans le temps. Ce numéro est transmis avec l'adresse IPv6, i.e. se retrouve dans l'envoi de courrier, les forums de discussion, l'accès aux moteurs de recherche, etc.
Des solutions existent pour remédier à ce problème, l'une proposant de remplacer l'identifiant fixe par un nombre pseudo-aléatoire [RFC3041]. Cette option est par exemple activée par défaut sous Windows XP, mais n'est pas acceptée avec certaines configurations de routage, ou avec l'utilisation de portails captifs (réseaux sans-fil notamment).
Les protocoles de routage ne changent pas avec IPv6. Les efforts qui ont été faits consistent seulement à les adapter au nouveau format des adresses IPv6. En revanche, ils bénéficient des apports d'IPv6, comme l'authentification et la diffusion multicast.
Pour le routage interne (au sein d'un sous-réseau), l'équivalent de RIPv2 est RIPng, décrit dans [RFC2080]. Il est quasiment identique, mais n'inclut plus d'authentification. Celle-ci repose sur les moyens de sécurité mis en place au niveau d'IPv6 (voir section 4.1).
Le second protocole de routage interne, OSPF passe à la version 3. Une opération a été effectuée afin de rendre le coeur du protocole indépendant du protocole réseau IPv6, et de le restreindre au transport d'informations d'adressage. Les routeurs voisins sont indiqués par un identifiant, afin de limiter l'usage des adresses IPv6.
Le mécanisme d'encapsulation et de commutation de données MPLS est particulièrement adapté pour la transition IPv4 vers IPv6. En effet, l'interconnection de différents réseaux IPv6 se fait de manière transparente, même au travers d'un réseau IPv4 MPLS, dans la mesure où MPLS sert à commuter des labels, et non pas des adresses IPs. Ce protocole reste cependant vulnérable à certaines classes d'attaques particulières, comme l'injection malveillante de labels au sein du réseau ou certaines attaques de niveau 2 (couche MAC).
Le protocole de routage externe actuellement utilisé pour le routage global de l'Internet est BGPv4. Il garde la même appélation pour IPv6. Son adaptation s'est globalement limitée à changer trois attributs dont le format dépend de l'adresse. Les règles d'agrégation de plages d'adresses restent inchangées. Une adaptation du protocole BGP est cependant à prévoir, comme l'annonce le standard RFC 4893 de mai 2007 : le numéro AS (Autonomous System) doit passer de deux à quatre octets.
Les protocoles de routage et les mécanismes d'encapsulation associés sont donc peu modifiés pour le moment. Ils gardent les avantages et faiblesses actuels. Il est aussi intéressant de noter pour RIPng la volonté de limiter l'authentification au niveau IPv6, fonctionalité discutée au paragraphe 4.1.
IPv6 est aussi un protocole destiné à interconnecter les terminaux mobiles. MIPv6 (ou Mobile IPv6) permet, en pratique, à une machine de rester joignable et de communiquer avec la même adresse, quelle que soit son medium et sa position courante. Il est par exemple peu à peu intégré dans les différents éléments de l'architecture de la téléphonie dite de troisième génération. Globalement, les mécanismes d'IPv6 vus dans les sections précédentes offrent une très bonne base à la gestion de la mobilité. En effet, ils résolvent plusieurs difficultés qu'avaient à résoudre les solutions de mobilité d'IPv4. Ainsi, le mécanisme de configuration sans état permet au système mobile d'acquérir, en déplacement, une adresse IP fonctionnelle. Il peut dès lors communiquer. Le mécanisme d'annonce des routeurs facilite quant à lui la détection du mouvement, qui est essentielle à la gestion de la mobilité. De manière grossière, il est possible de distinguer, au niveau protocolaire, trois propriétés :
Le protocole Mobile IPv6 permet au système mobile de conserver l'adresse utilisée dans son réseau d'origine, même en mouvement. Celle-ci se nomme adresse mère (HoA). Il acquiert par ailleurs des adresses temporaires (CoA) locales aux réseaux qu'il visite. Une machine, l'agent mère, garde les traces de ces changements successifs. Le mobile utilise enfin la détection de voisinage pour voir si son routeur par défaut n'est plus accessible. Les échanges principaux sont résumés dans la figure 4 : un correspondant extérieur envoie du trafic vers l'agent mère qui les communique au mobile, qui lui-même communique directement avec l'hôte.
Il existe un risque lorsque le système mobile envoie des mises à jour d'association à l'agent mère. Celles-ci peuvent être fausses. Un système malveillant dans un autre réseau peut lui même envoyer une fausse demande afin de détourner le trafic de son véritable destinataire. Il est indispensable d'utiliser une méthode d'authentification entre le mobile et son agent mère pour éviter ce scénario. Une analyse de la sécurité de Mobile IPv6 est disponible à [SSTIC]. Il faut retenir que la mobilité IPv6 est très prometteuse en terme d'exploitation, mais elle fait intervenir plusieurs acteurs au niveau protocolaire (réseau mère, réseau correspondant, système mobile), qui complexifient d'avantage les procédures de sécurisation, et qui, de fait, accroissent potentiellement les risques.
Un standard datant de mai 2007 aborde enfin la problématique du respect de la vie privée avec Mobile IPv6 [RFC4882]. La mobile acquiert une nouvelle adresse IP à chaque réseau visité. Si le nœud correspondant parvient à déterminer un signe caractéristique de la machine, il peut esssayer de déterminer approximativement la position du mobile, ou sa trace. Le standard reprend donc les moyens de communication décrit dans le [RFC3775] et détaille leurs défauts vis-à-vis de la protection de la vie privée. Il ne propose cependant pas de solution.
Plusieurs initiatives sont apparues, suite à IPv6, profitant de l'élan réformateur. La plupart sont, à la date de rédaction de document, en phase de discussion. Shim6 est parmi les plus intéressantes. Il s'agit d'un protocole répondant au problème du multihoming : un site peut disposer de plusieurs liens Internet, gérés par différents fournisseurs d'accès. Chacun de ces liens fournit une adresse IP appartenant à un réseau donné. Il n'est actuellement pas possible de maintenir une communication, vers un serveur par exemple, quand le système change de lien. Shim6 propose donc de rendre plus indépendant les couches «réseau» et «transport» (modèle OSI), en distinguant deux adresses au lieu de la seule IPv6 : Les couches supérieures (transport, session, présentation, application) ne voient, selon Shim6, qu'une adresse fixe unique, appelée ULID (pour Upper Layer Identifier). L'ULID est une adresse IPv6. Des adresses locales maintenues servent à faire la transition quand le lien change, mais sont invisibles des autres couches protocolaires. L'ULID sert alors aux noeuds communicants pour maintenir la communication, sans se préoccuper du changement de lien du système. Ce changement de lien peut également être un changement de position d'un agent mobile, qui ne veut pas perdre sa communication au cours de l'entrée dans un nouveau réseau (roaming).
D'autres protocoles prometteurs verront sûrement le jour avec IPv6. Ils ne sont cependant pas encore matures pour être mis en œuvre, sans de très grandes précautions, dans un réseau de production.
La double pile IP consiste à équiper un équipement du réseau d'une double pile protocolaire (Dual Stack) et d'affecter une adresse IPv4 et une adresse IPv6 à l'interface. Cela peut s'appliquer sur la plupart des systèmes d'information. Les serveurs doivent alors avoir deux sockets, l'une correspondant à une écoute via IPv4, et l'autre correspondant à une écoute via IPv6.
Il faut donc garder en mémoire que, dans ce cas là, les deux protocoles sont installés sur le même système : ils communiquent directement entre eux et séparemment avec l'extérieur. La section 5.4 montrera quelques problèmes de sécurité que cette propriété induit.
Il n'est pas toujours possible d'avoir une double pile IP ou un réseau IPv6 de bout-en-bout. Cependant, les trames IPv6 doivent pouvoir être transmises, même si un réseau intermédiaire ne supporte qu'IPv4. Plusieurs solutions sont disponibles, pour former un tunnel : les paquets IPv6 transitent alors encapsulés dans IPv4, ce qui s'appelle autrement un tunnel IPv4. Nous distinguons les tunnels statiques et les tunnels automatiques.
Au lieu de configurer manuellement chaque extrémité des tunnels, il est aussi possible d'automatiser un peu la précédure, tout en maintenant la structure statique du tunnel. Le principe est très similaire à celui d'un VPN et est illustré par la figure 5. Des serveurs, nommés IP Tunnel Brokers servent pour la transition. Il faut se connecter à l'un d'eux en IPv4 pour obtenir une adresse et accéder à la configuration du tunnel vers un réseau IPv6. Ce procédé est bien statique (ou semi-dynamique), dans la mesure où il nécessite de connaître et de configurer correctement IPv4 au niveau du Tunnel Broker. Ce dernier se charge du routage et des configurations des extrémités des tunnels : il reste un point vulnérable dans la mesure où tout le transport du trafic repose sur lui.
Dans le cas d'un tunnel automatique, une liaison fixe point à point est établie entre les machines impliquées (des routeurs par exemple). Ce tunnel formé fragmente les paquets selon IPv4, et met en œuvre les mécanismes de découverte des voisins.
Si une erreur survient au cours de l'acheminement IPv4, un paquet ICMPv4 est envoyé. Idéalement, le point à la source du tunnel devrait récupérer ce message, puis le traduire en un paquet ICMPv6 équivalent afin de le retourner vers la source du datagramme IPv6. Le transport de datagrammes IPv6 dans une trame IPv4 est précisé dans [RFC2893].
Il existe à l'heure actuelle quatre mises en œuvre majeures pour effectuer l'acheminement d'IPv6 sous IPv4 : 6to4, ISATAP, Teredo et 6over4.
Le tableau 2 résume les points essentiels qui différencient chacune de ces méthodes d'encapsulation.
Le transport de datagrammes IPv4 ou IPv6 dans une trame IPv6 est précisé dans [RFC2473]. L'entête indique alors le protocole qui est encapsulé, 4 pour IPv4, et 41 pour IPv6. Le RFC 2473 propose aussi des mécanismes pour éviter le bouclage dû à l'imbrication de protocoles.
La traduction se fait relativement bien, car IPv6 est suffisamment souple en terme d'extension. Ce scénario est cependant encore assez rare, à l'exception du cœur des réseaux de certains fournisseurs d'accès.
Le protocole de résolution de noms DNS ne subit que très peu de modifications avec l'arrivée d'IPv6. Il doit supporter l'enregistrement AAAA, qui nomme une adresse IPv6, à l'instar de l'enregistrement A pour une adresse IPv4. Il doit pouvoir également supporter la résolution inverse en IPv6 (ip6.arpa.). Ainsi, l'arrivée d'IPv6 entraîne des problèmes d'incompatibilité. Avant IPv6, la résolution de noms DNS ne faisait intervenir qu'IPv4, et le service était donc garanti pour tous les clients DNS. Avec l'arrivée d'IPv6, l'espace de nommage devient fragmenté en des partitions accessibles via IPv4 uniquement et d'autres accessibles en IPv6 uniquement. Il est alors possible d'imaginer le scénario suivant :
La réciproque est également valable. Il existe donc quelques problèmes de continuité qui ne sont pas clairement résolus pour le moment. Certains sont cités dans [IETF]. Ce rapport fait mention des difficultés à mettre en œuvre la résolution inverse DNS, dans le cas des tunnels. Il donne aussi quelques comportements singuliers des serveurs liés à getaddrinfo(), la fonction chargée de lancer les requêtes DNS depuis un poste client. Celle-ci cherche d'abord un enregistrement AAAA IPv6, ou sinon, après réponse négative, essaie de trouver un enregistrement A IPv4. Mais certains serveurs ne répondent pas systématiquement à la première requête, pouvant alors provoquer des délais d'attente importants côté client.
En l'état, les solutions proposées consistent à utiliser un serveur DNS double-pile IPv4/IPv6, ou deux serveurs supportant les deux protocoles.
Le groupe de travail, NGtrans, maintenant dissout, a écrit un ensemble de mécanismes de transition, permettant chacun de résoudre un problème particulier. Ils répondent à un bon nombre de questions, même si les solutions proposées ne sont pas toujours aussi techniques qu'il faudrait. La plupart sont illustrées de scénarios de transition et de cohabitation. Ils abordent notamment les thèmes suivants :
Un groupe de travail IETF, nommé IPv6ops (pour IPv6 operations) vise à traiter de l'ensemble des problèmes opérationnels liés à la migration vers IPv6. Ils reprennent donc en partie les thèmes du groupe de travail précédent, mais en distinguant cette fois quatre grandes familles de déploiement :
L'ensemble des documents de ces groupes de travail est
disponible aux deux adresses réticulaires ci-dessous
:
http://www.6bone.net/ngtrans/ngtrans_project-status.html
http://www.ietf.org/html.charters/v6ops-charter.html
IPv6 supporte par défaut les deux architectures classiques d'IPsec : AH et ESP.
L'extension d'authentification, ou AH, assure l'authentification et l'intégrité des données. L'émetteur calcule une signature sur un datagramme et l'émet avec le datagramme sur lequel elle porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Cette signature peut s'appuyer sur des clés asymétriques et éventuellement des certificats.
L'extension ESP (pour Encryption Security Payload) complète la précédente pour offrir la confidentialité des données. Elle permet de chiffrer l'ensemble des paquets (entête IPv6 comprise) ou seulement leur partie transport (tout ce qui se trouve après l'entête IP), selon les modes dits repectivement tunnel et transport.
Avant l'authentification ou le chiffrement de données IP, l'émetteur et le receveur doivent convenir des algorithmes et des clés à utiliser. Ceci se fait par le protocole IKE (pour Internet Key Exchange, [RFC2409]). Sans décrire les détails de ce dernier, il est important de se souvenir que ce protocole ne convient pas, dans l'état actuel, aux échanges multicast. Des initiatives dans ce domaine se confirment, comme GSAKMP pour la distribution de clés, et tesla pour l'authentification, mais les couches IPv6 actuelles ne les utilisent pas encore pour le multicast. Le trafic multicast passe donc en clair, pour la majorité des cas, dans le réseau, à moins de considérer une procédure d'authentification et de chiffrement dans les niveaux protocolaires supérieurs.
SEND propose de sécuriser NDP, le protocole de voisinage d'IPv6 (cf. section 2.4.1). La première proposition est l'utilisation de CGA ([RFC3972]) (pour Cryptographically Generated Addresses), qui crée des identifiants d'adresses à partir d'une clé publique. Ce méchanisme permet de vérifier l'identité de la machine émettrice du paquet NDP. L'adresse CGA s'obtient en appliquant une fonction de hashage à un ensemble de paramètres. L'algorithme de génération d'adresse CGA repose en grande partie sur une attribution pseudo-aléatoire à l'un d'entre eux (le paramètre Modifieur sur 128 bits). Il est important de vérifier que celle-ci s'effectue correctement. Il prend également en considération d'éventuelles collisions. Si trois ou plus sont détectées, l'algorithme s'interrompt. A l'adresse CGA s'ajoutent quelques options :
Ce méchanisme de sécurisation ne NDP n'est pas encore déployé, et reste anecdotique. Cependant, une mise en œuvre du protocole SEND en source libre est offerte par Docomo à l'adresse réticulaire suivante :
Plusieurs outils de filtrage existent, et sont mis à disposition dans les systèmes d'exploitation avec la couche IPv6. Parmi ceux-ci :
Les règles de filtrage se basent souvent sur les champs suivants :
Cependant, les différentes options de tunnel offertes par IPv6 sont difficilement contrôlables au niveau d'un pare-feu, et les règles simples de connectivité (ports source/destination) sont facilement contournables. Les pare-feux ne gardent souvent pas les détails de l'état des connexions.
Enfin, comme il a été rapidement mentionné ci-dessus, les extensions du protocole IPv6 sont évolutives et peuvent provoquer des problèmes décisionnels. Les documents RFCs ne donnent que très peu de directives sur les actions à entreprendre pour le filtrage IPv6.
Les «systèmes de détection d'intrusions» (IDSs) se mettent progressivement à IPv6. Pour ceux qui s'appuient sur des ensembles de signatures, le changement de code n'est pas majeur. Ils doivent pouvoir capturer et analyser des paquets aux différents formats IPv6. Cependant, il y a encore peu d'attaques connues ciblant les nouveaux protocoles associés à IPv6. L'ensemble de règles reste encore à écrire. Sans cela, l'intérêt des IDSs reste minime. L'usage d'IPsec va aussi compliquer la tâche des sondes surveillant le trafic du réseau. Si les paquets sont chiffrés, il sera plus difficile d'y voir des indications de code malveillant. A l'heure actuelle, la plupart des outils IDSs se bornent à détecter la présence de paquets IPv6 dans le réseau, sans regarder la sémantique ni le contenu : leur action est encore loin d'être satisfaisante.
Les pare-feux et IDSs compatibles IPv6 sont encore en phase de développement. Il est néanmoins raisonnable de prévoir que le besoin de sécurisation des postes terminaux va s'accentuer, compte tenu de la difficulté de cette tâche au niveau des équipements du réseau.
Le code IPv6 est disponible dans les équipements
terminaux récents (PCs, imprimantes, etc) et dans les
routeurs. Cette phase de développement est
achevée pour la plupart des équipementiers. Les
fabriquants de systèmes d'interconnexion ont
intégré IPv6 dans leurs systèmes
d'exploitation. Une liste de systèmes est disponible
à l'adresse réticulaire suivante:
http://www.ipv6.org/impl/
Cependant, plusieurs avis du CERTA tendent à indiquer que la mise en œuvre des différentes piles protocolaires (ou des applications les utilisant) présentent encore des faiblesses. Le tableau 1 liste quelques avis du CERTA à ce sujet, visibles sur son site Internet :
|
Il est important de noter que toutes les mises en œuvre d'IPv6 conformes doivent intégrer IPsec. Cependant, la plupart de celles actuelles ne l'utilisent pas convenablement. L'une des raisons étant que les échanges en multicast ne sont pas adaptés aux protocoles de gestion des associations liés à IPsec. Les extensions ESP et AH ne sont également pas compatibles avec la traduction d'adresses/ports. Le fait que ces deux extensions ne soient pas systématiquement applicables et appliquées provoque une certaine méfiance quant à la garantie des principes de confidentialité, d'intégrité et d'authentification dans un usage courant des protocoles. Il faut aussi noter que certains produits (routeurs, passerelles) offrent une version d'IPsec non fonctionnelle avec IPv6. Ils affichent donc bien commercialement les deux protocoles, mais il apparaît par la suite qu'IPsec ne fonctionne que sous IPv4.
Une autre question est celle de la priorité, pour les systèmes mettant en œuvre à la fois IPv4 et IPv6. Dans le cas de la découverte réseau, ceci peut se faire, comme nous l'avons vu, sous IPv6 par le Neighbor Discovery, ou sous IPv4 par le biais de Netbios. Dans ces conditions, il n'existe pas nécessairement de procédures pour forcer la communication par l'un ou l'autre des protocoles.
Ce chapitre recense brièvement les premiers risques associés au déploiement IPv6 qui ont été rapportés, soit sous forme d'outils, soit sous forme de concept.
Une des toutes premières utilisations malveillantes concernant IPv6 concerne les portes dérobées. Une fois qu'une machine est compromise, le code malveillant active la couche IPv6 présente sur la machine, mais non utilisée avant la compromission. Le code ouvre ensuite une porte dérobée via IPv6 [USCERT]. De cette manière, la porte dérobée a peu de chances d'être détectée par des tests d'audit traditionnels. Par ailleurs, le trafic IPv6 se joue assez aisément des pare-feux et systèmes de détection d'intrusions encore largement icompatibles avec IPv6.
Il existe déjà dans le domaine public des outils exploitant certaines vulnérabilités du protocole IPv6, que ce soit des faiblesses protocolaires, des erreurs de mise en œuvre ou des problèmes de configuration.
Cela inclut :
L'arrivée d'IPv6 tend à faire penser que les
vers virulents qui se progagent sur l'Internet vont
disparaître, ou du moins se raréfier. Cet argument
s'appuie sur le fait que les adresses IP passent de 32 à
128 bits, augmentant la taille de l'espace d'adressage d'un
facteur 
. Il
est donc beaucoup moins évident de balayer l'ensemble
des adresses afin de trouver celles potentiellement
vulnérables. Les principales techniques de propagation
actuelles des vers sont : le balayage exhaustif, ou le balayage
pseudo-aléatoire. Dans de telles conditions, la
probabilité de voir sa propre machine touchée
serait donc bien plus faible, et les vers utilisant ces
techniques auront davantage de difficultés à se
propager dans l'espace IPv6. Malheureusement, des chercheurs de
l'Université de Columbia ont récemment
montré que cette idée n'était pas
complètement valable. En effet, ils démontrent
que les vers auront aussi de nombreuses sources d'information
à leur disposition, leur permettant de déterminer
les réseaux existants, puis de se propager localement au
sein de ceux-ci. Ils citent entre autres :
La propagation des vers sera sûrement moins rapide que dans le monde IPv4, mais il est illusoire de croire en leur disparition. Par ailleurs, la phase de transition entre IPv4 et IPv6 pourrait voir apparaître de nouvelles formes virales, profitant des couches double-pile pour pénétrer les systèmes.
Comme il a été montré dans la section 4.3, des outils de filtrage existent et sont fournis avec les distributions des systèmes d'exploitation les plus courants. Le filtrage en lui-même est cependant plus difficile qu'avec IPv4, et nécessite patience et expérience. En effet, les machines peuvent maintenant présenter deux portes d'entrée, comme l'illustre la figure 9. Ainsi, quand un service se lie à un port IPv6, il sera par défaut lié au port IPv4 correspondant.
Le filtrage doit alors en tenir compte, pour éviter des transgressions de la politique de sécurité. Il est très facile d'imaginer un pare-feu ne bloquant pas ICMPv6. Sous cette condition, une personne malveillante peut cartographier le réseau depuis l'extérieur en adressant quelques paquets ICMPv6 aux machines. Plusieurs questions viennent naturellement à l'esprit et les réponses ne sont pas toutes évidentes. Voyons plus en détails les scénarios suivants :
Ces scénarios sont donnés à valeur illustrative. Il existe pour chacun des solutions techniques, mais elles ne sont pas intuitives, et doivent être adaptées. Les codes existants sont rares.
Les outils de filtrage actuels ne sont pas adaptés au tunnels «IPv4 dans IPv6» et «IPv6 dans IPv4». Imaginons le scénario où une machine IPv6 veut créer un tunnel IPv6 traversant le réseau IPv4 dans lequel elle se trouve. Elle peut utiliser la solution du Tunnel Broker présentée en figure 5. L'administrateur veut s'assurer au niveau réseau que la machine effectuant le tunnel communique en IPv6 avec le bon destinataire. Il n'y a pas de technique simple pour filtrer les paquets d'encapsulation IPv4 contenant les paquets IPv6 avec la bonne source et la bonne destination en IPv6. Le Tunnel Broker peut s'en charger au cours du transfert, mais il n'est pas forcément intégré dans le réseau et peut appartenir à un tiers. La politique de sécurité s'applique pourtant autant au trafic encapsulé que celui IPv4. Il est envisageable d'avoir un mécanisme simple, qui décide, à l'aide d'iptables par exemple, de donner un paquet IPv6 encapsulé à ip6tables pour appliquer les règles IPv6 qui conviennent, mais de telles mises en œuvre ne sont pas encore déployées.
Le filtrage doit être considéré avec la plus grande attention pour respecter les politiques d'accès rigoureuses déjà mises en œuvre. L'intégration d'IPv6 ne doit pas modifier, ou rendre plus laxistes, celles-ci.
Les applications devraient en théorie être indépendantes des couches protocolaires plus basses. Ce n'est malheureusement pas toujours le cas : certaines catégories d'applications comme le serveur de messagerie, le web doivent aussi subir des modifications. Les plus courantes (sendmail, exim, ssh, apache, mozilla, openLDAP, squid, etc) supportent maintenant nativement IPv6. Certaines applications peuvent encore poser problème. La stratégie adoptée lorsque le système utilise les deux piles est mis en œuvre localement dans chacune des applications. Un schéma standard est le suivant : l'application cherche à résoudre en IPv6 un nom (DNS AAAA). Si elle y parvient, elle se connecte alors en IPv6. Dans le cas où l'une des deux actions précédentes échoue, l'application réessaie en IPv4. [JRES05]. Elle est donc vulnérable à certains dysfonctionnements DNS, aussi appelés trous noirs :
Très souvent, il existe des relais applicatifs (ou serveurs mandataires) permettant de faciliter la conversion, pour permettre d'accéder à un service au réseau IPv4 inaccessible en IPv6 (et inversement). L'équipement IPv6 émet sa requête vers le relai applicatif qui interprète le contenu de celle-ci et la restransmet en IPv4 vers le le serveur d'application légitime. Un ou plusieurs relais peuvent être installés en fonction des applications et des services disponibles. Cette solution a l'avantage de ne pas modifier les serveurs existants. En revanche, il n'y a plus de connexion point-à-point entre le client et le serveur, étant donné que le relai applicatif interprète les données échangées. Certains services ne peuvent fonctionner sans cette condition (le plus connu étant telnet).
La première recommandation, avant toute autre, est de prendre pleinement conscience qu'IPv6 est maintenant présent dans les systèmes d'exploitation. La politique de sécurité doit par voie de conséquence l'intégrer.
De manière plus générale, il est, dans la mesure du possible, conseillé de suivre les points décrits dans la table ci-dessous :
| 1. Filtrer toutes les adresses IPv6 du réseau au niveau du pare-feu de sortie vers l'Internet. |
| ex : ne pas oublier qu'une machine utilise plusieurs adresses IPv6. |
| 2. Employer des adresses IPv6 conformes, mais pas prévisibles pour les systèmes critiques. |
| 3. Bloquer tous les services inutiles au niveau du pare-feu. |
| ex. : pour éviter les tunnels sortants, bloquer le protocole 41 des paquets IPv4. |
| ex. : pour interdire Teredo, bloquer les ports UDP 3544 (src/dst). |
| 4. Filtrer de manière sélective les paquets ICMP (ICMPv4 et ICMPv6). |
| ex : distinguer les différents type de messages (erreurs et information, adressage, etc) |
| 5. Interdire la fragmentation des paquets au niveau IPv6, si cela est possible. |
| Sinon, celle-ci doit être correctement filtrée (tailles min et max). |
| 6. Sélectionner les extensions des entêtes IPv6 qui ont légitimité dans le réseau. |
| ex : faut-il autoriser les jumbogrammes, ou l'extension Router Alert ? |
| 7. Utiliser IPsec pour les communications avec des systèmes critiques, et pour les protocoles de routage. |
| L'authentification doit être déployée dès que possible, via IPsec et IEEE 802.1X (Radius, etc). |
| 8. Renforcer la sécurité au niveau des stations (antivirus, pare-feu, services nécessaires strictement). |
| 9. Garder les bonnes pratiques IPv4 pour appliquer les correctifs de sécurité et les mises à jour. |
| 10. Développer des surveillances adaptées à IPv6 (blocage de périmètres, surveillance du volume, etc). |
| Vérifier que les outils de sécurité utilisés comprennent correctement IPv6. |
En mai 2007, un RFC a été publié, qui éclaircit la recommandation 4 ("Filtrer de manière sélective les paquets ICMP"). Ce dernier, intitulé "RFC 4890 : ICMPv6 Filtering recommandations", donne quelques éclaircissements sur toutes les options de ce protocole bien complexe à filtrer.
A la différence d'ICMPv4, le choix draconien de bloquer tout trafic ICMPv6 pertubera plusieurs services du réseau. La plupart des options ne doivent être utilisées que dans un contexte local, et les règles de filtrage ICMPv6 doivent dépendre aussi bien du type d'adresse dans les paquets que les adresses elles-mêmes (source / destination). Le RFC 4890 reprend donc plusieurs scénarios afin de déterminer ce qu'il est nécessaire, facultatif ou déconseillé de filtrer. En voici un extrait.
En périphérie de réseau, et de manière concise, il est dit qu'il est fortement déconseillé de jeter les paquets suivants :
Dans un environnement local, il faut ajouter aux paquets précédents :
Les autres types et codes d'ICMPv6 doivent être étudiés au cas par cas, en fonction des choix de la mise en œuvre IPv6 (mobilité ? teredo ?).
Si la migration vers IPv6 est reportée, dans l'attente d'une meilleure visibilité, il est fortement recommandé de désactiver les piles IPv6 et les protocoles associés. Il est aussi conseillé de limiter les installations des applications aux piles protocolaires existantes (fonctionnement sous IPv4 uniquement).
Les paragraphes suivants donnent quelques indices pour désactiver les piles protocolaires non utiles sur les systèmes d'exploitation les plus fréquents.
Comme le support d'IPv6 est expérimental sous Windows XP, la configuration se fait en ligne de commandes avec netsh. Il est désactivé par défaut. Pour s'en assurer et le désactiver si ce n'est pas le cas, il suffit de :
La plupart des sytèmes BSD, que ce soit BSD/OS, FreeBSD ou OpenBSD disposent d'IPv6 depuis plusieurs années (FreeBSD depuis sa version 4.0). Actuellement, ces systèmes proposent IPv6 en standard. Si IPv6 n'est pas activé à l'installation, il est possible de rappeler le programme de configuration /stand/sysinstall pour reconfigurer les interfaces. En revanche, si IPv6 est installé, il est plus difficile de le faire disparaître a posteriori. Cela doit passer par la recompilation du noyau. Le pare-feu pf peut sinon être configuré de la sorte :
Les versions MAC OS intègrent IPv6, à partir de la version Jaguar 10.2. Le système d'exploitation attribue une adresse IPv6 par défaut à l'interface réseau, qui est joignable de l'extérieur. Si IPv6 n'est effectivement pas utilisé, il est recommandé de le désactiver :
Pour les versions récentes de Linux (noyau 2.6.X), IPv6 est installé par défaut. A moins de recompiler le noyau, il n'est pas évident de le désactiver complètement. En revanche, la plupart des distributions Linux (Debian, Ubuntu, Fedora) intègrent nativement un outil d'administration pour le filtrage de paquets IPv6, nommé ip6tables (équivalent de l'utilitaire iptables pour IPv4). Il est recommandé de filtrer IPv6 si celui-ci n'est pas utilisé. Cela peut se faire par la série de commandes suivantes :
Certaines distributions indiquent néanmoins d'autres méthodes, comme par exemple OpenSuse et Red Hat, qui proposent :
Les outils de surveillance traditionnels (tcpdump et ethereal) supportent également IPv6, et interprétent l'ensemble des options (extensions) déployées. Ils permettent de comprendre plus précisément les activités IPv6 du réseau. Le document [SANSv6] liste sous forme de mémento les détails de filtrage possibles.
IPv4 ne disparaîtra pas brutalement du monde Internet. A la date de rédaction de ce document, sa disparition totale n'est d'ailleurs pas envisagée. Cependant, nous sommes actuellement dans une période transitoire, où IPv6 émerge. Ce protocole, prometteur, introduit de nombreux changements. Ce document se focalise sur les implications en terme de sécurité de ce dernier, sans toutefois remettre en cause les avantages certains qu'il présente et qui justifie son développement.
Comme il a été montré dans ce document, l'étape de standardisation des protocoles de base d'IPv6 peut être considérée comme achevée. IPv6 résoud plusieurs problèmes de sécurité, mais, malgré cela, plusieurs demeurent, et certains sont directement liés à cette phase transitoire.
De manière schématique, la sécurité IPv6 en l'état n'est pas nécessairement meilleure que celle IPv4. Les mécanismes d'attaques sont très semblables, et les nouveaux protocoles autour d'IPv6 ne changent pas ces vulnérabilités. D'autres peuvent également apparaître, du fait de la jeunesse et de la qualité de mise en œuvre des protocoles associés.
Il est important, dès maintenant, d'envisager ce tournant avec le plus grand soin, et de ne pas oublier qu'IPv6 fait déjà partie de nos systèmes d'information. La SSI doit donc le considérer comme tel, et prendre les mesures nécessaires afin d'obtenir à terme une transition maîtrisée.
http://www.certa.ssi.gouv.fr/site/CERTA-2007-ACT-018.pdf
http://www3.ietf.org/proceedings/06mar/IDs/draft-ietf-dnsop-ipv6-dns-issues-12.txt
http://www.fr.ipv6tf.org/
http://www.jres.org/slides/72.pdf
http://www.netbsd.org/fr/Documentation/network/ipv6/
http://www.niscc.gov.uk
http://www.ietf.org/html.charters/v6ops-charter.html
http://livre.point6.net/
http://sem2.renater.fr/ipv6/
http://www.ietf.org/rfc/rfc0791.txt
http://www.ietf.org/rfc/rfc1519.txt
http://www.ietf.org/rfc/rfc2080.txt
http://www.ietf.org/rfc/rfc2409.txt
http://www.ietf.org/rfc/rfc2460.txt
http://www.ietf.org/rfc/rfc2462.txt
http://www.ietf.org/rfc/rfc2473.txt
http://www.ietf.org/rfc/rfc2474.txt
http://www.ietf.org/rfc/rfc2529.txt
http://www.ietf.org/rfc/rfc2675.txt
http://www.ietf.org/rfc/rfc2711.txt
http://www.ietf.org/rfc/rfc2893.txt
http://www.ietf.org/rfc/rfc3041.txt
http://www.ietf.org/rfc/rfc3056.txt
http://www.ietf.org/rfc/rfc3068.txt
http://www.ietf.org/rfc/rfc3315.txt
http://www.ietf.org/rfc/rfc3513.txt
http://www.ietf.org/rfc/rfc3775.txt
http://www.ietf.org/rfc/rfc3849.txt
http://www.ietf.org/rfc/rfc3879.txt
http://www.ietf.org/rfc/rfc3964.txt
http://www.ietf.org/rfc/rfc3972.txt
http://www.ietf.org/rfc/rfc4048.txt
http://www.ietf.org/rfc/rfc4193.txt
http://www.ietf.org/rfc/rfc4862.txt
http://www.ietf.org/rfc/rfc4882.txt
http://www.ietf.org/rfc/rfc4890.txt
http://www.ietf.org/rfc/rfc5006.txt
http://www.ietf.org/rfc/rfc5095.txt
http://www.sans.org/resources/ipv6_tcpip_pocketguide.pdf
http://www.us-cert.gov/reading_room/IPv6Malware-Tunneling.pdf
http://www.6bone.net/ngtrans_project-status.html
