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

Koken : le portfolio web des photographes

Depuis quelques temps je traîne un WordPress dédié à mes photos, histoire de présenter un peu ce que je fais, sans tout mélanger avec le présent blog. Le truc c'est que WordPress n'est pas fait pour ça. Sa gestion d'images, bien que très correcte pour un CMS, reste limitée. Les thèmes de présentation ne sont pas terribles, je n'en ai jamais trouvé un qui me plaise vraiment.
Puis j'en avais marre de ces failles de sécurité presque hebdomadaires : je passe plus de temps à administrer les noyaux WordPress qu'à m'en servir pour publier des choses.

Les thèmes de koken sont aussi entièrement "responsive"

Les thèmes de koken sont aussi entièrement "responsive"

Il était donc temps de changer. Après une courte recherche, je suis tombé presque par hasard sur Koken. Doté d'un scepticisme hors du commun quand il s'agit des applications web, a fortiori codées en PHP, j'ai tout d'abord cru que Koken était comme les autres : mal conçu, plein de parti-pris et de choix techniques imposés par des développeurs plutôt que par des photographes. J'ai approché l'objet avec cautèle, prêt à le vouer aux gémonies et sautant sur la moindre occasion pour râler et montrer du doigt ici un comportement inadmissible ou là une fonctionnalité mal implémentée. "Ha ! Je vous l'avais bien dit" m'apprêtais-je à exulter.

Lâs ! Mal m'en a pris, j'étais dans l'erreur. Koken c'est de la grosse bombe.

C'est tout d'abord une application vraiment bien pensée. Elle atteint un degré de fonctionnalité et d'ergonomie rarement vu sur des applications gratuites, et plus particulièrement dans ce segment (CMS/Portfolio auto-hébergé). Toute sa gestion de contenu est bien conçue, et pour ceux qui utilisent Photoshop Lightroom, l'intégration est poussée au maximum avec la possibilité de publier directement à partir de LR vers ses albums dans Koken. Je ne suis pas fan des applications web qui tentent d'imiter le fonctionnement et l'ergonomie des applications "lourdes". Là encore, je mets ma critique dans la poche, Koken réussi ce pari de fournir une expérience utilisateur quasi parfaite.

Un des principes de base de Koken est de partir de vos photos dans leur version la plus grande et lourde. En général, on publie des photos sur internet sous une taille limitée, pour qu'elles soient légères, plus vite téléchargées et affichées sur l'écran du visiteur. Ici il faut prendre le contre-pied total de cette démarche d'optimisation. En postant l'image la plus grosse possible, vous préparez l'avenir. Vous supportez dès maintenant les écrans "retina", et vous n'aurez pas besoin de republier des photos en haute définition plus tard, quand le débit des connexions aura encore grimpé.
Je viens de le faire : j'ai parcouru mon blog photo WordPress, j'ai fait l'inventaire de toutes les photos publiées, à l'époque en 800px de large, j'ai retrouvé ces photos dans Lightroom, je les ai réexportées dans Koken en grand format. J'avais déjà du le faire en 2012 en passant de PixelPost à WP, c'est incroyablement laborieux, et si mon ancien portfolio avait contenu les fichiers en haute définition j'aurai gagné un temps fou. Mais désormais je suis paré, prêt pour l'avenir.

Sur le plan technique Koken est aussi une application très abordable. Elle ravira tous les photographes qui n'aiment pas bricoler sur un serveur, configurer des bouts de machins, se battre avec des fichiers php. L'installation se fait assez simplement : vous vous assurez de disposer d'une base de données, et vous téléchargez un fichier "index.php" que vous déposez sur un serveur dans son répertoire "koken". Vous accédez ensuite à cette page via un navigateur et vous suivez les instructions.
Et c'est là ma seule et unique réserve au sujet de Koken : la manière pas très transparente qu'ils ont de collecter des informations sur l'utilisateur. En effet, pour installer réellement le logiciel à partir de la page index.php, il faut s'enregistrer (adresse email, nom, prénom, ...). Heureusement on peut toujours donner des informations bidons (même pour l'adresse email). Je trouve le procédé pas très classe. En fait, le produit est tellement bon que je pourrais payer si ça me dispensait de cette procédure d'enregistrement.
Bref, une fois enregistré, tout se fait rapidement : la dernière version de l'application est téléchargée, installée et configurée.

Le travail technique est terminé, il reste le plus dur : décider de votre workflow, de la manière dont vous allez organiser vos photos, des albums, sets, et catégories que vous allez créer pour classer votre production, et bien sûr choisir un thème. Surtout, n'hésitez pas à repousser le choix du thème à la toute fin. Dès que vous avez l'assurance que quelques uns vous plaisent, ne perdez pas de temps dessus et concentrez-vous sur les photos. Revisitez votre bibliothèque Lightroom, décidez quoi faire de vos tags, réfléchissez aux réglages d'import initial des images dans Koken, etc.
Le choix du thème peut vraiment arriver en dernier : certains utilisent les tags, d'autres pas, certains affichent le nom du fichier, d'autres pas, et souvent ils disposent de nombreux réglages, si bien qu'il est probablement plus intéressant de consolider le contenu du portfolio avant de s'attaquer à la présentation.

Pour résumer, je suis totalement conquis (et c'est rare).

Related posts

Firefox mange mon CPU

Comme je suis vieux et extrémiste, j'ai décidé de ne pas adhérer aux mises à jour continuelles des systèmes d'exploitation Apple. Ce que proposent les nouvelles versions est rarement intéressant (cloud, flicage des utilisateurs, baisse des performances, App Store, etc.).
Le souci avec les vieux logiciels, c'est le manque de sécurité qu'ils offrent. Les nouveaux ne valent guère mieux, mais la mesure du risque se fait sur le nombre de failles connues, et donc à ce compte là, les anciennes versions sont toujours perdantes. Ne faisant plus évoluer mon système, mais passant mon temps sur internet, j'ai donc du m'adapter : virer mon Safari préhistorique, et installer un navigateur bien à jour, au taquet, fourni par un éditeur qui lui ne se fout pas de ma gueule (comprendre qu'il n'oblige pas les gens à acheter un nouveau Mac pour bénéficier d'un navigateur web à jour).

Bref, j'utilise Firefox.

J'en étais content, jusqu'au moment où j'ai trouvé qu'il était relativement lent, puis lent, puis très lent, puis très très lent. En fait, ce navigateur mange mon CPU. Petit à petit. Si vous êtes le genre d'utilisateur qui allume/éteint sa machine tous les jours, vous n'avez pas ce problème. Mais si vous laissez le chauffage d'appoint allumé 24/7/365, alors vous pourriez constater ce genre de chose :

firefox_cpu-580

Avec le temps qui passe Firefox consomme de plus en plus de cycles de processeur. Après une poignée d'heures, il est environ à 18%. Sans rien faire avec, 200 minutes plus tard il consomme 21% du CPU. Après 1000 minutes, il oscille entre 33 et 35% CPU.
On constate aussi que le nombre de threads de l'application gonfle tranquillement.

J'ai tenté d'accuser les extensions, mais je n'en utilise que 2 et une fois désactivées Firefox avait le même comportement. J'ai aussi tenté d'analyser le comportement du navigateur avec Instruments, sans succès. Je ne comprends pas d'où vient le souci. Peut être d'une des pages web que je garde ouvertes en permanence… Quoi qu'il en soit, c'est un peu dommage, je vais devoir programmer un redémarrage de Firefox toutes les nuits

Related posts

Rotation des clés DKIM

La signature des emails par clé DKIM est une composante importante d'un système de messagerie sain et bien géré. Comme tout système cryptographique fonctionnant sur la base d'un couple clé publique / clé privée, il est nécessaire de renouveler les jeux de clés régulièrement.
En effet, plus longtemps une même clé est utilisée, plus elle a de chance d'être cassée. De la même manière, plus elle est petite, plus elle sera facilement cassée.
Comme toujours, avec la correspondance par email, rien n'est instantané. Contrairement à un serveur web par exemple qui pourrait changer de certificat SSL en quelques minutes et faire immédiatement disparaître l'ancien de la circulation, les clés DKIM doivent changer selon un roulement tuilé : quand la nouvelle clé remplace l'ancienne, cette dernière doit rester disponible encore quelques temps pour permettre la validation des signatures présentes dans des messages encore en cours de livraison.
Ainsi, le besoin de faire tourner régulièrement les clés DKIM tout en garantissant un tuilage, ajouté à la complexité (relative) d'une architecture mixte à base de serveur DNS, serveur de mail, logiciel de signature DKIM, rendent nécessaire la mise en place d'une procédure claire, fiable et automatique.

Évolution de l'utilisation de DKIM mesurée au niveau de l'antispam en entrée de mon serveur de mails

Évolution de l'utilisation de DKIM mesurée au niveau de l'antispam en entrée de mon serveur de mails, entre fin 2005 et début 2015

Pour mes propres besoins, j'ai conçu un script shell utilisable pour faire tourner les clés d'un domaine donné. Ce script s'appuie sur un serveur Bind local : la modification des zones DNS se fait par modification directe des fichiers. Il utilise l'implémentation DKIM de OpenDKIM.
Il serait tout à fait possible de concevoir un script qui utilise un serveur DNS distant ou local via la commande nsupdate(8), mais cette approche laisse la main totalement à Bind pour l'écriture des fichiers de zones. Il fait alors disparaître tous les commentaires, il change l'ordre des enregistrements, etc. Ce n'était pas souhaitable pour moi qui stocke des informations en commentaire dans mes fichiers de zones.

Prérequis pour utiliser ce script

- Être root sur le serveur ;
- Disposer d'un serveur DNS Bind, ou compatible (c'est OpenDKIM qui écrit les enregistrements DNS), maître pour les zones concernées par la rotation de clés ;
- Disposer sur la même machine d'une installation OpenDKIM fonctionnelle ;
- Avoir une version de sed qui supporte l'option -i (in place).

Comportement

Le premier argument obligatoire du script est l'action : renouvellement ("new") ou nettoyage ("clean"). Le second argument obligatoire est le domaine cible et le troisième argument (facultatif) est la longueur des nouvelles clés.
Pour l'action "new" et un domaine donné, le script renouvelle l'ensemble des clés DKIM. Par défaut, il génère des clés de la même longueur que celles qu'il remplace, et les sélecteurs sont nommés en `date "+%Y%m"` suivi d'un tiret et des 8 premiers caractères retournés par la commande uuidgen(1). Si une longueur de clé est imposée en argument, l'ensemble des clés du domaine utilisera cette nouvelle valeur. Pour l'action "clean" et un domaine donné, le script vidange les anciennes clés.
Pour assurer un tuilage d'une semaine par exemple, il faut donc le jour J lancer le script avec "new", et à J+7 lancer le script avec "clean" sur le même domaine. Ainsi, avant le jour J, la clé N est utilisée pour signer les messages. À partir du jour J, la clé N+1 est utilisée pour signer les messages, mais la clé N est encore disponible pour vérifier de vieux messages qui seraient encore en circulation. À partir de J+7, l'ancienne clé N disparaît.

Syntaxe des fichiers de zone DNS

Deux contraintes ici :
- Le numéro de série de la zone doit être seul sur sa ligne et suivi du commentaire " ; Serial" pour que le script puisse facilement le localiser et l'incrémenter.
- Les enregistrements DNS des clés DKIM doivent être en inclusion dans le fichier de la zone et résider respectivement dans le fichier dkim-active.${DOMAIN} pour les clés actives et dans le fichier dkim-retired.${DOMAIN} pour les clés inactives. Cela donne pour le fichier de zone patpro.net :

...
$INCLUDE "/etc/namedb/master/dkim-active.patpro.net"
$INCLUDE "/etc/namedb/master/dkim-retired.patpro.net"
...

Ainsi, le script peut très facilement déplacer les clés actives vers le fichier dkim-retired quand de nouvelles clés sont fabriquées et intégrées à dkim-active.

OpenDKIM

Les clés doivent être rangées par domaine, dans des répertoires qui portent le nom du domaine. Cela donne chez moi :

opendkim/patpro.net/201501-62e79011.private
opendkim/patpro.net/201501-62e79011.txt
opendkim/patpro.net/201501-82a3edc5.private
opendkim/patpro.net/201501-82a3edc5.txt
opendkim/proniewski.net/201502-e47af46c.private
opendkim/proniewski.net/201502-e47af46c.txt

Les clés utilisées doivent être référencées dans un fichier KeyTable unique que le script analyse pour retrouver les sélecteurs à remplacer, et réécrit avec les nouveaux sélecteurs.

Utilisation

crontab pour renouvellement automatique mensuel :

0 0 1 * *    /usr/local/sbin/rotate-dkim.sh new patpro.net
0 0 8 * *    /usr/local/sbin/rotate-dkim.sh clean patpro.net

ligne de commande pour changer la taille des clés d'un domaine :

rotate-dkim.sh new proniewski.net 2048

Corpus Scripti

#!/usr/local/bin/bash
# rotate DKIM keys
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# settings
ACTION=${1}
DOMAIN=${2}
NBITS=${3}; NBITS=$(( $NBITS+0 )) # force number
CHROOT=/var/db/opendkim
GENKEY=/usr/local/sbin/opendkim-genkey
KeyTable=/usr/local/etc/opendkim/KeyTable
ZONEROOT=/etc/namedb/master
USERGROUP=root:opendkim
ARCHIVE=/tmp/
MAXKEY=4096
MINKEY=512

onerror() {
case "$1" in
	"args")
		echo "usage: $(basename $0) new|clean domain.name [bits]"; exit 1
		;;
	"chroot")
		echo "\$CHROOT must exist and be a directory"; exit 1
		;;
	"genkey")
		echo "opendkim-genkey not found or not executable"; exit 1
		;;
	"ktable")
		echo "KeyTable not found"; exit 1
		;;
	"zoneroot")
		echo "\$ZONEROOT must exist and be a directory"; exit 1
		;;
	"usergroup")
		echo "User and group must exist"; exit 1
		;;
	"archive")
		echo "\$ARCHIVE must exist and be a directory"; exit 1
		;;
	"nbits")
		echo "Bits length must be greater than $MINKEY, and should not be greater than $MAXKEY"; exit 1
		;;
esac
}

# Checks
[ $# -ge 2 ] || onerror "args"
[ ${ACTION} = "new" -o ${ACTION} = "clean" ] || onerror "args"
[ -d ${CHROOT} ] || onerror "chroot"
[ -d ${ZONEROOT} ] || onerror "zoneroot"
[ -d ${ARCHIVE} ] || onerror "archive"
[ -x ${GENKEY} ] || onerror "genkey"
[ -f ${KeyTable} ] || onerror "ktable"
pw usershow ${USERGROUP/:*/} >/dev/null 2>&1 || onerror "usergroup"
pw groupshow ${USERGROUP/*:/} >/dev/null 2>&1 || onerror "usergroup"
if [ $NBITS -ne 0 ]; then
	[ $NBITS -gt $MINKEY ] || onerror "nbits"
	[ $NBITS -le $MAXKEY ] || onerror "nbits"
fi


archive() {
	echo "Putting away files for old DKIM selector ${1}"
	mv -v ${CHROOT}/${DOMAIN}/${1}.* ${ARCHIVE}
}

if [ ${ACTION} = "new" ]; then
	# Keytable: update SELECTOR
	# structure: 
	# arbitrary-name signing-domain:selector:keypath
	# for each line matching DOMAIN: 
	# - get SELECTOR. 
	# - key path derived from CHROOT/SELECTOR

	# get SELECTOR for DOMAIN:
	SELECTORLIST=( $(awk '/^[^#].* '${DOMAIN}':/ {split($2,a,":"); print a[2]}' ${KeyTable}) )

	# for each SELECTOR we must:
	# - destroy/archive private key 
	# - create a new SELECTOR + key + DNS
	# - rewrite KeyTable
	echo ""
	echo "Selector list for domain $DOMAIN has ${#SELECTORLIST[*]} member-s, lets renew each one:"
	for OLDSELECTOR in ${SELECTORLIST[@]}; do
		if [ $NBITS -ne 0 ]; then
			echo "Bits length set on command line to ${NBITS}, overriding current private key bits length"
			BITS=${NBITS}
		else
			echo -n "Get bits length for private key ${OLDSELECTOR}.private: "
			BITS=$(openssl rsa -in ${CHROOT}/${DOMAIN}/${OLDSELECTOR}.private -text -noout | awk '/Private-Key/ {gsub(/[^0-9]/,"",$2); print $2}')
			echo "$BITS"
		fi		
		echo -n "Create new selector: "
		UUID=$(uuidgen)
		SELECTOR="$(date "+%Y%m")-${UUID/-*/}"
		echo "${SELECTOR}"
		echo "Create new private key with ${SELECTOR}:"
		${GENKEY} -v -b ${BITS} -d ${DOMAIN} -D ${CHROOT}/${DOMAIN} -r -s ${SELECTOR}
		# permission adjustments:
		chown ${USERGROUP} ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		chmod u=r,g=r ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		ls -l ${CHROOT}/${DOMAIN}/${SELECTOR}.*
		echo -n "Update KeyTable: "
		sed -i .bkp -e 's/'$OLDSELECTOR'/'${SELECTOR}'/g' ${KeyTable}
		[ $? -eq 0 ] && echo "OK"
		archive ${OLDSELECTOR}
	done
	echo ""
	echo "End of selector renewal."
	# every SELECTOR for DOMAIN is updated, now deal with DNS
fi

echo ""
# calculate new serial for zone $DOMAIN
echo -n "Get old DNS zone serial for ${DOMAIN} and increment: "
NEWSERIAL=$(date +%Y%m%d%I)
OLDSERIAL=$(awk '/ ; Serial/ {print $1}' ${ZONEROOT}/${DOMAIN})
while [ $OLDSERIAL -ge $NEWSERIAL ]; do
	let NEWSERIAL=(NEWSERIAL+1)
done
echo "$OLDSERIAL -> $NEWSERIAL"
#
# Update SERIAL of DNS zone.
echo -n "Change serial in zone file: "
sed -i .bkp -e 's/'$OLDSERIAL' ; Serial/'${NEWSERIAL}' ; Serial/g' ${ZONEROOT}/${DOMAIN}
[ $? -eq 0 ] && echo "OK"

if [ ${ACTION} = "new" ]; then
	echo -n "Move old public keys to dkim-retired.${DOMAIN}: "
	cat ${ZONEROOT}/dkim-active.${DOMAIN} > ${ZONEROOT}/dkim-retired.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
	echo -n "Copy new public keys to dkim-active.${DOMAIN}: "
	cat ${CHROOT}/${DOMAIN}/*.txt > ${ZONEROOT}/dkim-active.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
elif [ ${ACTION} = "clean" ]; then
	echo -n "Clean old public keys of dkim-retired.${DOMAIN}: "
	echo "" > ${ZONEROOT}/dkim-retired.${DOMAIN}
	[ $? -eq 0 ] && echo "OK"
fi

echo ""
echo "Everything looks good, lets refresh world:"
named-checkzone ${DOMAIN} ${ZONEROOT}/${DOMAIN}
service named restart
[ ${ACTION} = "new" ] && service milter-opendkim restart

Les commentaires dans le code sont suffisants pour expliquer chaque étape du déroulement du script.

Bibliographie

DKIM
M3AAWG DKIM Key Rotation Best Common Practices (PDF)

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

Du SSL gratuit pour tout le monde ?

letsencrypt-logoLet’s Encrypt est une initiative toute récente de Mozilla, Cisco, l'EFF, Akamai, et IdenTrust. Elle vise à permettre à tout webmaster de proposer son site en HTTPS sans surcoût. Il s'agit de proposer aux administrateurs de serveurs web la possibilité d'obtenir gratuitement, automatiquement, et sans contrainte le précieux certificat SSL nécessaire au chiffrement des échanges entre le serveur et les clients. Le certificat sera bien évidemment reconnu nativement dans les navigateurs. C'est en tout cas la promesse du projet. Si cela permet de mettre fin à un racket que je dénonçais il y a quelques semaines, cela lève aussi quelques questions.

Un des principaux arguments des Verisign et autres Thawte pour vous facturer une fortune pour chaque certificat est que la création et le maintient d'une autorité de certification (CA) est extrêmement onéreux. Cela coûte en effet assez cher : les contraintes de sécurité sont immenses, les audits nombreux, etc. En effet la moindre compromission de l'autorité de certification réduit tous les efforts à néant : l'attaquant qui parviendrait à s'infiltrer dans la CA serait capable d'émettre des faux certificats passant pour tout à fait valides dans les navigateurs. Votre belle connexion sécurisée avec "barre verte" pourrait alors être détournée sans que vous n'en ayez conscience (sécurité ≠ confiance).
Mais on le sait ces grosses CA ne sont pas forcément plus fiables que les petites. Elles ne résistent pas forcément mieux aux pressions des agences gouvernementales, ni aux détournements ou piratages. Quelques exemples par ici. Finalement, ce surcoût n'a guère de valeur. Ce qui compte vraiment c'est de savoir si on peut faire confiance à la CA, ou pas.

Dans l'initiative Let’s Encrypt, la question de confiance peut se poser. Je n'ai pas de souci avec Mozilla, et la présence de l'EFF est rassurante. Par contre celle de Cisco m'interpelle. Snowden nous a montré comment la NSA s'amuse à intercepter les livraisons de matériels de cette marque pour caviarder les firmwares et ajouter des portes dérobées. Rien, bien évidement, n'incrimine Cisco directement dans ces magouilles. Néanmoins le doute raisonnable peut naître sur leur degré de connaissance de ces agissements.
Au bout du compte je n'ai pas trop envie de faire confiance à un groupement d'entités sachant que la duplicité d'une seule d'entre elles peut réduire à néant la sécurité des certificats délivrés.

Le protocole proposé (ACME) me laisse aussi dubitatif. J'avoue n'avoir pas lu l'ensemble du brouillon. Je n'ai pas de critique fondée à son encontre mais la débauche d'automatisme (le serveur web qui commande lui même le certificat par exemple) me laisse dubitatif, et je pense que j'attendrai sagement de voir ce que ça donne chez les autres avant d'essayer moi-même.

L'outils lets-encrypt est conçu pour fonctionner assez simplement. C'est sans doute une bonne idée au départ, mais cela laisse peu de maitrise sur le processus. Bien sûr, tout comme le protocole, il faudra attendre de voir ce que ça donne, quelles plateformes sont supportées, quels logiciels aussi. Mettre du SSL dans le web c'est sympa, mettre du SSL dans du mail (smtp, pop, imap) c'est primordial. A priori la première version sera livrée à l'été 2015, donc il reste un peu de temps.

Je souhaite profondément que Let’s Encrypt réussisse son pari. Fournir des certificats SSL reconnus et gratuits, avec des outils simples, basés sur une autorité de certification et sur des protocoles sûrs est un vrai défi.

Related posts

Giving up on Logstash

splunk-logoMore than six months away, I've put both Splunk and Logstash (plus ElasticSearch and Kibana) to trial. Since the beginning of my experiment, the difference between both products was pretty clear. I was hoping that ELK would be a nice solution to aggregate GBs of logs every day and more importantly to allow me and my team to dig into those logs.
Unfortunately, ELK failed hard on me. Mostly because of ElasticSearch: java threads on the loose eating my CPU, weird issue where a restart would fail and ES would become unavailable, no real storage tiering solution, and so on.
ElastickSearch looks like a very nice developer playground to me. It's quite badly - if at all - documented on the sysadmin side, meaning if you're not a developer and don't have weeks to spend reading API documentation you will have a hard time figuring out how to simply use/tune the product.
Also, this data storage backend has absolutely no security features (at the time I was testing Logstash). Just imagine you put valuable data into a remotely available database/storage/whatever and you're told that you are the one that should create a security layer around the storage. Imagine a product like SMB, NFS, Oracle DB, Postgres, etc. with zero access control feature, no role. Anyone who can display a pie chart in Kibana can gain full control of your ElasticSearch cluster and wipe all your data.
Logstash too has important issues: almost every setting changes require an application restart. Writing grok pattern to extract data is an horrendous process, and a new pattern won't be applied on past data. Splunk on the other hand will happily use a brand new pattern to extract values from past logs, no restart required.
Logstash misses also pipes, functions, triggers… Search in Kibana is not great. The syntax is a bit weird and you can easily find nothing just because you've forgot to enclose your search string with quotes… or is it because you put those quotes? And of course there is this strange limit that prevent you from searching in more than seven or eight months of data…

I've tried, hard. I've registered to not-so-helpful official mailing lists for Logstash and ElasticSearch and simply reading them will show you how far those products are from "production approval". I've used it alongside with Splunk, it boils down to this statement: Kibana is pretty, you can put together many fancy pie charts, tables, maps and Splunk is useful, reliable, efficient.

Yes, I'm moving to Splunk, @work and @home. My own needs are very easily covered by a Free license, and we are buying a 10 GB/day license for our +350 servers/switches/firewalls.

You might say that Splunk is expensive. That's true. But it's way less expensive to me than paying a full time experienced Java developer to dive into ElasticSearch and Logstash for at least a year. Splunk has proper ACL that will allow me to abide by regulations, a good documentation, and a large community. It support natively storage tiering, too.

ELK is a fast moving beast, it grows, evolves, but it's way behind Splunk in terms of maturity. You can't just deploy ELK like you would do for MySQL, Apache, Postfix, Oracle DB, or Splunk. Lets wait few years to see how it gets better.

Related posts

Log aggregation and analysis: logstash

Logstash is free software, as in beer and speech. It can use many different backends, filters, etc. It comes packaged with Elasticsearch as a backend, and Kibana as user interface, by default. It makes a pleasant package to start with, as it's readily available for the user to start feeding logs. For your personal use, demo, or testing, the package is enough. But if you want to seriously use LS+ES you must have at least a dedicated Elasticsearch cluster.

apache-log-logstash-kibana

Starting with Logstash 1.4.0, the release is no longer a single jar file. It's now a fully browsable directory tree allowing you to manipulate files more easily.
ELK (Elasticsearch+Logstash+Kibana) is quite easy to deploy, but unlike Splunk, you'll have to install prerequisites yourself (Java, for example). No big deal. But the learning curve of ELK is harder. It took me almost a week to get some interesting results. I can blame the 1.4.0 release that is a bit buggy and won't start-up agent and web as advertised, the documentation that is light years away from what Splunk provides, the modularity of the solution that makes you wonder where to find support (is this an Elasticsearch question? a Kibana problem? some kind of grok issue?), etc.

Before going further with functionalities lets take a look at how ELK works. Logstash is the log aggregator tool. It's the piece of software in the middle of the mess, taking logs, filtering them, and sending them to any output you choose. Logstash takes logs through about 40 different "inputs" advertised in the documentation. You can think of file and syslog, of course, stdin, snmptrap, and so on. You'll also find some exotic inputs like twitter. That's in Logstash that you will spend the more time initially, tuning inputs, and tuning filters.
Elasticsearch is your storage backend. It's where Logstash outputs its filtered data. Elasticsearch can be very complex and needs a bit of work if you want to use it for production. It's more or less a clustered database system.
Kibana is the user interface to Elasticsearch. Kibana does not talk to your Logstash install. It will only talk to your Elasticsearch cluster. The thing I love the most about Kibana, is that it does not require any server-side processing. Kibana is entirely HTML and Javascript. You can even use a local copy of Kibana on your workstation to send request to a remote Elasticsearch cluster. This is important. Because Javascript is accessing your Elasticsearch server directly, it means that your Elasticsearch server has to be accessible from where you stand. This is not a good idea to let the world browse your indexed logs, or worse, write into your Elasticsearch cluster.

To avoid security complications the best move is to hide your ELK install behind an HTTP proxy. I'm using Apache, but anything else is fine (Nginx for example).
Knowing that 127.0.0.1:9292 is served by "logstash web" command, and 127.0.0.1:9200 is default Elasticsearch socket, your can use those Apache directives to get remote access based on IP addresses. Feel free to use any other access control policy.

ProxyPass /KI http://127.0.0.1:9292 
ProxyPassReverse /KI http://127.0.0.1:9292 
ProxyPass /ES http://127.0.0.1:9200 
ProxyPassReverse /ES http://127.0.0.1:9200 
<Location /KI>
	Order Allow,Deny
	Allow from YOUR-IP 127.0.0.1
</Location>
<Location /ES>
	Order Allow,Deny
	Allow from YOUR-IP 127.0.0.1
</Location>

original data in µs, result in µs. Impossible to convert in hours (17h09)

original data in µs, result in µs. Impossible to convert in hours (17h09)

On the user side, ELK looks a lot like Splunk. Using queries to search through indexed logs is working the same, even if syntax is different. But Splunk allows you to pipe results into operators and math/stats/presentation functions… ELK is not really built for complex searches and the user cannot transform data with functions. The philosophy around Kibana is all about dashboards, with a very limited set of functions. You can build histograms, geoip maps, counters, compute some basic stats. You cannot make something as simple as rounding a number, or dynamically get a geolocation for an IP address. Everything has to be computed through Logstash filters, before reaching the Elasticsearch backend. So everything has to be computed before you know you need it.
Working with Logstash requires a lot of planing: breakdown of data with filters, process the result (geoip, calculation, normalization…), inject into Elasticsearch, taylor your request in Kibana, create the appropriate dashboard. And in the end, it won't allow you to mine your data as deep as I would want.
Kibana makes it very easy to save, store, share your dashboards/searches but is not very friendly with clear analysis needs.

Elasticsearch+Logstash+Kibana is an interesting product, for sure. It's also very badly documented. It looks like a free Splunk, but its only on the surface. I've been testing both for more than a month now, and I can testify they don't have a lot in common when it comes to use them on the field.

If you want pretty dashboards, and a nice web-based grep, go for ELK. It can also help a lot your command-line-illeterate colleagues. You know, those who don't know how to compute human-readable stats with a grep/awk one-liner and who gratefully rely on a dashboard printing a 61 billions microseconds figure.
If you want more than that, if you need some analytics, or even forensic, then odds are that ELK will let you down, and it makes me sad.

Related posts