Lorsque l’on installe un service ayant une interface web, le réflexe à avoir est le suivant :

Installer des certificats signés par une CA pour sécuriser la connexion en HTTPS.

Réflexe des arsouyes

C’est peut être too much dans notre cas vu que nous n’avons que 4 utilisateurs dans le SI, dont deux connaissent le mot de passe et deux sont trop jeunes pour sniffer le réseau… Mais comme dans toutes les situations, les choses changent… Sans voir le temps passer, l’ainée aura 16 ans et s’amusera (peut être) avec le réseau (à moins qu’elle l’ait déjà fait bien avant).

On a un problème

Pour utiliser SSL avec duplicati, d’après la documentation officielle, il faut lancer le serveur avec l’option --webservice-sslcertificatefile=, suivit du chemin vers un certificat au format PKCS12.

Dans l’idée, c’est donc très facile de passer votre interface en HTTPs. Sauf que les choses ne sont jamais aussi simple. Si vous essayez sous Linux, cela ne marchera pas.

En investiguant le problème, on se rends compte que duplicati est codé en .NET. Et que sous Linux, .Net est géré par Mono qui est une implémentation OpenSource de la machine virtuelle .NET. Mono a des problèmes avec la gestion des certificats au format PKCS12 (cf. ici ou encore là).

On ne peut donc pas utiliser cette option de configuration, et on doit contourner le problème en installant un apache devant duplicati.

Préparer duplicati

Si vous avez suivi notre article sur l’installation de duplicati, vous avez surement changé le numéro de port pour y accéder et ouvert l’accès à toutes les IP. Si ce n’est pas le cas, vérifiez quand même les points suivants dans le fichier /etc/default/duplicati, pour être sûr qu’il soit configurés de la manière suivante:

• --webservice-interface=127.0.0.1: restreint l’accès à l’interface à 127.0.0.1.
• --webservice-port=8200 : permet d’accéder à l’interface en utilisant le port 8200.

Relancez duplicati.

sudo service duplicati restart

Vous ne pourrez pour le moment plus y accéder, sauf depuis la machine elle-même.

Apache

Nous allons maintenant utiliser apache en tant que mandataire inverse afin qu’il se mette entre duplicati et nous, les administrateurs. C’est apache qui gèrera alors la partie HTTPs avant de transférer nos requêtes à duplicati (en clair, mais en local à la machine).

Déploiement du certificat et de la clef

Partons du principe que vous avez déjà votre PKI et que vous avez déjà votre certificat et votre clef. Vous disposez donc des fichiers suivant :

• duplicati.crt pour le certificat
• duplicati.key pour la clef.

On téléverse ces fichiers sur le serveur. L’habitude veut que les répertoires suivants soient utilisés :

• /etc/ssl/certs/ pour les certificats,
• /etc/ssl/private/ pour les clés.

On met ensuite les bons droits sur les fichiers, histoire que les fichiers appartiennent à root, et que le fichier clef n’ait que des droits en écriture.

sudo chown root:root /etc/ssl/certs/duplicati.crt
sudo chown root:root /etc/ssl/private/duplicati.key
sudo chmod 400 /etc/ssl/private/duplicati.key

Si vous avez comme nous installé duplicati en tant que service, ces droits seront suffisants.

Installation et activation des modules

On va ensuite intaller apache en ligne de commande .

sudo apt-get install apache2

Puis on active tous les modules qui nous seront nécessaires :

• proxy : fournit les fonctionnalités de base d’un mandataire,
• proxy_http : support du mandatement des requêtes HTTP et HTTPS,
• headers : permet de contrôler les en-têtes HTTP,
• proxy_wsttunnel : fournit le support du tunneling pour les websocket,
• ssl : fournit le support SSL v3 et TLS v1,
• rewrite : permet de réécrire les URL des requêtes à la volée.

Mandatement : Action de mandater. Terme utilisé dans la documentation officielle d’Apache en français.

sudo a2enmod proxy proxy_http headers proxy_wstunnel ssl rewrite

HTTPs

Pour configurer un hôte virtuel, qui va juste faire passe-plat entre le reste du monde et duplicati en ajoutant du HTTPs au passage, on crée un nouveau fichier, dans /etc/apache2/sites-available/, nommé duplicati.conf , avec les directives pour la gestion du SSL d’un côté, et celles pour le reverse proxy de l’autre.

<VirtualHost *:443>
    ServerName lynx.arsouyes.org

    # Directives pour SSL avec les administrateurs
    SSLEngine on
    SSLCertificateFile    "/etc/ssl/certs/duplicati.crt"
    SSLCertificateKeyFile "/etc/ssl/private/duplicati.key"

    # Directives pour le reverse proxy
    ProxyPreserveHost On
    ProxyRequests off
    ProxyPass / http://127.0.0.1:8200/
    ProxyPassReverse / http://127.0.0.1:8200/

    AllowEncodedSlashes On

</VirtualHost>

Les slashs encodés dans les URL sont refusés par Apache. Or duplicati les utilise lors de la récupération de fichiers. Le serveur Apache en coupure empêche donc la bonne transmission de la requête à duplicati. Pour le forcer Apache à transmettre la requête telle que demandée,, il est nécessaire de mettre AllowEncodedSlashes à On.

Maintenant que le fichier de configuration est créé, on va activer le site:

sudo a2ensite duplicati.conf

Puis relancer apache avec sa nouvelle configuration.

sudo systemctl reload apache2

Redirection de HTTP vers HTTPs

De base, apache installe un site de tests dans /etc/apache2/site-available/000-default.conf. On va supprimer tout ce qui est configuré pour cet hôte, et se contenter d’une redirection.

<VirtualHost *:80>
    ServerName lynx.arsouyes.org
    Redirect permanent / https://lynx.arsouyes.org
</VirtualHost>

On relance une dernière fois la configuration.

sudo systemctl reload apache2

Et après

Vous pouvez dorénavant accéder à l’interface en HTTPs. Grâce à Apache en coupure entre duplicati (en local) et le reste du SI, il n’est plus possible de sniffer le réseau et de récupérer le mot de passe.

Il existe bien d’autres modules utiles de apache que l’on pourrait envisager maintenant de restreindre l’accès, non plus par un simple mot de passe, mais aux utilisateurs d’un annuaire LDAP ou d’un domaine, via le module authnz_ldap .