[usit-rt.git] / docs / security.pod

=head1 RT Security

=head2 Reporting security vulnerabilities in RT

If you believe you've discovered a security issue in RT, please send an
email to <security@bestpractical.com> with a detailed description of the
issue, and a secure means to respond to you (such as your PGP public
key).

More information is available at L<http://bestpractical.com/security/>.


=head2 RT's security process

After a security vulnerability is reported to Best Practical and
verified, we attempt to resolve it in as timely a fashion as possible.
Best Practical support customers will be notified before we disclose the
information to the public.  All security announcements will be sent to
C<rt-announce@bestpractical.com>, which includes
C<rt-users@bestpractical.com> and C<rt-devel@bestpractical.com>.

As the tests for security vulnerabilities are often nearly identical to
working exploits, sensitive tests will be embargoed for a period of six
months before being added to the public RT repository.


=head2 Security tips for running RT

=over

=item *

Protect your RT installation by making it only accessible via SSL.  This
will protect against users' passwords being sniffed as they go over the
wire, as well as helping prevent phishing attacks.

You should use a certificate signed by a reputable authority, or at very
least a certificate signed by a consistent local CA, which you configure
your local systems to trust.  If your SSL certificate is self-signed, it
does little to prevent phishing, as users are trained to accept the
unauthorized certificate.  See also the C<--no-verify-ssl> flag to
C<rt-mailgate>.

=item *

Be sure to change the password for the C<root> user of RT.  The default
password is C<password>.  This can be changed via the RT web interface
at: Preferences > About me


=item *

Be sure to protect your F<RT_SiteConfig.pm> file if it contains database
credentials or other sensitive information.  This file only needs to be
readable by RT and your web server.  One way to accomplish this is to
make the file readable only by root and the group that RT runs as, and
then make sure your web server is a member of that group.  Advanced
configuration may be required if other users have the ability to run
CGIs or access the server where RT is running.


=item *

Be sure to protect your database.  If it does not need to talk to the
world, then don't allow it to listen for remote connections.  With MySQL
this can be accomplished via C<skip-networking>.  If you use your
database for other things and must allow remote connections, be sure to
use a strong, hard to guess password for RT.


=item *

Apache, lighttpd, and most other web servers support name based virtual
hosts.  When possible, configure RT as a name based virtual host to
raise the bar against DNS rebinding attacks.  If you see RT when you
visit http://your.servers.ipaddress.here, it means you are likely not
getting this additional protection.


=item *

Use groups to organize RT permissions.  Granting permissions per-user
makes them, in general, more easily over-granted and forgotten, and more
likely to diverge from each other, forming a maintenance hassle.

=back

=cut
Commit	Line	Data
84fb5b46 MKG	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
b5747ff2 MKG	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
84fb5b46 MKG	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
af59614d	35	wire, as well as helping prevent phishing attacks.
84fb5b46 MKG	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