Sécuriser le serveur web Apache sous CentOS

Audit ApacheL’installation par défaut du serveur web Apache comporte une série de vulnérabilités connues. La correction de ces failles constitue l’objet de cet article. Notre démarche consistera à installer un scanner de sécurité sur une machine distante, qui nous permettra d’auditer le serveur. Ensuite, nous allons peaufiner la configuration d’Apache en fonction des résultats de notre audit. Pour nos tests, nous partons d’une installation par défaut d’Apache avec PHP.

Le scanner de sécurité Nikto

Nikto est un scanner de sécurité pour les serveurs Web. Il permet d’auditer Apache à la recherche de failles diverses et variées, en puisant dans une base de données de vulnérabilités connues à ce jour.

# yum install nikto

L’utilisation de Nikto est triviale. Il suffit de fournir l’adresse IP ou le nom d’hôte du serveur en argument.

$ nikto -h sd-100246.dedibox.fr

Au premier lancement, Nikto nous affiche l’avertissement suivant.

*** RFIURL is not defined in nikto.conf--no RFI tests will run ***

Pour effectuer les tests RFI (Remote File Inclusion), nous allons éditer /etc/nikto/config et fournir l’URL du fichier distant index.php avec la fonction phpinfo().

# RFI URL. This remote file should return a phpinfo call, 
# for example: <?php phpinfo(); ?>
RFIURL=http://sd-100246.dedibox.fr/index.php

Au deuxième lancement, Nikto va mouliner quelques minutes, pour nous afficher une  liste de vulnérabilités potentielles du serveur. À partir de là, il suffit d’être un peu méthodique.

Masquer les infos sur le système

Dans la configuration par défaut, Apache fournit des infos sur la version du serveur, le système d’exploitation et la version de PHP. Autant d’infos précieuses pour un attaquant potentiel.

-----------------------------------------------------------------
+ Target IP:          163.172.220.174
+ Target Hostname:    sd-100246.dedibox.fr
+ Target Port:        80
+ Start Time:         2017-07-10 10:59:49 (GMT2)
-----------------------------------------------------------------
+ Server: Apache/2.4.6 (CentOS) PHP/5.4.16

Pour masquer ces infos, créer un fichier /etc/httpd/conf.d/hardening.conf comme ceci.

# /etc/httpd/conf.d/hardening.conf

# Masquer les infos d'Apache
ServerSignature Off
ServerTokens Prod

Recharger la configuration d’Apache.

# systemctl reload httpd

À présent, Apache est bien moins bavard.

$ nikto -h sd-100246.dedibox.fr
- Nikto v2.1.5
-----------------------------------------------------------------
+ Target IP:          163.172.220.174
+ Target Hostname:    sd-100246.dedibox.fr
+ Target Port:        80
+ Start Time:         2017-07-10 11:21:40 (GMT2)
-----------------------------------------------------------------
+ Server: Apache

Masquer la signature de PHP

Le deuxième avertissement concerne la signature de PHP sur le serveur.

+ Retrieved x-powered-by header: PHP/5.4.16

Pour corriger ce comportement, il suffit d’éditer /etc/php.ini sur le serveur. Repérer la variable expose_php et modifier sa valeur en conséquence.

expose_php = Off

Recharger Apache.

# systemctl reload httpd

Empêcher les détournements de clics

Le clickjacking ou détournement de clic est une technique malveillante visant à pousser un internaute à fournir des informations confidentielles ou à prendre le contrôle de son ordinateur en le poussant à cliquer sur des pages apparemment sûres.

+ The anti-clickjacking X-Frame-Options header is not present.

Pour empêcher ce genre d’attaque, éditer /etc/httpd/conf.d/hardening.conf et ajouter la directive suivante.

# Clickjacking
<IfModule mod_headers.c>
  Header always append X-Frame-Options SAMEORIGIN
</IfModule> 

Prendre en compte les modifications.

# systemctl httpd reload

L’avertissement relatif au clickjacking ne s’affiche plus. Notons au passage que Nikto nous affiche un nouvel avertissement, que nous pouvons ignorer sereinement, vu qu’il s’agit d’un bug dans le scanner.

+ Uncommon header 'x-frame-options' found, with contents: SAMEORIGIN

Désactiver les ETags

Les ETags (ou entity tags) sont normalement utilisés pour pouvoir différencier deux versions d’un même document. C’est un identifiant de la forme 1321-553ba6ed5c167, unique pour une URL, qui est transmis entre le navigateur et le serveur dans les requêtes HTTP. Et c’est également une faille de sécurité potentielle d’Apache, qui peut permettre à un attaquant d’obtenir des infos sensibles sur les fichiers du serveur, comme les inodes. Dans la configuration par défaut d’Apache, les ETags sont activés.

+ Server leaks inodes via ETags, header found with file /, 
fields: 0x1321 0x5058a1e728280

Pour désactiver les ETags, on va ajouter une ligne à notre fichier /etc/httpd/conf.d/hardening.conf.

# ETags
FileETag none

Recharger la configuration.

# systemctl reload httpd

Désactiver l’affichage du contenu des répertoires

En l’absence d’un fichier index.html ou index.php, Apache affiche le contenu d’un répertoire.

+ OSVDB-3268: /icons/: Directory indexing found.

Voici à quoi cela ressemble concrètement.

Apache Directory Listing

Cette fonctionnalité peut être désactivée grâce à la directive Options. Ouvrir /etc/httpd/conf/httpd.conf et repérer la stance suivante.

<Directory "/var/www/html">
  Options Indexes FollowSymlinks
  AllowOverride None
  Require all granted
</Directory>

Éditer les options comme ceci.

<Directory "/var/www/html">
  Options -Indexes 
  Options FollowSymlinks
  AllowOverride None
  Require all granted
</Directory>

Prendre en charge les modifications.

# systemctl reload httpd

Apprécier le résultat.

Apache Directory Listing Forbidden

Empêcher Apache de suivre les liens symboliques

Dans la configuration par défaut, Apache suit les liens symboliques, ce qui n’est pas recommandé en termes de sécurité. Pour empêcher ceci, nous allons reprendre la stance précédente dans /etc/httpd/conf/httpd.conf en l’éditant comme ceci.

<Directory "/var/www/html">
 Options -Indexes -FollowSymlinks 
 AllowOverride None
 Require all granted
</Directory>

Recharger la configuration, et le tour est joué.

# systemctl reload httpd

Installer le module mod_security

Nikto nous affiche toute une série d’avertissement relatifs au XST (cross-site tracing) et au XSS (cross-site scripting), qui ressemblent à ceci.

+ OSVDB-877: HTTP TRACE method is active, suggesting the host is 
  vulnerable to XST

Le meilleur moyen de lutter contre ce genre d’attaque tout comme les injections SQL, c’est d’installer le pare-feu applicatif mod_security, qui se présente sous la forme d’un module pour Apache.

Outre le module mod_security à proprement parler, CentOS fournit le paquet mod_security_crs qui contient une collection de règles de base (Core Rule Set) pour le bon fonctionnement du module.

# yum install mod_security mod_security_crs

Après l’installation, le répertoire /etc/httpd/conf.d contient un nouveau fichier mod_security.conf. Le module mod_security est activé dans la configuration par défaut.

SecRuleEngine On
  • On – Les règles sont activées
  • Off – Les règles sont désactivées
  • DetectionOnly – Les transactions sont interceptées et journalisées

Recharger la configuration.

# systemctl restart httpd

L’activation de mod_security se manifeste dans /var/log/httpd/error.log.

ModSecurity for Apache/2.7.3 (http://www.modsecurity.org/) 
configured.

L’installation de ce module semble avoir résolu un grand nombre de failles de sécurité d’Apache, au vu du nombre réduit d’avertissements de Nikto.

Désactiver les SSI et l’exécution des CGI

Les SSI (Server Side Includes ou « Inclusions Côté Serveur ») sont un langage de programmation fait pour être interprété par un serveur HTTP lorsqu’il sert un document HTML. Une attaque SSI exploite une application web en exécutant du code arbitraire à distance, ce qui permet à l’attaquant d’accéder à des infos sensibles comme les fichiers de mots de passe, ou encore d’exécuter des commandes de shell. Il vaut donc mieux désactiver cette fonctionnalité si l’on n’en a pas besoin.

Là encore, reprendre la stance précédente dans /etc/httpd/conf/httpd.conf en ajoutant les deux options correspondantes.

<Directory "/var/www/html">
 Options -Indexes -FollowSymlinks -ExecCGI -Includes 
 AllowOverride None
 Require all granted
</Directory>

Recharger la configuration d’Apache.

# systemctl reload httpd

Désactiver les modules superflus

Dans la configuration par défaut, Apache charge une quantité de modules. Nous allons désactiver les modules que nous n’utilisons pas. Le répertoire /etc/httpd/conf.modules.d contient une série de fichiers qui s’occupent du chargement des modules Apache. Ouvrir 00-base.conf et commenter les modules superflus.

#LoadModule autoindex_module modules/mod_autoindex.so
#LoadModule info_module modules/mod_info.so
#LoadModule userdir_module modules/mod_userdir.so

Le module mod_autoindex est appelé par /etc/httpd/conf.d/autoindex.conf. Étant donné que nous avons désactivé l’affichage du contenu des répertoires, nous pouvons le désactiver comme ceci.

# cd /etc/httpd/conf.d
# mv autoindex.conf autoindex.conf.deactivated

Recharger la configuration d’Apache.

# systemctl reload httpd

Protéger Apache des attaques XSS

XSS est une faille de sécurité qui permet d’injecter du code dans des pages web, par le biais de variables mal protégées. Pour contrer ce genre d’attaque, on peut activer la protection XSS en ajoutant la stance suivante au fichier /etc/httpd/conf.d/hardening.conf.

# XSS
<IfModule mod_headers.c>
   Header set X-XSS-Protection "1; mode=block"
</IfModule>

Une fois qu’on a rechargé la configuration d’Apache, voici comment cela se présente côté client.

$ curl --head http://sd-100246.dedibox.fr
HTTP/1.1 200 OK
Date: Mon, 10 Jul 2017 13:59:38 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Type: text/html
Ce contenu a été publié dans CentOS, Documentation Microlinux, avec comme mot(s)-clé(s) , , , , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *