Re: securing rsync backup solutions?
> - - 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 You may be interested in the approach listed at the following URL : http://www.lbackup.org/synchronizing_disk_images_between_machines Unfortunately, the URL above is aimed specifically towards Mac OS X systems. However, I am hopeful that there is a similar (band based) disk image system available for GNU/LINUX. If you find something like that then please let me know. Using a virtual file system allows you to save permissions within the disk image and then push the changes within the disk image to a remote server without requiring root access to the remote server. Finally, Kevin's comments regarding push and pull backups are worth keeping in mind. - This email is protected by LBackup, an open source backup solution. http://www.lbackup.org -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: securing rsync backup solutions?
On 27.12.2011 19:26, Daniel Pocock wrote: > > > For full system backup, rsync obviously needs to run as root on the > machine being backed up > > - 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)? The nearest i can see with rsync is "--fake-super", which doesn't need root on the backup-server-side but needs a filesystem with enabled xattrs. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: securing rsync backup solutions?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/27/11 15:47, Daniel Pocock wrote: > > > 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 When you use rsync over ssh you can provide an arbitrary --rsync-path which can include just about anything. For instance I have used - --rsync-path '/usr/bin/ionice -c3 /usr/bin/rsync' Since rrsync is a forced command that would be completely ignored. > >>> - 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. > The only way I know to restrict root in that way is with rrsync, scponly, rssh, or similar restrictions. Even a chroot isn't going to do it since root can easily escape from a chroot. >>> - 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 That is a neat idea. If it ends up working for you I would like to hear about it. > > 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
Re: securing rsync backup solutions?
On Tue, 27 Dec 2011, Daniel Pocock wrote: > For full system backup, rsync obviously needs to run as root on the > machine being backed up > Not exactly, .. it is trivial to setup a root key on the 'to be backed up' machine that only authorizes the rsync command. Lee -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: securing rsync backup solutions?
-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 ar
Re: securing rsync backup solutions?
-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. ke...@futurequest.net (work) Orlando, Floridak...@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- -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.
securing rsync backup solutions?
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) ? - are there any ideal examples of wrapper scripts that set up a fakeroot environment (either on each invocation or wrapping the rsync daemon)? - 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 ? - 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. - 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)? 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 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
RE: Securing Rsync
Thanks to all for your help. I got it working and am in the process of refining my configuration to do what I need it to do. I wish I could tell you everything I did to get it working but it would be too confusing. I finally started over and that's what made everything start working. Thanks again, Mike Winfrey -Original Message- From: Max Bowsher [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 10:49 AM To: Mike Winfrey; [EMAIL PROTECTED] Subject: Re: Securing Rsync Mike Winfrey wrote: > I have a rsync server set up on a win2k server and a win xp pro > computer is my client. It's working very well doing the anonymous > transfers. However, I've tried setting up a password file and not > having any success. > > rsync.secrets on my rsync server > user:password > > I run the following command string on my client computer: > C:\rsync\rsync.exe -av --delete --password-file=/rsync/rsync.secrets > "/cygdrive/C/Documents and Settings/All Users" > "user@server::serverbu/" > > the password file on my XP machine looks just like the one on the > server. There is your problem, then. From the manpage: --password-file (The file) should contain just the password as a single line. > I tried "set rsync_password=password" as well but that doesn't work > either. rsync_password != RSYNC_PASSWORD Max. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: Securing Rsync
On cygwin and Netware, I think that message is coming from the default strict modes in rsyncd.conf. For these, be sure to add "strict modes=no" in the rsyncd.conf. Lee -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Securing Rsync
I seem to remember that one of the links in "resources" at www.rsync.org
pointed to a page that talked about running rsync on a Win32. This page
warned for the use of passwords. But if it works, it works, right?
Kind regards,
Bart Coninckx
Network Administrator
CNE, ASE
*
Sita ICT Services
Lilsedijk 19
B-2340 Beerse
Belgium
e-mail: [EMAIL PROTECTED]
Tel: + 32 (0) 14 62 28 22
Fax: + 32 (0) 14 62 41 47
*
== Disclaimer ==
The information in this email is confidential, and is intended solely for
the addressee(s). If you are not the intended recipient of this email
please let us know by reply and then delete it from your system;
you should not copy this message or disclose its contents to anyone,
not even by forwarding it.
Due to the integrity risk of sending emails over the Internet,
Sita ICT will accept no liability for any comments and/or attachments
contained within this email.
== Disclaimer ==
"Max Bowsher"
<[EMAIL PROTECTED]To: "Mike Winfrey"
<[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
>cc: <[EMAIL PROTECTED]>
Subject: Re: Securing Rsync
27/01/2003
17:49
[EMAIL PROTECTED] wrote:
> It's my understanding that passwords don't work in a cygwinned rsync.
I see no reason why that should be the case.
Max.
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Securing Rsync
[EMAIL PROTECTED] wrote: > It's my understanding that passwords don't work in a cygwinned rsync. I see no reason why that should be the case. Max. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Securing Rsync
Mike Winfrey wrote: > I have a rsync server set up on a win2k server and a win xp pro > computer is my client. It's working very well doing the anonymous > transfers. However, I've tried setting up a password file and not > having any success. > > rsync.secrets on my rsync server > user:password > > I run the following command string on my client computer: > C:\rsync\rsync.exe -av --delete --password-file=/rsync/rsync.secrets > "/cygdrive/C/Documents and Settings/All Users" > "user@server::serverbu/" > > the password file on my XP machine looks just like the one on the > server. There is your problem, then. From the manpage: --password-file (The file) should contain just the password as a single line. > I tried "set rsync_password=password" as well but that doesn't work > either. rsync_password != RSYNC_PASSWORD Max. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Securing Rsync
It's my understanding that passwords don't work in a cygwinned rsync. You might consider limiting the modules to a certain trusted IP-address . Kind regards, Bart Coninckx Network Administrator CNE, ASE * Sita ICT Services Lilsedijk 19 B-2340 Beerse Belgium e-mail: [EMAIL PROTECTED] Tel: + 32 (0) 14 62 28 22 Fax: + 32 (0) 14 62 41 47 * "Mike Winfrey" .com>cc: Sent by: Subject: Securing Rsync rsync-admin@lists .samba.org 27/01/2003 16:18 I have a rsync server set up on a win2k server and a win xp pro computer is my client. It's working very well doing the anonymous transfers. However, I've tried setting up a password file and not having any success. rsyncd.conf on my server: use chroot = false strict modes = false hosts allow = * [serverbu] auth users = user path = c:/serverbu read only = no list = no secrets file = c:/rsync/rsync.secrets rsync.secrets on my rsync server user:password I run the following command string on my client computer: C:\rsync\rsync.exe -av --delete --password-file=/rsync/rsync.secrets "/cygdrive/C/Documents and Settings/All Users" "user@server::serverbu/" the password file on my XP machine looks just like the one on the server. I get an error stating "password file must not be other-accessible continuing without password file using RSYNC_PASSWORD environment variable. @ERROR: auth failed on module serverbu" I tried "set rsync_password=password" as well but that doesn't work either. Any ideas on how I can get this working with passwords. Thanks, Mike Winfrey -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Securing Rsync
I have a rsync server set up on a win2k server and a win xp pro computer is my client. It's working very well doing the anonymous transfers. However, I've tried setting up a password file and not having any success. rsyncd.conf on my server: use chroot = false strict modes = false hosts allow = * [serverbu] auth users = user path = c:/serverbu read only = no list = no secrets file = c:/rsync/rsync.secrets rsync.secrets on my rsync server user:password I run the following command string on my client computer: C:\rsync\rsync.exe -av --delete --password-file=/rsync/rsync.secrets "/cygdrive/C/Documents and Settings/All Users" "user@server::serverbu/" the password file on my XP machine looks just like the one on the server. I get an error stating "password file must not be other-accessible continuing without password file using RSYNC_PASSWORD environment variable. @ERROR: auth failed on module serverbu" I tried "set rsync_password=password" as well but that doesn't work either. Any ideas on how I can get this working with passwords. Thanks, Mike Winfrey -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
