[Dirvish] Client -> Backup Server (Rsyncd)

Matthew Whittaker-Williams m.whittaker-Williams at iu.nl
Wed Feb 1 05:22:14 EST 2006


Keith Lofstrom wrote:

>On Tue, Jan 31, 2006 at 01:09:41PM +0100, Matthew Whittaker-Williams wrote:
>  
>
>>Hey,
>>
>>I`ve been reading through the docs and some howto`s on the web about 
>>dirvish.
>>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 
>>to backup.
>>
>>Like say:
>>
>>From the client there is an ssh tunnel towards the rsyncd daemon on the 
>>backup server.
>>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 
>>the backupserver.
>>
>>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 
server.

>   account on the server, but there still can be problems with spoofing.
>
>Outrageous corrolary:
>   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 :)

Thanks again.

With kind regards

Matthew



More information about the Dirvish mailing list