Macrium MultiSite and Security
Macrium MultiSite enables you to monitor and manage multiple instances of Macrium Site Manager using one web interface. This web interface is hosted by us using Microsoft Azure virtual machines. Information from the Site Managers is sent securely over an insecure network, the internet, to the virtual machines. This begs the question, how do we keep your information secure from Site Manager to MultiSite?
How Site Managers are added to MultiSite
Before we discuss the security of MultiSite in detail, we’ll first clarify the steps that are taken to add a Site Manager to MultiSite. First, ‘Remote Management’ must be enabled on the Site Manager that you want to add to MultiSite.
You will then be provided with an API key. In MultiSite, after selecting ‘Add Site’ on the ‘Sites’ page, you will be prompted to enter the API key from the Site Manager.
If the API key that is entered into MultiSite matches the API key in the Site Manager settings, then the Site Manager will be added to MultiSite. After a brief period where the Site Manager ‘Initializes’, you can then begin monitoring the Site Manager using MultiSite.
What is happening behind the scenes?
When ‘Remote Management’ is enabled in the Site Manager settings, the Site Manager begins “pinging” our MultiSite endpoints with information. This information contains:
- A hash of the API key that is shown in the Site Manager, this ensures that the API key itself is never sent from the Site Manager to MultiSite. This hash uses SHA-512 based HMAC, and a 1024-bit shared secret key between the Site Manager and MultiSite (symmetric encryption).
- The current time is included to ensure that messages cannot be captured and used in a replay attack at a later point in time. If the time difference between the Site Manager and MultiSite varies too much, the connection will be rejected.
- Unique IDs and non-sensitive metadata about the Site.
- A HMAC of the entire message is also sent to verify the integrity of the entire handshake.
The MultiSite server will then confirm the hash and store the public key from the Site Manager in MultiSite’s database along with the hashed API key. MultiSite will then return the relevant connection details for the Site Manager to create an SSH connection to the MultiSite endpoints.
If the Site Manager service detects significant hardware changes since last run, a new API will be generated in Site Manager automatically. This will prevent accidental duplication of API keys if the Site Manager server is imaged and restored. Additionally, it will also prevent a malicious third-party attempting to steal the Site Manager’s config file and use the API key to access systems in another Site Manager instance.
Establishing the connection:
The Site Manage will then establish an outgoing SSH connection to the destination that MultiSite returned. This SSH connection uses the RSA 2048-bit private key that matches the public key transmitted in the initial connection. The Site Manager then configures a reverse tunnel that links the Site Manager’s HTTPS port, by default this is 2904, to the MultiSite server.
Communication between MultiSite and Site Manager:
Once the SSH tunnel has been established, Site Manager and MultiSite will communicate exclusively through this secure tunnel. MultiSite and Site Manager communicate over this tunnel using HTTPs calls, which has an additional layer of inherent security. For additional security, the Site Manager server requires HTTPS requests from MultiSite to contain the Site Manager’s API key. All the HTTPs requests are routed from the SSH connection to Site Manager’s internal web server.
Only metadata about the backups are sent from the Site Manager to MultiSite, the actual data contained in the backups will not be sent to MultiSite.
MultiSite is hosted on Microsoft Azure virtual machines that are running Docker. Docker enables instances of MultiSite to be run in isolated containers; this means that in the extremely unlikely event that one of the containers is compromised, the other containers will be unaffected. When MultiSite is updated, each docker container is deleted and recreated. The MultiSite virtual machines in Azure are hidden behind a reverse proxy that only accepts SSH and HTTPs traffic. The web endpoints themselves all use TLS1.2 for HTTPS encryption.
Securing your MultiSite
To ensure that your MultiSite users can only access permitted content, MultiSite implements granularity in the user accounts. There are three types of accounts:
Owner - This is the default account that is created when a MultiSite domain is created. This account has access to everything and is initially associated with the email address that was used to create the domain. This account has unrestricted access to the MultiSite. Ownership can be transferred to admin accounts at any time using the ‘Users’ settings menu. Once ownership has been transferred to an admin account, the owner account will become an admin account and the admin account that ownership was transferred to will become the owner account.
Admin - Admin accounts also have access to everything on the MultiSite, however, they are unable to delete the MultiSite domain.
Viewer - Viewer accounts have the least access of the three account types. Viewers can only view sites that have been specified by owner or admin accounts. The ability to remote view sites can also be disabled for the viewer accounts. Viewer accounts also have restricted access to settings, and cannot modify global MultiSite settings.
We recommend using these account types to ensure a principle of least privilege (PoLP) policy is followed. By ensuring that each user has access to only the necessary parts of MultiSite, you can ensure that unauthorized access to sites does not occur. MultiSite also supports two factor authentication (2FA). Enabling 2FA ensures that unauthorized access cannot be gained to MultiSite in the event that your credentials are compromised, as you will need to approve logins via email. 2FA is enabled on a MultiSite wide basis, it will be enabled for all users of the MultiSite domain.