Dev -> 4.0.6. Clean upgrade from 4.0.5-5.
[usit-rt.git] / docs / security.pod
CommitLineData
84fb5b46
MKG
1=head1 RT Security
2
3=head2 Reporting security vulnerabilities in RT
4
5If you believe you've discovered a security issue in RT, please send an
6email to <security@bestpractical.com> with a detailed description of the
7issue, and a secure means to respond to you (such as your PGP public
8key).
9
10More information is available at L<http://bestpractical.com/security/>.
11
b5747ff2
MKG
12
13=head2 RT's security process
14
15After a security vulnerability is reported to Best Practical and
16verified, we attempt to resolve it in as timely a fashion as possible.
17Best Practical support customers will be notified before we disclose the
18information to the public. All security announcements will be sent to
19C<rt-announce@bestpractical.com>, which includes
20C<rt-users@bestpractical.com> and C<rt-devel@bestpractical.com>.
21
22As the tests for security vulnerabilities are often nearly identical to
23working exploits, sensitive tests will be embargoed for a period of six
24months before being added to the public RT repository.
25
26
84fb5b46
MKG
27=head2 Security tips for running RT
28
29=over
30
31=item *
32
33Protect your RT installation by making it only accessible via SSL. This
34will protect against users' passwords being sniffed as they go over the
35wire, as well as helping prevent phishing attacks. If you use SSL, you
36will need to install some additional Perl libraries so that C<rt-mailgate>
37can connect. You can use the C<--enable-ssl-mailgate> command to
38configure to automate the installation of these dependencies. This is
39documented further in step 10 of the README.
40
41You should use a certificate signed by a reputable authority, or at very
42least a certificate signed by a consistent local CA, which you configure
43your local systems to trust. If your SSL certificate is self-signed, it
44does little to prevent phishing, as users are trained to accept the
45unauthorized certificate. See also the C<--no-verify-ssl> flag to
46C<rt-mailgate>.
47
48=item *
49
50Be sure to change the password for the C<root> user of RT. The default
51password is C<password>. This can be changed via the RT web interface
52at: Preferences > About me
53
54
55=item *
56
57Be sure to protect your F<RT_SiteConfig.pm> file if it contains database
58credentials or other sensitive information. This file only needs to be
59readable by RT and your web server. One way to accomplish this is to
60make the file readable only by root and the group that RT runs as, and
61then make sure your web server is a member of that group. Advanced
62configuration may be required if other users have the ability to run
63CGIs or access the server where RT is running.
64
65
66=item *
67
68Be sure to protect your database. If it does not need to talk to the
69world, then don't allow it to listen for remote connections. With MySQL
70this can be accomplished via C<skip-networking>. If you use your
71database for other things and must allow remote connections, be sure to
72use a strong, hard to guess password for RT.
73
74
75=item *
76
77Apache, lighttpd, and most other web servers support name based virtual
78hosts. When possible, configure RT as a name based virtual host to
79raise the bar against DNS rebinding attacks. If you see RT when you
80visit http://your.servers.ipaddress.here, it means you are likely not
81getting this additional protection.
82
83
84=item *
85
86Use groups to organize RT permissions. Granting permissions per-user
87makes them, in general, more easily over-granted and forgotten, and more
88likely to diverge from each other, forming a maintenance hassle.
89
90=back
91
92=cut