Re: [gentoo-user] {OT} Are "push" backups flawed?

[Florian Philipp <lists@binarywings.net>]

[-- Attachment #1: Type: text/plain, Size: 3987 bytes --]

Am 11.11.2011 19:56, schrieb Pandu Poluan:
> 
> On Nov 12, 2011 1:39 AM, "Grant" <emailgrant@gmail.com
> <mailto:emailgrant@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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]