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