DRD Agent

This is the remote part of the DRD module version 3.x and later.

No requirements / no dependencies

DRD Agent is simply a wrapper to receive, route, handle and respond to requests from authorised Drupal Remote Dashboards. Just download and enable the module and everything else will be managed by DRD.

No maintenance

Being a wrapper is done so that we hopefully don't have to update this module too often. The reason for that is a DRD library (drd.phar) which is part of the main dashboard module that contains all the functionality for the agent. That library is stored on drupal.org and the agent downloads the latest library from there when ever it is needed.

Security and privacy

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 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 available ciphers 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 hosts, 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.

We believe that we've done all we can to make it save using DRD and DRD Agent. Of course, we're happy to improve the scenario should there be any concerns left and we want to encourage you to discuss those with us.