Rudder security & hardening

By default, all HTTPS traffic is handled by the same virtual host in Apache httpd. To allow hardening the connection security, a first step is to split public Web/API from internal node-server communication. You can do so by commenting the default virtual host in /etc/apache2/sites-enabled/rudder.conf or /etc/httpd/conf.d/rudder.conf (depending on the distribution), and uncommenting the two separate configurations. You need to define a method to distinguish both configurations, in general with a different port (which allows applying different firewall rules too) or a specific domain for Web/API.

Once your virtual hosts are split, set up a valid certificate for the Web/API. This allows validating the server identity from Web browsers and API clients. You can use an internal PKI or a publicly trusted certificate, like with Let’s Encrypt. The certificate configuration is done in /etc/apache2/sites-enabled/rudder.conf or /etc/httpd/conf.d/rudder.conf depending on your distribution, in the Web/API virtual host. To configure the TLS settings of the Web/API virtual hosts depending on your requirements and platform, we recommend using Mozilla SSL configurator generator.

HTTP Strict Transport Security (HSTS) ensures the user’s browser will always use HTTPS to connect to your server. It is not enabled by default as it may conflict with other services served from the same domain (e.g. package repositories). If you only use HTTPS with your Rudder’s server domain, you can enable the HSTS header in /opt/rudder/etc/rudder-web.properties by modifying or adding the following properties (and restarting the rudder-jetty service to apply it):

You may want to hide the Apache httpd version from the headers. It cannot be done inside Rudder’s configuration as it is a global httpd setting. To do so, you need to set the ServerTokens parameter to the Prod value (in /etc/httpd or /etc/apache depending on your distribution).

It is recommended to use an external authentication backend exposing an OpenID Connect or OAUTH2 interface with a second authentication factor (TOTP, WebAuthn, etc.), configured through the auth-backends plugins.

In case you use local Rudder users, your passwords must be hashed with bcrypt, which is now the only hash algorithm used when generating new passwords in the user management page. It may still be the case that users use other kind of unsalted hashed password (especially before Rudder 6.0), so they are still allowed but they will be deprecated soon in favor of bcrypt. You can check the documentation of /opt/rudder/etc/rudder-users.xml and of the user management page for the migration guide.

Session expiration is configured by default to 30 minutes of user inactivity. You may want to shorten this value in /opt/rudder/etc/rudder-web.properties by modifying or adding the following property (and restarting the rudder-jetty service to apply it):

Give minimal privileges to Rudder users using roles. You can create custom roles to match your needs in /opt/rudder/etc/rudder-users.xml.

When a user have not logged in, by default for 90 days, the account is marked as disabled, you can change this value by modifying or adding the parameter rudder.users.cleanup.account.disableAfterLastLogin in /opt/rudder/etc/rudder-web.properties, for example if we want to disable a user after 100 days of inactivity we can set the parameter like this :

A user is deleted after a certain period of time, by default the parameter rudder.users.cleanup.account.deletedAfterLastLogin is set to 120 days. You can change this value by modifying or adding this parameter in /opt/rudder/etc/rudder-web.properties, for example if we want to delete a user after 365 days of inactivity we can set the parameter like this :

When an user is deleted (for example removed from rudder-user.xml file), then the user information, like status changes, are not purged immediately (typically to be able to do post-deletion accountability). You can modify the period of time (by default 30 days) after which the purge is performed by editing or adding the parameter rudder.users.cleanup.purgeDeletedAfter, like this:

Give minimal privileges to Rudder users using roles (through the user-management plugin). You can create custom roles to match your needs in /opt/rudder/etc/rudder-users.xml.

After a configuration change on a user that might have a security impact, the user session will be immediately invalidated (when user password or roles change, or when user is disabled or deleted).

When upgrading from a previous version to 8.0, regenerate all your exiting API tokens to use the more secure hashed storage.

Give minimal privileges to your HTTP API tokens (though the api-authorizations plugin) and use a different token for each application or use-case.

Even if all communications are encrypted with TLS 1.3, we recommend avoiding Rudder communications across public networks, and using a VPN in case you need access outside your private network.

Add firewall rules to limit access to Rudder ports to relevant systems.