1. On the machine being backed up:
    Create limited privilege account on a production Linux VM with content to backup.
    • Account would have access to a single direct [e.g. /home/backup] and allow ssh via keys only.
    • Account would be chrooted to the /home/backup directory.
    • Account would be restricted shell [ rssh ]
    • Account would be restricted via AllowUsers backup@[backup vm ip address]
  2. On the machine being backed up
    As root generate the backups, place them where the limited privilege account can access them, and chown them to the limited privilege account.
    • Root account would have access to an encryption password/key. Copies of this key would exist on the developer/sysadmin machines and/or usb key drives. Assumption is a compromised sysadmin/dev machine = screwed. They'd be able to keylog the entry of the key passphrases and obtain copies of the keys.
    • Root account generates the backup -> compresses backup -> encrypts backup -> moves backup to /home/backup/current.tar.bz2 -> chown backup:backup
  3. On the machine collecting the backups
    Have SSH keys for the backup account on all production machines, and just copy /home/backup/current.zip from the source machine to the local machine.
    • Does not have encryption/decryption information.
    • Backup VM access is limited to sysadmin/dev ssh keys on their machines.

The information to be backed up isn't unusually sensitive [public/private conversations, account passwords to the services being backed up, etc.]. It is not anything like credit cards, health info, etc.

I'm confident the rest of the backup process [restoration, frequency of backups, etc.] functions to my satisfaction.

  • 2
    Ignore your backup procedure, it only matters in that it permits you to restore. What is your restore procedure? Have you tested that? Does it work? Are you saving your data long enough? Your backup needs to be tailored to the needs of the business. – Zoredache Mar 3 '14 at 17:35
  • @Zoredache I'm confident with the core of the backup/restore process - I've used it successfully before. I'm mainly concerned with security (being sure an attacker can't take over the production machines if they gain access to the backup server, and that an attacker can't vandalize the backups with control of the production machine. – ReadWriteCode Mar 3 '14 at 17:42

You should use public key encryption in this scenario, when your offsite backups are stored by a third party.

This way, the machine being backed up has only its own public key, and therefore can only create backups. You store the private key offline, and use it only for restores.

Backup solutions such as Bareos already support public-key encryption, or you could fairly easily integrate it into your existing setup with GPG.

  • That is a good point if only for completeness. I always overlook something. :) I am going to wait to see what other responses I get before an accepting an answer since I probably made at least two mistakes. ;) – ReadWriteCode Mar 3 '14 at 18:19
  • @ReadWriteCode I would suggest using Bacula or BaReOS over your current system if only because the backup/restore process is a bit more tried and tested (and doesn't require SSH access). In practical matters your security plan above is pretty solid: the attack surface / potential for compromise isn't substantially different between that and dedicated backup software. The other benefits of dedicated backup software (like more granular restores) might tip the scales though. – voretaq7 Mar 10 '14 at 21:23

Your setup seems pretty solid - though I'm really a huge proponent of backup software for doing backups.

I'll offer you the following outline based on Bacula (and/or BaReOS):

  1. On the machines being backed up
    Install the Bacula agent, and configure a machine-specific encryption certificate.
    (The decryption key need not be stored on these machines as it's only needed for restores.)
    Your backups will be initiated the same way as any "normal" Bacula backup, and will be encrypted using the specified certificate.

  2. On the Bacula Director (The machine requesting the backups)
    Configure your backup schedule as appropriate for your organization (Full & Incrementals).

  3. On the Bacula Storage Server (The machine the backups are written to)
    You don't have to do anything special, but it's generally good practice to either have the Storage server be off-site, or to sync the backups off-site using rsync or equivalent.

This is effectively equivalent to your outline above, only not requiring SSH access & cron jobs. In addition, you gain a few other benefits:

  • It's difficult for an attacker to vandalize the backups.
    Access to one of the machines being backed up doesn't allow you to delete/overwrite backups - that's all controlled by the Director.

  • It's difficult for an attacker to vandalize the machines being backed up.
    With the decryption keys stored offline an attacker can't restore data to the machines being backed up (the backup won't decrypt), so even if they have access to the Director they can't command a restore.

  • Your backups are pretty secure.
    Since they're encrypted prior to leaving the source machine (and only decrypted on the target machine during restore) someone grabbing a copy of your backups is getting unusable (encrypted) data. This is more of a concern if your data is sensitive, but it also means your backup can't be tampered with (and thus can't be used to restore corrupt/malicious data to your servers if someone gets access to the storage server).

  • You're using "real backup software"
    This is useful when you need to "restore that document I was working on on Thursday" - you can get that one file back without having to extract (or copy around) a whole archive.

The downside? The backup agent needs to run as root (or at least as a user who can read all the data you want to back up). The agents are pretty secure, but there's always a chance that an undiscovered flaw exists that could present a possible attack avenue.
Keep on top of your patches and you should be fine though.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.