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 & 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 !

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/*

Propulsé par Dotclear