Cette page contient un certain nombre de préconisations liées à la sécurisation d'un IdP. Elles n'ont pas la prétention d'être exhaustives: elles ne couvrent que le durcissement initial, et pas d'autres aspects tout aussi important, comme les mises à jour par exemple. Et elles n'ont pas de valeur de vérité: elles doivent être relativisées et adaptées par rapport à votre contexte, notamment si vous utilisez un autre serveur web ou serveur d'application Java.

TODO

L'installation de Tomcat depuis les sources upstream entraine par effet de bord l'installation d'un certain nombre d'applications annexes.

Les applications d'exemples peuvent être utilisées comme application témoin sur une machine de développement, mais elles n'ont aucun intérêt en production, où elles constituent même un risque potentiel.

L'interface d'administration graphique (web manager) constitue elle un risque avéré, puisqu'il s'agit d'un outil d'administration. Le seul cas dans lequel cette application est vraiment nécessaire est celui d'une externalisation des fonctions d'administration applicative à des utilisateurs ne disposant pas de comptes shell privilégiés sur la machine hébergeant Tomcat. Dans tous les autres cas, il s'agit juste d'une solution de confort, qui doit être mis en balance avec le risque associé.

La solution la plus simple consiste à supprimer les applications en question du système de fichier:

$> sudo rm -rf /opt/tomcat/webapps/*

L'utilisation d'un compte applicatif dédié pour exécuter Tomcat, plutôt que le compte super-utilisateur (root), n'est qu'une première étape de durcissement. En effet, donner à cet utilisateur la propriété de l'ensemble des fichiers du serveur d'application et du fournisseur d'identité est une méthode laxiste, conférant à ce compte utilisateur plus de droits que nécessaires, et en particulier des droits en écriture, permettant potentiellement à un attaquant de prendre le contrôle de l'application en modifiant sa configuration à la volée.

Pour une utilisation en production, il est recommandé de limiter ces privilèges aux seuls réellement nécessaires, à savoir:

• lecture seule par défaut sur l'ensemble des fichiers et répertoires
• lecture/écriture sur les répertoires suivant de Tomcat: webapps, work, temp, et logs
• lecture/écriture sur les répertoires suivant de l'IdP Shibboleth: metadata, et logs

Afin d'arrive à un compromis raisonnable entre sécurité et facilité d'exploitation, nous allons procéder en 3 temps:

• donner la propriété de l'ensemble des répertoires et fichier à l'utilisateur root, puis élargir les accès en lecture à l'ensemble des utilisateurs du système
• donner la propriété des répertoires nécessitant un accès en écriture à l'utilisateur tomcat
• donner la propriété des fichiers contenant des éléments sensibles au groupe tomcat, avec suppression des droits en lecture pour tous

Pour Tomcat:

$> sudo chown -R root.root /opt/apache-tomcat-9.x.x
$> sudo chmod -R go=u-w /opt/apache-tomcat-9.x.x
$> sudo chown -R tomcat.tomcat /opt/apache-tomcat-9.x.x/webapps
$> sudo chown -R tomcat.tomcat /opt/apache-tomcat-9.x.x/work
$> sudo chown -R tomcat.tomcat /opt/apache-tomcat-9.x.x/temp
$> sudo chown -R tomcat.tomcat /opt/apache-tomcat-9.x.x/logs

Pour l'IdP Shibboleth:

$> sudo chown -R root.root /opt/shibboleth-idp
$> sudo chmod -R go=u-w /opt/shibboleth-idp/
$> sudo chown -R tomcat.tomcat /opt/shibboleth-idp/metadata
$> sudo chown -R tomcat.tomcat /opt/shibboleth-idp/logs
$> sudo chmod u=rw,g=r,o= /opt/shibboleth-idp/credentials/*
$> sudo chgrp tomcat /opt/shibboleth-idp/credentials/*

Documentation :

• Secret Key Management, consortium Shibboleth

L'IdP Shibboleth utilise une clé AES pour sécuriser les cookies de session et certaines autres données de l'IdP. Cette clé est stockée dans un fichier dédié, /opt/shibboleth-idp/credentials/sealer.jks, un keystore Java.

Il est possible de protéger cette clé en utilisant un premier mot de passe pour protéger l'accès au keystore, et un second mot de passe pour protéger la clé elle-même. Néanmoins, ces deux mots de passe devant être indiqués en clair dans la configuration de l'IdP, la pertinence de l'utilisation de ces mots de passe est discutable. Surtout lorsque d'autres secrets similaires, comme par exemple les clés associées aux certificats de signature et de chiffrement, ne sont pas protégés de la même façon.

En revanche, il est relativement simple et peu couteux de renouveler régulièrement cette clé, par exemple en exécutant le script suivant par le biais d'une tache cron:

/opt/shibboleth-idp/credentials/rotate-sealer.sh

#!/bin/bash
 
## Renouvellement de la clé AES de l'IdP Shibboleth
IDP_HOME=IDP_ROOT_DIR
export JAVA_HOME=/usr/java/latest/
 
$IDP_HOME/bin/seckeygen.sh \
    --storefile $IDP_HOME/credentials/sealer.jks \
    --versionfile $IDP_HOME/credentials/sealer.kver \
    --alias secret \
    --storepass "$(grep '^idp.sealer.storePassword' $IDP_HOME/conf/idp.properties | cut -d = -f 2)"

$> sudo chmod a+x /opt/shibboleth-idp/credentials/rotate-sealer.sh

Programmez l'exécution quotidienne de ce script depuis la crontab :

/etc/crontab

13 3 * * * tomcat IDP_ROOT_DIR/credentials/rotate-sealer.sh

Vous pouvez constater qu'une nouvelle clé a été ajoutée au keystore :

$> keytool -list -keystore /opt/shibboleth-idp/credentials/sealer.jks -storetype jceks
Enter keystore password:  

Keystore type: JCEKS
Keystore provider: SunJCE

Your keystore contains 3 entries

secret3, Jun 19, 2015, SecretKeyEntry, 
secret2, Jun 19, 2015, SecretKeyEntry, 
secret1, May 18, 2015, SecretKeyEntry,