• RT Security
  • Reporting security vulnerabilities in RT
  • RT's security process
  • Security tips for running RT

RT Security

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 http://bestpractical.com/security/.

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 rt-announce@bestpractical.com and posted to the community forum at https://forum.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.

Security tips for running RT

• 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 --no-verify-ssl flag to rt-mailgate.

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

• Be sure to protect your 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.

• 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 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.

• 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.

• 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.