Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision Next revisionBoth sides next revision | ||
rethinking_my_backup_strategy [01.01.2021 18:50] – created Pascal Suter | rethinking_my_backup_strategy [01.01.2021 22:39] – [self-made collection of other tools] Pascal Suter | ||
---|---|---|---|
Line 14: | Line 14: | ||
the main goal of Mobi was to be as portable and simple as possible and to provide incremental backups where i had full snapshots of each backup in a simple folder structure to facilitate restores and make browsing of backups easy. | the main goal of Mobi was to be as portable and simple as possible and to provide incremental backups where i had full snapshots of each backup in a simple folder structure to facilitate restores and make browsing of backups easy. | ||
- | ===== Design Goals for Mobi 2.0 ===== | + | ===== What i want from my new backup solution |
* No more root access should be necessary between any of the involved machines! | * No more root access should be necessary between any of the involved machines! | ||
* untrusted client machines --> we have to assume, that the machine we are creating a backup for could be hacked, so we have to make sure, that not even root on a client machine could delete or tamper with previous benchmarks. We will assume however, that the retention time for the backups is longer than the time the client machine has been hacked, meaning, we don't need to detect if the client is hacked or not.. we will continue to make backups for as long as the hacker wants to and hope that the admin of the hacked client will notice the attack before his oldest backup is purged from the repository | * untrusted client machines --> we have to assume, that the machine we are creating a backup for could be hacked, so we have to make sure, that not even root on a client machine could delete or tamper with previous benchmarks. We will assume however, that the retention time for the backups is longer than the time the client machine has been hacked, meaning, we don't need to detect if the client is hacked or not.. we will continue to make backups for as long as the hacker wants to and hope that the admin of the hacked client will notice the attack before his oldest backup is purged from the repository | ||
Line 63: | Line 63: | ||
* use rsync daemon on the server to provide access to the backup repos for each of the clients. | * use rsync daemon on the server to provide access to the backup repos for each of the clients. | ||
* use '' | * use '' | ||
- | * provide a read-only share via rsync daemon where the client can access all its backups to restore files from. --> **this needs some more thinking / research**, as the backups will contain encrpyted file- and directory names as well as data.. so we would need some other means of sharing the backups in read-only mode but that will retain the orignal linux permissuons | + | * provide a read-only share via rsync daemon where the client can access all its backups to restore files from. --> **this needs some more thinking / research**, as the backups will contain encrpyted file- and directory names as well as data.. so we would need some other means of sharing the backups in read-only mode but that will retain the orignal linux permissions |
* use the same set of tools again to create backups from the primary backup server to the secondary. | * use the same set of tools again to create backups from the primary backup server to the secondary. | ||
Unsolved issues of this solution: | Unsolved issues of this solution: | ||
- | * **file ownership** is retained on all the files, so a file belonging to root on the client will belong to root on the backup server.. this brings some security issues, as for example a privilege escalation could be made possible by backing up a copy of bash belonging to root and with the suid bit set.. once the attacker gets unprivileged user access to the backup server, he could start this shell and become root. So it would be preferrable | + | * **file ownership** is retained on all the files, so a file belonging to root on the client will belong to root on the backup server.. this brings some security issues, as for example a privilege escalation could be made possible by backing up a copy of bash belonging to root and with the suid bit set.. once the attacker gets unprivileged user access to the backup server, he could start this shell and become root. So it would be preferable |
* **restoring files and browsing backups** needs to be simple. for example it should be possible to either use normal '' | * **restoring files and browsing backups** needs to be simple. for example it should be possible to either use normal '' | ||
* backups are encrypted before rsync lays a hand on the file, so '' | * backups are encrypted before rsync lays a hand on the file, so '' | ||
* it would be nice to be able to mount an entire backup, or even all backups at once, via for example sshfs. One could then remount it using gocryptfs on the client to see a decrypted representation. however, this brings another isse: the mount should be read-only, so that a hacked client can't destroy existing backups on the backup server. so either we find a way to create a read-only share using for example NFS (possibly tunnelled over ssh) or we find a way to make them read-only on the backup server already before sharing them through sshfs. | * it would be nice to be able to mount an entire backup, or even all backups at once, via for example sshfs. One could then remount it using gocryptfs on the client to see a decrypted representation. however, this brings another isse: the mount should be read-only, so that a hacked client can't destroy existing backups on the backup server. so either we find a way to create a read-only share using for example NFS (possibly tunnelled over ssh) or we find a way to make them read-only on the backup server already before sharing them through sshfs. | ||
* i have found [[https:// | * i have found [[https:// | ||
+ | |||
+ | ===== First POC - Burp + rsync ===== | ||
+ | with all the arguments above considered, I decided to proceed a burp based solution and just add off-site capabilities to burp. Here is the targeted setup: | ||
+ | * " | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * one needs to make sure that all the necessary paths mentioned in '' | ||
+ | * " | ||
+ | * clients run the burp client and use client-side encryption with a strong password. the following additional core settings are used: | ||
+ | * '' | ||
+ | * '' | ||
+ | * a script on the burp server uses '' | ||
+ | * on the offsite server, a script is called (somehow, haven' | ||