Bien que certains des éléments dans ce chapitre soient relatifs au système d'exploitation sur lequel est exécuté Bugzilla ou sur certains logiciels de support requis pour faire fonctionner Bugzilla, tout est lié à la protection de vos données. Ceci n'est pas destiné à être un guide exhaustif de sécurisation de Linux, Apache, MySQL ou toute autre partie logicielle mentionnée. Il n'y a pas de substitut à une administration et une surveillance actives d'une machine. La clé pour une bonne sécurité tient en fait en ces trois mots : c'est vous.
Bien que les programmeurs s'efforcent en général à écrire du code sûr, les accidents dpeuvent arriver et arrivent. La meilleure approche de sécurité consiste toujours à supposer que le programme sur lequel vous travaillez n'est pas sûr à 100 % et qu'il faut faut limiter son accès aux autres éléments de la machine autant que possible.
Le standard TCP/IP définit plus de 65000 ports pour l'envoi et la réception du trafic. Parmi ceux-ci, Bugzilla n'a besoin que d'un seul pour fonctionner (différentes configurations et options peuvent en nécessiter jusqu'à trois). Vous devez faire un audit sur votre serveur et vous assurez que vous n'êtes pas en train d'écouter des ports dont vous n'avez pas besoin. Il est aussi fortement recommandé que le serveur sur lequel se trouve Bugzilla, de même que toute autre machine que vous administrez, soient placés derrière un pare-feu.
Beaucoup de démons, tels que httpd d'Apache ou mysqld de MySQL fonctionnent en tant que root ou nobody. C'est encore pire sur les machines Windows où la majorité des services focntionne en tant que SYSTEM. L'exécution en root ou SYSTEM introduit des inquiétudes évidentes quant à la sécurité, les problèmes introduits par l'exécution de tout en tant que nobody peuvent ne pas être si évidents. Grossièrement, si vous exécutez tous les démons en tant que nobody et que l'un d'entre eux est compromis, il peut compromettre tout autre démon exécuté en tant que nobody sur votre machine. Pour cette raison, il est recommandé de créer un compte utilisateur par démon.
Note
Vous aurez besoin de définir l'option webservergroup dans le fichier localconfig pour le groupe avec lequel votre serveur Web s'exécute. Cela permettra au script ./checksetup.pl de définir les permissions de fichiers sur les systèmes Unix de sorte que rien ne soit accessible en écriture pour tout le monde.
Si votre système le gère, vous devriez considérer de faire fonctionner Bugzilla dans une prison chroot. Cette option fournit une sécurité sans précédent en empêchant tout ce qui s'exécute à l'intérieur de la prison d'accéder à toute information en dehors de celle-ci. Si vous souhaitez utiliser cette option, veuillez consulter la documentation livrée avec votre système.
Il y a beaucoup de fichiers placés dans le répertoire Bugzilla qui ne doivent pas être accessibles depuis le Web. À cause de la façon dont est actuellement structuré Bugzilla, la liste de ce qui doit ou ne doit pas être accessible est plutôt compliquée. Un moyen rapide est d'exécuter le script testserver.pl pour vérifier que votre serveur Web sert les pages de Bugzilla comme il le doit. Si ce n'est pas le cas, veuillez suivre les quelques étapes ci-dessous.
Note
Bugzilla sait créer des fichiers .htaccess qui appliquent ces règles. Les instructions pour activer ces directives dans Apache peuvent être consultées sur Bugzilla utilisant Apache
Assurez-vous que les données qui ne doivent pas être accédées à distance soient correctement bloquées. Accordez un intérêt particulier au fichier localconfig qui contient le mot de passe de votre base de données. Gardez à l'esprit que certains éditeurs créent des fichiers temporaires ou de sauvegarde dans le répertoire de travail et que ceux-ci ne doivent pas être accessibles non plus. Pour plus d'informations, consultez le bogue 186383 ou Bugtraq ID 6501. Pour tester, exécutez le script testserver.pl.
Note
Assurez-vous de consulter Le serveur Web pour les intructions spécifiques au serveur Web que vous utilisez.
Si vous avez installé Bugzilla version 2.22 ou une version ultérieure pour la première fois (pas une mise à jour à partir d'une ancienne installation), alors le paramètre utf8 est activé par défaut. Ceci permet à Bugzilla de définir explicitement l'encodage de caractères, suivant ainsi la a recommandation du CERT conseillant exactement cela. Ce qui suit par conséquent ne s'adresse pas à vous ; conservez seulement le paramètre utf8 activé.
Si vous avez fait une mise à jour à partir d'une ancienne version, il peut alors être possible pour un utilisateur de Bugzilla de tirer avantage del'ambiguïté de l'encodage de caractères pour injecter du code HTML dans les commentaires de Bugzilla. Ceci pourrait inclure du code malveillant. À cause des problèmes d'internationalisation, nous ne pouvons pas activer le paramètre utf8 sur des mises à jour d'installations. Activer ce paramètre manuellement empêchera ce problème de survenir.