Scott H>
I may not understand your situation, but I think you have two issues:
Scott H>
1) rsnapshot server needing root access to XPTO.
Scott H>
2) rsnapshot server containing sensitive files from XPTO.
I agree with Scott, but it sounds like you are asking about #1. You want to preserve file UIDs, GIDs, and permissions, which requires rsync to run as "root" on the XPTO.
To accomplish this, you can use "sudo", or you can just set tight restrictions in root's authorized_keys. You can restrict the SSH key to only allow a (read-only) backup using rsync (and nothing more). If you are particularly paranoid, you could do both.
To use "sudo", you'd need to edit /etc/sudoers to allow the user "backuper" to become root for the backup, but nothing else. I think this will be difficult to configure, because rsnapshot doesn't know how to use "sudo" on the remote side. You'll need some kind of wrapper script to invoke "sudo rsync
[your unique client-side options here]" instead of the normal rsync command. In my opinion, this method would be unnecessarily complicated to configure and document.
Instead, I recommend just using SSH to restrict what the SSH key is allowed to do. Tell SSH that the key used for backup is allowed to run read-only rsync commands, but nothing else; no shell login, no rsync writes, no other commands, etc. Like sudo, this also requires a wrapper script on the client, but unlike sudo, this is easy to configure because there is a working script included with rsync called "rrsync", which enforces read-only backups. Options you'll want to include in the /root/.ssh/authorized_keys are:
- no-pty: Don't offer the user a psuedo terminal. This adds a layer against shell logins.
- no-agent-forwarding: Don't let an attacker use their own agent. (Doesn't really add much here.)
- no-X11-forwarding: Prevents X11 apps. Just another extra layer to reduce attack vectors.
- no-port-forwarding: Do not allow SSH tunnels using this key.
- command="/root/rrsync -ro /" : This forces the script to run on login, with the -ro "read-only" option
This way, the key trusted by root can do the backup, but nothing else. I give a full rsnapshot configuration tutorial using this method here:
http://derek.simkowiak.net/backing-up-multiple-servers-with-rsnapshot/
Regarding the issue #2, you'll need store the files onto an encrypted something (like encrypted partition or EncFS filesystem) locally. If you want your Internet-connected backup copy to be encrypted, such that, if your backup server is compromised, the attacker will not see all your files, then do not run rsnapshot on the backup server. Instead, run rsnapshot locally on the XPTO to a remotely-connected and encrypted file store, such as an encrypted iSCSI partition, an encrypted DRDB device with a remote mirror, or an SSHFS mounted EncFS directory, or some other such system.
Note that using full-disk encrypted on the backup server is not sufficient, as that only protects data at rest (when the server is powered off), and offers nothing once the server is booted up and online. Also, be careful with strong encryption, because if the key is unavailable for any reason, including technical problems or a disgruntled employee, your data is gone forever. Other security considerations are firewall rules and intrustion detection.
Thanks,
Derek Simkowiak
On 01/09/2012 10:29 AM, Scott Hess wrote: On Mon, Jan 9, 2012 at 9:14 AM, Miguel Almeida <miguel < at > almeida.at> ([email]miguel < at > almeida.at[/email]) wrote:
- The current XPTO user I'm using in the NAS' rsnapshot script is "backuper"
(owner of /mnt/backups in XPTO). However, since I'm keeping the original
ownership of the files inside machine1,machine2..., rsnapshot will have
problems with files that have more restrictive permissions [1]
- The only alternative I see is using "root" instead of "backuper" as the
rsnapshot user. However, this leaves me with a security issue: if the NAS is
compromised, my XPTO server will also be compromised as I have the
shared-key to root there. And naturally it'll be compromised entirely (ie,
from /).
Do you see any alternative setup that reduces or eliminates this security
risk?
I may not understand your situation, but I think you have two issues:
1) rsnapshot server needing root access to XPTO.
2) rsnapshot server containing sensitive files from XPTO.
Problem #1 can be resolved by setting the system up just right.
Search for rsync-wrapper on the web. I was not entirely happy with
any of the sites I found, so rolled my own, but cannot find my notes
;-(. Basically, you setup an rsnapshot user which is in sudoers,
tightly control who can be that user (such as not ability to login
except ssh with the public key), and tightly control what that user
can run (only a specific rsync command-line).
Problem #2 requires you to either not backup those files, or to have a
script on the server back them up to a local encrypted something, and
then back _that_ up. Of course, #1 implies that the backup server has
effective read-only access at root level. You could probably extend
the wrapper technique to restrict which directories rsync has access
to, but that might become infinitely annoying
. Perhaps you could
also extend the technique to inject --exclude parameters to rsync, but
I'd worry about accidentally poking holes.
-scott
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free!
http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net ([email]rsnapshot-discuss < at > lists.sourceforge.net[/email])
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
