securing rsync backup solutions?

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 12/27/11 13:26, Daniel Pocock wrote:
> 
> 
> For full system backup, rsync obviously needs to run as root on
> the machine being backed up
> 
> For preservation of user/group/permissions info, rsync also
> typically needs to be run as root on the machine storing the backup
> - although there appear to be various ways to avoid this (e.g.
> using fakeroot -s, or running rsync inside a Xen VM which only
> stores the backup of one host)
> 
> Can anyone comment on some of the following:
> 
> - is it more secure to run rsync as a command within ssh (probably
> using command=some_wrapper in authorized_keys) or to run an rsync
> daemon (with VPN and/or restricted port forwarding, e.g.
> permitopen="localhost:873" in authorized_keys) ?

I prefer ssh both for encryption and superior authentication (key
authentication).  It is easy to configure sshd to only allow root to
login using an ssh key and you can restrict where that key can be used
and what it can do.

I would actually go as far as to say forget rsyncd for system backups.
 That just isn't what it was designed for.  With rsync over ssh you
don't even need to bother with the rsyncd.conf file.

> - are there any ideal examples of wrapper scripts that set up a
> fakeroot environment (either on each invocation or wrapping the
> rsync daemon)?

It isn't exactly what you are asking for but check out rrsync in the
support directory of the rsync source tree.

> - is there any facility for command line filtering (or any example
> of such a wrapper script) when running in ssh mode?  E.g. to stop
> people using `some nasty rm command` or detect attempts to steal 
> ../../../secret_file ?

Again, see rrsync though it is for rsync over ssh not rsyncd.

> - as an alternative to fakeroot, is there any type of filesystem
> that can be run on the backup server that would allow non-root
> processes to manipulate file ownership and permissions?  I couldn't
> find examples of this in the common Linux filesystems.

I am not aware of one and I think most people would consider it to be
a security violation.

> - is there any possibility for the rsync process on the backup
> server to keep the destination files within a tar file (or some
> virtual filesystem that is backed by a tar file) and then the
> owner/permission data can be stored in the tar file (without
> needing to run as root)?

There might be something in Linux's fuse.  There is just about
everything in fuse.

> I've seen a few examples online that answer parts of these
> questions, but nobody has shared a complete recipe, and some of the
> issues are not addressed anywhere

The first question is do you want to pull or push your backups.  That
changes things big time.  Since you are talking about using fakeroot
(I assume you mean --fake-super) I assume you are planning to push
your backups from the client to the backup server.  This does have the
advantage of only needing root on client side.  OTOH, it could allow
an attacker who gains control of your client to infect or destroy your
backups of a system.

I prefer to pull my backups.  This means that I run as root on both
ends but it also means that I can make an ultra secure backup server
that has no other services running.  It can ssh as root to any other
system by key but that key will only work from its IP address.  I
could make it so that key can only run rsync (or rrsync) but I don't
because I also use it to gather non-file information such as partition
tables and to activate LVM2 snapshots.

By ultra secure backup server I mean it is only powered on while
backups are running (or if I need to do a restore of course), has no
user accounts, only listens for ssh connections, ssh connections only
allowed from specific IP addresses, sshd only allows authentication
via keys.

Here is something I wrote up for my local LUG:
http://sanitarium.net/golug/rsync_backups_2010.html
It explains my rationale for doing backups the way I do them as well
as some tricks I have learned.  I also tend to be in #rsync on
freenode btw.

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk76FEgACgkQVKC1jlbQAQfvtQCguELG7E9kHWzIHrKyFKKOncoi
OMAAoIIQ0KTRIM/XjLHg5O1XO7rNv1fs
=fXTZ
-----END PGP SIGNATURE-----