Bits of Freedom
Bits of Freedom

Tinkerer and thinker on everything free and open. Exploring possibilities and engaging with new opportunities to instigate change.

Jonas Öberg
Author

Jonas is a dad, husband, tinkerer, thinker and traveler. He's passionate about the future and bringing people together, from all fields of free and open.

Share


My Newsletters


If you're interested in what Commons Machinery, Elog.io, or myself are up to, I'd love for you to be part of my notification lists. It's pretty low volume, a few messages per month, depending on which notifications you sign up for. Thanks for taking an interest!

Read more & subscribe
Bits of Freedom

Configuring backups at FSFE

Jonas ÖbergJonas Öberg

During the past month, I've been testing a new backup strategy and system for the FSFE which is built around Duplicity and a remote storage accessible via SSH. While we've gone through some of the attack vectors to see if this makes sense, I would appreciate more eyes on it. Our previous backup system was significantly simpler in a way, consisting of a simple computer with massive amounts of disk, talking directly via ssh to the client machines and running rsnapshot.

The reason we at all set out to configure a new backup system is that our previous one would not be available for much longer, and given our need to store terabytes of backup data, we could not actually (for a reasonable cost) add the needed backup space to one of our current hosts. So instead I decided to investigate the option of separating the storage from the backup controller, with the idea that if the storage is encrypted, we would be more flexible in where and how it is stored, as access would not (only) depend on physical security.

There are three agents of this new system:

  1. Our backup server (BACKUP)
  2. Our client machine which is supposed to be backed up (CLIENT)
  3. A remote storage accessible via SSH and having ~10TB storage (REMOTE)

The flow of our system at the moment is basically as follows:

  1. BACKUP controls and initiates the backups by pulling data from CLIENT,
  2. CLIENT allow BACKUP access to its file system in read-only mode via sshf (this access is enforced by an ssh key specifically starting command="/usr/lib/openssh/sftp-server -R"),
  3. BACKUP runs duplicity and encrypts backups with a specific (non published) GnuPG key where the secret key passphrase is not stored on BACKUP itself but only kept by out system administrators,
  4. Duplicity on BACKUP sends the backup archives to REMOTE

Attack vectors

Here are the attack vectors I've currently considered in this:

Of course, there are issues with this. Given the controlling function of BACKUP, an attacker could for instance try to sneak under the radar and replace or destroy files in transit between BACKUP and REMOTE, ultimately rendering our backup archives invalid. If BACKUP is compromised, even with just read-only permission, it may be possible to read enough data from our servers to find authentication keys or similar which provides a way to escalate the permissions.

Those drawbacks are likely to be the same regardless of what strategy we employ though. One way around them would be that the client machine encrypts data before sending it to the backup server, but this places a stronger emphasis on having local software installed on the client machine, which we try to avoid in favor of a simple ssh connection.

Jonas Öberg
Author

Jonas Öberg

Jonas is a dad, husband, tinkerer, thinker and traveler. He's passionate about the future and bringing people together, from all fields of free and open.