> 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" <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
