1 |
On Nov 12, 2011 9:29 AM, "Grant" <emailgrant@×××××.com> wrote: |
2 |
> |
3 |
> >> The problem with my current push-style layout is that if one of the 3 |
4 |
> >> machines is compromised, the attacker can delete or alter the backup |
5 |
> >> of the compromised machine on the backup server. I can rsync the |
6 |
> >> backups from the backup server to another machine, but if the backups |
7 |
> >> are deleted or altered on the backup server, the rsync'ed copy on the |
8 |
> >> next machine will also be deleted or altered. |
9 |
> >> |
10 |
> >> If I run a pull-style layout and the backup server is compromised, the |
11 |
> >> attacker would have root read access to each of the 3 machines, but |
12 |
> >> the attacker would already have access to backups from each of the 3 |
13 |
> >> machines stored on the backup server itself so that's not really an |
14 |
> >> issue. I would also have the added inconvenience of using openvpn or |
15 |
> >> ssh -R for my laptop so the backup server can pull from it through any |
16 |
> >> router. |
17 |
> > |
18 |
> > If an attacker can read the entire filesystem, he'll gain full root |
19 |
> > privileges quickly. |
20 |
> |
21 |
> So if I push, I don't really have backups because anyone who breaks |
22 |
> into the backed-up system can delete all of its backups like this: |
23 |
> |
24 |
> rdiff-backup --remove-older-than 1s backup@12.34.56.78::/path/to/backup |
25 |
> |
26 |
|
27 |
Write a daemon that immediately create hardlinks of the backed-up files in |
28 |
a separate folder. Thus, even if rdiff decides to unlink everything, your |
29 |
data are safe thanks to the nature of hardlinks. Optionally, have the same |
30 |
daemon tarball the files (via the hardlinks) if you deem the revision |
31 |
'permanent'. |
32 |
|
33 |
> And if I pull, none of my backed-up systems are secure because anyone |
34 |
> who breaks into the backup server has root read privileges on every |
35 |
> backed-up system and will thereby "gain full root privileges quickly." |
36 |
|
37 |
IMO that depends on whether you also backup the authentication-related |
38 |
files or not. Exclude them from backup, ensure different root passwords for |
39 |
all boxes, and now you can limit the infiltration. |
40 |
|
41 |
Rgds, |