From: Grant <emailgrant@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] {OT} Are "push" backups flawed?
Date: Fri, 11 Nov 2011 10:34:54 -0800 [thread overview]
Message-ID: <CAN0CFw1_eqx4tCitAnNN-w33-kmu=6cJ261q9iVcFM9xbFX_5A@mail.gmail.com> (raw)
In-Reply-To: <CAA2qdGW4UTzF+WYJy=FxNJmRRnG6UK3x7hSEEHtHOh0g+oCdrA@mail.gmail.com>
>> 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.
next prev parent reply other threads:[~2011-11-11 18:36 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-11 17:55 [gentoo-user] {OT} Are "push" backups flawed? Grant
2011-11-11 18:15 ` Michael Mol
2011-11-11 18:27 ` Grant
2011-11-11 18:33 ` Michael Mol
2011-11-11 18:25 ` Pandu Poluan
2011-11-11 18:34 ` Grant [this message]
2011-11-11 18:56 ` Pandu Poluan
2011-11-11 19:14 ` Florian Philipp
2011-11-12 3:22 ` Pandu Poluan
2011-11-12 1:11 ` Michael Orlitzky
2011-11-12 2:22 ` Grant
2011-11-12 3:20 ` Pandu Poluan
2011-11-12 4:16 ` Michael Orlitzky
2011-11-12 4:32 ` Pandu Poluan
2011-11-13 18:03 ` Grant
2011-11-13 19:44 ` Florian Philipp
2011-11-15 0:43 ` Grant
2011-11-15 1:04 ` Michael Mol
2011-11-15 1:19 ` Grant
2011-11-15 2:11 ` Michael Mol
2011-11-15 2:32 ` Grant
2011-11-15 2:37 ` Michael Mol
2011-11-15 2:47 ` Grant
2011-11-15 4:54 ` Pandu Poluan
2011-11-15 7:18 ` J. Roeleveld
2011-11-13 20:43 ` Michael Orlitzky
2011-11-15 0:46 ` Grant
2011-11-13 20:50 ` Michael Orlitzky
2011-11-15 1:54 ` Grant
2011-11-15 15:23 ` Michael Orlitzky
2011-11-12 4:10 ` Michael Orlitzky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAN0CFw1_eqx4tCitAnNN-w33-kmu=6cJ261q9iVcFM9xbFX_5A@mail.gmail.com' \
--to=emailgrant@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox