[Dirvish] Client -> Backup Server (Rsyncd)
m.whittaker-Williams at iu.nl
Wed Feb 1 10:22:14 UTC 2006
Keith Lofstrom wrote:
>On Tue, Jan 31, 2006 at 01:09:41PM +0100, Matthew Whittaker-Williams wrote:
>>I`ve been reading through the docs and some howto`s on the web about
>>It seems to me Dirvish can only be configured to backup the clients from
>>the backup server.
>>So I was wondering is there a way to setup dirvish the oposite direction
>>From the client there is an ssh tunnel towards the rsyncd daemon on the
>>And from te client runs the cronjob that normaly runs on the server side
>>and it sends the files to vaults that could perhaps be created by using
>>the rsyncd daemon.
>>The reason for questioning this is mainly for security.
>>Alot of backup programs out there use the BackupServer ( dump/rsync/tar
>>) -> Client ( Partitions ) > ( Directory backup server) backup scheme.
>>But this requires root access from the Backupserver itself which makes
>>it more vulnerable to attacks and when broken into its possible to break
>>into the rest of your machine`s.
>>Ofcourse configuring the command only by ssh works just fine, but
>>possible there is a way arround and then your a long way from home.
>>It would be ideal to let the clients backup the needed files, instead of
>>Well any comments about this are appreciated.
>I need to add this to the FAQ because it comes up often.
>Outrageous statement #1:
> If the backup server is compromised, everything is compromised. The
> backup server, after all, may contain copies of all the security
> information that is stored on the client.
>Outrageous statement #2:
> If clients can control writing to the backup server, then they
> can compromise the backup server, because they can potentially read
> and write any data on the backup server. This can be mitigated by
> making each client instance control a separate, less-privileged
Not if this is done by a seperate user to keep security tight on backup
> account on the server, but there still can be problems with spoofing.
> If any of the clients are compromised in this "client push"
> scenario, potentially every machine is compromised.
>That is why dirvish does "server pull" backups. There are also
>scheduling advantages - you don't have a bunch of clients fighting
>over network bandwidth and disk I/O.
I agree on your statement about I/O and bandwith, though limiting
bandwidth on rsync client side will prevent this.
>If you are really worried about the server getting control of the
>client, then you can configure rsync on the client so that the server
>can only access certain portions of the data. That makes bare metal
>restores difficult, but if that is what you want ... :-/
>Bottom line: the backup server is where the crown jewels are kept.
>The backup process should be designed to protect them. If you are
>very paranoid, the backup server should be a separate machine
>offering NO incoming services, only outbound ssh. It should not
>used for email or web browsing or other compromisable activities,
>and restores should be initiated from the console of the backup
>server only, perhaps by creating a temporary image on another
>machine that the client can access. If the clients can initiate
>restores, so can the bad guys.
>There are other programs that use "client push" (backuppc?). If
>you are on a secure network, and every machine on it is secure,
>this is not too dangerous. The windows rsync client doesn't
>play well with ssh, but you can client push windows rsync back
>through ssh to the server without breakage. Typically, though,
>the windows machines should be accessed over secure networks only -
>if you need to move windows backup data over insecure networks, you
>should connect locally to a Linux/BSD/Solaris box, and tunnel from
>that over the insecure network.
I thank you for your well stated response.
I`ll take your arguments in considuration and try different setups to
find the most suitable situation for me :)
With kind regards
More information about the Dirvish