5.6. Bugzilla Security

5.6.1. TCP/IP Ports

TCP/IP defines 65,000 some ports for trafic. Of those, Bugzilla only needs 1... 2 if you need to use features that require e-mail such as bug moving or the e-mail interface from contrib. You should audit your server and make sure that you aren't listening on any ports you don't need to be. You may also wish to use some kind of firewall software to be sure that trafic can only be recieved on ports you specify.

5.6.2. MySQL

MySQL ships by default with many settings that should be changed. By defaults it allows anybody to connect from localhost without a password and have full administrative capabilities. It also defaults to not have a root password (this is not the same as the system root). Also, many installations default to running mysqld as the system root.

1. Consult the documentation that came with your system for information on making mysqld run as an unprivleged user.

2. You should also be sure to disable the anonymous user account and set a password for the root user. This is accomplished using the following commands:

   bash$ mysql mysql mysql> DELETE FROM user WHERE user = ''; mysql> UPDATE user SET password = password('new_password') WHERE user = 'root'; mysql> FLUSH PRIVILEGES;

   From this point forward you will need to use mysql -u root -p and enter new_password when prompted when using the mysql client.

3. If you run MySQL on the same machine as your httpd server, you should consider disabling networking from within MySQL by adding the following to your /etc/my.conf:

   [myslqd] # Prevent network access to MySQL. skip-networking

4. You may also consider running MySQL, or even all of Bugzilla in a chroot jail; however, instructions for doing that are beyond the scope of this document.

5.6.3. Daemon Accounts

Many daemons, such as Apache's httpd and MySQL's mysqld default to running as either "root" or "nobody". Running as "root" introduces obvious security problems, but the problems introduced by running everything as "nobody" may not be so obvious. Basically, if you're running every daemon as "nobody" and one of them gets comprimised, they all get comprimised. For this reason it is recommended that you create a user account for each daemon.

You will need to set the webservergroup to the group you created for your webserver to run as in localconfig. This will allow ./checksetup.pl to better adjust the file permissions on your Bugzilla install so as to not require making anything world-writable.

5.6.4. Web Server Access Controls

There are many files that are placed in the Bugzilla directory area that should not be accessable from the web. Because of the way Bugzilla is currently layed out, the list of what should and should not be accessible is rather complicated. A new installation method is currently in the works which should solve this by allowing files that shouldn't be accessible from the web to be placed in directory outside the webroot. See bug 44659 for more information.

• In the main Bugzilla directory, you should:

  • Block: *.pl, *localconfig*, runtests.sh

  • But allow: localconfig.js, localconfig.rdf

• In data:

  • Block everything

  • But allow: duplicates.rdf

• In data/webdot:

  • If you use a remote webdot server:

    • Block everything

    • But allow *.dot only for the remote webdot server

  • Otherwise, if you use a local GraphViz:

    • Block everything

    • But allow: *.png, *.gif, *.jpg, *.map

  • And if you don't use any dot:

    • Block everything

• In Bugzilla:

  • Block everything

• In template:

  • Block everything

Bugzilla ships with the ability to generate .htaccess files instructing Apache which files should and should not be accessible. For more information, see Section 4.4.1.

You should test to make sure that the files mentioned above are not accessible from the Internet, especially your localconfig file which contains your database password. To test, simply point your web browser at the file; for example, to test mozilla.org's installation, we'd try to access http://bugzilla.mozilla.org/localconfig. You should get a 403 Forbidden error.

Not following the instructions in this section, including testing, may result in sensitive information being globally accessible.

You should check Section 4.4 to see if instructions have been included for your web server. You should also compare those instructions with this list to make sure everything is properly accounted for.