Backup Central

I'm using rdiff-backup in an automated "push" arrangement with access
to the backup server provided via SSH keys and restricted to the
rdiff-backup command like command="rdiff-backup --server". I think an
infiltrator could delete a compromised machine's backups from the
backup server like this:

rdiff-backup --remove-older-than 1s backup < at > 12.34.56.78::/path/to/backup

Is there any way to prevent something like that from happening?

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

I think (but haven't tried) you could alter the rdiff-backup option text
like this (this is under Ubuntu 10.04, the location might differ with
another OS):

sed -i 's/remove-older-than/remove-older-thax/g'
/usr/share/pyshared/rdiff_backup/*.py

So unless an infiltrator knew the new command name (remove-older-thax in
the example above), they couldn't use it.

Dominic

On 11/11/2011 20:51, Grant wrote:
I'm using rdiff-backup in an automated "push" arrangement with access
to the backup server provided via SSH keys and restricted to the
rdiff-backup command like command="rdiff-backup --server". I think an
infiltrator could delete a compromised machine's backups from the
backup server like this:

rdiff-backup --remove-older-than 1s backup < at > 12.34.56.78::/path/to/backup

Is there any way to prevent something like that from happening?

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki


_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

I think (but haven't tried) you could alter the rdiff-backup option text
like this (this is under Ubuntu 10.04, the location might differ with
another OS):

sed -i 's/remove-older-than/remove-older-thax/g'
/usr/share/pyshared/rdiff_backup/*.py

So unless an infiltrator knew the new command name (remove-older-thax in the
example above), they couldn't use it.

The problem is that I run rdiff-backup in a crontab and one of the
commands there includes --remove-older-than. That's a very creative
solution though.

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?

- Grant


I'm using rdiff-backup in an automated "push" arrangement with access
to the backup server provided via SSH keys and restricted to the
rdiff-backup command like command="rdiff-backup --server".  I think an
infiltrator could delete a compromised machine's backups from the
backup server like this:

rdiff-backup --remove-older-than 1s backup < at > 12.34.56.78::/path/to/backup

Is there any way to prevent something like that from happening?

- Grant

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

On Mon, 14 Nov 2011, Grant wrote:

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.)

Any automated system can be fooled when not supervised properly


--
Maarten

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

A simple solution is to edit the python source code for rdiff-backup on
the backup server and restrict what it will accept for the
--remove-older-than argument.

You could also have two different versions of rdiff-backup on the backup
server. One accessed remotely that has this option completely disabled
(by editing the source). The other version would be the original code
but can only be accessed from the local backup server.

Sarel

On 11/14/2011 9:03 PM, Grant wrote:
The problem is that I run rdiff-backup in a crontab and one of the
commands there includes --remove-older-than. That's a very creative
solution though. 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? - Grantolutionsfirst.com.au/index.php/RdiffBackupWiki

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

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

_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki