Hi,
> for similar reasons, I NFS mount a directory from my NFS server on the
> BackupPC server and do a local backup through 'sudo'. The directory is
> exported anyway, and I still use the name of the NFS server for the
> configuration (and thus ping that machine). Only my ClientCmd
> happens not
> to contain 'ssh' or '$host'.
>
> I don't know if this is applicable to your server too, I just
> wanted to
> mention the idea. Note though, that NFS is probably slower than ssh.
Well, lets explain my situation, I'm sure I would give me [at least]
*your* best solution, because using NFS was one of my thought at the
beginning.
- MainServer is the server where all important data are store (on a
raid-1). It's located inside the building on a internal 1Gbyte network.
- BackupServer is a tiny NAS, a DNS-323, running a linux on a ARM. We
want to locate it outside the building (namely in my home basement),
with an internet access.
The goal is to be sure we won't lost our data even if the building burn.
And as those data are critical and confidential, I want to be sure
that every data transmitted by internet are crypted and also that
access to the backupserver are secured.
I have two options :
1) Running backuppc on MainServer and using BackupServer just as a
deported hard-drive. This, I understand, maybe set up with NFS and a
VPN, but it seems that it is not easy to setup, and further more with
the DNS-323. But maybe There are solution that I didn't imagine? like
a ssh connection and a link to a pipe? I just don't know how to do
that for now.
2) Running backuppc on BackupServer connecting to MainSever through
ssh+rsync. There are a few tutorial using backuppc on a DSN-323, with
rsyncd, so it seems to work pretty well.
I choosed to do the second solution, so BackupServer would be
autonomous.
What do you think? Which solution is the easiest?
For now my problem is that I still get error where peolple using a
DNS-323 don't...
After that, dealing with user and permission would be the cherry on
the cake, as The only port open on the two server would be port 22,
something that I can change to make security harder to brake.
I promess, I will write a tutorial in the backuppc wiki if I can get
a working solution! ;-)
Cheers,
Bruno
> Gian Carlo Stagni wrote on 2008-07-29 23:49:29 +0200 [Re: [BackupPC-
> users] Why should I use root to connect to host]:
>> Chris Robertson ha scritto:
>>> brunal wrote:
>>>>
>>>> One question that I dont understand : can I use another user than
>>>> root to connect to my host?
>>>
>>> The only reason to connect as root is to make sure you have
>>> access to
>>> all the files you want to back up.
>> I believe you can properly verify it by loggin in as the effective
>> user
>> (backuppc) that performs the backup.
>>
>>>> And to my host side, a user backuppc exist and have access to
>>>> all the
>>>> necessary folder and file. Should this configuration work?
>>> Since you have this condition met, you should be fine.
>> IMHO this is a security risk if sudo is not used.
>
> Permissions set in some specific way are *not* a security risk,
> provided they
> are meant to be set like that. You can export public(ly readable)
> content from
> a secure server and do backups without special priviledges. You can
> give the
> backuppc user access to confidential content, as long as you
> realize that you
> are doing just that: giving access to confidential content. Whether
> you do
> that via permissions or via sudo is irrelevant. If someone gains
> access to the
> backuppc user account on the BackupPC server, he can access the
> content. There
> is no way around that.
>
> An attacker gaining a root shell on the server is more harmful than
> "just"
> access to the data (because a root shell usually gives you that
> access anyway),
> so not using root ssh access makes perfect sense.
>
> I agree that sudo is a more comfortable way to give the backuppc
> user access
> to *all* files, but trying to limit that to just some files can be
> a pain. In
> any case, you have [at least] the rsync command running with root
> priviledges,
> which may be an attack vector you want to avoid. I admit I'm not
> really
> concerned about this risk, but I wouldn't say "nothing running with
> root
> priviledges" is security-wise inferior.
>
> Of course, 'chmod -R o=u /' just so the backuppc user can access
> everything is
> *not a good idea*, but I suspect that is not what Bruno had in
> mind :-).
>
> Regards,
> Holger
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
