> 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
