Conseils sur la s�curit�

Maintenez votre serveur � jour

Le serveur HTTP Apache a une bonne r�putation en mati�re de s�curit� et poss�de une communaut� de d�veloppeurs tr�s sensibilis�s aux probl�mes de s�curit�. Mais il est in�vitable de trouver certains probl�mes -- petits ou grands -- une fois le logiciel mis � disposition. C'est pour cette raison qu'il est crucial de se tenir inform� des mises � jour. Si vous avez obtenu votre version du serveur HTTP directement depuis Apache, nous vous conseillons grandement de vous abonner � la Liste de diffusion des annonces du serveur HTTP qui vous informera de la parution des nouvelles versions et des mises � jour de s�curit�. La plupart des distributeurs tiers d'Apache fournissent des services similaires.

Gardez cependant � l'esprit que lorsqu'un serveur web est compromis, le code du serveur HTTP n'est la plupart du temps pas en cause. Les probl�mes proviennent plut�t de code ajout�, de scripts CGI, ou du syst�me d'exploitation sous-jacent. Vous devez donc vous tenir inform� des probl�mes et mises � jour concernant tous les logiciels pr�sents sur votre syst�me.

Attaques de type "D�ni de service" (Denial of Service - DoS)

Tous les services r�seau peuvent faire l'objet d'attaques de type "D�ni de service" qui tentent de les emp�cher de r�pondre aux clients en saturant leurs ressources. Il est impossible de se pr�munir totalement contre ce type d'attaques, mais vous pouvez accomplir certaines actions afin de minimiser les probl�mes qu'elles cr�ent.

Souvent, l'outil anti-DoS le plus efficace sera constitu� par le pare-feu ou certaines configurations du syst�me d'exploitation. Par exemple, la plupart des pare-feu peuvent �tre configur�s de fa�on � limiter le nombre de connexions simultan�es depuis une adresse IP ou un r�seau, ce qui permet de pr�venir toute une gamme d'attaques simples. Bien s�r, ceci n'est d'aucun secours contre les attaques de type "D�ni de service" distribu�es (DDoS).

Certains r�glages de la configuration d'Apache peuvent aussi minimiser les probl�mes :

• La directive RequestReadTimeout permet de limiter le temps que met le client pour envoyer sa requ�te.
• La valeur de la directive TimeOut doit �tre diminu�e sur les sites sujets aux attaques DoS. Une valeur de quelques secondes devrait convenir. Cependant, comme TimeOut est actuellement concern� par de nombreuses op�rations diff�rentes, lui attribuer une valeur trop faible peut provoquer des probl�mes avec les scripts CGI qui pr�sentent un long temps de r�ponse.
• La valeur de la directive KeepAliveTimeout doit aussi �tre diminu�e sur les sites sujets aux attaques DoS. Certains sites d�sactivent m�me compl�tement le "maintien en vie" (keepalives) � l'aide de la directive KeepAlive, ce qui bien s�r pr�sente des inconv�nients en mati�re de performances.
• Les valeurs des diff�rentes directives fournies par d'autres modules et en rapport avec des d�lais doivent aussi �tre v�rifi�es.
• Les directives LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, et LimitXMLRequestBody doivent �tre configur�es avec prudence afin de limiter la consommation de ressources induite par les demandes des clients.
• Sur les syst�mes d'exploitation qui le supportent, assurez-vous que la directive AcceptFilter est activ�e afin de d�l�guer une partie du traitement des requ�tes au syst�me d'exploitation. Elle est activ�e par d�faut dans le d�mon httpd d'Apache, mais peut n�cessiter une reconfiguration de votre noyau.
• Optimisez la directive MaxRequestWorkers de fa�on � d�finir le nombre maximum de connexions simultan�es au dessus duquel les ressources s'�puisent. Voir aussi la documentation sur l'optimisation des performances.
• L'utilisation d'un module mpm thread� vous permet de traiter d'avantage de connexions simultan�es, ce qui minimise l'effet des attaques DoS. Dans le futur, le module mpm event utilisera un traitement asynchrone afin de ne pas d�dier un thread � chaque connexion. De par la nature de la biblioth�que OpenSSL, le module mpm event est actuellement incompatible avec le module mod_ssl ainsi que d'autres filtres en entr�e. Dans ces cas, son comportement se ram�ne � celui du module mpm worker.
• Il existe de nombreux modules tiers disponibles � http://modules.apache.org/ qui peuvent retreindre les comportements de certains clients et ainsi minimiser les probl�mes de DoS.

Permissions sur les r�pertoires de la racine du serveur

Typiquement, Apache est d�marr� par l'utilisateur root, puis il devient la propri�t� de l'utilisateur d�fini par la directive User afin de r�pondre aux demandes. Comme pour toutes les commandes ex�cut�es par root, vous devez vous assurer qu'elle n'est pas modifiable par les utilisateurs autres que root. Les fichiers eux-m�mes, mais aussi les r�pertoires ainsi que leurs parents ne doivent �tre modifiables que par root. Par exemple, si vous avez choisi de placer la racine du serveur dans /usr/local/apache, il est conseill� de cr�er le r�pertoire en tant que root, avec des commandes du style :

Nous supposerons que /, /usr et /usr/local ne sont modifiables que par root. Quand vous installez l'ex�cutable httpd, vous devez vous assurer qu'il poss�de des protections similaires :

Vous pouvez cr�er un sous-r�pertoire htdocs modifiable par d'autres utilisateurs -- car root ne cr�e ni ex�cute aucun fichier dans ce sous-r�pertoire.

Si vous permettez � des utilisateurs non root de modifier des fichiers que root �crit ou ex�cute, vous exposez votre syst�me � une compromission de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire httpd de fa�on � ce que la prochaine fois que vous le red�marrerez, il ex�cutera un code arbitraire. Si le r�pertoire des journaux a les droits en �criture (pour un utilisateur non root), quelqu'un pourrait remplacer un fichier journal par un lien symbolique vers un autre fichier syst�me, et root pourrait alors �craser ce fichier avec des donn�es arbitraires. Si les fichiers journaux eux-m�mes ont des droits en �criture (pour un utilisateur non root), quelqu'un pourrait modifier les journaux eux-m�mes avec des donn�es fausses.

Inclusions c�t� serveur

Les inclusions c�t� serveur (Server Side Includes - SSI) exposent l'administrateur du serveur � de nombreux risques potentiels en mati�re de s�curit�.

Le premier risque est l'augmentation de la charge du serveur. Tous les fichiers o� SSI est activ� doivent �tre analys�s par Apache, qu'ils contiennent des directives SSI ou non. L'augmentation de la charge induite est minime, mais peut devenir significative dans le contexte d'un serveur partag�.

Les fichiers SSI pr�sentent les m�mes risques que les scripts CGI en g�n�ral. Les fichiers o� SSI est activ� peuvent ex�cuter tout script CGI ou autre programme � l'aide de la commande "exec cmd" avec les permissions des utilisateur et groupe sous lesquels Apache s'ex�cute, comme d�fini dans apache2.conf.

Des m�thodes existent pour am�liorer la s�curit� des fichiers SSI, tout en tirant parti des b�n�fices qu'ils apportent.

Pour limiter les dommages qu'un fichier SSI agressif pourrait causer, l'administrateur du serveur peut activersuexec comme d�crit dans la section Les CGI en g�n�ral.

L'activation des SSI pour des fichiers poss�dant des extensions .html ou .htm peut s'av�rer dangereux. Ceci est particuli�rement vrai dans un environnement de serveur partag� ou �tant le si�ge d'un traffic �lev�. Les fichiers o� SSI est activ� doivent poss�der une extension sp�cifique, telle que la conventionnelle .shtml. Ceci permet de limiter la charge du serveur � un niveau minimum et de simplifier la gestion des risques.

Une autre solution consiste � interdire l'ex�cution de scripts et programmes � partir de pages SSI. Pour ce faire, remplacez Includes par IncludesNOEXEC dans la directive Options. Notez que les utilisateurs pourront encore utiliser <--#include virtual="..." --> pour ex�cuter des scripts CGI si ces scripts sont situ�s dans des r�pertoires sp�cifi�s par une directive ScriptAlias.

Les CGI en g�n�ral

Tout d'abord, vous devez toujours garder � l'esprit que vous devez faire confiance aux d�veloppeurs de scripts ou programmes CGI ainsi qu'� vos comp�tences pour d�celer les trous de s�curit� potentiels dans les CGI, que ceux-ci soient d�lib�r�s ou accidentels. Les scripts CGI peuvent essentiellement ex�cuter des commandes arbitraires sur votre syst�me avec les droits de l'utilisateur du serveur web, et peuvent par cons�quent �tre extr�mement dangereux s'ils ne sont pas v�rifi�s avec soin.

Tous les scripts CGI s'ex�cutent sous le m�me utilisateur, il peuvent donc entrer en conflit (accidentellement ou d�lib�r�ment) avec d'autres scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il �crit donc un script qui efface la base de donn�es CGI de l'utilisateur B. Vous pouvez utiliser le programme suEXEC pour faire en sorte que les scripts s'ex�cutent sous des utilisateurs diff�rents. Ce programme est inclus dans la distribution d'Apache depuis la version 1.2 et est appel� � partir de certaines portions de code du serveur Apache. Une autre m�thode plus connue est l'utilisation de CGIWrap.

CGI sans alias de script

Vous ne devez permettre aux utilisateurs d'ex�cuter des scripts CGI depuis n'importe quel r�pertoire que dans l'�ventualit� o� :

• Vous faites confiance � vos utilisateurs pour ne pas �crire de scripts qui vont d�lib�r�ment ou accidentellement exposer votre syst�me � une attaque.
• Vous estimez que le niveau de s�curit� dans les autres parties de votre site est si faible qu'un trou de s�curit� de plus ou de moins n'est pas tr�s important.
• Votre syst�me ne comporte aucun utilisateur, et personne ne visite jamais votre site.

CGI avec alias de script

Le confinement des CGI dans des r�pertoires sp�cifiques permet � l'administrateur de contr�ler ce que l'on met dans ces r�pertoires. Ceci est bien entendu mieux s�curis� que les CGI sans alias de script, mais seulement � condition que les utilisateurs avec les droits en �criture sur les r�pertoires soient dignes de confiance, et que l'administrateur ait la volont� de tester chaque programme ou script CGI � la recherche d'�ventuels trous de s�curit�.

La plupart des sites choisissent cette approche au d�triment des CGI sans alias de script.

Autres sources de contenu dynamique

Les options de scripting int�gr�es qui s'ex�cutent en tant que partie du serveur lui-m�me, comme mod_php, mod_perl, mod_tcl, et mod_python, s'ex�cutent sous le m�me utilisateur que le serveur (voir la directive User), et par cons�quent, les scripts que ces moteurs ex�cutent peuvent acc�der aux m�mes ressources que le serveur. Certains moteurs de scripting peuvent proposer des restrictions, mais pour plus de s�ret�, il vaut mieux partir du principe que ce n'est pas le cas.

Protection de la configuration du syst�me

Pour contr�ler �troitement votre serveur, vous pouvez interdire l'utilisation des fichiers .htaccess qui permettent de passer outre les fonctionnalit�s de s�curit� que vous avez configur�es. Voici un moyen pour y parvenir :

Ajoutez dans le fichier de configuration du serveur

<Directory "/">
    AllowOverride None
</Directory>

Ceci interdit l'utilisation des fichiers .htaccess dans tous les r�pertoires, sauf ceux pour lesquels c'est explicitement autoris�.

Notez que c'est la configuration par d�faut depuis Apache 2.3.9.

Protection par d�faut des fichiers du serveur

Le concept d'acc�s par d�faut est un aspect d'Apache qui est parfois mal compris. C'est � dire que, � moins que vous ne changiez explicitement ce comportement, si le serveur trouve son chemin vers un fichier en suivant les r�gles normales de correspondance URL - fichier, il peut le retourner aux clients.

Consid�rons l'exemple suivant :

Ceci permettrait aux clients de parcourir l'ensemble du syst�me de fichiers. Pour l'�viter, ajoutez le bloc suivant � la configuration de votre serveur :

<Directory "/">
    Require all denied
</Directory>

ceci va interdire l'acc�s par d�faut � tous les fichiers du syst�me de fichiers. Vous devrez ensuite ajouter les blocs Directory appropri�s correspondant aux r�pertoires auxquels vous voulez autorisez l'acc�s. Par exemple,

<Directory "/usr/users/*/public_html">
    Require all granted
</Directory>
<Directory "/usr/local/httpd">
    Require all granted
</Directory>

Portez une attention particuli�re aux interactions entre les directives Location et Directory ; par exemple, si une directive <Directory ""/> interdit un acc�s, une directive <Location "/"> pourra passer outre.

De m�me, soyez m�fiant en jouant avec la directive UserDir ; la positionner � "./" aurait le m�me effet, pour root, que le premier exemple plus haut. Nous vous conseillons fortement d'inclure la ligne suivante dans le fichier de configuration de votre serveur :

UserDir disabled root

Surveillez vos journaux

Pour vous tenir inform� de ce qui se passe r�ellement dans votre serveur, vous devez consulter vos fichiers journaux. M�me si les fichiers journaux ne consignent que des �v�nements qui se sont d�j� produits, ils vous informeront sur la nature des attaques qui sont lanc�es contre le serveur et vous permettront de v�rifier si le niveau de s�curit� n�cessaire est atteint.

Quelques exemples :

Le premier exemple listera les attaques essayant d'exploiter la vuln�rabilit� d'Apache Tomcat pouvant provoquer la divulgation d'informations par des requ�tes Source.JSP mal form�es, le second donnera la liste des dix derni�res interdictions client ; par exemple :

Comme vous le voyez, les fichiers journaux ne consignent que ce qui s'est d�j� produit ; ainsi, si le client a pu acc�der au fichier .htpasswd, vous devriez avoir quelque chose du style :

dans votre journal des acc�s ; ce qui signifie que vous avez probablement mis en commentaire ce qui suit dans le fichier de configuration de votre serveur :

<Files ".ht*">
    Require all denied
</Files>

Fusion des sections de configuration

La fusion des sections de configuration est complexe et d�pend souvent des directives utilis�es. Vous devez syst�matiquement tester vos modifications pour v�rifier la mani�re dont les directives sont fusionn�es.

Concernant les modules qui n'impl�mentent aucune logique de fusion, comme mod_access_compat, le comportement des sections suivantes est tributaire de la pr�sence dans ces derni�res de directives appartenant � ces modules. La configuration est h�rit�e jusqu'� ce qu'une modification soit effectu�e ; � ce moment, la configuration est remplac�e et non fusionn�e.