From 6c709dd097e65025038a0dc9c17fad6a88e99b6b Mon Sep 17 00:00:00 2001 From: "gerv%gerv.net" <> Date: Sun, 25 Jan 2004 02:30:57 +0000 Subject: Massive rearrangement of the installation section. Hopefully it makes sense now. --- docs/html/security.html | 686 ------------------------------------------------ 1 file changed, 686 deletions(-) delete mode 100644 docs/html/security.html (limited to 'docs/html/security.html') diff --git a/docs/html/security.html b/docs/html/security.html deleted file mode 100644 index 4bf56506e..000000000 --- a/docs/html/security.html +++ /dev/null @@ -1,686 +0,0 @@ -
Poorly-configured MySQL and Bugzilla installations have - given attackers full access to systems in the past. Please take these - guidelines seriously, even for Bugzilla machines hidden away behind - your firewall. 80% of all computer trespassers are insiders, not - anonymous crackers. This is not meant to be a comprehensive list of every possible - security issue pertaining to the software mentioned in this section. - There is - no subsitute for reading the information written by the authors of any - software running on your system. - |
TCP/IP defines 65,000 some ports for trafic. Of those, Bugzilla - only needs 1, or 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. -
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. -
Consult the documentation that came with your system for - information on making mysqld run as an - unprivleged user. -
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. -
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 - |
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. -
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 compromised, they all get - compromised. 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. - |
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 laid out, the list of what should and should - not be accessible is rather complicated. -
Users of Apache don't need to worry about this, however, because - Bugzilla ships with .htaccess files which restrict access to all the - sensitive files in this section. Users of other webservers, read on. -
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
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.2 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. - |