Recently I decided to start using Amazon AWS as my backup storage but my paranoid soul wasn’t satisfied until I figured it out how to secure my private data. It’s not that I don’t trust Amazon but a lot of bad things could happen if I decided that I just copy my data to a remote server on Amazon:
- Amazon staff would have access to my data.
- A breach in Amazon’s systems would expose my data.
- A breach in my remote server OS would expose my data.
One of the solutions which I considered was to encrypt my local file-system with eCryptfs but it has some issues with relatively long file names.
Finally I came out with the following working backup solution which I currently use to backup both my Windows and Linux partitions. I share the Windows root directory with the VirtualBox Linux machine and run the backup scripts from there. Here is a short explanation of the properties and features of the backup setup:
- Locally encrypted — all files which I store on the iSCSI volume are encrypted on my personal desktop, before being sent to the remote server. This ensures that the files cannot be read by anyone else.
- Secure — besides the local volume encryption, the whole communication is done over an SSH tunnel which secures the Internet point-to-point client-to-server communication.
- Remote — having a remote backup ensures that even if someone breached in my house and steals my laptop and my offline backup, I can still recover my data from the remote server. Furthermore, it is more convenient to frequently backup on a remote machine, because we have Internet access everywhere now. Note that remote backups are not a substitution for offline backups.
- Over Internet — very convenient. Of course, this backup scheme can be used in any TCP/IP network — private LAN, WAN, VPN networks, etc.
The following two articles provide detailed instructions on how to setup the backup solution:
- Secure iSCSI setup via an SSH tunnel on Linux
- Locally encrypt an iSCSI volume with TrueCrypt on Linux
Daily usage example
Here are the commands which I execute, in order to make a backup of my laptop. Those can be further scripted and automated if a daily or more frequent backup is required:
IP=23.21.98.10 # the public DNS IP address of the EC2 instance / server ## Execute the following, in order to mount the remote encrypted iSCSI volume: sudo -E \ ssh -F /dev/null \ -o PermitLocalCommand=yes \ -o LocalCommand="ifconfig tun0 172.18.0.2 pointopoint 172.18.0.1 netmask 255.255.255.0" \ -o ServerAliveInterval=60 \ -w 0:0 root@"$IP" \ 'sudo ifconfig tun0 172.18.0.1 pointopoint 172.18.0.2 netmask 255.255.255.0; hostname; echo tun0 ready' sudo iscsiadm -m node --targetname "iqn.2012-03.net.famzah:storage.backup" --portal "172.18.0.1:3260" --login sudo truecrypt --filesystem=none -k "" --protect-hidden=no /dev/sdb sudo mount /dev/mapper/truecrypt1 /mnt ## You can now work on /mnt -- make a backup, copy files, etc. ls -la /mnt ## Execute the following, in order to unmount the encrypted iSCSI volume: sync sudo umount /mnt sudo truecrypt -d /dev/sdb sudo iscsiadm -m node --targetname "iqn.2012-03.net.famzah:storage.backup" --portal "172.18.0.1:3260" --logout # stop the SSH tunnel
Disaster recovery plan
Any backup is useless if you cannot restore your data. If your main computer is totally out, you would need the following, in order to access your backed up data:
- The Amazon AWS login credentials to start the EC2 backup instance.
- The root password for the EC2 backup instance, so that you can log in there and then access your backup data by mounting the encrypted iSCSI volume locally on the remote server.
In order to be able to log in to the remote server via SSH, you need to set up the following:
vi /etc/ssh/sshd_config # PasswordAuthentication yes /etc/init.d/ssh restart passwd root # set a very long password which you CAN remember
Make sure that you test if you can log in using an SSH client which does not have your SSH key and thus requires you to enter the root password manually.
I do not consider password authentication for the root account to be a security threat here. The backup server is online only during the time a backup is being made, after which I shut it down in order to save money from Amazon AWS. Furthermore, the backup has a new IP address on each new EC2 machine start, so an attacker cannot continue a brute-force attack easily, even if they started it.
/contrib/famzah 