Activité 34 : Sécurisation des usages du réseau IPv6

Introduction

La mise en œuvre d’IPv6 dans un réseau doit s’accompagner de la définition de politiques de sécurité adaptées en bordure de votre réseau. Sans ces politiques de sécurité, le trafic IPv6 ne sera pas filtré et la surface d’attaque du réseau se retrouvera augmentée. Aujourd’hui les attaques provenant de l’Internet utilisant le protocole IPv6 ne sont pas très répandues. Mais leur nombre va certainement croître parallèlement au déploiement et à la banalisation du nouveau protocole.

Certaines vulnérabilités ont cependant été identifiées^[1] et il est donc important de suivre les bonnes pratiques de filtrage afin de protéger votre réseau des attaques extérieures potentielles, mais aussi éviter des attaques pouvant être initiée depuis votre réseau et à destination d’autres réseaux. Ces règles de filtrage doivent être appliquées avec discernement, ainsi un filtrage aveuglement trop strict des messages ICMPv6 peut compromettre le bon fonctionnement du protocole IPv6.

Principales vulnérabilités d’un site activant IPv6

Exposition des réseaux et des équipements

L’utilisation systématique d’adresse unicast globale est pour IPv6 à la fois son point fort en terme de connectivité à travers le réseau, mais aussi son point faible en terme de sécurité. Chaque équipement connecté est supposé être joignable en IPv6 depuis l’Internet. L’absence de politique de sécurité adaptée en bordure de réseau peut donc entrainer des connexions non sollicitées provenant de l’Internet à destination des équipements connectés.

Usurpation et détournement d’adresses

Comme pour IPv4, il est possible de forger une adresse IP comme adresse source d’un paquet IPv6. L’espace d’adressage IPv6 étant plus vaste qu’en IPv4, les adresses IPv6 potentiellement forgées sont plus nombreuses. Ces adresses forgées peuvent être utilisées pour des attaques malveillantes à destination du réseau du site mais aussi depuis le réseau interne vers un autre réseau.

Amplification

Comme pour IPv4, IPv6 définit des adresses multicast permettant d’émettre un message à destination d’un groupe d’équipement. Une attaque courante est d’utiliser ce type d’adresse comme adresse source d’un message entrant dans le réseau. Le destinataire de ce message, croyant répondre légitimement à la source, va émettre un message en multicast à destination d’un groupe plus large.

Vulnérabilité des implémentations

Certains produits, équipements comme logiciels, peuvent indiquer une compatibilité au protocole IPv6. Cependant l’implémentation de cette fonctionnalité est potentiellement peu mature et mal testé. Ces produits peuvent donc présenter des vulnérabilités et être sujets à certaines attaques. Exemple : Les routeurs de la Mikrotix peuvent être victimes d’un déni de service par saturation de certaines tables spécifiques à la gestion du protocole IPv6. Le problème a depuis été corrigé^[2].

Porte dérobée utilisant les mécanismes de transition vers IPv6

Même si le réseau interne d’un site n’est pas connecté à l’Internet IPv6, la disponibilité et l’activation de la pile IPv6 sur les équipements du site peut constituer une augmentation de la surface d’attaque. Il est en effet possible de l’exploiter grâce aux protocoles de tunnels permettant de transporter le protocole IPv6 au dessus d’IPv4 (6in4, 6to4, TEREDO). Un équipement malveillant au sein du réseau interne peut mettre en place un tel mécanisme pour installer une porte dérobée vers l’Internet.

Activation illégitime de mécanismes d'auto-configuration

L'activation non contrôlée, par maladresse ou malveillance, de mécanismes d'auto-configuration permet la mise en place de détournements de trafic RFC 6104. Des points de contrôle illégitimes du trafic peuvent alors être introduits conduisant à des attaques de type MiM (Man In the Middle) dans lesquelles un intermédiaire frauduleux abuse du trafic à des fins de surveillance ou d'usurpation. Les techniques d'introduction illégitime de "faux AP" sur les espaces wifi, ou de faux serveurs DHCP en IPv4, s'appliquent également dans un contexte IPv6. La surface de ce type d'attaque s'en trouve même augmentée en IPv6 par le détournement du mécanisme d'auto-configuration sans état (SLAAC Stateless Address Auto-Configuration). En activant de fausses annonces de routeur l'attaquant (couramment dénommé RAcaille : RouterAdvertisment-caille) va contrôler l'attribution d'adresses automatiques dont le trafic sera routé explicitement vers ses équipements.

Adaptation des politiques de sécurité déjà définies en IPv4

Politiques d’accès aux services

En IPv4, les politiques de sécurité à l’entrée du site doivent normalement n’autoriser des connexions entrantes uniquement à destination des équipements hébergeant des services ouverts sur l’Internet. Il est donc recommandé de dupliquer ces règles en IPv6 pour ces mêmes équipements afin de permettre l’accès à ces services.

Dans la phase de déploiement d’IPv6 au sein du site, il est de plus recommandé de n’activer ces règles seulement une fois que le service ait pu être testé comme opérationnel en IPv6 et qu’il ait été publié dans le DNS.

Isolation des réseaux internes

Les équipements qui n’hébergent pas de service accessible depuis l’Internet doivent être protégés des connexions entrantes. Si de plus ces équipements ne sont pas amenés à communiquer avec des services extérieurs, une isolation complète de ces équipements peut être réalisés en interdisant, en IPv6 comme en IPv4, tout paquets émis ou à destination de ces équipements.

La politique de sécurité doit être adaptée si les équipements sont autorisés à communiquer avec l’extérieur, comme par exemple les postes utilisateurs. En IPv4, la translation d’adresse (NAT) est souvent considérée par erreur comme suffisante pour permettre les connexions initiées depuis les équipements à destination de l’Internet tout en les isolant des connexions entrantes. Il est recommandé d’ajouter à ce mécanisme, pour IPv6 comme pour IPv4, des règles de filtrage avec état (statefull) permettant de n’autoriser en entrée du réseau que des paquets correspondant à des connexions ouvertes depuis le réseau interne.

Filtrage des mécanismes de tunnels IPv6 dans IPv4

Les mécanismes de tunnels IPv6 dans IPv4 pouvant être détournés pour créer depuis l’intérieur du réseau des portes dérobées, il est recommandé de les interdire en entrée comme en sortie du réseau. Les règles de filtrage IPv4 doivent donc interdire le transport du protocole IPv6 (protocole 41) afin de désactiver les mécanismes 6in4 et 6to4. Le mécanisme TEREDO peut être rendu inopérant en désactivant le protocole UDP et plus spécifiquement le port 3544. Si les tunnels IPv6 dans IPv4 sont utilisés depuis l’intérieur du réseau pendant la phase de déploiement d’IPv6, seuls les équipements identifiés comme points d’entrée de tunnel doivent être autorisés à utiliser le transport du protocole 41.

Contrôle de la source du trafic d'auto-configuration

Le contrôle de la source des trafics d'auto-configuration est recommandé afin de lutter contre l'introduction de mécanismes détournement de trafic RFC 6104. Comme l'indique S. Bortzmeyer dans son analyse de ce RFC 6104 : "Si une machine envoie des RAcailles sans y être autorisée, on n'a pas de raison d'avoir des scrupules à la faire taire".

Des techniques de filtrage au niveau des commutateurs d'un réseau local peuvent assurer que seule la source légitime des annonces est commutée sur les différents segments du domaine de diffusion. Cependant elles ne sont généralement pas simples et alourdissent la charge de l'administrateur réseaux. Des ACL sur les adresses MAC sources des routeurs légitimes et le type Router Advertisement du protocole ICMPv6 peuvent être déployées sur les commutateurs du réseau local mais posent le problème du passage à l'échelle sur les LAN de grande taille. Le RFC 6105 (IPv6 Router Advertisement Guard) décline cette approche du filtrage selon deux modes sans état ou avec état introduisant, dans le second cas, une phase d'apprentissage de reconnaissance des émetteurs légitimes des annonces.

Une autre stratégie consiste à détecter puis empoisonner les RAcailles. Il s'agit de détecter les annonces illégitimes à l'aide d'un outil de surveillance des annonces de voisinage tel NDPMon ou RAMOND lorsqu'elles se diffusent sur le réseau, puis de les invalider par la diffusion d'une contre-annonce avec une durée de vie nulle.

Enfin la stratégie la plus aboutie serait de s'appuyer sur la découverte sécurisée du voisinage à l'aide du protocole SEND (RFC 3971: SEcure Neighbor Discovery) où les annonces des routeurs légitimes sont signées. Ce dernier n'est cependant pas banalisé car il nécessite de déployer les outils de chiffrement et les certificats associés sur l'ensemble des équipements du réseau. Il n'est donc pas adapté aux environnements contraints avec peu de capacité tels le "grille pain" de l'Internet des objets. Cependant le RFC 6105 indique dans ses recommandation qu'un commutateur peut être mandataire SEND et configuré avec un certificat. Avec le mandataire SEND, seul le commutateur va valider les annonces signées par SEND.

Filtrage spécifique du trafic IPv6 entrant

Filtrage sur les adresses source

Le trafic IPv6 entrant peut présenter des adresses IPv6 illégitimes dans le champ source du paquet. Une adresse source d’un paquet entrant sur le réseau d’un site doit obligatoirement être une adresse IPv6 unicast global. Aucun autre type d’adresse (unicast lien local, unicast local ou multicast) n’est censé être présent dans le champ adresse source d’un paquet entrant. Un premier filtrage sur ce champ adresse source peut donc être défini en n’autorisant que les adresses IPv6 unicast globale (incluse dans le préfixe 2000::/3) et rejetant toute autre adresse.

Cependant, même si une adresse est bien de type unicast globale, il est possible qu’elle ne corresponde à aucun réseau effectivement déclaré et déployé. Ce type d’adresse s’appelle BOGON et est caractéristique d’une adresse forgée. Une politique restrictive de filtrage consiste à n’autoriser en entrée du réseau que les adresses appartenant à des préfixes effectivement alloués par les RIRs. Cette liste est cependant très longue et mise à jour fréquemment. Une autre solution consiste à autoriser toutes les adresses IPv6 et d’exclure les adresses de type BOGON. La liste des préfixes BOGON à interdire en entrée du réseau est disponible en ligne. Mais de la même façon, cette liste est longue et fréquemment mise à jour. Il est alors nécessaire d'utiliser des outils pour récupérer ces listes afin de mettre à jour les règles de filtrage.

Une politique plus simple, mais certes plus relâchée, consiste à n’autoriser que les préfixes alloués par l’IANA aux RIRs. Le tableau ci-dessous présente cette liste des préfixes à autoriser, qui n’a pas évoluée depuis 2008^[3][4]

Préfixe IANA	Allocation
2001::/16	Divers RIRs
2002::/16	6to4(voir note)
2003::/18	RIPE-NCC
2400::/12	APNIC
2600::/10	ARIN
2800::/12	LACNIC
2a00::/12	RIPE-NCC
2a10::/12	RIPE-NCC
2c00::/12	AfriNIC

Note : Le préfixe 2002::/16 (6to4) est encore officiellement autorisé. Cependant l’usage de ce protocole de transition étant découragé par le RFC 7526, il est conseillé de le retirer de la liste des préfixes autorisés.

Filtrage du protocole ICMPv6

Le protocole ICMPv6 est utilisé pour deux fonctions : les rapports d’erreurs et la gestion du bon fonctionnement du réseau. Les rapports d’erreurs signalent un problème d’acheminement d’un paquet et peuvent être émis depuis n’importe quel routeur intermédiaire dans l’Internet ayant détecté le problème. Le rapport d’erreur est envoyé à destination de l’adresse source du paquet afin de traiter l’erreur sur le paquet fautif.

Les différents rapports d’erreurs, identifiés par le champ Type du message ICMPv6, sont

• Destination inaccessible (Destination Unreachable, ICMPv6 Type=1) : le paquet fautif est remonté à l’application émettrice
• Taille de paquet trop grande (Packet too big, ICMPv6 Type=2) : la taille du paquet est ajusté par le niveau supérieur ou le paquet est fragmenté
• Temps dépassé (Time exceeded, ICMPv6 Type=3) : le paquet fautif est remonté à l’application émettrice
• Problème de paramètre (Parameter problem, ICMPv6 Type=4) : le paquet fautif est remonté à l’application émettrice

En entrée du réseau, il est recommandé d’autoriser les messages ICMPv6 contenant un rapport d’erreur (Type >128). Ces messages pouvant provenir de n’importe quel équipement intermédiaire, toutes les adresses sources doivent être autorisées. Un filtrage trop restrictif des messages ICMPv6 peut perturber le bon fonctionnement du protocole IPv6.

Les fonctions de gestion du réseau utilisant ICMPv6 concernent principalement les tests d’accessibilité par échange de messages Echo Request / Echo Reply (application ping6, ICMPv6 Type=128/129). Ces messages, identifiés par une valeur Type supérieure ou égale à 128, peuvent être interdits en entrée du réseau sans risquer de perturber le fonctionnement du protocole IPv6. Ce filtrage permet notamment de se prémunir de tentative de scan de réseau en IPv6. Lors de la phase de déploiement d’IPv6, l’outil ping6 peut cependant être utile pour diagnostiquer des problèmes de connectivité.

Les bonnes pratiques du filtrage du protocole ICMPv6 sont décrites dans le document RFC 4890.

Filtrage des extensions d’en-tête IPv6

Les extensions d’en-tête IPv6 permettent d’augmenter le protocole IPv6 de certaines fonctionnalités comme la fragmentation et le chiffrement IPsec. La présence d’une extension d’en-tête peut être identifiée par la valeur du champ Protocole de l’en-tête IPv6. Ces fonctionnalités sont relativement nouvelles, leur usage a cependant déjà été détourné pour des utilisations malveillantes^[5].

Il est possible d’interdire tout trafic IPv6 entrant et sortant présentant des extensions d’en-tête, cependant certains cas demandent une étude particulière. Ainsi, des paquets IPv6 peuvent légitimement présenter une extension de fragmentation. Ces paquets transportent normalement un datagramme UDP qui n’a pas pu être transporté dans un seul paquet car de taille plus importante que la MTU minimale sur le chemin. Ce type de message UDP peut être présent dans le trafic entrant pour le protocole DNS, lors d’une demande de résolution incluant la vérification de la signature DNSSEC. Un serveur de résolution DNS présent dans le réseau interne, configuré pour effectuer cette vérification, peut donc être amené à recevoir des paquets IPv6 fragmenté. Dans ce cas précis, il est recommandé d’accepter les paquets contenant l’en-tête de fragmentation, uniquement s’ils concernent le DNS et sont à destination du résolveur.

Le chiffrement IPsec nécessite en IPv6 l’utilisation des extensions d’en-tête AH (Authentication Header) et ESP (Encapsulated Security Payload). Ces extensions peuvent donc être présentes dans le trafic entrant à destination d’équipements mettant en œuvre IPsec. Les équipements destinataires sont généralement les concentrateurs VPN disponibles dans le réseau interne ou les clients présents sur un réseau BYOD. Si ce type d’équipements est présent et que des connexions IPsec sont envisagées en IPv6, il sera nécessaire pour l’établissement des tunnels que les extensions d’en-tête AH et ESP soient autorisées.

Filtrage spécifique du trafic IPv6 sortant

Filtrage anti-spoofing

Sur le trafic IPv6 en sortie du réseau, il est important de vérifier que les adresses sources des paquets sortants appartiennent aux adresses valides dans le réseau interne. Cette bonne pratique, spécifiée dans le document BCP38 ^[6], permet d’éviter les usages malveillants depuis le réseau interne utilisant des adresses forgées. Cette recommandation s’adresse principalement en IPv4 aux opérateurs et aux administrateurs de larges sites. En IPv6, chaque site possédant son propre préfixe, chaque administrateur est amené à respecter cette pratique. Il est donc recommandé de filtrer le trafic IPv6 sortant en n’autorisant que les paquets utilisant des adresses source appartenant au préfixe IPv6 qui a été alloué au site.

Filtrage du protocole ICMPv6

A l’instar des messages ICMPv6 entrants, les messages ICMPv6 contenant un rapport d’erreur (Type < 128) doivent être autorisés en sortie du réseau. Cependant ces messages ne pourront être émis seulement par les équipements autorisés à recevoir des paquets IPv6 (équipements serveurs et clients si autorisés). Un filtrage sur l’adresse source de ces messages ICMPv6 peut donc être ajouté. Les messages ICMPv6 de contrôle (Type >= 128) peuvent être interdits en sortie de réseau sans risquer de perturber le fonctionnement du réseau. Lors de la phase de déploiement d’IPv6, l’outil ping6 peut cependant être utile pour diagnostiquer des problèmes de connectivité. Les bonnes pratiques du filtrage du protocole ICMPv6 sont décrites dans le document RFC 4890.

Filtrage des extensions d’en-tête IPv6

De la même façon que pour le trafic entrant, les extensions d’en-tête IPv6 peuvent être globalement interdites en sortie du réseau, sauf dans deux cas particulier concernant la fragmentation et l’utilisation d’IPsec. Les en-têtes de fragmentation peuvent se présenter dans le trafic sortant du réseau pour le service DNS. Ce cas peut se présenter si le site héberge un serveur DNS faisant autorité d’un domaine, et que ce serveur met en œuvre la signature de ces zones par DNSSEC. Dans ce cas précis, les réponses vont générer des paquets de taille potentiellement importante qui nécessiteront d’être fragmentés si cette taille est supérieure à la MTU sur le chemin à destination du requérant. Les paquets présentant une extension d’en-tête de fragmentation doivent donc être autorisés en sortie du réseau si ceux-ci concernent le DNS et ont bien été émis par le serveur DNS autoritaire.

Les extensions d’en-tête IPsec (AH et ESP) peuvent être présentes dans le trafic sortant si le réseau interne met en œuvre un concentrateur VPN et/ou autorise l’utilisation d’IPsec depuis les clients des réseaux BYOD. Dans ce cas, les extensions d’en-tête doivent être autorisées pour le trafic sortant émis depuis ces équipements.

Synthèse des règles de filtrage à appliquer

En entrée du réseau

Règles de filtrage IPv4 :

IPv4 Source	IPv4 Dest.	Protocole	Filtrage	Commentaire
any	any	Protocole 41	Interdit	Protection contre tunnel 6in4/6to4 indésirable
any	any	UDP Port 3544	Interdit	Protection contre tunnel TEREDO indésirable

Règles de filtrage IPv6 :

IPv6 Source	IPv6 Dest	Protocole	Filtrage	Commentaire
BOGON	any	any	Interdit	Interdiction des sources non déclarées
Préfixes IANA	IP Serveur	TCP	Sous condition	Autorisation des connexions vers les serveurs
Préfixes IANA	Préfixe site	TCP	Sous condition	Règle stateful pour les connexions client
Préfixes IANA	Préfixe site	ICMPv6 type<128	Autorisé	Autorisation des rapports d'erreurs
Préfixes IANA	Préfixe site	ICMPv6 type>=128	Interdit	Protection contre les scans
Préfixes IANA	Préfixe site	Frag. / UDP Port 53	Sous condition	Si présence d'un résolveur IPv6 DNSSEC
Préfixes IANA	Préfixe site	AH / ESP (IPsec)	Sous condition	Si présence d'un concentrateur VPN ou clients VPN

En sortie du réseau

Règles de filtrage IPv4 :

IPv4 Source	IPv4 Dest.	Protocole	Filtrage	Commentaire
any	any	Protocole 41	Interdit	Protection contre tunnel 6in4/6to4 indésirable
any	any	UDP Port 3544	Interdit	Protection contre tunnel TEREDO indésirable

Règles de filtrage IPv6 :

IPv6 Source	IPv6 Dest	Protocole	Filtrage	Commentaire
Autre que Préfixe Site	any	any	Interdit	Network Ingress Filtering
Préfixe site	Préfixes IANA	TCP	Sous condition	Autorisation des connexions TCP clients
Préfixe site	Préfixes IANA	ICMPv6 type<128	Autorisé	Autorisation des rapports d'erreurs
Préfixe site	Préfixes IANA	ICMPv6 type>=128	Interdit	Protection contre les scans
Préfixe site	Préfixes IANA	Frag. / UDP Port 53	Sous condition	Si présence d'un serveur autoritaire IPv6 DNSSEC
Préfixe site	Préfixes IANA	AH / ESP (IPsec)	Sous condition	Si présence d'un concentrateur VPN ou clients VPN

Sécurité applicative (IDS/IPS)

Les équipements en charge de l’analyse du trafic au niveau applicatif sont appelés IDS (Intrusion Detection System) ou IPS (Intrusion Prevention System) selon qu’ils sont respectivement passifs ou actifs aux attaques détectées. Ces équipements devront être compatibles à IPv6 pour pouvoir accepter le trafic IPv6 qui transitera entre le site et l’Internet. Cette compatibilité sera obligatoire sur l’interface de données par où passe le trafic Internet et optionnelle sur l’interface de contrôle selon la capacité des outils d’administration à communiquer en IPv6. L’analyse de trafic IPv6 devra être possible par l’équipement IDS et IPS avec les mêmes performances que pour le trafic IPv4, afin de ne pas impacter l’expérience utilisateur selon le protocole utilisé. Les attaques au niveau applicatif détectées par ces équipements seront équivalentes selon le protocole utilisé. Les logiciels IDS/IPS open-source communément utilisés (Snort, Suricata, Bro) sont aujourd’hui pleinement capables de détecter n’importe quelle attaque, quelque soit le protocole utilisé ^[7]. Un point de vigilance sera cependant apporté sur la capacité de l’équipement à traiter correctement les extensions de l’en-tête IPv6. Ce mécanisme doit effectivement être pris en considération pour l’analyse des en-têtes de niveau supérieur à celle du protocole IPv6. Sur certains équipements, il a été démontré que ce mécanisme pouvait être utilisé pour contourner des règles de détection ^[8]. Ce problème a depuis été corrigé.

Références bibliographiques

1. ↑ A complete guide to IPv6 attack and defense, Whitepaper, SANS Institute, Novembre 2011. https://www.sans.org/reading-room/whitepapers/detection/complete-guide-ipv6-attack-defense-33904
2. ↑ CVE-2018-19298 CVE-2018-19299 IPV6 RESOURCE EXHAUSTION, Mikrotik, Avril 2019. https://blog.mikrotik.com/software/cve-2018-19298-cve-2018-19299-ipv6-resource-exhaustion.html
3. ↑ Liste des préfixes IPv6 alloués par l'IANA https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
4. ↑ How to Securely Operate an IPv6 Network, E. Vyncke, Cisco, 2014 https://www.troopers.de/wp-content/uploads/2013/11/TROOPERS14-Secure_Operation_of_an_IPv6_Network-Eric_Vyncke.pdf
5. ↑ IPv6 extension headers and security: Analyzing the risk, F.Gont, Decembre 2014 https://searchsecurity.techtarget.com/tip/IPv6-extension-headers-and-security-Analyzing-the-risk
6. ↑ Network Ingress Filtering, BCP38, Mai 2000. https://tools.ietf.org/html/bcp38
7. ↑ A Performance Comparison of Intrusion Detection Systems with Regard to IPv6, Whitepaper, SANS Intitute, Mai 2015 : https://www.sans.org/reading-room/whitepapers/logging/ipv6-open-source-ids-35957
8. ↑ Evasion of High-End IPS Devices in the Age of IPv6, A. Atlasys, E. Rey, Août 2014 https://www.blackhat.com/docs/us-14/materials/us-14-Atlasis-Evasion-Of-HighEnd-IPS-Devices-In-The-Age-Of-IPv6-WP.pdf

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 3971: SEcure Neighbor Discovery (SEND) Analyse
• RFC 4890: Recommendations for Filtering ICMPv6 Messages in Firewalls
• RFC 4942: IPv6 Transition/Co-existence Security Considerations
• RFC 6092: Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service Analyse
• RFC 6104 Rogue IPv6 Router Advertisement Problem Statement Analyse
• RFC 6105: IPv6 Router Advertisement Guard Analyse
• RFC 6169: Security Concerns with IP Tunneling
• RFC 6192: Protecting the Router Control Plane,
• RFC 7113: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) Analyse
• RFC 7707 Network Reconnaissance in IPv6 Networks Analyse
• RFC 9099: Operational Security Considerations for IPv6 Networks Analyse
• S. Bortzmeyer Exposé sur la sécurité d'IPv6 à l'ESGI