PROJET AUTOBLOG


Geekfault

Site original : Geekfault

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Comment faire un Initram minimal avec mode rescue

mardi 8 mai 2012 à 00:51

Aujourd’hui Geekfault vous propose d’apprendre à construire vous même votre initram, comme un grand.
On ne parlera pas de splash ou autre eyecandy pour newbies, juste de choses utiles pour nous autres les geeks.
Et on vous expliquera surtout comment ça marche, afin que vous puissiez devenir un Guru de la fabrication d’initram.

Mais au fait, c’est quoi un initram ?

Un initram est un fichier contenant un mini système sur lequel boot le kernel.
Son utilisation la plus commune est de servir d’étape pour lancer le vrai système, c’est ce cas que nous verrons.

Étapes d’un boot typique avec initram

Dans quel cas l’utiliser ?

Si le système est directement accessible par le kernel, un initram ne sert à rien, le kernel y arrivera tout seul.
En revanche si le système n’est pas directement accessible (raid, cryptage, lvm, etc), alors il faut un initram pour y accéder.

Autopsie d’un initram

Un fichier d’initram n’est en fait qu’une archive cpio. cpio étant un format similaire à tar, mais plus basique.
Dans cette archive on retrouve une arborescence de fichier similaire à celle d’un système classique (/dev, /etc, /bin, /lib, etc)
Il doit aussi y avoir le fichier init à la racine de l’arborescence, c’est à ce fichier que le kernel passe la main et c’est presque toujours un script shell.
On ne laisse évidemment dans cette arborescence que le strict nécessaire si bien qu’il ne reste souvent que /bin, /init et un ou deux autres dossiers.
On peux également compresser ce fichier avec gzip, bzip2 ou xz si le kernel le supporte.

Voila pour un rappel de la technologie.

Initram vs initrd

On confond souvent les deux car ils servent à la même chose mais l’initrd est en fait le grand-père de l’initram.
L’initrd est un fichier de taille fixe, formaté en ext2, copié en RAM et monté comme un disque dur.
Alors que l’initram est une archive cpio dont le contenu est copié dans du tmpfs, (taille dynamique, pas besoin de formater).

Bref l’initrd est à l’initram ce que le Tam-tam est à Internet: un ancêtre archaïque.

Construire son initram

Pour éviter de rester vague, prenons un exemple concret: une Gentoo sur une partition cryptée avec dm-crypt, le tout sur Raid 1 software.
En bonus, et pour le même prix, on rajoutera un mode rescue.

Il va nous falloir les ingrédients suivant:

On mettra tout ces ingrédients dans un dossier appelé DOSSIER et on verra plus tard comment transformer ce dossier en initram.

Shell: Busybox

Busybox est une sorte de couteau suisse qui fournit les commandes de base (sh, cd, ls, rm, mount, …), tout cela contenu dans un seul petit exécutable. Il contient bien évidement un shell.

Il existe deux méthodes pour accéder aux commandes de Busybox:

On ajoute Busybox à notre initram:

$ cd DOSSIER
$ mkdir bin
$ cp `which busybox` bin/
$ ln -s busybox bin/sh

Busybox est disponible sur toutes les distribution et, sauf exception, est toujours compilé en static.
Vous pouvez vérifier avec la commande:
$ file `which busybox`
/bin/busybox: ELF 64-bit LSB executable, x86-64, statically linked

Si il est dynamically linked alors il faut soit se débrouiller pour avoir une version statically linked, soit inclure dans l’initram (dans /lib) les librairies dont il a besoin (utiliser la commande ldd pour avoir la liste).
Cela est valable pour tout exécutables que vous ajoutez à votre initram.

/dev: Busybox

La encore, busybox a ce qu’il faut: mdev, un mini udev.
mdev marche différemment de udev qui pour rappel est un service qui tourne en permanence.
mdev à l’inverse est à lancer quand on en a besoin, et on en a besoin de deux façon:

On utilisera mdev dans le script /init.

mdadm et cryptsetup

Pour vous faciliter la tache il vaut mieux les avoir en static sinon il faut inclure les librairies avec.

On ajoute mdadm et cryptsetup à notre initram:

$ cp `which mdadm` bin/
$ cp `which cryptsetup` bin/

On les utilisera dans le script /init

Clavier Français: Busybox

Décidément ce Busybox fait tout !
En fait il ne sait pas vraiment configurer le clavier en français mais il sait sauver la configuration actuelle dans un fichier.

On crée le fichier avec:

$ cd DOSSIER
$ mkdir etc
$ busybox dumpkmap > etc/kmap-fr

Évidement il faut que le clavier soit déjà correctement configuré pour que cette opération ait un sens.
On peux ensuite charger le fichier avec loadkmap, mais nous verrons cela dans le script /init.

Rescue

On a donc maintenant un shell, le clavier peut etre configuré, on a mdadm et cryptsetup, en plus de ça busybox est plein d’outils divers (ip, lspci, wget, ps, etc, …). tapez busybox pour voir la liste.
Il y a donc tout ce qu’il faut pour un rescue, autant en profiter.
Le mode rescue sera tout simplement de lancer un shell pour donner la main à l’utilisateur.

On pourra y arrivera de deux manières:

On vera tout ca dans le script /init.

Pour info, rajouter un paramètre au kernel peux se faire directement depuis Grub:

La modification n’est pas permanente.

Script /init

Le gros morceau, c’est lui qui fait le boulot.

#!/bin/sh

# on monte /sys et /proc
# certains programmes en ont besoin et ça coûte rien
mkdir /proc /sys
mount -t proc proc /proc
mount -t sysfs sysfs /sys

# On crée /dev et on le remplit avec mdev
mkdir -p /dev
mount -t tmpfs none /dev
ln -s busybox /bin/mdev
echo '/bin/mdev' > /proc/sys/kernel/hotplug
mdev -s

# On charge la config clavier pour pouvoir taper le mdp correctement
loadkmap < /etc/kmap-fr # on lance le shell si il y a "rescue" dans les paramètres du kernel grep -w rescue /proc/cmdline && exec sh # on bloque l'output du kernel le temps de taper le mot de passe PRINTK=`cat /proc/sys/kernel/printk` echo 0 > /proc/sys/kernel/printk

# On laisse mdadm se débrouiller pour monter le RAID
# On lui donne juste les dev possible et l'UUID du RAID
# L'UUID peut être obtenu avec la commande "mdadm -D /dev/mdX"
echo 'DEVICE /dev/sd[abcd][2]' > /etc/mdadm.conf
echo 'ARRAY /dev/md2 UUID=62121:a6a45:34d17:37d8e' >> /etc/mdadm.conf
mdadm --assemble --scan || exec sh

# on décrypte (il demande donc le mdp)
cryptsetup luksOpen /dev/md2 vault || exec sh

# on monte la partition décryptée
mkdir /newroot
mount -r /dev/mapper/vault /newroot || exec sh

# on sauve les paramètres du kernel pour les donner au vrai init
CMDLINE=`cat /proc/cmdline`

# on nettoie le bordel qu'on a mis
echo "${PRINTK}" > /proc/sys/kernel/printk
echo '' > /proc/sys/kernel/hotplug
umount /dev
umount /sys
umount /proc

# et on passe la main au vrai système
exec switch_root /newroot /sbin/init ${CMDLINE}

Générer l’initam

Ultra simple:

$ cd DOSSIER
$ find . | cpio --quiet -o -H newc | gzip --best > /boot/mon_initram

Vous pouvez évidement utiliser bzip2 ou xz pour compresser, assurez vous juste que votre kernel le supporte.

Et voila, votre initram est terminé.
Il n’y a plus qu’à booter dessus, à vous les kernel panic !

Retrouver un laptop volé

vendredi 13 avril 2012 à 12:10

Pour ne pas vous raconter ma vie, j’étais en vacances familiales en Floride et nous avons fait la grave erreur de laisser nos sacs dans la voiture, plus de deux heures sans surveillance. Les malfrats d’Orlando ne nous ont pas pardonné : 5 laptops volés ! (sans compter les disques durs et nos passeports).

Le policier qui dressait le constat nous a demandé s’il y avait un système de tracking sur un des laptops. Honte à moi, je prévoyais de l’installer à mon retour…

Mieux vaut prévenir…

Évidemment, personne n’aimerait voir son laptop se faire voler. Mais si on ne s’y est pas préparé, le retrouver sera probablement impossible. Même si dans tous les cas la probabilité de le retrouver reste faible, pourquoi ne pas mettre toutes les chances de votre côté ?

Identification

La première information qui aurait pu être utile et que nous n’avons malheureusement pas pu communiquer aux policiers, c’est un moyen d’identifier l’ordinateur ! Prenez donc le temps de noter sur une feuille de papier et/ou quelque part dans le Cloud les informations discriminantes de votre laptop :

Ce n’est pas grand chose mais si la police venait à retrouver une centaine de laptops dans une cache, ils pourraient probablement vous restituer le vôtre.

Si votre laptop est volé, avoir son numéro de série va vous permettre de l’inscrire sur plusieurs listes :

Bien sûr, ces solutions sont des “long shot”. Si vous souhaitez être plus proactif dans la récupération de votre ordinateur, il va falloir s’orienter vers des solutions logicielles voire matérielles…

Solutions logicielles

Vous avez probablement déjà entendu parler de telles solutions : vous installez un logiciel de tracking sur votre machine et un site gratuit ou payant vous permet de le localiser, de prendre une photo webcam et de collecter d’autres informations.

La solution que je recommande parce qu’elle est aboutie, puissante et pourtant Open-Source est Prey. Cette solution gratuite est disponible sur toutes les plateformes : Windows, MacOS, Linux et même iOS et Android !

Par défaut Prey fonctionne de manière centralisée sur les serveurs du projets. Cela le rend très facile d’utilisation mais avec quelques options payantes heureusement achetables après le vol.

Dans sa version “geek”, Prey est entièrement décentralisé, se basant sur votre propre système, et donc sans aucun risque pour votre vie privée. Je vous recommande aussi de vous renseigner sur Adeona une solution encore plus sûre mais toujours développement.

Attention tout de même : n’oubliez pas que ces solutions nécessitent que votre ordinateur se connecte à Internet ! Pour cette raison, je recommande de laisser un compte “invité” sans aucun droits d’accès mais qui suffira au voleur. Évidemment la solution logicielle ne survivra pas au formatage de l’ordinateur.

Solution matérielle

Mis à part essayer de faire tenir dans votre chassis un de ces appareils servant à espionner votre femme/enfants/employé, je ne connais qu’une solution qui résiste à un reformatage du PC : Computrace.

Très peu connue du grand public, Computrace, commercialisé sous le nom LoJack for Laptops, est une technologie d’Absolute Software inclue dans la plupart des ordinateurs récents (liste de compatibilité). Les mauvaises langues diront que Computrace est un trojan caché dans le BIOS de ces machines et ils n’auraient pas tout à fait tort. Puisqu’il est contenu dans le BIOS, ce petit script est impossible à supprimer. S’il le faut, il se réinstalle au démarrage ce qui le rend même immunisé à un changement du disque dur.

A la manière de Prey, il contacte toutes les 24 heures les serveurs de Computrace pour voir si la machine a été volée (puis toutes les 20 minutes si c’est le cas) et permet de localiser l’ordinateur ou en effacer les données si requis. Malheureusement, en plus de nécessiter Windows ou MacOS pour fonctionner, c’est une solution commerciale qui nécessite de payer un abonnement annuel (minimum 30$/an) et de configurer la machine avant qu’elle ne soit volée.

(Petite note d’inquiétude pour le geek qui est en vous : Computrace semble contacter les serveurs d’Absolute Software même s’il n’a jamais été activé. Serions-nous trahis par notre BIOS ? Heureusement que leur technologie n’est pas compatible Linux…)

Conclusion

Voilà j’espère que je vous aurai convaincu de prendre quelques minutes de votre temps pour préparer le pire. En tout cas, moi j’ai installé Prey sur tous les nouveaux laptops que nous avons dû acheter suite à nos mésaventures.

Pour pousser le vice plus loin, n’oubliez pas de chiffrer vos données sensibles et de révoquer vos clés et mots de passe si nécessaire.

Pour en savoir plus, je vous invite à lire les récits de récupérations grâce à Prey ou, pourquoi pas, expliquer en commentaire comment vous sécurisez votre précieux PC.

Lancer votre dual-booting Windows dans une VirtualBox

vendredi 14 octobre 2011 à 19:48

Mes études me forcent à utiliser des logiciels disponibles uniquement sous Microsoft Windows. Sur ma nouvelle machine j’ai donc décidé de laisser le Windows en dual-boot. Mais je souhaite aussi pouvoir le lancer virtualisé dans mon environnement Linux !

Avec un peu d’astuce c’est tout à fait possible, grâce au mode d’accès disque “raw”. Voici comment j’ai réussi à lancer mon Windows physique à l’intérieur d’une VirtualBox.

Préparation

Je présuppose que vous avez déjà une installation dual-boot fonctionnelle. Dans votre environnement Linux, installez VirtualBox ainsi que l’utilitaire mbr :
# apt-get install virtualbox mbr
Si vous souhaitez lancer cette machine virtuelle en tant qu’utilisateur, nous devons ajouter l’user aux groupes nécessaires :
# gpasswd -a tito vboxusers
# gpasswd -a tito disk

Finalement, essayez de retrouver votre CD d’installation de Windows.

Création du disque virtuel

Pour permettre à VirtualBox de lancer Windows, nous devons créer un disque virtuel bootable. Pour cela on crée un Master Boot Record. Il faut d’abord identifier où se trouve votre Windows. Le mien, comme beaucoup d’installations constructeur de nos jours, tient en deux partitions : la boot sur /dev/sda1 et le système sur /dev/sda2. Je suppose que vous saurez aisément situer le vôtre.
$ mkdir Virtual7 && cd Virtual7
$ install-mbr -e12 --force ./vm.mbr

Remarquez l’option -e12 qui signifie “partitions 1 et 2”, modifiez selon votre système!

Nous créons maintenant le disque virtuel :
$ VBoxManage internalcommands createrawvmdk -filename ./win7.vmdk -rawdisk /dev/sda -partitions 1,2 -mbr ./vm.mbr -relative
À nouveau, modifiez les arguments rawdisk et partitions selon votre système.

Création de la VirtualBox

Vous pouvez maintenant lancer l’interface graphique de VirtualBox et créer une nouvelle machine virtuelle. Lorsque l’assistant demande le disque dur virtuel, allez chercher le fichier Virtual7/win7.vmdk.

Réparer Windows

Si vous essayez de lancer la machine virtuelle maintenant, Windows vous gratifiera d’une jolie erreur vous demandant de démarrer sur le CD d’installation pour réparation. C’est tout à fait normal!

Après avoir monté votre CD d’installation Windows dans VirtualBox, bootez à partir de celui-ci. Choisissez vos options linguistiques et cliquez sur “Réparer l’installation”. La machine virtuelle va redémarrer sous votre Windows!

Problèmes divers

En savoir plus

Prolongez la vie de vos batteries au lithium

mardi 2 août 2011 à 16:04

À chaque fois qu’un ami achète un nouvel ordinateur il me demande comment faire pour que sa batterie au lithium ait une vie longue et prospère. Quand et comment les recharger pour qu’elles durent plus longtemps? Faut-il attendre qu’elles soient vides? Faut-il les enlever lorsqu’on n’a qu’une utilisation sédentaire?

Voici donc un petit survol technique sur la vie et la mort des batteries au lithium qui, je l’espère, vous permettra de comprendre comment prolonger la durée de vie de vos batteries.

Principe de fonctionnement

La base du fonctionnement d’une batterie au lithium peut être résumée à un échange (revérsible lors de la recharge) d’ions de lithium entre les électrodes de la batterie.

Vous avez sans doute déjà entendu plusieurs termes techniques obscurs tels que lithium-ion (Li-Io), lithium-polymère (Li-Po), lithium-air, etc. Celles-ci désignent des batteries au fonctionnement similaire mais utilisant des matériaux différents comme électrodes ou électrolyte. Cependant ces variations sont plus rares que le lithium-ion et l’entretien est relativement similaire.

Capacité d’une batterie

La principale caractéristique d’une batterie est sa capacité (à pleine charge) exprimée en Watt-heures (noté Wh). Une batterie de 1Wh peut fournir une puissance de 1 watt pendant 1 heure. Une batterie typique de laptop ayant une capacité de 50Wh (pouvant donc en théorie fournir 50W pendant 1h), tiendra en fait 5 heures si l’ordinateur consomme 10W.

D’autres batteries voient leur capacité affichées en ampère-heure (Ah) dans ce cas-là elles précisent aussi leur tension nominale. Puisque A×V = W, multiplier la tension par la capacité en Ah vous donnera la capacité en Wh.

Au fil de la vie d’une batterie, c’est cette capacité à pleine charge qui va décroître. Si vous êtes sous Linux, ACPI permet d’accéder à ces informations vitales sur l’état de votre batterie :

$ cat /proc/acpi/battery/BAT*/info
design capacity: 3800 mAh
last full capacity: 3347 mAh

On voit ici que ma batterie de plus de 3 ans est en très bon état pour son âge puisqu’elle a une capacité apparente de 3347/3800 = 88% !

Principal avantage du lithium : pas d’effet mémoire

L’effet mémoire, principalement observé sur les batteries utilisant des alliages au nickel, est une perte de capacité observée lorsqu’on recharge la batterie avant qu’elle soit vide ou qu’on ne la recharge pas jusqu’au bout.

En plus de leur poids et volume plus faible, le principal avantage des batteries au lithium est l’absence totale d’effet mémoire ! Il est donc inutile (et même contreproductif, voir section suivante) de les déchager complètement avant de les recharger.

Mort d’une cellule

Une cellule au lithium chargée fournit 3,7 Volts en moyenne. Cependant elles ne doivent jamais dépasser 4,2V (sous peine d’explosion) ni tomber sous 2,4V sous peine de mort pure et simple de la cellule. Pour cette raison les batteries au lithium incluent un circuit de contrôle qui les éteint avant d’atteindre ce seuil critique.

Il n’est donc pas dangereux de vider une batterie au lithium jusqu’à extinction de l’appareil, mais il est dangereux de les laisser dans cet état déchargé! En effet, les batteries n’étant pas parfaites, elles présentent un phénomène d’auto-décharge qui pourrait les faire passer sous ce seuil critique de 2,4V.

De plus, à l’intérieur d’une cellule déchargée, des cristaux peuvent se former sur les électrodes et nuire à la capacité de la batterie. Il ne faut donc jamais laisser une batterie déchargée. Rechargez-la dès que possible.

Pour les mêmes raison, si vous pensez ne plus utiliser votre batterie durant plusieurs semaines, stockez-la chargée à environ 40%, une valeur limitant l’auto-décharge.

Cycles de décharge/recharge

Après ce cas extrême, parlons de l’utilisation normale de la batterie : des cycles de décharge et recharge. Ces cycles entraînent l’usure normale de la batterie. Selon la qualité des éléments utilisés par votre constructeur, votre batterie pourra survivre de 300 à 1500 cycles avant de présenter une perte importante de capacité.

On compte un cycle à chaque fois que vous utilisez entièrement la capacité de votre batterie. Ainsi, décharger à 50% et recharger une batterie compte pour un demi cycle; deux fois cela fera un cycle.

Pour prolonger la durée de votre batterie il faut donc faire le moins de cycles possibles et le conseil sera donc de brancher votre laptop sur secteur dès que possible. N’oubliez pas qu’il n’y aucun effet mémoire et donc aucune raison d’hésiter!

Utilisation sédentaire d’un appareil à batterie

On entend souvent dire que lorsqu’on est toujours branché sur secteur il vaut mieux retirer la batterie de son laptop. Cette idée reçue est essentiellement fausse car le circuit de contrôle de la batterie évitera toute surcharge.

Débranchée, la batterie risquerait de s’auto-décharger sous le seuil critique de 2,4V alors que branchée elle se remettra à charger dès qu’elle tombera sous les 95%. Remarquons qu’il est toutefois vrai que la chaleur peut altérer une batterie mais dans un ordinateur bien conçu elle ne chauffera pas à ce point.

Les conseils de Tito

Plus d’informations

Yubikey : la petite clé qui assure

jeudi 14 avril 2011 à 12:30

Yubikey, c’est une petite clé USB un peu spéciale. Une petite pastille tactile sur le dessus permet de générer un mot de passe à usage unique, qu’un service distant saura utiliser pour vous identifier ou non. C’est pratique, c’est sûr (si c’est bien utilisé), et c’est assez geek pour qu’on en parle.


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 :

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 :

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 :

yubikey login

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 :

Yubikey 2 Factor

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 😉

yubikey en ssh

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 :
YubiServe

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

Can't retrieve feed: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small