IPv6 et la sécurité : nouvelles du front – mars

Articles publiés

Dans un article intitulé « Don’t Panic About, or Ignore, IPv6 Security », Carl Weinschenk se base sur des extraits de plusieurs articles pour faire ressortir les risques de sécurité que pourrait apporter IPv6. En voici les grandes lignes :

  • Manque de maturité de l’infrastructure (de nombreux opérateurs ne sont pas capables de surveiller le trafic IPv6 suffisamment pour détecter des attaques par déni de service)
  • Les mécanismes de tunnel IPv4/IPv6 risquent de permettre à une partie du trafic de circuler sans surveillance
  • S’il n’y a pas suffisamment de mémoire allouée pour traiter les adresses IPv6, plus grandes que les adresses IPv4, il existe un risque d’exécution de code

Quelques points positifs sont aussi abordés :

  • Les principaux systèmes d’exploitation ont une pile IPv6 qui a été grandement testée et la plupart des équipements sont basés sur ces systèmes d’exploitation – « Things may go wrong, of course, but we’ll survive. »

Il conclut en disant qu’il faut être extrêmement prudent lors de la planification, du déploiement et de l’utilisation d’IPv6.
Fernando Gont a publié un article intitulé « IPv6 NIDS evasion and improvements in IPv6 fragmentation/reassembly » suite à des tests qu’il a effectué concernant la fragmentation. Les conclusions sont les suivantes :

  • La majorité des systèmes d’exploitation « populaires » (Windows, Linux, *BSD) implémentent la RFC 5722 et n’acceptent pas les overlaping fragments
  • La majorité de ces systèmes n’implémentent pas le draft draft-ietf-6man-ipv6-atomic-fragments-00 et traitent les atomic fragment comme des fragments classiques

Comparé à IPv4, il paraît beaucoup plus difficile d’utiliser la fragmentation comme méthode d’évasion des pare-feux et NIDS.
Une interview de Robert Hinden a été réalisée : « RSA 2012 talk to offer help understanding IPv6 security issues ». Il donne son avis sur IPv6 et la sécurité en général. Voici quelques extraits :

  • Un des gros problèmes aujourd’hui est le manque de compétences dans le domaine d’IPv6 (les protocoles sont là, les produits aussi, mais les équipes ont besoin de se former sur le sujet)
  • Un des deux problèmes les plus préoccupants avec IPv6 concerne les mécanismes de transition IPv4/IPv6 qui peuvent permettre de créer des tunnels non surveillés vers l’extérieur de l’entreprise
  • Le second problème est le manque de surveillance du trafic IPv6 (des malwares pourraient utiliser ce protocole pour se propager sans être détectés)

Scott Hogg a publié un article intitulé « Should You Allow Inbound E-mail Over IPv6? ». Il y aborde de manière plutôt complète les problèmes qui apparaîtront sûrement avec l’activation de l’IPv6 sur les serveurs SMTP : comment créer des blacklists d’IP contenant les IP de spammeurs sachant que IPv6 permet d’utiliser de très nombreuses adresses, les solutions de gestion des mails (SpamAssassin, Barracuda, etc.) ne possèdent pas toutes des fonctionnalités IPv6, etc.
Alexandre M. S. P. Moraes a publié une série d’articles traitant de la configuration d’IPv6 (ACL, zone-base policy firewall, etc.) sur des équipements Cisco.
Sur le blog de Tenable Network Security, Ron Gula a publié un article où il aborde quatre idées reçues sur la sécurité d’IPv6 : « Decoding IPv6: Four Misconceptions that Security Execs Need to Know ». Les voici :

  • IPv6 est plus sûr
  • L’absence de NAT induit un risque supplémentaire
  • IPv6 est trop gros pour être scanné, empêchant des hackers de compromettre un réseau IPv6
  • Les FAI vont s’occuper de la transition vers IPv6

Outils

La version 4.2 de Metasploit est sortie. Parmi les nouveautés, on trouve de grosses améliorations du côté du support d’IPv6 :

  • De nouvelles payloads ont été ajoutées et celles existantes ont été mises à jour ; désormais, la majorité des payloads sont compatibles avec IPv6
  • Metasploit peut maintenant communiquer avec une base de données en utilisant IPv6
  • Diverses autres améliorations liées au support d’IPv6 ont aussi été effectuées

Vulnérabilités

Certaines versions des équipements Cisco Wireless LAN Controller sont affectées par une vulnérabilité (CVE-2012-0369) permettant de causer un déni de service en envoyant une série de paquets IPv6 spécialement formés.