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