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 !

Vous naviguez toujours sur un site HTTPS

Bon d'accord, je suis over-méga-à la bourre sur celui-ci : en gros il y a quelques mois, après avoir passé ce blog en HTTPS, je me suis rendu compte que certains couples OS/navigateurs ne fonctionnaient plus, par exemple certaines version d'Internet Explorer sous Windows 7. J'imagine que cela ne doit pas être beaucoup en terme de proportion, mais je me suis quand même dit que c'était vachement dommage. Je suis donc retourné voir générateur de configuration SSL proposé par Mozilla, et j'ai sélectionné un choix "intermédiaire".

Première conséquence : une augmentation des clients compatibles, ça tombe bien, c'est le but ! Maintenant, pour profiter de ce blog, il suffit de disposer d'au minimum Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3 ou bien Java 7.

Deuxième conséquence : une baisse de la ^W ^W ^W ^W et bien non, même pas ! J'ai toujours une note de A+ au test SSL Labs ! Dans ces conditions, pourquoi se priver ? :)

Bonne année 2017

Bonne et heureuse année 2017 à toutes et à tous ! Qu'elle apporte joie, bonheur et réussite aux lecteurs de ce blog :) Les semaines à venir devraient apporter quelques billets, j'espère que j'aurai le temps d'en écrire d'autres après ça.

Vous naviguez sur un site web HTTPS

Depuis hier, ce blog est dorénavant accessible uniquement en HTTPS. Pour l'exercice, j'ai fait en sorte que celui-ci dispose d'une note A+ au test SSL Labs de chez Qualys, en me basant sur une configuration proposée par le générateur de configuration SSL proposé par Mozilla. J'ai choisi une configuration "moderne". Côté certificat, j'ai choisi d'utiliser Let's Encrypt.

On peut très vite noter quelques impacts :

  • d'abord, la liste des plus vieux clients compatibles : Firefox 27, Chrome 22, IE 11, Opera 14, Safari 7, Android 4.4, Java 8 ;
  • ensuite, une légère augmentation du temps de chargement du site, qui peut s'avérer plus que significative lors d'une redirection HTTP vers HTTPS.

Concernant les clients compatibles, je ne m'en fais pas trop, ce blog n'est pas très visité, et je doute que beaucoup de personnes visitent ce site avec Internet Explorer. Je suis un peu plus embêté pour Android, du fait d'une fragmentation assez importante. Du côté du temps de chargement, de nouvelles mesures réalisées un peu plus tard sont encourageantes, j'imagine donc que les divers caches possibles feront toujours leur travail et que la navigation sera confortable.

Java prend trop de place

Un billet d'humeur, ça faisant longtemps. De temps en temps, il me prend l'envie de faire un peu de ménage sur mon disque dur, je pars donc à la recherche de fichiers volumineux, en double, ou inutiles. En la matière, je tiens un gagnant : Java.

Java, sur OS X, réclame de temps à autres une mise à jour. C'est louable, de penser à la sécurité de l'utilisateur. Sauf que le téléchargement de la mise à jour se fait dans un répertoire inadapté (non, c'est trop simple de télécharger dans le répertoire "Téléchargements", on va aller mettre ça dans la bibliothèque de l'utilisateur, planqué au fond d'_Application Support_), mais en plus, le programme de mise à jour n'efface ni l'archive courante, ni les archives précédentes. Le résultat : environ 65Mo téléchargés, puis 65Mo décompressés à chaque mise à jour. Total sur ma machine : 972Mo. Je peux comprendre qu'on garde l'archive, qu'on garde l'installeur si l'installation se passe mal, mais franchement, ne pas purger les versions précédentes, je ne comprend pas.

nils@dalaran-wifi:~/Library/Application Support/Java$ du -sh
972M	.
nils@dalaran-wifi:~/Library/Application Support/Java$ du -sh *
116M	Java 1.8.45.14
116M	Java 1.8.51.16
121M	Java 1.8.60.27
121M	Java 1.8.60.27 1
121M	Java 1.8.60.27 2
121M	Java 1.8.60.27 3
129M	Java 1.8.60.27 4
129M	Java 1.8.65.17

Je suis conscient de l'augmentation des capacités de stockage, mais quand même, faudrait pas pousser, non ? Ou alors, Oracle a passé un accord avec les fabricants de stockage pour vendre des disques durs encore plus gros (bon, j'avoue, ma théorie du complot est elle aussi un peu abusée) ?

Bon, bref, tout ça pour dire que sur une machine OS X, si vous voulez gagner quelques centaines de méga-octet facilement, il suffit de faire ceci :

rm -rf ~/Library/Application Support/Java/*

installation minimaliste de CentOS 7

Mieux vaut tard que jamais, j'ai commencé à jouer un peu avec CentOS 7 ! Bien que celle-ci regorge de fonctionnalités et de mécanismes intéressants, elle amène beaucoup de paquets logiciels. J'ai donc commencé par regarder ce que je pouvais retirer comme paquets, et à préparer une section _packages_ minimaliste, bien plus que l'image iso "minimal install" fournie par les miroirs. Cette liste de paquets retirés peut se voir complétée par une liste de paquets à installer, mais il s'agit d'un choix personnel. Qu'ai-je donc retiré ? Et bien c'est simple, comme il s'agit généralement d'une installation sur une machine physique ou virtuelle reliée en réseau filaire et disposant d'une adresse IP fixe (sauf lors de l'installation), j'ai retiré tous les firmwares possibles de matériel que je n'utilise probablement pas, comme les cartes Wifi. J'ai aussi enlevé, usage serveur oblige, des paquets liés au son (alsa). Un choix discutable, j'ai retiré man et les pages de manuel de base : je considère, en particulier si la machine est "en production", que la documentation n'a rien à faire à cet endroit. Je n'ai, par contre, rien à redire à l'installation des pages de manuel sur une machine de test. De plus, comme j'utilise le système de fichiers proposé par défaut (xfs), j'estime ne pas avoir besoin des outils pour gérer les systèmes ext2-3-4 ou btrfs.

Voici donc, la liste :

%packages --nobase
@core
-NetworkManager
-NetworkManager-team
-NetworkManager-tui
-aic94xx-firmware
-alsa-firmware
-alsa-lib
-alsa-tools-firmware
-atmel-firmware
-avahi-autoipd
-avahi-libs
-b43-openfwwf
-bfa-firmware
-biosdevname
-btrfs-progs
-dhclient
-dmidecode
-dnsmasq
-dracut-network
-e2fsprogs
-e2fsprogs-libs
-gnutls
-kexec-tools
-ipw2100-firmware
-ipw2200-firmware
-ivtv-firmware
-iwl100-firmware
-iwl1000-firmware
-iwl105-firmware
-iwl135-firmware
-iwl2000-firmware
-iwl2030-firmware
-iwl3160-firmware
-iwl3945-firmware
-iwl4965-firmware
-iwl5000-firmware
-iwl5150-firmware
-iwl6000-firmware
-iwl6000g2a-firmware
-iwl6000g2b-firmware
-iwl6050-firmware
-iwl7260-firmware
-libertas-usb8388
-man
-man-db
-mariadb-libs
-postfix
-ql2100-firmware
-ql2200-firmware
-ql23xx-firmware
-ql2400-firmware
-ql2500-firmware
-rt61pci-firmware
-rt73usb-firmware
-snappy
-teamd
-tuned
-virt-what
-wpa_supplicant
-xorg-x11-drv-ati-firmware
-zd1211-firmware

Il y a de fortes chances que pour une machine vraiment en production, j'ai besoin d'un MTA, mais à moins de prévoir une configuration dès l'installation, postfix fait aussi partie des exclus. De cette manière, non seulement le système s'installe rapidement, mais il démarre aussi rapidement ! On arrive à un total inférieur à 220 paquets. Cela peut varier pour vous en particulier si vous installez un système avec du RAID logiciel, qui nécessitera l'installation de mdadm.

Et vous, est-ce que vous retireriez d'autres paquets ?

Hébergement de contenu : 4 services gratuits ou presque !

Quand on souhaite démarrer un site web, se pose parfois la question du coût et du type d'hébergement qu'on souhaite acquérir : quelles capacités, pour quoi faire, à quel tarif ? On peut aussi se poser la question de la qualité, et vouloir démarrer petit pour ensuite grandir au fur et à mesure. Et aussi minimiser le risque financier en cas d'échec ou d'abandon. J'ai donc sélectionné pour vous quelques hébergeurs web originaux, pour démarrer votre aventure !

Github Pages

Si le site que vous démarrez est relatif à un projet de logiciel, ou à tout autre contenu hébergé sur Github, alors choisir Github Pages vous permet de tout regrouper au même endroit. Vous pourrez, comme pour votre projet, gérer les versions de vos pages, via git, et même utiliser des générateurs de pages statiques, comme Jekyll ou Pelican. Il est toujours possible d'utiliser l'interface de Github pour éditer vos pages. De plus, Github Pages vous permet d'utiliser votre propre nom de domaine si vous le souhaitez ! Par contre, cela veut dire que les sources de votre site sont accessibles, à moins de payer pour un dépôt privé.

Surge

Surge vous propose aussi d'héberger des pages statiques gratuitement, mais ne propose pas de gestion de version. Le service, tel qu'il est présenté sur le site, se veut néanmoins orienté développeurs, et propose d'héberger votre site en une seule ligne de commande, en utilisant un client dédié à l'hébergeur. De plus, lorsque vous déployez votre site, celui-ci est répliqué sur le CDN de Surge. Autre point intéressant, celui de pouvoir utiliser son propre nom de domaine (il y a même des explications pour le faire). Enfin, Surge met aussi en avant l'utilisation d'un certificat SSL basique. Le client Surge est à mon sens une grande force mais aussi une grande faiblesse de ce service : bien que le code source soit disponible, je n'ai pas vu de licence, et pas vu non plus d'autre moyen de déployer le contenu.

Freeshell

J'ai déjà eu l'occasion de vous parler de Freeshell dans un billet précédent. On a donc plus qu'un simple hébergement de fichiers statiques, on dispose d'un accès par SSH avec des commandes limitées. Il est possible d'avoir un accès utilisateur bien plus complet en envoyant 1 dollar ou 5 euros, et des services supplémentaires sont accessibles à d'autres tarifs. Alors certes, ce n'est pas vraiment gratuit, mais on ne donne qu'une fois. Un service comparable a été lancé en Europe : SDFeu.

RHIEN

Le RHIEN n'est pas qu'un hébergeur. C'est une association regroupant des hébergeurs à but non lucratif, pratiquant souvent l'auto-hébergement, et attachés à certaines valeurs comme la neutralité du net ou le Logiciel Libre. Vous y trouverez certainement plus que de l'hébergement de fichiers statiques, puisque la plupart des hébergeurs proposent PHP et MySQL.

Ces quatre moyens d'hébergement ont chacun des particularités qui le rendent unique. Alors, plutôt développeur, déployeur, accès shell ou indépendant ?

Moi aussi j'ai des lutins qui courent très vite dans les fils !

Résumé des épisodes précédents : NetBSD et PXE sont de grands copains. Démarrer ce type d'OS en PXE est faisable, pas trop difficile, documenté dans la langue de Shakespeare ou dans celle de Molière que ce soit pour un système fini (merci iMil) ou juste pour l'installation (autopromotion sans honte).

Mieux vaut tard que jamais, j'ai décidé de tenter ma chance et de configurer un système NetBSD sans disque, suite à la présence à ${HOME} d'une machine graphiquement réduite mais disposant d'une puissance de calcul non négligeable, jugez plutôt :

marvin# egrep '(name|MHz)' /proc/cpuinfo 
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
cpu MHz         : 2100.35
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
cpu MHz         : 2106.73
model name      : AMD Phenom(tm) 8450 Triple-Core Processor
cpu MHz         : 2304.94
marvin# grep MemTotal /proc/meminfo
MemTotal:   3931368 kB

Merci à Madame de me laisser l'utiliser !

Je pourrais utiliser une clé USB, débrancher les disques durs et en ajouter un de mon stock. Mais ce ne serait pas drôle. J'ai utilisé les liens ci-dessus pour démarrer le brave Marvin via NFS, je ne vais donc pas paraphraser ces articles, mais ajouter ici quelques détails, remarques, trucs et peut-être astuces glanés ici et là et qui m'ont aidé.

D'abord, mieux vaut tester dans une machine virtuelle. Parce qu'aller chercher la bécane au fond sous le bureau, ça va une fois. Du coup, il faut s'assurer quand même qu'elle démarre sur le réseau, voire via Wake On LAN pour les plus fainéants. Sinon, une clé USB ou un CD Etherboot devrait faire l'affaire.

Ensuite, repérer la marque de la carte réseau et surtout potentiellement le pilote qui sera utilisé par NetBSD sera pratique : en effet, il faudra créer un fichier ifconfig.xy0, où xy0 sera remplacé par le nom du pilote de la carte réseau, dans mon cas c'est nfe0. Comment trouver le nom du pilote ? Soit on démarre un noyau NetBSD (l'installeur par exemple, qui permet d'obtenir un shell et d'exécuter dmesg | grep -i eth), soit on connaît le modèle de carte réseau et on cherche dans les sources. En ce qui me me concerne, je suis allé cherché la chaîne "NVIDIA" dans le fichier de configuration du noyau.

Toujours dans la catégorie réseau, si vous faites des tests en machine virtuelle, vous risquez probablement de le faire depuis un ordinateur portable connecté en Wi-Fi. Mieux vaut réfléchir un instant à la qualité de son réseau sans fil, et envisager de faire les tests en filaire. Mon expérience personnelle (VM simple cœur, 2Go de ram) : en Wi-Fi, le système démarre en plus de 5 bonnes minutes, en filaire (gigabit Ethernet) cela met moins d'une minute. 5 FICHUES MINUTES QUOI !!! En prime, dès que vous allez vouloir écrire ne serait-ce qu'un méga-octet sur le système, cela va se traîner. J'ai senti ma douleur quand je me suis rendu compte que j'avais oublié de décompresser un set.

J'ai eu une surprise sur le fichier /dev/null, il peut être nécessaire de le recréer :

marvin# cd /dev/
marvin# rm null
marvin# ./MAKEDEV -u all

L'installeur de NetBSD crée automatiquement certains fichiers ou paramètres. Sauf qu'on ne l'a pas utilisé... Parmi les trucs qu'il peut être utile de faire manuellement, il y a ces lignes dans /etc/fstab :

procfs                                          /proc            procfs  rw,auto,linux
kernfs                                          /kern            kernfs  rw
ptyfs                                            /dev/pts       ptyfs    rw

Il n'est pas obligatoire de monter /proc avec l'option linux, c'est juste un confort personnel. Ne pas oublier de créer les répertoires /proc/ et /kern/ avant.

Autre paramètre, celui de la date et de l'heure : par défaut, le système est en heure UTC, moi je veux l'heure de Paris. Pour cela, j'ai modifié le lien symbolique /etc/localtime :

marvin# readlink -f /etc/localtime
/usr/share/zoneinfo/Europe/Paris

Cela n'exclut pas le paramétrage NTP.

J'ai choisi de ne configurer qu'un seul partage NFS, car je n'envisage pas dans l'immédiat d'utiliser ce partage pour d'autres machines. Du coup, je n'ai initialement pas paramétré de swap, mais j'ai ajouté un fichier après coup, en utilisant la documentation officielle. Cela donne :

marvin# dd if=/dev/zero bs=1024k count=1024 of=/swapfile
marvin# chmod 600 /swapfile
marvin# swapctl -a -p 1 /swapfile
marvin# echo "/swapfile none    swap    sw,priority=1 0 0" >> /etc/fstab

Si comme moi vous avez déjà un serveur PXE en place, avec un fichier boot.cfg utilisé par pxeboot_ia32.bin, vous n'avez pas envie de mettre tous les noyaux, d'installation ou non, dans une longue liste. Il est possible de créer un deuxième fichier, qu'on donne à manger à pxeboot en lieu et place de boot.cfg. On le paramètre au niveau du serveur DHCP, par exemple pour ISC DHCP j'ai mis en place la configuration suivante :

host marvin {
        hardware ethernet 01:23:45:67:89:ab;
        fixed-address 192.168.1.13;
        option host-name "marvin";
        option root-path "/chemin/vers/diskless/nbmarvin";
        if filename = "boot.cfg" {
                filename "tftp:nbmarvin.boot.cfg";
        }   
}

On remarque donc que si pxeboot veut récupérer boot.cfg depuis la machine marvin, alors on lui servira nbmarvin.boot.cfg.

J'ai aussi remarqué que le clavier est en qwerty par défaut. Comme je n'ai pas relié de clavier ou d'écran à cette machine, et que j'ai configuré un accès SSH dès que possible, je n'ai pas changé ce paramètre. Toutefois, pour les pressés, vous pouvez utiliser la documentation officielle pour changer l'agencement du clavier.

Et sinon, pas de bol, la carte Wi-Fi PCI n'est pas reconnue :

vendor 0x1814 product 0x3060 (miscellaneous network) at pci1 dev 7 function 0 not configured

Bref, quelques notes en vrac qui, je l'espère, pourront s'avérer utile à l'occasion. Maintenant, il me reste à utiliser cette puissance de calcul à ma disposition (quelqu'un a dit bulk build pkgsrc ?).

vimrc global à son système

Quand on utilise Vim, on a tendance à personnaliser sa configuration en ajoutant ses options préférées dans son fichier ~/.vimrc. Sur un système GNU/Linux (mon expérience porte principalement sur RHEL/CentOS/Fedora), il est possible d'étendre cette personnalisation à tous les utilisateurs d'un système en modifiant /etc/vimrc. En revanche, côté NetBSD, le chemin n'est pas le même. On pourrait naïvement penser qu'il suffit d'utiliser le préfixe /usr/pkg, hein ? Bein non, loupé : le fichier par défaut pour tous les utilisateurs est /usr/pkg/share/vim/vimrc. Heureusement, rien d'insurmontable, et quelques liens symboliques bien placés permettront d'harmoniser les configurations sur tous les systèmes.

je m'en frotte encore les yeux

J'ai encore du mal à y croire : sur la page de la liste des développeurs NetBSD, on y trouve un "Nils". Et c'est moi.

Je. Suis. Développeur. NetBSD.

Je m'en frotte encore les yeux. Je me pince de temps en temps. Et il m'arrive d'aller vérifier sur la page, des fois que quelqu'un soit revenu sur la décision.

Bon allez, c'est pas tout, j'ai des paquets à commiter.

Propulsé par Dotclear