Déployer des services en IPv6

Déployer des services en IPv6 Best Practice Document Document rédigé par le groupe de travail «IPv6 pour les services» animé par le GIP RENATER (BPD R3.2) Auteurs: Jean Benoit - jean@unistra.fr (Université de Strasbourg/GIP RENATER) Simon MUYAL simon.muyal@renater.fr (GIP RENATER) Christophe Palanché christophe.palanche@unistra.fr (Université de Strasbourg/GIP RENATER) Philippe Wender philippe.wender@insa-rouen.fr (INSA Rouen/GIP RENATER) V1-27/11/13

GIP RENATER 2013 TERENA 2013. All rights reserved. Document No: GN3plus-NA3-T2-R3.2 Version / date: V1-27/11/13 Original language : French Original title: Déployer des services en IPv6 Original version / date: V1-27/11/13 Contact: cbp@listes.renater.fr RENATER bears responsibility for the content of this document. The work has been carried out by a RENATER led working group on IPv6 as part of a joint-venture project within the HE sector in France. Parts of the report may be freely copied, unaltered, provided that the original source is acknowledged and copyright preserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n 605243, relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'. 2

Table of Contents Introduction 5 1 Recommandations générales 6 1.1 Étape 1 : organisation du déploiement 6 1.1.1 Approches 6 1.1.2 Ordre de déploiement 7 1.1.3 Les applications web en priorité 7 1.1.4 Applications (web ou non-web) manipulant des adresses IP 7 1.2 Étape 2 : formation des administrateurs systèmes à IPv6 8 1.3 Étape 3 : activer IPv6 sur le réseau des serveurs 8 1.3.1 Plan d adressage du réseau des serveurs 8 1.4 Étape 4 : superviser l adresse IPv6 9 1.5 Étape 5 : tests et validation 9 1.6 Étape 6 : activation 9 1.7 Étape 7 : publication du service dans le DNS 10 2 Implémentation de la double-pile IPv4/IPv6 11 3 Mail 13 3.1 Configuration des principaux MTA en IPv6 13 3.1.1 Sendmail 13 3.1.2 Postfix 13 3.2 Impact de l activation d IPv6 14 4 Web 15 4.1 Architecture 15 4.1.1 Architecture sans redondance 15 4.1.2 Proxy et load-balancer 15 4.2 Exemples 16 4.2.1 Architecture sans redondance 16 4.2.2 Proxy et translation IPv6/IPv4 17 4.2.3 Redondance 19 5 Sécurité 20 5.1 Filtrage 20 5.1.1 Politique par défaut 20 5.1.2 Règles nécessaires au fonctionnement d IPv6 20 5.2 ICMPv6 21 3

5.3 Le multicast 22 5.4 Les extensions 22 5.5 Filtrage du service 22 Références 24 Glossaire 25 4

Introduction Il existe déjà de nombreux documents de bonnes pratiques concernant le déploiement d'ipv6 aussi bien sur les postes clients que sur une infrastructure réseau. Mais le déploiement d'ipv6 sur les serveurs et les services a rarement été abordé. Le présent document vise à combler ce manque. Le périmètre des bonnes pratiques présentées ici inclus les services réseaux (web, mail, dns) et les serveurs sur lesquels ces services fonctionnent. Il s adresse aux administrateurs systèmes et réseaux. Des sujets comme la stratégie de configuration des postes de travail (avec SLAAC, DHCPv6...) ou la configuration des interconnexions entre routeurs en IPv6 ne seront donc pas abordés. La connectivité IPv6 doit déjà être disponible sur le cœur de réseau. Plus précisément, ces recommandations portent sur le déploiement de services en IPv6 sur des serveurs Unix pour un service existant déjà en IPv4. L'approche d'une double pile de protocole (IPv4 - IPv6) sur le serveur sera privilégiée. Tout d'abord, des préconisations générales seront données concernant le déploiement de services en IPv6 : préparation, formation, organisation, tests, mise en œuvre. Puis différents cas seront étudiés en détail : messagerie, web et partage de charge. Enfin, des préconisations en matière de sécurités seront faites. 5

1 Recommandations générales La démarche de mise en œuvre de services en IPv6 se déroule en plusieurs étapes : définition des services à déployer en IPv6, en analysant les impacts, formation des administrateurs systèmes, mise en place la connectivité IPv6 sur le réseau des serveurs, supervision du service en IPv6 avant de le déployer, tests de bon fonctionnement du service, activation d IPv6, publication de l adresse du service dans le DNS. 1.1 Étape 1 : organisation du déploiement Cette étape permet de préparer le déploiement en définissant précisément le périmètre. Elle exige de répondre aux questions suivantes : - quel service sera déployé en IPv6? - sur quels serveurs tourne-t-il? - quels sont les autres services dont il dépend? (exemple de dépendance : un service web dépend d'une base de données ou d'un annuaire pour fonctionner) - quels sont les autres services qui dépendent de ce service? (exemple : un web service utilisé par d'autres applications). 1.1.1 Approches Le déploiement d'ipv6 se fait pour un service qui existe déjà en IPv4. Il y a trois approches possibles : I. Le service en IPv6 va fonctionner sur un serveur dédié, 6

II. III. Un serveur mandataire applicatif (proxy) joue le rôle de traducteur : le client va s'y connecter en IPv6 et le mandataire relaiera le trafic en IPv4 vers le service qui reste inchangé, Le service va fonctionner sur le même serveur doté d'une double pile réseau, IPv4 et IPv6. L'approche I n'est pas recommandée car elle complique la gestion du service : en doublant les serveurs, la maintenance s accroit. L'approche II est possible si le service ne peut pas fonctionner en IPv6 nativement : elle permet un accès en IPv6 au service sans le modifier mais elle reporte en partie la complexité sur le mandataire (la gestion des sessions). L'approche III est l'approche la plus courante dans le contexte d'un réseau de campus. C est l approche principalement étudiée dans ce document. 1.1.2 Ordre de déploiement Lorsqu on active IPv6 sur un serveur, cela impacte l ensemble des services hébergés sur ce serveur. Il est préférable d'organiser le déploiement de manière progressive, serveur par serveur, en tenant compte des dépendances. Les serveurs ayant le moins de dépendances et de services sont à privilégier dans un premier temps. Les dépendances ne sont pas bloquantes : l activation d IPv6 sur un serveur pour l accès aux services qu il héberge n empêche pas l utilisation d IPv4 vers ses dépendances. Par exemple, si un serveur de base de données ne fonctionne pas en IPv6, un serveur web déployé en IPv6 peut se connecter à la base en IPv4. 1.1.3 Les applications web en priorité Il est vivement recommandé de commencer par les services web : la plupart des applications s'appuient sur des serveurs web qui supportent IPv6 (Apache [1], Lighttpd [2], Nginx [3], etc.), la plupart des applications web ne manipulent pas d adresses IP : la gestion d IPv6 reste le plus souvent à la charge du serveur web frontal. 1.1.4 Applications (web ou non-web) manipulant des adresses IP Pour une application utilisant des adresses IP, il faut veiller à sa compatibilité avec IPv6. Il existe des suites de tests pour valider son bon fonctionnement, comme IPv6CARE [4] par exemple. De plus, de nombreux langages et leur environnement (comme C, PHP, java, perl, ruby, python etc.) offrent un bon niveau de support d IPv6. 7

1.2 Étape 2 : formation des administrateurs systèmes à IPv6 Cette première étape est indispensable pour que les personnes chargées d administrer les serveurs et les services puissent opérer des services en IPv6. Il est recommandé de commencer plusieurs mois avant de déployer IPv6. La formation doit être essentiellement pratique. Le plan de formation doit inclure au moins les points suivants : l adressage et le routage (portée des adresses locale et globale etc.), avec notamment un exemple de plan d adressage pour des réseaux de serveurs, les différences entre IPv4 et IPv6, la description des protocoles liés à IPv6 (NDP, ICMP6 etc.), la sécurité, la configuration de serveurs sur un réseau de test (en consacrant suffisamment de temps aux travaux pratiques), la stratégie de déploiement (les différentes étapes). 1.3 Étape 3 : activer IPv6 sur le réseau des serveurs On suppose qu IPv6 est déjà actif sur le cœur de réseau et qu une connectivité externe est établie. IPv6 n est pas livré sur un vlan séparé. La connectivité IPv6 sur le réseau de production des serveurs doit être mise en place. Attention! L activation d IPv6 sur le réseau des serveurs doit être contrôlée : il ne faut pas activer les router-advertisement sur le réseau des serveurs : il ne doit pas y avoir d annonce de préfixe ni pas d annonce de routeur, il est recommandé de désactiver l auto-configuration d adresses IPv6 sur les serveurs, la passerelle par défaut est également configurée en statique, il est recommandé de vérifier que la politique de filtrage IPv6 en périphérie du réseau est cohérente avec celle d IPv4. Par exemple, si l accès SSH est bloqué pour tous les serveurs en IPv4, il doit aussi être bloqué en IPv6. Rappel : tous les serveurs sur lesquels on veut activer IPv6 auront une double-pile IPv4 et IPv6. 1.3.1 Plan d adressage du réseau des serveurs Pour établir le plan d adressage des serveurs, il faut respecter les points suivants : les serveurs ont uniquement des adresses IPv6 statiques, 8

la méthode de numérotation doit rester simple. Par exemple, mettre comme dernier octet de l adresse IPv6 le même que celui de l adresse IPv4 : si le serveur a pour adresse IPv4, 192.0.2.54 dans le réseau 192.0.2.0/24, alors adresse IPv6 sera : 2001:db8::54 dans le réseau 2001:db8::/64. Dans le cas où le dernier octet n est pas assez spécifique (par exemple pour un préfixe en /23 ou plus petit), les deux ou trois derniers octets de l adresses IPv4 peuvent être reportée dans l adresse IPv6. Par exemple, 192.0.2.1/23 devient 2001 :db8 ::2 :1/64. 1.4 Étape 4 : superviser l adresse IPv6 Il est nécessaire d avoir de la visibilité sur le fonctionnement du service en IPv6 avant la déclaration dans les DNS. Il faut tester à la fois la connectivité IPv6 et superviser le service en IPv6. Il est pertinent de regrouper tous les tests concernant les services IPv6 dans un tableau de bord dédié à la supervision IPv6. Par exemple, dans Nagios [5], il est recommandé d ajouter un host supplémentaire pour IPv6 (monserveurweb-v6) pour rendre explicite l état du serveur. Attention : il faut s assurer que le test est compatible avec IPv6 (par exemple, les plugins Nagios ne supportent pas tous IPv6). Si le test supporte IPv4 et IPv6, il faut bien vérifier que le statut de bon fonctionnement remonté par le test donne explicitement l état du service en IPv6. Par exemple, pour certains plugins, il est possible de forcer le test en IPv6 : check_http -H www.example.com -6 1.5 Étape 5 : tests et validation Il faut valider autant que possible sur une plate-forme de pré-production l activation d IPv6 : cette plate-forme doit être une copie de la plate-forme cible dans les conditions les plus proches possible du réseau de production. Si la plate-forme est composée de plusieurs serveurs (loadbalancer frontal, serveurs de backends et serveurs de base de données), il faut tester l ensemble de la chaîne. 1.6 Étape 6 : activation Activer l adresse IPv6 statique sur le serveur de production. Vérifier dans la supervision que le service est opérationnel en IPv6. 9

1.7 Étape 7 : publication du service dans le DNS Attention : il ne faut pas déclarer l'adresse IPv6 d'un serveur avant d'être certain que les services fonctionnent en IPV6. La supervision indiquant que le service fonctionne, on peut à présent déclarer l adresse IPv6 du serveur (enregistrement de type AAAA) et son enregistrement inverse (type PTR) dans le DNS. Il faut à présent tester le fonctionnement du service via le nom. Le test le plus exact se fait avec un outil comme telnet ou netcat [6] en précisant l option -6. Exemple : nc -v -6 monserveur.exemple.com 80 Une fois que l adresse est publiée dans le DNS, il est possible de modifier la déclaration du serveur dans la supervision pour faire un test IPv4 et IPv6, si le plugin le permet. 10

2 Implémentation de la double-pile IPv4/IPv6 En prenant comme exemple le service web, 2 méthodes sont possibles : le serveur web écoute à la fois sur une socket IPv4 et sur une socket IPv6, le serveur web n écoute que sur une socket IPv6 et les adresses IPv6 de type IPv4-mapped (::FFFF:ADDR_IPv4) sont utilisées. 1 er cas: Sockets IPv4 et IPv6: Le serveur web va écouter aussi bien sur une socket IPv4 qu IPv6 sur les ports configurés (par défaut, port 80 et port 443). 2 ème cas: Socket IPv6: l autre architecture possible est qu une seule socket TCP soit ouverte avec l utilisation des adresses IPv6 de type IPv4-mapped. Le service web écoute les requêtes V4 et v6 seulement via la socket IPv6 (cf RFC 3493, «Basic Socket Interface Extensions for IPv6»). Par exemple, [::ffff:192.0.2.128] pour l addresse IPV4 [192.0.2.128]. 11

Source : Rino Nucara, GARR, EuChinaGRID IPv6 Tutorial [7] Dans la plupart des distributions Linux, le 2eme cas est utilisé. On a un socket unique qui fonctionne à la fois en IPv4 et en IPv6. Cela ne fonctionne uniquement si on ne précise pas d adresse associée à la socket. Ce socket est représenté comme un socket IPv6 dans le résultat de la commande netstat : tcp6 0 0 :::80 :::* LISTEN 24035/nginx 12

3 Mail 3.1 Configuration des principaux MTA en IPv6 3.1.1 Sendmail Dans le système de configuration mc, définir la famille d adresse à l aide de la directive DAEMON_OPTIONS (elle correspond à l option DaemonPortOptions dans sendmail.cf [8]) : DAEMON_OPTIONS(`Family=inet6, Name=MTA, Modifier=O')dnl Le modificateur O permet de fonctionner même si IPv6 s il n est pas actif. Attention : sous Linux, par défaut, un seul socket est créé à la fois pour IPv4 et IPv6. Cette option est suffisante et ne peut pas cohabiter avec l option Family=inet pour IPv4. Sous *BSD, il faut mettre les deux options. Il faut vérifier avec la commande suivante que sendmail est bien à l écoute en IPv6 : lsof -i 6TCP:25 -n Il faut ensuite tester la connexion sur le port SMTP avec la commande suivante : openssl s_client -starttls smtp -connect @IPv6_server:587 3.1.2 Postfix 13

IPv6 est activé par défaut dans Postfix, à partir de la version 2.9. Pour les versions antérieures, il faut préciser : inet_protocols = all dans le fichier main.conf [9]. 3.2 Impact de l activation d IPv6 Les mécanismes de relayage de messagerie sont les même en IPv4 et en IPv6. Il n y donc pas d architecture spécifique à mettre en œuvre. Par contre, l activation d IPv6 a un impact sur l acheminement des messages vers d autres sites. En effet, de nombreux serveurs de messagerie (MTA) sont actuellement mal configurés : ils n ont pas de connectivité IPv6 vers l extérieur, ils n ont qu une adresse IPv6 de portée locale, ils font malgré tout une résolution DNS en demande l adresse IPv6 du serveur de messagerie du destinataire. La conséquence est que le serveur externe ne peut pas nous transmettre des mails. Il faut prévenir les administrateurs de messagerie des sites concernés, en indiquant d activer IPv6 sur son site ou de désactiver IPv6 sur le serveur ou sur le service de messagerie. Le problème est souvent lié à la configuration par défaut de la variable inet_protocols du MTA Postfix. La configuration par défaut contient : inet_protocols = all Il faut indiquer à l administrateur de forcer cette valeur à ipv4 s il n est pas en mesure de faire fonctionner IPv6 dans l immédiat. 14

4 Web 4.1 Architecture 4.1.1 Architecture sans redondance Dans une architecture classique de serveur web, quelques modifications au niveau de la configuration sont suffisantes généralement pour v6fier le serveur. 4.1.2 Proxy et load-balancer Afin de rendre l architecture de serveurs web plus robuste, des proxies et des mécanismes de partage de charge sont souvent utilisés. Dans la plupart des cas, il est suffisant que ces mécanismes supportent IPv6 pour proposer un service web accessible en IPv6. La partie backend n est pas forcément v6fiée. Il existe plusieurs façons de rendre ce service de partage de charge : au niveau réseau : Des mécanismes type VRRP ou CARP peuvent permettre d aiguiller des paquets vers un ensemble de serveurs web. Ces mécanismes ne tiennent pas compte de l état du service web. Si l interface réseau est active, le mécanisme continuera à envoyer des paquets vers le serveur en question. Il faut mettre en place une sonde qui vérifie l état du service. au niveau DNS : Des mécanismes de round robin DNS peuvent être utilisés. Cependant, ces mécanismes ne tiennent pas compte de l état du service web. au niveau applicatif: Les mécanismes de partage de charge applicatifs ont l avantage de tenir compte de l état du service web. 15

4.2 Exemples 4.2.1 Architecture sans redondance 4.2.1.1 Apache Configuration apache pour host: Si la pile IPv6 est déjà configurée sur le serveur, le serveur apache peut par défaut répondre aux requêtes IPv6. Il écoute sur toutes les adresses IP du serveur. La configuration se trouve dans le fichier ports.conf pour une distribution Linux Debian: Listen 80 <IfModule mod_ssl.c> Listen 443 </IfModule> Si l on souhaite écouter sur des adresses IPv4 et IPv6 spécifiques, la syntaxe est la suivante : Listen 192.168.0.1:80 Listen [2001:db8::1]:80 Pour vérifier que le serveur écoute sur les ports 80 en IPv4 et IPv6, les commandes suivantes sous Linux permettent de vérifier la liste des ports ouverts en IPv4 et IPv6 sur le port TCP 80 : netstat -ant lsof -ni tcp:80 Configuration apache pour SSL : Pour que le serveur apache écoute sur le port par défaut web SSL (443), le fichier ports.conf doit contenir les lignes suivantes : <IfModule mod_ssl.c> Listen 443 </IfModule> Ensuite, il est nécessaire d associer les différents virtual hosts dans la configuration. <VirtualHost *:80> ServerName nom_dns_du_service_web DocumentRoot /chemin_du_repertoire/ </VirtualHost> Un deuxième exemple avec un virtual host qui écoute sur les adresses IPv4 et IPv6 192.168.0.1 et 2001:db8::1 : 16

<VirtualHost 192.168.0.1:80 [2001:db8::1]:80> ServerName nom_dns_du_service_web DocumentRoot /chemin_du_repertoire/ </VirtualHost> 4.2.1.2 Nginx Il suffit d ajouter la directive suivante dans la configuration de nginx dans la section server. (NB: sous les système qui ne créent qu un seul socket pour IPv4 et IPv6, comme Linux, la configuration suivante fonctionnera également pour IPv4) : server { listen [::]:80 } server { listen [::]:443 } 4.2.2 Proxy et translation IPv6/IPv4 4.2.2.1 Apache Le module Apache mod_proxy [10] permet de mettre en place un reverse-proxy. Ce reverse-proxy est à l écoute sur une adresse IPv6 et renvoyant les requêtes sur le site interne en IPv4 uniquement. Par exemple, le site internal.appliv4.example.com ne supporte pas IPv6. Le nom www.example.com est déclaré dans le DNS associé à l adresse IPv6 2001:db8::1 La configuration d Apache est la suivante : <VirtualHost [2001:db8::1]:80> ServerName www.example.com ProxyRequests Off ProxyPass / http://internal.appliv4.example.com/ ProxyPassReverse / http://internal.appliv4.example.com/ ProxyPreserveHost On </VirtualHost> 17

4.2.2.2 Nginx Nginx permet de mettre en place un reverse-proxy (http/https) à l écoute sur une adresse IPv6 et renvoyant les requêtes sur les serveurs en IPv6 ou IPv4. Pour activer ce service il faut : Définir la liste des serveurs internes grâce à la directive upstream : upstream my_service { server internal.appliv4.example.com } Activer la redirection vers les serveurs interne avec la directive proxy_pass : server { listen [::]:80 ; server_name www.example.com; location / { proxy_pass http://my_service; } } 4.2.2.3 Translation avec OpenBSD Sur OpenBSD [11] PF [12] permet de faire une translation de famille d adresse, et notamment d IPv6 à IPv4 : L adresse IPv4 du serveur est incorporée à la fin de l adresse IPv6 : 2001:db8:3:4::c0a8:0101 pour 192.168.1.1, l adresse IPv6 du serveur doit être déclarée sur une interface externe, dans la règle de translation, Il faut préciser l adresse IPv4 source vers laquelle l adresse IPv6 sera réécrite (adresse déclarée sur l interface interne du firewall). 18

Exemple de règle à ajouter dans /etc/pf.conf : pass in on bnx0 inet6 af-to inet from 192.168.1.1 4.2.3 Redondance Sur Linux, l outil Keepalived implémente le protocole VRRP pour IPv6 et s appuie sur IPVS [13] qui supporte également IPv6. Sur OpenBSD, CARP, PF, PFSYNC, et Relayd sont compatibles IPv6. On peut nativement bâtir une architecture de load-balancer redondante. 19

5 Sécurité En principe, la même politique de sécurité doit s appliquer aux serveurs en IPv4 et en IPv6. Il faut disposer d un mécanisme de filtrage des paquets en IPv6 avant d activer IPv6 sur les serveurs. Le principe qui consiste à autoriser une adresse IP source en IPv4 ne fonctionne plus en IPv6. Il faut autoriser des réseaux entiers et s appuyer sur la sécurité applicative (authentification, autorisation). 5.1 Filtrage La politique de filtrage appliquée sur le serveur (et non sur un dispositif de filtrage externe) s'articule en 3 parties : une politique par défaut qui interdit tout, des règles qui permettent le fonctionnement d'ipv6, des règles spécifiques au fonctionnement du service. 5.1.1 Politique par défaut Tout est interdit par défaut Exemple pour Netfilter/Linux [14]: ip6tables -P INPUT DROP Exemple avec PF/*BSD : block inet6 all 5.1.2 Règles nécessaires au fonctionnement d IPv6 Pour garantir le fonctionnement d IPv6, lors de la mise en place d une politique de filtrage, il faut porter une attention particulière aux points suivants : 20

ICMPv6, le multicast, certaines extensions. 5.2 ICMPv6 ICMPv6 est indispensable au bon fonctionnement d IPv6. Il ne doit jamais être bloqué totalement sinon la connectivité ne fonctionnera pas. Par exemple, le protocole de Neighbor Discovery s appuie sur ICMPv6. De même le message ICMP Packet Too Big est indispensable au fonctionnement de l algorithme de découverte de la MTU (Path MTU discovery). Il convient donc d autoriser un sousensemble minimum d ICMPv6 documenté dans la RFC 4890 [15]. Les paquets ICMPv6 de type router advertisement sont volontairement bloqués dans le contexte d un réseau de serveurs ou il est recommandé de désactiver les RA sur les routeurs. Exemple avec Netfilter/Linux: ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type address-unreachable -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type port-unreachable -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-advertisement -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbor-solicitation -j ACCEPT # MLD Query ip6tables -A INPUT -p icmpv6 --icmpv6-type 130 -j ACCEPT ip6tables -A INPUT -p icmpv6 -j DROP Exemple avec PF/*BSD : pass in inet6 proto icmp6 all icmp6-type echoreq pass in inet6 proto icmp6 all icmp6-type echorep pass in inet6 proto icmp6 all icmp6-type toobig pass in inet6 proto icmp6 all icmp6-type timex pass in inet6 proto icmp6 all icmp6-type paramprob pass in inet6 proto icmp6 all icmp6-type unreach code addr-unr pass in inet6 proto icmp6 all icmp6-type unreach code port-unr pass in inet6 proto icmp6 all icmp6-type neighbrsol pass in inet6 proto icmp6 all icmp6-type neighbradv # MLD query 21

pass in inet6 proto icmp6 all icmp6-type listqry 5.3 Le multicast Le multicast local ne doit pas être filtré car le protocole de Neighbor discovery en dépend : il est basé sur le multicast sollicité. Il faut autoriser en adresse IP destination tout le prefixe ff02::/16. Exemple avec Netfilter/Linux : ip6tables -A INPUT --destination ff02::/16 -j ACCEPT Exemple avec PF/*BSD : pass in inet6 from ff02::/16 5.4 Les extensions Dans un paquet IPv6, le champ d en-tête Next-Header permet d intercaler des extensions entre l en-tête IPv6 et le protocole transportant la charge utile (TCP, UDP, ICMPv6 etc.). Ces extensions sont chaînables. Il est difficile d établir une politique générale des extensions à filtrer. Certaines extensions sont indispensables, comme l extension Hop by Hop, utilisée par MLD. MLD s appuie sur ICMPv6 et est nécessaire au fonctionnement du Multicast. Cependant, cette extension n est utile qu aux routeurs. D autres extensions peuvent être des vecteurs d attaque si elles n ont pas été correctement paramétrées sur l hôte. Par exemple, la fragmentation et l extension de routage (routing header extension) [16] ont été utilisées par le passé pour conduire des attaques sur des serveurs suite à des vulnérabilités dans l implémentation de la pile de protocole IPv6. Il est possible de bloquer totalement la fragmentation (mais sans bloquer la signalisation ICMP). 5.5 Filtrage du service Le filtrage est identique au filtrage en IPv4. Exemple Linux/Netfilter : # web ip6tables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT # dns 22

ip6tables -A INPUT -p tcp --dport 53 -j ACCEPT ip6tables -A INPUT -p udp --dport 53 -j ACCEPT # ipsec ip6tables -A INPUT -m ah -j ACCEPT ip6tables -A INPUT -p esp -j ACCEPT ip6tables -A INPUT -p udp --dport 500 -j ACCEPT Exemple pf/*bsd : # web pass inet6 proto tcp from any to any port { 80 443 } # dns pass inet6 proto { udp tcp } from any to any port 53 # VPN IPSEC pass inet6 proto {ah esp} from any to any pass inet6 proto udp from any to any port 500 23

Références [1] http://httpd.apache.org/ [2] http://www.lighttpd.net/ [3] http://nginx.org [4] http://sourceforge.net/projects/ipv6-care/ [5] http://www.nagios.org/ [6] http://nc110.sourceforge.net/ [7] http://www.euchinagrid.org/ipv6/ipv6_presentation/introduction_to_ipv6_programming.pdf [8] http://www.sendmail.org/~ca/email/doc8.12/op.html [9] http://www.postfix.org/postconf.5.html [10] http://httpd.apache.org/docs/2.2/mod/mod_proxy.html [11] http://openbsd.org/ [12] http://www.openbsd.org/faq/pf/ [13] http://www.linuxvirtualserver.org/ [14] http://www.netfilter.org/ [15] http://www.ietf.org/rfc/rfc4890.txt [16] http://www.ietf.org/rfc/rfc5095.txt 24

Glossaire DNSv6 Domain Name System extensions to support IPv6 (RFC 3596) ICMPv6 Internet Control Message Protocol for IPv6 (RFC 4884) PMDv6 Path MTU Discovery for IPv6 (RFC 1981) NA Neighbor Advertisement ND Neighbor Discovery for IPv6 (RFC 4861) NS Neighbor Solicitation RA Router Advertisement RS Router Solicitation SLAAC Stateless Address Autoconfiguration (RFC 4862) 25