1 |
>> A little while ago I set up an automated backup system to back up the |
2 |
>> data from 3 machines to a backup server. I decided to use a |
3 |
>> push-style layout where the 3 machines push their data to the backup |
4 |
>> server. Public SSH keys for the 3 machines are stored on the backup |
5 |
>> server and restricted to the rdiff-backup command. Each of the 3 |
6 |
>> machines pushes their data to the backup server as a different user |
7 |
>> and the top directory of each backup is chmod 700 to prevent any of |
8 |
>> the 3 machines from reading or writing a backup from another machine. |
9 |
>> |
10 |
>> I've run into a problem with this layout that I can't seem to solve, |
11 |
>> and I'm wondering if I should switch to a pull-style layout where the |
12 |
>> backup server pulls data from each of the 3 machines. |
13 |
>> |
14 |
>> The problem with my current push-style layout is that if one of the 3 |
15 |
>> machines is compromised, the attacker can delete or alter the backup |
16 |
>> of the compromised machine on the backup server. I can rsync the |
17 |
>> backups from the backup server to another machine, but if the backups |
18 |
>> are deleted or altered on the backup server, the rsync'ed copy on the |
19 |
>> next machine will also be deleted or altered. |
20 |
>> |
21 |
>> If I run a pull-style layout and the backup server is compromised, the |
22 |
>> attacker would have root read access to each of the 3 machines, but |
23 |
>> the attacker would already have access to backups from each of the 3 |
24 |
>> machines stored on the backup server itself so that's not really an |
25 |
>> issue. I would also have the added inconvenience of using openvpn or |
26 |
>> ssh -R for my laptop so the backup server can pull from it through any |
27 |
>> router. |
28 |
>> |
29 |
>> What do you think guys? Are push-style backups flawed and unacceptable? |
30 |
>> |
31 |
> |
32 |
> No, it's not flawed, as long as the implementation is right: versioning and |
33 |
> deduplication. |
34 |
> |
35 |
> With versioning, an attacker (or infiltrator, in this matter) might try to |
36 |
> taint the backup, but all she can do is just push a new version to the |
37 |
> server. You can recover your data by reverting to a prior version. |
38 |
|
39 |
Is that true? Wouldn't the infiltrator be able to craft some sort of |
40 |
rdiff-backup command that deletes the entire backup? I can't come up |
41 |
with such a command myself, but I thought I was essentially giving |
42 |
full read/write access of a system's backup to an infiltrator by |
43 |
putting that system's public key on the backup server. I do restrict |
44 |
the key like command="rdiff-backup --server" but I didn't expect that |
45 |
to completely prevent the backup from being wiped out. Does it? |
46 |
|
47 |
- Grant |
48 |
|
49 |
|
50 |
> The deduplication part is only to save storage space. It's less necessary if |
51 |
> you have a robust versioning system that can categorize each push as either |
52 |
> canonical/perpetual/permanent or ephemeral/temporary. The system can just |
53 |
> discard old ephemeral pushes when storage becomes critical. |