Étapes recommandées pour renforcer Apache HTTP sous FreeBSD 12.0

L’auteur a choisi le Free and Open Source Fund comme récipiendaire d’une donation dans le cadre du programme Write for Donations.

Introduction

Bien que l’installation par défaut d’un serveur Apache HTTP soit déjà sûre, sa configuration peut être considérablement améliorée grâce à quelques modifications. Vous pouvez compléter les mécanismes de sécurité déjà existants, par exemple en mettant en place des protections autour des cookies et des en-têtes, afin que les connexions ne puissent pas être altérées au niveau du client de l’utilisateur. Ce faisant, vous pouvez considérablement réduire les possibilités de plusieurs méthodes d’attaque, comme les attaques de type “Cross-Site Scripting” (également connues sous le nom de XSS). Vous pouvez également éviter d’autres types d’attaques, telles que la falsification de requête inter-sites, ou le détournement de session, ainsi que les attaques par déni de service.

Dans ce tutoriel, vous allez implémenter certaines mesures recommandées pour réduire la quantité d’informations exposées sur votre serveur. Vous vérifierez la liste des répertoires et désactiverez l’indexation pour vérifier l’accès aux ressources. Vous modifierez également la valeur par défaut de la directive sur le délai d'attente afin d’atténuer les attaques de type déni de service. En outre, vous désactiverez la méthode TRACE afin que les sessions ne puissent pas être inversées et détournées. Enfin, vous sécuriserez les en-têtes et les cookies.

La plupart des paramètres de configuration seront appliqués au fichier de configuration principal d’Apache HTTP qui se trouve dans /usr/local/etc/apache24/httpd.conf.

Conditions préalables

Avant de commencer ce guide, vous aurez besoin des éléments suivants :

• Un serveur FreeBSD 12 configuré en suivant ce tutoriel sur Comment démarrer avec FreeBSD.

• Un pare-feu mis en place en suivant la section Configuration d’un pare-feu dans l’article Étapes recommandées pour les nouveaux serveurs FreeBSD 12.0.

• Une pile FAMP complète installée en suivant le tutoriel Comment installer une pile Apache, MySQL, et PHP (FAMP) sous FreeBSD 12.0.

• Un certificat Let’s Encrypt installé en suivant le tutoriel Comment sécuriser Apache avec Let’s Encrypt sous FreeBSD.

Une fois ces conditions préalables réunies, vous disposez d’un système FreeBSD avec une pile capable de servir du contenu web en utilisant tout ce qui est écrit en PHP, comme les principaux logiciels de gestion de contenu (CMS). De plus, vous avez chiffré des connexions sécurisées grâce à Let’s Encrypt.

Réduire les informations sur le serveur

La bannière de système d’exploitation est une méthode utilisée par les ordinateurs, les serveurs et les dispositifs de toutes sortes pour se présenter sur les réseaux. Des personnes malveillantes peuvent utiliser ces informations pour exploiter les systèmes concernés. Dans cette section, vous réduirez la quantité d’informations publiées par cette bannière.

Des ensembles de directives contrôlent la manière dont ces informations sont affichées. À cet effet, la directive ServerTokens est importante ; par défaut, elle affiche au client qui s’y connecte tous les détails sur le système d’exploitation et les modules compilés.

Vous utiliserez un outil de balayage du réseau pour vérifier quelles informations sont actuellement révélées avant d’appliquer tout changement. Pour installer nmap, exécutez la commande suivante :

sudo pkg install nmap

Pour obtenir l’adresse IP de votre serveur, vous pouvez exécuter la commande suivante :

ifconfig vtnet0 | awk '/inet / {print $2}'

Vous pouvez vérifier la réponse du serveur web en utilisant la commande suivante :

nmap -sV -p 80 your-server-ip

Vous appelez nmap pour effectuer un scan (d’où le drapeau -s), pour afficher la version (le drapeau -V) sur le port 80 (le drapeau -p) sur l’IP ou le domaine donné.

Vous recevrez des informations sur votre serveur web, semblables à celles qui suivent :

Output
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET
Nmap scan report for 206.189.123.232
Host is up (0.054s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Cette sortie montre que des informations telles que le système d’exploitation, la version d’Apache HTTP et OpenSSL sont visibles. Cela peut être utile aux attaquants pour obtenir des informations sur le serveur et choisir les bons outils à exploiter, par exemple, une vulnérabilité dans le logiciel fonctionnant sur le serveur.

Vous placerez la directive ServerTokens dans le fichier de configuration principal puisqu’elle n’est pas configurée par défaut. L’absence de cette configuration fait qu’Apache HTTP affiche les informations complètes sur le serveur, comme l’indique la documentation. Pour limiter les informations qui sont révélées sur votre serveur et votre configuration, vous placerez la directive ServerTokens dans le fichier de configuration principal.

Vous placerez cette directive à la suite de l’entrée ServerName dans le fichier de configuration. Exécutez la commande suivante pour trouver la directive :

grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

Vous trouverez le numéro de ligne que vous pouvez ensuite rechercher avec vi :

Output
226    #ServerName www.example.com:80

Exécutez la commande suivante :

sudo vi +226 /usr/local/etc/apache24/httpd.conf

Ajoutez la ligne surlignée suivante :

. . .
#ServerName www.example.com:80
ServerTokens Prod

Enregistrez et quittez le fichier avec :wq et ENTER.

En réglant la directive ServerTokens sur Prod, on affichera uniquement qu’il s’agit d’un serveur web Apache.

Pour que cela prenne effet, redémarrez le serveur Apache HTTP :

sudo apachectl restart

Pour tester les changements, exécutez la commande suivante :

nmap -sV -p 80 your-server-ip

Vous obtiendrez un résultat similaire à celui qui suit, avec un minimum d’informations sur votre serveur web Apache :

Output
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET
Nmap scan report for WPressBSD (206.189.123.232)
Host is up (0.056s latency).

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Vous avez vu quelles informations le serveur annonçait avant la modification et vous avez maintenant réduit celles-ci au minimum. De ce fait, vous fournissez moins d’indices sur votre serveur à un acteur externe. Au cours de l’étape suivante, vous gérerez les listes du répertoire pour votre serveur web.

Gestion des listes du répertoire

Au cours de cette étape, vous vous assurerez que les listes du répertoire sont correctement configurées, de sorte que les bonnes parties du système soient accessibles au public comme prévu, tandis que les autres sont protégées.

L’ajout de l’énoncé Options -Indexes permet de définir le contenu du chemin de données /usr/local/www/apache24/data pour qu’il ne soit pas indexé (read listed) automatiquement si un fichier .html n’existe pas, et qu’il n’indique pas si une URL correspond à ce répertoire. Cela s’appliquera également lors de l’utilisation de configurations d’hôtes virtuels telles que celui utilisé pour le tutoriel préalable au certificat Let’s Encrypt.

Vous définirez la directive Options avec l’argument -Indexes et avec la directive +FollowSymLinks, qui permettra de suivre des liens symboliques. Vous utiliserez le symbole + afin de respecter les conventions HTTP d’Apache.

Exécutez la commande suivante pour trouver la ligne à modifier dans le fichier de configuration :

grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

Vous verrez une sortie similaire à ce qui suit :

Output
263 :    Options Indexes FollowSymLinks

Exécutez cette commande pour accéder directement à la ligne que vous souhaitez modifier :

sudo vi +263 /usr/local/etc/apache24/httpd.conf

Modifiez maintenant la ligne conformément à la configuration :

. . .
#
Options -Indexes +FollowSymLinks

#
. . .

Enregistrez et quittez le fichier avec :wq et ENTER.

Redémarrez Apache HTTP pour implémenter ces modifications :

sudo apachectl restart

Au niveau de votre domaine dans le navigateur, vous verrez un message d’accès interdit, également connu sous le nom d’erreur 403. Cela est dû aux changements que vous avez appliqués. Le placement de -Indexes dans la directive Options a désactivé la capacité d’auto-indexation d’Apache HTTP et il n’y a donc pas de fichier index.html dans le chemin des données.

Vous pouvez résoudre ce problème en plaçant un fichier index.html à l’intérieur du VirtualHost que vous avez activé dans le tutoriel préalable au certificat Let’s Encrypt. Vous utiliserez le bloc par défaut dans Apache HTTP et le placerez dans le même dossier que le DocumentRoot que vous avez déclaré dans l’hôte virtuel.

<VirtualHost *:80>
    ServerAdmin your_email@your_domain.com
    DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
    ServerName your_domain.com
    ServerAlias www.your_domain.com
    ErrorLog "/var/log/your_domain.com-error_log"
    CustomLog "/var/log/your_domain.com-access_log" common
</VirtualHost>

Utilisez la commande suivante pour ce faire :

sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

Vous verrez maintenant un message Ça marche ! lorsque vous visiterez votre domaine.

Dans cette section, vous avez imposé des restrictions à la directive Indexes afin de ne pas inclure et afficher automatiquement un contenu autre que celui que vous avez prévu. Désormais, s’il n’existe pas de fichier index.html dans le chemin de données, Apache HTTP ne créera pas automatiquement un index du contenu. Dans la prochaine étape, vous irez au-delà de l’obscurcissement des informations et vous adapterez différentes directives.

Réduire la valeur de la directive sur le délai d’attente

La directive Timeout fixe la limite du délai pendant lequel Apache HTTP attendra une nouvelle entrée/sortie avant l’échec de la demande de connexion. Cette échec peut être du à différentes circonstances telles que des paquets n’arrivant pas au serveur ou des données n’étant pas confirmées comme ayant été reçues par le client.

Par défaut, le délai d’attente est fixé à 60 secondes. Dans les environnements où le service Internet est lent, cette valeur par défaut peut être raisonnable, mais une minute est une durée assez longue, en particulier si le serveur couvre une cible d’utilisateurs avec un service Internet plus rapide. En outre, la période pendant laquelle le serveur ne ferme pas la connexion peut être utilisée abusivement pour effectuer des attaques par déni de service (DoS). Si une invasion de ces connexions malveillantes se produit, le serveur faiblira et s’exposera à des risques de saturation et d’incapacité à répondre.

Pour modifier la valeur, vous trouverez les entrées Timeout dans le fichier httpd-default.conf :

grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

Vous verrez une sortie similaire à :

Output
 8  # Timeout: The number of seconds before receives and sends time out.
10  Timeout 60
26  # KeepAliveTimeout: Number of seconds to wait for the next request from the
29  KeepAliveTimeout 5
89  RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

Dans la ligne de sortie, 10 définit la valeur de la directive Timeout. Pour accéder directement à cette ligne, exécutez la commande suivante :

sudo vi +10  /usr/local/etc/apache24/extra/httpd-default.conf

Vous la modifierez pour la régler sur 30 secondes, par exemple, comme suit :

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 30

Enregistrez et quittez le fichier avec :wq et ENTER.

La valeur de la directive Timeout doit trouver un équilibre entre une période suffisamment longue pour que ces événements permettent une connexion légitime et réussie, et suffisamment courte pour empêcher des tentatives de connexion non souhaitées.

Pour que cette modification prenne effet, redémarrez le serveur Apache HTTP :

sudo apachectl restart

Vous avez modifié la valeur par défaut de la directive Timeout afin d’atténuer partiellement les attaques par déni de service.

Désactiver la méthode TRACE

Le Hypertext Transport Protocol a été développé selon un modèle client-serveur et, à ce titre, le protocole dispose de méthodes de requête pour récupérer ou placer des informations depuis/vers le serveur. Le serveur doit comprendre ces ensembles de méthodes et l’interaction entre elles. Dans cette étape, vous configurerez les méthodes minimales nécessaires.

La méthode TRACE, considérée comme inoffensive, a été utilisée pour réaliser des attaques de type Cross Site Tracing. Ces types d’attaques permettent à des acteurs malveillants de voler des sessions d’utilisateurs grâce à cette méthode. La méthode a été conçue à des fins de débogage. Le serveur renvoie la même requête que celle envoyée à l’origine par le client. Comme le cookie de la session du navigateur est envoyé au serveur, il sera renvoyé à nouveau. Cependant, cela peut potentiellement être intercepté par un acteur malveillant, qui peut alors rediriger la connexion d’un navigateur vers un site sous son contrôle et non vers le serveur d’origine.

En raison de la possibilité d’une utilisation abusive de la méthode TRACE, il est recommandé de ne l’utiliser que pour le débogage et non en production. Dans cette section, vous désactiverez cette méthode.

Modifiez le fichier httpd.conf avec la commande suivante, puis appuyez sur G pour atteindre la fin du fichier :

sudo vi /usr/local/etc/apache24/httpd.conf

Ajoutez le chemin d’entrée suivant à la fin du fichier :

. . .
TraceEnable off

Une bonne pratique consiste à spécifier uniquement les méthodes que vous utiliserez dans votre serveur web Apache HTTP. Cela permettra de limiter les points d’entrée potentiels pour les acteurs malveillants.

LimitExcept peut être utile à cette fin, car il n’autorise aucune autre méthode que celles qui y sont déclarées. Par exemple, une configuration peut être établie comme celle-ci :

DocumentRoot "/usr/local/www/apache24/data"
<Directory "/usr/local/www/apache24/data">
    Options -Indexes +FollowSymLinks -Includes
    AllowOverride none
     <LimitExcept GET POST HEAD>
       deny from all
    </LimitExcept>
    Require all granted
</Directory>

Comme indiqué dans la directive LimitExcept, seules les méthodes GET, POST et HEAD sont autorisées dans la configuration.

• La méthode GET fait partie du protocole HTTP et elle est utilisée pour récupérer des données.
• La méthode POST fait également partie du protocole HTTP et est utilisée pour envoyer des données au serveur.
• La méthode HEAD est similaire à la méthode GET, mais elle n’a pas d’organe de réponse.

Vous utiliserez la commande suivante et placerez le bloc LimitExcept à l’intérieur du fichier :

sudo vi +272 /usr/local/etc/apache24/httpd.conf

Pour définir cette configuration, vous placerez le bloc suivant dans l’entrée de la directive DocumentRoot où le contenu sera lu, plus précisément dans l’entrée Directory :

. . .
<LimitExcept GET POST HEAD>
   deny from all
</LimitExcept>
. . .

Pour appliquer les modifications, redémarrez Apache HTTP :

sudo apachectl restart

La nouvelle directive AllowedMethods offre des fonctionnalités similaires, bien que son statut soit encore expérimental.

Vous avez vu ce que sont les méthodes HTTP, leur utilisation et la protection qu’elles offrent contre les activités malveillantes se servant de la méthode TRACE, ainsi que la manière de déclarer les méthodes à utiliser. Maintenant, vous allez travailler avec d’autres protections dédiées aux en-têtes et aux cookies HTTP.

Sécuriser des en-têtes et des cookies

Au cours de cette étape, vous allez définir des directives spécifiques pour protéger les sessions que les machines clientes ouvriront lorsqu’elles visiteront votre serveur web Apache HTTP. De cette façon, votre serveur ne chargera pas de contenu indésirable, le chiffrage ne sera pas déclassé et vous éviterez que votre contenu soit fouillé.

Les en-têtes sont des éléments des méthodes de requêtes. Il existe des en-têtes pour ajuster l’authentification, la communication entre le serveur et le client, la mise en cache, la négociation de contenu, etc.

Les cookies sont des éléments d’information envoyés par le serveur au navigateur. Ces bits permettent au serveur de reconnaître le navigateur du client d’un ordinateur à l’autre. Ils permettent également aux serveurs de reconnaître les sessions des utilisateurs. Ils peuvent, par exemple, suivre le panier d’un utilisateur connecté, ses informations de paiement, son historique, etc. Les cookies sont utilisés et conservés dans le navigateur web du client puisque HTTP est un protocole apatride, ce qui signifie qu’une fois la connexion fermée, le serveur ne se souvient pas de la requête envoyée par un client, ou un autre.

Il est important de protéger les en-têtes ainsi que les cookies car ils assurent la communication entre le client du navigateur web et le serveur web.

Le module des en-têtes est activé par défaut. Pour vérifier s’il est chargé, vous utiliserez la commande suivante :

sudo apachectl -M | grep 'headers'

Vous verrez la sortie suivante :

Output
headers_module (shared)

Si vous ne voyez aucune sortie, vérifiez si le module est activé dans le fichier httpd.conf d’Apache :

grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

En sortie, vous verrez une ligne non commentée renvoyant au module spécifique pour les en-têtes :

. . .
122  LoadModule headers_module libexec/apache24/mod_headers.so
. . .

Supprimez le hashtag au début de la ligne mod_headers.so, s’il est présent, pour activer la directive.

En utilisant les directives HTTP Apache suivantes, vous protégerez les en-têtes et les cookies contre les activités malveillantes, afin de réduire le risque pour les clients et les serveurs.

Vous allez maintenant régler la protection de l’en-tête. Vous placerez toutes ces valeurs d’en-tête dans un seul bloc. Vous pouvez choisir d’appliquer ces valeurs comme vous le souhaitez, mais toutes sont recommandées.

Modifiez le fichier httpd.conf avec la commande suivante, puis appuyez sur G pour atteindre la fin du fichier :

sudo vi /usr/local/etc/apache24/httpd.conf

Placez le bloc suivant à la fin du fichier :

. . .
<IfModule mod_headers.c>
  # Add security and privacy related headers
  Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
  Header set X-Content-Type-Options "nosniff"
  Header set X-XSS-Protection "1; mode=block"
  Header set Referrer-Policy "strict-origin"
  Header set X-Frame-Options: "deny"
  SetEnv modHeadersAvailable true
</IfModule>

• Jeu d'en-tête Strict-Transport-Security "max-age=31536000 ; includeSubDomains" : le HTTP Strict Transport Security (HTSTS) est un mécanisme permettant aux serveurs et clients web (principalement les navigateurs) d’établir des communications en utilisant uniquement le HTTPS. En l’implémentant, vous évitez les attaques de type “man-in-the-middle”, où une tierce partie entre les communications pourrait potentiellement accéder aux bits, mais aussi les altérer.

• En-tête always edit Set-Cookie (. *) "$1 ; HttpOnly ; Secure" : les drapeaux HttpOnly et Secure sur les en-têtes aident à prévenir les attaques de type “cross-site scripting”, également connues sous le nom de XSS. Les cookies peuvent être utilisés à mauvais escient par les pirates pour se faire passer pour des visiteurs légitimes se présentant comme quelqu’un d’autre (vol d’identité), ou être trafiqués.

• En-tête Referrer-Policy "strict-origin" : l’en-tête Referrer-Policy définit les informations qui sont incluses en tant qu’informations de référence dans le champ d’en-tête.

• En-tête Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": l’en-tête Content-Security-Policy (CSP) empêchera complètement le chargement de contenu non spécifié dans les paramètres, ce qui est utile pour prévenir les attaques par script inter-sites (XSS). Il existe de nombreux paramètres possibles pour configurer la politique pour cet en-tête. L’essentiel est de le configurer pour charger le contenu du même site et de mettre à jour tout contenu ayant une origine HTTP.

• En-tête X-XSS-Protection "1; mode=block" : cette option prend en charge les anciens navigateurs qui ne sont pas compatibles avec les en-têtes Content-Security-Policy. L’en-tête ‘X-XSS-Protection’ assure une protection contre les attaques de type Cross-Site Scripting. Vous n’avez pas besoin de définir cet en-tête, sauf si vous devez prendre en charge d’anciennes versions de navigateur, ce qui est rare.

• En-tête X-Frame-Options: "deny": cela permet d’éviter les attaques de type “clickjacking”. L’en-tête “X-Frame-Options” indique au navigateur si une page peut être rendue dans un <frame>, <iframe>, <embed> ou <object>. Ainsi, le contenu d’autres sites ne peut pas être intégré à d’autres, ce qui empêche les attaques de type “clickjacking”. Ici, vous refusez tout rendu de trame afin que la page web ne puisse être intégrée nulle part ailleurs, pas même à l’intérieur du même site web. Vous pouvez l’adapter à vos besoins, si, par exemple, vous devez autoriser le rendu de certaines pages parce qu’il s’agit de publicités ou de collaborations avec des sites web spécifiques.

• En-tête X-Content-Type-Options "nosniff": l’en-tête “X-Content-Type-Options” contrôle les types MIME afin qu’ils ne soient pas modifiés et suivis. Les types MIME sont des normes de format de fichier ; ils fonctionnent pour le texte, l’audio, la vidéo, l’image, etc. Cet en-tête empêche les acteurs malveillants de fouiller le contenu de ces fichiers et d’essayer de modifier les types de fichiers.

Redémarrez maintenant Apache pour que les modifications prennent effet :

sudo apachectl restart

Pour vérifier les niveaux de sécurité de vos paramètres de configuration, visitez le site web des en-têtes de sécurité. Après avoir suivi les étapes de ce tutoriel, votre domaine obtiendra la note A.

Dans cette étape, vous avez utilisé jusqu’à sept paramètres pour améliorer la sécurité de vos en-têtes et cookies. Ces mesures permettront d’éviter les attaques de type Cross-Site Scripting, le “clickjacking” et d’autres types d’attaques.

Conclusion

Dans ce tutoriel, vous avez abordé plusieurs aspects liés à la sécurité, à la divulgation d’informations à la protection des sessions, en passant par la définition d’autres paramètres de configuration pour les fonctionnalités importantes.

Pour d’autres ressources concernant le renforcement d’Apache, voici quelques autres références :

• Conseils de sécurité HTTP d’Apache
• Directives de sécurité de Mozilla
• Recommandations d’audit du Center for Internet Security pour Apache HTTP

Pour connaître des outils supplémentaires de protection d’Apache HTTP :

• mod_evasive est un outil utile pour aider à atténuer les attaques DoS. Vous pouvez trouver plus de détails dans le tutoriel Comment se protéger contre les DoS et DDoS avec mod_evasive pour Apache.

• fail2ban est un logiciel de prévention des intrusions utile pour bloquer les tentatives de connexion répétées des utilisateurs non autorisés. Vous pouvez trouver plus d’informations dans le tutoriel Comment protéger un serveur Apache avec Fail2Ban.

• ModSecurity est un pare-feu d’application Web (ou WAF) qui, en tant que tel, offre un large éventail de possibilités basées sur des règles prédéfinies écrites par SpyderLabs et les membres de la communauté. Vous pouvez trouver plus d’informations à ce sujet dans le tutoriel Comment configurer ModSecurity avec Apache.