Sysadmin on Jesuisadmin

WordOps - Déployer WordPress avec Nginx simplement

Sat, 18 May 2019 12:03:24 +0000

Pour automatiser le déploiement de mes serveurs avec Nginx, PHP, MariaDB et pour créer les vhosts Nginx, j’utilisais précédemment EasyEngine v3 - qui avait d’ailleurs fait l’objet d’un article. Le problème, c’est qu’EasyEngine n’était plus vraiment à jour. Et pour cause, ses développeurs (rtCamp) travaillaient sur une nouvelle mouture qui a été publiée fin novembre 2018, EasyEngine v4.

Malheureusement, cette nouvelle version développée en PHP qui utilise WP-CLI et Docker ne réponds pas vraiment à mes besoins, et ne laisse (à l’heure actuelle) que très peu de place à la customisation, aussi bien au niveau des configurations Nginx, que des paquets/containers utilisés.

N’y voyez pas un reproche à l’encontre de ses créateurs, puisque je comprends tout à fait le choix fait par l’équipe de rtCamp, et il me semble tout à fait normal que l’outil qu’ils développent soit avant tout adapté à leurs besoins. Il me paraît d’ailleurs important de souligner qu’ils mettent à disposition, gratuitement, avec une simple licence MIT, une application très complète et documentée, et ceux depuis déjà plusieurs années (la première version d’EasyEngine a été publiée en 2014).

Finalement, c’est en parcourant les articles du blog d’EasyEngine fin Décembre, que j’ai découvert qu’un fork de la version 3 d’EasyEngine baptisé WordOps était actuellement en développement et qu’une première pre-release était disponible sur Github.

Ayant contribué de mon mieux au projet EasyEngine v3 en publiant un certain nombre de scripts ainsi que la majorité de mes configurations Nginx, j’ai été contacté par l’équipe de WordOps que j’ai finalement intégré début Février.

Nous avons publié la première version “stable” de l’application début Mai et il était donc temps de rédiger un article pour vous présenter WordOps.

WordOps qu’est ce que c’est ?

C’est un outil en ligne de commande qui facilite l’administration d’un serveur et le déploiement de sites avec Nginx (notamment WordPress) en utilisant des commandes simples - faciles à mémoriser.

Quels sont les pré-requis pour installer WordOps ?

Du côté hardware, il n’y a pas vraiment de pré-requis, puisque l’application est développée en Python avec le framework Cement et ne nécessite que quelques mégaoctets d’espace disque pour le stockage des librairies.

Pour une utilisation en production, les services installés et configurés par WordOps tel que Nginx, PHP-FPM ou MariaDB, nécessitent un minimum de ressources pour fonctionner. Ce minimum peut varier en fonction du trafic des sites hébergés. C’est pourquoi nous conseillons d’installer WordOps sur un serveur disposant d’au moins 2Go de RAM et si possible d’un processeur multi-core (qu’ils soient virtuels ou non) pour garantir le bon fonctionnement des différents services déployés avec WordOps et donc la disponibilité des sites hébergés.

Par contre, si vous comptez utiliser WordOps pour du développement, il devrait normalement fonctionner sur n’importe qu’elle machine/VM disposant de 512mo de RAM ou plus.

Nous avons d’ailleurs ajouté depuis peu le support de la distribution Raspbian 9, qui permet donc l’installation sur Raspberry Pi (nos tests ont été réalisés sur le modèle 3B+).

Du côté software, les distributions linux supportées sont :

Ubuntu 16.04 LTS (Xenial)
Ubuntu 18.04 LTS (Bionic)
Ubuntu 19.04 (Disco)
Debian 8 (Jessie)
Debian 9 (Stretch)
Raspbian 9 (Stretch)

Quelles sont ses fonctionnalités ?

WordOps réalise non seulement l’installation et la configuration des paquets nécessaires au déploiement d’un site (Nginx, PHP, MariaDB) mais il s’occupe également de la création des vhosts Nginx, de la base de données, d’installer WordPress et même d’obtenir un certificat SSL Let’s Encrypt, le tout réalisable en une seule ligne de commande.

Dans le cas d’un site WordPress, vous disposez de plusieurs solutions de cache (optionelles) : Nginx fastcgi_cache, Redis (full page cache + object cache) ou WP-Super-Cache.

Enfin WordOps dispose d’un tableau de bord (que j’ai réalisé depuis un template bootstrap de Creative Tim et avec la suite de monitoring Netdata) qui permet à la fois de monitorer le serveur mais également d’accéder à des outils tel que PhpMyAdmin, Adminer, eXtplorer, phpRedisAdmin etc.. Une démo est disponible à l’adresse suivante : demo.wordops.eu.

Qu’est ce qu’il y a sous le capot ?

Nginx stable v1.16.1 (custom) avec le support du HTTP/2 HPACK de Cloudflare, de la compression avec Brotli, et des modules tiers tel que ngx_cache_purge ou ngx_vts
PHP 7.2 & PHP 7.3
MariaDB server 10.3
Redis 5.0
Netdata pour le monitoring
Acme.sh pour la gestion des certificats SSL Let’s Encrypt
WP-CLI pour le déploiement des sites WordPress

Et bien sûr, un ensemble de templates de configuration Nginx, qui ont pour objectif de délivrer les meilleures performances possibles ainsi qu’un niveau de sécurité optimale. Pour cela, WordOps utilise par exemple Nginx en tant que load-balancer pour répartir la charge sur les pools php-fpm en utilisant plusieurs unix sockets. On retrouve également un certain nombre de directives limitant l’accès et/ou l’exécution et le téléchargement de certains fichiers afin de bloquer les tentatives d’attaques régulièrement utilisées.

Installer WordOps

Un script pour automatiser l’installation de WordOps est bien sûr disponible, il s’exécute avec la commande suivante :

wget -qO wo wops.cc && sudo bash wo

Si vous souhaitez installer manuellement WordOps, un guide est disponible dans la documentation

Durant l’installation, WordOps vous demandera un nom d’utilisateur et une adresse email. Ces informations sont uniquement utilisées pour générer le fichier .gitconfig nécessaire au fonctionnement de git, qui est utilisé pour enregistrer les différentes configurations du serveur.

Commencer avec WordOps

Après avoir installé WordOps, la première étape est d’activer la complétion des commandes, il suffit pour cela d’utiliser la commande :

source /etc/bash_completion.d/wo_auto.rc

Nous pouvons donc commencer à utiliser les commandes WordOps, dont la structure est la suivante :

wo <commande> [options]

Vous souhaitez obtenir la liste des commandes disponibles ? Rien de plus simple, utilisez la commande :

wo

Vous pouvez également obtenir des informations sur chacune des sous-commandes en ajoutant les arguments -h ou --help.

Exemple :

wo site create -h

Installer les services (optionnel)

WordOps peut installer les services Nginx, PHP ou MySQL via la commande wo stack ou n’installer que les services nécessaires lors de la création d’un site avec la commande wo site create.

Si vous comptez utiliser WordOps pour héberger vos sites WordPress, il peut être intéressant de commencer par déployqer les services (Nginx, PHP 7.2, MariaDB) ainsi que les outils additionnels (phpMyAdmin, Adminer, OpcacheGui) qui seront disponibles dans le backend accessible via le port 22222 (exemple : https://IP.DU.SERVEUR:22222 ou https://serveur.hostname:22222).

Pour déployer les services, la commande à utiliser est :

wo stack install

Créer votre premier site

Que vous ayez suivi ou non l’étape précédente, vous pouvez créer votre premier site. La création de site se fait via la commande wo site create avec la structure suivante :

wo site create [<nom_de_domaine>] [type_de_site] [options] <options>

Pour vous donner un exemple relativement simple, nous allons créer un site WordPress, configuré avec PHP 7.3 et le système de cache nginx fastcgi_cache, sécurisé avec un certificat SSL Let’s Encrypt :

wo site create site.tld --wpfc --php73 --letsencrypt

Quelques points à retenir

par défaut et en l’absence de l’argument --php73, WordOps utilisera PHP 7.2
l’argument --wpfc définit le type de site, ici un site WordPress avec le système de cache Nginx fastcgi_cache. Vous pouvez découvrir tous les autres types de sites dans la documentation.
l’argument --letsencrypt est optionel et peut être utilisé avec n’importe quel type de site. Si le site que vous souhaitez créer est un sous-domaine, utilisez alors l’argument --letsencrypt=subdomain pour que WordOps n’essaye pas de générer un certificat SSL pour l’alias www.site.tld.

Voici un exemple qui présente le fonctionnement général de WordOps :

Contribuer

Comme pour la majorité des projets open-source, toute contribution est la bienvenue. Et il n’est pas nécessaire d’être un développeur ou un administrateur système pour contribuer.

Le simple fait de faire un signalement détaillé d’un bug dans l’application est une contribution au projet. Vous pouvez également participer à l’amélioration de la documentation de WordOps, qui peut facilement être éditée car elle est rédigée en markdown et hébergée dans un dépôt Github.

Si vous souhaitez contribuer directement au développement de WordOps, sachez que la rédaction d’un guide est en cours, avec un présentation détaillée des librairies utilisées et les règles à suivre notamment pour le style à appliquer au code (PEP8). Je mettrais à jour cet article dès que le guide sera publié sur le dépôt Github.

Les liens utiles

le site du projet : https://wordops.net
le dépôt Github : https://github.com/WordOps/WordOps
le forum : https://community.wordops.net/
la documentation : https://docs.wordops.net/
le compte twitter : https://twitter.com/WordOps_
le compte mastodon : https://mastodon.top/@WordOps

Mettre en place un VPN Mesh avec tinc sur Debian/Ubuntu

Sat, 02 Mar 2019 15:07:54 +0000

Il peut-être intéressant (ou nécessaire) de mettre en place un VPN pour inter-connecter plusieurs serveurs, principalement pour garantir le chiffrement des échanges entre ces derniers. Si des solutions comme OpenVPN sont très populaires car elles proposent des clients sur toutes les plateformes, elles ne sont pas nécessairement les plus pertinentes lorsqu’il s’agit de créer un réseau privé entre plusieurs serveurs linux. Pour répondre à ce besoin, il existe heureusement d’autres solutions, notamment Tinc, le sujet que nous allons aborder aujourd’hui.

Dans ce tutoriel nous allons voir comment installer la dernière version stable de Tinc et comment créer un réseau privé pour connecter 3 serveurs. Cet exemple est basé sur mon utilisation ~~actuelle~~ précédente de Tinc, à savoir connecter mon raspberry pi (derrière un NAT) et mon cluster de stockage GlusterFS, réparti sur deux serveurs dédiés. Tinc était alors la solution à deux problématiques :

établir une connexion securisée entre les noeuds GlusterFS (j’ai préféré mettre en place un VPN à cause des nombreux problèmes rencontrés avec les connexions SSL/TLS et GlusterFS 4.X)
accéder aux données d’un cluster GlusterFS depuis un client derrière un NAT

Les termes utilisés dans ce tutoriel :

une instance Tinc = un réseau privé Tinc
un noeud = un serveur du réseau

Installer Tinc

La méthode la plus simple pour installer Tinc est d’utiliser les dépôts APT d’Ubuntu ou de Debian. Cependant les paquets disponibles ne sont pas vraiment à jour. La version actuelle de Tinc est 1.0.35, mais les dépôts Ubuntu ne propose que la version 1.0.33 et ceux de Debian la version 1.0.31.

Edit du 10/07/2019 : Les mises à jour de sécurité des paquets Debian sont rétro-actives sur les versions précédentes. Il n’y a donc pas de danger particulier à utiliser des versions antérieures à 1.0.35 sur Debian.

Il est donc préférable/recommandé de compiler Tinc depuis les sources, notamment lorsqu’on sait que la version 1.0.35 est une release de sécurité suite à la découverte de deux failles qui touchent toutes les versions antérieures (CVE-2018-16737, CVE-2018-16738).

Ajout du 10/07/2019 : Pour simplifer l’installation sur Ubuntu 18.04 LTS, j’ai réalisé un backport du paquet tinc 1.0.35 depuis les dépôts d’Ubuntu 19.04. Le backport est disponible via le service PPA launchpad : https://launchpad.net/~virtubox/+archive/ubuntu/tinc

Cette version n’est pas vulnérable aux CVE-2018-16737 et CVE-2018-16738. Pour l’installer rien de plus simple :

sudo add-apt-repository ppa:virtubox/tinc -u -y
apt install tinc -t bionic-backports

Compilation

On commence par installer les dépendances permettant de compiler tinc :

sudo apt-get install git libssl-dev zlib1g-dev liblzo2-dev \
build-essential automake autoconf gettext texinfo -y

Puis on clone le dépôt Git :

cd /usr/local/src
git clone git://tinc-vpn.org/tinc
cd tinc

On réalise la configuration avant de compiler :

autoreconf -fsi
./configure --prefix=

Puis on lance la compilation :

# -j définit le nombre de threads utilisés pour la compilation
# $(nproc) permet d'obtenir le nombre de threads disponibles sur le CPU
make -j"$(nproc)"

Si la compilation se déroule sans erreur, on peut alors installer tinc avec la commande :

sudo make install

Ajout des services systemd

La dernière étape pour terminer l’installation est la création des services systemd permettant d’exécuter Tinc et ses instances (réseaux privés) dès le démarrage de la machine. Il faut en effet créer deux services distincts, le premier permettant de gérer l’exécution de Tinc, et le second l’exécution des instances Tinc (sous le format tinc@nom_du_reseau).

Le service tinc

Le fichier à créer est /lib/systemd/system/tinc.service dont le contenu est le suivant :

# This is a mostly empty service, but allows commands like stop, start, reload
# to propagate to all tinc@ service instances.
[Unit]
Description=Tinc VPN
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/etc/tinc

[Install]
WantedBy=multi-user.target

On peut ensuite activer le service via la commande :

sudo systemctl enable tinc.service

Le service pour les instances tinc@

Le second service qui permet la gestion des instances Tinc est à créer dans /lib/systemd/system/tinc@.service, voici son contenu :

[Unit]
Description=Tinc net %i
PartOf=tinc.service
ReloadPropagatedFrom=tinc.service

[Service]
Type=simple
WorkingDirectory=/etc/tinc/%i
ExecStart=/usr/sbin/tincd -n %i -D
ExecReload=/usr/sbin/tincd -n %i -kHUP
KillMode=mixed
TimeoutStopSec=5
Restart=always
RestartSec=60

[Install]
WantedBy=tinc.service

Il permettra par la suite d’activer séparément les réseaux privés (instances) Tinc via la commande :

sudo systemctl enable tinc@nom_du_reseau

Il n’est donc pas nécessaire d’utiliser cette commande immédiatement, puisqu’il faut tout d’abord réaliser la configuration de notre réseau privé.

Configurer Tinc

La configuration d’une instance Tinc

L’ensemble des fichiers de configuration de Tinc sont à placer dans le répertoire /etc/tinc, dans lequel la configuration de chaque instance se fera dans un répertoire portant le nom de l’instance.

Quelques informations sur la configuration utilisée pour notre exemple :

notre instance/réseau privé se nomme jesuisadmin_reseau, sa configuration se trouve donc dans le répertoire /etc/tinc/jesuisadmin_reseau
nos 3 serveurs se nomment respectivement gfs1, gfs2 et rbpy.
Nous avons choisi d’utiliser la plage d’adresses 10.0.0.0/24 pour notre réseau privé Tinc

Afin vous donner tout de suite une vue d’ensemble de la configuration d’un réseau privé avec Tinc, voici le répertoire de configuration du réseau jesuisadmin_reseau, une fois toutes les étapes du tutoriel terminées :

├── jesuisadmin_reseau
│   ├── hosts
│   │   ├── gfs1
│   │   ├── gfs2
│   │   └── rbpy
│   ├── rsa_key.priv
│   ├── tinc-down
│   ├── tinc-up
│   └── tinc.conf

On y retrouve :

tinc.conf : fichier de configuration principal qui contient notamment le nom de la machine, l’interface réseau à utiliser et le protocole de l’instance (ipv4/ipv6).
tinc-up et tinc-down : les scripts permettant de démarrer et d’arrêter l’instance Tinc
rsa_key.priv : la clé privée du serveur
répertoire hosts : le répertoire qui contient les configurations partagées de chacun des noeuds connectés au réseau privé.

Les étapes pour configurer nos 3 machines vont donc être :

Réaliser la configuration initiale de chaque machine
Générer les clés publiques/privées de chaque machine
Synchroniser le répertoire hosts entre les machines

Configuration initiale

– À réaliser sur les 3 serveurs –

On commence donc par créer le répertoire /etc/tinc/jesuisadmin_reseau :

mkdir -p /etc/tinc/jesuisadmin_reseau

Puis on créer le fichier de configuration principal tinc.conf dans ce nouveau répertoire :

nano /etc/tinc/jesuisadmin_reseau/tinc.conf

Dans lequel nous allons définir la configuration de notre réseau privé, en commençant par gfs1 :

# Interface réseau à utiliser
Interface = tun0
# Identifiant de la machine sur le VPN
Name=gfs1
AddressFamily = ipv4

On réalise la même opération sur gfs2, avec une petite différence dans le fichier tinc.conf puisqu’on y ajoute la directive ConnectTo :

# Interface réseau à utiliser
Interface = tun0
# Identifiant de la machine sur le VPN
Name=gfs2
AddressFamily = ipv4
# sur le client
ConnectTo = gfs1

On termine par le troisième serveur rbpy dont la configuration sera similaire à gfs2 :

# Interface réseau à utiliser
Interface = tun0
# Identifiant de la machine sur le VPN
Name=rbpy
AddressFamily = ipv4
# sur le client
ConnectTo = gfs2

Générer les clés publiques/privées

Pour pouvoir initier la connexion entre les différents serveurs, Tinc se base sur un échange de clés cryptographiques, sur le même principe que les clés SSH. Il faut donc créer un répertoire hosts dans lequel nous allons définir les adresses IP publiques et privées de chacun des serveurs, ainsi que leurs clés publiques.

On commence donc par créer le répertoire hosts :

mkdir -p /etc/tinc/jesuisadmin_reseau/hosts

Avant de générer la clé publique et privée d’un serveur, en utilisant la commande :

sudo tincd -n jesuisadmin_reseau -K4096

L’argument -K4096 définit la taille de la clé RSA à générer. Lors de l’exécution de cette commande, vous devriez obtenir deux nouveaux fichiers :

la clé privée du serveur /etc/tinc/jesuisadmin_reseau/rsa_key.priv
la clé publique du serveur dans le fichier de configuration portant le nom de l’hôte : /etc/tinc/jesuisadmin_reseau/hosts/nom_du_serveur

Dans ce dernier fichier, nous allons devoir ajouter avant la clé publique, l’adresse publique et privée de l’hôte. Il est également possible d’y ajouter d’autres paramètres, comme par exemple les ciphers à utiliser pour la connexion.

Voici un exemple de fichier de configuration pour le serveur gfs1 :

Address = 5.9.XXX.XXX
Subnet = 10.0.0.1/32
Cipher=aes-256-cbc
Digest=sha256

-----BEGIN RSA PUBLIC KEY-----
MIICCgKCAgEApd4Gf48I1Cnvgb8Hw67yIWmlhoe9yiz80Fr1IF0gjjbDpzsZwkg+
6r7KaDIWmVdoSYiOlrutohH0105daS+YyJbTVP6heGYAlStVqMFL/rT2CbZvYEfe
F1l/PYtEGrbTRJDQgpwByXbmgvha2DcKBJFcfduH85FnYv7KzZ94vmYBwhZe8ArA
f/0XeEpR7fYfIdxN7Z5jS0olkd5mUyrpXVwkmbJ/9q3j5vuVMon9BLDAf1XP4oXn
ehRPLdh39XswFfF35rrxtLy03a+iPTZuhDBbVl2V/UVcVtyQHUNwTzrOvqBgYfaa
Q2L8hW6U/bvvOpj2NCN3YIm8cDR2NNScORXVSqm0xpTk+vCjETrOpBGR1z2JEWdT
3nPw+a7oAwfgCzSOvRx1MW+w1GqF+iil/ADQXcQa78i0xRIl/xCG0taI5EdUnRAq
7R5Y2kDtMt6LUdvOLPGpYFdIP859jTxSXSkkvWeEO7syuvVMdMLfBIGG1zczqQ6+
RLKCV+l0JwZpw4YEiJLHlzZQax3J7eBxlsv3gJoEWeuPZaPP/dUcREisqhrXLLT3
Jiq+aqMolbSzcXvRIGrcNVko4d82SStzpSJwehREhyDrgzOSMhEhTy7m/G3YvcGQ
v0F0bnuk1tqf6VUT9+MTBstaRTLEaRsc5RqI26lkCWwfO7c0WHkDLg0CAwEAAQ==
-----END RSA PUBLIC KEY-----

Dans lequel on retrouve les options :

Address est l’IP publique du serveur
Subnet est l’IP privée du serveur
Cipher & Digest les paramètres TLS (facultatif)

Synchroniser le répertoire hosts

Une fois cette étape réalisée sur chacun des serveur, il faut également procéder à l’échange des clés publiques entre les serveurs. Autrement dit, le contenu du répertoire hosts doit être le même sur chaque serveur. Dans notre cas, on doit y retrouver trois fichiers configurations : gfs1, gfs2 et rpby.

Vous êtes libre d’utiliser la méthode de votre choix pour synchroniser le contenu du répertoire hosts entre vos serveurs, voici quelques propositions pour échanger les fichiers de configuration entre les serveur :

Synchroniser le répertoire avec rsync
Transférer les fichiers avec scp
Utiliser un dépôt git pour ajouter chaque serveur

Une fois de répertoire hosts synchronisé entre les serveurs, il ne reste plus qu’à configurer les scripts d’initialisation et d’arrêt de Tinc.

Configuration des exécutables Tinc

La dernière étape avant de pouvoir connecter nos serveurs est la création des scripts exécutables de créer et démarrer/arrêter l’interface réseau virtuelle utilisée pour se connecter au réseau privé. Pour cela il faut créer les fichiers tinc-up et tinc-down dans /etc/tinc/jesuisadmin_reseau dont voici le contenu pour gfs1 :

tinc-up

#!/bin/sh
# /etc/tinc/jesuisadmin_reseau/tinc-up
ip addr add 10.0.0.1/24 dev $INTERFACE
ifconfig $INTERFACE up

tinc-down

#!/bin/sh
# /etc/tinc/jesuisadmin_reseau/tinc-down
ifconfig $INTERFACE down

Sur les deux autres serveurs, le contenu des deux scripts sera quasiment le même, puisque l’unique différence sera l’adresse IP de l’interface réseau.

Une fois les deux fichiers créés sur chacun des serveurs, il ne reste plus qu’à les rendre exécutables :

sudo chmod 755 /etc/tinc/jesuisadmin_reseau/tinc-*

Démarrer et administrer Tinc

Vérifier la configuration du pare-feu

Avant d’initialiser la connexion entre les serveurs, il est important de faire une vérification : le port utilisé par Tinc est-il ouvert ? Par défaut, Tinc utilise le port 655, qu’il est donc nécessaire d’ouvrir préalablement. Si vous utilisez ufw, il vous suffit d’utiliser la commande

ufw allow 655

Mais vous pouvez également le faire directement via iptables :

iptables INPUT -p tcp --dport 655 -j ACCEPT
iptables INPUT -p udp --dport 655 -j ACCEPT

Démarrer et arrêter Tinc

Si vous avez réussi à suivre toutes les étapes du tutoriel, vous êtes enfin arrivés**** au bout du tunnel (meilleur jeu de mot de l’année) puisque vous allez pouvoir initialiser votre réseau privé depuis votre premier noeud. Cela peut se faire directement via la commande tincd ou en utilisant un service systemd.

Avec tincd

démarrer le réseau jesuisadmin_reseau

sudo tincd -n jesuisadmin_reseau

Vous pouvez ensuite vérifier avec ifconfig ou ip addr show que la création de l’interface réseau tun0 s’est bien déroulée et que l’adresse IP de cette dernière correspond bien à votre configuration. Il ne reste plus qu’à tester le ping entre vos machines.

Un problème de connexion ? Vous pouvez à tout moment arrêter la connexion au réseau tinc avec la commande suivante :

arrêter le réseau jesuisadmin_reseau

sudo tincd -n jesuisadmin_reseau -k

Avec un service systemd

Pour utiliser un service systemd, il faut tout d’abord activer le service associé à notre instance Tinc, ce qui se fait via la commande :

sudo systemctl enable tinc@jesuisadmin_reseau

On peut ensuite démarrer le service via la commande :

sudo service tinc@jesuisadmin_reseau start

Et après ?

Une fois la connexion entre les noeuds établie, vous pouvez librement utiliser votre réseau privé pour faire transiter vos données entre les serveurs.

Il sera peut-être nécessaire d’autoriser le trafic depuis le sous-réseau utilisé par Tinc via votre pare-feu. Dans le cas d’UFW, cela se fait via la commande :

sudo ufw allow from 10.0.0.0/24

Enfin pour un usage derrière un NAT, il vous suffit d’ajouter une redirection de port sur votre routeur/box pour pouvoir connecter votre serveur au réseau privé.

Installer MariaDB 10.3 sur Ubuntu 18.04 LTS

Sun, 03 Jun 2018 17:08:32 +0000

La nouvelle version stable de MariaDB a été publiée le 25 Mai 2018, avec la release 10.3.7. Dans ce tutoriel, nous allons voir comment installer MariaDB 10.3 sur Ubuntu 18.04 LTS et comment mettre à jour MariaDB 10.2 vers la version 10.3

Ce tutoriel est également applicable à Ubuntu 16.04 LTS

Il est tout d’abord important de préciser que les versions précédentes du serveur de base de données restent supportées jusqu’en 2020 pour la version 10.1 et 2022 pour la version 10.2. Il n’y a donc aucune raison de se précipiter pour effectuer la mise à jour sur votre serveur.

Cependant, comme le précise les notes de publications de MariaDB, la version 10.3 est une évolution de la version 10.2, avec de nombreuses nouvelles fonctionnalités, mais toujours les fonctionalités backportées et réimplémentées de MySQL.

On peut même trouver le message suivant dans l’article concernant la mise à jour de MariaDB 10.2 vers la version 10.3 :

On most servers upgrading from 10.2 should be painless

La majorité de mes serveurs utilisant déjà MariaDB 10.2, j’ai souhaité vérifier si la mise à jour se faisait effectivement sans problème.

Installer MariaDB 10.3

La première étape, que ce soit sur pour installer MariaDB sur un nouveau serveur, ou pour mettre à jour MariaDB 10.2 est l’ajout des dépôts APT. Et pour cela MariaDB propose un script qui réalise l’ajout des dépots et l’importation des clés GPG automatiquement. Il est compatible avec les distributions linux les plus populaires : Ubuntu 14/16/18.04 LTS - Debian 7/8/9 - Centos 6/7

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
| sudo bash -s -- --mariadb-server-version=10.3 --skip-maxscale

Ce script réalise l’ajout des dépôts APT pour MariaDB Server/Cluster et Percona XtraBackup. L’argument --mariadb-server-version= permet de choisir la version de MariaDB que l’on souhaite installer (10.1 ou 10.2 ou 10.3). Et l’argument --skip-maxscale désactive l’ajout des dépôts de MariaDB MaxScale.

Sur un nouveau serveur

S’il s’agit d’une installation initiale, sur un nouveau serveur, après avoir ajouté les dépôts APT, il vous suffit d’installer le paquet mariadb-server

sudo apt-get update && sudo apt-get install mariadb-server -y

Durant l’installation, vous pouvez définir le mot de passe root, ou le laisser vide afin d’utiliser ensuite la commande mysql_secure_installation qui permet de sécuriser un serveur MySQL en répondant à quelques questions.

Mise à jour depuis MariaDB 10.2

Pour mettre à jour MariaDB depuis la version 10.2 vers la version 10.3, il est nécessaire de prendre quelques précautions avant de mettre à jour les paquets pour être sûr de ne pas perdre de données.

Pour cela, le plus simple est de réaliser une copie du dossier /var/lib/mysql qui contient vos bases de données avant de désinstaller mariadb

# on arrête le serveur MySQL
sudo service mysql stop

# on copie le dossier /var/lib/mysql
sudo cp -rf /varlib/mysql /var/lib/mysqlold

# on désinstalle mariadb 10.2
sudo apt-get autoremove mariadb-server

On peut ensuite remplacer les dépôts APT de la version 10.2 par ceux de la version 10.3 en utilisant le script mariadb_repo_setup

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
| sudo bash -s -- --mariadb-server-version=10.3 --skip-maxscale

Puis mettre à jour la liste des dépôts :

sudo apt-get update

La dernière étape est de lancer l’installation de la nouvelle version de mariadb

sudo apt-get install mariadb-server

Durant la mise à jour, vous pouvez laisser le mot de passe root vide pour conserver celui que vous avez définit précédemment.

Une fois la mise à jour terminée, vous pouvez vérifié le status de MariaDB avec la commande :

service mysql status

Si la mise s’est bien déroulée, n’oubliez pas d’utiliser la commande mysql_upgrade pour mettre à jour vos base de données. Si vous n’avez placé les identfiants du serveur MySQL dans un fichier .my.cnf, mysql_upgrade s’utilise de la même façon que mysql :

mysql_upgrade -u root -p

Revenir à MariaDB 10.2

J’ai déjà réalisé cette mise à jour sur 6 serveurs sans rencontrer le moindre problème. Mais dans le cas d’un problème suite à la mise à jour, vous pouvez à tout moment revenir sur la version 10.2 en utilisant la copie du dossier /var/lib/mysql réalisée plus tôt.

Commencez par remettre en place les dépôts APT de MariaDB 10.2, qui sont normalement récupérable dans un fichier nommé mariadb.list.old_1

# cp -f /etc/apt/sources.list.d/mariadb.list.old_1 /etc/apt/sources.list.d/mariadb.list

Mais que vous pouvez également ajouter en utilisant le script mariadb_repo_setup :

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
| sudo bash -s -- --mariadb-server-version=10.2 --skip-maxscale

Ensuite, désinstaller mariadb-server

sudo apt-get autoremove mariadb-server

Et Remplacez le dossier /var/lib/mysql avec le contenu du dossier /var/lib/mysqlold

# on déplace le dossier /var/lib/mysql
sudo mv /var/lib/mysql /var/lib/mysqlnew

# on remet en place le dossier /var/lib/mysqlold
sudo mv /var/lib/mysqlold /var/lib/mysql

# on définit à nouveau le propriétaire du dossier
sudo chown -R mysql:mysql /var/lib/mysql

La dernière étape est de réinstaller MariaDB 10.2

sudo apt-get update
sudo apt-get install mariadb-server

Configuration réseau d'une machine virtuelle KVM sur Proxmox

Wed, 09 May 2018 21:14:42 +0000

Si la configuration réseau d’un container LXC peut s’effectuer directement depuis l’interface web de Proxmox VE, il ~~est~~ était nécessaire (et pénible) de la réaliser via la console NoVNC pour les machines virtuelles KVM tournant sous Debian/Ubuntu.

Nous allons voir dans ce tutoriel, comment configurer le réseau d’une machine virtuelle KVM en utilisant qemu-nbd, qui permet de monter le disque d’une VM et donc d’accéder directement aux fichiers de configuration des interfaces réseau. Si la procédure peut sembler longue pour configurer une seule VM, il sera tout à fait possible de l’automatiser avec un script bash par la suite.

PS : Alors que j’écris ces lignes, le module cloud-init a déjà fait son apparition sur Proxmox VE 5.1, et représentera très probablement une excellente alternative à la solution présentée dans cette article. Mais cela fera sûrement l’objet d’un autre article.

Installer le client nbd

Pour commencer, il faut installer le client nbd sur votre serveur Proxmox.

apt-get update && apt-get install nbd-client -y

Puis charger le module :

modprobe nbd max_part=16

Et enfin, pour rendre la configuration persistente, on utilise :

echo "nbd" >> /etc/modules
cat > /etc/modprobe.d/nbd.conf <<\EOT

options nbd max_part=16

EOT

Monter le disque d’un VM avec qemu-nbd

Cas d’une machine virtuelle sans LVM

Pour monter le disque d’une VM, on utilise qemu-nbd :

qemu-nbd -c /dev/nbd0 vm-101* -f raw

vm-101 correspond à l’ID de la machine virtuelle dans Proxmox.

On créer ensuite un dossier dans lequel nous allons pouvoir monter le disque de la machine virtuelle :

mkdir /mnt/ma-vm
mount /dev/nbd0p1 /mnt/ma-vm

Cas d’une machine virtuelle avec LVM

Dans le cas d’un LVM, il n’est pas possible de monter directement la partition car il faut pour cela connaître le nom du volume group qui contient les fichiers de configuration.

La procédure pour monter le disque est quasiment la même que précédemment :

qemu-nbd -c /dev/nbd0 vm-101*

Mais cette fois-ci on utilise vgscan pour détecter les volume groups disponibles

vgscan

On obtient alors la liste des volume group et on active le volume auquel on souhaite accéder :

vgchange -a y vp-vg

Nous pouvons alors monter le VG :

mkdir /mnt/ma-vm
mount /dev/vp-vg/root /mnt/ma-vm

Configurer l’interface réseau

Maintenant que le disque de notre machine virtuelle est monté dans le répertoire /mnt/ma-vm, nous pouvons modifier la configuation de ses interfaces réseau. On se déplace à la racine du disque :

cd /mnt/ma-vm/

Et nous pouvons modifier directement le fichier /etc/network/interfaces dans le cas d’une machine virtuelle tournant sous Debian ou Ubuntu (exemple avec Ubuntu 16.04 LTS sur un serveur dédié OVH) :

cat > etc/network/interfaces << EOF

auto ens18
iface ens18 inet static
 address IP.FAIL.OVER
 netmask 255.255.255.255
 broadcast IP.FAIL.OVER
 post-up route add IP.SERVEUR.DEDIE.254 dev ens18
 post-up route add default gw IP.SERVEUR.DEDIE.254
 pre-down route del IP.SERVEUR.DEDIE.254 dev ens18
 pre-down route del default gw IP.SERVEUR.DEDIE.254
 # dns-* options are implemented by the resolvconf package, if installed
 dns-nameservers 213.186.33.99

iface ens18 inet6 static
 address IP:V6:FAIL:OVER
 netmask 64
 post-up /sbin/ip -f inet6 route add XXXX:XXXX:XXX:XXff:ff:ff:ff:ff dev ens18
 post-up /sbin/ip -f inet6 route add default via XXXX:XXXX:XXX:XXff:ff:ff:ff:ff
 pre-down /sbin/ip -f inet6 route del XXXX:XXXX:XXX:XXff:ff:ff:ff:ff dev ens18
 pre-down /sbin/ip -f inet6 route del default via XXXX:XXXX:XXX:XXff:ff:ff:ff:ff

EOF

Terminer la configuration

Une fois la modification terminée, nous pouvons démonter le disque de la VM.

Sans LVM

Sans LVM, la méthode est la même que pour monter le disque

cd ..
umount /dev/nbd0p1
qemu-nbd -d /dev/nbd0
rm -r /mnt/ma-vm

Avec LVM

Avec LVM, il faut utiliser à nouveau vgchange de désactiver le volume group :

cd ..
umount /dev/vp-vg/root
vgchange -a n vp-vg
qemu-nbd -d /dev/nbd0
rm -r /mnt/ma-vm

Dernière étapes, redémarrer la machine virtuelle pour appliquer les modificiations. J’espère que cet article vous aidera à automatiser un peu plus vos création de machines virtuelles.

Migrer ses emails facilement avec imapsync

Sat, 21 Apr 2018 18:53:00 +0000

Si la migration de sites web ne pose généralement pas de problème, il est parfois plus délicat de migrer des emails, notamment lorsque deux serveurs n’utilisent pas le même software ou lorsqu’il s’agit d’une migration depuis/vers un hébergeur tiers. Heureusement pour simplifier cette étape, il existe de nombreux outils, dont imapsync qui est celui dont nous allons parler aujourd’hui.

imapsync est comme son nom l’indique un outil (développé en perl) qui permet de synchroniser des boîtes mail en utilisant le protocol imap. Cela ne fonctionnera bien sûr que si vous utilisez également l’IMAP pour récupérer vos emails, ou si vous n’effacez pas vos emails du serveur avec le protocol POP.

Nous allons voir dans ce tutoriel comment installer Imapsync (sur Ubuntu 16.04 LTS), puis comment synchroniser deux boîtes mails ainsi que les options proposées par cet outil.

Installer imapsync

Tout d’abord, il faut installer les pré-requis nécessaires à l’éxecution d’imapsync :

 sudo apt-get install \
libauthen-ntlm-perl \
libclass-load-perl \
libcrypt-ssleay-perl \
libdata-uniqid-perl \
libdigest-hmac-perl \
libdist-checkconflicts-perl \
libfile-copy-recursive-perl \
libio-compress-perl \
libio-socket-inet6-perl \
libio-socket-ssl-perl \
libio-tee-perl \
libmail-imapclient-perl \
libmodule-scandeps-perl \
libnet-ssleay-perl \
libpar-packer-perl \
libreadonly-perl \
libregexp-common-perl \
libsys-meminfo-perl \
libterm-readkey-perl \
libtest-fatal-perl \
libtest-mock-guard-perl \
libtest-pod-perl \
libtest-requires-perl \
libtest-simple-perl \
libunicode-string-perl \
liburi-perl \
libtest-nowarnings-perl \
libtest-deep-perl \
libtest-warn-perl \
make \
cpanminus

Il peut être nécessaire de mettre à jour le client IMAP et JSON avec cpanm :

sudo cpanm Mail::IMAPClient
sudo cpanm JSON::WebToken

On peut ensuite télécharger imapsync :

sudo wget https://imapsync.lamiral.info/dist/imapsync -O /usr/bin/imapsync

Et il ne reste plus qu’à le rendre éxecutable :

sudo chmod +x /usr/bin/imapsync

Vous pouvez ensuite obtenir la liste des variables disponibles en utilisant la commande imapsync

Synchroniser une boîte mail

Pour lancer la synchronisation d’une boite mail avec imapsync avec uniquement les options requises ressemble à :

 imapsync \
 --host1 serveur1.imap.tld \
	 --user1 boite@email.tld \
	 --password1 motdepasse1 \
	 --host2 serveur2.imap.tld \
	 --user2 boite@email.tld \
	 --password2 motdepasse2

Les options

Les mots de passes

Pour éviter d’avoir à entrer les mots de passe des boîte email en clair, vous pouvez les stockers dans des fichiers et utiliser l’argument --passfile1 et --passfile2 pour les charger automatiquement depuis les fichiers contenant les mots de passe.

Ce qui donne :

 imapsync \
 --host1 serveur1.imap.tld \
	 --user1 boite@email.tld \
	 --passfile2 /home/user/pass1 \
	 --host2 serveur2.imap.tld \
	 --user2 boite@email.tld \
	 --passfile2 /home/user/pass2

La connexion au serveur imap

Plusieurs options sont disponibles pour connecter imapsync à votre serveur mail, notamment le type de connexion utilisée. Par défaut imapsync essaira d’utiliser SSL ou TLS sur le port 993 pour se connecter. Voici des exemples pour la connexion sur le serveur à migrer (remplacer 1 par 2 pour le deuxième serveur) :

--nossl1 pour une connexion non chiffrée via le port 143 (non recommandé)
--ssl1 pour une connexion avec SSL via le port 993
--tls1 pour une connexion avec TLS via le port 143

Il y a également des options pour définir le type d’authentification que l’on peut définir via les arguments --authmech1 et --authmech2 dont les valeurs possibles sont (en majusule) :

PLAIN
LOGIN
CRAM-MD5

Les dossiers

La synchronisation des dossiers peut être une source de problèmes, notamment si les dossiers par défaut (Inbox, Spam, Archive, Envoyés) ne sont pas nommés de la même façon sur les deux serveurs mails. Pour cela imapsync offre plusieurs options :

--automap pour utiliser la reconnaissance automatique des dossiers par défaut
--nomixfolders pour éviter de fusionner des dossier ayant un nom similaire selon la sensibilité à la casse
--prefix1 pour retirer un prefix des dossiers à migrer
--prefix2 pour ajouter un prefix aux dossiers migrés
--skipemptyfolders pour ne pas recréer les dossiers vides sur le serveur de destination

Les options de migration

Pour accélerer la migration des emails, vous pouvez utiliser l’argument --usecache afin de stocker temporairement les UIDs des messages et accélérer les synchronisations suivantes (n’accélère pas la première migration). Vous pouvez également supprimer les messages du premier serveur avec l’argument --delete1. Enfin, avant de lancer votre migration, n’hésitez pas à utiliser l’argument --dry pour voir ce que ferai imapsync, sans l’appliquer.

Déployer un système de backup centralisé avec UrBackup

Mon, 13 Nov 2017 19:03:46 +0000

La gestion des backups peut rapidement devenir un problème lorsque l’on gère un grand nombre de serveurs, aussi bien pour gérer l’espace de stockage que pour le suivi des backups. Je vais donc vous présenter la solution UrBackup.

UrBackup est une solution de sauvegarde client/serveur qui propose plusieurs système de backup, sous forme d’image disque ou par répertoire de fichiers. Les principaux avantages de cette solution sont sa facilité de déploiement, sa gestion de l’espace de stockage avec des backups complets ou incrémentaux. Mais également sa compabilité avec Windows, MacOS et Linux.

Dans mon cas, UrBackup me sert à réaliser des sauvegardes de serveurs web. Il est installé sur un serveur Kimsufi KS-2A avec 2To de stockage commandé dans le cadre d’une offre à 8.99€/mois.

Mais il est tout à fait possible d’utiliser directement le backup storage proposé avec les serveurs OVH ou Online.net. Il suffit pour cela de monter le backup storage en NFS et de définir l’emplacement des sauvegardes UrBackup durant l’installation.

Installation du serveur UrBackup

L’installation du serveur UrBackup peut se faire sur Windows, Linux mais également sur les distributions comme FreeNas, OpenMediaVault ainsi que sur des NAS QNAP.

Vous pouvez trouver les instructions d’installation sur la page Downloads du site Urbackup. Dans mon cas j’ai choisi d’utiliser Ubuntu 16.04 LTS qui permet l’installation via les dépôts PPA.

On commence donc par ajouter le dépôt puis on installe le paquet urbackup-server :

sudo add-apt-repository ppa:uroni/urbackup
sudo apt-get update
sudo apt-get install urbackup-server

Durant le processus, vous serez inviter à choisir le répertoire dans lequel UrBackup va réaliser les sauvegardes. On peut ensuite accéder à l’interface d’administration via l’adresse http://IP-DU-SERVEUR:55414.

Les réglages principaux à définir après l’installation sont :

la création d’un utilisateur pour protéger l’accès à l’interface
le type de sauvegarde que vous souhaitez utiliser (image, fichiers, les deux)
le dossier par défaut à sauvegarder
la fréquence et le nombre de sauvegardes
le type de réseau (local ou sur internet)
les informations smtp pour l’envoi des notifications

Pour mes serveurs web, je n’utilise pour le moment que les sauvegardes de fichiers et le dossier par défaut à sauvegarder est /var/www.

Installation du client UrBackup

Pour linux, l’installation du client UrBackup se fait via une seule ligne de commande :

TF=`mktemp` && wget "https://hndl.urbackup.org/Client/2.3.4/UrBackup%20Client%20Linux%202.3.4.sh" -O $TF && sudo sh $TF; rm $TF

Durant l’installation, il vous sera demandé quel type de sauvegarde vous souhaitez utiliser pour la réalisation d’image disque (dans le cas où le système de fichier le permet). Par la suite la mise à jour du client sera automatique. Il est nécessaire d’ouvrir les ports 35621, 35622 et 35623 pour pouvoir connecter votre client au serveur Urbackup.

Si vous utilisez UFW, vous pouvez les ouvrir uniquement vers l’IP de votre serveur Urbackup :

ufw allow from IP.DE.VOTRE.SERVEUR-URBACKUP to any port 35621
ufw allow from IP.DE.VOTRE.SERVEUR-URBACKUP to any port 35622
ufw allow from IP.DE.VOTRE.SERVEUR-URBACKUP to any port 35623

Dès la première connexion au serveur (après avoir ajouté l’IP ou le hostname du client via l’interface UrBackup Server), une première sauvegarde complète du client sera réalisée, en fonction des options que vous aurez définie. Les sauvegardes suivantes seront incrémentielles.

La configuration du client urbackup se trouve dans le fichier /etc/default/urbackupclient, dans lequel vous pouvez changer l’option RESTORE="disabled" par RESTORE="server-confirms" pour autoriser la restauration d’un backup depuis l’interface d’administration de UrBackup Server.

Modification qui peut être effectuée avant de connecter le client au serveur avec la commande :

sed -i 's/RESTORE=disabled/RESTORE="server-confirms"/' /etc/default/urbackupclient

Sauvegarder vos bases de données

Si vous utilisez Urbackup en mode sauvegarde de fichiers, vous allez sûrement souhaitez sauvegarder vos bases de données. Et pour cela il y a deux solutions avec UrBackup.

Utiliser mysqldump

C’est la solution la plus simple à mettre en place, puisque vous pouvez utiliser un cronjob pour exécuter un script bash régulièrement. J’utilise par exemple un script modifié par mes soins disponible sur Github, que vous pouvez télécharger et utiliser librement. Voici les étapes à suivre :

Télécharger le script et le rendre exécutable

wget -O mysqldump.sh vtb.cx/mysqldump
chmod +x mysqldump.sh

Définir les identifiants root pour MySQL dans .my.cnf Pour accéder à vos bases de données, le script utilise les identifiants stockés dans le fichier ~/my.cnf. Ce fichier doit ressembler à :

[client]
user = root
password = votremotdepasse

ajouter un cronjob On ajoute une crontab en utilisant la commande crontab -e, puis en ajoutant la ligne :

@daily /root/mysqldump.sh > /dev/null

Il ne reste plus qu’à enregister la modification et le cronjob réalisera ainsi un backup journalier de chacune des bases de données, stocké par défaut dans le dossier /var/www/mysqldump.

Utiliser Percona XtraBackup pour des sauvegardes incrémentielles

UrBackup a une fois de plus prévu tout ce qu’il vous faut, puisqu’il permet de réaliser des sauvegardes incrémentales de votre serveur MySQL, en utilisant l’outil Percona XtraBackup qui réalise des sauvegardes à chaud du dossier /var/lib/mysql que vous pouvez restaurer en quelques minutes.

Avant de pouvoir utiliser XtraBackup, il vous faut installer le paquet percona-xtrabackup. Pour MariaDB, le dépôt apt est automatiquement ajouté par le script mariadb_repo_setup.

Exemple pour MariaDB 10.1

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
| sudo bash -s -- --mariadb-server-version=10.1 --skip-maxscale
sudo apt update && sudo apt install percona-xtrabackup -y

Exemple pour MariaDB 10.2

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
| sudo bash -s -- --mariadb-server-version=10.2 --skip-maxscale
sudo apt update && sudo apt install percona-xtrabackup-24 -y

Une fois XtraBackup installé, il faut éditer le fichier /usr/local/etc/urbackup/mariadbxtrabackup.conf, dans lequel il faut remplacer MARIADB_XTRABACKUP_ENABLED=0 par MARIADB_XTRABACKUP_ENABLED=1 et définir le mot de passe root de MySQL à la fin du fichier.

On peut ensuite activer la configuration avec la commande :

/usr/local/share/urbackup/scripts/setup-mariadbbackup

Et vérifier que la sauvegarde fonctionne avec la commande :

/usr/local/share/urbackup/scripts/mariadbxtrabackup > /dev/null

Pour restaurer la dernière sauvegarde, vous pourrez utiliser la commande :

/usr/local/share/urbackup/scripts/restore-mariadb

Comment avoir une excellente configuration HTTPS en 2017 ?

Fri, 13 Oct 2017 00:05:47 +0000

Article écrit par Wonderfall. Suite à la fermeture de son blog, j’ai souhaité (avec son accord) remettre en ligne ce dernier pour que son contenu reste accessible.

Cet article est adressé principalement aux administrateurs système, ou devrais-je plutôt dire aux administrateurs de système puisque parmi vous il y a non seulement des personnes qui en ont fait leur métier, et d’autres personnes qui en font leur passion (comme moi, peut-être…). Par manque de temps et surtout parce que je parlerai des outils sur lesquels j’ai mis la main, j’utiliserai un seul serveur web au cours de cet article, le bien connu nginx. Cet article reprendra en partie un ancien article de mon précédent blog : Des certificats ECDSA avec Let’s Encrypt.

1. Mettons les choses en ordre…

Jetez un coup d’oeil à l’image d’en-tête de l’article. Vous vous y reconnaitrez peut-être. Ou peut-être pas. Certains parmi vous sont complètement perdus, et ces noms ne leurs évoqueront rien. D’autres sont déjà à l’aise, savent grossièrement à quoi cela correspond. Eh bien, j’en fais moi-même partie. Dans un esprit d’humilité, je reconnais ne pas avoir les capacités nécessaires pour comprendre à 100% les notions conceptuelles, mathématiques, et toutes les subtilités derrière les technologies que je mentionnerai. Cela dit, ça ne m’empêchera pas de tenter, au moins, de vulgariser et de montrer des exemples. Ma vulgarisation sera approximative, elle comportera peut-être des erreurs, je l’admets. Mais tant que j’estime ne pas mettre en danger la sécurité des personnes (au contraire…), et tant que vous avez compris ce que je voulais dire dans ce paragraphe, je me sens libre de continuer à écrire cet article.

Ce qui m’a poussé à le faire, c’est que le nombre de demandes d’aide à propos de la configuration HTTPS est devenu croissant. Vous vous souvenez de Mastodon ? Aujourd’hui le nombre d’instances est bien plus important, et plus d’instances, ça veut dire aussi plus de configurations. Le principal site qui recense les différentes instances classe désormais les instances en fonction de leur configuration HTTPS, à travers Cryptcheck et depuis peu l’Observatoire Mozilla (qui comprend Cryptcheck également puisqu’il fait appel à des tests tiers). Évidemment, c’est la folie : tout le monde veut absolument avoir son instance le plus haut possible dans la liste, donc il faut à tout prix mieux sécuriser… si seulement c’était le cas pour les banques aussi, mais passons.

Et puis, certains iraient bien se masturber un coup sur un A+ de Cryptcheck/Qualys. Mais, pourquoi pas ? Ces questions ne me concernent pas. On atteindra cette finalité si c’est ce que vous voulez, vos motivations sont les vôtres. Quand je parle d’une excellente configuration, c’est effectivement une configuration qui vous donnera une note maximale sur ces outils. Dans le titre, je n’ai pas parlé de “comment configurer HTTPS”, nuance. Mais il ne faut pas non plus suivre mon tutoriel n’importe comment, parce que premièrement, la compatibilité des clients en prend forcément un coup, et deuxièmement, certains mécanismes tels que HPKP peuvent vous casser la gueule si vous les utilisez n’importe comment. Lisez, puis faites. Pas l’inverse…

D’avance, j’annonce que je ne me prendrai pas la tête avec la compatibilité. Donc ne venez pas me dire que votre site ne fonctionne pas sur X ou Y, parce que je vous aurais prévenu.

2. Choix de la bibliothèque SSL/TLS

Les bibliothèques SSL/TLS fournissent une implémentation d’algorithmes cryptographiques et de protocoles de communication sécurisés (les différentes versions de SSL et TLS : SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3..). Aujourd’hui, 3 bibliothèques sont compatibles avec nginx :

OpenSSL : la plus connue, et la plus présente.
LibreSSL : fork d’OpenSSL par OpenBSD.
BoringSSL : fork d’OpenSSL par Google.

Il faut dire que Heartbleed a porté en 2014 un coup à la popularité d’OpenSSL. Non pas que ce fut la première faille découverte, loin de là, mais il y a eu une prise de conscience sur la qualité du code d’OpenSSL et des implémentations trop anciennes qui y sont présentes. OpenBSD fidèle à sa réputation, créa son fork LibreSSL dans le but de littéralement nettoyer OpenSSL et de le débarrasser d’algorithmes dépassés et dangereux d’utilisation. Aujourd’hui, il n’y a pas seulement OpenBSD qui utilise LibreSSL à la place d’OpenSSL en tant que bibliothèque par défaut du système. En effet, d’autres distributions ont sauté le pas, y compris macOS.

Quant à Google, ce n’est pas vraiment la même raison qui a conduit à créer BoringSSL. En effet, ils maintenaient déjà une version d’OpenSSL interne avec de nombreux patchs, Heartbleed a seulement été l’élément déclencheur pour repartir d’une page blanche, et c’est bien ce travail qui a été mené. Peu importe si les mises à jour cassent la compatibilité API/ABI avec d’autres logiciels comme nginx, Google met de toute façon en garde :

EN : Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

FR : Bien que BoringSSL soit un projet open-source, il n’est pas destiné à un usage général, comme OpenSSL l’est. Nous ne recommandons pas que les tierces parties dépendent dessus. Faire ainsi sera probablement source de frustrations puisqu’il n’y aucune garantie de la stabilité de l’API/ABI.

En pratique, BoringSSL fonctionne avec nginx et les développeurs ont accepté de faire quelques efforts pour satisfaire les quelques curieux qui souhaitent l’utiliser de cette façon. En revanche, pas de support de OCSP stapling.

En pratique, qu’est-ce que je dois choisir ?

Utiliser la bibliothèque de son système est une bonne chose car les mises à jour sont simples, donc il n’est pas nécessaire de recompiler nginx à chaque fois. Sur Debian, ça reste pour le moment OpenSSL. La version de Jessie est maintenue, mais elle est figée du point de vue technologique, donc en pratique, on aura pas quelques algorithmes récents (même si on peut s’en passer) et quelques features intéressantes compatibles avec nginx, mais nécessitant une version d’OpenSSL supérieure. La version d’OpenSSL fournie par Stretch (1.1.0) est aujourd’hui la version la plus récente d’OpenSSL.

Si vous êtes prêts à ne pas utiliser une bibliothèque système, je vous recommande sans hésiter LibreSSL, pour les raisons que j’ai énoncées plus haut. OpenBSD est une équipe de confiance, vraiment (et même un peu trop) perfectionniste. BoringSSL est celui qui vous proposera le plus de nouveautés, dont l’utilisation des versions drafts de TLS 1.3, des expérimentations d’algorithmes quantum proofs qui peuvent être retirées du jour au lendemain par Google (comme CECPQ1), etc. mais de mon point de vue, ce n’est vraiment pas quelque chose à utiliser sur une machine en production, il n’y a même pas de versioning, à utiliser plus pour la curiosité donc.

Si vous avez fait le choix d’utiliser une autre bibliothèque que la bibliothèque utilisée par défaut par le système, vous allez devoir recompiler nginx. Inutile que je passe mon temps à faire un tutoriel, il y en a… plein : ici (2015) pour LibreSSL, là (2016) pour BoringSSL (je me fais un peu de publicité, je sais). Mais si vous ne voulez pas vous prendre la tête, je vous propose des scripts voire des images Docker :

Angristan/nginx-autoinstall : compile nginx sur Debian, avec le choix entre OpenSSL et LibreSSL et d’autres modules !
wonderfall/boring-nginx : une image Docker basée sur Alpine Linux, avec nginx compilé depuis les sources avec BoringSSL.
xataz/nginx : une image Docker basée sur Alpine Linux qui installe simplement nginx, mais Alpine Linux utilise LibreSSL par défaut.
ajhaydock/BoringNginx : des scripts pour Debian/CentOS et une image Docker basée sur CentOS pour utiliser nginx avec BoringSSL.

3. D’abord, les certificats !

a. Savoir (un peu) de quoi on parle

Inutile de s’attaquer à la configuration d’HTTPS sans passer par la génération de certificats. Mais d’abord, pourquoi parle-t-on de certificats ? Deux mots pour décrire les buts d’HTTPS : chiffrement et authenticité. Ce dernier point repose sur la certification de la clé publique avec un certificat (d’un certain format nommé X.509) signé par une autorité connue (CA pour Certificate Authority). L’ensemble des composantes visant à gérer le cycle de vie des certificats porte le nom de Public Key Infrastructure (PKI). Les certificats définissent les informations d’appartenance de la clé publique, et définissent également les hostnames pour lesquels le certificat est valide. Par exemple, le certificat que j’utilise pour psychedeli.cat est aussi valable pour isso.psychedeli.cat (un sous-domaine). Ces informations, vous pouvez les obtenir très simplement depuis votre navigateur qui lit ces informations depuis le certificat fourni par le serveur web.

Voyez l’illustration comme un arbre, on part de la racine (= root), on passe par les branches ramifiées (certificats intermédiaires) et enfin on atteint les feuilles (= leaf)

Nous allons ici utiliser Let’s Encrypt, qui est comme je vous l’ai dit une autorité de certification. Le principe est celui d’une chaîne de confiance : le certificat root (fourni ici par ISRG) est le certificat originel, qui peut signer des certificats intermédiaires (ceux de Let’s Encrypt). Ces certificats intermédiaires permettront de signer les certificats que nous utilisons tous les jours, qu’on appelle aussi leaf certificate, ils permettront de signer des clés temporaires dérivées de la paire clé publique/privée qui sera utilisée pour sécuriser une session. Ces certificats sont en fin de chaîne et ce sont eux que nous allons obtenir.

b. Générer des certificats ECDSA (P-384)

Plus précisément, on va le faire d’une façon un peu plus manuelle mais loin d’être difficile. Cela nous permettra :

De gérer nous-même le renouvellement de la paire de clés, ce qui nous permet d’utiliser plus sereinement et efficacement HPKP.
D’utiliser une autre approche d’algorithme asymétrique que RSA, ECDSA qui repose donc sur la cryptographie sur les courbes elliptiques (ECC).

Les algorithmes de la famille des courbes elliptiques proposent d’utiliser des clés bien plus courtes, pour une sécurité comparable à celle offerte par RSA, et ils permettent également d’économiser des ressources. Voici des tests de performance que j’ai réalisés avec ma machine :

$ openssl speed rsa
 sign verify sign/s verify/s
rsa 2048 bits 0.000549s 0.000025s 1821.4 39636.0
rsa 3072 bits 0.002579s 0.000051s 387.7 19471.4
rsa 4096 bits 0.005829s 0.000089s 171.5 11270.1

$ openssl speed ecdsa
 sign verify sign/s verify/s
 256 bit ecdsa (nistp256) 0.0000s 0.0001s 25425.7 10819.8
 384 bit ecdsa (nistp384) 0.0002s 0.0007s 5749.2 1340.1
 521 bit ecdsa (nistp521) 0.0003s 0.0006s 3007.0 1659.5

ECDSA en soit n’est pas directement comparable à RSA, il doit être associé à des courbes elliptiques, et ici, ce sont les courbes NIST P-256, P-384, et P-521, qui sont utilisées. Le nombre de signatures/secondes est tout simplement bien meilleur avec ECDSA. Quid de la sécurité ? Selon la NSA elle-même, une clé ECC de taille 384 bits offrirait une sécurité équivalente à une clé RSA de taille 7680 bits.

Depuis Février 2016, Let’s Encrypt peut émettre des certificats ECDSA (les choix sont P-256 et P-384). Malheureusement, le client officiel certbot ne le permet pas. Alors soit on peut utiliser d’autres clients comme lego qui vont mâcher le travail, soit on peut toujours utiliser certbot mais se débrouiller nous-même pour générer notre clé privée et notre demande de signature de certificat (dans un fichier CSR).

Commençons par générer une clé privée P-384 :

openssl ecparam -genkey -name secp384r1 > privkey.pem

On peut maintenant créer un fichier CSR, qui contient toutes les informations relatives à une demande de certificat. Comme moi, vous aurez peut-être envie de générer un seul certificat pour plusieurs domaines, ceci peut se faire avec l’extension SAN de X.509. Vous devez tout d’abord copier le fichier /etc/ssl/openssl.cnf dans votre répertoire de travail. Par exemple :

cp /etc/ssl/openssl.cnf custom.cnf

On va modifier ce custom.cnf pour bénéficier de SAN et donc d’un certificat valable, en gros, pour plusieurs domaines. Voici comment. Dans la section [ req ], décommettez req_extensions = v3_req. Dans la section [ v3_req ], ajoutez une nouvelle ligne : subjectAltName = @alt_names. Enfin, tout se passe dans [ alt_names ] pour ajouter vos domaines. Cette section n’existe pas, il faut la créer, par exemple tout à la fin du fichier.

# custom.cnf

...

[ req ]
...
req_extensions = v3_req

...

[ v3_req ]
...
subjectAltName = @alt_names
### OCSP Must-Staple, cf. plus loin
#tlsfeature = status_request # OpenSSL >=1.1.0
#1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05 # OpenSSL <=1.0

...

[ alt_names ]
DNS.1 = domain.tld
DNS.2 = sub1.domain.tld
DNS.3 = sub2.domain.tld
...
DNS.n = subn.domain.tld

Pour chaque domaine souhaité, on l’associe à la directive DNS.k où k, allant de 1 à n, est incrémenté sur chaque nouvelle ligne. Le SAN que peut signer Let’s Encrypt peut atteindre 100 (autrement dit, 100 domaines différents dans un seul certificat X.509), donc n <= 100.

Enregistrez toutes ces modifications. Vous pouvez désormais générer votre CSR avec la commande suivante :

openssl req -new -sha256 -key privkey.pem -out csr.der -config custom.cnf

Rentrez des informations, mais laissez Common Name vide, et ne protégez pas avec un mot de passe. Vous devez, à ce stade, avoir en votre possession un privkey.pem et un csr.der.

Pour demander à Let’s Encrypt de nous émettre un certificat à partir de notre demande, il suffit d’utiliser certbot de cette façon, avec l’argument --csr pour fournir le CSR :

certbot certonly --standalone --agree-tos -m admin@domain.tld \
 --csr /path/to/csr.der \
 --cert-path /path/to/cert.pem \
 --chain-path /path/to/chain.pem \
 --fullchain-path /path/to/fullchain.pem

Congrats! Vous avez ainsi obtenu :

cert.pem : leaf certificate, contient entre autres la clé publique
chain.pem : certificat de la chaîne Let’s Encrypt
fullchain.pem : concaténation des deux fichiers ci-dessus
privkey.pem : clé privée qu’on avait générée tout à l’heure

DNS CAA : N’oubliez pas d’ajouter des enregistrements CAA dans votre zone DNS, ils permettent de définir quel CA est autorisé à émettre un certificat pour le domaine domain.tld. Exemple pour ce domaine avec Let’s Encrypt :

domain.tld. CAA 0 issue "letsencrypt.org"
domain.tld. CAA 0 iodef "mailto:admin@domain.tld"

4. Le protocole SSL/TLS

Je vous recommande la lecture de cet article : CryptCheck, vérifiez vos implémentations de TLS.

TLS et son ancêtre SSL sont des protocoles qui sont utilisés pour sécuriser des échanges sur Internet. Par exemple conjointement avec HTTP pour donner HTTPS, le joli cadenas vert que vous avez dans votre barre d’adresse et qui ne veut pas dire grand chose parfois. Ils sont utilisés pour l’intégrité, l’authentification, la confidentialité (chiffrement), etc.

Aujourd’hui, la compatibilité de TLS 1.2 est répandue et il s’agit de la dernière version datant de 2008. TLS 1.0 (quoique…) et 1.1 peuvent être activés en cas de besoin de compatibilité. Pour cet article je ne vais garder que TLS 1.2. Il est par contre hors de question d’utiliser SSL. SSLv3 c’est poubelle (POODLE), SSLv2 c’est poubelle aussi (DROWN). D’ailleurs j’en profite : arrêtez de véhiculer cet abus de langage comme quoi SSL/TLS = SSL. J’aurais d’ailleurs trouvé ça appréciable si LibreSSL s’appelait plutôt LibreTLS, bref.

Donc on configure nginx pour n’accepter que TLS 1.2 :

ssl_protocols TLSv1.2;

TLS 1.3 arrivera incessamment sous peu, à l’heure où j’écrit cet article la 19e draft est encore très récente. OpenSSL 1.1.0 aura droit à TLS 1.3, tout comme LibreSSL qui devrait suivre. BoringSSL propose déjà TLS 1.3, j’ai testé et ça fonctionne même s’il faut l’activer de force. Cela dit je ne peux pas vraiment recommander d’utiliser un protocole au stade de brouillon et dont l’implémentation est encore trop jeune.

Histoire de faire une transition avec la partie suivante : avec TLS, tout commence par un handshake entre le client et le serveur. Le client envoie au serveur un message ClientHello avec une liste de suites cryptographiques supportées et de protocoles (par exemple pour HTTP/2). Le serveur renvoie à son tour un ServerHello avec entre autres, le choix de la suite cryptographique pour la session.

5. La suite cryptographique

Vous auriez déjà dû entendre parler du terme cipher. Cela désigne pour ceux qui ne le savent pas un algorithme qui chiffre et déchiffre, c’est une notion simple et cela existe depuis l’antiquité en fait, puisque ce sont les débuts même de la cryptographie. Mais avant que les 2 parties (ici, le serveur et le client) ne puissent chiffrer/déchiffrer leurs communications (par exemple du chiffrement par bloc avec un algorithme de cryptographie symétrique comme AES), il faut que les deux s’échangent une clé temporaire qui a été dérivée de la paire de clés du certificat, pour une session. Donc la question est de le faire d’une façon sécurisée à travers Internet, et éviter à tout prix les attaques MiTM.

a. L’échange de clés

Pour cela, on préfère l’échange de clés Diffie-Hellman (DH) car il y a la propriété de confidentialité persistante (Forward Secrecy FS ou Perfect Forward Secrecy PFS) : si la clé privée à partir de laquelle les clés de session ont été dérivés est compromise dans le futur, les clés de session utilisées précédemment pour des communications passées ne seront pas compromises. On pourrait en parler mathématiquement, mais là n’est pas vraiment le sujet, des personnes plus compétentes en parleront mieux que moi.

Avec TLS, on utilise DHE (Diffie-Hellman Exchange) ou ECDHE (Elliptic Curve Diffie-Hellman Exchange), ECDHE étant une variante de DHE. Sans rentrer dans les détails, la différence est dans la génération des clés : pour ce faire, DHE repose sur de l’algorithmique modulaire (simple), tandis que ECDHE repose sur le problème mathématique des courbes elliptiques (algébriques). Ces courbes (NIST, Brainpool, X25519…) ont les bénéfices que nous avons en partie évoqué plus haut.

De mon côté, je vous recommande carrément de n’utiliser que ECDHE pour l’échange de clés. Si vous voulez continuer à utiliser DHE, générez au moins une bonne clé de taille 4096 bits. Souvenez-vous des conséquences d’une clé trop petite, je parle bien sûr de Logjam. DHE souffre également d’un autre problème qui consiste en une MiTM assez violente : il est possible de downgrade vers une suite EXPORT dès que le serveur la supporte, et même si le client ne la supporte pas (merci @aeris pour cette remarque). Je persiste, utilisez donc seulement ECDHE, c’est très bien et dans la continuité de cet article. Et il n’y a rien de plus simple pour nginx puisqu’il suffit de jouer avec la directive ssl_ecdh_curve.

On peut ne pas renseigner cette directive, c’est possible, et dans ce cas le client et le serveur se mettront d’accord comme des grands sur la courbe à utiliser. Avec des versions de nginx relativement récentes (1.11+) et OpenSSL 1.1.0+ / LibreSSL / BoringSSL, il est possible de définir, côté serveur, un ordre de préférence. De mon côté, je préfère le faire (et si vous ne pouvez pas préciser plusieurs courbes, ne pas renseigner la directive est plus sage, sinon vous pouvez utiliser P-384 seulement) :

ssl_ecdh_curve X25519:P-521:P-384;
# ssl_ecdh_curve secp521r1:secp384r1; # Autres noms
# ssl_ecdh_curve secp384r1; # Si nginx pas récent

Petite aparté sur X25519 : cette courbe elliptique est le fruit des recherches du Dr. Bernstein. Comme indiqué sur ce site, la sécurité offerte par les courbes NIST n’est pas parfaite et mathématiquement douteuse. X25519 est “meilleur”, et en plus, il ne vient pas d’une agence proche de la NSA qui a tout intérêt à rendre la cryptanalyse des courbes NIST plus avantageuse pour elle.

X25519 n’étant disponible que sur des versions récentes de Chromium, il faut accepter d’autres courbes pour supporter par exemple Firefox et d’autres plateformes : P-521 et P-384, c’est très bien aussi. Ajoutez P-256 si la compatibilité est vraiment un problème.

b. Le chiffrement des données

Maintenant que la clé temporaire de session a été communiquée de façon sécurisée grâce à ECDH au client, ce dernier et le serveur peuvent échanger dans un canal chiffré dans une configuration symétrique, d’où l’utilisation d’algorithmes symétriques comme AES. C’est aujourd’hui le plus éprouvé. RC4, DES, 3DES… sont à bannir. Des chatons meurent à chaque fois que ces algorithmes sont utilisées. En 2017, on utilise normalement AES.

AES faisant du chiffrement par bloc, on introduit deux notions :

Le mode d’opération des blocs : CCM, CBC, GCM…
La taille des clés utilisées : 128, 256…

TLS 1.2 standardise notamment des suites cryptographiques qui reposent sur AES-CBC et AES-GCM, avec des clés 128 et 256 bits. Le mode GCM est nettement préférable à CBC. Pourquoi ? Dans le mode CBC, on utilise la fonction XOR (disjonction exclusive) avec un bloc de données en clair et un vecteur d’initialisation (IV), ensuite la sortie de XOR est chiffrée avec notre clé symétrique. Le mode GCM diffère de par son fonctionnement : un compteur pour chaque bloc est chiffré par la clé symétrique (dans le Corps de Galois), puis on utilise la fonction XOR avec la sortie obtenue et le bloc de données en clair : le bloc chiffré est formé ainsi. Pour ne pas aller plus loin dans les détails même si ce sont de grands mots qui peuvent faire peur, le fonctionnement inhérent de GCM est plus sécurisé que celui de CBC. Il est aussi très rapide. CBC est vulnérable aux attaques padding oracle.

Ne faites pas une erreur tentante : Qualys ne vous mettra pas du 100/100 partout si vous avez le malheur d’utiliser AES avec une clé 128 bits, même AES GCM. Donc certains vont forcer AES avec une clé 256 bits, mode GCM et CBC, parce que AES-256-GCM n’est pas forcément très bien supporté partout encore. C’est une fausse bonne idée ! AES-128-GCM est très bien, et quoiqu’il arrive, il faut privilégier GCM à CBC. C’est le comportement de la suite EECDH+AES par défaut, inutile d’en préciser plus. Pour utiliser GCM seulement, ce que je fais, vous pouvez utiliser EECDH+AESGCM.

ChaCha20 est un autre algorithme symétrique, qui a un fonctionnement intrinsèquement différent puisqu’il fonctionne par flot et non par blocs (comme RC4). C’est une alternative à AES proposée par le Dr. Bernstein encore une fois. Bien que la cryptanalyse faite sur ChaCha20 ne soit pas aussi importante qu’avec AES, on le considère comme sûr, et de toute façon, avoir une alternative est toujours une bonne chose (et le monopole cryptographique n’étant pas idéal de toute façon…). Il est moins rapide que AES sur des CPU qui disposent des instructions AES-NI, c’est-à-dire presque tous les CPU x86_64 actuels si je ne me trompe pas. Mais ChaCha20 offre des performances remarquables et se défend bien, si bien qu’il est préféré à AES quand on est sur des SoC ARM par exemple.

ChaCha20 est combiné à Poly1305, un type de code d’authentification de message (MAC) assurant l’intégrité des données, alors qu’on combine AES-GCM à HMAC-SHA2 par exemple. La qualité du HMAC dépendant de la fonction de hashage utilisée, je préfère ne pas utiliser SHA1 (et il est hors de question d’utiliser MD5), mais s’en séparer convient de faire une croix sur la compatibilité avec certains clients encore une fois. Pour continuer l’analogie entre ChaCha20 et AES, est-ce que Poly1305 est mieux que HMAC-SHA2 ? C’est différent, et c’est bien d’avoir le choix. Il y a certainement des subtilités qui feront pencher les cryptographes d’un côté plus que l’autre… De mon côté, je préfère même mettre ChaCha20+Poly1305 en tête de liste parce que je préfère Docteur Bernstein. Mais il ne faut pas basher AES non plus : bien qu’il ait vu le jour lors du concours NIST au début des années 2000, les critères autour de sa création sont rigoureusement transparents. Tout ce dont on peut être sûr c’est que la NSA par exemple a eu le temps de faire sa cryptanalyse.

Donc la configuration que je propose est la suivante :

ssl_ciphers EECDH+CHACHA20:EECDH+AESGCM;

Restrictive, certes. Mais il ne devrait pas y avoir de soucis avec des clients modernes. Chrome et Firefox supportent déjà ChaCha20+Poly1305. AES-GCM fera l’affaire pour Edge, Safari (jusqu’à la version incluse dans Yosemite, mais n’oubliez pas que Mavericks a le droit à des updates majeures de Safari par exemple), et Android jusqu’à KitKat.

Bonus si vous utilisez BoringSSL : vous pouvez définir des groupes de suites cryptographiques équivalentes. Au sein d’un même groupe, vous laissez le client choisir selon son ordre à lui. Cela peut-être utile si vous voulez utiliser AES sur votre PC, mais ChaCha20 sur votre smartphone ARM, par exemple. Le groupe est défini entre crochets [] et avec une barre verticale pipe | entre chaque ciphersuite, ça donnerait ceci :

ssl_ciphers [EECDH+CHACHA20|EECDH+AESGCM];

6. HTTP Strict Transport Security

HSTS est un mécanisme de sécurité qui consiste à indiquer par un header envoyé au client qu’il doit communiquer, pour un domaine donné, avec le serveur web par une connexion sécurisée HTTPS uniquement. L’intérêt est évident, car si HSTS est actif, le client est protégé de diverses attaques réseau et d’une MiTM. Mais je n’ai pas mis le précédent “si” en gras pour rien, en effet si HSTS n’a jamais été actif ou ne l’est plus, HSTS ne peut plus plus offrir cette sécurité. C’est pour cela qu’a été inventé le mécanisme de HSTS Preloading, qui consiste en des listes préchargées et intégrées aux navigateurs pour indiquer la politique HSTS utilisée pour un domaine ; en quelque sorte, HSTS est déjà actif avant même que vous n’ayez visité le site.

Pour utiliser HSTS, il faut utiliser :

Le header Strict-Transport-Security.
max-age : durée d’activité une fois actif (recommandé : 6 mois+)
includeSubDomains : protéger tous les sous-domaines.
preload : activer HSTS preloading.

De mon côté, je vais mettre max-age à 1 an soit 31536000 secondes. J’activerai HSTS preloading, et j’indiquerai de protéger tous les sous-domaines, soyez sûr que vous souhaitez faire de même :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Pour s’inscrire à la liste préchargée, il faut aller inscrire son domaine ici. La propagation peut prendre plusieurs semaines. Attention, HSTS Preload n’est pas là pour remplacer la redirection 301 vers HTTPS depuis HTTP.

7. OCSP Stapling et OCSP Must-Staple

OCSP Stapling est une alternative au protocole OCSP qui consiste à vérifier auprès de l’autorité de certification la validité du certificat. Avec OCSP, c’est le client lui-même qui fait cette démarche de vérification auprès du CA ; tandis qu’avec OCSP Stapling, c’est le serveur qui fait cette tâche et qui envoie la réponse OCSP au début de l’échange TLS. Bien que ce soit discuté d’un point de vue sécurité, les gains apportés par OCSP Stapling pour la vie privée sont non-négligeables, il est donc préférable de l’activer. Voyons comment cela se configure avec nginx, d’abord les paramètres OCSP Stapling à proprement parler :

ssl_stapling on;
ssl_stapling_verify on;
resolver 213.133.98.98 213.133.99.99 valid=300s;
resolver_timeout 5s;

Les deux premières lignes activeront OCSP Stapling. Mais il faut fournir un résolveur DNS à stapling pour qu’il puisse fonctionner. On peut fournir plusieurs IPs ou des FQDN pour pointer vers des résolveurs DNS, IPv4 et IPv6. Il faut également fournir à nginx le certificat de la chaîne Let’s Encrypt chain.pem dans chaque configuration :

ssl_trusted_certificate /path/to/chain.pem;

Une fois que c’est fait et nginx redémarré, vous pouvez tester vos paramètres OCSP Stapling sur Qualys SSL. Si OCSP Stapling s’affiche en vert avec Yes, c’est que logiquement ça fonctionne bien.

Quant à OCSP Must-Staple, imaginez tout simplement la même problématique qu’avec HSTS : au départ, le client n’a aucune idée si le serveur supporte HSTS, ou OCSP Stapling. OCSP Must-Staple est la solution pour OCSP Stapling qui a été proposée pour résoudre ce problème. C’est une extension à activer dans le certificat, qui indique au client qu’il doit être livré en même temps qu’une réponse OCSP du serveur, sinon c’est niet (donc vérifiez bien, et régulièrement, que vos paramètres fonctionnent…). Comment faire ? J’en ai déjà parlé plus haut, lors de la génération du certificat, quand vous modifiez custom.cnf dans la section [ v3_req ].

Si vous êtes sur OpenSSL 1.1.0 ou supérieur :

tlsfeature = status_request

Si vous êtes sur OpenSSL 1.0 et inférieur (moins sexy) :

1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05

Encore une fois vous pouvez vérifier que le flag est bien présent dans votre certificat après un petit tour sur Qualys SSL, ou en regardant les détails du certificat depuis votre navigateur.

Remarque : Firefox est ici le bon élève puisqu’apparemment il supporte bien OCSP Must-Staple. Cependant il se peut que dès le démarrage du serveur web et lors de la première tentative de connexion, Firefox vous colle une belle erreur OCSP : c’est normal. En fait, il faut que nginx remplisse son cache OCSP, et c’est ce que vous avez fait lors de la première connexion. Une idée toute bête pour contourner ce problème est de faire un script qui va faire la connexion. Vous pouvez même l’ajouter dans une entrée cron pour être sûr qu’il n’y ait aucun problème de ce genre sur le long terme.

Problème : le cache OCSP ne se remplit pas automatiquement lors du démarrage d’nginx et il a besoin de se remplir de temps en temps. “Oui, et ?” me diriez-vous. Le problème c’est que quand le cache doit se remplir sur demande d’un client, le client balancera une erreur. Si on rafraîchit la page, hop, l’erreur part. C’est donc une limitation de OCSP stapling que l’on peut contourner avec un script (merci @href pour la piste) à mettre en cron où $domain est le domaine concerné, voici un bout de code pour vous montrer :

/bin/echo "Q" | /usr/bin/openssl s_client -connect $domain:443 -status > /dev/null 2>&1

pm## 8. HTTP Public Key Pinning (HPKP) HPKP est un autre mécanisme de sécurité, basé sur un header HTTP, qui vise à faire mémoriser au client une liste sûre de clés. Si le CA est compromis et se met à faire de faux certificats pour votre domaine, HPKP s’il est bien configuré vous protégera d’une MiTM. Vu qu’on utilise Let’s Encrypt, et avec la méthode que je vous ai fournie pour gérer vos certificats, nous pouvons directement pin la clé publique du leaf certificate. Pourquoi ? Parce que comme je vous l’ai dit, on peut désormais utiliser nos propres clés privées donc on peut se passer de la régénération automatique de Let’s Encrypt qui rend l’usage de HPKP très délicat.

Prudence. Le problème avec HPKP, c’est qu’une fois actif chez le client, il le reste pendant la durée max-age fournie dans le header. Si par malheur la clé privée est compromise mais que vous avez pin un seul certificat, pardonnez-moi le terme, mais vous êtes littéralement baisé (et plus concrètement votre site sera inaccessible chez ceux qui auront l’ancienne version du header active chez eux). Voilà pourquoi il faut pin plusieurs clés :

Si la clé privée est compromise, on peut changer de clé.
Par mesure de bon sens, il faut parfois rouler les clés.
Si l’algo est pété, on peut changer sur une autré clé d’un autre type d’algo.

Concrètement, moi, ce que je vous recommande, c’est de générer 2 clés P-384 et une clé RSA 4096, et de faire le tutoriel pour créer le certificat ECDSA à partir d’une clé P-384 générée.

# Génération des 3 clés : 2x P-384, 1x RSA-4096
openssl ecparam -genkey -name secp384r1 > privkey_ec_1.pem
openssl ecparam -genkey -name secp384r1 > privkey_ec_2.pem
openssl genrsa -out privkey_rsa.pem 4096

# Configurez comme indiqué plus haut le custom.cnf
cp /etc/ssl/openssl.cnf custom.cnf

# Les 3 CSR à générer
openssl req -new -sha256 -key privkey_ec_1.pem -out csr_ec_1.der -config custom.cnf
openssl req -new -sha256 -key privkey_ec_2.pem -out csr_ec_2.der -config custom.cnf
openssl req -new -sha256 -key privkey_rsa.pem -out csr_rsa.der -config custom.cnf

# Récupérer les empreintes
openssl req -pubkey < csr_ec_1.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
openssl req -pubkey < csr_ec_2.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
openssl req -pubkey < csr_rsa.der | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

# Génération d'un certificat à partir de la première clé
letsencrypt certonly --standalone --agree-tos -m admin@domain.tld \
 --csr /path/to/csr_ec_1.der \
 --cert-path /path/to/cert.pem \
 --chain-path /path/to/chain.pem \
 --fullchain-path /path/to/fullchain.pem

Le header Public-Key-Pins est à renseigner avec les 3 empreintes obtenues et un max-age. Pour l’instant, et pour commencer, je le mettrais à 2 mois (de toute façon, Chrome limite la validité du header à 60 jours…) ; libre à vous de monter plus haut ensuite. Il est également possible d’appliquer HPKP à tous les sous-domaines une fois actif sur un domaine.

add_header Public-Key-Pins 'pin-sha256="empreinte_ec_1"; pin-sha256="empreinte ec_2"; pin-sha256="empreinte_rsa"; max-age=5184000; includeSubdomains';

Il va de soit que les clés ne doivent pas être idéalement sur la même machine, car si celle-ci est compromise, ce n’est pas une mais les trois clés privées que vous allez perdre. N’hésitez pas à rouler les clés, c’est-à-dire passer sur la deuxième clé privée puis en générer une nouvelle et l’ajouter à HPKP, en virant la première et en laissant la deuxième.

9. DANE, une alternative à HPKP ?

DANE pour DNS-based Authentication of Named Entities est un autre mécanisme sécurité, qui a la même finalité que HPKP mais qui repose sur des entrées DNS (des enregistrements TLSA). La condition pour son utilisation est l’activation de DNSSEC, sans quoi DANE n’a aucun intérêt. Je vais éviter la redite parce que mon ami Hardware a rédigé un billet sur le sujet, n’hésitez pas à le consulter.

Les entrées TLSA se présentent sous cette forme :

Pour extraire l’empreinte SHA-256 du fullchain.pem, voici comment :

openssl x509 -noout -in fullchain.pem -fingerprint -sha256 | cut -c 20- | sed s/://g | awk '{print tolower($0)}'

Puis il “suffit” d’ajouter une entrée TLSA dans votre zone DNS :

_443._tcp.domain.tld. IN TLSA 3 0 1 EMPREINTE
# À faire pour chaque sous-domaine.

Du coup si on met le fullchain.pem, il convient de mettre à jour l’entrée TLSA à chaque fois qu’on crée un nouveau certificat. Personnellement j’ai automatisé ça à coups de sed dans mon script de renouvellement, et ça marche bien.

Malheureusement DANE n’est pas présent dans la plupart des clients modernes (même pas Chrome et Firefox), c’est pour cela qu’il vaut mieux garder HPKP à côté. Pour tester si DANE fonctionne correctement, je vous recommande l’utilisation du plugin DNSSEC/TLSA Validator. Vous devriez voir cela :

10. Certificate Transparency

Certificate Transparency (CT) est en passe de devenir un standard. L’objectif derrière est de rendre public et transparent par les CAs toutes les informations autour de la génération d’un certificat. Ainsi, c’est une façon de lutter contre l’apparition de certificats frauduleux.

Lors de la création du certificat, le CA envoie des informations au log server qui répond avec un SCT (signed certificate timestamp). Ce SCT est soit intégré au certificat, soit présenté au travers d’autres moyens : une extension TLS, ou OCSP Stapling. Let’s Encrypt est déjà compatible avec certificate transparency, mais il ne présente pas encore de SCT (il est prévu que OCSP Stapling s’en occupe d’ici la fin d’année). Pour le moment on peut donc utiliser une extension TLS, il faudra compiler nginx avec le module nginx-ct. Il ne fonctionnera qu’avec une version d’OpenSSL assez récente.

Pour obtenir le SCT de fullchain.pem il nous faut utiliser ct-submit.

git clone https://github.com/grahamedgecombe/ct-submit --depth=1
cd ct-submit && go build
./ct-submit ct.googleapis.com/pilot <fullchain.pem>fullchain.sct
xxd fullchain.sct # Pour tester

00000000: 00a4 b909 90b4 1858 1487 bb13 a2cc 6770 .......X......gp
00000010: 0a3c 3598 04f9 1bdf b8e3 77cd 0ec8 0ddc .<5.......w.....
00000020: 1000 0001 4bc7 e617 c800 0004 0300 4830 ....K.........H0
00000030: 4602 2100 b9fe e206 f0f5 f600 93d5 e04c F.!............L
00000040: d2fd 75c9 e1fc a5c8 4812 a8b7 bc2c eb0c ..u.....H....,..
00000050: ee16 1fe9 0221 008a 5974 e1b6 a0e0 281a .....!..Yt....(.
00000060: 61e8 3447 895f 7ad4 2f70 f528 6133 a445 a.4G._z./p.(a3.E
00000070: 4fd4 ab60 ba36 db O..`.6.

Je vous suggère ici de créer un fichier ct_domain.tld.conf où l’on mettra les paramètres nginx pour servir le SCT.

ssl_ct on;
ssl_ct_static_scts /path/to/sct/dir;

Normalement nginx devrait servir les SCTs qui sont dans ce dossier. Si jamais ça ne marche pas, il est possible que ce soit dû à une limitation pour laquelle le serveur par défaut doit impérativement servir des SCTs (ajoutez default_server aux directives listen d’un vhost d’un domaine qui utilise CT). Pour vérifier si Certificate Transparency est opérationnel, Chrome et Qualys SSL feront l’affaire.

A ce fichier de configuration on peut aussi ajouter un header, Expect-CT. Il indique au browser que l’on attend l’utilisation de Certificate Transparency. Au jour d’aujourd’hui aucun browser ne l’utilise mais ce sera bientôt le cas. Surtout vérifiez bien que Certificate Transparency fonctionne et que les SCTs sont bien servis.

add_header Expect-CT "enforce; max-age=86400";

Dans ce cas-ci le browser devrait forcer l’utilisation de Certificate Transparency (erreur si pas possible) pendant un jour.

11. On récapitule ?

Et c’est après, je l’espère, vous avoir expliqué en quoi consistent les mécanismes utilisés, que je vais vous fournir les exemples de configuration. À chaque fois qu’il y a un domain.tld, c’est bien sûr à remplacer par votre domaine. Créons peut-être un dossier /etc/nginx/conf dans lequel on mettra des fichiers de configuration personnalisés, histoire d’éviter la redondance plus tard et de pouvoir maintenir plus facilement.

Créons un fichier tls.conf où l’on mettra les paramètres TLS :

ssl_protocols TLSv1.2;
ssl_ecdh_curve X25519:P-521:P-384;
ssl_ciphers EECDH+CHACHA20:EECDH+AESGCM;
ssl_prefer_server_ciphers on;

ssl_session_cache shared:SSL:20m;
ssl_session_timeout 15m;
ssl_session_tickets off;

On désactive les tickets TLS car leur mauvaise implémentation nuit au principe de confidentialité persistance (FS). Les autres directives modifient le cache alloué aux sessions et le timeout d’une session, elles sont à adapter selon les capacités de votre serveur et l’affluence des connexions.

Un fichier hsts.conf pour HSTS :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

Un fichier hpkp_domain.tld.conf pour HPKP d’un domaine :

add_header Public-Key-Pins 'pin-sha256="empreinte_ec_1"; pin-sha256="empreinte ec_2"; pin-sha256="empreinte_rsa"; max-age=5184000; includeSubdomains';

Un fichier ocsp.conf avec les paramètres OCSP :

ssl_stapling on;
ssl_stapling_verify on;
resolver 213.133.98.98 213.133.99.99 valid=300s;
resolver_timeout 5s;

Un fichier headers.conf qui peut être ajouté si l’application n’ajoute pas déjà ces headers :

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

Dans sites-enabled/, on aura notre fichier lambda.conf ainsi construit :

server {
 listen 80;
 listen [::]:80;
 server_name domain.tld;
 return 301 https://$host$request_uri;
}

server {
 listen 443 ssl http2;
 listen [::]:443 ssl http2;
 server_name domain.tld;

 ssl_certificate /path/to/fullchain.pem;
 ssl_certificate_key /path/to/privkey.pem;
 ssl_trusted_certificate /path/to/chain.pem;

 include /etc/nginx/conf/tls.conf;
 include /etc/nginx/conf/hsts.conf;
 include /etc/nginx/conf/headers.conf;
 include /etc/nginx/conf/ocsp.conf;
 include /etc/nginx/conf/hpkp_domain.tld.conf;
 #include /etc/nginx/conf/ct_domain.tld.conf;

 ...
}

N’oubliez pas de redémarrer nginx une fois les paramètres appliqués, sans oublier un nginx -t avant pour éviter les mauvaises surprises.

Les tests pour voir si vous avez tout bon :

Qualys SSL (SSL/TLS) : https://www.ssllabs.com/ssltest/
Cryptcheck (SSL/TLS): https://tls.imirhil.fr/ (v2 bientôt)
Observatoire Mozilla (SSL/TLS + headers) : https://observatory.mozilla.org
DNSSEC Analyzer (DNS) : https://dnssec-debugger.verisignlabs.com/
DANE Checker (DNS) : https://www.huque.com/bin/danecheck
Si vous en avez d’autres, proposez !

Ce n’est pas difficile, et je ne pense pas avoir menti sur la marchandise, il s’agit d’une excellente configuration HTTPS, peut-être même un peu trop extrémiste. Si la compatibilité est un trop gros problème, appliquez les conseils que j’ai disséminés le long de l’article.

Article rédigé par Wonderfall, vous pouvez le suivre sur Mastodon ou Twitter

Installer Plesk Onyx sur Ubuntu 16.04 LTS et optimiser la configuration

Fri, 15 Sep 2017 18:53:00 +0000

Si pour mon utilisation personnelle, je préfère configurer moi même un serveur avec nginx pour bénéficier des meilleures performances possibles, il m’arrive tout de même régulièrement d’installer Plesk Onyx.

Voici donc un tutoriel pour installer Plesk Onyx sur Ubuntu 16.04 LTS avec une configuration optimisée permettant d’avoir un serveur stable, sécurisé et performant.

On commence par optimiser un peu la configuration du kernel via le fichier sysctl.conf :

wget -O /etc/sysctl.conf https://raw.githubusercontent.com/VirtuBox/ubuntu-nginx-web-server/master/etc/sysctl.conf
sysctl -p
echo never > /sys/kernel/mm/transparent_hugepage/enabled
wget -O /etc/security/limits.conf https://raw.githubusercontent.com/VirtuBox/ubuntu-nginx-web-server/master/etc/security/limits.conf

Par défaut, Plesk Onyx utilise MySQL 5.7 sur Ubuntu Xenial, mais il est tout à fait possible d’utiliser MariaDB 10.1. Il suffit pour cela d’installer mariadb-server avant de débuter l’installation de Plesk.

On ajoute donc le dépôt MariaDB 10.1 :

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup |
 sudo bash -s -- --mariadb-server-version=10.1 --skip-maxscale

Puis on met à jour la liste des dépôts avant d’installer MariaDB. Durant l’installation, laissez le mot de passe root vide. Il sera automatiquement mis à jour durant l’installation de Plesk.

sudo apt update
sudo apt install mariadb-server

MariaDB 10.1 est désormais installé sur notre serveur, nous pouvons donc passer à l’installation de Plesk en mode personnalisé. Il vous suffit de suivre les étapes pour choisir les composants et les extensions que vous souhaitez installer :

sh <(curl https://autoinstall.plesk.com/plesk-installer || wget -O - https://autoinstall.plesk.com/plesk-installer)

Une fois l’installation terminée, n’ouvrez pas tout de suite l’interface web pour réaliser la configuration initiale. Nous allons tout d’abord activer le mode vps_optimized. Ce dernier désactive un bon nombre de modules apache, qui ne sont pas nécessaires sur un VPS.

plesk bin vps_optimized --turn-on

Vous pouvez enfin définir le langage par défaut via la CLI de Plesk :

plesk bin locales --set-default fr-FR

Pour sécuriser notre serveur, nous allons également activer l’option pci_compliance, cela va configurer les différents services pour rendre le serveur pci compliant.

plesk sbin pci_compliance_resolver --enable all

Si comme moi, vous pensez qu’une clé d’échange Diffie-Hellman de 2048 bits est insuffisant, vous pouvez sans problème utiliser une clé ECC.

Il vous suffira ensuite de modifier la configuration SSL de Nginx, avec une meilleure suite de ciphers, et notre clé Diffie-Hellman :

nano /etc/nginx/conf.d/ssl

Voici le contenu de mon fichier de configuration SSL pour Nginx :

ssl_ciphers 'EECDH+AESGCM:EECDH+CHACHA20';
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2;
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 15m;
ssl_session_tickets off;

Il vous suffit ensuite de reload nginx pour appliquer les changement :

nginx -t && service nginx reload

Après avoir optimiser la configuration Nginx, nous pouvons passer à Apache. Pour cette partie, je me contente de modifier le fichier /etc/apache2/conf-enabled/security.conf et d’y ajouter les headers suivants :

Header set X-Content-Type-Options: "nosniff"
Header set X-Frame-Options: "sameorigin"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set x-xss-protection "1; mode=block"

On relance Apache via la commande service apache2 restart

Vous pouvez désormais vous connecter à l’interface Plesk via l’adresse affichée après l’installation. Vous pouvez à tout moment générer une autre adresse de connexion avec la commande plesk login.

Si vous souhaitez modifier la configuration générale de Plesk, cela est faisable en utilisant l’extension Panel.ini editor, ou en modifiant directement le fichier /usr/local/psa/admin/conf/panel.ini. L’extension vous permet de définir depuis l’interface web vos propre variables pour les options Plesk, ainsi que pour les extensions. Par exemple, pour que l’extension let’s encrypt utilise des clés RSA de 4096 bits plutôt que de 2048 bits, il vous suffit d’ajouter au fichier panel.ini (via le fichier ou via l’extension dans la partie editor), les lignes suivantes :

[ext-letsencrypt]
renew-before-expiration = 45
rsa-key-size = 4096

Vous pouvez également désactivé les publicités pour certaines extensions, et les propositions de certificats SSL Symantec en ajoutant les lignes suivantes :

[ext-security-advisor]
promoteSymantec = false

[ext-catalog]
contextAds = off

Vous pouvez appliquer ces configurations en téléchargeant directement mon ficher panel.ini

wget https://raw.githubusercontent.com/VirtuBox/ubuntu-plesk-onyx/master/usr/local/psa/admin/conf/panel.ini -O /usr/local/psa/admin/conf/panel.ini

Il est même possible d’aller plus loin avec Plesk Onyx, puisque vous pouvez compiler Nginx avec les modules de votre choix afin de remplacer le paquet installé par Plesk.

Edit du 11/12/2017 :

Je propose désormais un script bash pour compiler la dernière release mainline de Nginx (v1.13.8) avec certains modules tel que Brotli, support de TLS 1.3, dynamic-tls-records-patch, pagespeed etc …

Le script est pour le moment mis à jour uniquement pour Plesk Onyx sur Ubuntu 16.04 LTS, vous pouvez trouver toutes les informations sur mon dépôt Github.

N’hésitez pas à ouvrir une Issue sur Github si vous rencontrez des erreurs durant la compilation.

Mettre en place un serveur mail avec mail-in-a-box sur Ubuntu 18.04 LTS

Sat, 08 Jul 2017 14:07:30 +0000

Il n’est pas toujours facile de mettre en place un serveur mail, notamment si lorsque l’on souhaite utiliser l’ensemble des protocoles qui assurent l’authentification des emails tel que SPF, DKIM et DMARC. C’est pourquoi je vais vous présenter dans ce tutoriel une solution pour installer un serveur mail sécurisé et stable avec mail-in-a-box.

Article mis à jour le 29/07/2019

Pourquoi mail-in-a-box ?

J’ai testé de nombreuses autres solutions dont notamment Modoboa, Mailcow ou encore iRedMail, et mail-in-a-box est d’après moi la solution la plus simple à déployer, elle propose l’ensemble des fonctionnalités requises pour avoir un serveur mail stable, sécurisé et dispose d’un système de backup.

Les principales fonctionnalités sont :

Serveur Mail supportant les protocoles : SPF, DKIM & DMARC
Serveur DNS avec DNSSEC
Certificats SSL/TLS Let’s Encrypt
Webmail Roundcube
Gestion et synchronisation des contacts & calendrier via OwnCloud
Backup local, Amazon S3 ou via Rsync
Statud check hebdomadaire incluant le blacklisting de l’IP du serveur

Installer mail-in-a-box

Pré-requis :

– Un VPS avec Ubuntu 18.04 LTS et 2Go de RAM – Un nom de domaine – Se connecter au serveur distant avec des clés SSH

On passe à l’installation :

curl -s https://mailinabox.email/setup.sh | sudo bash

Lors de l’installation, choisissez le hostname de votre serveur en utilisant un sous-domaine. Par défaut mail-in-a-box utilisera box.votredomaine.com

Définissez ensuite la première adresse email que vous souhaitez créer, ce sera également votre nom d’utilisateur pour accéder à l’interface d’administration

Sélectionnez votre zone géographique pour mettre à jour le serveur de temps puis validez.

Sélectionnez ensuite la ville correspondant à votre fuseau horaire, dans mon cas Paris.

Une fois l’installation terminée, vous pourrez accéder au panel d’administration via l’adresse : https://IP-de-Votre-Serveur/admin

Configurer le serveur mail

Vous avez ensuite le choix d’utiliser la box pour gérer vos DNS ou non. En effet Mail-in-a-box inclut un serveur DNS qui mettra en place automatiquement l’ensemble des enregistrements DNS nécessaires pour utiliser le serveur en tant que serveur mail pour votre domaine.

Cependant, vous pouvez très bien utiliser un service DNS externe et il vous suffira dans ce cas de vous rendre sur la page System > External DNS pour obtenir un listing complet des enregistrements DNS. Il vous faudra alors copier ces enregistrements du côté de votre registar pour utiliser la box en tant que serveur mail.

Les enregistrements nécessaires pour utiliser la box en tant que serveur mail sont :

votredomaine.com MX(10) "box.votredomaine.com" : pour définir la box en tant que serveur mail principal

votredomaine.com TXT "v=spf1 a:box.votredomaine.com -all" : pour spécifier que la box est le seul serveur autorisé à envoyer des emails pour ce domaine

_dmarc.votredomaine.com TXT "v=DMARC1; p=quarantine" : pour indiquer que les emails ne respectant pas les règles DKIM ou SPF doivent être envoyé en quarantaine.

mail._domainkey.votredomaine.com TXT "v=DKIM1; k=rsa; s=email; p=la-signature-très-longue-pour-le-dkim" : qui correspond à la signature DKIM utilisée pour signer les emails sortant de votre serveur.

Mail-in-a-box ajoute également les enregistrements associés au sous domaine www pour éviter que des emails soient envoyés via www.votredomaine.tld. Ils sont facultatifs mais cela ne coûte rien de les mettre en place.

Une fois les enregistrements DNS configurés pour le domaine de votre box, vous pourrez aller dans l’onglet System TLS (SSL) Certificates, et installer un certificat SSL Let’s Encrypt pour sécuriser votre serveur web et mail.

Une fois le processus terminé, vous pourrez accéder à l’interface d’administration via l’adresse : https://box.votredomaine.com/admin

N’oubliez pas également de définir le reverse-DNS sur l’IP du serveur. Cela se fait via le panel de gestion de votre VPS et nécessite que l’enregistrement DNS associé soit existant. Dans cet exemple, le reverse DNS à spécifié sur l’IP du serveur est box.vtbox.xyz

Connecter un client mail

Pour connecter vos clients mail, l’adresse pour les services pop/imap et smtp sera box.votredomaine.com. Les ports à utiliser pour se connecter avec SSL/TLS sont :

IMAP : 993 avec SSL/TLS

POP : 995 avec SSL/TLS

SMTP : 587 avec TLS

Ajouter un domaine

Pour ajouter un domaine, il vous suffit d’aller dans l’onglet Mail > Users et d’ajouter une adresse email utilisant un autre domaine que celui de votre box.

Mail-in-a-box mettra automatiquement en place les enregistrements DNS associés et vous n’aurez alors qu’à modifier les nameservers du nouveau domaine, ou les retrouver dans l’onglet External DNS si vous souhaitez les copier via votre registar.

Mettre à jour mail-in-a-box

Pour la mise à jour de votre serveur mail, rien de plus simple, puisqu’il vous suffit d’utiliser à nouveau la commande d’installation :

curl -s https://mailinabox.email/setup.sh | sudo bash

Backup & Migration

Le processus de backup de mail-in-a-box est relativement simple, puisque par défaut les backups sont stockés dans le répertoire /home/user-data/backup. Dans ce répertoire, vous trouverez un fichier secret_key.txt qui contient la clé privée utilisée pour chiffrer les sauvegardes stockées dans le répertoire encrypted.

Pour migrer ou restaurer un serveur depuis un sauvegarde, il vous suffit de réinstaller mail-in-a-box sur un serveur, avant de transférer le dernier backup dont vous disposez ainsi que la clé privée.

Vous pourrez ensuite restaurer les données en utilisant l’outil duplicity :

export PASSPHRASE=$(cat your_backup_secret_key_file.txt)
sudo -E duplicity restore --force file:///emplacement/des/backup /home/user-data/

Il suffira ensuite d’utiliser la commande mailinabox pour appliquer à nouveau la configuration du serveur :

sudo mailinabox

Installer et configurer proftpd en serveur FTP avec TLS

Sun, 16 Apr 2017 17:20:02 +0000

Si vous utilisez comme moi EasyEngine/WordOps sur votre serveur, vous souhaitez peut-être proposer un accès via ftp, tout en limitant l’accès aux fichiers d’un site web pour chaque utilisateur.

Pour cela, nous allons installer et configurer proftpd afin que chaque utilisateur ne puisse accéder qu’à son répertoire, sans causer de problèmes de permissions sur les fichiers d’un site. Enfin nous mettrons en place un certificat SSL pour chiffrer les échanges avec le serveur distant.

Installation de profpd

On commence par installer proftpd :

apt-get update && apt-get install proftpd

Puis on modifie la configuration de proftpd :

nano /etc/proftpd/proftpd.conf

Pour empêcher les utilisateurs de remonter dans l’arboresence des fichiers du serveur, il faut de décommenter la ligne suivante en supprimant le # :

DefaultRoot ~

Il est également préférable décommenter l’option RequireValidShell afin de pouvoir ajouter des utilisateurs sans accès ssh :

RequireValidShell off

Enfin, si vous utilisez un pare-feu sur votre serveur, il est nécessaire de décommenter la ligne PassivePorts en définissant une intervalle de ports. Dans mon exemple, j’ai choisi d’utiliser les ports 49000 à 50000 pour les connexions FTP passives :

PassivePorts 49000 50000

Il suffit ensuite d’autoriser ces ports dans votre pare-feu. Si vous utilisez UFW, il suffit d’utiliser la commande :

ufw allow 49000:50000/tcp

On redémarre ensuite proftpd pour appliquer les modifications :

service proftpd restart

Ajouter un utilisateur

Pour ajouter un utilisateur, il faut définir son dossier home qui correspond au dossier du site web concerné, et l’ajouter au groupe www-data pour qu’il n’y ai pas de problème au niveau des permissions. Remplacez dans la commande suivante le dossier utilisé après –home et le nom de l’utilisateur :

adduser --home /var/www/votredomaine.tld/ --shell /bin/false --ingroup www-data votre-utilisateur

La commande précédente inclut la directive –shell /bin/false, interdisant ainsi l’accès au shell pour le nouvel utilisateur puisque nous avons précédemment définit que l’utilisation du serveur FTP ne nécessitait pas un accès valide au shell.

Enfin pour ajouter les permissions au groupe sur un dossier on utilise :

chmod -R g+rw /var/www/domainname

Votre utilisateur pourra ainsi ajouter ou supprimer des fichiers en se connectant via un client ftp, mais il ne pourra pas accéder à d’autres fichiers que ceux présents dans son répertoire –home et il ne pourra pas se connecter au serveur en SSH.

Configuration TLS

Pour les transferts de fichiers sur internet, le chiffrement, c’est mieux avec. Nous allons donc voir comment configurer proftpd pour en faire un serveur FTPS.

Avec un certificat auto-signé

Un certificat auto-signé n’apparaîtra peut-être pas comme valide, mais vous permettra de bénéficier du chiffrement autant qu’un certificat issue d’une authorité de certificats.

On commence par créer un répertoire pour stocker notre certificat :

mkdir /etc/proftpd/ssl

Puis on génère à l’aide d’OpenSSL notre certificat :

openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem

Voici le déroulement de la procédure :

root@vps~# openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem
Generating a 2048 bit RSA private key
.................+++
..............+++
writing new private key to '/etc/proftpd/ssl/proftpd.key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:-
Locality Name (eg, city) []: Paris
Organization Name (eg, company) [Internet Widgits Pty Ltd]: VirtuBox
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN or YOUR name) []:server.virtubox.net
Email Address []:admin@virtubox.net

On s’assure ensuite de définir des permissions correctes sur le certificat et la clé privée :

chmod 600 /etc/proftpd/ssl/proftpd.*

Et on peut alors éditer le fichier /etc/proftpd/tls.conf dont le contenu devra ressembler à :

TLSEngine on
TLSLog /var/log/proftpd/tls.log
TLSProtocol TLSv1.2
TLSCipherSuite AES128+EECDH:AES128+EDH
TLSOptions NoCertRequest AllowClientRenegotiations NoSessionReuseRequired
TLSRSACertificateFile /etc/proftpd/ssl/proftpd.cert.pem
TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key.pem
TLSVerifyClient off
TLSRequired on
RequireValidShell no
</IfModule>

Une fois les modifications enregistrées, il vous suffit de décommenter la ligne

Include /etc/proftpd/tls.conf

dans le fichier /etc/proftpd/protftpd.conf

Vous pouvez ensuite relancer le service proftpd pour appliqer la nouvelle configuration.

sudo service proftpd restart

Installer votre résolveur DNS avec unbound

Thu, 06 Apr 2017 13:23:11 +0000

Pourquoi mettre en place un résolveur DNS ?

Avec une généralisation de la censure et de nombreuses pannes sur les résolveurs DNS des FAI, beaucoup d’articles recommandent l’utilisation des résolveurs DNS Google. Mais si ce dernier propose un service stable et performant, il peut être inquiétant de laisser google analyser l’ensemble des requêtes DNS que vous pouvez faire en naviguant sur le web.

Dans ce tutoriel, je vais donc vous expliquer comment mettre en place un résolveur DNS récursif, supportant la norme DNSSEC avec unbound. Pour l’installation, j’ai utilisé un VPS avec Ubuntu 16.04 LTS.

Installer et configurer unbound

Tout d’abord, il faut installer unbound :

apt update
apt install unbound

Après quoi, il faut créer un fichier de configuration dans le dossier /etc/unbound/unboud.conf.d/ que vous pouvez nommer mondns.conf par exemple. Voici le contenu de ce fichier :

server:
 interface: 0.0.0.0
 interface: ::0
 access-control: 0.0.0.0/0 allow
 access-control: ::/0 allow
 root-hints: "/var/lib/unbound/root.hints"
 verbosity: 0
 qname-minimisation: yes

 num-threads: 2
 msg-cache-slabs: 4
 rrset-cache-slabs: 4
 infra-cache-slabs: 4
 key-cache-slabs: 4
 rrset-cache-size: 100m
 msg-cache-size: 50m
 outgoing-range: 465
 so-rcvbuf: 4m
 so-sndbuf: 4m
 port: 53
 do-ip4: yes
 do-ip6: yes
 do-udp: yes
 do-tcp: yes
 do-daemonize: yes
 hide-identity: yes
 hide-version: yes
 harden-glue: yes
 harden-dnssec-stripped: yes
 harden-referral-path: yes
 use-caps-for-id: yes
 prefetch: yes

Attention, l’option *qname-minimisation: yes *ne fonctionne que sur Ubuntu car unbound 1.5.7 n’est pas disponible sur le repository debian.

On télécharge ensuite le fichier contenant les IPs des 13 serveurs de la racine.

wget https://www.internic.net/domain/named.cache -O /var/lib/unbound/root.hints

Il ne nous reste plus qu’à redémarrer le service unbound :

service unbound restart

Et votre résolveur DNS est désormais opérationnel ! (vérifiez que le service unbound fonctionne correctement avec la commande service unbound status) Vous pouvez maintenant éditer le fichier /etc/resolv.conf pour remplacer l’IP du nameserver utilisé par 127.0.0.1.

Ensuite, si vous souhaitez automatiser la mise à jour des serveurs de la racine, vous pouvez le faire en ajoutant un cron avec le script suivant :

wget https://git.virtubox.net/virtubox/unbound-dns-server/raw/master/update-root-dns.sh

chmod +x update-root-dns.sh

crontab -e

0 0 * * * ./update-root-dns.sh

Résolveur DNS Public Ouverts de VirtuBox

Si vous n’avez pas l’envie ou la patience de mettre en place votre propre résolveur DNS, vous pouvez utiliser ceux mis à disposition par VirtuBox :

Nom : **dns.vtbox.net **

IPv4 : 163.172.189.181
IPv6 : 2001:bc8:4400:2100::25:5

Nom : sdns.vtbox.net

IPv4 : 217.182.205.213
IPv6 : 2001:41d0:302:2100::7a77

Les deux résolveurs utilisent la même configuration que ci-dessus, avec l’ajout de trois lignes afin d’avoir les statistiques d’utilisation :

statistics-interval: 0
extended-statistics: yes
statistics-cumulative: yes

Si vous souhaitez aller encore plus loin, vous pouvez également mettre en place un résolveur DNSCrypt qui permet de chiffrer les requêtes faites entre votre machine et le résolveur DNS.

Je vous invite à jeter un coup d’œil sur le tutoriel de noobunbox.

Tutoriel inspiré de l’article de shaftinc.fr.