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

[Grant]

> Sure, but you've noted that rdiff-backup is insecure if the source box is
> violated. What you need, then, is a layer of versioning not subject to that
> vulnerability.

Does it exist?

- Grant


>> > You identified a flaw in the system as you were using it. You're right,
>> > those are flaws. However, you can " fix" those flaws by applying some
>> > magic
>> > as a sysadmin. That's why several posts in the thread have mentioned
>> > versioning your backups in some fashion. I've mentioned lvm a couple
>> > times.
>>
>> I thought versioning meant that you could roll back to a previous
>> version.  rdiff-backup provides that.
>>
>> > I think someone else mentioned pulling the backup target's data to
>> > another
>> > locale, either via a pull from another server, or via something like a
>> > traditional incremental tape backup.
>>
>> So the systems push to the backup server and a second backup server
>> pulls from the first backup server?  Should the second backup server
>> use rdiff-backup against the rdiff-backup repository on the first
>> backup server?  I think I've read that's not a good idea.
>>
>> What does everybody else do?  I feel like the first person to ever
>> attempt secure automated backups.
>>
>> - Grant
>>
>>
>> > You're getting the data off the original machines to a remote location,
>> > which is good. You identified a way the backed-up data could be tampered
>> > with, which is good. You just need to put in another (better) barrier to
>> > protect the data from being tampered with, or limit how much data is
>> > lost in
>> > such an event.
>> >
>> > ZZ
>> >
>> > On Nov 14, 2011 8:21 PM, "Grant" <emailgrant@×××××.com> wrote:
>> >>
>> >> > It's out of scope for file transfer protocols; it's a
>> >> > daemon/system-local
>> >> > problem.  Attach pre-event or post-event scripts serverside for any
>> >> > special
>> >> > munging or protections you'd like to apply. (Such as triggering an
>> >> > LVM
>> >> > snapshot, for example...)
>> >>
>> >> I must be going about this the wrong way.  Am I the only one using
>> >> automated backups?  If not, how is it done properly?
>> >>
>> >> - Grant
>> >>
>> >>
>> >> >> >>>>> 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.
>> >> >> >>>
>> >> >> >>> If you're pulling to the backup server, that backup server has
>> >> >> >>> to
>> >> >> >>> be
>> >> >> >>> able to log in to and read all files on the other servers.
>> >> >> >>> Including
>> >> >> >>> e.g. your swap partition and device files.
>> >> >> >>
>> >> >> >> What if I have each system save a copy of everything to be backed
>> >> >> >> up
>> >> >> >> from its own filesystem in a separate directory and change the
>> >> >> >> ownership of everything in that directory so it can be read by an
>> >> >> >> unprivileged backup user?  Then I could have the backup server
>> >> >> >> pull
>> >> >> >> that copy from each system without giving it root access to each
>> >> >> >> system.  Can I somehow have the correct ownerships for the backup
>> >> >> >> saved in a separate file for use during a restore?
>> >> >> >>
>> >> >> >> - Grant
>> >> >> >>
>> >> >> >
>> >> >> > You could just as well use an NFS share with no_root_squash. It is
>> >> >> > really more a question of finding the right combination of tools
>> >> >> > to
>> >> >> > ensure proper separation of concern for server and client.
>> >> >> >
>> >> >> > In fact, I think we are intermixing three distinct problems:
>> >> >> > 1. (Possible) limitations of rdiff-backup with regard to untrusted
>> >> >> > backup servers or clients.
>> >> >>
>> >> >> The limitation is real unfortunately.  All backups created by
>> >> >> rdiff-backup more than a second ago can be deleted something like
>> >> >> this:
>> >> >>
>> >> >> rdiff-backup --remove-older-than 1s
>> >> >> backup@12.34.56.78::/path/to/backup
>> >> >>
>> >> >> > 2. The purely technical question which file transfer protocols
>> >> >> > protect
>> >> >> > against write access from backup server to backup client and
>> >> >> > backup
>> >> >> > client to older backups on the server.
>> >> >>
>> >> >> rdiff-backup doesn't provide those sort of protections.  Do any file
>> >> >> transfer protocols?
>> >> >>
>> >> >> > 3. The more or less organisational question what level of
>> >> >> > protection
>> >> >> > backups need and how fast security breaks have to be detected.
>> >> >>
>> >> >> I think backups should be very well protected and security breaks
>> >> >> should not have to be immediately detected.
>> >> >>
>> >> >> - Grant
>> >> >>
>> >> >>
>> >> >> > I think push vs. pull is just a secondary concern with regard to
>> >> >> > the
>> >> >> > second question and has practically no relevance to the third one.
>> >> >> >
>> >> >> > Regards,
>> >> >> > Florian Philipp