rt/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 =head2 Security tips for running RT
  13
  14 =over
  15
  16 =item *
  17
  18 Protect your RT installation by making it only accessible via SSL.  This
  19 will protect against users' passwords being sniffed as they go over the
  20 wire, as well as helping prevent phishing attacks.  If you use SSL, you
  21 will need to install some additional Perl libraries so that C<rt-mailgate>
  22 can connect.  You can use the C<--enable-ssl-mailgate> command to
  23 configure to automate the installation of these dependencies.  This is
  24 documented further in step 10 of the README.
  25
  26 You should use a certificate signed by a reputable authority, or at very
  27 least a certificate signed by a consistent local CA, which you configure
  28 your local systems to trust.  If your SSL certificate is self-signed, it
  29 does little to prevent phishing, as users are trained to accept the
  30 unauthorized certificate.  See also the C<--no-verify-ssl> flag to
  31 C<rt-mailgate>.
  32
  33 =item *
  34
  35 Be sure to change the password for the C<root> user of RT.  The default
  36 password is C<password>.  This can be changed via the RT web interface
  37 at: Preferences > About me
  38
  39
  40 =item *
  41
  42 Be sure to protect your F<RT_SiteConfig.pm> file if it contains database
  43 credentials or other sensitive information.  This file only needs to be
  44 readable by RT and your web server.  One way to accomplish this is to
  45 make the file readable only by root and the group that RT runs as, and
  46 then make sure your web server is a member of that group.  Advanced
  47 configuration may be required if other users have the ability to run
  48 CGIs or access the server where RT is running.
  49
  50
  51 =item *
  52
  53 Be sure to protect your database.  If it does not need to talk to the
  54 world, then don't allow it to listen for remote connections.  With MySQL
  55 this can be accomplished via C<skip-networking>.  If you use your
  56 database for other things and must allow remote connections, be sure to
  57 use a strong, hard to guess password for RT.
  58
  59
  60 =item *
  61
  62 Apache, lighttpd, and most other web servers support name based virtual
  63 hosts.  When possible, configure RT as a name based virtual host to
  64 raise the bar against DNS rebinding attacks.  If you see RT when you
  65 visit http://your.servers.ipaddress.here, it means you are likely not
  66 getting this additional protection.
  67
  68
  69 =item *
  70
  71 Use groups to organize RT permissions.  Granting permissions per-user
  72 makes them, in general, more easily over-granted and forgotten, and more
  73 likely to diverge from each other, forming a maintenance hassle.
  74
  75 =back
  76
  77 =cut