Le problème

Les mots de passe se multiplient comme des petits pains, surtout chez les geeks. Comme il est impensable de tous les noter dans un petit calepin ou d’utiliser le même partout (on est d’accord ?), il faut sans cesse en inventer de nouveaux et les retenir.

Par ailleurs, si on veut être un peu sérieux, il faut se méfier du terminal que l’on utilise, surtout s’il appartient à un tiers. Qui vous dit que le vilain admin du cyber-café n’a pas un vilain keylogger sur toutes ses machines ? Plus fourbe, qui vous dit qu’il n’y a pas un vilain keylogger malware installé sur le laptop de votre [maman|grand-père|hamster] que vous utilisez en ce moment, “pour dépanner” ? Sans parler d’attaques type MitM et autres joyeusetés …

Arrive la Yubikey. Sans être une solution miracle à tous les problèmes de mot de passe, c’est une façon élégante de se simplifier la vie.

La Yubikey, en bref

Yubikey 2.0, by Yubico

Plutôt que de vous pointer vers le manuel de la Yubikey, je vais en synthétiser quelques passage pour commencer.

La Yubikey fonctionne sur n’importe quel matériel équipé d’un port USB hôte et tournant sous à peu près n’importe quel système d’exploitation supportant un clavier USB (sous Linux, le support HID suffit) : en effet, elle fonctionne en émulant des frappes clavier, sans avoir recours à un driver particulier.

À chaque utilisation, la clé génère une chaîne de caractères unique (appelée OTP pour One Time Password), basée entre autres choses sur une identité propre à la clé, un compteur non-volatile, une horloge et un nombre aléatoire. Cette chaîne est ensuite chiffrée à l’aide d’une clé AES de 128 bits et envoyée à l’hôte. Exemples :

[cc]fifjgjgkhchbirdrfdnlnghhfgrtnnlgedjlftrbdeut
fifjgjgkhchbgefdkbbditfjrlniggevfhenublfnrev
fifjgjgkhchblechfkfhiiuunbtnvgihdfiktncvlhck[/cc]

(on constate que les 12 premiers caractères sont toujours les mêmes : il s’agit là de l’identité de la Yubikey)

De l’autre côté, elle sera déchiffrée à l’aide de la même clé AES. De par l’usage d’un chiffrement symétrique, la sûreté de l’ensemble repose sur une bonne protection de la clé AES. Celle-ci est stockée dans une mémoire non volatile intégrée au microcontrolleur et n’est pas accessible, la configuration de la Yubikey se faisant en écriture seule. Pour récupérer la clé, il faudrait éventuellement sonder physiquement la puce ou analyser son comportement, ce qui implique de casser physiquement la Yubikey et de disposer de matériel de pointe. En d’autres termes, si ce n’est pas complètement adapté aux agents secrets, c’est probablement suffisamment sûr pour le geek moyen que je suis.

Le résultat est enfin vérifié par un serveur de validation : soit celui de Yubico, soit un serveur fait maison. La validation tient compte de plusieurs critères, au-delà de la simple identité. Notamment, la valeur du compteur est examinée : si elle est inférieure ou égale à la dernière valeur reçue, l’OTP est rejeté comme étant un “rejeu” d’un OTP plus ancien.

L’ensemble se résume au schéma suivant (cliquer pour agrandir) :

Fonctionnement de base de la Yubikey

Une application doit donc être configurée (ou modifiée) afin d’accepter un login Yubikey. Comme nous utilisons du logiciel libre, ça se fait en général assez facilement. Nous allons donc voir comment utiliser la Yubikey sous Linux de façon basique, puis nous verrons la configuration dune clé pour une utilisation “indépendante” avec serveur de validation maison.

Utilisation simple

De base, nous utiliserons les services de validation de Yubico. Il s’agit ici de configurer simplement Linux pour identifier un utilisateur en utilisant sa clé.

Application n°1 : login Linux

Tout bon Linux moderne utilise en général Linux-PAM pour tout ce qui touche à l’identification utilisateur. Et comme Yubico a la bonne idée de proposer un module PAM, c’est ce que nous allons utiliser.

Il y a trois dépôts à aller chercher pour construire notre module PAM : celui de la bibliothèque yubico-c-client, celui de l’outil de configurationyubikey-personalization, et enfin yubico-pam lui-même. Pour la suite, je suppose que vous avez déjà git d’installé, en sus des outils habituels (automake, gcc …), et que vous savez aller installer une dépendance manquante (comme curl) au besoin.

Compilations

On commence par compiler la bilbiothèque client.
[cc][smokey@moira yubi]$ git clone https://github.com/Yubico/yubico-c-client
Cloning into yubico-c-client…
remote: Counting objects: 397, done.
remote: Compressing objects: 100% (194/194), done.
remote: Total 397 (delta 233), reused 319 (delta 201)
Receiving objects: 100% (397/397), 94.17 KiB, done.
Resolving deltas: 100% (233/233), done.
[smokey@moira yubi]$ cd yubico-c-client/
[smokey@moira yubico-c-client]$ autoreconf –install
[smokey@moira yubico-c-client]$ ./configure
[smokey@moira yubico-c-client]$ sudo make install
[smokey@moira yubico-c-client]$
[/cc]
Rien que du très classique. La bibliothèque est installée comme il se doit dans /usr/local/lib. Je vous laisse d’ailleurs faire exactement la même chose avec yubikey-personalization dans un répertoire à côté, vous êtes grands après tout.

On peut maintenant répéter l’opération avec yubico-pam, à une astuce près : la dépendance ykpers-1 (yubikey-personalization) a été ajoutée très récemment et se vérifie via pkg-config. Il faut donc indiquer à ce dernier où trouver le fichier .pc qui va bien via la variable d’environnement PKG_CONFIG_PATH. Ce qui donne :
[ccW][smokey@moira yubico-pam]$ cd ..
[smokey@moira yubi]$ git clone https://github.com/Yubico/yubico-pam
[smokey@moira yubi]$ cd yubico-pam/
[smokey@moira yubico-pam]$ autoreconf –install
[smokey@moira yubico-pam]$ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig ./configure
[smokey@moira yubico-pam]$ sudo make install
[smokey@moira yubico-pam]$[/ccW]

Le module est installé dans /usr/local/lib/security. Pour que PAM puisse l’utiliser, il faut le mettre au bon endroit (et donc être root) :
[cc]# mv /usr/local/lib/security/pam_yubico.so /lib/security/[/cc]

Configuration de PAM

Il faut maintenant indiquer à PAM que l’on veut pouvoir utiliser l’OTP de la Yubikey. Pour ce faire, on modifie /etc/pam.d/login pour y faire ajouter la ligne suivante :
[cc]auth sufficient pam_yubico.so id=16[/cc]
Attention : si vous n’êtes pas très familiers avec PAM, sachez qu’il faut ajouter cette ligne au bon endroit. Je vous recommande de la mettre juste au-dessus de celle du module pam_unix.so. Si vous la placez trop haut, étant donné que le module est ici sufficient (suffisant), il shuntera les modules auth suivants, même s’ils sont required (requis) : pam_securetty ou pam_nologin seraient par exemple rendus inefficaces, ce qui PEUT être grave OU PAS. À vous de voir

Variantes possibles :

• avec debug (conseillé en cas de souci)
  [cc]auth sufficient pam_yubico.so id=16 debug[/cc]
• avec gestion centralisée des identités
  [cc]auth sufficient pam_yubico.so id=16 authfile=[/cc]

Note : pour observer les messages de debug, il suffit de créer le fichier /var/run/pam-debug.log et de le rendre inscriptible à tous.

Pour finir, il faut renseigner le système sur l’identité des yubikeys des utilisateurs. Il y a deux façons de le faire :

• individuellement : il faut alors créer ~/.yubico/authorized_yubikeys pour chaque utilisateur ;
• globalement : le fichier peut se trouver n’importe où, du moment que le chemin correspond à celui passé à authfile= ci-dessus évidemment.

Dans les deux cas, le format du fichier est :
[cc]::…[/cc]
Pour le fichier global, ayez soin d’utiliser une ligne par enregistrement utilisateur. L’ID de chaque Yubikey peut facilement être récupéré en prenant les 12 premiers caractères de n’importe quel OTP généré.

Si tout s’est bien passé, au prochain login, vous devriez voir quelque chose dans ce genre :

Login console avec la Yubikey
On effleure la clé, et c'est gagné

Application n°2 : authentification à 2 facteurs avec SSH

L’authentification à 2 facteurs est basée, comme son nom l’indique, sur deux moyens d’authentification différents. Ici, nous sommes dans le cas typique de “ce que l’on connaît” (un mot de passe classique) combiné avec “ce que l’on détient” (la Yubikey). Les deux seront combinés pour former un mot de passe hybride, que l’on va charger pam_yupico de valider. En image, ça donne ça :

Fonctionnement de l'authentification à 2 facteurs avec SHS et PAM

La marche à suivre est sensiblement la même que précédemment, sauf bien entendu pour ce qui est de la configuration de PAM. Ici, on va s’intéresser logiquement à /etc/pam.d/sshd. Tout d’abord, on y ajoute la ligne suivante :
[cc]auth required pam_yubico.so id=16[/cc]
Par rapport à tout-à-l’heure, l’utilisation de la Yubikey est ici requise au lieu d’être suffisante. Du coup, on ne risque plus de shunter d’autre modules, mais il faut tout de même placer cette ligne AVANT celle de pam_unix.so.

Ensuite, il faut modifier les paramètres du module pam_unix.so. Celui-ci peut être configuré directement dans /etc/pam.d/sshd (ex. Archlinux), ou être appelé par un @include pointant sur /etc/pam.d/system-auth (ex. Gentoo) ou /etc/pam.d/common-auth (ex. Debian) : à vous d’adapter en fonction de ce que vous avez sous les yeux. L’important est d’ajouter l’option try_first_pass, de façon à ce que la ligne ressemble à ceci :
[cc]auth required pam_unix.so try_first_pass nullok[/cc]

Une fois ces modifications faites, il ne reste plus qu’à vous connecter à la machine distante comme d’habitude ; mais au lieu de taper simplement Entrée pour valider le mot de passe, on va rajouter l’OTP de la Yubikey. En d’autres termes, au lieu de faire mot_de_passe+Entrée, on fait mot_de_passe+toucher_la_yubikey.

Et ça marche ! Sauf si bien sûr vous avez oublié de préciser PasswordAuthentication yes dans votre /etc/ssh/sshd_config … c’était pour voir si vous suiviez

Login SSH. Par défaut, SSH propose d'utiliser la clé publique s'il en trouve une : taper entrée pour passer à l'étape suivante.

Utilisation avancée

Dans cette partie, un peu plus technique, nous allons aborder la configuration d’une Yubikey et le montage d’un serveur de validation. Mais avant tout …

ATTENTION

La Yubikey est “write-only”. Ceci signifie que lors d’une opération de configuration, les réglages précédents sont irrémédiablement perdus. Notamment, si vous écrasez la configuration par défaut, votre clé ne pourra plus vous identifier auprès de Yubico.
Par ailleurs, si vous décidez de protéger la clé par un code d’accès, et que vous oubliez ce code, vous aurez gagné un joli bout de plastique très décoratif …

Ceci dit, passons aux choses sérieuses.

Configuration de la clé

Sous Linux, le seul outil disponible pour l’instant est en ligne de commande. Si ça vous fait peur, il y a des équivalent pour clicodrome Windows ou Mac OS. Choisissez ici celui qui vous convient le mieux

Le dépôt de l’outil de configuration (ou personalization en anglais) est ici : https://github.com/Yubico/yubikey-personalization.git. Je ne reviens pas sur la procédure d’installation, elle est identique aux précédentes et détaillée sur le wiki du projet. D’ailleurs, si vous avez suivi la partie sur la configuration de PAM, vous l’avez déjà installé

Une fois compilé, je vous engage vivement à jeter un oeil à l’aide en ligne : [cci]ykpersonalize -h [/cci]

L’option la plus importante à mes yeux est -1 ou -2 : c’est ainsi que l’on choisit la configuration que l’on souhaite modifier. En effet, les Yubikeys version 2.0 et plus possèdent deux “emplacements” différents, contre un seul dans la première version. Par défaut sur une clé 2.0 par exemple, l’emplacement 1 est paramétré pour une identification OTP auprès des serveurs de Yubico, et l’emplacement 2 est vide.

Le paramétrage le plus fréquemment rencontré est d’assigner un mot de passe statique à la configuraion 2, mot de passe qui sera accessible par un contact long (≃ 2s). La manipulation est ici très simple :
[cc lines="16"]smokey@moira:~$ sudo ykpersonalize -2
Password:
Firmware version 2.0.2 Touch level 1792 Program sequence 6

Passphrase to create AES key: crévindiou
Configuration data to be written to key configuration 2:

fixed: m:
uid: h:000000000000
key: h:459b2b6c6f4c511d543919efbad3051a
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags: STATIC_TICKET|STRONG_PW1|STRONG_PW2|MAN_UPDATE
extended_flags:

Commit? (y/n) [n]:[/cc]
Il ne reste plus qu’à valider par un “y” pour sauvegarder la configuration.
Notez que vous n’êtes pas obligés de taper des bêtises (comme mon “crévindiou”) pour créer la clé AES. Le résultat sera ici un mot de passe statique du style :
[cci]è(IFejhdkkjnvrtbdeggeffvbknvbulg[/cci].

Note : Pourquoi sudo ? tout simplement parce que les permissions de /dev/bus/usb/xxx/yyy n’autorisent en général pas l’utilisateur lambda à écrire sur un port USB.

Il est également possible de créer une configuration “OTP Yubikey” similaire à la configuration par défaut. Je fais ici le choix d’utiliser l’emplacement 2, afin de conserver la configuration d’origine dans l’emplacement 1. Or, l’outil ykpersonalize considère par défaut que l’option -2 va de pair avec une configuration statique ; il faut donc désactiver les options liées au mot de passe statique pour écrire une configuration OTP dans l’emplacement 2 (d’où les 4 options -o-xxx). Si ce n’est pas clair, faites tourner “à vide” (sans écrire) ykpersonalize avec -1 et -2, et observez les différents config_flags. Ici, ça nous donne :
[ccW lines="16"]smokey@moira:~/tmp/yubiserve$ sudo ykpersonalize -2 -o-static-ticket -o-strong-pw1 -o-strong-pw2 -o-man-update -ofixed=cccccccccccc
Firmware version 2.0.2 Touch level 1792 Program sequence 6

Passphrase to create AES key:
Configuration data to be written to key configuration 2:

fixed: m:cccccccccccc
uid: h:000000000000
key: h:8ebfe5cd3dad48f2c5008d686ea5b384
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags:
extended_flags:

Commit? (y/n) [n]: y
smokey@moira:~/tmp/yubiserve$
[/ccW]

La configuration 2 de la clé est donc faite pour l’identité cccccccccccc et avec la clé AES 8ebfe5cd3dad48f2c5008d686ea5b384. Nous allons voir maintenant comment utiliser cette configuration avec un serveur de validation maison.

Serveur de validation “maison”

Comme me le faisait remarquer un certain Spyou, confier à un tiers la vérification du droit d’accès à son infrastructure n’est probablement pas l’idée du siècle. Mon infrastructure se limite à peu de choses, mais tant qu’à faire, autant garder la vérification en interne. Il s’agit donc maintenant de monter son propre serveur de vérification. Yubico en référence quelques-uns, je vais ici détailler l’installation et la configuration du plus simple, YubiServe. Et quand je dis simple, je pèse mes mots : le tout tient en 2 scripts Python

Avant tout, je vous recommande d’éviter la version 3.1, qui (chez moi en tout cas) contient des “?” partout là où on attend des tabulations. Je vais donc partir du trunk svn :
[cc]svn checkout http://yubico-yubiserve.googlecode.com/svn/trunk/ yubiserve[/cc]

Ceci fait, suivons les instructions du README.
Tout d’abord, on crée un certificat SSL :
[ccW]openssl req -new -x509 -keyout yubiserve.pem -out yubiserve.pem -days 365 -nodes[/ccW]

Ensuite, si vous avez installé Python 2 et 3 sur votre système, il vous faudra peut-être modifier un peu les scripts dbconf.py et yubiserve.py : soit pour faire pointer l’interpréteur vers python2, soit pour modifier l’appel au module sqlite en sqlite3. Par défaut, YubiServe utilisera une base sqlite (déjà présente d’origine), mais il suffit de modifier le fichier de configuration (yubiserve.cfg) pour utiliser une base MySQL à la place.

Il est temps maintenant d’ajouter une clé au serveur. Utilisons donc dbconf.py, qui prend en arguments un “nickname” permettant d’identifier facilement la clé, ainsi que l’uid et la clé AES utilisés lors du paramétrage (cf. plus haut).
[ccW]smokey@moira:~/tmp/yubiserve$ ./dbconf.py -ya smokey cccccccccccc 000000000000 8ebfe5cd3dad48f2c5008d686ea5b384
Key ‘smokey’ added to database.
smokey@moira:~/tmp/yubiserve$[/ccW]
On en profite pour ajouter aussi l’identité cccccccccccc dans le /home/utilisateur/.yubico/authorized_yubikeys qui va bien.

Lançons le serveur :
[cc]smokey@moira:~/tmp/yubiserve$ ./yubiserve.py
HTTP Server is running.
[/cc]

Il ne reste plus qu’à essayer le tout, en faisant pointer un navigateur sur http://127.0.0.1:8000/, ce qui donne normalement ceci :

Il suffit alors d’envoyer l’OTP dans le champ prévu à cet effet pour obtenir le résultat :

Ça fonctionne ! Mais comment faire en sorte d’interroger ce serveur ? Nous allons voir le cas du module PAM, configuré dans la partie précédente.

PAM + Serveur de validation maison

Rappelez-vous, la configuration ressemblait à ça :
[cc]auth required pam_yubico.so id=16[/cc]
Nous allons la transformer en ça :
[ccW]auth required pam_yubico.so id=1 debug url=http://127.0.0.1:8000/wsapi/2.0/verify?id=%d&otp=%s[/ccW]

Par ailleurs, vous aurez remarqué que l’on a précisé un id en argument à pam_yubico. Cet id numérique sera passé via l’URL au serveur de validation : il faut donc qu’il soit défini côté serveur. Nous allons donc ajouter une clé d’API :
[cc]smokey@moira:~/tmp/yubiserve$ ./dbconf.py -aa test-ssh
New API Key for ‘test2′: ‘WGZydWozbHQyVW9BM092cy9nMTk=’
Your API Key ID is: 1[/cc]
Bien entendu, notre “API Key ID” est 1 seulement si c’est le premier à être créé ; l’important est qu’il existe.

C’est fini ! On peut maintenant s’identifier auprès de PAM avec la clé re-configurée par nos soins.

N’oublions pas …

Il serait imprudent de penser que la Yubikey est la réponse à tout. Elle n’est qu’un élément de plus dans une stratégie de sûreté qui se doit d’être solide par ailleurs (c’est toujours le maillon le plus faible qui compte). Si votre login est connu et que vous n’utilisez *que* la Yubikey pour vous connecter, c’est déjà beaucoup moins sûr qu’un schéma à 2 facteurs.

Par ailleurs, comme la Yubikey fonctionne en émulant une saisie clavier, son comportement dépendra du type de clavier utilisé sur le terminal ; si la plupart des dispositions classiques (azerty/qwerty) ne devraient pas poser problème, il en est tout autrement pour les dispositions plus “exotiques” (comme bepo) ou utilisant des caractères non-latins (cyrilliques par exemple). Ce n’est pas un point bloquant en soi, vu qu’il suffit de changer temporairement la configuration du clavier, mais je me devais de le souligner, vu qu’on m’avait posé la question.

Conclusion et informations additionnelles

Tout comme une clé SSH avec un user-agent, une Yubikey permet d’éviter de taper des mots de passe à chaque login. C’est un gain de temps et de tranquillité d’esprit. C’est aussi une sécurité supplémentaire car les mots de passe générés ne sont pas réutilisables, ce qui invalide toute forme d’attaque par rejeu. Cerise sur le gâteau, on trouve déjà pas mal de solutions logicielles libres, venant de Yubico ou d’ailleurs, permettant de tirer le maximum de sa clé. Que demander de plus ?

Liens

• Le site de Yubico, le fabricant : http://www.yubico.com/
• Le lien direct Yubikey du site : http://www.yubico.com/yubikey
• La bibliothèque Yubico-C : https://github.com/Yubico/yubico-c-client
• L’outil de configuration : https://github.com/Yubico/yubikey-personalization
• Le module Yubico-PAM : https://github.com/Yubico/yubico-pam
• Le HOWTO pour SSH : https://github.com/Yubico/yubico-pam/wiki/YubikeyAndSSHViaPAM

Si vous avez aimé ce post...

1. La petite guerre du Warez

Qu’est-ce qu’IPv6 ?

Comme vous le savez certainement, Internet aujourd’hui repose essentiellement sur IPv4. Pour lui succéder, IPv6 (ou IPng, bien que cette deuxième dénomination soit moins fréquente) a été conçu il y a bien longtemps déjà. Sa mise en service était prévue en 1996 !
Bizarrerie d’Internet, IPv5 n’a pas grand chose à voir avec les deux autres ; pour les curieux, il s’agit du Stream Protocol ST-II, qui est décrit ici.
Alors qu’une adresse IPv4 ressemble à 81.93.247.142, une adresse IPv6 ressemble plutôt à 2001:758:1664::42 … mais nous y reviendrons plus tard.

Pourquoi remplacer IPv4 ?

Disons-le tout net, IPv4 marche encore très bien (aux dernières nouvelles en tous cas). Mais comme une adresse IPv4 est codée sur 32 bits, IPv4 ne peut adresser que 2³² hôtes, soit un peu plus de 4 milliards de machines diverses et variées. La quantité d’adresses disponibles, qui semblait suffisante il y a 30 ans, diminue constamment, sans compter qu’une bonne partie de ces adresses sont réservées et ne peuvent être allouées. Selon certaines estimations, l’espace d’adresses IPv4 sera épuisé d’ici 2011/2012.

Par ailleurs, la plupart des FAI grand public attribuent en général UNE adresse IPv4 publique par abonné … et encore. Si vous êtes derrière un routeur ou une *box, sauf cas particulier, vous pouvez dire adieu à l’adresse IP publique : le routeur fera probablement du NAT (Network Address Translation). Et s’il s’agit d’une connexion Internet mobile, là encore, il n’y aura probablement pas d’IP publique au bout de la ligne.
Or, selon la définition que l’on donne à Internet, ne pas avoir d’adresse IP publique c’est ne pas être sur Internet (c’est en tout cas l’opinion de Benjamin Bayart, président de FDN).
Par ailleurs, le NAT c’est bien gentil, mais ça complique très nettement la vie dès qu’il s’agit de faire du peer-to-peer (la technologie au sens large) ou de la VoIP par exemple.

Enfin, de façon générale, IPv6 apporte de nombreuses améliorations par rapport à IPv4 : il a été conçu de manière à permettre une répartition plus facile de son espace d’adressage, à effectuer un routage plus efficace, à mieux supporter le multicast ou encore à intégrer un concept de mobilité pour les terminaux nomades : autant de bonnes raisons de migrer !

Avant d’aller plus loin, voici un petit brin de théorie visant à exposer les bases d’IPv6. Après cela, nous verrons comment se doter d’IPv6 à la maison, et nous aborderons enfin quelques-unes des améliorations évoquées précédemment ainsi que certains aspects plus pointus de l’utilisation et de la configuration.

Généralités sur les adresses

Pour commencer, les adresses IPv6 sont codées sur 128 bits, ou encore 16 octets. Il y a donc 2¹²⁸ adresses possibles, soit environ 3.4×10³⁸, c’est-à-dire environ 5×10²⁸ adresses pour chacun des 6.5 milliards d’habitants de la planète (en 2006, source Wikipedia).
Selon l’hypothèse la plus conservatrice, un foyer connecté à Internet pourrait recevoir environ 18 … milliards … de milliards d’adresses publiques : 18 x 10¹⁸, ou 2⁶⁴ plus exactement. Par foyer. On devrait pouvoir tenir le coup.

Comme ça n’est pas très pratique d’écrire 128 bits sous forme décimale (essayez, vous verrez …), on utilise une représentation hexadécimale : les digits sont groupés par 4, les groupes sépares par des “:”, et les zéros non-significatifs peuvent être omis tant que ça reste non-équivoque. Exemples :

• 3FFE:1123:4567:89AB:CDEF:1234:5678:9ABC
• 2001:7a8:b285::1 ; ici les zéros superflus ont été remplacés par “::”, ce qui ne peut être fait qu’une seule fois dans l’écriture de l’adresse pour éviter toute ambiguïté. Cette adresse équivaut donc à 2001:07A8:B285:0000:0000:0000:0000:0001 ;
• ::1 ; c’est l’équivalent du bon vieux 127.0.0.1, la boucle locale (pas celle de FT, vous l’aurez compris) ;
• :: ou ::/0; l’adresse la plus simple à écrire sans aucun doute, c’est le pendant du 0.0.0.0 (/0) d’IPv4 ;
• ::ffff:81.93.247.142 ; petite entorse à la règle, il est acceptable d’utiliser la notation décimale IPv4 quand on écrit une adresse IPv4 “mappée” en IPv6 (attention, ça ne marche pas partout) ;
• 2001:7a8:b285::12::34 n’est PAS une adresse valide. Les :: sont équivoques, on ne sait pas exactement où se situe le 12 au milieu de l’adresse.

ping6 vers le site de GeekFault depuis un serveur voisin

La notation CIDR (en “slash”) fonctionne sur le même principe qu’en IPv4 : le suffixe /X signifie qu’une adresse appartient à un réseau dont les X premiers bits sont fixés (partie réseau de l’adresse donc) et les 128-X derniers bits sont réservés à l’hôte. Par exemple, 2001:7a8::/32 désigne le réseau dont les 32 premiers bits sont 2001:7a8 (en l’occurrence il s’agit du FAI français Nerim), tandis que ::/0 représente n’importe quelle adresse IPv6. On peut dire que 2001:758:1664::42 et 2001:758:1664::57 sont deux hôtes probablement différents mais appartenant au même sous-réseau 2001:758:1664::/64, lui même appartenant à 2001:758:1664::/48. Un sous-réseau de taille 64 est normalement situé sur un même brin physique.

Les 16 premiers bits d’une adresse IPv6 nous renseignent sur son type d’utilisation, par exemple 2001 pour les adresses attribuées de façon permanente, ou 3FFE pour le 6bone expérimental aujourd’hui obsolète. Deux cas particuliers sont à noter : le préfixe 2002::/16 identifie les adresse 6to4 (un protocole de transition pour ceux qui sont privés d’IPv6), tandis que le préfixe fe80::/10 est réservé aux adresses locales (un peu à l’image de 169.254.0.0/16) ou “link-local” ; ces adresses locales ne sont utilisables que sur un même segment du réseau local ou sur une connexion point-à-point.

Pour pouvoir continuer à utiliser des noms symboliques plutôt que des adresse littérales, il faut que le DNS soit lui aussi IPv6-ready. Dans la pratique, un serveur DNS délivre des enregistrements AAAA pour la recherche directe (conversion de nom en adresse IPv6) et utilise les zones .ip6.arpa pour les recherches inverses. Par exemple :
[cc]geeknode@ircd ~ $ dig +short -t aaaa www.kame.net
2001:200:0:8002:203:47ff:fea5:3085
geeknode@ircd ~ $ dig +short -x 2001:200:0:8002:203:47ff:fea5:3085
orange.kame.net.
geeknode@ircd ~ $[/cc]

Dernière astuce à noter, il arrive de devoir (ou de vouloir) taper une adresse IP littérale dans un navigateur, dans un fichier de configuration, ou à d’autres endroits où le caractère “:” est déjà utilisé (pour spécifier le numéro de port par exemple). Dans ce genre de cas, il est possible d’indiquer une adresse IPv6 littérale en l’encadrant par des crochets, comme par exemple [2001:758:1664::42].

Maintenant que l’on connaît un peu mieux les différents types d’adresses IPv6 et que nous savons à quoi elles ressemblent, nous allons faire un tour du côté de la configuration.

Auto-Configuration sans état

L’une des nouveautés d’IPv6, c’est la possibilité pour l’OS de configurer automatiquement une interface réseau. Certes, IPv4 le fait déjà assez bien avec l’aide du DHCP, mais il s’agit là d’une configuration dite “avec état”, ou “stateful” : le serveur DHCP tient à jour une liste des clients configurés et des adresses IP disponibles. Nous allons aborder ici la configuration automatique “sans état”, ou “stateless”.

Dès lors que le protocole IPv6 est disponible et si l’auto-configuration est activée, l’OS va chercher ses réglages tout seul. La première étape consiste à monter une adresse link-local sur l’interface considérée. Pour cela, on utilise le préfixe fe80::/10 et l’adresse MAC de l’interface ; par une subtile transformation, les 48 bits de cette adresse vont donner les 64 bits de droite de l’adresse locale. Cette transformation est simple :

• on part de l’adresse MAC, 00:18:F8:CC:CC:20 par exemple (ici un Linksys WRT54GL) que l’on sépare en deux blocs de 24 bits par le milieu : 00:18:F8 et CC:CC:20 ;
• on inverse la valeur du 7è bit du premier groupe, appelé “universel/local” ; 0×00 en binaire donne 00000000, qui devient 00000010 après l’inversion du 7è bit, et donc 0×02 de retour en hexa ;
• on réunit le groupe ainsi modifié et le deuxième groupe du début en insérant au milieu les octets FFFE, ce qui donne au final les 64 bits 02:18:F8:FF:FE:CC:CC:20 ;

Génération de la partie hôte de l'adresse à partir de l'adresse MAC

Avant d’utiliser cette adresse, il faut vérifier son unicité sur le lien réseau. C’est l’une des applications du Neighbour Discovery Protocol, nommément la Duplicate Address Detection (DAD). Le protocole NDP repose sur ICMPv6, qui pour l’occasion se dote de nouveaux types de messages. L’un d’eux, “Neighbour Solicitation”, sert justement à vérifier que l’adresse que l’on s’apprête à utiliser n’est pas déjà attribuée à quelqu’un d’autre sur le lien. Lorsqu’une interface est montée est que son adresse locale potentielle (ou “tentative” dans le jargon) a été déterminée, l’hôte envoie un paquet “Neighbour Solicitation” à destination de cette même adresse et attend une réponse éventuelle. S’il n’y en a pas, l’adresse est considérée comme disponible et devient utilisable sur l’interface considérée.

Jusqu’ici, nous avons tout de même obtenu une adresse utilisable sur le LAN sans l’aide d’un DHCP. Cependant, pour sortir du LAN, il nous manque encore deux éléments : un routeur et une adresse IPv6 globale routable. Là encore c’est grâce à NDP que l’on va y arriver.
Un routeur IPv6 envoie périodiquement sur le réseau des messages NDP dits “Routeur Advertisement” (RA pour faire court) qui contiennent entre autres informations le préfixe réseau à utiliser pour l’auto-configuration ainsi que l’adresse du routeur. L’hôte peut également envoyer un message “Router Solicitation” à une adresse multicast spéciale dite “all routers” valable sur le lien (link-local), ff02::2 ; le routeur doit répondre à cette requête par un RA. L’hôte utilise alors le même mécanisme que pour déterminer l’adresse link-local, mais en utilisant cette fois-ci le préfixe annoncé par le routeur.
Après vérification (DAD), l’adresse unicast globalement unique et routable ainsi obtenue est validée pour de bon, et l’adresse du routeur enregistrée comme passerelle par défaut : bienvenue sur la toile-v6 !

Il est temps maintenant de passer à la pratique

IPv6 en pratique

Dans la vraie vie, tout le monde est plus ou moins égal face à IPv6. Les plus chanceux (abonnés Nerim, FDN, Free dans une moindre mesure) ont de l’IPv6 natif (ou presque) directement sur leur interface WAN (fût-elle xDSL ou FTTH). Pour les autres, il faudra utiliser des méthodes basées sur les tunnels, comme le 6to4 ou Teredo (article à venir …).

Quoi qu’il en soit, un abonné recevra de son FAI (ou de son fournisseur de tunnel) un préfixe de la forme 2001:7a8:b285::/48. Le FAI se charge de router tout ce préfixe vers la ligne de l’abonné, et ce dernier se débrouille pour faire le reste. Comme il n’y a en général qu’une seule ligne chez l’abonné, par laquelle passe tout le trafic, il faut un routeur.

Fabuleux, vous en avez probablement déjà un. Mais est-il seulement IPv6-aware ? À moins d’avoir une FreeBox, la réponse est probablement “non” : le support IPv6 dans ce genre de matériels est pour le moins anecdotique. Le geek IPv6-friendly va donc se monter une petite bécane sous Linux (ou flasher son WRT54GL par exemple) avec le support IPv6 compilé dedans. On peut certainement faire pareil avec *BSD, mais je ne parle pas de ce que je ne connais pas

Le routeur fait en général au moins trois choses chez un particulier, quatre si on a du bol :

• il fournit la connexion au WAN, fût-ce par ADSL, câble, fibre ou autre ;
• il route les paquets, c’est quand même pas banal, avouez-le ;
• il aide à se configurer les postes clients ;
• en option, il fait du filtrage.

Pour la connexion au WAN, le plus facile reste l’IPv6 natif. En effet, en ajoutant simplement une ligne contenant ipv6 , à son /etc/ppp/options, pppd se charge de négocier une IPv6 link-local avec le pair d’en face.

Pour le routage, c’est là encore désarmant de simplicité :
[cc lang="bash"]echo 1 > /proc/sys/net/ipv6/conf/all/forwarding[/cc]
Félicitations : le routeur est maintenant capable de relayer les paquets à qui de droit. Bien sûr, libre à vous d’ajouter ça au sysctl.conf pour faciliter les choses.

Il faut ensuite informer les postes clients de la disponibilité d’IPv6 et à les configurer. On peut bien sûr utiliser l’auto-configuration stateful, avec DHCPv6, ou stateless, dont on a parlé au chapitre précédent. Cette dernière méthode requiert l’utilisation sur le routeur de radvd, pour Router ADVertisement Daemon. Après l’avoir installé selon la méthode de votre choix (apt-get, emerge, tar …), il vous faudra éditer le fichier de configuration (en général /etc/radvd.conf ou approchant), dont voici un example :
[cc]interface br-lan
{
AdvSendAdvert on;
MaxRtrAdvInterval 60;
# AdvLinkMTU 1492;

prefix 2001:7a8:b285::1/64
{
};
};[/cc]

Le fichier comporte au moins une définition d’interface ; ici, il s’agit de l’interface br-lan d’un WRT54GL sous OpenWRT. Dans l’ordre, les 4 premières options servent à indiquer que le service doit envoyer des RA et répondre aux sollicitations sur l’interface, les RA sont au maximum espacés de 60 secondes, et le MTU annoncé sur le lien est fixé à 1492 (option désactivée ici, mais très utile si vous êtes en PPPoE sur l’interface WAN). Vient ensuite une définition de préfixe, ici de longueur 64, qui ne contient ici aucune option particulière : les options par défaut conviendront parfaitement.

Enfin, pour le filtrage, il existe sous Linux le pendant IPv6 d’iptables, tout simplement nommé ip6tables. Tout comme en IPv4, il est possible de faire du conntrack en IPv6, moyennant un kernel “pas trop vieux” (ça ne marchera pas avec un 2.4 par exemple). La principale différence avec l’IPv4 est bien sûr l’absence du NAT : tout ou presque se passera directement dans la table FORWARD

Nous n’avons pas encore parlé de la configuration des postes clients, et il y a une raison très simple à cela : par défaut, il n’y a rien à faire. Du moment que le routeur est configuré correctement, l’OS client saura s’auto-configurer comme nous l’avons vu au chapitre précédent. Comme IPv6 est utilisé en priorité chaque fois que c’est possible, l’accès aux services disponibles se fera automatiquement et de façon transparente pour l’utilisateur final.

Nous voici arrivés à la fin de cette introduction à IPv6. Moyennant un petit temps de prise en main, ce “nouveau” protocole ne devrait pas poser trop de soucis à ceux qui ont déjà quelques notions de réseaux IP. Quelques points à retenir :

• la forme des adresse doit maintenant vous être familière, attention simplement à l’écriture compacte (placement des “::”) et aux préfixes particuliers (2002::, fec0::, fe80:: …) ;
• ICMPv6 joue un grand rôle dans IPv6, le NDP se substituant ainsi pour partie à ARP et DHCP ;
• un routeur sous linux avec un démon radvd suffira à faire profiter de l’IPv6 à votre LAN.

Cet article est j’espère le premier d’une série sur le sujet. Il y a en effet d’autres aspects à aborder ou certains problèmes à évoquer (comme le souci du pMTU par exemple) et un ou deux mythes à casser (non, IPv6 ne ralentit pas votre connexion !). À bientôt !

Si vous avez aimé ce post...

1. Geekfault disponible en IPv6
2. DenyHosts pour empêcher le bruteforce sur SSH
3. On a testé pour vous : Ubuntu Jaunty Jackalope 9.04