1 |
On Nov 12, 2011 1:39 AM, "Grant" <emailgrant@×××××.com> wrote: |
2 |
> |
3 |
> >> A little while ago I set up an automated backup system to back up the |
4 |
> >> data from 3 machines to a backup server. I decided to use a |
5 |
> >> push-style layout where the 3 machines push their data to the backup |
6 |
> >> server. Public SSH keys for the 3 machines are stored on the backup |
7 |
> >> server and restricted to the rdiff-backup command. Each of the 3 |
8 |
> >> machines pushes their data to the backup server as a different user |
9 |
> >> and the top directory of each backup is chmod 700 to prevent any of |
10 |
> >> the 3 machines from reading or writing a backup from another machine. |
11 |
> >> |
12 |
> >> I've run into a problem with this layout that I can't seem to solve, |
13 |
> >> and I'm wondering if I should switch to a pull-style layout where the |
14 |
> >> backup server pulls data from each of the 3 machines. |
15 |
> >> |
16 |
> >> The problem with my current push-style layout is that if one of the 3 |
17 |
> >> machines is compromised, the attacker can delete or alter the backup |
18 |
> >> of the compromised machine on the backup server. I can rsync the |
19 |
> >> backups from the backup server to another machine, but if the backups |
20 |
> >> are deleted or altered on the backup server, the rsync'ed copy on the |
21 |
> >> next machine will also be deleted or altered. |
22 |
> >> |
23 |
> >> If I run a pull-style layout and the backup server is compromised, the |
24 |
> >> attacker would have root read access to each of the 3 machines, but |
25 |
> >> the attacker would already have access to backups from each of the 3 |
26 |
> >> machines stored on the backup server itself so that's not really an |
27 |
> >> issue. I would also have the added inconvenience of using openvpn or |
28 |
> >> ssh -R for my laptop so the backup server can pull from it through any |
29 |
> >> router. |
30 |
> >> |
31 |
> >> What do you think guys? Are push-style backups flawed and |
32 |
unacceptable? |
33 |
> >> |
34 |
> > |
35 |
> > No, it's not flawed, as long as the implementation is right: versioning |
36 |
and |
37 |
> > deduplication. |
38 |
> > |
39 |
> > With versioning, an attacker (or infiltrator, in this matter) might try |
40 |
to |
41 |
> > taint the backup, but all she can do is just push a new version to the |
42 |
> > server. You can recover your data by reverting to a prior version. |
43 |
> |
44 |
> Is that true? Wouldn't the infiltrator be able to craft some sort of |
45 |
> rdiff-backup command that deletes the entire backup? I can't come up |
46 |
> with such a command myself, but I thought I was essentially giving |
47 |
> full read/write access of a system's backup to an infiltrator by |
48 |
> putting that system's public key on the backup server. I do restrict |
49 |
> the key like command="rdiff-backup --server" but I didn't expect that |
50 |
> to completely prevent the backup from being wiped out. Does it? |
51 |
> |
52 |
> - Grant |
53 |
> |
54 |
> |
55 |
> > The deduplication part is only to save storage space. It's less |
56 |
necessary if |
57 |
> > you have a robust versioning system that can categorize each push as |
58 |
either |
59 |
> > canonical/perpetual/permanent or ephemeral/temporary. The system can |
60 |
just |
61 |
> > discard old ephemeral pushes when storage becomes critical. |
62 |
> |
63 |
|
64 |
Just an illustration: My employer will soon do a PoC/Live Demo of this |
65 |
product: |
66 |
|
67 |
http://www.atempo.com/products/liveBackup/features.asp |
68 |
|
69 |
Only an 'agent' lives inside the employee's workstation. It pushes all |
70 |
writes to certain folders to the server, and able to request 'reverts' to |
71 |
their local copy, but the server's archives are immutable. |
72 |
|
73 |
Unfortunately, said product only supports Windows and Macs. I'm still on |
74 |
the lookout for something similar for Linux. |
75 |
|
76 |
(For pure text files, a git/mercurial server would be enough, though.) |
77 |
|
78 |
Rgds, |