securing rsync backup solutions?

[Daniel Pocock]

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



On 27/12/11 19:54, Kevin Korb wrote:
> 
> 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.

I agree that ssh with key based auth is great, and I already use it for
a range of purposes, for example, I've deployed a range of OpenWRT boxes
that `phone home' using ssh and an RSA key.  With DynDNS recently
cutting their free services, the extra effort I had put in developing an
ssh-based solution instantly proved it's value.

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

Found it: http://rsync.samba.org/ftp/unpacked/rsync/support/rrsync
- - this appears good for some of my concerns, and it even exists in the
Debian package at /usr/share/doc/rsync/scripts/rrsync.gz

I notice it can restrict the flow of data to go from client to server,
that is another nice feature that I had in mind

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

Does rsync provide any way to execute arbitrary server-side code when
used in this manner, e.g. by putting backticks on the command line?  I
think I remember seeing such an example on the web somewhere, and I'm
not sure if rrsync is able to detect that

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

To be more precise: the uid of the rsync process would not be able to
access/modify files owned by root on all filesystems of the backup
server.  It would only presumably have such access on a dedicated
filesystem for storing the backup.

>> - 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 came across this:
http://www.cybernoia.de/software/archivemount/
and this:
http://lwn.net/Articles/131856/

so it does appear Fuse may allow rsync to make arbitrary file
owner/permission changes, and the rsync process would only need to run
as a user with sufficient permissions to read/write the tar file

I'd be particularly interested to know if anyone has tried this and
confirmed it to be robust (or confirmed the opposite)?

Obviously, you wouldn't want to be able to run setuid binaries stored on
such an FS

> 
>> 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 was thinking about using either approach - the fakeroot utility from
Debian, or the --fake-super argument.

As for the direction (push or pull), I am looking to set up a number of
rsyncs:

- - server-to-server: these should be run by cron (so the ssh keys may be
kept without encryption, or unlocked manually at boot) - these may be
either push or pull, but my current testing has been pull

- - laptop-to-server: the laptop tends to roam a lot, network conditions
vary from place to place, and the rsync will be initiated manually, so
it is likely to be a `push' operation, the ssh keys will definitely need
to be encrypted and unlocked manually, but even with that security, I
want to ensure the keys have the minimum level of access possible on the
server - the laptop definitely shouldn't have a key for the root account

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

I agree that has some desirable characteristics

Just out of interest, why not have separate accounts for each of those
activities, with each account having the minimum level of access
necessary?  E.g. you could have a normal user with sudo access to the
lvm commands?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk76LtgACgkQCVo/7lJLCViCrwCfYMifhqmjrno5KkOLIwSsajSI
hWcAnAhMpHtVhqdfPcz5jaJ4g8RvvWvF
=jlAp
-----END PGP SIGNATURE-----