Apache HTTP Server Version 1.3

Discussion sur la configuration rapport à la sécurité

La configuration d'un serveur Web a des implications en matière de sécurité informatique . Certaines des suggestions faites ici sont d'ordre général, d'autres sont plus spécifiques à Apache.

Droits d'accès sur les répertoires de trace

Lorsqu'Apache démarre, il ouvre les fichiers de trace comme appartenant au même utilisateur sous lequel il a été lancé avant de basculer sur l'utilisateur défini par la directive User . Toute personne ayant les droits d'écriture dans ce répertoire peut de ce fait rajouter des données pseudo-arbitraires dans n'importe quel fichier du système pour lequel l'utilisateur ayant démarré Apache a un droit d'accès en écriture. Comme le serveur est normalement démarré sous "root", vous ne devrez JAMAIS donner à quiconque le droit d'écriture sur ce répertoire de trace sauf si vous souhaitez lui attribuer les privilèges super utilisateur.

Server Side Includes

Les "Server side includes" (SSI) peuvent être configurés de telle sorte que les utilisateurs puissent exécuter des programmes arbitraires sur le serveur. Cette seule pensée glace d'horreur le moindre administrateur système.

L'une des solutions est de désactiver cette partie des SSI. Pour ce faire, vous pourrez utiliser l'option IncludesNOEXEC de la directive Options.

Absence d'aliasing pour les scripts CGI

La permission d'exécuter des scripts CGI dans n'importe quel répertoire de la machine ne devra être considérée que si :

vous avez la garantie que vos utilisateurs n'écriront pas des scripts qui exposeraient délibérément ou accidentellement votre système à une attaque.
vous considérez que la sécurité des autres zones de votre installation est suffisamment fiable pour qu'une sous protection du serveur ne puisse apparaître comme un trou de sécurité.
Vous n'avez pas d'utilisateurs, et personne ne visite votre serveur (!).

Aliasing pour les scripts CGI

Limiter l'exécution des CGI à quelques répertoires spécifiques permet de contrôler administrativement tout ce qui rentre dans ces répertoires. Ceci est indéniablement plus sûr que la méthode précédente, mais uniquement si les utilisateurs disposant du droit d'accès en écriture au répertoire considérés sont fiables et si l'administrateur teste chaque nouveau script ou programme CGI à la recherche de "cheval de troie".

La grande majorité des sites utilisent cette approche.

CGI en général

Rappelez-vous toujours que vous devrez vous fier à la compétence et au sérieux des développeurs de scripts CGI, à moins que vous en fassiez preuve d'une grande habileté à détecter des trous de sécurité potentiels dans le source des CGI, qu'ils soient accidentels, ou délibérés.

Tous les scripts CGI seront exécutés sous le même utilisateur, et il est donc possible qu'ils puissent entrer en conflit (délibérément ou accidentellement) avec d'autres scripts ex. L'utilisateur A a une grosse dent contre l'utilisateur B, et écrit un script qui efface la base de donnée du script (ou le script lui-même) de l'utilisateur B. Un programme peut être utilisé pour permettre l'exécution des scripts sous différents utilisateurs. Il s'agit de suEXEC, inclus dans la distribution 1.2 d'Apache et est appelé par des liens spéciaux du code du serveur Apache. Une autre méthode courant pour y arriver est l'utilisation de CGIWrap.

Bloquer des utilisateurs par surcharge des droits systèmes...

Pour contrôler de près votre plate-forme, vous souhaîterez interdire aux utilisateurs d'écrire leurs propres fichiers .htaccess qui pourraient contrer les principes de sécurité que vous avez mis en oeuvre. Voici une manière de le faire...

Dans le fichier de configuration serveur, inscrivez

<Directory /> AllowOverride None Options None allow from all </Directory>

puis réglez les droits explicitement pour chacun des répertoires particuliers

Ceci permet d'interdire toute surcharge, inclusions et accès dans tous les répertoires à l'exception de ceux qui auront été explicitement configurés autrement.

Protection des fichiers serveurs par défaut

Un des aspects d'Apache qui est parfois mal compris est le principe de l'attribution de droits d'accès par défaut. C'est-à-dire, à moins que vous ne preniez des mesures pour changer la situation, si le serveur peut trouver le chemin vers un fichier par l'application normale des règles d'écriture des URL, il ne peut refuser le document au client.

Par exemple, considérez les cas suivants :

# cd /; ln -s / public_html
Un accès à http://localhost/~root/

Ceci permettrait aux clients de naviguer dans l'ensemble du système de fichiers. Pour éviter ce risque, ajoutez le bloc suivant à votre fichier de configuration du serveur :

 <Directory />
     Order deny,allow
     Deny from all
 </Directory>

Ceci interdira par défaut l'accès à tout répertoire non "ouvert" explicitement. Vous ajouterez les blocs <Directory> appropriés pour "ouvrir" les zones que vous souhaîtez publiques. Par exemple,

 <Directory /usr/users/*/public_html>
     Order deny,allow
     Allow from all
 </Directory>
 <Directory /usr/local/httpd>
     Order deny,allow
     Allow from all
 </Directory>

Apportez une attention particulière aux interactions entre la directive <Location> et la directive <Directory> ; par exemple, même si un bloc <Directory /> interdit l'accès, une directive <Location /> peut outrepasser l'interdiction.

Prenez garde à ne pas trop jouer avec la directive UserDir ; lui donner une valeur de "./" aurait le même effet, vis à vis de la racine, que le premier exemple cité ci-avant. Si vous utilisez la version 1.3 d'Apache ou postérieure, nous vous conseillons vivement d'ajouter les lignes suivantes dans vos fichiers de configuration du serveur :

UserDir disabled root

Si vous avez des commentaires ou découvrez des autres astuces concernant la sécurité sous Apache, communiquez les directement à l'Apache Group (en anglais) en remplissant le formulaire problem report, ou en envoyant un courrier (en français si vous le souhaitez) à l'adresse ifdt@eisti.fr qui retransmettra

Apache HTTP Server Version 1.3