Cet article décrit la mise en place d’un hébergement sécurisé sur un serveur Apache tournant sous CentOS 7. Le protocole HTTP (Hypertext Transfer Protocol) transmet les données entre le serveur et le navigateur « en clair ». Les données personnelles, mots de passe et autres numéros de Carte Bleue sont donc interceptables. Pour résoudre ce problème, on utilisera le protocole HTTPS, qui ajoute une couche de cryptage SSL (Secure Sockets Layer) au protocole HTTP.
Le transfert crypté des données ne constitue qu’un aspect dans l’établissement d’une connexion sécurisé. L’autre aspect tout aussi important, c’est que l’utilisateur doit être sûr de communiquer avec la bonne personne. Autrement dit, votre numéro de Carte Bleue a beau être transmis de façon sécurisée, encore faut-il que la plateforme de paiement ne soit pas située sur un serveur géré par la mafia albanaise.
Pour savoir si l’on a bien affaire au bon interlocuteur, on utilisera un certificat. Cette véritable carte d’identité électronique contient non seulement la clé publique du serveur pour crypter les transmissions, mais également des renseignements sur le site ainsi que la signature de l’autorité de certification.
La génération d’un certificat électronique fait l’objet d’un article à part. Pour nos essais, nous utiliserons un certificat SSL/TLS fourni par le client Certbot. Si l’on décide de partir sur un certificat auto-signé, la configuration devra être adaptée en conséquence.
Dans l’exemple ci-dessous, nous allons configurer un hébergement public https://www.slackbox.fr.
- Prérequis
- Installation
- Configurer Apache et SSL
- Améliorer la sécurité de notre hébergement
- La politique HSTS
- Héberger plusieurs sites sécurisés
Prérequis
Le protocole HTTPS utilise le port 443. Il faut donc songer avant toute chose à ouvrir ce port dans le pare-feu.
Installation
Le chiffrement SSL/TLS pour Apache est fourni par le paquet mod_ssl.
# yum install mod_ssl
On notera l’apparition d’un fichier de configuration ssl.conf dans /etc/httpd/conf.d.
Configurer Apache et SSL
Avant de continuer, effectuer une copie de sauvegarde du fichier de configuration par défaut.
# cd /etc/httpd/conf.d # cp ssl.conf ssl.conf.orig
Partant d’un répertoire /var/www/html vide, on peut récupérer un peu de contenu statique pour avoir quelque chose à nous mettre sous la dent.
# cd /var/www/html/ # cp -R /usr/share/httpd/noindex/* .
Régler les permissions de l’arborescence de fichiers téléchargés.
# chown -R microlinux:microlinux *
# find . -type d -exec chmod 0755 {} \;
# find . -type f -exec chmod 0644 {} \;
Ensuite, éditer /etc/httpd/conf.d/ssl.conf en renseignant les directives DocumentRoot et ServerName ainsi que l’emplacement du certificat SSL et de la clé privée.
## ## SSL Virtual Host Context ## <VirtualHost _default_:443> DocumentRoot "/var/www/html" ServerName www.slackbox.fr:443 ... SSLCertificateFile /chemin/vers/cert.pem SSLCertificateKeyFile /chemin/vers/privkey.pem SSLCertificateChainFile /chemin/vers/fullchain.pem ... </VirtualHost>
Redémarrer Apache.
# systemctl restart httpd
Ouvrir le site avec Firefox. On notera la présence du petit cadenas vert en haut à gauche dans la barre d’adresses pour indiquer l’établissement d’une connexion sécurisée.
Améliorer la sécurité de notre hébergement
Rendons-nous sur la page SSL Server Test du portail Qualys SSL Labs pour effectuer un audit de la sécurité de notre hébergement.
Pour l’heure, la résultat est plutôt médiocre et comporte une série de vulnérabilités, que nous allons éliminer l’une après l’autre en suivant les suggestions affichées.
La vulnérabilité à l’attaque POODLE se résoud en désactivant SSLv3 dans ssl.conf. L’option SSLProtocol se situe dans la configuration de l’hôte virtuel. Il faut la déplacer au début du fichier dans les options globales, en ajoutant -SSLv3, comme ceci.
# # When we also provide SSL we have to listen to the # the HTTPS port in addition. # Listen 443 https ## ## SSL Global Context ## ## All SSL configuration in this context applies both to ## the main server and all SSL-enabled virtual hosts. ## # SSL Protocol support: # List the enable protocol levels with which clients will be able # to connect. Disable SSLv2 access by default: SSLProtocol all -SSLv2 -SSLv3
Prendre en compte les modifications et relancer un test sur le site de Qualys Labs en cliquant sur Clear cache.
C’est déjà un peu mieux. La prochaine suggestion concerne la désactivation du chiffrement RC4. Cette fois-ci, il faut récupérer l’option SSLCipherSuite dans la configuration de l’hôte virtuel et la placer en tête du fichier dans les options globales, en ajoutant !RC4.
# SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: SSLProtocol all -SSLv2 -SSLv3 # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4
Recharger la configuration d’Apache et relancer un test.
On avance petit à petit. Pour nous débarrasser de la vulnérabilité restante, repérer l’option commentée SSLHonorCipherOrder et l’insérer juste après SSLCipherSuite en la décommentant.
# SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4 SSLHonorCipherOrder on
Cette fois-ci, nous avons bel et bien éliminé l’ensemble des failles de sécurité connues concernant le chiffrement.
La politique HSTS
HSTS (HTTP Strict Transport Security) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (navigateur web) compatible qu’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l’agent utilisateur par le serveur via la réponse HTTP, dans le champ d’en-tête nommé Strict-Transport-Security. La politique spécifie une période de temps durant laquelle l’agent utilisateur doit accéder au serveur uniquement de façon sécurisée.
Pour activer cette politique dans la configuration d’Apache, il suffit d’ajouter la ligne suivante dans la définition de l’hôte virtuel.
<VirtualHost _default_:443> # HSTS Header always set Strict-Transport-Security \ "max-age=63072000; includeSubDomains" ... </VirtualHost>
L’audit de sécurité nous montre qu’on est assez proche de la perfection.
Héberger plusieurs sites sécurisés
Si l’on souhaite héberger plusieurs sites sécurisés sous forme d’hôtes virtuels Apache, la solution la plus propre consiste à éditer /etc/httpd/conf.d/ssl.conf pour ne garder que les options globales, comme ceci par exemple.
# /etc/httpd/conf.d/ssl.conf Listen 443 https SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog SSLSessionCache shmcb:/run/httpd/sslcache(512000) SSLSessionCacheTimeout 300 SSLRandomSeed startup file:/dev/urandom 256 SSLRandomSeed connect builtin SSLCryptoDevice builtin SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA:!RC4 SSLHonorCipherOrder on
Ensuite, chaque hôte virtuel disposera de son propre fichier de configuration dans /etc/httpd/conf.d. Voici un exemple.
# /etc/httpd/conf.d/www.slackbox.fr.conf
# http://www.slackbox.fr -> https://www.slackbox.fr
<VirtualHost *:80>
ServerName www.slackbox.fr
ServerAlias slackbox.fr
Redirect / https://www.slackbox.fr
</VirtualHost>
# https://www.slackbox.fr
<VirtualHost _default_:443>
Header always set Strict-Transport-Security \
"max-age=63072000; includeSubDomains"
ServerAdmin info@microlinux.fr
DocumentRoot "/var/www/slackbox-site/html"
ServerName www.slackbox.fr:443
ServerAlias slackbox.fr
SSLEngine on
SSLCertificateFile /etc/letsencrypt/.../cert.pem
SSLCertificateKeyFile /etc/letsencrypt/.../privkey.pem
SSLCertificateChainFile /etc/letsencrypt/.../fullchain.pem
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
ErrorLog logs/www.slackbox.fr-error_log
CustomLog logs/www.slackbox.fr-access_log common
</VirtualHost>
