On Nov 12, 2011 1:39 AM, "Grant" <emailgr...@gmail.com> wrote: > > >> A little while ago I set up an automated backup system to back up the > >> data from 3 machines to a backup server. I decided to use a > >> push-style layout where the 3 machines push their data to the backup > >> server. Public SSH keys for the 3 machines are stored on the backup > >> server and restricted to the rdiff-backup command. Each of the 3 > >> machines pushes their data to the backup server as a different user > >> and the top directory of each backup is chmod 700 to prevent any of > >> the 3 machines from reading or writing a backup from another machine. > >> > >> I've run into a problem with this layout that I can't seem to solve, > >> and I'm wondering if I should switch to a pull-style layout where the > >> backup server pulls data from each of the 3 machines. > >> > >> 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. > >> > >> What do you think guys? Are push-style backups flawed and unacceptable? > >> > > > > No, it's not flawed, as long as the implementation is right: versioning and > > deduplication. > > > > With versioning, an attacker (or infiltrator, in this matter) might try to > > taint the backup, but all she can do is just push a new version to the > > server. You can recover your data by reverting to a prior version. > > Is that true? Wouldn't the infiltrator be able to craft some sort of > rdiff-backup command that deletes the entire backup? I can't come up > with such a command myself, but I thought I was essentially giving > full read/write access of a system's backup to an infiltrator by > putting that system's public key on the backup server. I do restrict > the key like command="rdiff-backup --server" but I didn't expect that > to completely prevent the backup from being wiped out. Does it? > > - Grant > > > > The deduplication part is only to save storage space. It's less necessary if > > you have a robust versioning system that can categorize each push as either > > canonical/perpetual/permanent or ephemeral/temporary. The system can just > > discard old ephemeral pushes when storage becomes critical. >
Just an illustration: My employer will soon do a PoC/Live Demo of this product: http://www.atempo.com/products/liveBackup/features.asp Only an 'agent' lives inside the employee's workstation. It pushes all writes to certain folders to the server, and able to request 'reverts' to their local copy, but the server's archives are immutable. Unfortunately, said product only supports Windows and Macs. I'm still on the lookout for something similar for Linux. (For pure text files, a git/mercurial server would be enough, though.) Rgds,
