46.6. Sécurité

Un serveur Web exposé à Internet nécessite des efforts d'administration incessants. Il est inévitable que des problèmes de sécurité surviennent, qu'ils soient liés aux logiciels ou à une erreur de configuration. Voici quelques conseils qui vous permettront de les gérer.

Mises à jour

Si des failles sont détectées dans le logiciel Apache, un avertissement de sécurité est diffusé par SUSE. Il contient des instructions permettant de corriger les failles, qui doivent être appliquées dès que possible. La liste de diffusion des annonces de sécurité de SUSE se trouve à l'adresse http://www.suse.com/us/private/support/online_help/mailinglists/. Les informations les plus récentes concernant les problèmes de sécurité des paquetages SUSE Linux sont également disponibles en ligne à l'adresse http://www.novell.com/linux/security/securitysupport.html.

En outre, nous vous conseillons de vous abonner à la liste de diffusion des annonces d'Apache (http://httpd.apache.org/lists.html#http-announce), dans laquelle des versions et des correctifs sont publiés.

Autorisations DocumentRoot

Par défaut dans SUSE Linux, le répertoire DocumentRoot /srv/www/htdocs et le répertoire CGI /srv/www/cgi-bin appartiennent à l'utilisateur root. Vous ne devez pas changer ces autorisations. Si tout le monde pouvait écrire dans les cépertoires, n'importe quel utilisateur pourrait y placer des fichiers. Ces fichiers pourraient ensuite être exécutés par Apache avec les autorisations wwwrun, qui peuvent donner à l'utilisateur un accès involontaire aux ressources du système de fichiers. Utilisez les sous-répertoires /srv/www/htdocs et /srv/www/cgi-bin pour organiser les données d'un utilisateur ou d'un domaine en combinaison avec la directive Directory (voir Répertoire).

Répertoires CGI et SSI

Les scripts interactifs en Perl, PHP, SSI ou n'importe quel autre langage de programmation peuvent surtout exécuter des commandes arbitraires. La limitation de l'exécution de CGI et de SSI (voir Section 46.5.1.2, « Common Gateway Interface : mod_cgi  », ScriptAlias et Section 46.5.1.1, « Inclusions côté serveur avec mod_include  ») à des répertoires spécifiques au lieu de les autoriser de façon globale est une option qui permet de réduire les risques.

Une autre possibilité consiste à utiliser mod_suexec (voir Section 46.5.2.1, « Exécution de CGI en tant qu'utilisateur différent avec mod_suexec  ») pour les CGI en général. Pour les modules Apache, une configuration tenant compte de la sécurité pour les interpréteurs, comme dans Section 46.5.3.2, « Service de PHP : mod_php4, mod_php5  », contribue à la conservation d'un environnement Web sécurisé.

Autorisations d'accès

Il est fréquent, en particulier dans les environnements de test, que les autorisations d'accès à un serveur Web soient gérées avec désinvolture du fait de la nature de test d'une configuration. Ceci peut se traduire par le dévoilement accidentel d'informations sensibles, voire par l'exposition d'un serveur entier à un public qui ne devrait pas y accéder. Utilisez la directive Order (http://httpd.apache.org/docs-2.0/mod/mod_access.html#order) en combinaison avec des fichiers .htaccess (voir Section 46.3.2.3.3, « noms de fichier AccessFileName  ») pour restreindre l'accès à certains sites Web à des utilisateurs ou à des clients spécifiques.

Vous pouvez également utiliser l'approche « sécurité par obscurcissement ». Un exemple classique consiste à exécuter Apache sur un port non standard (voir Sélection du périphérique réseau). Ceci se traduit par l'ajout du port aux URL, par exemple http://www.example.com:8765, ce qui est acceptable dans des environnements de test.