Activité 34 : Sécuriser les usages d'un réseau IPv6

Introduction

Nous allons dans cette vidéo aborder la question de la sécurité d'un réseau IPv6. Et nous commencerons par ce constat : La sécurisation d'un réseau en IPv6 ne présentent pas de différence majeure avec la démarche adoptée en IPv4. L'ingénieur réseau retrouvera beaucoup de similarités entre les deux versions du protocole.

Pas de différences majeures, mais quelques différences subtiles quand même. Nous allons détailler dans la suite ces quelques points à considérer dans politiques de sécurité en IPv6.

Vulnérabilités sur trafic entrant

L'évolution apportée par IPv6 qui perturbe le plus les esprits soucieux de la sécurité des réseaux est l'utilisation généralisée de l'adressage globale.

Assigner des adresses globales à tous les équipements de son réseau peut en effet en augmenter sa surface d'attaque : un attaquant pourrait ainsi atteindre plusieurs cibles directement joignables en IPv6.

Ces machines, de plus, peuvent utiliser des implémentations logiciels vulnérables en IPv6. Le risque paraît donc élevé.

Pour réduire ce risque, il faut d'abord rappeler que pour joindre directement une machine, l'attaquant a besoin de son adresse IP.

Pour trouver ces adresses joignables, il devra tester l'ensemble des adresses IP d'un réseau. En IPv4, cette énumération est facile : un réseau contient quelques centaines voir milliers d'adresses.

Mais en IPv6, il est très compliqué d'identifier les adresses joignables parmi des milliards d'adresses possibles sur un réseau.

A la manière du NAT en IPv4, qui, rappelons-le, n'est pas un dispositif de sécurité, il est possible en IPv6 d'interdire les connexions entrantes pour les machines n'hébergeant pas de services. Ce filtrage s'effectue dans un dispositif approprié, comme un pare-feu.

Une politique de sécurité explicite les communications autorisées entre les réseaux. Sa mise en application dans les pare-feu qui isolent ces réseaux les uns des autres prévient de tout connexion illicite. Ceci est valable en IPv6 comme en IPv4.

Vulnérabilités sur trafic sortant

Pour atteindre de manière anonyme une cible ou tenter de contourner des règles de sécurité, un attaquant peut tenter d'usurper une adresse IP d'un autre réseau et l'utiliser comme adresse source du paquet malveillant.

Comme pour IPv4, il est possible de modifier l'adresse source d’un paquet IPv6. L’espace d’adressage IPv6 étant plus vaste qu’en IPv4, les adresses IPv6 qu'il est possible d'usurper sont plus nombreuses.

La cible qui reçoit un tel paquet peut y répondre avec un nouveau paquet contenant l'adresse usurpée comme destination. On dit qu'elle est utilisée alors comme rebond. Si l'adresse source est une adresse multicast, sa réponse va atteindre plusieurs machines. On parle alors d'attaque par amplification.

La contre-mesure à ce type d'attaque se situe de nouveau au niveau de pare-feux. Tout d'abord, le filtrage des paquets entrant sur le réseau de la cible doit vérifier si le paquet a une adresse source légitime. Une adresse multicast comme source est un signal fort d'un paquet malveillant qui doit donc être éliminé.

Mais ce pare-feu ne pourra pas reconnaitre les adresses usurpées provenant d'un réseau IPv6 légitime. Le filtrage doit alors s'effectuer au niveau du pare-feu du réseau de l'attaquant. Celui-ci ne doit autoriser en sortie uniquement les paquets ayant des adresses sources appartenant à ce réseau. Il devient alors impossible d'envoyer des paquets usurpant des adresses d'un autre réseau.

Vulnérabilités liées à la transition

Un réseau qui n'est pas connecté à l’Internet IPv6 n'est cependant pas à l'abri de problèmes liés à ce nouveau protocole. Il faut savoir que certains systèmes dans un environnement IPv4 seul activent automatiquement des protocoles de transitions comme 6to4 ou TEREDO. Se créent alors des tunnels IPv6 sur IPv4 entre ces équipements et l'Internet IPv6. Ces tunnels peuvent être détournés pour servir de porte dérobée, soit pour échapper aux politiques de filtrage, soit pour pénétrer dans le réseau local.

Il est donc important que les sites ne disposant pas encore d'IPv6 se prémunissent contre ces usages en interdisant aux équipements en interne l'utilisation de ces protocoles de transition. Le blocage de ces tunnels peut se faire simplement en filtrant les numéros de ports du transport UDP ou le champ protocole de l'en-tête IPv4.

Vulnérabilités liées à l'auto-configuration

Le mécanisme de découverte des voisins sur le réseau local, comme celui d'auto-configuration, présente des vulnérabilités dès qu'un équipement malveillant est présent sur le même réseau.

Il est par exemple facile de perturber la détection de l'adresse dupliqué. Un équipement malveillant peut répondre systématiquement à chaque sollicitation de voisin sur le réseau et ainsi affirmer posséder toutes les adresses IPv6 qui cherchent à être configurées par les autres stations.

Si ce comportement est contrariant pour le réseau local, l'équipement fautif sera facilement identifiable.

L'équipement malveillant peut aussi chercher à se faire passer pour le routeur de sortie du réseau en diffusant des annonces de routeurs. Il va alors contrôler l'attribution d'adresses automatiques et potentiellement router vers lui le trafic sortant du réseau local.

Ces messages parasites, aussi appelé judicieusement RA-cailles, sont insidieux car ils ne créent par de rupture de la connectivité. L'utilisateur a toujours l'impression que le réseau fonctionne, alors que ses paquets traversent un équipement illégitime.

Il n'est pas simple de prévenir ces comportements car les messages de découverte des voisins sont échangés dans un réseau local, sans équipement de filtrage intermédiaire. Des problèmes équivalents existent en IPv4 avec la compromission du protocole ARP ou les serveurs DHCP parasites.

Conscient de ces problèmes, les équipementiers ont depuis développé des mécanismes de filtrage des RA-cailles dans les commutateurs de niveau 2. Il est ainsi possible de n'autoriser la diffusion d'annonce de routeur que pour le port du commutateur connecté au routeur de sortie. Les annonces provenant d'autres ports seront ainsi éliminés avant leur diffusion.

Conclusion

En IPv6 comme en IPv4, la sécurité du réseau est à considérer avec attention et pragmatisme. Déployer IPv6 sur son réseau apporte en effet des risques supplémentaires. Mais ces risques ne sont pas insurmontables s'ils sont traités sérieusement et bien intégrés dans une politique de sécurité.

Mais combien de politique de sécurité s'appuient encore sur la croyance que les attaques s'arrêtent à la porte du NAT IPv4 isolant le réseau local de l'Internet ? Ces approches empiriques sont aujourd'hui un frein au déploiement d'IPv6. L'intégration du nouveau protocole dans un réseau est souvent l'occasion d'établir des fondations plus solides pour la sécurité des réseaux.

Ces remarques s'appliquent bien pour les réseaux administrés, dans une entreprise ou un campus universitaire. La situation est différente dans des domaines comme la domotique et l'Internet des Objets où IPv6 est très présent mais où la sécurité des réseaux est encore très perfectible.