mobi_2.0

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
Last revisionBoth sides next revision
mobi_2.0 [31.12.2020 08:50] – [self-made collection of other tools] Pascal Sutermobi_2.0 [31.12.2020 09:00] – [Burp] Pascal Suter
Line 48: Line 48:
 ===== possible solutions ===== ===== possible solutions =====
 ==== Burp ==== ==== Burp ====
-as stated above, use burp, maybe in hardlink mode or with a BTRFS storage underneath and then create a custom off-site backup (by using BTRFS Snapshots, or some fancy rsync methods). +Since burp has all the features we want, it seems like it might be worth to just dig into the remote-backup issue and fix that in whatever way i can find. 
  
 +possible solutions to consider are: 
 +  * use burp in hardlink mode and try if using rsync is simpler now
 +  * use burp with a BTRFS or ZFS storage underneath and then create a custom off-site backup (by using BTRFS Snapshots). 
 +    * BTRFS seems to be a good choice as it is designed to provide easily transferrable snapshots.. by backing up each snapshot to the offsite server, we could make sure, that even if the entire btrfs filesystem is messed up on the main backup server, we would still have intact old snapshots on the secondary backup server. 
 +    * ZFS on the other hand provides erasure coding through the various radz2 and so on levels, which means we will loose less harddisk space and can work without expensive and error prone raid controllers in our backup systems, that would be a nice side-effect
 +    * the advantage of any of these snapshot method is, that they will work no matter what the burp developers decide to change in the future about how they store backups.. so we don't need to mess with internals of burp to get a remote backup running, where with rsync we need to know what burp does exactly and how we can back up the right data to preserve this functionality. 
 +
 +the main advantages of using burp over a selve made variant are
 +  * burp is tested and trusted by many
 +  * burp already solves the permission issues 
 +  * burp provides a way to browse client-side encrypted backups already
 +  * we only have to implement a secondary backup solution. so this is probably a lot less work over all 
 +  * we get additional features such as windows backups for free which might be appreciated in the future. 
 ==== self-made collection of other tools ==== ==== self-made collection of other tools ====
 so "self made" is a bit flexible here.. what i mean is a larger script that will use a combination of several tools together:  so "self made" is a bit flexible here.. what i mean is a larger script that will use a combination of several tools together: 
Line 61: Line 74:
 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 to change at least file ownership to a dedicated user and limit the possibilities for an attack   * **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 to change at least file ownership to a dedicated user and limit the possibilities for an attack
-  * restoring files and browsing backups needs to be simple. for example it should be possible to either use normal ''rsync -l'' or even better, to mount complete backups from the backup server onto the client server and then browse through them. however, this is currently not so simple because: +  * **restoring files and browsing backups** needs to be simple. for example it should be possible to either use normal ''rsync -l'' or even better, to mount complete backups from the backup server onto the client server and then browse through them. however, this is currently not so simple because: 
     * backups are encrypted before rsync lays a hand on the file, so ''rsync -l'' will list encrypted file- and directory names and it will download encrypted files which will then need to be decrypted.. so finding the latest version of a file that contains a string X for example is very cumbresome      * backups are encrypted before rsync lays a hand on the file, so ''rsync -l'' will list encrypted file- and directory names and it will download encrypted files which will then need to be decrypted.. so finding the latest version of a file that contains a string X for example is very cumbresome 
     * 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.