Secure Offsite Backups
From CoCCA Registry Services (NZ) Limited
Encrypt Backup Files
Protect your Backup files using GPG encryption to protect your sensitive data like users info, to do that you can follow the following steps:
1- Create your keys (private and public Keys):
# gpg --gen-key Notice: If you will use an already exists keys, you can import those keys via the following commands: # gpg --import backup_publicgpg.key # gpg --allow-secret-key-import --import priv.key But when you use the script at step 3 you will always get message like this: "It is NOT certain that the key belongs to the person named in the user ID" and then need to enter yes every time you try to encrypt the backup file. The solution is to trust the imported key so you can use the gpg --yes command with file encryption. to trust the imported key just do the following: # gpg --edit-key 'Keys_Tag_or_ID' gpg (GnuPG) 1.4.11; Copyright (C) 2010 Free Software Foundation, Inc.This is free software: you are free to change and redistribute it. [Here you will See your keys Details] gpg> Then you need to enter the following command in gpg prompt: gpg> trust Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y gpg> quit
Exiting the gpg program, and Continue the reset steps.
2- use the created keys as a defualt recepint via edit the gpg.conf file.
# vi /root/.gnupg/gpg.conf uncomment the following lines in gpg.conf file: # default-key Key ID # default-recipient Key ID
3- apply our small script to decrypt all Backup files.
#!/bin/bash
ls -l /YOUR/BACKUP/DIRECTORY/ > backups_list.txt
while IFS= read -r line || -n "$line" ; do
file2encrypt="$(echo $line |awk '{print $9}')"
field1="$(echo "$file2encrypt" | awk -F- '{print $1}')"
if [ "$field1" == "backup" ]
then
check_encrypted="encrypted-$file2encrypt.ryde"
echo "$check_encrypted"
if [ -f "/YOUR/BACKUP/DIRECTORY/$check_encrypted" ]
then
echo "Already Encrypted Same File Name"
else
echo "Now Begin Encrypt File :$file2encrypt"
gpg --yes --recipient "backup keys" --encrypt --armor --output "/YOUR/BACKUP/DIRECTORY/encrypted-$file2encrypt.ryde" "/YOUR/BACKUP/DIRECTORY/$file2encrypt"
echo encryption_DONE
fi
fi
done < backups_list.txt
4- Copy the backup Offsite to Secure Backup server using next section "Secure offsite backup".
5- try to decrypt the encrypted backups to ensure every thing work well:
for example as our secript one of the out put files: encrypted-backup-2016-04-24-16-00-03.bak.zip.ryde then rune the following command: # gpg --output backup-2016-05-05-00-12-14.bak.zip --decrypt encrypted-backup-2016-05-05-00-12-14.bak.zip.ryde then try to unzip the uncrypted file to ensure your Data is OK: # /opt/cocca-8/java/bin/jar -xf backup-2016-05-05-00-12-14.bak.zip after you excute this command ypu should get this file: backup.sql then you can import it to be sure evry thing is OK.
Secure offsite backup
The main important task in Registry system is to take the backups of your SRS database periodically using secure way. There are alot of backups technology we can use it to take our back and safe it offsite, like streaming replication, static backup, Barman, ... . But the more important is to keep your production server and backup servers secure, by avoid any of the following cases:
- if The production server compromised the backups in backup server shouldn't affect. - if the backup server compromised should not affect the database in production server.
Most of backup technology uses the automated backups using autologin server keys without password, this can affect in servers security if the attacker hacked the Backup server then can search about the backup script to find the way to login to the production servers and vice versa.
setup secure automated backup
There are alot of articles in the internet to secure you backups by use chrooted enviroment and restrict the backup server to access your production server and use only the required backup command. we will use the simple way by using the rsync command over ssh using keys and restrict the access for specific user and from specific IP. the configuration is very simple: first if we have two servers: - production server which has the SRS database: production.nic.ccTLD , then we can create a backup user into this server : backup@production.nic.ccTLD.
then we can configure the SRS software to save the SRS database backup files in backup user home directory : /home/backup.
- Backup server is offsite or inside backup sever backup.nic.ccTLD, which can get (may production can deposits) backup files. The recommnded backup direction is the backup servers get the backups from the production server, this mean the backup server will try to use rsync over ssh to production server: - Create the required keys for the backup server user wich will try to ssh the production server, login to backup server using root (or any user will excute the backup cron) then will excute:
# ssh-keygen
then it will ask you for directory to save the generated keys (by default it is the home directory), and the passphrase for this keys and we need
to leave it empty.
- Now you can look at the home directory for this user we will find the .ssh folder generated and contain the private and public keys:
$ ls ~/.ssh
id_rsa id_rsa.pub
- Copy the generated public key in backup server and add it to /home/backup/.ssh/authorized_keys in the production server.
if the directory .ssh does not exsist just create it and give it permissions 700 and the owner should be backup user, then create the file authorized_keys and give it permissions 600 and the owner should be backup user. The file authorized_keys in production server for the backup user should be similer to this line: command="/usr/bin/rsync --server --sender -vlogDtpre.is . /home/backup/backup*",from="backup.nic.ccTLD",no-pty,no-agent-forwarding,no-port-forwarding, no-X11-forwarding ssh-rsa AAAA_YOUR_Backup_SERVER_GENERATED_public_KEY== root@backup.nic.ccTLD
- after adding this line to file authorized_keys in production server you can now return to backup server and try to backup the files, you will notice
when you run the rsync command in backup server you will not use any source path and if you used the production server will ignore it and use one in authorized_keys file : "/usr/bin/rsync --server --sender -vlogDtpre.is . /home/backup/backup* "
- Test The backup using new configuration, in backup server run this command:
$ rsync -av backup@production.nic.ccTLD:/ /backu/path/at backup server/ you can see we donot specify any source path only just the destination backup server. then you can add this command to cronjob.
