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