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