Security

GPG

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 (<key-fingerprint>).
• 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>.full_backup.asc and <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 .gnupg
• 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.

Firewall/iptables

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.

SSH access

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