Sécurité du serveur
La sécurisation d’un serveur à de nombreux aspects, mais les points suivants sont un bon point de départ. Ils doivent être contrôlés régulièrement et par quelqu’un d’autre que l’administrateur système habituel : deux paires d’yeux valent mieux qu’une pour trouver les problèmes et un contrôle indépendant, fait par quelqu’un de compétent, accroît la confiance.
Mot de passe root
Le mot de passe root de votre serveur est la charnière de votre sécurité. Ne laissez personne l’inscrire sur un papier cloué au mur ou collé sur leur écran, ou le trahir d’une façon ou d’une autre.
Emplacements et appartenance des fichiers
La sécurité des fichiers est un point essentiel de la sécurité d’un serveur web. Voici les règles à observer quant aux emplacements et aux appartenances des fichiers :
- Les fichiers ne devraient pas appartenir aux utilisateurs qui exécutent des services (http, ftpd, sendmail, ...) -- chaque service devrait avoir son propre utilisateur. Dans une situation idéale, l’appartenance des fichiers et des services devraient être aussi cloisonnées que possible : le compte sous lequel s’exécute Apache, par exemple, ne devrait pas être le même que celui qui possède les fichiers de configuration. Ce cloisonnement empêche le serveur de modifier sa propre configuration, même si quelqu’un à réussit à en prendre le contrôle. Chaque service devrait également avoir son propre compte, afin que les attaques utilisant plusieurs services soient rendues plus difficiles (avec des comptes différents, il est probable que les fichiers capturés à l’aide d’un serveur ne pourront être accessibles par un autre, par exemple). Ainsi, Qmail, un serveur de courrier sécurisé, n’utilise pas moins de six comptes différents pour les différentes parties de son service, et ses fichiers de configuration appartiennent encore à un autre utilisateur, généralement root.
- Les services ne devraient pas partager des arborescences de fichiers.
- Ne placez pas de fichiers exécutables dans l’arborescence de vos documents web, c’est-à-dire dans ou au-dessous du DocumentRoot d’Apache.
- Ne placez pas les fichiers de configuration des services dans l’arborescence de vos documents web, de votre site ftp ou à tout autre endroit accessible à distance.
- L’idéal consiste à lancer chaque service sur une machine différente.
Concernant les permissions de fichiers, voici les règles à respecter :
- Si les fichiers appartiennent à quelqu’un d’autre, vous devez donner la permission de lecture au groupe contenant le service concerné. De même, vous devez donner le droit d’exécution pour les fichiers exécutables. Les binaires exécutables n’ont pas besoin d’être accessibles en lecture, à la différence des scripts qui doivent pouvoir être lus pour être exécutés. Essayez toujours de limiter au maximum les permissions -- n’autorisez pas le serveur à modifier ses fichiers de configuration, par exemple.
- Dans la procédure de mise à jour (voir plus loin), réalisez des scripts qui configureront les permissions et les propriétaires des fichiers, cela permettra d’éviter des erreurs.
Site web d’Apache
Le site d’Apache donne quelques trucs et astuces sur les problèmes de sécurité que l’on est susceptible de rencontrer lorsque l’on installe un serveur web. Certains de ces conseils sont généraux, d’autres sont spécifiques à Apache.
Permissions sur les répertoires ServerRoot
Généralement, Apache est lancé sous le compte root, puis il passe sous le compte de l’utilisateur défini par la directive User pour répondre aux requêtes. Comme pour toute commande exécutée par root, vous devez vérifier qu’il est protégé de toute modification par les utilisateurs non root : non seulement les fichiers eux-mêmes ne doivent être modifiables que par root, mais c’est également le cas pour les répertoires et leus répertoires parents. Si vous choisissez, par exemple, de placer ServerRoot dans /usr/local/apache, il est conseillé de créer ce répertoire en tant que root avec des commandes comme celles-ci :
mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs
On suppose ici que /, /usr et /usr/local, ne sont modifiable que par root. Lorsque vous installez l’exécutable httpd, vous devez vous assurez qu’il est protégé de la même façon :
cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd
Vous pouvez créer un sous-répertoire htdocs modifiable par d’autres utilisateurs -- root n’exécute jamais de fichiers à cet endroit et ne devrait rien y créer.
Si vous autorisez les utilisateurs non root à modifier un fichier qui s’exécute sous le compte root ou dans lequel celui-ci écrit, vous ouvrez votre système à des attaques très dangereuses. Quelqu’un pourrait, par exemple, remplacer le binaire httpd pour que, la prochaine fois que vous le lancez, il exécute un code quelconque. Si un utilisateur non root peut écrire dans le répertoire des logs, il peut remplacer un fichier log par un lien symbolique vers un autre fichier système qui sera écrasé par les logs du serveur. Si les fichiers logs eux-mêmes sont accessibles en écriture par n’importe qui, ils peuvent être remplis de données fausses.
Server-side includes
SSI (Server-side includes) peut être configuré pour que les utilisateurs puissent exécuter n’importe quel programme sur le serveur. Cette seule pensée devrait faire frissonner n’importe quel administrateur système.
Une solution possible consiste à désactiver cette partie de SSI en utilisant l’option IncludesNOEXEC de la directive Options.
CGI sans ScriptAlias
Les utilisateurs ne doivent pouvoir exécuter des scripts CGI placés dans un répertoire quelconque que si :
- Vous êtes sûr que vos utilisateurs n’écriront pas de scripts qui exposeront, volontairement ou non, votre système à une attaque.
- Vous considérez que la sécurité de votre site est si faible par ailleurs qu’un trou de plus n’a aucune importance.
- Vous n’avez aucun utilisateur et jamais personne ne visite votre site.
CGI avec ScriptAlias
Limiter les CGI à des répertoires particuliers permet à l’administrateur système de contrôler ce qui est placé dans ces répertoires. C’est évidemment plus sûr que de permettre l’exécution de ces scripts n’importe où, mais uniquement si les utilisateurs qui ont le droit d’écrire dans ces répertoires sont dignes de confiance ou si l’administrateur système accepte de tester chaque nouveau script/programme CGI pour y rechercher des trous de sécurité potentiels.
La plupart des sites préfèrent cette configuration à celle donnant une totale liberté aux scripts CGI.
CGI en général
N’oubliez jamais que vous devez faire confiance aux concepteurs des scripts/programmes CGI, ou vous devrez prendre en charge la détection de leurs trous de sécurités potentiels, qu’ils soient volontaires ou non.
Tous les scripts CGI s’exécuteront sous le même compte : ils peuvent donc entrer en conflit (accidentellement ou volontairement) avec d’autres scripts. Si, par exemple, l’utilisateur A hait l’utilisateur B, il peut écrire un script pour détruire la base de données CGI de ce dernier. Il existe un programme permettant aux scripts de s’exécuter sous des comptes différents : suEXEC fait partie de la distribution Apache depuis la version 1.2 et il est appelé à partir de différents endroits du code du serveur. Un autre moyen consiste à utiliser CGIWrap.
Empêcher les utilisateurs d’outrepasser la configuration du serveur...
Pour disposer d’un vaisseau vraiment sécurisé, vous devrez empêcher les utilisateurs de créer des fichiers .htaccess qui pourraient outrepasser les mesures de sécurité que vous avez mises en place. Un moyen de le faire est d’ajouter les lignes suivantes dans le fichier de configuration du serveur :
<Directory />
AllowOverride None
Options None
Allow from all
</Directory>
puis de créer des conteneurs pour des répertoires spécifiques. Cela empêchera toutes les surcharges, les inclusions et les accès dans tous les répertoires, sauf dans ceux que vous aurez explicitement indiqués.
Protéger par défaut les fichiers du serveur
L’un des aspects d’Apache, qui est parfois mal compris, est l’accès par défaut. À moins que vous ne modifiez ce comportement, si le serveur peut trouver un fichier en utilisant les règles classiques de transformation des URL, il peut le fournir à ses clients. Considérons l’exemple suivant :
- # ln -s / /root/public_html
- Si l’on accède au serveur par l’URL http://localhost/~root/, si Apache est configuré pour servir les répertoires utilisateurs et que l’option SymlinkIfOwnerMatch est activée, cela permet de se promener dans tout le système de fichiers. Pour éviter cela, ajoutez le conteneur suivant à la configuration du serveur :
<Directory />
Order Deny,Allow
Deny from all
</Directory>
Cela interdira l’accès par défaut au différentes parties du système de fichiers. Ajoutez des conteneurs <Directory> spécifiques pour n’autoriser l’accès qu’aux zones que vous souhaitez. Par exemple :
<Directory /home/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>
Faites spécialement attention aux interactions entre les directives <Location> et <Directory> : même si <Directory /> interdit l’accès, par exemple, une directive <Location /> peut le contourner.
Faites également attention lorsque vous jouez avec la directive UserDir : la configurer avec une valeur comme ./ aurait le même effet, pour root, que le premier exemple que nous avons donné. Si vous utilisez Apache 1.3 ou une version supérieure, nous vous conseillons fortement d’inclure la ligne suivante dans le fichier de configuration de votre serveur :
UserDir disabled root
Envoyez toutes vos astuces utiles concernant la sécurité à l’Apache Group, en lui expédiant un rapport de bogue. Si vous pensez avoir trouvé un trou de sécurité dans le code source d’Apache, faites-nous le savoir.