Hacker News new | past | comments | ask | show | jobs | submit login

I use duplicity + rsync.net and have wondered about this attack vector. My solution (which admittedly only protects against remote backups being deleted by an attacker, not read) is:

1. Use sub accounts on rsync.net so backups from different parts of the system are isolated from each other.

2. Use a different GPG keypair and passphrase for each host being backed up.

3. Have an isolated machine out on the internet somewhere (that, importantly, isn't referenced by anything in the main system including documentation / internal wikis i.e. so the attackers don't know it exists) that does a daily copy of the latest and previous full backup plus any current incrementals directly from rsync.net's storage. This way I'm still covered (and can restore relatively quickly) if an attacker gets in to the system and deletes the rsync.net hosted backups for lulz.

If you're truly paranoid or need to protect backups going back over months you could also introduce a final routine that duplicates the data from the ghost machine to Amazon glacier (and then optionally pay for an HDD to be shipped periodically to your offices).




Your rsync.net account has ZFS snapshots enabled - at the very least, the smallest default is 7 daily snapshots.

The ZFS snapshots are immutable. Completely. Even root can't write or delete in a snapshot. The snapshot has to be deliberately destroyed with ZFS commands run by root - which of course, the attacker would not have access to.

Also, thanks for your business :)


Ha! Well that simplifies things for me :) Honestly, your service is so solid I can't remember the last time I actually logged in to check something. It really is backup as a utility (you should consider re-branding as "BaaU" lol)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: