Geoffroy Gramaize

Dans ce billet, je vais montrer comment activer une méthode d’authentification à deux facteurs pour les accès SSH qui arrivent de réseaux inconnus. L’objectif final est de fournir un niveau de sécurité renforcé pour un sous-ensemble de connexions entrantes, sans compliquer l’exploitation quotidienne depuis l’intérieur de votre réseau. La solution mise en place s’appuie sur l’infrastructure PAM.

Prérequis

L’utilisation de codes basés sur le temps demande une synchronisation des horloges, il est donc vivement conseillé de déléguer cette tâche à ntpd, si ce n’est pas déjà en place.

Le paquet qui contient le module PAM pour google authenticator est libpam-google-authenticator pour la famille des distributions debian (dispo depuis debian jessie), et google-authenticator sur CentOS 7. Si vous ne disposez pas de paquet pour votre distribution, vous pouvez télécharger les sources et les compiler.

Préparation des comptes utilisateur

Pour que l’authentification puisse fonctionner, il faut impérativement définir un jeton en lançant la commande google-authenticator sur chaque compte qui aura besoin de se connecter via SSH. L’authentification échouera systématiquement si ce n’est pas fait.

Un assistant va apparaître pour vous aider à configurer le jeton personnel. Certaines versions (comme dans le cas présent) vous afficheront un code barre QR scannable par l’application de Google.

Définir la liste de contrôle d’accès

Nous allons configurer une liste d’accès pour définir les réseaux qui seront exemptés d’une vérification à deux facteurs. La syntaxe de l’entrée dans le fichier PAM sera abordée dans la partie suivante. La logique de l’ACL est la suivante: un utilisateur « accepté » est exempté d’une procédure de double vérification.

Créer le fichier /etc/security/access-gauth.conf (si vous utilisez l’acl pour un autre module, changez gauth par le nom du module concerné).

La structure d’une entrée dans le fichier est composé de la manière suivante: <permission> : <utilisateur> : <origine>

La permission a deux valeurs possibles: « + » (autoriser) et « – » (rejeter).

Le champ utilisateur peut être composé de un ou plusieurs utilisateur(s) et/ou groupe(s) séparé(s) par des espaces. Les noms de groupes sont préfixés par un « @ ». Des exceptions peuvent être mises en place grâce au mot clé EXCEPT. La différence majeure pour la liste d’exception concerne les groupes, qui ne sont plus désigné par le « @ », mais par une paire de parenthèses.

Le champ origine peut contenir le nom du terminal d’origine de l’utilisateur, le mot-clé LOCAL qui désigne toute console présente physiquement sur la machine, une adresse IPv6/v4, un subnet IPv6/v4, un subnet réseau IPv4 avec le masque en notation décimale pointée. Encore une fois, le mot-clé EXCEPT vous permet de faire des exclusions de sous-ensembles.

Un exemple complexe de ligne est donné ci-dessous:

+ : emustermann @staff EXCEPT jdoe (rookies) : 3fff:15d4:dead:beef::/64 192.168.15.0/24 EXCEPT 192.168.15.254 3fff:15d4:dead:beef::1337

Votre fichier d’ACL devrait ressembler au minimum à ceci:

# Indiquez ici les réseaux de confiance
+ : ALL : 192.168.0.0/24
+ : ALL : 2001:xxxx:xxxx:xxxx::/64
+ : ALL : fe80::/64

# Toujours bypasser pour l'authentification locale
+ : ALL : 127.0.0.0/8
+ : ALL : ::1
+ : ALL : LOCAL

# Rejeter tous les autres
- : ALL : ALL

Configuration de PAM

Il faut maintenant éditer le fichier /etc/pam.d/sshd pour insérer les lignes données ci-dessous. Vous devrez coller ces lignes à la suite de l’inclusion du mécanisme commun d’authentification (« @include common-auth » sur debian), ou à la suite de la dernière ligne dont le premier verbe est « auth ».

auth	[success=1 default=ignore]	pam_access.so	accessfile=/etc/security/access-gauth.conf
auth	required			pam_google_authenticator.so

La première ligne sert à arrêter le processus d’authentification avant l’exécution du module google authenticator si l’utilisateur est accepté par l’ACL (success=1), mais à ne pas le rejeter s’il est rejeté par la liste (default=ignore).

Le module google authenticator est défini en « required » car un échec à ce test doit entraîner un refus de connexion, mais la réussite du test n’est pas suffisante en soi pour accepter la connexion d’office (ce que permettrait un mot-clé « sufficient »).

Configuration d’OpenSSH

Par défaut, OpenSSH est configuré pour utiliser la méthode embarquée du protocole pour authentifier l’utilisateur par mot de passe. Pour changer ce comportement, il faut définir les deux lignes suivantes dans votre fichier sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes

Pour éviter de se couper la main, il est vivement recommandé de disposer d’une clé privée valide pour remonter sur la machine en cas de pépins, ou d’avoir mis l’IP de votre machine en liste blanche ;).

Une fois que vous êtes prêt, relancez le serveur ssh sur la machine distante.

(An english version of this post is available.)

Le 6 Juin 2015, je me suis généré une nouvelle clé PGP, dont l’empreinte est D4B08488 03E7D7AF F9DB90E2 4EB88CD9 57312C28.

J’utilise encore à ce jour ma clé historique, à savoir celle dont l’empreinte est E05CDFED D9B6DC33 6B23B510 27FFC627 78A363DF, mais je prévois de la révoquer d’ici environ un an.

J’ai resigné avec ma nouvelle clé toutes les clés que j’avais signé auparavant.
Pour faciliter l’authentification de ma nouvelle clé, mes deux clés sont signées mutuellement. Vous bénéficierez de la toile de confiance via ma clé actuelle, en attendant de signer ma nouvelle clé.

Voici les raison qui expliquent pourquoi j’ai décidé de me lancer:

Ma clé actuelle est vieille

Elle a 4 ans et demi, et je ne souhaite pas utiliser des clés qui ont plus de 6 ans, ce qui représente déjà une durée de vie importante pour une clé cryptographique.

Le risque associé à l’utilisation de vieilles clés tient au risque croissant avec le temps qu’un adversaire arrive à trouver la partie privée de votre clé.

Je voulais disposer d’une clé plus solide depuis un moment

Ma clé actuelle est une clé RSA de 2048 bits, et je souhaitais me générer une clé plus solide depuis un moment.

Je n’ai pas basculé vers la cryptographie sur courbes elliptiques, car les versions de gnupg 2.1 ne sont pas encore suffisament diffusées pour avoir un support correct, les cartes openpgp ne supportent pas les clés ECC, et je ne veux pas monter une configuration pour utiliser une carte PKCS#11 avec gnupg.

J’ai renouvellé ma carte à puce

Afin d’assurer une sécurité optimale, le stockage de clés privées ne devrait jamais se faire à l’extérieur d’une carte à puce. Ci-dessous, une photo du matériel que j’ai utilisé jusqu’à maintenant (carte à puce format ISO 7816 et un lecteur expresscard54).

De nos jours, d’une part, les slots Expresscard 54 se font de plus en plus rares sur les PC portables, à cause des contraintes de poids, et de volume des nouvelles gammes de matériel. Conserver une carte à puce au format ISO 7816 devient contraignant, car je devrais transporter un lecteur de cartes externe en permanence avec ma carte à puce.

D’autre part, j’utilise fréquemment ma carte à puce à la fois pour les opérations communes avec GPG, et pour l’authentification SSH, et je souhaitais remplacer mon matériel avant d’être victime d’une panne par usure de la mémoire interne.

En prenant en compte les deux points en supra, repartir sur de la carte à puce au format classique n’était pas envisageable, et je me suis donc tourné vers un format type « clé USB ».

Le format « dongle USB » est meilleur

J’ai rentenu le lecteur Gemalto Usb shell token V2 (cf. image en infra), pour sa légèreté, ses dimensions compactes, sa solidité, et parce qu’il est supporté nativement par une gamme large d’OS, avec le support des APDUs étendues (configuration plus simple).

A l’intérieur de dongle, j’ai installé une carte OpenPGP version 2.1, que mon fournisseur vend prédécoupée au format mini-SIM (si vous souhaitez vous équiper, n’hésitez pas à consulter sa boutique en ligne).

Depuis que Feitian a arrêté son contrat de revente avec gooze, c’est la meilleure solution que j’ai trouvé. A ce propos, j’ai constaté que gooze a mis la clé sous la porte.

Le résultat est assez propre une fois assemblé comme en témoigne la photo ci-dessus. J’ai ajouté un petit logo « GnuPG » entre la puce et la paroi du pour ne pas confondre ce dongle avec un autre que j’utilise déjà.

Pour les gens paranos qui souhaiterais authentifier la source de cet article, vous pouvez télécharger cette archive qui contient une version texte de cet article, et signé avec mes deux clés PGP. N’hésitez pas à poser vos questions en commentaire.

(Une version française de cet article est disponible)

On July 6th, 2015, I’ve generated a new PGP key, which fingerprint is D4B08488 03E7D7AF F9DB90E2 4EB88CD9 57312C28.

As for now, I’m still using my historical key as my primary key (E05CDFED D9B6DC33 6B23B510 27FFC627 78A363DF), but I’m planning to revoke my current main key in approximately a year.

All keys I have signed in the past have already been resigned with my new key. My two keys are cross-signed to confirm mutual ownership, and to keep a trust path, as long as my current key is not revoked.

Here are the main reasons why I decided to engage in such a mess:

My current main key is old

It’s nearly 4 and a half year old, and I don’t wish to use keys that are more that 6 years old (which is already a long life for crypto keys).

The more time elapses from the time you begin using a crypto key, the higher is the risk that an attacker could have found your private key.

I’ve wanted to get a stronger key for a while

My current key is 2048 bits long, using RSA, and I’ve been wanting to generate a stronger key for while. On the opportunities to switch to elliptic curve keys, I’ve decided not to migrate for now, as gnupg 2.1 adoption is still marginal, and OpenPGP smart card v2.1 smart cards do not support ECC keys, and I didn’t want to bother setting up a PKCS#11 card with gnupg to manage my keys.

I’ve renewed my smart card

For serious cryptographic operations, one shouldn’t store private keys outside a smartcard. Here is a photograph of the hardware I’ve been using to store my PGP key so far.

Nowadays, from one hand, Expresscard 54 slots are being scarcer and scarcer, as laptops dimensions and weight are shrinking, so keeping the ISO 7816 form factor is being more and more problematic, as I’d have to keep a smart card reader all the time with me on some hardware. The picture above this paragraph features an expresscard-54 smart card reader.

From another hand, I’ve been using extensively my smart card both for PGP and SSH authentication, and I was willing to replace my card before being victim of a wearout failure.

Considering those two reasons, re-using the same smart card isn’t an option.

The USB dongle a better form factor.

I’ve selected the Gemalto Usb shell token V2 reader (picture below related), which is light, compact, pretty solid, and natively supported by a wide range of recent OSes, with extended APDUs. The smart card inside, an OpenPGP card v2.1, is retailed in pre-cut mini SIM form factor by my dealer (you should check his shop if you wish to purchase smart cards from europe).

This is the cleanest alternative I’ve found so far since Feitian decided to break their trading agreement with Gooze. I’ve just checked out Gooze website, and it seems that  they’re now closed.

The assembled result is pretty neat. I’ve put a small « GnuPG » logo between the card and the case in order not to mistake it with another dongle I already use.

For paranoid people that would like to authenticate the source of this article, you can find a text-only version of this article signed with my two keys in this archive. Feel free to comment if you have any questions on the hardware I use.

Since my last article, there has been a lot of movement : new vulnerabilities have appeared, but a good setup might have protected you (especially if you decided to drop SSLv3 support).

Let’s begin on an excellent news from the Apache project : version 2.2.30 will support strong DH exponents as detailed in this commit.

TL;DR: updated cipher suites are at the end of the document.

SSLv3 : the weak link

Since my last post, the POODLE attack was disclosed, proving SSLv3 to be weak. For a reminder, in 2013, I did an implicit recommendation to disable SSLv3, which was already more than obsolete at that time. The caveat to this is that obsolete OS like MS Windows XP are not natively compatible with TLS 1.0.

If you’re still using Windows XP, and if you can’t migrate from it, please follow the following guide from certiport to enable TLS 1.0. Please use this opportunity to disable SSLv2 and SSLv3: as Windows XP is not supported anymore, the internal libraries won’t benefit from the TLS_FALLBACK_SCSV flag to detect a downgrade attack.

RC4: partially broken, pruned by IETF

According to a 2013 publication which deals with the state of RC4 in TLS, this cipher has been partially broken in some conditions. Therefore, it should be considered as weak, and it MUST (I strongly emphasize on this) be rolled out as soon as possible from production.

At the beginning of this year, the IETF has written RFC 7465 to prohibit the use of RC4 cipher suites. This document is, at the date of publication, a proposed standard.

ChaCha20-Poly1305: a promising newcomer

The obsolescence of RC4 has a significant impact for high traffic servers and low-resources devices (phones, embedded systems…) Indeed, AES performances are lower to RC4’s on hardware that don’t implement specific instruction sets. In regard of these issues, Google has implemented a new stream cipher that runs efficiently without any need of hardware implementation.

Beside Google’s work on this cipher, current adoption is still marginal, because the cipher specification process on the IETF side has been on hiatus for a while. However, it’s now published, and implementation in IPSec/IKE is to be published soon. No work has been performed for TLS yet, but you can track the evolution on the IETF datatracker here.

Up to now, this cipher is implemented in Android, and in Windows build of Google Chrome, but there is no upstream implementation in the most popular TLS libraries because the developpers are waiting for the cipher suite ID bytes to be standardized.

However we can think Chacha20-Poly1305 will gain traction once its specification is standardized for TLS.

3DES: Necessary evil for legacy support

Now that RC4 has been proven insecure, there is only one « safe » (112 bit of effective key size) cipher suite on Windows XP: TLS_RSA_WITH_3DES_EDE_CBC_SHA. There is another suite that uses 3DES, but it requires use of DSA keys, which size are effectively limited to 1024 bits on Legacy OS.

I insist that this cipher suite is to be included only for legacy support, put it at the end of your cipher suite, and you should remove it as soon as possible.

TLS 1.3 : what to expect so far

The IETF is currently working on TLS version 1.3 which will essentially focus on cleaning the crufty legacy features that one shouldn’t use today (compression, non-AEAD ciphers, DHE key exchange…), and improving the protocol performances and strength.
 

Recent attacks messing with both the client and server sides.

The support for « export » cryptography on the client side has been leveraged downgrade the security of connections. FREAK targets old cipher suites (e.g. DES with 56 bit keys), and Logjam targets Diffie-Hellmann ephemeral key exchange, by using weak key length (512 bits moduli). The best way to mitigate these attacks is to upgrade your browser to the last version.

The updated TLS cipher suites

A significant change has been performed on the suggested cipher suites: DHE suites are put after all ECDHE because of the risks induced by Logjam attacks, and because ECDHE key exchange is significantly faster than DHE key exchange. AEAD ciphers (with built-in authentication) and TLS 1.2 ciphers are put first.

This profile is built with performance in mind. It features 128 bits ciphers first.

SSLProtocol all -SSLv3 -SSLv2
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:CAMELLIA128-SHA:AES128-SHA:CAMELLIA256-SHA:AES256-SHA

The second profile is built with maximum security.

SSLProtocol all -SSLv3 -SSLv2
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

The third profile is built for legacy support, based on the performance profile.

SSLProtocol all -SSLv3 -SSLv2
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:CAMELLIA128-SHA:AES128-SHA:CAMELLIA256-SHA:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Bonus: Enabling HSTS

HTTP Strict Transport Security (HSTS) is a security mechanism which is to HTTPS websites against downgrade-to-HTTP attacks. Compatible browsers will remember websites that show the appropriate headers, and redirect any http request to https.

Enabling HSTS is a good practice to apply when your TLS setup is stable and mature.

To do so, you must enable mod_headers and add the following line on your TLS-Enabled virtual host:

Header always set Strict-Transport-Security "max-age=15768000"

If all your subdomains are properly set up, you can add includeSubDomain at the end of the value of the header, as follow.

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"

La matrice de Walsh-Hadamard dispose de certaines propriétés mathématiques intéressantes, comme l’orthogonalité 2 à 2 des lignes de la matrice qui est exploitée dans les systèmes à accès multiple par répartition de codes (CDMA). Cependant, les méthodes de génération conventionnelles font assez facilement appel à la multiplication de deux matrices.

Je me suis donc intéressé à une méthode de génération qui utilise quasi exclusivement des opérations de base (décalage de bits pour les puissances de 2, additions et branchements logiques). Elle présente toutefois l’inconvénient de consommer 2 fois la mémoire nécessaire à stocker la matrice.

Le code qui vous est proposé est optimisable, notamment en terme de stockage, mais il a été réalisé dans un objectif d’universalité. Il est fonctionnel et a été vérifié avec les matrices H₂, H₄ et H₁₀₂₄. Attention, le code source suivant est en C99, n’oubliez pas de configurer correctement votre compilateur.

Fichier hadamard.h

#ifndef __HADAMARD_H
#define __HADAMARD_H

typedef struct matrix {
	size_t width;
	size_t height;
	unsigned char *data;
} matrix;

typedef struct smatrix {
	size_t width;
	size_t height;
	char *data;
} smatrix;

void print_smatrix( smatrix *mtx);

void __hadamard_increment( size_t iteration, matrix *mtx);

// Generates the hadamard matrix of dimention 2^k
smatrix* gen_hadamard_matrix( size_t k);

#endif // __HADAMARD_H

Fichier hadamard.c

#include <stdio.h>
#include <stdlib.h>
#include "hadamard.h"

void print_smatrix( smatrix *mtx) {
	for( size_t i = 0; i<mtx->height; ++i)
	{
		printf( "|");

		for( size_t j=0; j<mtx->width; ++j)
		{
			printf( ((int)mtx->data[mtx->width*i+j] < 0 ? " %d" : " +%d"), (int)mtx->data[mtx->width*i+j]);
		}
		printf( " |\n");
	}
}

void __hadamard_increment( size_t iteration, matrix *mtx)
{
	size_t powOfTwo = 1 << iteration;

	for( size_t y=0; y<mtx->height; ++y)
	{
		// If selected bit is not set, skip this column
		if( (powOfTwo & y) != powOfTwo )
			continue;

		for( size_t x=0; x<mtx->height; ++x)
		{
			if( (powOfTwo & x) != powOfTwo)
				continue;
			++(mtx->data[mtx->height*y+x]);
		}
	}
}

// Generates the hadamard matrix of dimention 2^k
smatrix* gen_hadamard_matrix( size_t k)
{
	matrix mtx;
	smatrix* smat = malloc( sizeof(smatrix));

	// To generate a hadamard matrix, without using the multiplication,
	// we use an additive transition matrix.

	mtx.width = mtx.height = 1 << k;
        mtx.data = malloc(sizeof(unsigned char)*mtx.width*mtx.height);

	size_t mtxSZ2D = smat->width*smat->height;
        for (size_t i=0; i<mtxSZ2D; ++i)
        {
                mtx.data[i] = 0;
        }

	// We iteratively apply the incrementation on cells where the k_th bit
	// is set on both y and x coordinates. Apply k times for a 2^k by 2^k
	// Hadamard matrix

        for( size_t i=0; i<k; ++i)
                __hadamard_increment( i, &mtx);

        smat->width = mtx.width;
        smat->height = mtx.height;
        smat->data = malloc(sizeof(char)*smat->width*smat->height);

	// Then we generate the hadamard matrix by converting odd cells to '-1'
	// from the transition matrix and even cells to '+1'.

	size_t smatSZ2D = smat->width*smat->height;
        for ( size_t i=0; i<smatSZ2D; ++i)
        {
                smat->data[i] = (char)( ((mtx.data[i]) & 1) == 0 ? 1 : -1 );
        }

	free(mtx.data);
	return smat;
}

Fichier main.c

#include <stdio.h>
#include <stdlib.h>
#include "hadamard.h"

int main(void)
{
	size_t k;
	matrix mtx;

	printf( "Calcul de H(2^k). Valeur de k? ");
	scanf( "%i", &k);

	smatrix* smat = NULL;

	smat = gen_hadamard_matrix(k);
	print_smatrix( smat);

	free(smat->data);
	free(smat);
	return 0;
}

Les explications seront publiées prochainement.