Backup Central

On Sat, 17 Apr 2004 23:58, Jan-Frederik wrote:
But this doesn't really solves the problem, or does it? What is to stop
an attacker from login in as a non-root user on the client machine,
executing sudo rsync, and overwriting /etc/shadow with a version in
which he has altered the pasword crypt for the root user?

It wont stop an attacker from doing that, no. But as pointed out by Daniel
Poelzleithner he will already have access to the data on the machines. That
includes access to the /etc/shadow file which he can go away and find out all
your passwords using a cracking tool, then get in via ssh anyway.

I personally now use the rsyncd for machines that are on their own
private network (ie DMZ) as it is easier to back up both unix and win
machines this way. If you are using public networks you are best to use
ssh with a non-root user and sudo.

So rsyncd+ssh for use public networks, combined with backuppc would not
be possible in your opinion?

I took a quick look at the website you originally posted, it seemed to suggest
that the rsyncd server was being spawned via the shell over ssh but it didn't
really say that the data going to/from the rsync server would then be
encrypted. If that isn't the case then you are just as well off having an
rsyncd server with the plaintext passwords.

An option that you do have is to have the rsyncd server running, allowing
connections only to localhost. Have a pre-backup script start up an ssh
tunnel to the server and port forward the rsyncd port on the machine being
backed up to the backup machine, then get the backup to use the encrypted
link. I'm not sure on the specifics but it's a start.

Another option would be to have a vpn such as openvpn / vtund / tinc whatever
(entirely different thread) between the backup machine and all others to
encrypt the data. By using a good vpn it should be as secure (maybe more)
than using ssh.

Regards,
Josh.


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Jan-Frederik writes:

An option that you do have is to have the rsyncd server running, allowing
connections only to localhost. Have a pre-backup script start up an ssh
tunnel to the server and port forward the rsyncd port on the machine being
backed up to the backup machine, then get the backup to use the encrypted
link. I'm not sure on the specifics but it's a start.

Very interesting approach! I will definately explore this possibility.
Thanks for the idea.

Strange however, that these security concerns are discussed so little in
the backuppc documentation?

There is a section on "Security issues" in the documentation,
that, among others, includes:

=item SSH key security

Using ssh for linux/unix clients is quite secure, but the
security is only as good as the protection of ssh's private
keys. If an attacker can devise a way to run a shell as the
BackupPC user then they will have access to BackupPC's private
ssh keys. They can then, in turn, ssh to any client machine as
root (or whichever user you have configured BackupPC to use).
This represents a serious compromise of your entire network.
So in vulnerable networks, think carefully about how to protect
the machine running BackupPC and how to prevent attackers from
gaining shell access (as the BackupPC user) to the machine.

I've tried to catalog each area of potential weakness that people
should understand so they can evaluate the risk.

I'm happy to include documentation on best-practices if people can write
up their solution.

For example, someone suggested using ssh-agent to provide better
security for the private keys.

Craig


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Craig Barratt wrote:

I'm happy to include documentation on best-practices if people can write
up their solution.


Well, perhaps the setup we have figures out could be usefull:

On each [client] runs a rsyncd server with the following config:

-------------------------
uid = root
gid=nogroup
use chroot = no
max connections = 3
syslog facility = daemon

[backuppc]
path = /
comment = Root directory
read only = true
list = false
strict modes = true
hosts allow = [IP adress of the backup server]
auth users = backuppc
secrets file = /etc/rsyncd.secrets
-------------------------

On each [client] we insure that only the [backup server] can connect to
the rsyncd:

/sbin/iptables -A INPUT -p tcp -s ! [IP adress of the backup server]
--dport 873 -j DROP

tcp port 873 is rsync ...
-------------------------

And to make sure that the authentication between [client] & [backup
server] remains secure, we implemented a VPN connection between each
[client] & [backup server] using vtun (http://vtun.sourceforge.net/)

Benefits of this setup when compared to the rsync + ssh keys
implementation: Even if the [backup server] is compromised, he'd still
only have filesystem read access on each [client]

Drawbacks: Each additional [client] requires a new vtund (this might be
avoided by using subnets instead of single IP's)

We'd love comments (positive & negative) about this setup.

Greetings,

Jan-Frederik

Am Samstag 24 April 2004 20:58 schrieb Jan-Frederik:
...
On each [client] runs a rsyncd server with the following config:

-------------------------
uid = root
gid=nogroup
use chroot = no
max connections = 3
syslog facility = daemon

[backuppc]
path = /
comment = Root directory
read only = true
list = false
strict modes = true
hosts allow = [IP adress of the backup server]
auth users = backuppc
secrets file = /etc/rsyncd.secrets
-------------------------

I would also set "max connections" to 1, because there should never be more
than one backup running.

And I would add:
hosts allow = <the-ip-you-need-to-allow>
hosts deny = 0.0.0.0/0

Even when you firewall your box, it's not a failure to add the hosts
allow/deny line...

On each [client] we insure that only the [backup server] can connect to
the rsyncd:

/sbin/iptables -A INPUT -p tcp -s ! [IP adress of the backup server]
--dport 873 -j DROP

tcp port 873 is rsync ...
-------------------------

And to make sure that the authentication between [client] & [backup
server] remains secure, we implemented a VPN connection between each
[client] & [backup server] using vtun (http://vtun.sourceforge.net/)

Benefits of this setup when compared to the rsync + ssh keys
implementation: Even if the [backup server] is compromised, he'd still
only have filesystem read access on each [client]

Drawbacks: Each additional [client] requires a new vtund (this might be
avoided by using subnets instead of single IP's)

We'd love comments (positive & negative) about this setup.

Your setup is nice... We use more or less the same setup. Because I like
OpenVPN very much (really great product) we prefer that over vtun. OpenVPN
uses the complete openssl pki (with certs or shared secrets) for encryption
and authentification. http://openvpn.sf.net

Another benefit of openvpn: there are clients available for windows, mac os x,
bsd and linux available. So with openvpn and rsyncd it should also be
possible to backup windows pc. I never tried it, because for a professional
backup of windows pc you still need professional software like veritas or
other.

rsync(d)/smb isn't able to backup open files. But I read that there will maybe
a rsyncd port for windows which will be able to process these files to, so
maybe then backuppc is ideal for windows hosts too.

Greetings,

Jan-Frederik

In my opinion rsync is really great for incrementel backups, but rsync itself
isn't secure enough...

It would be very nice if rsync would use a encryption for transmitting the
data... If rsync would use the "passwort" from the rsyncd.secrets file as
shared secret key it would be perfect...

--Ralph


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

On Sun, 25 Apr 2004 04:58, Jan-Frederik wrote:
Drawbacks: Each additional [client] requires a new vtund (this might be
avoided by using subnets instead of single IP's)

You might like to look at tincd. It makes managing multiple vpn's very easy.
I've used vtun, tincd and openvpn and without starting a vpnwar...

vtun is simple to set up and use but multiple connections can get confusing.
Has security issues that seem to have been ignored, as it doesn't claim to be
the most secure vpn.
tincd is reasonably easy to set up and is designed for multiple connections so
comes into its own after >3 vpn tunnels (and has windows clients too) - the
newer versions fix similar security issues that vtun had. In my opinion this
is the one to use.
openvpn seems to be the most secure but has the same multi-connection drawback
as vtun. Is also slow compared to vtun and tincd.

Remember that iptables can also be used to limit the machines connecting on
the vpn. Yes I know ip addresses can be spoofed but it just adds some more
complexity to someone breaking in.

Regards,
Josh.


-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/