Sample Header Ad - 728x90

duplicity: how to prevent malicious user from messing with backups

0 votes
0 answers
129 views
I'm using duplicity on almost every host I'm maintaining for creating backups to a remote location (calling it "backup host"). How often and when to do full or incremental backups depends on the host and its use-case. I'm not just trying to protect myself from typical failure (human error, hardware-/software, etc.), but also to recover from a potential attack. In my cases I'm using the SSH/SFTP backend for running such duplicity backups. Since duplicity needs read/write access to the backup host, somebody gaining control of the the to-be-backed-up hosts can also connect to the backup host and delete / mess with respective backups. Despite that -- according to my understanding -- the to-be-backed-up hosts also /need/ to delete files on the backup host: In order not to run out of space, my to-be-backed-up hosts frequently call duplicity with remove-all-but-n-full- and remove-all-inc-of-but-n-full-actions in order to delete old backups. Such cleanups, as far as I was told, can't happen on the backup host itself, due to the backups -- incl. duplicity's metadata regarding which files belong to which set -- being encrypted, whereas respective private key (GPG) is not present on the backup host. So, to do such cleanups on the backup host, I'd have to do so based on file timestamps, which might result in corrupted/partial backup sets. Currently, to "protect" myself from such an attack, I have a second backup host regularly connecting to the primary backup host which rsync's all backup data from the primary to the secondary backup host. But here again I'm facing already above mentioned issues: - I'm just copying files from the primary to the second backup host without any understanding of their structure (as in: I'll copy not yet completed files, partial sets, etc.). - In order not to run out of space, I'll have to delete stale backups solely based on their file timestamps yet again, which might render backup sets unusable. What is the most elegant and cleanest way for to-be-backed-up hosts being backuped, via duplicity, automatically, while ensuring an attacker gaining full access to the to-be-backed-up hosts can't mess with already created backups? Thanks a lot!
Asked by daten (23 rep)
Oct 28, 2021, 08:32 PM