While some of the items in this chapter are related to the operating system Bugzilla is running on or some of the support software required to run Bugzilla, it is all related to protecting your data. This is not intended to be a comprehensive guide to securing Linux, Apache, MySQL, or any other piece of software mentioned. There is no substitute for active administration and monitoring of a machine. The key to good security is actually right in the middle of the word: U R It. While programmers in general always strive to write secure code, accidents can and do happen. The best approach to security is to always assume that the program you are working with isn't 100% secure and restrict its access to other parts of your machine as much as possible.

The TCP/IP standard defines more than 65,000 ports for sending and receiving traffic. Of those, Bugzilla needs exactly one to operate (different configurations and options may require up to 3). You should audit your server and make sure that you aren't listening on any ports you don't need to be. It's also highly recommended that the server Bugzilla resides on, along with any other machines you administer, be placed behind some kind of firewall.

Many daemons, such as Apache's httpd or MySQL's mysqld, run as either root or nobody. This is even worse on Windows machines where the majority of services run as SYSTEM. While running as root or SYSTEM introduces obvious security concerns, the problems introduced by running everything as nobody may not be so obvious. Basically, if you run every daemon as nobody and one of them gets comprimised it can comprimise every other daemon running as nobody on your machine. For this reason, it is recommended that you create a user account for each daemon. You will need to set the webservergroup option in localconfig to the group your webserver runs as. This will allow ./checksetup.pl to set file permissions on Unix systems so that nothing is world-writable.

If your system supports it, you may wish to consider running Bugzilla inside of a chroot jail. This option provides unpresidented security by restricting anything running inside the jail from accessing any information outside of it. If you wish to use this option, please consult the documentation that came with your system.

As mentioned in , the MySQL daemon should run as a non-privleged, unique user. Be sure to consult the MySQL documentation or the documentation that came with your system for instructions.

By default, MySQL comes with a root user with a blank password and an anonymous user, also with a blank password. In order to protect your data, the root user should be given a password and the anonymous user should be disabled. bash$ mysql mysql mysql> UPDATE user SET password = password('new_password') WHERE user = 'root'; mysql> FLUSH PRIVILEGES; bash$ mysql -u root -p mysql Enter Password: new_password mysql> DELETE FROM user WHERE user = ''; mysql> FLUSH PRIVILEGES; This command assumes that you have already completed .

If MySQL and your webserver both run on the same machine and you have no other reason to access MySQL remotely, then you should disable the network access. This, along with the suggestion in , will help protect your system from any remote vulnerabilites in MySQL. This is done using different methods in MySQL versions 3 and 4. Simply enter the following in /etc/my.conf: [myslqd] # Prevent network access to MySQL. skip-networking There's a bug in Bugzilla about this

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 a directory outside the webroot. See bug 44659 for more information. Bugzilla ships with the ability to create .htaccess files that enforce these rules. Instructions for enabling these directives in Apache can be found in 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 Be sure to test that data that should not be accessed remotely is properly blocked. Of particular intrest is the localconfig file which contains your database password. Also, be aware that many editors create temporary and backup files in the working directory and that those should also not be accessable. For more information, see bug 186383 or Bugtraq ID 6501. To test, simply point your web browser at the file; for example, to test mozilla.org's installation, we'd try to access . You should get a 403 Forbidden error. Be sure to check for instructions specific to the webserver you use.

This section only applies to people who have chosen the Apache webserver. It may be possible to do similar things with other webservers. Consult the documentation that came with your webserver to find out. It is possible for a user, by mistake or on purpose, to access the database many times in a row which can result in very slow access speeds for other users (effectively, a DOS attack). If your Bugzilla installation is experiencing this problem, you may install the Apache module mod_throttle which can limit connections by IP address. You may download this module at . Follow the instructions to install into your Apache install. The command you need is ThrottleClientIP. See the documentation for more information.

It is possible for a Bugzilla user to take advantage of character set encoding ambiguities to inject HTML into Bugzilla comments. This could include malicious scripts. Due to internationalization concerns, we are unable to incorporate by default the code changes suggested by the CERT advisory on this issue. If your installation is for an English speaking audience only, making the change in will prevent this problem. Locate the following line in Bugzilla/CGI.pm: $self->charset(''); and change it to: $self->charset('ISO-8859-1');