1 |
On Fri, Nov 11, 2011 at 1:27 PM, Grant <emailgrant@×××××.com> wrote: |
2 |
>> [snip] |
3 |
>> |
4 |
>>> The problem with my current push-style layout is that if one of the 3 |
5 |
>>> machines is compromised, the attacker can delete or alter the backup |
6 |
>>> of the compromised machine on the backup server. I can rsync the |
7 |
>>> backups from the backup server to another machine, but if the backups |
8 |
>>> are deleted or altered on the backup server, the rsync'ed copy on the |
9 |
>>> next machine will also be deleted or altered. |
10 |
>> |
11 |
>> As a final stage in your backup, could you trigger a 'pull'-style |
12 |
>> backup copying the data image to a more secure area? How about setting |
13 |
> |
14 |
> Even if I pull a copy of the backup to a separate machine from the |
15 |
> backup server, it will pull an altered copy if an attacker compromises |
16 |
> one of the systems being backed up and alters that system's backup on |
17 |
> the backup server. Am I missing something? |
18 |
|
19 |
If you're not applying any kind of versioning, it doesn't matter if |
20 |
you're pushing or pulling; your backup will eventually be overwritten |
21 |
by a backup of a hacked system unless you catch and respond as soon as |
22 |
the original invasion happens. So it sounds like the scenario you fear |
23 |
isn't tied to the mechanism you're reconsidering. |
24 |
|
25 |
-- |
26 |
:wq |