Incremental Remote Backup System Security Analysis
Internal
Overview
Overview
This document describes security risks and mitigation measures for a remote incremental backup solution.
The synchronization between the active storage and backup storage is performed using rsync over a ssh secure transport layer. Since the backup system is dedicated, it could be configured to run rsync in a loop, thus ensuring a high degree of synchronization between the active storage and backup storage. Alternatively the active system could run rsync periodically during times of low traffic.
The connection can be initiated by the active system or by the backup system. Solution 1 - Active System initiates Connection
Advantages:
The backup system does not need to maintain a security sensitive private key that may be exposed to attack and allow an attacker access to the active system, if an attacker takes physical or remote control of the backup system.
More than one active system may use the backup system (independently) to replicate filesystems.
The active system(s) do not need to expose access.
Disadvantages:
The backup system needs to expose an ssh access point, which implies a static IP address, or infrastructure that simulates a static IP address.
The backup system becomes vulnerable to remote attacks.
Solution 2 - Backup System initiates Connection
Advantages:
All the backup logic is collocated with the backup system, the active system is oblivious to the fact that is being replicated, except for the need to expose a ssh access point.
The backup system does not need special configuration within its host network (expose an external ssh access point). It could be just simply turned on, get its address via DHCP and become operational.
Disadvantages:
The backup system must carry an active system private key, which may be compromised by an attacker, who can then gain direct access to the active system.
The active system must open a remote access endpoint, making it vulnerable to remote attacks.
Security Risks
Attacker may gain physical possession of the backup disk.
Mitigation measures: the backup system uses block device-level strong symmetric encryption (AES 256-bit) and a key derivation algorithm. The passphrase is not stored locally and must be provided every time the system boots. This approach will make the block device storage resilient to a brute force attack.
Attacker may gain physical possession of the backup system (including the backup disk). While the system is running, the encrypted block device is mounted and the encryption key is maintained in memory, so an attacker who gains access to the backup system may read its content.
Mitigation measures:
Make the backup system sensitive to loss of power (no battery) so if the system is disconnected from power, it automatically shuts down. This way, an attacker cannot physically remove the system, transport it in a different location while the system is running and attempt to retrieve (or use) the secret encryption key active in memory. If the power goes down, the secret encryption key disappears from memory, and the access to the encrypted block device can only be restored if the passphrase is provided to the system’s console.
Make the backup system hard to break into, while on-line via usual security hardening measures:
Minimum possible number of login accounts (ideally just one for remote access and root)
Long, high entropy passwords, used only for console access (also see “remote attack” below).
Attacker may gain remote access to the backup system. This risk only applies to Solution 1, as the backup system needs to expose a ssh access point to the internet. This makes it vulnerable to remote attacks.
Mitigation measures:
Reduce the surface of attack:
sshd listens on a high, non-standard port.
Special access account, with no password, but only public/private key based access.
root not allowed to connect over ssh.
iptables drops traffic on all incoming ports, except ssh.
iptables only allows access from a set of white-listed IP addresses