describe the image
 

Inscrivez-vous à la newsletter

Your email:

Retrouvez-nous sur :

Current Articles | RSS Feed RSS Feed

Sécurité IPv6 : faut-il attendre ou pas ?

  
  
  

describe the image

Et si attendre était la meilleure stratégie IPv6 ?

2011 devait être l’année IPv6. L’épuisement des adresses v4 de l’IANA (fournisseur « mondial »), et l’annonce de la journée mondiale IPv6, le 8 juin, avaient donné le ton. Le message était clair : nous avons besoin d’IPv6 et nous en avons besoin maintenant ! En informatique, les Nostradamus sont légions et sont généralement peu écoutés, mais cette fois-ci, leur prédiction a attiré l’attention des médias. Pour le dire simplement, c’était une histoire sympathique : la croissance exponentielle d’Internet fait que nous avons maintenant besoin de plus d’adresses IP que d’habitants sur terre.

Il y a un certain nombre de faits incontestables : dans un monde de plus en plus connecté, les adresses IPv4 vont être rapidement insuffisantes. En fait, plusieurs fournisseurs d’accès en Asie font déjà face à ce défi et ont réussi leur migration vers IPv6, principalement pour leurs offres de télévision sur IP. Il y a donc un pan entier d’Internet qui n’est plus accessible depuis une adresse IPv4.

Cela dit, si nous devons conseiller les DSI et les RSSI du monde occidental à propos d’IPv6, nous ne pouvons-nous fier uniquement à cette analyse macroscopique. Si vous me permettez une analogie avec la problématique du réchauffement climatique, IPv6 est le problème pour tous, mais pas (encore) la préoccupation de tout le monde. Et pour IPv6 aussi, il y « des vérités qui dérangent ». Passons les en revue ici jouons l’avocat du diable, histoire de contrebalancer la sagesse populaire

Vous n’avez pas (encore) besoin d’IPv6

La gestion des priorités est un challenge familier du DSI. Il y a généralement beaucoup plus de projets que de temps et de ressources, et tous les 2 ans au moins, une nouvelle technologie apparait, histoire d’ajouter un peu de charge. Donc, si IPv6 n’est pas aussi urgent que les experts du marché veulent nous le faire croire, c’est quelque chose d’important à savoir, car cela peut nous (vous) permettre de vous concentrer sur une priorité plus immédiate. On peut citer par exemple la création d’un plan de reprise après sinistre ou passer au « Cloud ».

Disons-le clairement, excepté si vous êtes un hébergeur qui a oublié de réserver assez d’adresses IPv4 pour être tranquille pendant 5 ans (auquel cas, vous ne pouvez en vouloir qu’à vous-même), vous n’avez pas trop à vous inquiéter. Il y a beaucoup de raisons à cela, à commencer par le fait que ce n’est pas dans l’intérêt des opérateurs de vous forcer à une migration complète. Après tout, aucun FAI ne veut être le premier à priver ses clients de l’accès à une connectivité IPv4. C’est l’une des raisons pour laquelle la plupart des opérateurs se préparent à optimiser l’utilisation de leurs adresses IPv4. Tout d’abord, ils partageront une adresse IP publique entre plusieurs clients. Dans quelques années, voire quelques mois, votre « box » (CPE) vous attribuera une adresse IP privée. Grâce à des opérations de NAT à grande échelle (Large Scale NAT), le fournisseur d’accès vous donnera accès à l’espace d’adressage public. Cela donnera un sursis de quelques années et libérera des adresses IPv4 pour une réutilisation à destination des serveurs publics.

Donc vous avez encore le temps, mais peut-être vous dites-vous que puis qu’IPv6 est prêt, autant démarrer dès maintenant. Il y a, en fait, plusieurs bonnes raisons pour attendre.

IPv6 est un risque

Cette phrase peut vous faire peur (ou vous laisser incrédule), mais d’un point de vue purement sécurité, IPv6 crée plus de risques qu’il n’apporte d’améliorations. Malgré de nombreuses modifications dont le but était d’améliore la sécurité, ces changements, loin de tout corriger, ajoute au contraire de nouveaux risques. Regardons cela en détail.

Tout d’abord, IPSec, la plus grande amélioration apportée par IPv6 est déjà disponible en IPv4. Même si la compatibilité devient obligatoire avec la norme IPv6, la plupart des RSSI utilisent déjà le chiffrement et le tunneling pour sécuriser leurs flux sensibles.

Egalement, l’arrivée IPv6 n’apporte aucune réponse en matière de sécurité du réseau local (LAN). On pourrait même aller jusqu’à dire qu’elle a rendu plus complexe l’atteinte de cet objectif. La configuration automatique sans état des adresses (SLAAC) n’est pas sécurisée au niveau conceptuel. Une fois qu’une machine à configuré son adresse locale, il interroge ses voisins pour vérifier qu’aucun autre élément n’utilise la même adresse. S’il reçoit une réponse affirmative, la procédure d’attribution d’adresse s’arrête. Cela signifie qu’une personne malintentionnée n’a qu’à répondre par l’affirmative à toute tentative de détection d’adresse dupliquée (DAD). Cette technique est suffisante pour créer un déni de service sur le réseau local. Pour ceux qui sont familiers avec la notion d’usurpation ARP, il n’y a rien de réellement nouveau, il est juste dommage que personne n’ait saisi l’opportunité de corriger ce problème.

Egalement, l’arrivée IPv6 n’apporte aucune réponse en matière de sécurité du réseau local (LAN). On pourrait même aller jusqu’à dire qu’elle a rendu plus complexe l’atteinte de cet objectif. La configuration automatique sans état des adresses (SLAAC) n’est pas sécurisée au niveau conceptuel. Une fois qu’une machine à configuré son adresse locale, il interroge ses voisins pour vérifier qu’aucun autre élément n’utilise la même adresse. S’il reçoit une réponse affirmative, la procédure d’attribution d’adresse s’arrête. Cela signifie qu’une personne malintentionnée n’a qu’à répondre par l’affirmative à toute tentative de détection d’adresse dupliquée (DAD). Cette technique est suffisante pour créer un déni de service sur le réseau local. Pour ceux qui sont familiers avec la notion d’usurpation ARP, il n’y a rien de réellement nouveau, il est juste dommage que personne n’ait saisi l’opportunité de corriger ce problème.

Clairement, pour un RSSI Européen ou Américain, il n’y a aucun bénéfice à court terme à migrer à IPv6, et une boîte de Pandore pleine de risques.

Le NAT est une mesure de sécurité

Un autre défi ambigu lié à IPv6, est que vous devriez pouvoir vous passer d’opérations de translation (NAT). Il y a tellement d’adresses disponibles que chaque société devrait recevoir un préfixe (ensemble d’adresses IPv6) suffisamment important pour pouvoir allouer une adresse globale à chaque élément de son réseau. Le problème est que, même si nous sommes bien d’accord sur le fait que le NAT a ses limites, il reste un palliatif relativement correct à une politique de sécurité qui serait défaillante par ailleurs. Convaincre un DSI qu’il doit utiliser uniquement des adresses IP globales (et donc publiques) constitue un vrai défi, avec une probabilité très faible de succès. Jusqu’en 2010, le NAT était présent dans la norme PCI-DSS (v1.2) en tant que mesure de sécurité.

Si vous demandez à un responsable réseau quel niveau de sécurité aurait son infrastructure en l’absence de NAT, vous aurez probablement une réponse du type « Je ne sais pas, probablement autant sécurisé ». Le point critique ici est qu’aucun RSSI ne risquera sa carrière sur un « probablement »  De ce fait, le NAT survivra probablement à IPv6. Bien sûr, ce n’est, en théorie, qu’une question de conduite du changement, et chaque argument en faveur du NAT peut être défait. Mais, au final, il reste beaucoup d’accros au NAT dans l’univers IT, et je prends le pari avec vous, de nombreux responsables préféreront conserver leur réseau interne en adressage privé IPv4, plutôt que de le basculer en adressage public IPv6.

IPv6 n’est pas prêt pour un déploiement massif

Je sais, c’est un choc, mais après 15 ans de préparation, IPv6 n’est pas complètement prêt. Même si les dernières spécifications sont précises et pertinentes, elles ne sont pas implémentées sur le terrain. Encore une fois, faisons un inventaire des faits.

Le protocole de découverte sécurisée des voisins (SEND), nécessaire à une attribution d’adresse sûre, n’est pas supporté par les piles IP réseaux des principaux systèmes d’exploitation utilisés aujourd’hui. DHCPv6 n’est pas recommandé, mais il existe encore des implémentations qui n’acceptent pas l’attribution de serveurs DNS via la mécanique sans état. Le DNS est un composant encore plus critique en IPv6 (puisque vous n’allez probablement pas apprendre par cœur beaucoup d’adresses), mais le protocole DNSSEC est très peu utilisé, sans compter le fait qu’il n’est pas compatible avec cette même attribution d’adresse IP sans état.

En plus de tous ces éléments, une question importante reste ouverte. Sauf si vous travaillez pour Google ou pour un autre géant Américain, vous ne pourrez probablement pas acheter un préfixe IPv6. Leur attribution est réservée aux fournisseurs d’accès. Donc, si rien ne change, vous serez liés à votre fournisseur d’accès.

De toute façon, vous n’avez pas le budget

Une autre vérité qui dérange avec IPv6, c’est que cela risque de vous coûter beaucoup d’argent. Je vous entends déjà crier : « Une minute, une mise à jour logicielle suffit ! ». Effectivement, en théorie, c’est suffisant. En pratique, puisque les adresses v6 font 4 fois la taille des adresses v4, vous feriez mieux de vérifier que chaque équipement est compatible avec cette mise à jour logicielle. Une fois cette première étape franchie, vous devrez vous assurer que ces équipements peuvent fonctionner au même niveau de performance, ou accepter une perte de performance après la migration. Bien sûr, même si la plupart des constructeurs vont fournir des mises à jour pour les équipements récents, certains oublieront de vous parler de l’impact en performance. Vous ne le découvrirez malheureusement, qu’une fois passé en IPv6. Le défi sera alors de réussir à obtenir un budget supplémentaire, juste pour délivrer la même qualité de service qu’auparavant.

En fonction de votre secteur d’activité, vous aurez peut-être à tenir compte d’équipements spécifiques comme des imprimantes lasers à grand format (architectes, designers), ou des machines d’imagerie sophistiquées (hôpitaux, cliniques). Le passage à IPv6 pour ces équipements demandera un travail supplémentaire.

Avant de démarrer, vous devez donc évaluer le coût total (équipement + temps passé), et ne pas oublier les mises à jour régulières qui interviendront, car comme nous l’avons dit plus haut, vous devriez vous attendre à de nombreux patchs de sécurité.

Vous m’avez mis le doute, que dois-je dire à mon chef ?

Et maintenant que fait-on ? Vous êtes convaincus qu’il est plus sage d’attendre, mais on vous a demandé de vous préparer en urgence au passage à IPv6. Tant mieux ! Avoir le temps ne signifie pas que vous ne pouvez pas vous préparer. Cela vous permet seulement de choisir la cadence de cette évolution, et de le justifier

Il peut paraître décevant que la compatibilité avec les réseaux existant n’ait pas obtenu une priorité plus forte au moment de la conception d’IPv6. Malheureusement, plusieurs changements apportés augmentent le risque d’un passage à cette nouvelle version, plutôt que de le diminuer, comme nous l’espérions tous. Le résultat est que la transition sera très longue.

L’objectif de cet article n’est pas de rejeter IPv6 en bloc. Comme je l’ai expliqué, il y a de bonnes raisons de se préparer pour l’adoption future de ce protocole. L’enjeu principal est juste le rythme de cette transition. Entamer aveuglement cette migration, simplement parce que le sujet est à la mode, et sans y accorder suffisamment d’attention préalable pourrait exposer votre réseau à un niveau de risque inutilement élevé. Inutilement, car selon Google, seulement 0,4% du trafic à destination de leurs serveurs utilise IPv6. Êtes-vous prêts à expliquer que votre réseau complet a été compromis à cause d’une faille IPv6, qui ne représente même pas 1% de votre trafic ?

Rien ne vous empêche de démarrer maintenant. Allouez simplement le temps nécessaire à la planification et aux choix d’architecture, en tenant compte de la nécessaire cohabitation v4/v6. Ne vous pressez pas, il n’y a que peu de gloire à être un « early adopter ». Vous pouvez, par exemple, restreindre la première étape à une DMZ non critique, en utilisant une architecture DNS splittée et un reverse proxy  applicatif pour convertir les requêtes IPv6 en requête IPv4. Cela aura le goût d’IPv6, son parfum, mais votre profil de risque restera limité.

Alors qu’en pensez-vous ? Est-il urgent d’attendre ? N’hésitez pas à partager votre expérience ou votre avis sur la question dans les commentaires.