Sécuriser Apache2

Dans ce papier, nous allons faire petit un récapitulatif des bonnes pratiques pour sécuriser au mieux Apache contre les différentes attaques connues à ce jour.

Avec l’arrivée de Let’s Encrypt et donc de Certbot, nous n’avons plus d’excuse pour ne pas implémenter le TLS/SSL à notre Apache (https). Si ce n’est pas le cas chez vous, je vous recommande fortement à vous documenter et le déployer. Le chiffrement des connexions entre le client et le serveur pour des pages comme l’authentification est selon moi indispensable. 

Ici nous n’allons pas voir comment installer un certificat SSL avec Let’Encrypt et Apache mais plutôt revoir les paramètres de ce dernier pour le sécuriser en refusant, par exemple, l’utilisation de certains algorithmes de chiffrement et protocoles aujourd’hui vulnérable. Aussi, nous allons voir d’autres paramètres Apache à modifier pour se prémunir d’attaques de type Cross-site Scripting (XSS) et autre.
Pour commencer, ce billet se base sur la dernière version stable d’Apache2 (2.4). Aussi, nous nous basons sur le système d’exploitation Debian.

C’est important à savoir car sur certaines distributions, les fichiers de configurations ne sont pas les mêmes. Par exemple l’équivalent du fichier /etc/apache/apache2.conf sous RedHat et CentOS est /etc/httpd/conf/httpd.conf. De même que la syntaxe de certains paramètres peuvent différer entre la version 2.2 et 2.4 d’Apache.

Apache

Limiter les informations pouvant intéresser l’attaquant.

Dans le fichier /etc/apache/conf-available/security.conf:

# ne pas afficher la version d'apache dans les pages d'erreur
ServerSignature Off

# ne pas afficher les informations dans les en-têtes (headers)
ServerToken Prod

# ne pas afficher les informations comme les codes erreur aux clients
TraceEnable Off

# ne pas afficher les informations concernant PHP dans les en-têtes
Header unset X-Powered-By

# se protéger de fuites d'information lors de la mise en cache de données
FilETag none
Header unset ETag

# cet en-tête indique au navigateur d'activer la vérification des types mime (MSIE)
Header set X-Content-Type-Options "nosniff"

# cet en-tête indique au navigateur d'activer le filtre "anti-xss" s'il dispose de la fonctionnalité
Header set X-XSS-Protection "1; mode=block"

# se protéger des attaques dites clickjacking
Header always append X-Frame-Options SAMEORIGIN

Note: clickjacking

Vous aurez remarqué que la plupart de ces paramètres sont déjà présent dans la configuration par défaut mais commentés ou mal paramétrés. Concernant les en-têtes, cela s’explique par la nécessité de l’activation du module « mod_headers ». Pour que ces modifications soient donc prisent en compte, il faudra activer ce module avant de relancer Apache.

# activation du mod_headers
a2enmod headers

# relancer apache
service apache2 restart

Affinement au niveau du ou des sites. Ajouter cette modification des en-têtes afin de protéger vos Cookies dans le fichier vhost de votre site.

Header set Set-Cookie HttpOnly;Secure

Par défaut, les Cookies peuvent être accessible à tous programmes comme un script Javascript malveillant. Le flag « HttpOnly » permet d’indiquer au navigateur l’accès aux Cookies via des requêtes http. Le flag « Secure » permet de rediriger la requête « Cookie » initiale du navigateur vers un canal dit sécurisé, soit l’utilisation du https.

Dans la même lancée, nous allons en profiter pour modifier le (ou les) fichiers vhost_ssl afin d’y ajouter le mécanisme « HSTS ».

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

Le HSTS permet d’imposer au navigateur si compatible l’utilisation du https. Ainsi, c’est le navigateur qui fait la redirection du trafic http vers https. Aussi, le navigateur va bloquer les pages ne s’affichant pas en https.
La valeur « max-age=2592000 » permet d’indiquer au navigateur d’appliquer cette politique pendant une période de 30 jours. Il faut noter que cette configuration peut avoir un impacte si vous utilisez un proxy qui effectue le chiffrement https.

En parlant du canal https, passons maintenant à la sécurisation du TLS/SSL.

TLS/SSL

Pour commencer, il faut savoir que le terme « SSL » est largement employé par abus de langage alors que ce protocole est maintenant obsolète. En effet, même SSLv3 est aujourd’hui déchiffrable. Heureusement pour nous, il y a TLS. Protocole qui n’est pas sans failles non plus. Au même titre que SSLv3, TLSv1.0 est vulnérable à la faille dite « BEAST ». Ça date de 2011 tout de même.

Bref, commençons donc par limiter le choix des protocoles à utiliser en éditant le fichier de configuration du module SSL; /etc/apache/mods-available/ssl.conf.

SSLProtocol all -TLSv1 -SSLv2 -SSLv3

Notez que SSLv1 n’est plus du tout supporté.

Tout comme TLS/SSL, les algorithmes de chiffrements ne sont pas tous sans failles. Il faut donc aussi faire notre sélection et n’autoriser que ceux qui sont réputés fiable.

SSLCipherSuite SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

Notez que cette liste peut être amenée à changer dans le temps. Heureusement pour nous, le site cipherli.st ainsi que Mozilla mettent à disposition des outils pour nous aider à se mettre à jour.

Toujours dans les paramètres du module SSL, nous pouvons ajouter ces valeurs:

# prioriser l'algorithme par ordre
SSLHonorCipherOrder on
# désactiver la renégociation non sécurisé
SSLInsecureRenegotiation off
# désactiver la compression
SSLCompression off

Outils d’analyse

Voici quelques outils qui peuvent vous permettre un audit rapide de votre installation.

  • SSLLabs  : un tester web pour vérifier l’implémentation du SSL pour un site web donné
  • OpenVAS  : solution opensource permettant un audit complet pour une ou plusieurs machines
  • Nikto  : un script permettant de tester l’installation SSL avec support de proxy
  • testssl.sh  : un autre script permettant de tester l’installation SSL pour le web mais aussi pour les autres protocoles comme FTP, IMAP, SMTP etc

Nikto et testssl.sh m’ont été très utile pour la sécurisation de mon serveur mail et ftps. Je vous les recommandes vivement. Concernant testssl.sh, n’hésitez pas à l’utiliser avec « openssl1.0.2i-chacha ».

Comme vous l’avez constaté, cet article se consacre essentiellement sur Apache et le TLS/SSL. On voit brièvement comment sécuriser PHP mais cela ne sera pas suffisant, il faudra approfondir vos recherches pour modifier les paramètres du (ou des) fichier php.ini de vos sites par exemple.