Monter un serveur d’authentification multifacteur 1/3

YubiKey-4-EdgeLe simple mot de passe est de plus en plus souvent pointé du doigt comme ne présentant plus les garanties requises pour l'authentification. L'alliance FIDO montre d'ailleurs l'exemple en assurant le développement et la promotion d'une infrastructure grand public d'authentification double facteur.

Quels outils pour l'authentification double facteur ?

Il est néanmoins des cas (nombreux) où FIDO et son U2F ne fonctionneront pas pour vous : pour toutes les authentifications qui ne passent pas par un navigateur web.

Pour tout le reste, et en particulier ce qui passe par PAM sur les UNIX et Linux, il existe quelques outils. Google Authenticator fonctionne bien, mais il nécessite que vous utilisiez un client type Google Authenticator, en général sur téléphone malin. Pour quelqu'un qui va s'authentifier rarement, disons 1 à 5 fois par semaine, c'est supportable : initier la connexion, sortir et déverrouiller son téléphone, lancer l'application, recopier le code temporaire (OTP), fermer l'application.
Sur un an je m'authentifie en ssh ou dans sudo environ 4000 fois. C'est à dire en moyenne plus de 11 fois par jour, pour des semaines de 7 jours.
En réalité je travaille toujours un peu moins le week end. Il en résulte qu'une journée de travail peut voir des pics autour de 60 authentifications.
Utiliser une authentification double facteur basée sur une appli mobile ou tout autre appareil affichant un code à recopier serait un échec dans un tel contexte.

C'est là que la Yubikey entre en jeu. Cette petite clé USB programmable est vue comme un clavier par votre ordinateur, et sur pression du doigt elle va taper pour vous l'OTP nécessaire à l'auth double facteur.
Par défaut elle s'appuie sur des serveurs externes pour valider votre OTP. Le jour où pour une raison X ou Y votre réseau n'accède plus à ces serveurs, vous ne pourrez donc plus vous authentifier (il existe malgré tout des contournements). C'est particulièrement problématique si vous tentez justement de reprendre la main sur votre firewall qui a décidé de bloquer l'accès à internet.
Heureusement, Yubico met à disposition de la communauté les outils nécessaires à la création d'un serveur de validation et d'un serveur de stockage des clés, permettant ainsi aux plus exigeants d'entre-nous de monter leur propre infrastructure d'authentification double facteur interne.

Ces outils sont bruts de fonderie, un peu mal dégrossis, et les instructions pour leur mise en place sont parfois approximatives. Le sujet devient encore plus épineux quand on tente de faire l'installation sur FreeBSD. Voici donc quelques instructions basées sur les notes prises lors de mes errances.

Monter des serveurs d'authentification Yubico sur FreeBSD

L'infrastructure d'authentification double facteur Yubico est composée de deux services : le service de validation (YK-VAL), c'est à dire celui auquel votre OTP va être envoyé par PAM, et qui donnera la réponse à PAM, et le service de stockage des clés (YK-KSM) sur lequel les clés des utilisateurs sont enregistrées.
Pour des raisons évidentes, il est recommandé de sécuriser au maximum ces deux services. L'idéal est donc de les installer sur deux machines différentes, et d'appliquer de la sécurité en profondeur dessus : firewall en entrée et sortie, si possible un réseau privé entre les deux serveurs, HTTPS partout, etc.

proposition d'infrastructure YK-VAL YK-KSM

Prérequis : pour aller au bout du process, il vous faudra acheter au moins une clé Yubikey, n'importe laquelle supportant "Yubico OTP".

Pour les besoins de cette maquette, j'ai créé 3 machines virtuelles FreeBSD 10.3. Une d'entre elle sera le serveur de validation ykval.patpro.net, une autre sera le serveur de clé yksm.patpro.net, et la dernière sera un serveur sshd sur lequel je souhaite activer l'authentification double facteur.

Serveur de validation YK-VAL

Sur une installation relativement vierge de FreeBSD 10.3, j'installe les composants suivants :

pkg install apache24 mod_php56 php56-xml php56-curl php56-hash bash sudo mysql57-server php56-pdo_mysql ykclient

Attention, pour une raison que je n'ai plus en tête, l'installation du serveur YK-KSM n'est pas compatible avec mysql57-server. Si vous installez YK-VAL et YK-KSM sur la même machine, choisissez mysql56-server !

Je récupère aussi les sources du serveur de validation Yubico :

fetch https://github.com/Yubico/yubikey-val/archive/master.zip
unzip master.zip

Et je tente de suivre les instructions présentées sur la documentation officielle Yubico. Je vous encourage à lire cette documentation en parallèle avec ce blog, car je ne reprends pas ici l'intégralité des explications.

Premier souci, le Makefile n'est pas fonctionnel sur FreeBSD, et j'ai du faire l'installation manuellement. J'ai tenté de scripter les choses un tout petit peu en créant automatiquement les répertoires manquants :

for DIR in $(awk '/prefix = / {print $3}' Makefile); do
	[ -d $DIR ] || mkdir -p $DIR
done

Puis en créant une série de variables qu'il faut injecter dans bash :

awk '/prefix = / {print $1"="$3}' Makefile
etcprefix=/etc/yubico/val
sbinprefix=/usr/sbin
phpprefix=/usr/share/yubikey-val
docprefix=/usr/share/doc/yubikey-val
manprefix=/usr/share/man/man1
muninprefix=/usr/share/munin/plugins
wwwprefix=/var/www/wsapi

Ensuite on peut copier les fichiers vers leur destination :

cp ykval-verify.php ${phpprefix}/ykval-verify.php
cp ykval-common.php ${phpprefix}/ykval-common.php
cp ykval-synclib.php ${phpprefix}/ykval-synclib.php
cp ykval-sync.php ${phpprefix}/ykval-sync.php
cp ykval-resync.php ${phpprefix}/ykval-resync.php
cp ykval-db.php ${phpprefix}/ykval-db.php
cp ykval-db-pdo.php ${phpprefix}/ykval-db-pdo.php
cp ykval-db-oci.php ${phpprefix}/ykval-db-oci.php
cp ykval-log.php ${phpprefix}/ykval-log.php
cp ykval-queue ${sbinprefix}/ykval-queue
cp ykval-synchronize ${sbinprefix}/ykval-synchronize
cp ykval-export ${sbinprefix}/ykval-export
cp ykval-import ${sbinprefix}/ykval-import
cp ykval-gen-clients ${sbinprefix}/ykval-gen-clients
cp ykval-export-clients ${sbinprefix}/ykval-export-clients
cp ykval-import-clients ${sbinprefix}/ykval-import-clients
cp ykval-checksum-clients ${sbinprefix}/ykval-checksum-clients
cp ykval-checksum-deactivated ${sbinprefix}/ykval-checksum-deactivated
cp ykval-nagios-queuelength.php ${sbinprefix}/ykval-nagios-queuelength
cp ykval-queue.1 ${manprefix}/ykval-queue.1
cp ykval-synchronize.1 ${manprefix}/ykval-synchronize.1
cp ykval-import.1 ${manprefix}/ykval-import.1
cp ykval-export.1 ${manprefix}/ykval-export.1
cp ykval-gen-clients.1 ${manprefix}/ykval-gen-clients.1
cp ykval-import-clients.1 ${manprefix}/ykval-import-clients.1
cp ykval-export-clients.1 ${manprefix}/ykval-export-clients.1
cp ykval-checksum-clients.1 ${manprefix}/ykval-checksum-clients.1
cp ykval-checksum-deactivated.1 ${manprefix}/ykval-checksum-deactivated.1
cp ykval-munin-ksmlatency.php ${muninprefix}/ykval_ksmlatency
cp ykval-munin-vallatency.php ${muninprefix}/ykval_vallatency
cp ykval-munin-queuelength.php ${muninprefix}/ykval_queuelength
cp ykval-munin-responses.pl ${muninprefix}/ykval_responses
cp ykval-munin-ksmresponses.pl ${muninprefix}/ykval_ksmresponses
cp ykval-munin-yubikeystats.php ${muninprefix}/ykval_yubikeystats
cp ykval-db.sql ${docprefix}/ykval-db.sql
cp ykval-db.oracle.sql ${docprefix}/ykval-db.oracle.sql

À ce stade on a installé différents scripts php dont le shebang est réglé sur un chemin "linux". On pourrait modifier tous les shebangs, mais il est plus simple de créer un lien symbolique de php au bon endroit :

ln -s /usr/local/bin/php /usr/bin/

Ensuite on s'attaque à la configuration de la base de données. J'ai opté pour MySQL, avec lequel je suis plus à l'aise.
Les étapes de la documentation officielle fonctionnent assez bien, mais les droits alloués à l'utilisateur ykval_verifier sont insuffisants. Il faut en effet lui donner les droits d'ajouter des clients dans la table ykval.clients. J'ai donc remplacé la ligne :

GRANT SELECT(id, secret, active) ON ykval.clients TO 'ykval_verifier'@'localhost';

par :

GRANT SELECT,INSERT,UPDATE ON ykval.clients TO 'ykval_verifier'@'localhost';

L'étape 4 de la doc. se résume à ces trois commandes :

mkdir /var/www/wsapi/2.0
ln -sf /usr/share/yubikey-val/ykval-verify.php /var/www/wsapi/2.0/verify.php
ln -sf /usr/share/yubikey-val/ykval-sync.php /var/www/wsapi/2.0/sync.php

L'étape 5 consiste à créer l'endroit où seront stockées les préférences de l'application, et à s'assurer qu'elles seront lisibles par Apache.

mkdir /etc/default
vi /etc/default/ykval-queue
ajouter la ligne : DAEMON_ARGS="/etc/yubico/val:/usr/share/yubikey-val"
vi /var/www/wsapi/2.0/.htaccess
ajouter les lignes suivantes : 
	RewriteEngine on
	RewriteRule ^([^/\.\?]+)(\?.*)?$ $1.php$2 [L]
	<IfModule mod_php5.c>
	  php_value include_path ".:/etc/yubico/val:/usr/share/yubikey-val"
	</IfModule>
cd /var/www/wsapi
ln -s 2.0/.htaccess /var/www/wsapi/.htaccess

À l'étape 6, il faut récupérer l'exemple de fichier de configuration ykval-config.php fourni avec le code de l'application, et le copier au bon endroit :

cp ykval-config.php /etc/yubico/val/

On édite ce fichier pour renseigner le mot de passe MySQL.

L'étape 7 permet de configurer Apache. Les instructions présentées sont valides pour apache 2.2, mais en version 2.4 il y a quelques modifications à faire. Notamment, autoriser l'accès se fait par la formule Require all granted. Il faut aussi activer le mod_rewrite qui n'est pas actif par défaut sur FreeBSD.

C'est l'occasion de configurer proprement le virtual host, d'activer SSL, etc.

Pour configurer syslogd lors de l'étape 8, il suffit d'ajouter la ligne suivante à /etc/syslog.conf :

local0.*              /var/log/ykval.log

et de faire un touch /var/log/ykval.log && service syslogd restart.

La rotation automatique pourra être gérée dans /etc/newsyslog.conf.

J'ai sauté l'étape 9, car je n'ai pas souhaité mettre en place de synchronisation entre différents YK-VAL pour cette maquette. C'est néanmoins une étape à valider si vous souhaitez mettre en place une infrastructure utilisable en production (ie. redondante).

À ce stade vous pourrez passer à l'étape 11. Cette dernière donnera sans doute lieu à de nombreux petits ajustements : config Apache, droits de fichiers, etc. Pas de panique, les logs fournissent normalement pas mal de pistes (notamment /var/log/ykval.log), et vous ne seriez pas ici si vous n'étiez pas capable de vous en sortir.

curl 'http://ykval.patpro.net/wsapi/2.0/verify?id=1&nonce=asdmalksdmlkasmdlkasmdlakmsdaasklmdlak&otp=dteffujehknhfjbrjnlnldnhcujvddbikngjrtgh'
h=CqcOcOH1yokoXcDimKDnElyP+f8=
t=2016-02-18T17:47:56Z0853
status=NO_SUCH_CLIENT

Lire la suite : la création du serveur YK-KSM.

Related posts

Mise à jour FreeBSD : impact sur SSL/TLS

Dans le cadre de mon travail, j'administre quelques serveurs de messagerie à fort trafic. Certains tournent sous FreeBSD. Toute modification de ces serveurs, clés de voûte de notre infrastructure de messagerie, doit se faire avec prudence et en comparant leur fonctionnement avant et après le changement. Je suis aidé en cela par Splunk, un collecteur de logs qui me permet de faire des analyses poussées.
Splunk est notamment très doué pour afficher des tendances, des évolutions, et permettre de représenter quelques secondes ou minutes vos données sous forme graphique. Notamment, à chaque mise à jour de l'antispam, de l'antivirus, de Perl ou d'autres composants critiques, il me permet de vérifier en quelques instants que le temps de traitement des messages dans les différents filtres n'est pas dégradé par la mise à jour.
La montée de version de FreeBSD 9.x vers FreeBSD 10.1 m'a notamment permis de bénéficier d'une version d'OpenSSL plus récente, et supportant TLS 1.2. Ce changement n'est pas anodin. SSL est mort, TLS 1.0 suit le même chemin, il faut donc pouvoir utiliser TLS 1.2.
Voyons l'impact de cette mise à jour sur les échanges chiffrés avec les autres serveurs de messagerie (ici, uniquement les messages sortants) :

Évolution de la version de TLS dans les échanges suite à la mise à jour du système

Évolution de la version de TLS dans les échanges suite à la mise à jour du système

Évolution des algorithmes de chiffrement dans les échanges suite à la mise à jour du système

Évolution des algorithmes de chiffrement dans les échanges suite à la mise à jour du système

Cette rapide analyse ne porte que sur les échanges chiffrés : les échanges de mails avec les serveurs ne permettant pas le chiffrement TLS ne sont pas représentés. La passerelle de messagerie dont il est question ici fait tourner trois instances postfix en "postfix-multi", et voit transiter trois à cinq millions de messages par mois selon la période de l'année.

Related posts

ZFS primary cache is good

Last year I've written a post about ZFS primarycache setting, showing how it's not a good idea to mess with it. Here is a new example based on real world application.
Recently, my server crashed, and at launch-time Splunk decided it was a good idea to re-index a huge apache log file. Apart from exploding my daily index quota, this misbehavior filed the index with duplicated data. Getting rid of 1284408 events in Splunk can be a little bit resource-intensive. I won't detail the Splunk part of the operation: I've ended up having 1285 batches of delete commands that I've launched with a simple for/do/done bash loop. After a while, I noticed that the process was slow and was making lots of disk IOs. Annoying. So I checked:

# zfs get primarycache zdata/splunk
NAME          PROPERTY      VALUE         SOURCE
zdata/splunk  primarycache  metadata      local

Uncool. This setting was set locally so that my toy (Splunk) would not harvest all ARC from the server, hurting production. For efficiency's sake, I've switched back the primary cache to all:

# zfs set primarycache=all zdata/splunk

Effect was almost instantaneous: ARC filled with Splunk data and disk IOs plummeted.

primarycache # of deletes per second
metadata 10.06
all 22.08

A x2.2 speedup on a very long operation (~20 hours here) is a very good argument in favor of primarycache=all for any ZFS user.

acceleration of a repetitive splunk operation thanks to ZFS primarycache setting

Acceleration of a repetitive splunk operation thanks to ZFS primarycache setting

Related posts

Création de mots de passe en ligne de commande

keychainLa création de nouveaux mots de passe est une activité assez peu passionnante, d'autant que dans certains contextes on peut être amené à répéter l'opération plusieurs fois par jour. Plutôt que d'avoir à réfléchir - et donc de produire un résultat influencé par les travers de l'esprit humain - il est préférable de s'en remettre totalement à la machine.
L'aléa est bien meilleur, et le résultat est obtenu bien plus facilement. Il est bien sûr question ici de vrais mots de passe : large palette de caractères, longueur correcte, totalement aléatoires.

Voici deux fonctions assez simples qui trouveront leur place tout naturellement dans votre .bashrc ou .bash_profile sur *BSD (FreeBSD, Mac OS X, etc.). La seule condition étant de disposer des commandes jot et rs déjà présentées dans les articles "jot et seq, créer des séquences en ligne de commande" et surtout "Les bons mots de passe…".

Cette première fonction crée 5 mots de passe aléatoires dont les caractères sont pris entre les codes ASCII 32 (espace) et 126 (tilde). Par défaut, ces mots de passe font 25 caractères de long, mais la commande génère en fait un tirage de 500 caractères, ce qui permet de fabriquer 5 mots de passe de 100 chiffres, lettres, symboles en indiquant la longueur souhaitée comme paramètre. L'astuce ici tient dans l'utilisation de la tabulation comme séparateur en sortie de jot, ce qui permet d'avoir l'espace présent dans les mots de passe en sortie.

mdp-complexe() {
jot -s $'\t' -r -c 500 32 126 | rs -c$'\t' -g0 0 ${1-25} | head -5
}

Exemple d'utilisation :

$ mdp-complexe 
fnc\Y}02PSc6}{;0`T}LOeN?\
5W Y1Y8!o<VlTA2vuE}SU)g?]
'kGhRa=u|hJW#;6aDd[A&UR_/
n|$_f3S?[`pO2":+0e<;aTi\v
.nU\i.PhbPE5TfuXY)g+DiN~g

En imposant la longueur :

$ mdp-complexe 50
9Tu1StsL $Gk@K<X\R)xKv{JXYe|g>L^2T;|*GMASee@HX.Epj
T%2 N;VvLFVi]s>_~xpo^~vD8b2.Fb$02ay9sLgjW#,TQ>8JAO
7EyWUC)Cqm2F,72mIf$#vh3<sTx%j>*v't{Fump=Fb5cJeZir$
RfS638d~a.T#StF.t3%Z*`RG)/?#; H?liH2DielVvs#4IBp0a
G`OyIOzpYtt5Sh!92/zdp7^C98r.OtIV8Fk_ilYCvVI6~e@17T

Cette seconde fonction est basée sur la première, mais un filtrage est imposé à la sortie de jot pour ne garder qu'un sous-ensemble des caractères générés. Ici, les caractères a-z, A-Z, 0-9, _, / et - sont conservés. L'approche est relativement simple : il suffit d'ajouter à la liste entre [ ] les caractères que l'on souhaite conserver dans les mots de passe :

mdp-simple() {
jot -s $'\t' -r -c 500 32 126 | sed "s,[^a-zA-Z0-9_/-]"$'\t'",,g"|\
 rs -c$'\t' -g0 0 ${1-25} | head -5
}

Ce qui donne :

$ mdp-simple 
y0q/EKoZKN9ZqGGhr1triaB0l
VMFUNYNpopAu9NleSv0BxuuTh
W07eE4ef1A99yAl0UmP6EHo6_
9X4CWx7qgML6qxn9Y0nxhONpr
lw_eY4DYY414mrllNxe/FSUfM

Stockez ensuite le mot de passe choisi dans votre trousseau de mots de passe sécurisé.

Related posts

Créer un trou noir DNS

Même si la question a déjà été largement traitée, je livre ici ma propre version d'un trou noir DNS. Le DNS blackhole, en anglais dans le texte, permet par exemple de s'assurer (dans une certaine mesure) que les utilisateurs de votre réseau ne peuvent pas se connecter trop facilement à des sites web vecteurs d'infection.
Le fonctionnement est simple : vous avez un réseau local, chez vous ou dans votre entreprise, et vous mettez à disposition de vos utilisateurs un serveur DHCP pour que les équipements qui se connectent puissent obtenir une adresse IP. Je pars du principe que sur ce réseau local, vous disposez aussi d'un serveur DNS. Un utilisateur se connecte avec votre réseau : le serveur DHCP lui donne une adresse IP pour que la nouvelle machine puisse parler sur le réseau, et fourni aussi l'adresse de votre serveur DNS. C'est donc par ce serveur que vous maitrisez que la machine de l'utilisateur va convertir les noms de domaine (www.patpro.net) en adresse IP (193.30.227.216).
Comme vous avez la maîtrise du serveur DNS, vous avez la maîtrise de la résolution des noms de domaine. Vous pouvez donc décider de bloquer la résolution de certains noms de sites web qui posent problème (gros pourvoyeurs de malware, régies publicitaires, facebook, etc.).

Je vais me baser ici sur la liste de malwaredomains.com qui regroupe environ 20000 noms de domaine qui sont, ou ont été, impliqués dans la distribution de malware (en général en infectant le visiteur imprudent). Il s'agit donc pour moi de défendre mon réseau en protégeant les utilisateurs.

Les informations sont largement inspirées - voire pompées - de la prose anglophone de Paul.

Pré-requis : un serveur DNS BIND que vous maîtrisez, et un réseau avec serveur DHCP qui indique l'adresse IP du DNS, de sorte que les clients qui se connectent utiliseront par défaut le serveur DNS sus-mentionné. Il faut bash, curl, et jot (sur linux il faut remplacer jot par seq).

Obtenir la liste des zones DNS à mettre en trou noir.

Préparer le lieu de stockage :

mkdir /etc/namedb/blackhole

J'utilise le script suivant, à lancer en root via une crontab (une fois par semaine suffit) :

#!/usr/local/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
ZONEFILE=/etc/namedb/blackhole/spywaredomains.zones
MIRRORS[1]="http://mirror1.malwaredomains.com/files/spywaredomains.zones"
MIRRORS[2]="http://mirror2.malwaredomains.com/files/spywaredomains.zones"
MIRRORS[3]="http://dns-bh.sagadc.org/spywaredomains.zones"

# fonctionne sur BSD uniquement, pour linux il faut
# remplacer par `seq`
CHOOSE=$(jot -r 1 1 ${#MIRRORS[@]})

if [[ "$(/usr/local/bin/curl ${MIRRORS[CHOOSE]} -z ${ZONEFILE} -o ${ZONEFILE}_new -s -L -w %{http_code})" == "200" ]]; then
	rm -f ${ZONEFILE}_old
	mv ${ZONEFILE} ${ZONEFILE}_old
	mv ${ZONEFILE}_new ${ZONEFILE}
	named-checkconf -z | grep -v ": loaded serial"
	if [ ${PIPESTATUS[0]} -eq 0 ]; then
		service named restart
	else
		echo "Error loading new zone file, reversing..."
		mv ${ZONEFILE} ${ZONEFILE}_invalid_$(date "+%Y%m%d")
		mv ${ZONEFILE}_old ${ZONEFILE}
	fi
fi

C'est loin d'être foolproof, mais ça fait le travail. Les options de curl permettent de ne télécharger le fichier que si il a été modifié depuis votre dernière mise à jour. le script choisit un miroir au hasard au moment de faire le comparatif ce qui évite de charger toujours le même serveur.

Configurer BIND pour gérer les zones téléchargées.

Il faut ajouter dans la configuration du serveur DNS une directive d'inclusion du fichier téléchargé ci-dessus. Il suffit pour cela d'ajouter la ligne suivante à la fin du fichier /etc/named/named.conf :

 include "/etc/namedb/blackhole/spywaredomains.zones";

Le fichier spywaredomains.zones fait pointer chaque zone vers un unique fichier de définition qu'il convient de créer et de renseigner : /etc/namedb/blockeddomain.hosts.
Ce fichier contient une définition minimaliste de zone DNS BIND. Faites-la pointer vers un serveur web existant, cela vous permettra d'afficher à vos utilisateurs une page web d'explication :

$TTL    86400   ; one day
@       IN     SOA    NOM-DE-VOTRE-SERV-DNS. NOM-DE-VOTRE-SERV-DNS. (
	1
	28800   ; refresh  8 hours
	7200    ; retry    2 hours
	864000  ; expire  10 days
	86400 ) ; min ttl  1 day

	NS     NOM-DE-VOTRE-SERV-DNS.

	       A       IP-DE-VOTRE-SERVEUR-WEB
*	IN     A       IP-DE-VOTRE-SERVEUR-WEB

Si vous ne souhaitez pas informer vos utilisateurs, remplacez simplement IP-DE-VOTRE-SERVEUR-WEB par 127.0.0.1. Mais je recommande tout de même la publication d'une page web d'information sur la quelle les utilisateurs pourront arriver si ils tentent de joindre un domaine présent dans la liste noire.

Avec ça, votre serveur DNS est transformé en trou noir pour l'ensemble des domaines répertoriés chez malwaredomains.com. En analysant les logs de votre serveur web, vous pourrez aussi déterminer rapidement qui sur votre réseau est infecté ou risque de l'être.

Références.

edit : correction d'une coquille dans le script

Related posts

Chiffrer un répertoire sur FreeBSD avec PEFS

La sécurité des données numériques est au cœur des enjeux actuels, et pas seulement pour les professionnels. Pouvoir chiffrer ses propres données pour les rendre inutilisables pour un voleur éventuel, est donc une nécessité. Sous FreeBSD il est possible de faire du chiffrement sur l'ensemble du disque avec geli(8) ou gbde(4), ou sur un répertoire uniquement avec PEFS. Les deux premières solutions opèrent un chiffrement au niveau bloc. Elles travaillent sur des devices de taille fixe, et ne protègent pas vos données si un pirate accède à la machine quand elle est allumée et que les disques chiffrés sont montés.
PEFS permet de travailler sur un répertoire donc sans avoir à fixer un volume arbitraire au moment de l'initialisation. Le chiffrement se fait au niveau fichier avec une ou plusieurs clés autorisant la hiérarchisation des accès.

fichiers-chiffres-avec-PEFS

Installer PEFS

PEFS est disponible dans les ports et dans les packages. Il est recommandé de faire l'installation par les ports. En effet, l'outil contient un module pour le kernel, et un trop grand écart entre la version de votre noyau et celle qui a servi à la compilation du package peut générer un panic et geler votre système. Aussi, avec un processeur récent vous pourrez activer AES-NI au moment de la compilation du port (accélération matérielle pour le chiffrement AES).

$ cd /usr/ports/sysutils/pefs-kmod
$ sudo make install clean

Pour charger le module automatiquement au redémarrage, ajouter cette ligne dans votre /boot/loader.conf :

pefs_load="YES"

Utiliser PEFS

PEFS s'utilise assez simplement. Il faut commencer par créer un répertoire vide pour stocker les fichiers chiffrés. On peut créer un second répertoire qui servira de point de montage pour la version déchiffrée, mais le montage peut aussi se faire sur le premier répertoire.

$ mkdir ~/coffre.pefs ~/coffre

Ensuite on monte le répertoire (soit vers lui-même, soit comme ici vers un autre pour des raisons de clarté) :

$ sudo pefs mount ~/coffre.pefs ~/coffre

À ce stade, le répertoire ~/coffre est en lecture seule, car nous n'avons pas encore fourni de clé de chiffrement.

$ touch ~/coffre/toto
touch: coffre/toto: Read-only file system

L'ajout d'une clé est une étape simple, mais la documentation officielle manque légèrement d'explications. Il ne s'agit pas ici de fournir une clé une fois pour toute, mais de dire à PEFS de travailler pour la session courante avec cette clé. Si le répertoire est démonté, ou si les clés sont vidangées (flushkeys) il faudra fournir la même clé à nouveau pour accéder aux fichiers.

$ pefs addkey ~/coffre
Enter passphrase: (mot de passe pour (dé)chiffrer vos fichiers)
$ touch ~/coffre/toto
$ ls -A1 ~/coffre*
/home/me/coffre:
toto                               <- version en clair

/home/me/coffre.pefs:
.SfoQ93cCWWT+NnBB7EYE2ZK402YDSwsT  <- version chiffrée

Pour interdire l'accès à vos données vous pouvez simplement utiliser la commande flushkeys, ou aller jusqu'au démontage du répertoire:

$ pefs flushkeys ~/coffre
$ ls -A1 ~/coffre*
/home/me/coffre:
.SfoQ93cCWWT+NnBB7EYE2ZK402YDSwsT  <- version chiffrée

/home/me/coffre.pefs:
.SfoQ93cCWWT+NnBB7EYE2ZK402YDSwsT  <- version chiffrée
$ sudo pefs unmount ~/coffre
$ ls -A1 ~/coffre*
/home/me/coffre:
(vide)

/home/me/coffre.pefs:
.SfoQ93cCWWT+NnBB7EYE2ZK402YDSwsT  <- version chiffrée

Le démontage est facultatif, mais si vous utilisez PEFS dans des scripts, c'est sans doute plus propre. Aussi, faites bien attention, il est possible de monter plusieurs fois le même répertoire au même endroit ce qui peut déboucher sur des situations tout à fait inconfortables. En cas d'utilisation automatisée mettez les bouchées doubles sur les contrôles avant et après chaque commande.

Après le flushkeys, les données sont présentées uniquement dans leur forme chiffrée, mais vous y avez toujours accès ce qui vous permet par exemple de les exporter vers un cloud de sauvegarde (Amazon Glacier, par exemple) en toute sérénité.

Pour déchiffrer vos données, et en admettant que le répertoire soit déjà monté, il vous suffit de reproduire l'étape addkey avec la même clé :

$ pefs addkey ~/coffre
Enter passphrase:

Si à cette étape vous changez la valeur de la clé (volontairement ou par faute de frappe), la nouvelle clé sera acceptée par PEFS. Cette nouvelle clé ne vous donnera pas accès aux anciennes données bien évidemment. Par contre elle vous permettra de stocker de nouveaux fichiers, qui seront chiffrés grâce à cette nouvelle clé. C'est à la fois dangereux et pratique. Si la faute de frappe est votre ennemi vous pouvez jouer la prudence et utiliser un trousseau de clé. Le trousseau se trouve dans le fichier ~/coffre.pefs/.pefs.db et il stocke la ou les clés "officielles" de votre choix. L'initialisation du trousseau se fait avec la commande addchain :

$ pefs addchain -f -Z ~/coffre.pefs

Ensuite, il vous suffira lorsque vous fournirez votre clé de le faire avec l'option -c pour que votre saisie soit comparée au contenu du trousseau :

$ pefs addkey -c ~/coffre

Cela offre une sécurité intéressante mais impose aussi la contrainte d'avoir un fichier dont il faudra prendre soin (attention aux rsync qui pourraient le supprimer si vous utilisez PEFS pour stocker des sauvegardes dans un répertoire chiffrés).

Il existe d'autres possibilités au logiciel PEFS que je ne détaille pas ici, notamment celle de stocker dans le trousseau .pefs.db des chaînes de clés avec héritage parent-enfant, ou encore le module PAM pam_pefs.so qui permet de fournir le montage et le déchiffrement automatique du ~/ d'un utilisateur au moment où il s'authentifie.

Un peu de lecture

Wiki FreeBSD au sujet de PEFS
Tutoriel PEFS
Audit de sécurité rapide sur PEFS

Related posts

S’envoyer des SMS multilignes via l’API de free-mobile

Free vient de mettre à disposition de ses abonnés Free-mobile un moyen simple de générer via une API accessible en ligne des SMS à soi-même. L'utilisation est globalement très simple et tient presque toutes ses promesses (actuellement il ne semble pas possible de faire du POST, seul le GET fonctionne).
Il suffit aux intéressés de se rendre sur leur interface de gestion de compte Free-mobile, dans la section "Mes options", et d'y activer (vers le bas de la page) l'option ad-hoc. Une fois l'option activée, Free vous gratifie d'un mot de passe dédié à cet usage, et vous renseigne un peu sur le fonctionnement du service :

free-mobile-notification

Une fois l'option activée, l'utilisation se résume à une requête HTTP de cette forme :

curl 'https://smsapi.free-mobile.fr/sendmsg?user=***&pass=***&msg=coucou'

Vous recevez alors sur votre téléphone Free-mobile le SMS contenant le message "coucou".

La création d'un message multiligne est un peu plus délicate. La plupart des plateforme Unix/Linux envoie en guise de séparateur de ligne un \n qui se traduit par %0a une fois "url-encodé". Malheureusement, l'API n'accepte pas ce %0a et le message sera tronqué à la première occurrence.
Par contre, le séparateur de ligne \r, encodé en %0d est bien accepté par l'API Free-mobile. Il faut donc, avant d'envoyer un message sur plusieurs lignes, traduire les \n en \r.

J'ai conçu un script shell pour mes besoins personnels. Il prend ses données en entrée standard, par exemple via un pipe :

echo "mon message" | sms.sh

Ce qui est plus souple pour moi dans bien des situations, que de devoir invoquer le script et de lui servir le message comme argument, par exemple :

autresms.sh mon message

Voici donc le code de mon script qui prend les messages via stdin, et qui converti les \n en \r. Notez que le SMS à l'arrivée ne contient pas de saut de ligne, donc prévoyez des espaces en fin de ligne si vous ne voulez pas que la fin de ligne soit collée au début de la ligne suivante.

#!/usr/local/bin/bash  
#
# push notification via smsapi.free-mobile.fr
#
LOGGEROPT="-p security.notice -t SMS"
REPLOGG=1
REPMAIL=1
MAILTO=root
USR="****"
PSW="****"
URL="https://smsapi.free-mobile.fr/sendmsg"
CURL=/usr/local/bin/curl

report() {
        [ ${REPLOGG} -eq 1 ] && echo $@ | logger ${LOGGEROPT}
        [ ${REPMAIL} -eq 1 ] && echo $@ | mail -s "SMS $@" ${MAILTO}
}

eval $(${CURL} --insecure -G --write-out "c=%{http_code} u=%{url_effective}" \
        -o /dev/null -L -d user=${USR} -d pass=${PSW} --data-urlencode msg="$(cat|tr '\n' '\r')" ${URL} 2>/dev/null | tr '&' ';')

echo ${c} ${u}\&pass=***\&msg=${msg} | logger ${LOGGEROPT}

case ${c} in
        "200")
                exit 0
                ;;
        "400")
                report "parameter missing" ; exit 400
                ;;
        "402")
                report "too many SMS..." ; exit 402
                ;;
        "403")
                report "service unavailable for user, or wrong credentials" ; exit 403
                ;;
        "500")
                report "server error, try later" ; exit 500
                ;;
        *)
                report "unexpected result" ; exit 600
                ;;
esac

Utilisation :

echo "mon message 
sur plusieurs 
lignes" | sms.sh

Il reste à faire :
- ajouter l'enregistrement dans les log système de chaque utilisation du script sms.sh
- ajouter la gestion des codes de retour HTTP autres que 200.

Attention
Pour bénéficier d'une gestion d'erreur et d'une trace dans les log de la machine j'ai utilisé une grosse ruse très sale avec eval. Cela permet de créer des variables à la volée à partir de données fournie par l'utilisateur. C'est éminemment risqué car tout ce est qui généré par c=%{http_code} u=%{url_effective} sera évalué sans distinction (avec potentiellement des exécutions de code).
Pour un système de monitoring c'est un risque négligeable : les messages sont connus et fixés par le logiciel qui les génère, sans interaction avec l'utilisateur. Pour une utilisation dans tout autre mécanisme la prudence est requise.

Related posts

ZFS primarycache: all versus metadata

In my previous post, I wrote about tuning a ZFS storage for MySQL. For InnoDB storage engine, I've tuned the primarycache property so that only metadata would get cached by ZFS. It makes sense for this particular use, but in most cases you'll want to keep the default primarycache setting (all).
Here is a real world example showing how a non-MySQL workload is affected by this setting.

On a virtual server, 2 vCPU, 8 GB RAM, running FreeBSD 9.1-RELEASE-p7, I have a huge zpool of about 4 TB. It uses gzip compression, and stores 1.8TB of emails (compressratio 1.61x) and 1TB documents (compressratio 1.15x). Documents and emails have their own dataset, on the same zpool.
As it's a secondary backup server, isolated from production, I can easily make some tests.

I've launched clamscan (the binary part of ClamAV virus scanner) against a small branch of the email storage tree (about 1/1000 of total emails) and measured the zpool IOs, CPU usage and total runtime of the scan.
Before each run, I've rebooted the server to clear cache.
clamscan is set up so that every temporary files are written into a UFS2 filesystem (/tmp).

One run was made with property primarycache set to all, the other run was made with primarycache set to metadata.

Total runtime with default settings primarycache=all is less than 15 minutes, for 20518 files:

Scanned directories: 1
Scanned files: 20518
Infected files: 2
Data scanned: 7229.92 MB
Data read: 2664.59 MB (ratio 2.71:1)
Time: 892.431 sec (14 m 52 s)

Total runtime with default settings primarycache=metadata is more than 33 minutes:

Scanned directories: 1
Scanned files: 20518
Infected files: 2
Data scanned: 7229.92 MB
Data read: 2664.59 MB (ratio 2.71:1)
Time: 2029.921 sec (33 m 49 s)

zpool iostat every 5 seconds, with different primarycache settings, ~10 minutes range.

zpool IO stats

CPU usage for clamscan process, and for kernel{zio_read_intr_0} kernel thread. 5 seconds sampling, with different primarycache settings, ~10 minutes range.

CPU stats

In both tests, the server is freshly rebooted, cache is empty. Nevertheless, when primarycache=all the kernel{zio_read_intr_0} thread consumes very few CPU cycles, and the clamscan process run's more than twice as fast as the same process with primarycache=metadata.
More importantly, clamscan manages to read the exact same amount of data in both tests, using 10 times less IO throughput when primarycache is set to all.

There is something weird. Let's make another test:

I create 2 brand new datasets, both with primarycache=none and compression=lz4, and I copy in each one a 4.8GB file (2.05x compressratio). Then I set primarycache=all on the first one, and primarycache=metadata on the second one.
I cat the first file into /dev/null with zpool iostat running in another terminal. And finally, I cat the second file the same way.

The sum of read bandwidth column is (almost) exactly the physical size of the file on the disk (du output) for the dataset with primarycache=all: 2.44GB.
For the other dataset, with primarycache=metadata, the sum of the read bandwidth column is ...wait for it... 77.95GB.

There is some sort of voodoo under the hood that I can't explain. Feel free to comment if you have any idea on the subject.

A FreeBSD user has posted an interesting explanation to this puzzling behavior in FreeBSD forums:

clamscan reads a file, gets 4k (pagesize?) of data and processes it, then it reads the next 4k, etc.

ZFS, however, cannot read just 4k. It reads 128k (recordsize) by default. Since there is no cache (you've turned it off) the rest of the data is thrown away.

128k / 4k = 32
32 x 2.44GB = 78.08GB

Damnit.

Related posts