Security

The first question one should ask before installing monitoring components of any kind, is there any information disclosure to third parties or security implications for the site being monitored. With DRD, both concerns don't apply and here is why.

Only the site administrator is able to install and enable the DRD Agent on a remote site. By doing this, the agent won't respond to any request until the site administrator registers one or more remote dashboards as being authorised to communicate with any of the agents.

The registration is stored as a local variable in each site for the agent and contains a universally unique id (uuid) for an authorised dashboard and each future request will contain this uuid such that the agent can verify the validity of that request.

Having said that, let's have a look into how the communication between the dashboard and the agent is being protected from prying eyes. There are two steps to ensure that: encryption and authentication.

Encryption

Each and every request and response between the dashboard and the agent is being encrypted. By default, DRD implements 3 different encryption methods:

• OpenSSL (default)
• MCrypt
• TLS

When adding a new Drupal core to the dashboard a list of available encryption methods is being displayed that are available at both ends. For OpenSSL and MCrypt a list of ciphers available at both ends is also displayed and the administrator can select those they prefer. Only as a fallback, if none of the other encryption technologies were available on both sides, TLS could be used but of course only if the remote domain is configured to be accessible through https.

Authentication

When adding a new Drupal core to the dashboard, you can choose between username/password and a shared secret authentication. With the former method, all activity will be performed with the permissions of that user account on the remote domain, otherwise the session will be escalated to the user 1.

All the settings for a registered dashboard (uuid, encryption method, encryption settings, authentication method and settings) are stored with the DRD agent and each request will be validated against that and only executed if everything is OK.

Also, the implementation of encryption and authentication is done with plugins which means that developers can easily extend the list of available methods.

Shared secret:

When you add a new core, you can define a 'Shared secret' (a string you choose). When you proceed to the next step and authenticate your DRD instance with the remote site for the first time, that 'Shared secret' string is copied over to the Agent/website.

The secret is stored as a property at both ends, with DRD and with the Agent. When DRD makes a request, it always sends that Shared secret string for the agent to validate.