Am 11.11.2011 19:56, schrieb Pandu Poluan: > > On Nov 12, 2011 1:39 AM, "Grant" <emailgr...@gmail.com > <mailto: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, >
Isn't Bacula something like this? http://www.bacula.org/en/dev-manual/main/main/What_is_Bacula.html#SECTION00220000000000000000 Hint: "File server" actually is the client that is backed up.
signature.asc
Description: OpenPGP digital signature
