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.
ZZ On Nov 14, 2011 9:34 PM, "Grant" <emailgr...@gmail.com> wrote: > > 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" <emailgr...@gmail.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 > >
