systemd : reconfigurer une unité de service

bricolage bumperDans le billet précédent, j'ai abordé haveged et je terminais sur le fait que certains paramètres pouvaient être accessibles. Cela ne semble pas forcément évident, car si on regarde la liste des fichiers du paquet RPM, on n'y trouve aucun fichier de configuration :

$ rpm -ql haveged
 /usr/lib/systemd/system/haveged.service
 /usr/lib64/libhavege.so.1
 /usr/lib64/libhavege.so.1.1.0
 /usr/sbin/haveged
 /usr/share/doc/haveged
 /usr/share/doc/haveged/AUTHORS
 /usr/share/doc/haveged/COPYING
 /usr/share/doc/haveged/ChangeLog
 /usr/share/doc/haveged/README
 /usr/share/doc/haveged/havege_sample.c
 /usr/share/man/man8/haveged.8.gz

De plus, si on regarde le processus lancé, on remarque que certaines options sont précisées sur la ligne de commande :

$ ps auxwww | grep haveged | grep -v grep
root     22470  0.0  0.7  12132  3824 ?        Rs   May16   0:00 /usr/sbin/haveged -w 1024 -v 1 --Foreground

Allons un peu plus loin, le paquet contient un fichier "haveged.service" :

$ cat /usr/lib/systemd/system/haveged.service
[Unit]
Description=Entropy Daemon based on the HAVEGE algorithm
Documentation=man:haveged(8) http://www.issihosts.com/haveged/

[Service]
Type=simple
ExecStart=/usr/sbin/haveged -w 1024 -v 1 --Foreground
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target

Il ne faut pas succomber à la tentation de modifier directement ce fichier, car une possibilité plus propre existe : la documentation officielle RHEL 7 nous apprend ainsi comment créer un fichier de configuration pour le service.

Dans ce cas précis, je souhaite augmenter la valeur de l'argument -w à 2048. Pour l'anecdote, cette option permet d'augmenter l'utilisation de haveged en définissant une taille minimale du réservoir d'entropie. Nous allons donc d'abord créer un répertoire de configuration de service systemd, puis le fichier lui-même :

# mkdir /etc/systemd/system/haveged.service.d/
# vi /etc/systemd/system/haveged.service.d/custom_args.conf

Bon, peu importe le nom du fichier tant qu'il a pour extension ".conf", mais il est malgré tout préférable de lui donner un nom explicite (en clair, faites ce que je dis, pas ce que je fais).

Nous allons dans ce fichier redéfinir la directive ExecStart, puisque c'est celle qui définit l'option à modifier. Par contre, petite subtilité, cette directive doit être vidée pour être redéfinie. Le fichier a donc cette allure :

[Service]
ExecStart=
ExecStart=/usr/sbin/haveged -w 2048 -v 1 --Foreground

Il faut maintenant recharger les unités avant de redémarrer le service haveged :

# systemctl restart haveged.service
Warning: haveged.service changed on disk. Run 'systemctl daemon-reload' to reload units.
# systemctl daemon-reload
# systemctl restart haveged.service
# ps auxwww | grep haveged | grep -v grep
root     23074  2.4  0.7  12132  3836 ?        Ss   04:02   0:00 /usr/sbin/haveged -w 2048 -v 1 --Foreground

Le démon haveged est alors lancé avec une valeur de 2048 pour l'option -w.

Dernier petit détail, SELinux. J'ai testé cette manipulation sur un système configuré en "enforcing", l'édition du fichier s'est donc faite dans le bon contexte. Au cas où certains se demandent comment sont les labels, les voici :

# ll -Z -d /etc/systemd/system/haveged.service.d
drwxr-xr-x. root root unconfined_u:object_r:systemd_unit_file_t:s0 /etc/systemd/system/haveged.service.d
# ll -Z /etc/systemd/system/haveged.service.d/custom_args.conf
-rw-r--r--. root root unconfined_u:object_r:systemd_unit_file_t:s0 /etc/systemd/system/haveged.service.d/custom_args.conf

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Katie Hargrave - bricolage bumper.

Haveged : ajouter de l'entropie à son VPS Linux

EntropyEntre deux bidouilles NetBSD, je me suis retrouvé à des bidouilles Linux. Plus particulièrement en jetant un œil à une certaine documentation utile, j'ai pu lire :

Les clés doivent être générées dans un contexte où la source d’aléa est fiable, ou à défaut dans un environnement où suffisamment d’entropie a été accumulée.

Et là, on commence à se poser des questions : qu'est-ce que l'entropie ? Pourquoi faut-il une source fiable ? Comment avoir une meilleure entropie ?

Entropie et aléa

Pour résumer, disons que l'entropie c'est la qualité de la génération de nombres aléatoires. C'est un raccourci assez grossier j'en conviens, mais cela évitera d'écrire ou de paraphraser des pavés mathématiques.

Mais alors, pourquoi générer des nombres aléatoires ? Tout simplement parce que cela fait partie de nombreuses bases d'outils cryptographiques, comme par exemple la génération de clés SSH. C'est d'ailleurs l'occasion d'aborder la question du risque qu'on prend si on ne génère pas assez d'aléa dans notre exemple : il devient possible de générer deux fois le même couple de clés SSH, et par conséquent, que quelqu'un soit en mesure de se connecter à une machine à laquelle il ne devrait pas avoir accès.

Si vous pensez que cela n'arrive jamais, il suffit de se rappeler la vulnérabilité OpenSSH Debian. En 2008, la version Debian d'OpenSSL s'est trouvée modifiée, et a eu pour conséquence un très faible nombre de possibilités pour générer des clés SSH. La preuve ? On peut trouver sur cette page l'intégralité des clés DSA (1024 et 2048 bits) et RSA (1024 à 4096 bits) possibles via cette version vulnérable. J'admets volontiers que c'est un cas extrême, mais il a le mérite d'être assez parlant.

Bref, tout ça pour dire que plus on a d'entropie, mieux c'est.

Mesurer la qualité de l'entropie

Pour mesurer la qualité de l'entropie, c'est très simple :

$ cat /proc/sys/kernel/random/entropy_avail
175

On voit que cela renvoie un nombre, qui désigne la quantité de nombres aléatoires générés. On dit que ce nombre est la taille de notre réservoir d'entropie. Et donc, plus il est grand, mieux c'est. Sauf que là, 175 sur une VM Vagrant CentOS 7, bein c'est pas glorieux.

Une autre manière de mesurer l'entropie consiste à utiliser l'outil rngtest (disponible dans le paquet rng-tools pour CentOS). Celui-ci va lancer un certain nombre de tests utilisant le standard FIPS-140.

Par exemple :

$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 96
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=0.000; avg=0.000; max=0.000)bits/s
rngtest: FIPS tests speed: (min=0.000; avg=0.000; max=0.000)bits/s
rngtest: Program run time: 21307295 microseconds

Et là, ce n'est toujours pas glorieux, car j'ai arrêté l'exécution faute de patience.

Avant de remédier à ce problème, comparons avec une machine physique notre premier indicateur :

$ cat /proc/sys/kernel/random/entropy_avail
3217

On peut aussi constater que le problème d'entropie affecte particulièrement les machines virtuelles. Cela s'explique surtout par le fait qu'elles disposent de beaucoup moins d'éléments qu'une machine physique, et donc moins d'éléments à lire pour espérer y trouver de l'aléa.

Bon, ce n'est pas tout, mais il est temps de remédier à ce problème d'entropie sur cette VM !

Haveged : générateur d'entropie en espace utilisateur

Haveged est un logiciel qui se présente sous la forme d'un démon qui reste en espace utilisateur. Il tire son nom de l'algorithme qu'il utilise, HAVEGE (HArdware Volatile Entropy Gathering and Expansion).

Côté installation, rien de plus simple, il suffit, pour CentOS, d'avoir accès au dépôt Fedora EPEL. Une fois que c'est fait, un simple yum -y install haveged suffit à disposer du logiciel.

Comme il s'agit d'un démon, il faut le démarrer. Sous CentOS 7, cela se fait via systemd :

# systemctl start haveged.service

Et voilà ! Bon d'accord, cela fait peu. Maintenant, vérifions que notre entropie augmente :

$ cat /proc/sys/kernel/random/entropy_avail
 1779

Voilà qui est mieux. Vérifions aussi avec rngtest :

$ cat /dev/random | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.057; avg=17.351; max=25.915)Mibits/s
rngtest: FIPS tests speed: (min=44.564; avg=139.836; max=161.640)Mibits/s
rngtest: Program run time: 1237535 microseconds

Dans ce dernier cas, la récupération des informations fut quasi-instantanée ! On peu d'ailleurs noter le nombre de tests réalisés avec succès, qui correspond mieux à nos attentes.

Pour ce qui est d'activer haveged au démarrage, il ne faut pas oublier la commande systemctl qui va bien :

# systemctl enable haveged.service
 Created symlink from /etc/systemd/system/multi-user.target.wants/haveged.service to /usr/lib/systemd/system/haveged.service.

Selon les distributions, certains paramètres supplémentaires sont accessibles, mais cela fera l'objet d'un autre article ;)

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : teatimer - Entropy

Xen : installation d'un invité domU NetBSD

the handlerDans le billet précédent, j'ai abordé la création d'un hyperviseur Xen (dom0) NetBSD. Il est donc temps de s'occuper du système invité NetBSD, le domU.

Création du domU Xen

Pour créer notre domU, nous avons besoin de 3 éléments présents sur le dom0 :

  • un fichier de disque dur (on pourrait utiliser LVM ou une partition, mais cela est moins flexible) ;
  • dans le cas de NetBSD, un fichier de noyau ;
  • et un fichier de configuration.

D'abord, le fichier de disque dur. Pour le créer, il suffit d'utiliser la commande dd. La taille de ce fichier déterminera la taille du disque dur de la machine virtuelle. Créons un fichier de 4 Go (4096 blocs d'1 Mo) :

root@rogue:~# dd if=/dev/zero of=/srv/xen/images/disk/netbsd.img bs=1m count=4096

On peut remarquer que cet exemple remplit notre fichier de zéros, et ne crée pas de fichier sparse. Il semble que la gestion des fichiers sparse ne soit pas parfaite sous NetBSD, d'après le tutoriel officiel.

Ensuite, récupérons les fichiers noyau :

root@rogue:~# mkdir -p /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:~# cd /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-XEN3_DOMU.gz

On récupère deux fichiers de noyau, car l'un d'entre eux ne sert que pour l'installation. Une fois celle-ci terminée, il faut penser à configurer notre domU avec le noyau "classique".

Nous pouvons enfin créer notre fichier de configuration, /usr/pkg/etc/xen/netbsd :

root@rogue:/usr/pkg/etc/xen# grep -v ^# netbsd | grep -v ^$
name = "netbsd"
uuid = "d0f3e8d3-2f54-11e7-b035-00301bbde894"
kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 256
vcpus = 1
vif = [ 'bridge=bridge0,mac=00:16:3E:00:00:02' ]
disk = [ '/srv/xen/images/disk/netbsd.img,raw,xvda,rw' ]

Les directives du fichier de configuration sont assez explicites, néanmoins il convient de préciser certaines choses :

  • d'abord, le nom de la machine virtuelle ("name") doit être unique ;
  • et en passant, l'uuid aussi (généré via uuidgen), mais il n'est pas obligatoire, la directive peut être vide ;
  • la mémoire est spécifiée en méga-octets ;
  • on peut spécifier plusieurs interfaces réseau ou disques durs.

On peut ajouter bien d'autres options, mais il est préférable de commencer par un fichier simple, qui démarrera une machine en mode texte, avant d'aller plus loin.

Maintenant que notre fichier de configuration est prêt, démarrons notre domU :

root@rogue:/usr/pkg/etc/xen# xl create -c netbsd

L'option -c permet d'attacher la console locale de la machine virtuelle en mode texte, et donc de pouvoir interagir avec (pour, par exemple, effectuer une installation).

Installation de NetBSD dans le domU

L'installation se passe de manière similaire à ce qui est présenté dans le guide officiel, mais à une différence près : une fois l'installation terminée, il faut quitter l'installeur (au lieu de redémarrer), puis éteindre la machine virtuelle :

# shutdown -p now

De retour dans le dom0, il faut alors changer le fichier de noyau pour un démarrage "classique" :

root@rogue:/usr/pkg/etc/xen# vi netbsd
kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-XEN3_DOMU.gz"

On peut ensuite démarrer notre machine virtuelle, dans l'exemple suivant sans attacher la console locale de celle-ci :

root@rogue:/usr/pkg/etc/xen# xl create netbsd

On est vraiment obligé de spécifier sur le noyau ?

Dans le domU d'exemple du billet précédent, le système OpenWrt était démarré grâce à pygrub, un chargeur de démarrage pour Xen. Celui-ci n'est hélas pas capable de lire le système de fichiers FFS utilisé par NetBSD. Cela n'est pas non plus possible pour pv-grub, qui n'est de toute façon pas disponible dans les paquets Xen pkgsrc.

Quelles sont alors les possibilités ? La première consiste à créer une partition /boot en ext2/3/4 au début du disque virtuel, et d'y placer noyau et configuration Grub, comme l'indique ce tutoriel. Une autre consiste à compiler soi-même une version de Grub2, qui semble maintenant gérer Xen, tout du moins d'après ce billet du blog officiel Xen, daté de janvier 2015.

Autres actions possibles

Démarrer sa machine virtuelle, c'est bien, pouvoir effectuer d'autres actions et vérifications, c'est mieux ! Voici donc, en vrac, quelques commandes utiles pour gérer ses domU :

  • xl shutdown <chemin vers le fichier de configuration> permet d'arrêter proprement celui-ci ;
  • besoin d'appuyer sur le bouton Off comme un gros barbare ? xl destroy <nomdudomU> ;
  • lister les domU en fonctionnement : xl list ;
  • et pour avoir cette liste en temps réel, présentée à la manière d'un top, on peut utiliser xl top.

D'autres commandes et paramètres sont disponibles dans la page de manuel de la commande xl.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : ColonelMustard - the handler''

Xen : installation d'un hyperviseur dom0 NetBSD

ArmyJ'ai écrit dans le passé quelques billets concernant Xen, mais jamais sur l'installation à proprement parler d'un hyperviseur Xen à base de NetBSD. Il est temps de réparer cela ! Mais avant de commencer, quelques rappels :

  • en terminologie Xen, chaque système invité se nomme un "domaine" ;
  • une machine virtuelle est un domaines non-privilégié, en anglais "unprivileged domain", généralement raccourci en "domU" ;
  • l'OS qui fait fonctionner l'hyperviseur est un domaine privilégié, en anglais "privileged domain", ce qui donne en raccourci "dom0".

Il s'agit donc de détailler l'installation et la configuration de Xen en tant que dom0 sur un système NetBSD amd64. Pour valider son bon fonctionnement, une installation rapide d'un domU OpenWrt sera effectuée à la fin.

Mais avant de démarrer, voici quelques informations sur la configuration qui sera effectuée :

  • comme la machine physique ne dispose pas des instructions de virtualisation (Intel Atom 330), seul le mode "paravirtuel" sera abordé ;
  • la machine physique se verra attribuer 256 Mo de RAM sur ses 2 Go pour son fonctionnement ;
  • la configuration réseau sera en mode "bridge", le dom0 et les domU seront donc sur le même réseau.

Allons-y !

Installation et configuration de NetBSD

Commençons par l'installation du système d'exploitation : NetBSD 7.1 amd64. Il n'y a rien en particulier à signaler sur l'installation, cela dépend avant tout de son usage. Cette machine n'étant pas destinée à devenir un environnement de production, j'ai choisi un partitionnement minimal, à savoir juste un / qui prend tout le disque.

A noter aussi qu'à ce moment, il n'y a besoin de rien en particulier concernant le noyau. J'ai pris l'habitude de ne pas installer les sets de compilation ou source sur une machine sauf si j'en ai expressément besoin. Donc, je me suis limité aux sets suivants :

  • base ;
  • etc ;
  • man ;
  • misc ;
  • modules ;
  • tests ;
  • text ;
  • xbase.

Côté réseau, il sera sans doute plus simple de configurer une adresse IP statique. On va aussi dès maintenant configurer le bridge :

root@rogue:~# cat > /etc/ifconfig.bridge0 
create
!brconfig $int add re0 up

A noter que l'interface de la machine physique est re0, il convient de la modifier selon celle disponible. On va aussi autoriser la retransmission de paquets réseau :

root@rogue:~# cat >> /etc/sysctl.conf
net.inet.ip.forwarding=1

Ces modifications seront prises en compte au prochain démarrage du système, qu'il convient de faire dès maintenant.

Pour les paquets logiciels, j'ai choisi d'utiliser mon propre dépôt pkgsrc de paquets binaires. Là aussi, rien d'exceptionnel, j'ai juste installé mon petit confort personnel. Il est néanmoins possible d'utiliser le dépôt binaire pkgsrc officiel (configuré lors de l'installation) ou d'utiliser pkgsrc depuis les sources.

Installation et configuration de Xen 4.6

Maintenant que notre système est installé et prêt, passons à l'installation de Xen. Rien de compliqué non plus à ce niveau, il suffit d'utiliser pkgin :

root@rogue:~# pkgin in xenkernel46 xentools46

Des messages seront affichés durant l'installation des différents paquets, montrant un certain nombre de messages de conseils et de recommandations.

Pour que Xen fonctionne, il faut d'abord démarrer un noyau spécialisé qui chargera de lancer l'hyperviseur. Le noyau NetBSD dom0 est disponible à côté du noyau générique sur les dépôts :

root@rogue:~# wget http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-XEN3_DOM0.gz
root@rogue:~# mv netbsd-XEN3_DOM0.gz /

Configurons maintenant le chargeur de démarrage. Il suffit d'insérer la ligne suivante au début du fichier /boot.cfg :

menu=Xen:load /netbsd-XEN3_DOM0.gz console=pc;multiboot /usr/pkg/xen46-kernel/xen.gz dom0_mem=256M

Parmi les détails de cette ligne de configuration, on remarquera l'allocation de 256 Mo de mémoire vive pour le dom0.

Par contre, si jamais le partitionnement prévoit un /usr séparé, il vaudra mieux copier /usr/pkg/xen46-kernel/xen.gz dans / et de remplacer les chemins en accord avec la nouvelle localisation du fichier. Une fois que le chargeur de démarrage est modifié, un redémarrage est nécessaire, mais juste avant on peut créer les fichiers spéciaux dans /dev :

root@rogue~# cd /dev && sh MAKEDEV xen

Maintenant on peut redémarrer :)

Mais tout n'est pas encore prêt. Par exemple, le service xencommons doit être activé et démarré. On ajoute alors la ligne suivante au fichier /etc/rc.conf :

xencommons=YES

On peut ensuite lancer le service :

root@rogue~# service xencommons start

Il y a encore un fichier de configuration à modifier avant de commencer à faire joujou avec nos machines (para-)virtuelles : /usr/pkg/etc/xl.conf. Je n'ai fait que deux modifications à ce fichier :

root@rogue:~# grep -v ^# /usr/pkg/etc/xen/xl.conf | grep -v ^$
vif.default.script="vif-bridge"
vif.default.bridge="bridge0"

Il est temps d'effectuer rapidement un test de domU !

Test d'un domU OpenWrt

Un moyen de tester rapidement le fonctionnement de son dom0 Xen est d'utiliser un domU OpenWrt : il s'agit en effet d'un OS léger, non seulement d'un point de vue processeur et mémoire, mais aussi d'un point de vue espace disque. Au moment de la rédaction de cet article, la dernière version stable d'OpenWrt est la 15.05.1 et porte le nom de Chaos Calmer.

Deux éléments sont nécessaires : un fichier qui sera le disque dur de la machine virtuelle, et un fichier de configuration. Dans le premier cas c'est très simple, il suffit d'aller le récupérer sur le site d'OpenWrt, de le placer dans un répertoire, et de le décompresser :

root@rogue:~# mkdir -p /srv/xen/images/disk
root@rogue:~# cd /srv/xen/images/disk
root@rogue:/srv/xen/images/disk# wget https://downloads.openwrt.org/latest/x86/xen_domu/openwrt-15.05.1-x86-xen_domu-combined-ext4.img.gzroot@rogue:/srv/xen/images/disk# zcat openwrt-15.05.1-x86-xen_domu-combined-ext4.img.gz > openwrt.img

Continuons avec le fichier de configuration, basé sur un fichier d'exemple. Il doit se trouver dans /usr/pkg/etc/xen/, et se nomme tout simplement openwrt :

name = "openwrt"
uuid = "26824417-2dde-11e7-a2aa-00301bbde894"
bootloader = "/usr/pkg/bin/pygrub"
extra = "root=/dev/xvda2 rw"
memory = 128
vcpus = 1
vif = [ 'bridge=bridge0,mac=00:16:3E:00:00:01' ]
disk = [ '/srv/xen/images/disk/openwrt.img,raw,xvda,rw' ]

Maintenant que tout cela est en place, il ne reste plus qu'à lancer la machine virtuelle :

root@rogue:~# xl create -c /usr/pkg/etc/xen/openwrt

Une fois OpenWrt démarré, il suffit alors d'appuyer sur la touche entrée pour activer la console locale. Côté tests, il faut vérifier le nombre de processeurs (dans /proc/cpuinfo, il doit n'y en avoir qu'un), ainsi que la quantité de mémoire vive (dans /proc/meminfo, ou via free -m, on doit avoir 128 Mo). Si un serveur DHCP est présent, on peut facilement tester le réseau via udhcpc :

root@OpenWrt:/# udhcpc -i br-lan

On peut désormais vérifier que le réseau est bien connecté.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Marcos Leal - Army

Vlog épisode 0 : changement de boitier du NAS

p1020274.jpgAujourd'hui, un article un peu particulier, car il s'agit de signaler la publication de mon premier vlog ! L'idée de passer à la vidéo me trotte dans la tête depuis quelques temps, et j'ai saisi l'occasion de ce projet de changement du boitier de mon NAS pour passer à la réalisation. Pour voir la vidéo, c'est ici :

Le NAS, cette bonne excuse

Dans cette première vidéo, je démonte mon NAS existant afin de remplacer mon boitier. Plusieurs raisons ont poussé ce changement :

  • d'abord, l'ancien boitier manque de place, m'empêchant de disposer de six disques durs 3,5 pouces ;
  • de plus, je voulais passer à un boitier au format rackable 19 pouces, exploitant au mieux la place disponible pour le NAS (une table IKEA Lack) ;
  • enfin, l'ancien boitier ne permet d'installer au mieux qu'une carte mère micro-ATX, ce qui limite l'évolutivité.

J'en ai profité pour faire le ménage de printemps, c'est-à-dire faire les poussières, et changer la pâte thermique sur le processeur. Afin de mieux prévoir mes besoins futurs en stockage et services sur le NAS, j'ai aussi ajouté de la mémoire vive. Le moins qu'on puisse dire, c'est que FreeNAS en a tout de suite profité !

Les composants utilisés pour cette machine ne sont pas de première jeunesse, le NAS ayant déjà deux ans de service, je crois :

Côté logiciel, l'OS installé est FreeNAS.

D'autres vidéos ?

J'espère que vous apprécierez cette vidéo au moins autant que j'ai apprécié de la tourner. Bien sûr, c'est un premier jet, et j'espère à l'occasion d'autres vidéos m'améliorer sur certains points (euh... si si, vraiment !) Comme il s'agit pour l'instant plus d'une expérimentation que d'un véritable engagement à faire des vidéos, dans l'immédiat ce premier vlog n'est disponible que sur Youtube. Selon la demande, les vidéos seront disponibles en téléchargement direct. J'admets que ce faisant, je "nourris" un peu plus l'une des grosses sociétés d'Internet avec mes données, mais c'est aussi un moyen d'aller chercher une audience.

Enfin, tout ceci ne serait pas possible sans le Studio Cyanotype ! Merci à elle d'avoir filmé et monté cette vidéo ! N'hésitez pas à aller voir sa chaine Youtube et son blog !

Crédit Photo : Vincent Battez - P1020274

PHP Malware Finder : gestion des listes blanches

Lime &amp; List

Rappelez-vous : dans le billet précédent, nous avons découvert PHP Malware Finder. Aujourd'hui, allons plus loin et passons à la gestion des listes blanches ! Pour cela, prenons l'exemple d'un blog fonctionnant sous Wordpress. Cette gestion des listes blanches se fera en trois étapes :

  • tout d'abord, il s'agit de faire un état de l'existant, en exécutant PHP Malware Finder et en observant des faux-positifs ;
  • ensuite, la deuxième étape sera de comprendre le fonctionnement des règles et des listes blanches ;
  • enfin, la troisième étape consistera à générer la liste blanche et à l'intégrer dans les règles existantes.

Et pour finir, en bonus, un script de génération de liste blanche sera abordé. Au moment de l'écriture de cet article, la dernière version de Wordpress est la 4.7.3. La dernière version de PHP Malware Finder est la 0.3.4.

Exécution de PHP Malware Finder sur un site de test

Nous allons donc commencer par récupérer une archive de Wordpress directement sur le site officiel, afin de s'assurer qu'elle est saine :

nils@Dalaran:~/tmp$ wget https://wordpress.org/wordpress-4.7.3.tar.gz
--2017-04-11 21:54:31--  https://wordpress.org/wordpress-4.7.3.tar.gz
Résolution de wordpress.org… 66.155.40.250, 66.155.40.249
Connexion à wordpress.org|66.155.40.250|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 8008833 (7,6M) [application/octet-stream]
Sauvegarde en : « wordpress-4.7.3.tar.gz »

wordpress-4.7.3.tar.gz                                      100%[=========================================================================================================================================>]   7,64M  3,27MB/s    ds 2,3s    

2017-04-11 21:54:34 (3,27 MB/s) — « wordpress-4.7.3.tar.gz » sauvegardé [8008833/8008833]

nils@Dalaran:~/tmp$ tar -xzf wordpress-4.7.3.tar.gz

Puis, décompressons-la et scannons son contenu :

nils@Dalaran:~/tmp$ cd wordpress
nils@Dalaran:~/tmp/wordpress$ phpmalwarefinder .
ObfuscatedPhp ./wp-admin/includes/class-ftp.php
DodgyStrings ./wp-admin/includes/ajax-actions.php
ObfuscatedPhp ./wp-admin/includes/class-wp-plugins-list-table.php
DodgyPhp ./wp-admin/includes/schema.php
ObfuscatedPhp ./wp-admin/includes/media.php
DodgyStrings ./wp-admin/includes/template.php
ObfuscatedPhp ./wp-admin/includes/template.php
DodgyStrings ./wp-admin/includes/upgrade.php
ObfuscatedPhp ./wp-includes/bookmark-template.php
DodgyPhp ./wp-includes/class-pop3.php
DodgyStrings ./wp-includes/class-phpmailer.php
DodgyPhp ./wp-includes/class-phpmailer.php
ObfuscatedPhp ./wp-includes/class-wp-meta-query.php
ObfuscatedPhp ./wp-includes/class-wp-tax-query.php
DodgyStrings ./wp-includes/class-wp-query.php
DodgyStrings ./wp-includes/comment.php
ObfuscatedPhp ./wp-includes/date.php
DodgyStrings ./wp-includes/deprecated.php
ObfuscatedPhp ./wp-includes/deprecated.php
DodgyStrings ./wp-includes/functions.php
DodgyPhp ./wp-includes/functions.php
DangerousPhp ./wp-includes/functions.php
DodgyStrings ./wp-includes/formatting.php
ObfuscatedPhp ./wp-includes/IXR/class-IXR-date.php
DodgyPhp ./wp-includes/load.php
DodgyStrings ./wp-includes/media.php
ObfuscatedPhp ./wp-includes/post-template.php
ObfuscatedPhp ./wp-includes/js/tinymce/tinymce.min.js
DodgyStrings ./wp-includes/post.php
ObfuscatedPhp ./wp-includes/SimplePie/Parse/Date.php

Certains fichiers sont présentés comme malveillants, mais il n'en est rien : ce sont donc des faux-positifs. Il faut donc les mettre en liste blanche, mais avant, il convient de comprendre où sont les signatures et cette liste blanche.

Signatures et listes blanches

PHP Malware Finder est basé sur YARA, un outil qui recherche des fichiers selon certains critères, comme la présence d'une chaîne de caractères, ou une expression rationnelle. Les signatures sont définies dans les fichiers asp.yar, common.yar et php.yar. On comprend alors qu'un fichier est dédié aux fichiers ASP, un autre aux fichiers PHP, et le troisième regroupe des signatures communes aux deux langages.

Passons ensuite à la lecture des fichiers asp.yar et php.yar : on voit assez vite que pour qu'un fichier soit reconnu comme malveillant, il doit non seulement remplir certaines conditions (les règles définies), mais il doit aussi ne pas remplir les conditions des fichiers de liste blanche.

En fait, les fichiers de liste blanche sontdes sommes de contrôle SHA1 de la taille des fichiers considérés comme faux-positifs. Allons maintenant à la création du fichier contenant ces informations !

Création du fichier de liste blanche

Pour ajouter nos faux-positifs en liste blanche, nous allons avoir besoin de deux choses :

  • d'abord, python-yara, une bibliothèque qui permet d'accéder à yara depuis Python ;
  • ensuite un script, generate_whitelist.py, qui se trouve être écrit... en Python.

Ce script est disponible dans le répertoire utils de PHP Malware Finder, ou bien dans ${PREFIX}/share/php-malware-finder/utils/ s'il est installé depuis pkgsrc (${PREFIX} dépendant de l'installation de pkgsrc).

Testons donc ce script sur notre répertoire wordpress :

nils@Dalaran:~/tmp/php-malware-finder/php-malware-finder/utils$ /opt/pkg/bin/python2.7 ./generate_whitelist.py ma_liste_blanche ~/tmp/wordpress

Le résultat est alors ressemblant à celui-ci :

import "hash"

private rule maListeblanche
{
    condition:
        /* maListeblanche */
        hash.sha1(0, filesize) == "12a18329072bed94b6f9c4d9f16d7a079ca64655" or // /Users/nils/tmp/wordpress/wp-admin/includes/ajax-actions.php
        hash.sha1(0, filesize) == "6bccf04c8b46c8d6cdf79db8b509f4b76689f3bf" or // /Users/nils/tmp/wordpress/wp-admin/includes/class-ftp.php
        hash.sha1(0, filesize) == "aa6a12a0325056b9649f58f8072fa02a1e264551" or // /Users/nils/tmp/wordpress/wp-admin/includes/class-wp-plugins-list-table.php
        hash.sha1(0, filesize) == "3e73204644f0ce7b0971aad885fdcbcabba629fc" or // /Users/nils/tmp/wordpress/wp-admin/includes/media.php
        hash.sha1(0, filesize) == "81b1ae432ba765a43c6d81fb6d6c35ce72efd0e8" or // /Users/nils/tmp/wordpress/wp-admin/includes/schema.php
        hash.sha1(0, filesize) == "2ef50e790fdd42daa8ccd64d4c7c4be75d21742d" or // /Users/nils/tmp/wordpress/wp-admin/includes/template.php
        hash.sha1(0, filesize) == "9835d10a7561deeef1f8381da065b4b45d7f2662" or // /Users/nils/tmp/wordpress/wp-admin/includes/upgrade.php
        hash.sha1(0, filesize) == "b92aefa2917fc319ca7ceab092e183cafc651a6d" or // /Users/nils/tmp/wordpress/wp-includes/bookmark-template.php
        hash.sha1(0, filesize) == "cb0c5a355409d807202bbf52749a3e74a9967a6a" or // /Users/nils/tmp/wordpress/wp-includes/class-phpmailer.php
        hash.sha1(0, filesize) == "e4f0694bc96f99d5e30201171a3e7fc86e9e5ae4" or // /Users/nils/tmp/wordpress/wp-includes/class-pop3.php
        hash.sha1(0, filesize) == "c06a15f4869c5459a782b714572eacea5c82d570" or // /Users/nils/tmp/wordpress/wp-includes/class-wp-meta-query.php
        hash.sha1(0, filesize) == "72dbc1d4f2bbc8efdcdd834ecaf3771cbf17f64e" or // /Users/nils/tmp/wordpress/wp-includes/class-wp-query.php
        hash.sha1(0, filesize) == "348c3a60d99768041be690b65b008628f53badb7" or // /Users/nils/tmp/wordpress/wp-includes/class-wp-tax-query.php
        hash.sha1(0, filesize) == "0aab95245b9668f954151f4312b678fb0ee798cf" or // /Users/nils/tmp/wordpress/wp-includes/comment.php
        hash.sha1(0, filesize) == "c8c9182aa25fb92ca91fcc96c3419847acdcf6e0" or // /Users/nils/tmp/wordpress/wp-includes/date.php
        hash.sha1(0, filesize) == "5877695771fbe7a5667f4a06f4d897a37ef3fceb" or // /Users/nils/tmp/wordpress/wp-includes/deprecated.php
        hash.sha1(0, filesize) == "806d2872676ea22e0a6fa6b32fbd4652298023ee" or // /Users/nils/tmp/wordpress/wp-includes/formatting.php
        hash.sha1(0, filesize) == "3083b9a58e76d42455935811a457f29f57620145" or // /Users/nils/tmp/wordpress/wp-includes/functions.php
        hash.sha1(0, filesize) == "f53f80c4ee7446f0b605443b6d2f05acd8064d13" or // /Users/nils/tmp/wordpress/wp-includes/load.php
        hash.sha1(0, filesize) == "bea5ea598f537e7acb20b77a1421f819c0a9ec75" or // /Users/nils/tmp/wordpress/wp-includes/media.php
        hash.sha1(0, filesize) == "abcf1a0801694db4774cd2abb29b5392e10dd632" or // /Users/nils/tmp/wordpress/wp-includes/post-template.php
        hash.sha1(0, filesize) == "5ddc1e5c5c6302211b1aecbf930f76417b65d678" or // /Users/nils/tmp/wordpress/wp-includes/post.php
        hash.sha1(0, filesize) == "040ef40d245242723de200e494a27545ea0b121b" or // /Users/nils/tmp/wordpress/wp-includes/IXR/class-IXR-date.php
        hash.sha1(0, filesize) == "086986cdf03ede58494034661d38c4842af38fe3"    // /Users/nils/tmp/wordpress/wp-includes/SimplePie/Parse/Date.php
}

Il faut ensuite ajouter la règle générée à l'instant aux listes blanches déjà présentes. Pour aller vite, on peut directement éditer le fichier whitelist.yar et ajouter notre règle juste avant la dernière (IsWhitelisted). Il ne faut donc pas oublier d'ajouter dans cette dernière règle celle qu'on vient de créer. Dans mon cas, la dernière règle ressemble à cela :

private rule IsWhitelisted
{
    condition:
        Symfony or
        Wordpress or
        Prestashop or
        Magento or
        Magento2 or
        Drupal or
        Roundcube or
        Concrete5 or
        Dotclear or
        Owncloud or
        Phpmyadmin or
        Misc or
        maListeblanche
}

Vérifions maintenant que la liste blanche est bien à jour et assurons-nous qu'il n'y a plus de faux-positif dans notre répertoire :

nils@Dalaran:~/tmp/wordpress$ phpmalwarefinder ./
ObfuscatedPhp .//wp-includes/js/tinymce/tinymce.min.js

Et là, c'est le drame. Mais pourquoi ? En fait, c'est parce que le script utilisé à l'instant ne prend en compte que les fichiers PHP. Cela peut être une idée d'amélioration pour une version future.

Création facile de liste blanche pour divers logiciels PHP

Il existe un autre script fort utile : mass_whitelist.py. Son but est de faciliter la création de liste blanche pour des applications PHP connues, cela va de Wordpress à Drupal en passant par PHPMyAdmin. Il suffit de lui donner en argument le nom de l'application, l'URL de téléchargement (en remplaçant le numéro de version avec version), ainsi que les numéros de version mineurs et majeurs à rechercher.

Ce script va alors rechercher toutes les versions de l'application, les télécharger, et afficher une liste blanche les prenant toutes en compte. Par exemple, pour Wordpress :

nils@Dalaran:~/tmp/php-malware-finder/php-malware-finder/utils$ /opt/pkg/bin/python2.7 mass_whitelist.py wordpress https://wordpress.org/wordpress-__version__.tar.gz 4 7 3 | tee -a wordpress.yar

Le fichier de résultat se nomme donc wordpress.yar. Il suffira alors de le copier dans le répertoire de règles (et écraser le précédent) afin de le prendre en compte. Attention, car ce script est long, très long !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit Photo : List_84 - Lime & List

PHP Malware Finder : détecteur d'intrusion sur site PHP

Dans ma loupe - 2Lors des RMLL de Beauvais en 2015, j'ai eu l'occasion de voir une conférence présentant au passage un outil fort sympathique nommé PHP Malware Finder (site web). Le but de ce script est de détecter du code PHP qui semble obfusqué ou malveillant, voire même des fonctions trouvées généralement dans des malwares ou des webshells. On trouve, sur la page du projet, une liste (non exhaustive) des malwares qu'il est capable de trouver.

PHP Malware Finder scanne un répertoire pour trouver les malwares, on peut donc choisir de l'utiliser directement sur son serveur, soit depuis son ordinateur en ayant au préalable copié les fichiers de son site. La première option nécessitera les droits administrateurs pour les dépendances, il vaut mieux donc choisir la deuxième option pour la découverte de cet outil, et aussi parce qu'il est assez gourmand en accès disque.

Installer PHP Malware Finder

Son installation et utilisation sont simples, pourvu que YARA soit installé. Sur une distrbution Linux classique, une fois YARA installé, il suffit d'installer PHP Malware Finder en clonant le dépôt Github :

git clone https://github.com/nbs-system/php-malware-finder.git

Le script phpmalwarefinder se trouve dans le répertoire php-malware-finder/php-malware-finder/.

Il est par contre possible, sur un système NetBSD ou macOS, de l'installer facilement via pkgsrc-wip :

cd /usr/pkgsrc/wip/
make package-install

Avec cette manière, PHP Malware Finder est disponible directement dans $PATH :)

Utilisation

Il suffit maintenant de le lancer en spécifiant un endroit où il y a des pages PHP :

$ phpmalwarefinder /chemin/vers/ses/pages/

Si certains fichiers semblent réagir aux signatures, alors le script affichera le type de problème ainsi que le chemin du fichier. Sinon, il n'affiche rien. Bien sûr, d'autres options sont disponibles, et un résumé de celles-ci est disponible via l'option -h :

$ phpmalwarefinder -h
Usage phpmalwarefinder [-cfhtvl] <file|folder> ...
-c  Optional path to a configuration file
-f  Fast mode
-h  Show this help message
-t  Specify the number of threads to use (8 by default)
-v  Verbose mode
-l  Set language ('asp', 'php')
-L  Check long lines
-u  update rules

Par défaut, PHP Malware Finder va chercher ses signatures dans son répertoire (si utilisé depuis un clone du dépôt git), mais le paquet pkgsrc va les chercher dans /usr/pkg/etc/phpmalwarefinder/ (ou /opt/pkg/ pour macOS). Il est possible de préciser ses propres signatures via l'option -c.

D'autres options sont aussi très intéressantes, comme -f (pour accélérer le scan), ou -t qui permet de limiter le nombre de threads à utiliser en parallèle. Cela peut s'avérer très pratique dans le cas où le scan prend du temps et on veut continuer à utiliser sa machine pendant ce temps. Au passage, une recommandation : il vaut mieux éviter de lancer PHP Malware Finder directement sur son serveur, il a tendance à être assez gourmand en ressources !

Si vous aimez cet article, partagez-le sur les réseaux sociaux. Si vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Olivier Penet - Dans ma loupe-2

curl : utiliser une version plus récente sur macOS

Le système macOS dispose en standard de curl. Mais ce binaire n'est pas forcément dans une version assez récente, ou alors certaines options ne sont pas compilées.

Installation de curl par pkgin

Nous allons, grâce à pkgsrc, installer une autre version, sans toucher à celle installée par défaut. Pour cela, le prérequis est de suivre mon tutoriel pour installer pkgsrc. Une fois que c'est fait, une commande suffit :

sudo pkgin in curl

Comme vu dans les billets précédents, installer un logiciel grâce à pkgin est très simple. En plus, si la variable d'environnement $PATH définit l'emplacement des programmes issus de pkgsrc avant ceux du système, la prochaine invocation de curl dans le terminal sera celle que nous venons d'installer.

Mais il se peut qu'on ait besoin de plus : par exemple, ajouter ou retirer des options de compilation. Passons donc à une autre méthode d'installation, via les sources.

Installation de curl par compilation des sources

Tout d'abord, comparons les versions et les options de compilation :

nils@dalaran-wifi:~$ /usr/bin/curl -V
curl 7.51.0 (x86_64-apple-darwin16.0) libcurl/7.51.0 SecureTransport zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets
nils@dalaran-wifi:~$ /opt/pkg/bin/curl -V
curl 7.53.1 (x86_64-apple-darwin13) libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.8 libssh2/1.8.0 nghttp2/1.20.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy

Une option dont on a besoin n'est pas présente ? Ce n'est pas grave, car on peut l'ajouter. L'étape suivante consiste à lister les options disponibles :

    nils@dalaran-wifi:/opt/pkgsrc/www/curl$ bmake show-options
    Any of the following general options may be selected:
    gssapi     Enable gssapi (Kerberos V) support.
    http2     Add support for HTTP/2.
    inet6     Enable support for IPv6.
    ldap     Enable LDAP support.
    libidn     Add support for libidn text conversion.
    libssh2     Use libssh2 for SSHv2 protocol support.
    rtmp     Enable rtmp:// support using rtmpdump.

    These options are enabled by default:
    inet6 libidn

    These options are currently enabled:
    inet6 ldap libidn libssh2

    You can select which build options to use by setting PKG_DEFAULT_OPTIONS
    or PKG_OPTIONS.curl.

On peut alors éditer _/opt/pkg/etc/mk.conf.local_ (en tant que root, ou via _sudo_) et ajouter des options, comme par exemple http2 :

PKG_OPTIONS.curl+= http2

Et ensuite, on recompile :

nils@dalaran-wifi:/opt/pkgsrc/www/curl$ bmake package-install

L'étape d'après est de vérifier la présence de l'option http2 :

    nils@dalaran-wifi:/opt/pkgsrc/www/curl$ /opt/pkg/bin/curl -V
    curl 7.53.1 (x86_64-apple-darwin16) libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.8 libssh2/1.8.0 nghttp2/1.20.0
    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy

En conclusion, il est très simple, grâce à pkgsrc, de disposer d'une autre version de logiciel que celle installée par défaut, et de la compiler avec les options dont on a besoin.

Si vous aimez cet article, partagez-le sur les réseaux sociaux. Si vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Sysupgrade : mise à jour facile d'un système NetBSD

NetBSD 7.1 est disponible. Comme d'habitude, il est recommandé de mettre à jour son système, en particulier car cette version apporte de nombreux correctifs de sécurité.

Historiquement, mettre à jour son système NetBSD se fait via le logiciel d'installation, sysinst. Cependant, cette méthode a le principal désavantage de nécessiter de redémarrer sur l'installeur, et donc de rendre le système indisponible pendant toute la mise à jour.

Une deuxième possibilité consiste à décompresser soi-même les sets du système de base puis de lancer les commandes de post-installation, comme expliqué par exemple sur le wiki de GCU.

Cette deuxième possibilité, certes plus rapide, est automatisable, mais nécessite un peu d'intelligence, comme le fait de n'installer que les sets nécessaires, un noyau différent de GENERIC (surtout dans le cas où on compile soi-même un noyau personnalisé), voire même d'effacer son répertoire de téléchargement après coup. Et cela tombe bien, car c'est ce que fait sysupgrade ! A l'aide d'un simple fichier de configuration, celui-ci est capable de :

  • télécharger les sets d'une version précise de NetBSD ;
  • remplacer votre noyau par le nouveau, automatiquement, ou en spécifiant un nom de configuration ;
  • d'effectuer les tâches de post-installation ;
  • et même de faire le ménage à la fin !

Sysupgrade fait maintenant partie de la documentation officielle de mise à jour. Pour l'utiliser, idéalement, une commande suffit :

# sysupgrade auto http://cdn.NetBSD.org/pub/NetBSD/NetBSD-7.1/amd64

En ce qui me concerne, j'ai choisi de m'assurer que certaines options sont activées dans _/usr/pkg/etc/sysupgrade.conf_, en particulier car la commande _config_, qui permet de détecter le nom de la configuration du noyau, est disponible dans le set _comp_, que je n'installe pas systématiquement (ce dernier permet de disposer d'outils de développement et de compilation, que j'estime inutiles sur un serveur web par exemple). Mon fichier de configuration ressemble donc à ceci :

RELEASEDIR="http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/$(uname -m)"
KERNEL=GENERIC
ETCUPDATE=yes

Ma commande de mise à jour se résume donc à un simple sysupgrade auto. En revanche, la post-installation sera déclenchée et me demandera si je souhaite mettre à jour certains fichiers de configuration. Il convient donc d'être particulièrement attentif lors de cette étape.

Des remarques, des propositions d'améliorations ? Où même des exemples supplémentaires ? Les commentaires sont là pour ça !

Nmap : détection et récupération d'information sur Wordpress

Début mars 2017, le moteur de blog Wordpress a fait l'objet d'une nouvelle mise à jour, la version 4.7.3. Cette mise à jour revêt une certaine importance, puisqu'elle corrige 5 vulnérabilités !

Vérifier sur une installation de Wordpress que la dernière version est installée est assez simple à partir du moment où on peut se connecter à l'interface d'administration. Il se peut toutefois que cela ne soit pas envisageable : nombre d'installations, disponibilité des identifiants de connexion (pour des raisons d'organisation). Du fait de la verbosité par défaut de Wordpress, il est possible d'obtenir des informations sans posséder d'identifiants de connexion.

Pour réaliser cette vérification, faisons de nouveau appel à Nmap ! En effet, grâce à la disponibilité du langage de script NSE, il est possible de chercher plusieurs informations, comme la version. De manière générale, on peut voir la liste des scripts officiellement disponibles sur une page dédiée. Dans le cas qui nous intéresse, on notera la présence d'un dépôt contenant des scripts NSE personnalisés concernant Wordpress.

L'installation de scripts NSE dans Nmap est assez facile, il suffit de localiser les scripts existant et de copier les siens au même endroit. Par exemple, sur une Fedora 25 :

[nils@fedora-workstation ~]$ git clone https://github.com/peter-hackertarget/nmap-nse-scripts.git
Clonage dans 'nmap-nse-scripts'...
remote: Counting objects: 12, done.
remote: Total 12 (delta 0), reused 0 (delta 0), pack-reused 12
Dépaquetage des objets: 100% (12/12), fait.
Vérification de la connectivité... fait.
[nils@fedora-workstation ~]$ cd nmap-nse-scripts/
[nils@fedora-workstation nmap-nse-scripts]$ sudo cp -v wp-themes.lst /usr/share/nmap/nselib/
'wp-themes.lst' -> '/usr/share/nmap/nselib/wp-themes.lst'
[nils@fedora-workstation nmap-nse-scripts]$ sudo cp -v *.nse /usr/share/nmap/scripts/
'hostmap-hackertarget.nse' -> '/usr/share/nmap/scripts/hostmap-hackertarget.nse'
'http-wordpress-info.nse' -> '/usr/share/nmap/scripts/http-wordpress-info.nse'
'http-wordpress-plugins.nse' -> '/usr/share/nmap/scripts/http-wordpress-plugins.nse'
'http-wordpress-themes.nse' -> '/usr/share/nmap/scripts/http-wordpress-themes.nse'

Lançons alors un premier scan :

[nils@fedora-workstation ~]$ sudo nmap -sV -p80,443 --script http-wordpress-info exemple.fr

Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-20 09:46 CET
Nmap scan report for exemple.fr (10.172.46.128)
Host is up (0.0056s latency).
rDNS record for 10.172.46.128: www.exemple.fr
PORT    STATE SERVICE VERSION
80/tcp  open  http    Apache httpd
|_http-server-header: Apache
| http-wordpress-info: 
|   version: WordPress 4.7.3
|_  theme: twentyseventeen
443/tcp open  ssl/ssl Apache httpd (SSL-only mode)
|_http-server-header: Apache
| http-wordpress-info: 
|   version: WordPress 4.7.3
|_  theme: twentyseventeen

On dispose donc de la version de Wordpress, et du thème utilisé. Il est possible, grâce au script http-wordpress-themes, de chercher plus en profondeurs d'éventuels thèmes supplémentaires installés. Quant à http-wordpress-plugins, il permet de rechercher des plugins. Le script d'information est néanmoins assez verbeux. Voici son résultat après l'installation de quelques plugins et thèmes autres :

[nils@fedora-workstation ~]$ sudo nmap -sV -p80,443 --script http-wordpress-info exemple.fr

Starting Nmap 7.40 ( https://nmap.org ) at 2017-03-20 09:53 CET
Nmap scan report for exemple.fr (10.172.46.128)
Host is up (0.0058s latency).
rDNS record for 10.172.46.128: www.exemple.fr
PORT    STATE SERVICE VERSION
80/tcp  open  http    Apache httpd
|_http-server-header: Apache
| http-wordpress-info: 
|   version: WordPress 4.7.3
|   theme: fooding
|   plugins: 
|_    jetpack
443/tcp open  ssl/ssl Apache httpd (SSL-only mode)
|_http-server-header: Apache
| http-wordpress-info: 
|   version: WordPress 4.7.3
|   theme: fooding
|   plugins: 
|_    jetpack

On remarquera ici la présence du plugin bien connu Jetpack, ainsi que du thème fooding.

Jusqu'à maintenant, on a testé un script est assez gentil, mais d'autres sont plus brutaux, comme http-wordpress-brute qui cherche à obtenir un accès via bruteforce de l'interface d'administration. Il convient donc de faire très attention lors de l'utilisation de ces outils.

Des remarques, des propositions d'améliorations ? Où même des exemples intéressants sur certaines configurations de Wordpress ? Les commentaires sont là pour ça !

dmidecode : pour en savoir un peu plus sur son matériel

De nombreux outils libres de détection et d'information sur le matériel de son ordinateur existent. En vrac, lspci, lshw, et dmidecode. J'ai un peu mis le nez dans ce dernier récemment, et j'ai remarqué quelques options intéressantes, que je partage ici.

Habituellement, dmidecode est lancé, sans argument, en tant que root. En effet, celui-ci a besoin d'accéder au matériel via le SMBIOS. Je ne copierai pas ici un exemple de sortie, car c'est assez long. On peut commencer par limiter un peu cette longueur, en utilisant l'option -q, pour quiet. La différence est assez notable, voici une comparaison (sous NetBSD, bien entendu) :

root@shell2:~# dmidecode | wc -l
     544
root@shell2:~# dmidecode -q| wc -l
     443

Près de 100 lignes de différence, concernant principalement des entrées inactives et des méta-données. Cela devrait déjà aider en lisibilité.

Ensuite, il se peut qu'on cherche une information précise sur son système. Par exemple, le nombre de modules de mémoire vive, ainsi que le nombre total de modules présents :

root@shell2:~# dmidecode -q -t memory | grep Size
        Size: 4096 MB
        Size: No Module Installed
        Size: No Module Installed
        Size: No Module Installed

J'ai donc un module de 4 Go de mémoire vive, et la machine peut en accueillir trois autres. L'option -t peut prendre d'autres valeurs, il suffit de ne pas en indiquer pour avoir la liste.

Une autre option utile est -s, par exemple si on recherche des informations sur son processeur :

root@shell2:~# dmidecode -s processor-family
Atom
root@shell2:~# dmidecode -s processor-manufacturer
Intel(R) Corporation
root@shell2:~# dmidecode -s processor-version
Intel(R) Atom(TM) CPU  C2350  @ 1.74GHz
root@shell2:~# dmidecode -s processor-frequency
1743 MHz

Cette option peut aussi prendre d'autres valeurs, et comme pour la précédente, il suffit de ne pas en indiquer pour avoir la liste.

Là où j'ai beaucoup ri, c'est quand je suis allé chercher des informations sur le système et le baseboard :

root@shell2:~# dmidecode -s system-manufacturer
Online Labs
root@shell2:~# dmidecode -s system-product-name
SR
root@shell2:~# dmidecode -s system-version
(^_^)
root@shell2:~# dmidecode -s system-serial-number
42
root@shell2:~# dmidecode -s baseboard-manufacturer
Online Labs
root@shell2:~# dmidecode -s baseboard-product-name
SR
root@shell2:~# dmidecode -s baseboard-version
42
root@shell2:~# dmidecode -s baseboard-serial-number
42
root@shell2:~# dmidecode -s baseboard-asset-tag
42

On remarque donc que le constructeur de la machine peut y mettre un peu ce qu'il veut. On reconnaît ici clairement un serveur Dédibox.

Pour plus de détails, la page de manuel reste incontournable.

Des remarques, des propositions d'améliorations ? Où même des exemples amusants sur certains systèmes particuliers ? Les commentaires sont là pour ça !

Bilan de début d'année du blog

Cette semaine, une petite pause avec un contenu moins technique. J'ai repris depuis le début de cette année 2017 un certain rythme d'écriture sur ce blog, via la parution chaque lundi matin d'un nouveau billet. Je me demandais combien de temps j'allais pouvoir tenir cette cadence, et au bout de combien de temps j'allais m'essouffler, non seulement en terme de motivation, mais aussi en terme d'idées de contenu.

Côté motivation, pour le moment ça passe encore. Ces deux dernières semaines ont été assez remplies et ne m'ont laissé que peu de temps pour écrire. J'avais déjà fait ce constat il y a quelques temps, mais il a été encore plus flagrant en ce début d'année : je n'arrive pas à écrire en continu (comprendre : un peu chaque jour), mais par vague (par exemple, deux soirs toutes les deux ou trois semaines). En partant de ce constat, j'essaie de profiter au maximum de ces moments disponibles, et cela donne donc 10 billets depuis le début de l'année : la cadence est donc tenue !

Côté contenu, là aussi pour le moment j'ai encore quelques idées. Je ne les révèlerai pas pour éviter de gâcher la surprise, mais aussi pour changer de sujet si jamais je change d'avis ;) Là où je suis agréablement surpris, c'est qu'il m'arrive encore de réaliser des choses techniquement intéressantes ce qui nourrit cette sorte d'inspiration, comme le récent billet sur Nmap. Pourvu que ça dure !

Par contre, je ressens encore quelques difficultés pour déterminer là où publier mes différents contenus. J'ai laissé ce blog en jachère pendant plusieurs mois en me disant que je serais sans doute plus lu sur LinuxFr.org, et que j'y aurais certainement plus de retours. Il y a 3 ans, j'ai aussi écrit un article pour GNU/Linux Magazine France. Cela fut une expérience très enrichissante car j'ai pu échanger avec quelqu'un pendant la rédaction, mais c'est bien là où j'ai eu le moins de retour (en dehors d'un collègue qui a acheté le numéro exprès). J'en suis venu à la réflexion suivante :

  • l'actualité, c'est pour LinuxFr.org ;
  • les contenus techniques, qui ne relèvent pas d'une actualité, de taille faible à moyenne (encore qu'avec le billet sur pbulk on peut se poser la question) sont pour le blog ;
  • je voudrais faire publier dans un magazine les contenus techniques, qui ne relèvent pas d'une actualité, de taille moyenne à importante.

Pour ce qui est de la dernière catégorie de contenu, c'est sans doute celle où j'ai le moins d'idées (mais j'en ai), mais c'est aussi pour le moment celle pour laquelle je n'ai pas vraiment pris le temps de m'y mettre sérieusement. C'est peut-être le cœur de cette difficulté, je me demande si je ne devrais pas écrire d'abord, et réflechir après afin de déterminer où publier le contenu ?

Je reste malgré tout sur une note positive : j'ai plus que jamais, en ce début d'année, envie d'expérimenter, de bidouiller, de mettre en place des trucs, et d'écrire sur tout ça !

J'en profite pour terminer sur des questions pour les courageuses et courageux qui oseront écrire dans les commentaires : avez-vous un billet préféré dans ceux de ce début d'année ? Lequel ? Est-ce que vous souhaitez que certains domaines soient approfondis, ou bien un peu de diversité serait appréciée ?

pbulk : compilation massive de paquets pkgsrc

Je continue dans ma série de billets sur pkgsrc, mais cette fois-ci on retourne sous NetBSD. L'objectif aujourd'hui est de construire de nombreux paquets (idéalement tous, ou alors une liste précise) binaires et de créer un dépôt pour ceux-ci. On appelle cela un bulk build lorsqu'on tente de construire tous les paquets disponibles, et un partial bulk build lorsqu'on décide de n'en construire qu'une partie, en inscrivant ceux-ci dans un fichier de liste.

Précisons que ce contenu est en partie basé sur le tutoriel du wiki officiel : Using pbulk to create a pkgsrc binary repository. Si vous préférez la langue de Shakespeare, cela peut s'avérer un bon point de départ.

Préparation

Effectuer ce genre d'opérations requiert idéalement un système dédié, matériel ou virtuel. Dans mon cas, j'ai opté un Raspberry Pi 2B.

braverthanithought.jpg

Bon, on va pas se faire d'illusion, c'est juste pour du bulk build partiel, n'imaginons même pas tenter de construire tous les paquets disponibles sans une cinquantaine de ces trucs.

Côté ressources, il est donc préférable d'avoir plusieurs coeurs, 1 giga-octet de mémoire vive minimum, et quelques dizaines de giga-octets d'espace disque. Au niveau du partitionnement, c'est un peu comme on veut tant que l'endroit où on crée la sandbox (et les paquets) est assez grand. Dans mon cas, j'ai fait un choix très simpliste, vu que le Pi ne sert qu'à cela : un / sur une carte SD de 32 giga-octets. Le répertoire pour créer les sandbox est tout simplement /srv/sandbox.

Concernant l'installation de l'OS, là aussi on va se faciliter l'existence, il suffit d'installer tous les sets, sauf les codes sources du noyau et du système (encore moins de la partie graphique). Exemple sur le Pi, la liste des sets installés :

$ ls -hl /etc/mtree/
total 5.7M
-r--r--r--  1 root  wheel   57K Sep 25  2015 NetBSD.dist
-r--r--r--  1 root  wheel  749K Sep 25  2015 set.base
-r--r--r--  1 root  wheel  2.4M Sep 25  2015 set.comp
-r--r--r--  1 root  wheel   43K Sep 25  2015 set.etc
-r--r--r--  1 root  wheel   43K Sep 25  2015 set.games
-r--r--r--  1 root  wheel  815K Sep 25  2015 set.man
-r--r--r--  1 root  wheel   96K Sep 25  2015 set.misc
-r--r--r--  1 root  wheel   26K Sep 25  2015 set.modules
-r--r--r--  1 root  wheel   90K Sep 25  2015 set.text
-r--r--r--  1 root  wheel  193K Sep 25  2015 set.xbase
-r--r--r--  1 root  wheel  473K Sep 25  2015 set.xcomp
-r--r--r--  1 root  wheel   11K Sep 25  2015 set.xetc
-r--r--r--  1 root  wheel  761K Sep 25  2015 set.xfont
-r--r--r--  1 root  wheel   17K Sep 25  2015 set.xserver
-r--r--r--  1 root  wheel   18K Sep 25  2015 special

Par contre, dans certains cas, l'absence de /usr/src ou de /usr/xsrc peut arrêter net certaines manipulations. IL faut donc penser à les créer (en tant que root) : mkdir /usr/src && mkdir /usr/xsrc. Il n'est pas nécessaire d'installer pkgsrc, mais disposer au moins d'un dépôt de paquets binaires peut être une bonne idée (la dernière version stable suffira). Il s'agit plus d'une question de préférence ici.

Création et configuration de la sandbox

Nous allons donc créer une sandbox qui va contenir l'installation de l'outil pbulk. Cela a plusieurs avantages :

  • on peut créer plusieurs sandbox pour tester différents cas, comme une version différente de pkgsrc ou des options de compilation ;
  • si une sandbox ne fonctionne plus, il est possible d'en créer une autre, voire même de scripter son installation pour aller plus vite ;
  • on pourra installer son petit confort sur le système hébergeant la sandbox (qui a dit bash, vim et git ?), et aussi installer des outils de supervision ou de métrologie.

Ne soyons pas non plus trop optimistes sur la pérennité du système, dans le cas du Pi, j'en suis à la troisième réinstallation (une carte SD n'est pas un disque dur, une clé USB non plus).

Pour créer la sandbox, installons mksandbox. Cet outil est en fait un script shell qui va utiliser des points de montage de type null mountpoint pour faciliter la création de nos espaces de création de paquet et éviter de recopier tout le contenu du système hôte. Au moment de l'écriture de ce billet, la version en date est la 1.7, disponible dans pkgsrc-2016Q4. Au choix, on peut pkgin in mksandbox, pkg_add -v mksandbox, ou bien cd /usr/pkgsrc/pkgtools/mksandbox && make install clean clean-depends.

Une fois mksandbox installé, créons notre premier bac à sable (en tant que root) :

# mksandbox --without-pkgsrc /srv/sandbox/pkgsrc-2016q4
Make and populate /srv/sandbox/pkgsrc-2016q4/dev
Make and populate /srv/sandbox/pkgsrc-2016q4/etc
Make empty dirs upon which to mount the null mounts
Making /tmp in /srv/sandbox/pkgsrc-2016q4
Making /var/games in /srv/sandbox/pkgsrc-2016q4
Making /var/run in /srv/sandbox/pkgsrc-2016q4
Making /var/log in /srv/sandbox/pkgsrc-2016q4
Making /var/spool/lock in /srv/sandbox/pkgsrc-2016q4
Making /var/run/utmp in /srv/sandbox/pkgsrc-2016q4
Making /var/run/utmpx in /srv/sandbox/pkgsrc-2016q4
Making /var/log/wtmp in /srv/sandbox/pkgsrc-2016q4
Making /var/log/wtmpx in /srv/sandbox/pkgsrc-2016q4
Making /var/log/lastlog in /srv/sandbox/pkgsrc-2016q4
Making /var/log/lastlogx in /srv/sandbox/pkgsrc-2016q4
Mount /usr/src from /srv/sandbox/pkgsrc-2016q4
Mount /usr/xsrc from /srv/sandbox/pkgsrc-2016q4
Sandbox creation is now complete

La sandbox est d'ailleurs déjà montée à l'issue de sa création :

# mount | grep 2016q4
/bin on /srv/sandbox/pkgsrc-2016q4/bin type null (read-only, local)
/sbin on /srv/sandbox/pkgsrc-2016q4/sbin type null (read-only, local)
/lib on /srv/sandbox/pkgsrc-2016q4/lib type null (read-only, local)
/libexec on /srv/sandbox/pkgsrc-2016q4/libexec type null (read-only, local)
/usr/X11R7 on /srv/sandbox/pkgsrc-2016q4/usr/X11R7 type null (read-only, local)
/usr/bin on /srv/sandbox/pkgsrc-2016q4/usr/bin type null (read-only, local)
/usr/games on /srv/sandbox/pkgsrc-2016q4/usr/games type null (read-only, local)
/usr/include on /srv/sandbox/pkgsrc-2016q4/usr/include type null (read-only, local)
/usr/lib on /srv/sandbox/pkgsrc-2016q4/usr/lib type null (read-only, local)
/usr/libdata on /srv/sandbox/pkgsrc-2016q4/usr/libdata type null (read-only, local)
/usr/libexec on /srv/sandbox/pkgsrc-2016q4/usr/libexec type null (read-only, local)
/usr/share on /srv/sandbox/pkgsrc-2016q4/usr/share type null (read-only, local)
/usr/sbin on /srv/sandbox/pkgsrc-2016q4/usr/sbin type null (read-only, local)
/var/mail on /srv/sandbox/pkgsrc-2016q4/var/mail type null (read-only, local)
/usr/src on /srv/sandbox/pkgsrc-2016q4/usr/src type null (read-only, local)
/usr/xsrc on /srv/sandbox/pkgsrc-2016q4/usr/xsrc type null (read-only, local)

Profitons-en pour découvrir le script de montage, démontage, et d'entrée dans la sandbox, qui se nomme sandbox et se trouve à la racine de celle-ci. Dans mon cas c'est donc /srv/sandbox/pkgsrc-2016q4.

Pour démonter la sandbox, c'est donc :

# /srv/sandbox/pkgsrc-2016q4/sandbox umount

Pour monter la sandbox, c'est :

# /srv/sandbox/pkgsrc-2016q4/sandbox umount

Et pour entrer dans la sandbox, c'est :

# /srv/sandbox/pkgsrc-2016q4/sandbox chroot

Démontons-donc la sandbox, et avant de la remonter, éditons le script de sandbox. Les lignes 16 à 33 montrent la liste des répertoires à monter, et nous allons en ajouter une, qui permettra à la sandbox d'envoyer des mails (c'est donc optionnel mais pratique parfois). Il s'agit du répertoire /var/spool. Dans mon cas, le résultat est donc :

fses="\
/bin /bin ro \
/sbin /sbin ro \
/lib /lib ro \
/libexec /libexec ro \
/usr/X11R7 /usr/X11R7 ro \
/usr/bin /usr/bin ro \
/usr/games /usr/games ro \
/usr/include /usr/include ro \
/usr/lib /usr/lib ro \
/usr/libdata /usr/libdata ro \
/usr/libexec /usr/libexec ro \
/usr/share /usr/share ro \
/usr/sbin /usr/sbin ro \
/var/mail /var/mail ro \
/usr/src /usr/src ro \
/usr/xsrc /usr/xsrc ro \
/var/spool /var/spool rw \
"

Notons qu'il s'agit du seul répertoire accessible en écriture. Nous pouvons alors monter la sandbox, et y entrer.

Notre sandbox est crée, mais il nous faut ajouter quelques éléments avant d'installer pbulk. Par exemple, il nous manque pkgsrc. Installons donc ce dernier :

netpi2# mkdir -p /root/.ssh
netpi2# cd /usr                                                                                              
netpi2# cvs -d anoncvs@anoncvs.netbsd.org:/cvsroot co -rpkgsrc-2016Q4 pkgsrc

Dans le cas d'une installation de pkgsrc-current, il suffit de retirer la partie -rpkgsrc-2016Q4 de la commande précédente. Sauf que, dans mon cas, le Raspberry Pi (ou bien sa carte SD) ne tient pas le coup et abandonne avant la fin du checkout. Procédons à l'alternative :

netpi2# mkdir -p /root/.ssh
netpi2# cd /usr
netpi2# ftp http://cdn.netbsd.org/pub/pkgsrc/pkgsrc-2016Q4/pkgsrc-2016Q4.tar.xz 
Trying 2a04:4e42:4::262:80 ...
ftp: Can't connect to `2a04:4e42:4::262:80': No route to host
Trying 151.101.61.6:80 ...
Requesting http://cdn.netbsd.org/pub/pkgsrc/pkgsrc-2016Q4/pkgsrc-2016Q4.tar.xz
100% |*************************************************************************************************************************************************************************************************| 37422 KiB    2.65 MiB/s    00:00 ETA
38320872 bytes retrieved in 00:13 (2.65 MiB/s)
netpi2# unxz -v pkgsrc-2016Q4.tar.xz                                                                                                                                                                                                         
pkgsrc-2016Q4.tar.xz (1/1)
  100 %        36.5 MiB / 437.1 MiB = 0.084   8.8 MiB/s       0:49   
netpi2# tar -xvpf pkgsrc-2016Q4.tar
# non, je ne copierai pas la sortie d'un tar verbose de pkgsrc.
netpi2# cd pkgsrc && cvs update -dP

Note pour plus tard : bsdtar ne prend pas en compte nativement le format xz. En attendant, les archives au format bzip2 c'est pas mal.

Installation et configuration de pbulk

Avant d'installer pbulk, il convient de comprendre certains détails. Pbulk s'installe via pkgsrc, mais tous les paquets qui vont être créés par la suite le seront aussi, et probablement désinstallés. Cela risque donc d'influer sur les dépendances de pbulk. L'idée est donc d'installer pbulk non pas dans l'emplacement habituel des paquets /usr/pkg/ mais dans un autre endroit, qui se trouve être /usr/pbulk.

En préalable à l'installation de pbulk, initialisons un fichier d'options de compilation, nommé mk.conf.frag :

PKG_DEVELOPER=yes

MAKE_JOBS=3
SKIP_LICENSE_CHECK=yes
PKG_COMPILER=ccache gcc
PKG_RCD_SCRIPTS=yes
ALLOW_VULNERABLE_PACKAGES=YES
PKG_DEFAULT_OPTIONS+=
KRB5_ACCEPTED=heimdal mit-krb5
USE_CWRAPPERS=yes
PKG_OPTIONS.irssi+= ssl perl inet6

PKGCHK_CONF?=   /etc/pkgchk.conf
DEPENDS_TARGET= bulk-install
BATCH=          yes
BULK_PREREQ+=   pkgtools/lintpkgsrc
BULK_PREREQ+=   pkgtools/pkg_install
BULK_PREREQ+=   devel/ccache

# http://wiki.netbsd.org/tutorials/pkgsrc/cross_compile_distcc/
.for DISTCCDEPS in devel/ccache sysutils/checkperms pkgtools/digest devel/distcc devel/popt devel/libtool-base lang/f2c devel/gmake
.  if "${PKGPATH}" == "${DISTCCDEPS}"
IGNORE_DISTCC=  yes
IGNORE_CCACHE=  yes
.  endif
.endfor

WRKOBJDIR=              /tmp
PACKAGES=               /srv/packages
DISTDIR=                /srv/distfiles

L'idée est d'indiquer ici des options de personnalisation de compilation. Il est possible de comprendre à quoi correspondent ces options en allant jeter un œil dans le répertoire /usr/pkgsrc/mk/defaults/, mais je vais malgré tout m'attarder sur l'une d'entre elles : MAKE_JOBS. Cette directive permet d'utiliser plusieurs commandes make en parallèle, et il convient de l'ajuster selon le nombre de cœurs ou de threads de votre ordinateurs. Généralement une règle simple serait au minimum "nombre de processeurs +1". Mais, le Raspberry PI, malgré ses 4 cœurs, ne tient pas le coup, j'ai donc abaissé la valeurs à 3. A noter que le contenu de ce mk.conf.frag sera copié lors de l'installation de pbulk dans le fichier /etc/mk.conf. On pourra le modifier entre deux builds, pas besoin de relancer l'installation. Tiens, d'ailleurs, lançons-là :

sh /usr/pkgsrc/mk/pbulk/pbulk.sh -n -c mk.conf.frag

Une fois pbulk installé, configurons son fichier principal : /usr/pbulk/etc/pbulk.conf. Je ne vais pas détailler toutes les options, mais juste celles que je modifie. Commençons d'ailleurs par ajouter les deux lignes suivantes juste après la première :

ulimit -t 3600 # set the limit on CPU time (in seconds)
ulimit -v 2097152 # limits process address space

Comme l'indiquent les commentaires en anglais (recopiés textuellement depuis la page wiki du début du billet), ils servent à limiter la consommation CPU de nos builds, au cas où. Je choisis ensuite l'URL du rapport de bulk build :

base_url=http://pkg.anotherhomepage.org/pub/pkgsrc/reports/NetBSD/earmv6hf/7.0_2016Q

Ce rapport va me permettre de voir quels paquets n'ont pu être construits, et surtout de comprendre pourquoi grâce aux fichiers de log.

Avant la construction des paquets, une phase permet de lister ceux-ci et de déterminer l'ordre dans lequel les construire. Cette étape se nomme le "scan". Pour accélérer cette étape, nous pouvons conserver le résultat du scan d'un build précédent. Pour cela :

reuse_scan_results=yes

Il est possible d'utiliser plusieurs machines avec pbulk. Ce n'est pas notre cas ici :

master_mode=no

On passe alors aux options de publication des paquets, via rsync :

pkg_rsync_args="-rltoDPq"
pkg_rsync_target="user@host:/chemin/vers/les/paquets/"
report_rsync_args="-rltoDPq"
report_rsync_target="user@host:/chemin/vers/les/rapports/"

Le build est long, c'est pratique d'avoir un mail quand c'est fini, et qui contient le rapport :

report_subject_prefix="pkgsrc-2016Q4"
report_recipients="adresse@domaine.valide"

C'est d'ailleurs l'occasion de parler du BulkTracker, qui permet de suivre différents bulk builds. Pour y participer, il suffit d'ajouter dans dans report_recipients l'adresse pkgsrc-bulk chez NetBSD point org.

On parlait de bulk buid partiel, on peut spécifier un fichier contenant une liste de paquets pour ne pas avoir à compiler tous les paquets :

limited_list=/etc/pkgchk.conf

Dans ce fichier, chaque paquet est sur sa propre ligne. Pour le moment, on peut démarrer avec juste pkgtools/pkgin dedans.

Je choisis ensuite de modifier certains répertoires, celui qui contient les logs de construction des paquets, et celui qui contient les paquets :

bulklog=/srv/bulklog
packages=/srv/packages

Ne pas oublier aussi, surtout pour NetBSD, de bien positionner la variable make :

make=/usr/bin/make

Dernier détail, la fin du fichier contient quelques redéfinitions de variables, donc attention de les mettre en commentaire !

Et tu bulk, et tu bulk, et tu bulk (mais sans t-shirt jaune ni planche de surf)

Avant de lancer la construction à proprement parler, petit avertissement : il est plus que recommandé d'utiliser screen ou tmux, car cela prend énormément de temps !

Lançons pbulk :

/usr/pbulk/bin/bulkbuild
Warning: All log files of the previous pbulk run will be
removed in 5 seconds. If you want to abort, press Ctrl-C.
Removing old scan results

Si jamais un paquet ne fonctionne pas, mais qu'après mise à jour, il peut compiler, il est possible de ne pas tout recompiler :

/usr/pbulk/bin/bulkbuild-rebuild category/pkgname

Il est aussi possible de reprendre un build arrêté inopinément :

/usr/pbulk/bin/bulkbuild-restart

J'espère que malgré la longueur, ce billet saura se montrer utile et intéressant. Comme toujours, les commentaires sont là pour accueillir remarques, questions et compléments !

Vérifier les chiffrements disponibles sur un serveur HTTPS avec Nmap

Je me suis retrouvé l'autre jour avec une alerte de sonde de détection d'intrusion, laquelle me signalait qu'une potentielle exploitation de la faille Heartbleed avait eu lieu sur un serveur web. L'autre détail que j'avais au niveau de l'alerte : le protocole utilisé pour cette exploitation était SSL v3.

N'ayant pas la main sur la machine, je n'avais pour seule option que de vérifier côté client si le serveur utilise ce protocole. Sur l'instant, j'ai pensé à utiliser OpenSSL, qui dispose d'options pour se connecter à un serveur en utilisant certains protocoles. Cela donne pour mon cas, l'exemple et le résultat suivant :

$ openssl s_client -connect blog.anotherhomepage.org:443 -ssl3                                                                                                                                                             
CONNECTED(00000006)
140187574654788:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/usr/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:1304:SSL alert number 40
140187574654788:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/usr/src/crypto/external/bsd/openssl/dist/ssl/s3_pkt.c:637:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1485895043
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Alors bon, je sais pas trop vous, mais pour moi, ce n'est pas très évident que le serveur ne prend pas en charge SSL v3. Il y a quand même écrit "CONNECTED" au début, avant de me sortir "handshake failure". Néanmoins, la mission est remplie, et on peut vérifier plusieurs protocoles via les options suivantes d'OpenSSL :

* -ssl2 ;
* -ssl3 ;
* -tls1_2 ;
* -tls1_1 ;
* -tls1 ;
* -dtls1.

Peu satisfait de la solution, j'ai continué mon voyage dans les moteurs de recherche, avant de tomber sur une question similaire, disposant de la première solution, mais d'une autre visiblement plus lisible, utilisant le célèbre Nmap. Elle consiste à tirer parti d'une fonctionnalité assez intéressante du célèbre scanneur de ports, à savoir la disponibilité d'un langage de script permettant d'obtenir des détails supplémentaires lors d'un scan de port. Parmi les scripts disponibles, certains ont même pour but de mener des attaques par bruteforce. Là, il n'est pas question d'attaque, mais simplement d'énumération des ciphers disponibles. Comme plus haut, voici un exemple accompagné d'un résultat :

Starting Nmap 7.40 ( https://nmap.org ) at 2017-02-19 09:30 CET
Nmap scan report for blog.anotherhomepage.org (163.172.46.128)
Host is up (0.0012s latency).
rDNS record for 163.172.46.128: vhost2.anotherhomepage.org
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 10.06 seconds

On remarquera, dans mon exemple, l'absence de SSLv3.

Et pour l'alerte de mon IDS ? Et bien comme dans mon exemple, SSLv3 n'est pas apparu dans mes résultats, ce qui m'a permis de conclure au faux-positif.

Un dernier détail : au moment de l'écriture de ce billet, NSE n'est pas activé par défaut dans pkgsrc, et pour NetBSD, son activation empêche de compiler Nmap.

Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

Clamav : installation et scan antivirus sur macOS

Si installer un antivirus sur macOS peut sembler étonnant au premier abord, il n'en est pas moins utile, pour plusieurs raisons :

  • d'abord, car la popularité de ces dernières années le rend plus attractif pour ceux qui créent des virus, vers et autres malwares en tous genres ;
  • ensuite, car il est toujours possible d'être un porteur sain, et donc de propager des menaces vers d'autres machines, qui sont elles potentiellement vulnérables.

N'ayant pas encore pris la peine d'essayer quelques-uns de la pléthore d'antivirus disponibles sur l'App Store, j'ai décidé d'installer ClamAV. Une version graphique est disponible chez ClamXav, mais je voulais d'abord quelque chose en ligne de commande, avant d'essayer des produits disposant d'une protection résidente.

Comme pour Bash, on peut installer très facilement Clamav grâce à pkgsrc :

sudo pkgin in clamav

Ensuite, il va falloir mettre à jour les définitions de virus :

sudo freshclam

Et maintenant, scannons tout le système ! L'argument -r permet d'être récursif, -i n'affiche que les infections (sinon, les fichiers vides ou les liens symboliques seront aussi affichés) et -l s'occupe d'enregistrer le résultat du scan dans un fichier de rapport. A noter que des options supplémentaires, disponibles dans la page de manuel, donneront accès à certains comportements, comme certaines actions à effectuer sur un fichier infecté (comme le copier, le déplacer, ou l'effacer).

sudo clamscan -r / -i -l ~/clamscan_report.txt

Même si un rapport est demandé, Clamav affichera sur la sortie standard les fichiers traités (l'argument -i limite grandement la pollution visuelle).

Enfin, jetons un oeil rapide à notre rapport, en regardant si des menaces sont été trouvées. Si l'argument -i n'a pas été utilisé, ceci devrait aider :

grep FOUND ~/clamscan_report.txt

Voici deux exemples de message signalant la présence d'un virus dans ma boite mail Thunderbird :

/Users/nils/Library/Thunderbird/Profiles/XXXXX.default/ImapMail/mx.example.org/INBOX.sbd/SubDir.sbd/OtherDir: Win.Malware.Locky-542 FOUND

/Users/nils/Library/Thunderbird/Profiles/XXXXX.default/ImapMail/mx.example.org/Junk: Js.Downloader.Election_phishing-1 FOUND

Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

Bash : utiliser une version plus récente sur macOS

Dans le billet précédent à propos de pkgsrc sur macOS, nous avons abordé l'installation. Passons maintenant à un cas pratique ! En effet, si macOS profite de sa base Unix, et parfois dans des versions pas trop anciennes (en tous cas pour macOS Sierra, en version 10.12.3 au moment de l'écriture de ce billet), GNU Bash fait exception :

$ /bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16)
Copyright (C) 2007 Free Software Foundation, Inc.

Si Apple a laissé une version assez ancienne du célèbre interpréteur de commande, ce n'est peut-être pas pour rien. Comment donc utiliser une version plus récente, tout en conservant celui du système ? Grâce à pkgsrc bien sûr !

Une fois pkgsrc installé grâce au billet précédent, on peut très simplement installer Bash :

sudo pkgin -y install bash

Il est possible, en option, d'installer des complétions supplémentaires pour Bash via le paquet bash-completions :

sudo pkgin -y install bash-completions

Notre nouveau shell est alors disponible par le chemin /opt/pkg/bin/bash. Assurons-nous que ce chemin est considéré par macOS comme un shell valide, en vérifiant le fichier /etc/shells, et en l'éditant si besoin (il faudra faire attention à utiliser sudo pour cette édition). Par exemple, une fois l'édition effectuée, mon fichier ressemble à ceci :

$ cat /etc/shells
# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/opt/pkg/bin/bash

On peut alors modifier le shell de son propre utilisateur en utilisant la commande chsh :

chsh -s /opt/pkg/bin/bash

Cette nouvelle version de Bash n'est alors utilisée que pour l'utilisateur système courant, ce qui ne devrait perturber aucun script système. Une autre possibilité, si on veut limiter cette version de Bash au terminal, consiste à se rendre dans les préférences de l'application Terminal.app, puis, dans l'onglet "Général", de modifier le paramètre "Ouvrir les shells avec :", de sélectionner l'option "Commande (chemin d'accès complet) :" et de le positionner à /opt/pkg/bin/bash.

Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

pkgsrc : installer un gestionnaire de paquets pour plus de logiciels sur macOS

Disclaimer : mon installation de pkgsrc étant bien entendu faite depuis quelques temps, une partie de ce billet est écrite grâce aux documentations suivies à l'époque et un peu de mémoire, je n'ai pas pu tout re-tester. Si des passages sont erronés ou que vous éprouvez des difficultés, n'hésitez pas à m'en faire part dans les commentaires, je corrigerai dès que possible.

L'une des forces de macOS (anciennement OSX, anciennement Mac OS X, Apple pourrait quand même arrêter sa frénésie de renommage) est sa base héritée d'Unix. Sans rentrer dans les détails, j'apprécie de pouvoir lancer un terminal et disposer d'un interpréteur de commandes (Bash) et de certains logiciels "classiques", comme Vim, wget, curl, sed ou awk. J'apprécie aussi de pouvoir installer certains logiciels très facilement via le terminal, ce qui est le cas sur un système GNU/Linux ou BSD. Bien que cela ne soit pas disponible pour macOS, plusieurs projets viennent combler ce manque :



J'ai par le passé utilisé MacPorts, mais aujourd'hui j'utilise pkgsrc. Les raisons qui m'ont fait passer de l'un à l'autre sont surtout liées à mes contributions au dernier : au-delà de la réutilisation de connaissances liées à NetBSD/pkgsrc, je peux aussi tester certains paquets pkgsrc sous macOS. Quelque chose que j'ai apprécié aussi est la disponibilité de paquets binaires pré-compilés grâce à Joyent, tout en conservant la possibilité de compiler soi-même de manière rapide et simple ces propres paquets.

Installation de pkgsrc pour les paquets binaires

L'installation de pkgsrc sur macOS est assez simple si on souhaite juste utiliser les paquets binaires, et un peu plus longue si on souhaite aussi compiler ses propres paquets, qu'on verra dans un second temps. Une manière plus rapide d'installer pkgsrc consiste à utiliser Save mac OS, un script shell de boostrap qui effectuera ces opérations pour vous. Néanmoins, il me semble pertinent de comprendre un peu le pourquoi des choses, et c'est l'objectif de cette partie.

Démarrons par le bootstrap, qui consiste à installer l'arborescence de base permettant d'obtenir les paquets binaires. Je pars ici du principe qu'on dispose d'une machine au moins sous 10.9. Si vous avez une version plus ancienne, suivez ce qui est indiqué pour 10.6 chez Joyent. On commence par télécharger l'archive contenant cette arborescence :

BOOTSTRAP_TAR="bootstrap-trunk-x86_64-20161011.tar.gz"
curl -O https://pkgsrc.joyent.com/packages/Darwin/bootstrap/${BOOTSTRAP_TAR}

Par principe, vérifions aussi que le téléchargement de pkgsrc s'est bien déroulé :

BOOTSTRAP_SHA="09d6649027ce12cadf35a47fcc5ce1192f40e3b2"
echo "${BOOTSTRAP_SHA}  ${BOOTSTRAP_TAR}" >check-shasum
shasum -c check-shasum

Tant qu'on y est dans les vérifications, on peut s'occuper de la signature GPG, si celui-ci est installé (c'est optionnel, vous pouvez l'installer sur le site de GPGTools) :

curl -O https://pkgsrc.joyent.com/packages/Darwin/bootstrap/${BOOTSTRAP_TAR}.asc
gpg --recv-keys 0x1F32A9AD
gpg --verify ${BOOTSTRAP_TAR}{.asc,}

Passons à l'installation de pkgsrc à proprement parler, c'est maintenant qu'on a besoin de droits administrateur :

sudo tar -zxpf ${BOOTSTRAP_TAR} -C /

Enfin, on prend en compte les chemins additionnels dans le $PATH, car les paquets s'installent dans l'arborescence /opt/pkg/ (les exécutables sont dans /opt/pkg/bin ou /opt/pkg/sbin) :

eval $(/usr/libexec/path_helper)

Pour ce qui est des pages de manuel, on peut ajouter la ligne suivante dans son fichier .profile :

export MANPATH=$MANPATH:/opt/pkg/share/man/

Une fois que cela est fait, on peut vérifier que pkgin est bien installé, et mettre à jour la liste des paquets depuis le dépôt :

sudo pkgin -f up
sudo pkgin fug

On peut alors utiliser pkgin pour lister, installer, mettre à jour ou désinstaller des logiciels. Attention, il est préférable de l'utiliser avec sudo, surtout pour les actions d'installation, de désinstallation ou de mise à jour.

Installation de pkgsrc pour compiler depuis les sources

La partie binaire mise en place, passons aux sources. Dans cette optique, il faut commencer par installer les command-line tools de Xcode. Cette partie peut nécessiter de créer un compte développeur chez Apple. L'installation se fait de la manière suivante :

xcode-select --install

Bien qu'un miroir Github de pkgsrc existe, nous allons préférer utiliser CVS pour récupérer l'arbre des paquets :

sudo pkgin -y in cvs
cd /opt
sudo mkdir pkgsrc
sudo chown $(whoami):wheel pkgsrc
cvs -danoncvs@anoncvs.netbsd.org:/cvsroot checkout pkgsrc

Optionnellement, on peut ajouter pkgsrc-wip, un arbre supplémentaire de paquets, qui permet entre autres aux débutants de se faire la main dans le domaine de l'empaquetage logiciel pour pkgsrc. Ici, pas besoin d'installer CVS, git est le gestionnaire de version de ce projet (et inclus de base dans macOS) :

cd /opt/pkgsrc
git clone git://wip.pkgsrc.org/pkgsrc-wip.git wip

Pour mettre à jour les arborescences :

cd /opt/pkgsrc
cvs update -dP
cd wip
git pull -r

Pour installer un paquet, par exemple figlet, on utilise la commande bmake (il s'agit du bsd make, disponible sous NetBSD directement via la commande make) :

cd /opt/pkgsrc/misc/figlet
bmake install

On pourra ensuite faire le nettoyage dans l'arborescence via :

bmake clean clean-depends

Avant de terminer, un petit mot sur le paramétrage du bootstrap et de son impact sur l'installation de logiciels via les sources : le boostrap de Joyent active la vérification par clé GPG des paquets binaires, afind de s'assurer de l'intégrité de ceux-ci. Or, cela peut perturber l'installation de paquets via les sources, car le paquet créé ne sera pas signé par Joyent. Il est possible de signer tous les paquets qu'on crée, mais cela peut devenir vite rébarbatif si le processus de compilation n'est pas automatisé. Dans le cas où l'installation d'un paquet par les sources échouerait, il est possible de modifier le niveau de confiance, en demandant de manière interactive si le paquet doit être installé ou non. Il suffit alors de positionner la variable VERIFIED_INSTALLATION à "trusted" dans le fichier /opt/pkg/etc/pkg_install.conf.

J'espère que ce billet aura plus et poussera plus d'utilisateurs de macOS à mieux maîtriser les possibilités de leur machine. Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

Kodi : récupérer certaines informations sur des addons

J'ai récemment perdu le mot de passe d'un service web que j'utilise par le biais d'un addon de Kodi. Je sais, c'est pas très malin, j'ai malencontreusement écrasé ma base de mots de passe au mauvais moment. Shit happens, comme ils disent dans la langue de Shakespeare.

Comme c'est casse-pied de retaper un nouveau mot de passe via un clavier virtuel et une télécommande, je me suis demandé si le mot de passe était stocké en clair dans la configuration de l'addon. On sait jamais, sur un malentendu, ça pourrait marcher. J'ai donc commencé à fouiller dans l'arborescence de Kodi, et j'ai pu voir que celui-ci stocke ses informations dans ~/.kodi. On y trouve alors un répertoire addons, qui contient un répertoire par addon, ainsi qu'un répertoire packages, qui contient des archives des addons téléchargés. Il est intéressant de regarder le code source des addons, car c'est dans celui-ci que j'ai compris qu'il stockait bien le nom d'utilisateur et le mot de passe.

Au même niveau que le répertoire addons, se trouve un répertoire nommé userdata. Celui-ci contient un répertoire addon_data, dans lequel il y a un répertoire par addon. L'addon dont je souhaitais voir la configuration y a laissé un répertoire à son nom, contenant un fichier de paramètres ainsi qu'un répertoire temporaire. Un petit "cat" sur le fichier de paramètres dévoile donc le Graal :

<settings>
    <setting id="OSpass" value="motdepasseenclair" />
    <setting id="OSuser" value="utilisateur" />
</settings>

En résumé, les paramètres d'un addon Kodi se trouvent dans ~/.kodi/userdata/addon_data/nomdeladdon/, dans un fichier nommé settings.xml. Le code source se trouve quant à lui dans ~/.kodi/addons/nomdeladdon/.

Comme quoi, j'ai vraiment raison de ne vouloir utiliser qu'un unique trio e-mail/utilisateur/mot de passe sur certains sites ou certaines applications.

dehydrated, un client alternatif pour Let's Encrypt

Après quelques galères avec Certbot, j'ai découvert dehydrated, un client pour Let's Encrypt écrit en Bash.

Depuis plusieurs semaines, voire mois, le client officiel de l'autorité de certification Let's Encrypt, Certbot, ne fonctionne plus sous NetBSD. Cela semble venir du fait que Python, dont dépend Certbot, est compilé avec PaX MPROTECT. C'est tout du moins ce qu'indique ce rapport de bug.

N'ayant ni le temps ni les compétences pour voir ce qui bloque exactement du côté de Certbot, j'ai fait ce que pas mal d'autres ont fait : j'ai recherché une alternative. La première alternative qui a attiré mon attention est acme-client, en version portable, d'ailleurs disponible au moment où j'écris ces lignes dans pkgsrc-wip. Mais en fait celui-ci ne semble pas fonctionner sous NetBSD, me hurlant des histoires de droits et de suid bizarres.

J'ai ensuite jeté mon dévolu sur dehydrated, un client écrit en Bash. Celui-ci a l'avantage non-négligeable de fonctionner, contrairement au précédent. Je me suis donc lancé dans son empaquetage (wip/dehydrated au moment où j'écris ces lignes, mais j'espère l'importer dans pkgrsc-current dès que possible). Dehydrated est assez pratique à utiliser, il nécessite des dépendances assez classiques pour un script shell (sed, awk, curl), en plus d'OpenSSL. Bien qu'il dispose de fichiers de configuration, de nombreuses options peuvent être spécifiées sur la ligne de commandes. Dehydrated prévoit aussi des scripts "hook" pour pouvoir déclencher d'autres actions avant et après le renouvellement d'un certificat par exemple.

Le paquet est globalement fonctionnel sous NetBSD, le seul prérequis avant de se lancer dans l'édition des fichiers de configuration est d'avoir une configuration OpenSSL existante (ce qui se fait rapidement, en copiant simplement le fichier d'exemple fourni dans /usr/share/examples/openssl/), et de savoir dans quel répertoire le challenge ACME sera déposé. J'espère d'ici là avoir amélioré la prise en compte d'OpenSSL d'ailleurs (utilisation de celui de pkgsrc par exemple). Idéalement, ce serait assez cool que dehydrated puisse utiliser LibreSSL.

Il existe d'autres clients alternatifs que je n'ai pas essayés, comme getssl, mais lequel est votre préféré et pourquoi ? Le formulaire de commentaire n'attend que votre réponse !

SSL à l'arrache, épisode 2

Le premier épisode est ici. En gros, je voulais rapidement générer un certificat SSL/TLS à des fins de tests.

Mais pourquoi un deuxième épisode ? Parce qu'il manquait quelque chose au premier, c'est la facilité d'automatisation. Alors bon, pour un site public, aujourd'hui, Let's Encrypt fait très bien le travail et il vaut mieux se diriger vers cela. Mais dans le cas d'un site de tests, voire utilisé uniquement dans un LAN, c'est moins évident.

Retournons-donc à ce bon vieil OpenSSL et à sa page de manuel. Les autres pages de manuel sont fort utiles, elles aussi. On peut alors arriver à une seule commande créant un CSR puis un certificat. En utilisant l'argument -subj on peut alors indiquer directement sur la ligne de commande les informations de type pays, province, ainsi que le common name. On peut d'ailleurs ajouter plusieurs noms en ajoutant plusieurs directives de type "CN".

Voici un exemple de création de certificat auto-signé, valable un an :

openssl req -x509 -nodes -days 365 -newkey rsa:4096 \
  -keyout default.key \
  -out default.crt \
  -subj '/C=FR/ST=IdF/L=Paris/O=Example Org/OU=Dev/CN=example/CN=example.org/CN=www.example.org'

Des remarques, des propositions d'améliorations ? Les commentaires sont là pour ça !

Propulsé par Dotclear