rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Prevent rdiff-backup from deleting?


From: Grant
Subject: Re: [rdiff-backup-users] Prevent rdiff-backup from deleting?
Date: Tue, 15 Nov 2011 08:49:04 -0800

>> Because of this, I think there is a gaping security hole in any
>> automated rdiff-backup scheme that pushes backups to the server.
>> Pulling to the backup server eliminates this problem, but if the
>> backup server is compromised, the infiltrator has root read access to
>> each system being backed up and can thereby compromise each of those
>> systems as well.
>>
>> Is rdiff-backup ill-suited to automated backups?
>
> This topic has been discussed here many a time.
> There is always a trade-off between security and ease of use.
> If you do push-style backups, having root access on the main system gives an
> attacker access to the backup system, so the backup has to be considered
> compromised when the main system is compromised. Depending on what purpose
> you keep backups for, this may not be what you want.
>
> If you do pull-style backups, and the backup system is compromised, the
> attacker indeed has root access to all backed up systems (possibly more than
> one). If you do pull-style backups and the main system is compromised, you
> could restore from a 'clean' increment.
>
> However, a compromised main system can go unnoticed for weeks or even
> months. So backups may have become compromised as well, and when keeping
> less history than this detection period, there would be no way to go back to
> a clean state after that time. Again, it all depends on the exact use of the
> backup tool. You could e.g. use rdiff-backup for user's files, and some
> other tool for system backups.
>
> All in all, this is not very specific to rdiff-backup. Other push or pull
> style backups have the same 'problems'.
>
> The method I prefer is having a backup server that is not reachable from the
> outside. Currently a box behind a NAT gateway, but could as well be a fully
> firewalled IP address with only outgoing traffic allowed to the hosts that
> are to be backed up. (Possibly even one at a time.)

The downside of pull-style backups is that if the backup server is
compromised, the backed-up systems can be compromised easily since the
infiltrator would have root read access to those systems.  Your
solution is to make it harder for the backup server to be compromised.
 That sounds pretty good, but how do you access that system remotely?

- Grant


> Any automated system can be fooled when not supervised properly ;-)
>
>
> --
> Maarten



reply via email to

[Prev in Thread] Current Thread [Next in Thread]