In order to create a consistent set of practices (while keeping the convenience of cloud storage) for encrypting my data and passwords, I’ve decided to do the following:
- Primary (Sign,Certify) key and subkey #1 (Encrypt) was generated with 4096 RSA (
- A new subkey #2 is generated to provide (Sign) capability. For transferring
- and everyday carry, the subkeys can be deployed in a new machine, while the primary key will be kept encrypted in a separate location.
- This means that the subkeys have capability for signing and encrypting documents but can’t generate new subkeys or revoke them.
Symmetric encryption of backups
The generated backup keys
<key-fingerprint>.subkeys.asc are compressed into a
tar.gz and secured with:
tar -zcvf <key-fingerprint>.tar.gz \ <key-fingerprint>.full_backup.asc \ <key-fingerprint>.subkeys.asc gpg --symmetric <key-fingerprint>.tar.gz
This encrypted key can now stored in a secure location. Note that a different password can and should be used for the GPG key and the symmetric encryption.
To restore all the keys to a new machine use:
gpg --decrypt <key-fingerprint>.tar.gz.gpg | tar -zxv gpg --import <key-fingerprint>.[full_backup|subkeys].asc
Securing the main machine to use only subkeys
Once the primary key have been generated or imported, the only required steps to restrict the machine is as follows:
- Make a backup of
- Delete .gnupg
- Import the secret keys
- Edit the public key to maximum trust
Updating the keychain
We might want to update the keychain (i.e. adding new subkeys, a new mail/userid). To do so, import the primary key (
full_backup) into your machine, make the modifications and perform the full backup again.
Moving the password store
I’m currently using pass to manage my passwords. I set up a password store using
pass and my
<key-fingerprint> gpg key. All my passwords are saved there and I mirror it to a private git repository on github. Additionally, I’ve created a symbolic link of the password store to my Dropbox account.
Properly configuring firewalls is very important to avoid nasty attacks from malicious hackers. Using iptables, we can harden our server. Iptables are complicated to setup, but extremely powerful. We can also lock ourselves out of the server, so pay attention to what you are doing before changing anything. Note that the order in which we declare iptables matter. To avoid any surprises just follow the instructions in the order described by this document.
To get started, flush the existing iptables rules to start fresh:
sudo iptables -F
Block common attacks
Drop NULL packages (Used to find out weaknesess in the server), block the syn-flood attack (Where hackers try to open connections and do nothing, trying to starve your machine of resources). Finally we block XMAS packets (Also recon).
sudo iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP sudo iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP sudo iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
Ensure normal operations
Next, we need to make sure our machine can access connections on the localhost interface:
sudo iptables -A INPUT -i lo -j ACCEPT
Likewise, we need to allow outgoing connections stablished from this machine. Otherwise it will not be possible to run software updates.
sudo iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Open the ports for the services we need
Here they are some of the common services we want to allow. Select only those you are actually using.
sudo iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
Web server (HTTP/HTTPS)
sudo iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
Sending email (SMTP)
sudo iptables -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT sudo iptables -A INPUT -p tcp -m tcp --dport 465 -j ACCEPT
Read email (POP3)
sudo iptables -A INPUT -p tcp -m tcp --dport 110 -j ACCEPT sudo iptables -A INPUT -p tcp -m tcp --dport 995 -j ACCEPT
Read email (IMAP)
sudo iptables -A INPUT -p tcp -m tcp --dport 143 -j ACCEPT sudo iptables -A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
Block everything else
So far we have not blocked anything other than the common attacks. Here we explicitely block everything we have not included. This is a critical step, and you can get in trouble if the previous rules are not set properly.
sudo iptables -P OUTPUT ACCEPT sudo iptables -P INPUT DROP
If you get blocked, it’s not the end of the world. We might still be able to restart the server or access through the VPS console from the server provider, but in some cases it might be impossible. If all fails, make sure you can restore your backups for a fresh install.
Make the rules permanent.
The rules we have set up thus far are not permanent. To make this process painless, we can just install the
iptables-persistant package on Debian and it will handle the setup on restart.
sudo apt-get update sudo apt-get install iptables-persistant
Note that if you update the iptables, you need to save the configuration with the following command, otherwise
iptables-persistant will load the old ones instead.
sudo iptables-save > /etc/iptables/rules.v4