La sécurité dans la transition IPv4/IPv6 dans un réseau double pile. Gaël Beauquin CNRS/UREC

Transcription

1 La sécurité dans la transition IPv4/IPv6 dans un réseau double pile 1

2 La sécurité sur IPv6 Les fondements d'ipv6, basés sur la disette d'adresses publiques (1998) IPSec et IPv6 Privacy Extension (2001) Cryptographically Generated Addresses et SEcure Neighbor Discovery (2005) 2

3 Les vieilles vulnérabilités Sniffing toujours possible Protocoles de routage quasiment inchangés Scans toujours possible (nmap supporte IPv6 depuis 2002) Worms et Virus TCP/UDP restent les mêmes, avec les conséquences que cela entraine (attaques RST, SYN flood, etc) Attaques Man-in-the-middle Fragmentation toujours disponible (attaques, évasion d'ids) Flooding 3

4 IPSec Fournit une architecture de sécurité pour protéger les communications entre deux points au niveau de la couche réseau. Fournit une panoplie de services : Authentifier les points qui communiquent Crypter le trafic Garantir l'intégrité des données Protéger la communication contre des attaques Replay Pas forcément évident à mettre en place, concurrence de TLS/SSL 4

5 Un nouvel espace d'adressage Un espace inscannable? Il reste possible de retrouver des adresses de machine Utilisation de DNS qui pointe sur des machines Utilisation d'adresses «simples» Impact éventuel sur les worms Plusieurs adresses pour une seule machine Link-local, site-local, global De nouvelles adresses de multicast pour atteindre certaines machines 5

6 Le multicast En remplacement des broadcast, liste intégrale disponible sur Aucune réponse ICMPv6 ne doit être faite aux paquets destinés à des adresses multicast Multicast en link-local All nodes FF02::1 All routers FF02::2 All DHCP-agents FF02::1:2 Multicast en site-local All routers FF05::2 All DHCP servers FF05::1:3 6

7 Privacy Extension Comme avec un DHCP, permet d'avoir une adresse dynamique lors d'une configuration sans état. Défini par la RFC Rend les postes clients plus difficiles à tracer La méthode n'est pas dénuée d'inconvénients Si on utilise un système de DNS dynamique, on ne fait que déplacer le problème Les adresses dynamiques rendent les problèmes plus difficiles à localiser pour les administrateurs 7

8 Neighbour Discovery Le protocole Neighbour Discovery est utilisé notamment pour déterminer une adresse IPv6 et pour découvrir les routeurs. Il est expliqué dans la RFC Le protocole en lui même n'est pas sécurisé. Il est possible d'y ajouter IPSec, mais c'est relativement complexe. N'importe qui peut envoyer des paquets pour essayer de se faire passer pour un routeur. 8

9 Cryptographically Generated Addresses Mise au point d'une solution pour sécuriser IPv6, définie en 2005 par la RFC 3972 Définit un procédé pour associer une adresse IPv6 à une clé cryptographique publique Générer une adresse IPv6 lié au hash de la clé publique Vérifier l'association entre la CGA et la clé publique Signer les messages envoyé depuis la CGA, et vérifier la signature 9

10 Secure Neighbour Discovery SEND a été défini pour pallier aux failles de ND. Le protocole est défini dans la RFC Utilise les CGA pour authentifier les émetteurs Rajoute des options pour augmenter la sécurité, tel qu'un champ Timestamp pour contrer les attaques de type Replay Une implémentation du protocole existe, le DoCoMo Open Source SEND Project. Le code est fonctionnel et testé sur systèmes Linux (noyau 2.6) et FreeBSD (5.4) 10

11 Pare-feux et filtrage La plupart des équipements réseaux et pare-feux logiciels gèrent l'ipv6 maintenant (Cisco, Juniper, ip6tables, pf, pare-feu Windows XP/Vista) A priori, pas de changements notoires dans la politique de sécurité les flux restent identiques Ce qui est filtré en Ipv4 sera filtré en IPv6, il faudra juste tenir compte des nouveautés Nécessite une traduction rigoureuse des ACL existantes 11

12 Les filtres de base Ne pas oublier l' «ingress filtering». Rejeter les paquets dont l'adresse source n'est pas Unicast ou est non-attribuée. Il est plus simple d'accepter les adresses IP Unicast valides que de rejeter les adresses IP invalides Exception de 2001:db8::/32 (préfix réservé à des fins documentatives) 12

13 Les ICMP La problématique du choix du filtrage. Certains ICMPs existants ont été renommés Le protocole ICMPv6 est un vaste sujet à traiter (RFC 4890) A ne pas bloquer : ICMPv6 type 2 (fragmentation) 13

14 Les tunnels Dans un cadre double pile, les tunnels sont dangereux Changent les flux Ignore le pare-feu Possibilité d'abuser Teredo si mal configuré avec l'option source-routing : On peut mettre en place des ACLS pour éviter les tunnels Bloquer tout paquet IP avec la valeur 41 dans le champ protocole Bloquer le port 3544 en UDP pour Teredo 14

15 Quelques outils NDPMon : Permet de surveiller les trames du protocole Neighbour Discovery Ntop : donne des informations sur le trafic réseau TCPDump / Ethereal : sniffing de trames Netcat6 : version IPv6 de netcat IP6Sic : version IPv6 de ISIC, qui test une pile réseau en envoyant une multitudes de paquets. Nessus : Supporte l'ipv6 à partir de la version 3.2 Nmap : Supporte IPv6 depuis longtemps 15

16 Le futur? La sécurité en IPv6 ne fait que commencer, et ne doit pas être prise à la légère. Plus IPv6 sera déployé, plus la motivation pour l'attaquer et chercher de nouvelles failles sera grande Les vers peuvent s'y faire un nid : Des fonctionnalités telles que la mobilité ou le multicast ont encore leur «baptême du feu» à passer. 16