Netfilter et le filtrage du protocole IPv6

1. Netfilter et le filtrage du protocole IPv6

Si la pénurie d'adresses IPv4 est la première motivation de la définition d'IPv6, ce protocole intègre aussi de nouvelles fonctionnalités comme la découverte d'adresses, la fragmentation à la source, la généralisation du multicast, etc. Cet article fait le point sur quelques-unes de ces nouveautés et explique les conséquences en termes de filtrage par Netfilter et iptables.

2. Petit rappel sur IPv6 et début de filtrage

2.1 Format des adresses IPv6

Le changement le plus visible est la largeur des adresses : 128 bits contre 32 bits pour IPv4. Pour une lecture plus facile, une adresse est notée avec 8 blocs de 16 bits (ex : 1:2:3:4:5:6:7:8). On peut utiliser :: pour remplacer une suite de zéros (une seule fois par adresse), exemple : fe80:0:0:0:0:0:0:1 est abrégée fe80::1.

Comme IPv4, le début de l'adresse indique son type. Les préfixes les plus courants sont :

- 2000::/3 : Adresse globale (routable sur Internet), remplace de nombreux réseaux dispersés dans l'espace d'adressage IPv4.

- fe80::/64 : Adresse valable uniquement sur le lien local, remplace le réseau 169.254.0.0/16 (autoconfiguration IPv4 [RFC 3927])

- ff02::/16 : Multicast local, remplace 224.0.0.0/24[RFC 3171].

- ::ffff:0:0/96 : Adresse IPv4 stockée dans une IPv6, exemple : 192.168.0.2 devient ::ffff:c0a8:0002. On peut noter l'adresse IPv4 dans sa forme originale pour une meilleure lisibilité ::ffff:192.168.0.2.

Le réseau ::1/128 qui ne désigne qu'une seule adresse désigne la boucle locale. Elle remplace le réseau 127.0.0.0/8.

2.2 Création des adresses locales

Chaque interface réseau a sa propre adresse de lien dans le réseau fe80::/64. L'adresse est générée à partir de son adresse MAC selon l'algorithme décrit dans la [RFC 2464] (format EUI-64). Exemple : pour l'adresse MAC 00:16:76:ab:79:ed, l'adresse IPv6 fe80::216:76ff:feab:79ed sera utilisée.

La génération d'une adresse fixe (à partir de l'adresse MAC) peut être perçue comme une atteinte à la vie privée. Sous Linux, il est possible d'utiliser une adresse temporaire (adresse aléatoire, [RFC 4941]) en écrivant 1 dans la clé sysctl net.ipv6.conf.default.use_tempaddr (adresse *temporaire*). C'est le choix par défaut sous Windows.

2.3 Filtrage IPv6 sous Linux

Le filtrage d'IPv6 sous Netfilter n'est arrivé que récemment à maturité. C'est, en effet, dans le noyau 2.6.15 (sorti le 03 janvier 2006) qu'est arrivé le suivi de connexion IPv6. Jusque-là, le filtrage IPv6 s'effectuait comme un filtre sans état.

Comme le laisse comprendre le paragraphe précédent, le filtrage IPv6 s'est construit après l'élaboration du filtrage IPv4. Une des conséquences est l'utilisation d'un programme dédié pour la gestion des règles Netfilter : ip6tables. Cet outil se comporte comme iptables dont il reprend quasi intégralement la syntaxe et l'organisation. Nous allons utiliser, dans cet article, ip6tables pour construire un jeu de règles strict. Pour commencer, fermons les portes :

En définissant la politique par défaut à DROP sur les trois chaînes, plus rien ne peut passer en IPv6. Nous allons maintenant ajouter quelques règles pour être un peu plus à l'aise. En premier lieu, avant d'autoriser explicitement l'ouverture de certains trafics nous allons accepter les flux établis et relatifs à une connexion en cours et autoriser le trafic local :

Comme énoncé plus haut, un noyau supérieur à 2.6.15 est nécessaire pour que les filtres sur le suivi d'état (--state) soient utilisables. Pour être tout à fait strict, il est nécessaire d'ajouter maintenant une règle de filtrage sur les paquets détectés comme INVALID par le suivi de connexions pour chaque chaîne :

3. Autoconfiguration sous IPv6

Le protocole DHCP est la solution qui s'est imposée sous IPv4 pour assurer l'attribution automatique d'adresses aux postes se connectant à un réseau. Consciente de l'intérêt de cette fonctionnalité, l'IETF a décidé de normaliser un protocole d'autoconfiguration assurant le même service pour IPv6.

3.1 Découverte du préfixe

Pour obtenir une adresse routable sur Internet, on envoie un message Router Solicitation (ICMPv6 type 133, [RFC 2461]) à destination de ff02::2 (routeurs) en utilisant notre adresse locale comme source (fe80::...). Chaque routeur va répondre avec un message Router Advertisement (type 134) en utilisant son adresse locale comme source et ff02::1 comme destination. Ce message contient un préfixe et le MTU.

Le préfixe le plus court est choisi parmi les réponses et on rajoute notre suffixe (généré à partir de l'adresse MAC ou un suffixe aléatoire). Exemple : à partir du préfixe 2a01:e35:8a04:25b0::/64 et de l'adresse MAC 00:16:76:ab:79:ed, l'adresse 2a01:e35:8a04:25b0:216:76ff:feab:79ed est générée. Dans notre cas, le suffixe (64 bits de poids faible) est identique à celui de l'adresse locale.

On peut désactiver l'autoconfiguration (envoi de Router Solicitation) en écrivant 0 dans la clé sysctl net.ipv6.conf.eth0.autoconf, et refuser les messages Router Advertisement en écrivant 0 dans net.ipv6.conf.eth0.accept_ra. Un routeur n'utilise pas l'autoconfiguration (n'envoie pas de Router Solicitation et refuse les Router Advertisement).

Les règles pour un poste client peuvent s'écrire :

Les règles pour un routeur :

Le filtrage des paquets invalides (-m state --state INVALID) ne peut pas être utilisé en IPv6, car les paquets ICMPv6 vers/depuis le multicast local sont détectés comme invalides. Ce problème a été rapporté et fixé par vos serviteurs et le correctif a été accepté et devrait être inclus à partir de Linux 2.6.29. Il est donc nécessaire pour tous les noyaux précédents 2.6.29 d'aménager la règle de filtrage des paquets INVALID exprimée précédemment :

3.2 Vérification de l'unicité d'une adresse

Pour éviter les doublons, on commence par envoyer un message Multicast Listener Report Message v2 (ICMPv6 type 143, [RFC 3810]) à l'adresse ff02::16 (groupe des routeurs MLDv2) avec comme la source ::. L'adresse :: est utilisée lorsqu'on n'a pas encore d'adresse, et ne peut être utilisé qu'en tant que source. Ensuite, on envoie un message Neighbor Solicitation (type 135, [RFC 2461]) avec l'adresse dont on veut tester l'unicité comme destination, et :: comme source.

En cas de doublon, le propriétaire actuel de l'adresse envoie un message Neighbor Advertisement (type 136) à destination de ff02::1 (ensemble des nœuds locaux). Si aucun message n'est reçu après un certain délai (1 seconde par défaut sous Linux), on considère qu'il n'y a pas de doublon. Le multicast local remplace le protocole ARP utilisé pour IPv4.

Règles pour un poste client :

Pour un routeur, remplacez la première règle par :

Le critère --icmpv6-type 136/0 filtre le type (136), mais aussi le code (0).

3.3 Découverte des voisins

On peut utiliser un ping (Echo Request, ICMPv6 type 128) vers le multicast local la découverte des voisins [RFC 2461]. La commande ping a besoin de l'option -I interface si on utilise une adresse multicast (la notation ipv6%interface est aussi acceptée) :

Quatre nœuds qui ont répondu (Echo Reply, ICMPv6 type 129) y compris nous-mêmes. Il y a donc 3 voisins :

Lorsqu'on découvre un voisin, il est d'abord dans l'état DELAY, c'est-à-dire non joignable et on attend quelques secondes avant de tester la connectivité. On lui envoie ensuite un test de connectivité (Neighbor Solicitation) et il passe dans l'état PROBE. Si l’on reçoit la réponse (Neighbor Advertisement), il passe dans l'état REACHABLE, sinon il est supprimé. Après un certain délai, les voisins dans l'état REACHABLE sont supprimés, sauf le routeur qui reste dans l'état STALE (non joignable, mais on ne teste pas la connectivité).

Règles pour autoriser le ping :

4. Internet et routage

4.1 Routage

Pour afficher la table de routage, on peut utiliser la commande ip -6 route show (ou route -6). Exemple abrégé :

La passerelle est enregistrée avec son adresse locale. Les routes ont une durée de vie.

Comme en IPv4, il existe aussi le messages Redirect (ICMPv6 type 137) pour indiquer une route plus courte, et le message Destination Unreachable (type 1) pour indiquer qu'un hôte n'est pas joignable. On peut refuser les redirections en écrivant 0 dans les clés sysctl net.ipv6.conf.*.accept_redirects.

4.2 Internet

Contrairement à IPv4 qui utilise divers préfixes dispersés dans la plage d'adresse IPv4, IPv6 utilise un seul préfixe 2000::/3 pour les adresses unicast globales. Ce préfixe est découpé en :

- 2000::/16 : Ancien bloc utilisé avant 2001 (ouverture du registre officiel)

- 2001::/16 : Adresses permanentes ouvertes à la réservation

- 2002::/16 : Tunnels 6to4, utilise 192.88.99.0/24 [RFC 3068] en IPv4. En particulier, l'adresse 2002:c058:6301:: est une adresse anycast correspondant à 192.88.99.1 en IPv4.

Pour que les clients puissent utiliser l'autoconfiguration, les fournisseurs d'accès à Internet doivent distribuer un préfixe de 64 bits ou moins (la taille minimale des préfixes est fixée par RFC 3769). En France, depuis mars 2008, Free distribue des préfixes /60, ce qui permet d'utiliser 16 réseaux privés /64 différents.

4.3 Diminution de la charge des routeurs

Contrairement à une idée reçue, IPv6 allège la charge des routeurs. L'en-tête IPv6 a une taille fixe (40 octets), les options étant écrites à la suite. Comme l'en-tête ne contient plus de somme de contrôle, un routeur qui décrémente le nombre de sauts (hop limit) n'a pas à la recalculer.

Le MTU de chemin est communiquée par le message Router Advertisement et est donc connu. Sa valeur minimale est de 1280 octets [RFC 2460]. La fragmentation des paquets est réalisée à la source en utilisant l'en-tête Fragment header (numéro 44), et n'est donc plus à la charge des routeurs.

En IPv4, les blocs d'adresses ont tendance à être disjoints (vue la rareté des blocs libres), ce qui a pour conséquence de créer de grandes tables de routage. En IPv6, comme un réseau « privé » peut contenir au minimum 2^64 machines (4 milliards de fois Internet IPv4), on peut se contenter d'un seul bloc. Il y a moins de préfixes et les tables de routage sont donc plus petites.

Enfin, la translation d'adresse et de port (NAT) disparaît également.

5. Utilisation courante du filtrage IPv6

5.1 Règles de filtrage standard

Pour pouvoir faire quelque chose avec notre machine bien protégée, il va falloir autoriser quelques flux. Autorisons par exemple sur un poste client les connexions SSH en entrée depuis les adresses globales :

Pour autoriser DNS, HTTP et HTTPS en sortie :

Si l'on paramètre un routeur, voici un exemple de règles complémentaires pour autoriser DNS, HTTP et HTTPS depuis le réseau 2a01:e35:8a04:25b0::/64 vers Internet :

5.2 Journalisation IPv6

5.2.1 Paramétrage de ulogd2

La journalisation des paquets IPv6 est possible avec la cible LOG qui envoie un message dans syslog pour chaque paquet journalisé. Si l'on souhaite effectuer une journalisation dans une sortie autre que syslog, la seule solution au moment de la rédaction de l'article est d'utiliser la cible NFLOG et ulogd2 pour effectuer la journalisation. La cible ULOG qui était utilisée pour la journalisation dans ulogd est uniquement compatible IPv4 et devient donc désuète.

Le démon de journalisation ulogd2 supporte nativement IPv6. Aucun paramétrage spécifique n'est nécessaire pour traiter les paquets IPv6. À titre d'exemple, nous allons journaliser les paquets droppés en fin de règles dans un fichier et dans PostgreSQL. Pour ce qui est des règles ip6tables, c'est très simple :

Après avoir compilé et installé ulogd2, comme décrit dans l'article [ulogd2]. Nous éditons le fichier de configuration ulogd.conf. Il faut définir deux stacks prenant en entrée une instance NFLOG avec l'une sortant vers LOGEMU et l'autre vers PGSQL. Il faut donc avoir parmi les lignes décommentées du fichier :

La journalisation dans l'émulation syslog ressemblera à ceci :

Hormis le remplacement des adresses IPv4 par des adresses IPv6, on retrouve essentiellement des informations déjà présentes dans IPv4. Les nouveaux champs sont les suivants :

- TC : La classe de trafic, équivalente au champ TOS de Ipv4.

- HOPLIMIT : Équivalent IPv6 du TTL d'IPv4.

- FLOWLABEL : Identifiant de flux [RFC3697], il permet la classification par les routeurs des paquets appartenant à un même flux. L'identifiant de flux peut être calculé à partir des coordonnées IP ou être fixé de manière plus spécifique.

5.2.2 Installation de nulog2

Nulog2 est une interface web d'analyse des journaux Netfilter. Elle est capable d'analyser des journaux IPv4 et IPv6. Nous allons décrire son installation afin de réaliser une analyse des informations collectées par ulogd2.

 

 

Les sources de Nulog sont disponibles à l'adresse http://software.inl.fr/trac/wiki/EdenWall/NuLog#Download. À noter qu'il vous faut au moins la version 2.1.4 de Nulog pour pouvoir s'interfacer avec une base ulogd2. Une fois récupérée, il suffit de les décompresser. Le fichier INSTALL contient les instructions d'installation et les dépendances. Les dépendances sont twisted, nevow, matplotlib, gettext, soappy, mysqldb, cairo, python-ipy, python-numpy, python-docutils et, dans notre cas, psycopg2. Une fois les dépendances résolues, nous pouvons passer l'initialisation de la base MySQL qui ne nous concerne pas. Pour installer Nulog, il suffit alors de lancer :

Pour pouvoir utiliser Nulog2 avec la base PostgreSQL remplie par ulogd2, il faut injecter une vue dans le schéma de la base. Cette vue émule une base Nulog classique et permet l'interopérabilité. Pour ajouter cette vue, il utiliser la définition nulog.sql fournit dans le répertoire scripts des sources de Nulog et il faut lancer :

Dans le répertoire /etc/nulog, il faut copier default.core.conf en core.conf pour pouvoir paramétrer le backend de Nulog. Hormis les paramètres de base, il faut spécifier le type de base ulogd2 et l'utilisation d'une base IPv6 :

Si vous n'avez pas installé Nulog à partir des paquets Debian, il faut copier default.wrapper.conf en tant que wrapper.conf et éditer les chemins vers les modules si nécessaire. La dernière étape consiste à lancer scripts/install_defconf.sh pour créer le répertoire des préférences utilisateurs et installer la configuration par défaut.

La réponse aux questions et le paramétrage des chemins dans le fichier wrapper.conf finalisent l'installation.

Il suffit maintenant de démarrer Nulog. Cela se fait tout simplement en lançant la commande nulog. L'interface web est alors accessible depuis l'adresse http://localhost:8080/.

 

 

5.3 NuFW en IPv6

La pare-feu authentifiant NuFW supporte IPv6 depuis la branche 2.2 (c'est aujourd'hui la branche stable). Pour l'installation de NuFW, je vous invite à vous référer à l'article paru dans [Linux Mag 84]. À des fins de concision, nous ne détaillerons ici que l'installation depuis les paquets Debian disponibles sur packages.inl.fr :

Pour activer IPv6 au niveau du serveur d'authentification nuauth, il suffit de spécifier dans le fichier de configuration nuauth.conf :

La première valeur fixe l'adresse d'écoute. Ici, on écoute en IPv6 uniquement, il faut rajouter 0.0.0.0 pour écouter aussi en IPv4. La deuxième et la troisième variables prennent en compte le fait que l'utilisateur doit pouvoir authentifier des paquets IPv6 et IPv4. nuauth_push_to_client passe nuauth dans un mode où il ne fait pas de requête de rafraîchissement aux clients connectés à l'IP source des paquets reçus. Dans ce mode, le client vérifie à intervalles réguliers si des paquets sont à authentifier. nuauth_user_check_ip_equality supprime, quant à lui, une vérification de cohérence entre l'adresse source du tunnel TLS et l'adresse source des paquets authentifiés. Cette deuxième variable est disponible depuis la version 2.2.21 de NuFW.

Les clients peuvent alors se connecter sur les adresses IPv6 globales du pare-feu :

Le client ainsi connecté authentifie alors l'ensemble des paquets IPv4 et IPv6 émis par l'utilisateur.

6. Conclusion

Le support du filtrage IPv6 est récent sous GNU/Linux et les outils de l'administrateur de pare-feu sont encore peu nombreux à supporter IPv6 notamment au niveau de la journalisation.

Le déploiement d'IPv6 se fait progressivement et le protocole continue d'évoluer pour corriger certains défauts et préparer l'avenir. Le développement d'IPv6 est encore très actif, notamment du côté d'anycast, la mobilité et le chiffrement (ESP et AH). Pour en savoir plus, consultez le livre [IPv6 Théorie et Pratique], une référence en français dont le site Internet est une mine d'informations.

Les mécanismes mis en œuvre par ce protocole (comme l'autoconfiguration ou Mobile IPv6) peuvent se montrer difficiles à filtrer et IPv6 promet donc de nombreux années de bonheur pour les développeurs de pare-feu. Les administrateurs de pare-feu s'amuseront eux avec la fin de la translation d'adresse.

Références

[IPv6 Théorie et Pratique] CIZAULT (Gisèle), O'Reilly, http://livre.point6.net/

[IPv6 Routing Header Security] BIONDI (Philippe) et EBALARD (Arnaud), CanSecWest 2007, http://www.natisbad.org/RH0/

Nulog : http://software.inl.fr/trac/wiki/EdenWall/NuLog

Paquets Debian INL : http://software.inl.fr/trac/wiki/packages

[RFC 791] Internet protocol, 1981.

[RFC 2460]Internet Protocol, Version 6 (IPv6) Specification, 1998.

[RFC 2461]Neighbor Discovery for IP Version 6 (IPv6), 1998.

[RFC 2464]Transmission of IPv6 Packets over Ethernet Networks, 1998.

[RFC 3068]An Anycast Prefix for 6to4 Relay Routers, 2001.

[RFC 3171]IANA Guidelines for IPv4 Multicast Address Assignments, 2001.

[RFC 3697]IPv6 Flow Label Specification, 2004.

[RFC 3810]Multicast Listener Discovery Version 2 MLDv2) for IPv6, 2004.

[RFC 3879]Deprecating Site Local Addresses, 2004.

[RFC 3927]Dynamic Configuration of IPv4 Link-Local Addresses, 2005.

[RFC 4941]Privacy Extensions for Stateless Address Autoconfiguration in IPv6, 2007.

[RFC 5095]Deprecation of Type 0 Routing Headers in IPv6, 2007.

[ulogd2] LEBLOND (Éric) et CHIFFLIER (Pierre), « Ulogd2, journalisation avancée avec Netfilter », GNU/Linux Magazine HS 41, page 26.

[Linux Mag 84] LEBLOND (Éric), (Présentation de NUFW), GNU/Linux Magazine 84, 2006.