Sécurité IPv6 : les points à ne pas négliger

On est tenté de traiter IPv6 comme un simple remplaçant d'IPv4 qui se trouve juste disposer d'un espace d'adressage plus vaste. Côté sécurité, quelques différences réelles méritent d'être comprises plutôt que de supposer que tout ce qui vaut pour IPv4 se transpose à l'identique.

La liste de blocage doit être construite séparément, pas seulement allongée

IPv6 possède ses propres plages privées, de bouclage et de lien local, structurées différemment de leurs équivalents IPv4. Un contrôle de sécurité qui ne sait analyser et filtrer que les plages IPv4 laissera passer silencieusement toutes celles-ci du côté IPv6 : non pas parce qu'IPv6 est moins sûr, mais parce que les protections équivalentes n'ont tout simplement jamais été conçues pour lui.

Adresses IPv4-mappées : un angle mort facile à manquer

IPv6 dispose d'une notation permettant d'intégrer une adresse IPv4 dans une adresse IPv6, par exemple ::ffff:127.0.0.1, qui désigne la même adresse de bouclage que le simple 127.0.0.1, simplement écrite sous forme IPv6. Un contrôle qui filtre correctement le bouclage IPv4 mais ne déballe pas cette forme intégrée approuvera une adresse fonctionnellement identique à une adresse qu'il aurait autrement bloquée d'emblée.

• Tout système qui compare des adresses résolues à une liste de blocage a besoin d'une logique réellement distincte et complète pour IPv6, et non de l'hypothèse que les règles IPv4 se généralisent automatiquement.
• Les adresses IPv6 IPv4-mappées doivent être déballées et vérifiées spécifiquement par rapport aux règles IPv4, et non évaluées comme des adresses IPv6 opaques.
• Les systèmes à double pile (la plupart des systèmes modernes) doivent appliquer les deux contrôles de manière cohérente, car un attaquant utilisera simplement la famille d'adresses sur laquelle se trouve le contrôle le plus faible.

Rien de tout cela n'est une raison d'éviter IPv6 : une adoption plus large est généralement une bonne chose, et la surface d'attaque propre à IPv6 n'est pas intrinsèquement plus grande que celle d'IPv4. C'est une raison de s'assurer que la logique de sécurité qui traite les adresses a réellement été conçue et testée pour les deux familles d'adresses, plutôt que pour une seule avec l'autre ajoutée après coup.

NAT64 ajoute une seconde couche de traduction à connaître

Certains réseaux IPv6 uniquement utilisent NAT64 et DNS64 pour permettre à leurs clients d'atteindre tout de même l'internet réservé à IPv4 : DNS64 synthétise à la volée un enregistrement AAAA pour un domaine qui n'a qu'un enregistrement A, en intégrant l'adresse IPv4 dans un préfixe spécial (64:ff9b::/96 est la valeur par défaut bien connue), et NAT64 retraduit à la périphérie du réseau le trafic vers cette adresse synthétique en véritable IPv4. C'est un mécanisme légitime et utile, mais cela signifie qu'une adresse située dans cette plage précise n'est pas une adresse IPv6 brute à évaluer en elle-même : c'est de l'IPv4 déguisée en IPv6, qu'il faut déballer et vérifier par rapport aux règles IPv4 de la même façon qu'une adresse IPv4-mappée.

Tester la logique de sécurité, c'est réellement tester les deux familles

Il est facile que les tests automatisés penchent discrètement vers IPv4 : la plupart des domaines d'exemple, des jeux de données de test et des vérifications manuelles rapides l'utilisent par défaut sans que personne l'ait décidé délibérément. Une suite de tests pour tout ce qui résout et filtre des adresses n'est digne de confiance que dans la mesure de sa couverture IPv6 : les cas des plages privées, de bouclage et de lien local ci-dessus, d'une adresse IPv4-mappée et d'une adresse synthétisée de type NAT64 méritent chacun leurs propres assertions explicites, et pas seulement « ça marche probablement de la même façon ». Le code de sécurité qui traite les adresses est exactement le genre de logique où un chemin de code non testé et un chemin cassé sont indiscernables jusqu'à ce qu'un attaquant en trouve la différence avant vous.