Serveur Apache HTTP Version 2.3
+
Conseils sur la sécurité
+ + +Ce document propose quelques conseils et astuces concernant les + problèmes de sécurité liés + à l'installation d'un serveur web. Certaines suggestions seront à caractère + général, tandis que d'autres seront spécifiques à Apache.
+
Maintenez votre serveur à jour
+- Attaques de type "Déni de service"
+ (Denial of Service - DoS)
+
- Permissions sur les répertoires de la racine du serveur
+
- Inclusions côté serveur
+
- Les CGI en général
+
- CGI sans alias de script
+
- CGI avec alias de script
+
- Autres sources de contenu dynamique
+
- Protection de la configuration du système
+
- Protection par défaut des fichiers du serveur
+
- Surveillez vos journaux
+
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 valeur de la directive
+
TimeOutdoit être diminuée sur les + sites sujets aux attaques DoS. Une valeur de quelques secondes devrait + convenir. Cependant, commeTimeOut+ 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
+
KeepAliveTimeoutdoit 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 +LimitXMLRequestBodydoivent ê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
AcceptFilterest + 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
MaxClientsde 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 expérimental
+
eventutilisera un traitement asynchrone afin de ne pas + dédier un thread à chaque connexion. Il est en cours d'étude à + l'heure actuelle et n'est pas encore entièrement implémenté. En + particulier, le mpmeventest actuellement incompatible + avec le modulemod_sslainsi que d'autres filtres + en entrée.
+
+ - 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 :
+ 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
+
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 :
+ 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 -- 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 httpd.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é.
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 :
+ +
+ # cd /; ln -s / public_html
+ puis accès à http://localhost/~root/
+
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 />
+ Order Deny,Allow
+ Deny from all
+ </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>
+ Order Deny,Allow
+ Allow from all
+ </Directory>
+ <Directory /usr/local/httpd>
+ Order Deny,Allow
+ Allow from all
+ </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.
+ Si vous utilisez Apache version 1.3 ou supérieure, 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 :
+ +
+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10
+
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 :
+ +
+ [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
+ by server configuration: /usr/local/apache/htdocs/.htpasswd
+
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 :
+ foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
+
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">
+ Order allow,deny
+ Deny from all
+ </Files>
+
Ce document propose quelques conseils et astuces concernant les + problèmes de sécurité liés + à l'installation d'un serveur web. Certaines suggestions seront à caractère + général, tandis que d'autres seront spécifiques à Apache.
+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.
+ +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 valeur de la directive
+
TimeOut doit être diminuée sur les + sites sujets aux attaques DoS. Une valeur de quelques secondes devrait + convenir. Cependant, commeTimeOut + 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
MaxClients 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 expérimental
+
event utilisera un traitement asynchrone afin de ne pas + dédier un thread à chaque connexion. Il est en cours d'étude à + l'heure actuelle et n'est pas encore entièrement implémenté. En + particulier, le mpmevent est actuellement incompatible + avec le modulemod_ssl ainsi que d'autres filtres + en entrée.
+
+ - 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. + +
Typiquement, Apache est démarré par l'utilisateur root, puis il devient
+ la propriété de l'utilisateur défini par la directive /usr/local/apache, il est conseillé de
+ créer le répertoire en tant que root, avec des commandes du style :
+ cd /usr/local/apache
+ mkdir bin conf logs
+ chown 0 . bin conf logs
+ chgrp 0 . bin conf logs
+ chmod 755 . bin conf logs +
Nous supposerons que /, /usr et
+ /usr/local ne sont modifiables que par
+ root. Quand vous installez l'exécutable
+ 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 -- 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
+
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 httpd.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
+ <--#include virtual="..." --> pour exécuter
+ des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
+ par une directive
+
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.
+ +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. +
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.
+ +
+ 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
+
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
+ ++ AllowOverride None
+ </Directory> +
Ceci interdit l'utilisation des fichiers .htaccess dans
+ tous les répertoires, sauf ceux pour lesquels c'est explicitement
+ autorisé.
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 :
+ ++ puis accès à
http://localhost/~root/
+ 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 :
+ ++ Order Deny,Allow
+ Deny from all
+ </Directory> +
ceci va interdire l'accès par défaut à tous les fichiers du système de
+ fichiers. Vous devrez ensuite ajouter les blocs
+
+ Order Deny,Allow
+ Allow from all
+ </Directory>
+ <Directory /usr/local/httpd>
+ Order Deny,Allow
+ Allow from all
+ </Directory> +
Portez une attention particulière aux interactions entre les directives
+ <Directory /> interdit un accès, une
+ directive <Location /> pourra passer outre.
De même, soyez méfiant en jouant avec la directive
+ "./" aurait le même effet, pour root, que le premier exemple plus haut.
+ Si vous utilisez Apache version 1.3 ou supérieure, nous vous conseillons
+ fortement d'inclure la ligne suivante dans le fichier de configuration de
+ votre serveur :
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 :
+ ++ grep "client denied" error_log | tail -n 10 +
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 :
+ ++ Order allow,deny
+ Deny from all
+ </Files> +