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