From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RQ8VO-00052B-Jy for garchives@archives.gentoo.org; Tue, 15 Nov 2011 02:12:10 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8847A21C081; Tue, 15 Nov 2011 02:12:01 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id CE8F521C025 for ; Tue, 15 Nov 2011 02:11:09 +0000 (UTC) Received: by bkaq10 with SMTP id q10so8357798bka.40 for ; Mon, 14 Nov 2011 18:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HiVALqdHv9PF4sXeqMmwK0gNCUHRnNY3ZDqr+JlIdOM=; b=UBm8C3/sxPLdVAYlOwVhGzZXMnMoC8ZNOaX0KZMgpUMishqn8gpE0K+peu6LymtuzB wPjh3Em5BQ3jFJq0ImBCjfZCjTwZKxZF2RCxY+cF1oIgtMoY8LpllYksFItcALJ53pme Q3TnWuXyugiBgMmtTroaBLv2grqWWPWpM3mXU= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.147.75 with SMTP id k11mr19979186bkv.102.1321323068909; Mon, 14 Nov 2011 18:11:08 -0800 (PST) Received: by 10.204.177.76 with HTTP; Mon, 14 Nov 2011 18:11:08 -0800 (PST) Received: by 10.204.177.76 with HTTP; Mon, 14 Nov 2011 18:11:08 -0800 (PST) In-Reply-To: References: <4EBDC7A5.6020706@orlitzky.com> <4EBDF330.4010306@orlitzky.com> <4EC01E05.2040207@binarywings.net> Date: Mon, 14 Nov 2011 21:11:08 -0500 Message-ID: Subject: Re: [gentoo-user] {OT} Are "push" backups flawed? From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=0015174be32827e79b04b1bc80d3 X-Archives-Salt: 652fc92e-88b1-46a5-95a1-e546aed1f1af X-Archives-Hash: 337e5a92d5f1229375aa66aa5ae7dac8 --0015174be32827e79b04b1bc80d3 Content-Type: text/plain; charset=UTF-8 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" 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 > > --0015174be32827e79b04b1bc80d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

You identified a flaw in the system as you were using it. You're rig= ht, those are flaws. However, you can " fix" those flaws by apply= ing some magic as a sysadmin. That's why several posts in the thread ha= ve mentioned versioning your backups in some fashion. I've mentioned lv= m a couple times. I think someone else mentioned pulling the backup target&= #39;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 locati= on, which is good. You identified a way the backed-up data could be tampere= d 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 i= n such an event.

ZZ

On Nov 14, 2011 8:21 PM, "Grant" <<= a href=3D"mailto:emailgrant@gmail.com">emailgrant@gmail.com> wrote:<= br type=3D"attribution">
> It's out of scope for file transfer protocols; it's a daemon/s= ystem-local
> problem.=C2=A0 Attach pre-event or post-event scripts serverside for a= ny 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. =C2=A0Am I the only one using
automated backups? =C2=A0If not, how is it done properly?

- Grant


>> >>>>> And if I pull, none of my backed-up systems a= re secure because
>> >>>>> anyone
>> >>>>> who breaks into the backup server has root re= ad 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 di= fferent root
>> >>>> passwords
>> >>>> for all boxes, and now you can limit the infiltra= tion.
>> >>>
>> >>> If you're pulling to the backup server, that back= up server has to be
>> >>> able to log in to and read all files on the other ser= vers. Including
>> >>> e.g. your swap partition and device files.
>> >>
>> >> What if I have each system save a copy of everything to b= e backed up
>> >> from its own filesystem in a separate directory and chang= e the
>> >> ownership of everything in that directory so it can be re= ad by an
>> >> unprivileged backup user? =C2=A0Then I could have the bac= kup server pull
>> >> that copy from each system without giving it root access = to each
>> >> system. =C2=A0Can I somehow have the correct ownerships f= or 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 to= ols to
>> > ensure proper separation of concern for server and client. >> >
>> > In fact, I think we are intermixing three distinct problems:<= br> >> > 1. (Possible) limitations of rdiff-backup with regard to untr= usted
>> > backup servers or clients.
>>
>> The limitation is real unfortunately. =C2=A0All backups created by=
>> rdiff-backup more than a second ago can be deleted something like<= br> >> this:
>>
>> rdiff-backup --remove-older-than 1s backup@12.34.56.78::/path/to/b= ackup
>>
>> > 2. The purely technical question which file transfer protocol= s 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. =C2=A0= Do any file
>> transfer protocols?
>>
>> > 3. The more or less organisational question what level of pro= tection
>> > backups need and how fast security breaks have to be detected= .
>>
>> I think backups should be very well protected and security breaks<= br> >> 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

--0015174be32827e79b04b1bc80d3--