Whole-disk encryption on Ubuntu

I've had my wife's laptop running whole-disk encryption with TrueCrypt for a couple of years now, and I always wanted to get that level of security on my Ubuntu machine.  It really makes a lot of sense for the laptops to have as much privacy protection as possible, since we travel with them and therefore they are at higher risk of being stolen.  This week I finally got the opportunity to try it out.

The Plan

I knew I was going to take a performance hit, so I got myself an 8 gig SD card.  The root of my Ubuntu installation would go on it, with an unencrypted /boot partition on the hard drive as well as a 60 gig encrypted /home partition to store all of my files.  The home partition needs its own encryption key, so I decided on a key file that would be stored on the already encrypted root parition, allowing the OS to automatically unlock the home parition and mount it at boot time.

Installation

I downloaded the Ubuntu Alternate Install disk, since the standard install does not include the option to install logical volumes, which are necessary for thinks like encryption or software RAID.  The installation process was somewhat involved as you need to manually configure your partitions.  There's simply no way around it as your /boot directory needs to be unencrypted (this is because the software that performs on-the-fly encryption and decryption is a kernel module, and it can't be started if it is encrypted).  I tried to configure my /home partition on the 60 gig partition on the hard drive like I wanted, but I kept running into weird problems with the installer so I decided to take my chances installing /home on the SD card with everything else and seeing if I could set up /home on the 60 gig encrypted partition later.

So I ended up with /boot on an unencrypted partition on the hard drive, my swap space on an encrypted partition on the hard drive, and the root directory with everything else (/etc, /usr, /bin, /home, etc) on the encrypted partition on the SD card.

Configuration of the /home partition on the hard drive

Less than 8 gigs of space was just not going to cut it for my /home partition, so I was anxious to get the 60 gig encrypted parition configured.

After much Googling, I learned that encrypted volumes in Linux are configured on logical volumes.  This means creating a physical parition, configuring it as a physical volume, adding it to a volumne group, creating a logical volume inside the group, and finally installing a file system inside the logical volume, but fortunately a handy program called cryptsetup takes care of most of that for you.  Encrypted volumes use LUKS, the Linux Unified Key Setup along with dm-crypt.  One of the nice things about LUKS is that it contains 8 key "slots", meaning that you can have up to 8 passphrases or key files, any of which will unlock the volume.  This allows me to have a backup passphrase in case I need to reinstall the operating system or the key file goes corrupt.

So I formatted the 60 gig parition with ext4, and then I ran the following to initialize it as a physical volume for use as a logical volume, giving it the name pvHomeDir:

    $ sudo pvcreate /dev/sda7 pvHomeDir

Then I create a volume group called vgHomeDir and added that volume:

    $ sudo vgcreate vgHomeDir /dev/sda7

I then ran the following line to create an encrypted volume in that virtual group:

    $ sudo cryptsetup -y --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda7

It asked me for a passphrase, which I supplied.  When it was finished, I unlocked the new encrypted partition with:

    $ sudo cryptsetup luksOpen /dev/sda7 pvHomeDir

I then created a 60 gig logical volume called lvHomeDir in the encrypted parition with this:

    $ sudo lvcreate -n lvHomeDir -L 60G vgHomeDir

Then I installed an ext4 file system in the new logical volume (note the name and location of the volume; it is located in /dev/mapper and has the name of the volume group prepended with a dash to the name I gave it):

    $ sudo mkfs.ext4 /dev/mapper/vgHomeDir-lvHomeDir

OK, at this point the drive is all set up but it needs that key file so that I don't have to enter in two passphrases every time my computer boots.  I create a folder under /usr called keyfile, and copy a picture of myself and my daughter into it, and rename it "file".  To add the file as a key to the new partition I ran the following (I'm pretty sure this is the command but not 100%; I'm sorry if it is wrong and please post a comment if this line needs correcting):

    $ sudo cryptsetup luksAddKey --key-file=/usr/keyfile/file /dev/sda7

Almost done!  The partition just needs to be configured so that it will be used for my /home directory.  I edited 2 files:
    1. In /etc/crypttab I entered:
       
        pvHomeDir /dev/sda7 /usr/keyfile/file luks,retry=1,lvm=vgHomeDir

    2. In /etc/fstab I entered:
       
        /dev/mapper/vgHomeDir-lvHomeDir /home ext4 defaults 0 2

I created a directory called crypt in my home directory on the SD card and mounted the volume with the following command:

    $ sudo mount /dev/mapper/vgHomeDir-lvHomeDir /home/jizldrangs/crypt

I then restored my home directory to that folder, and when I rebooted, I had my old desktop background and all of my files! 

Drawbacks

    1.  I have noticed a performance hit when booting and every so often when browsing the web in Firefox
    2.  During the installation process, I chose the "random key" option for my swap space, so there is no way to do true hibernation, where the state of the machine in memory is saved to disk and restored later.  Suspend, which is where the computer turns off most components and uses minimal power, still works just fine.

SSH, the Secure Shizzle

SSH, the "secure shell" is the ultimate exception to the "security is inversely proportional to convenience" rule.  It is so easy to set up and once you have it running, secure authentication and communication are totally transparent.  It's almost irresponsible not to use it.

In its most basic form, SSH is a secure remote console program, a secure replacement for Telnet, however, it is very flexible and can handle such tasks as secure file copying between machines, proxying, and even tunneling.  Also, it's been around so long that it has become one of the de facto standards for secure authentication and communication on Linux.  Pretty much any network-enabled program worth its salt will feature support for it.

There are many fine tutorials on how to use SSH, my favorite is by the incomparable Chess Griffen on the Linux Reality podcast.  If you aren't already familiar with SSH, stop reading this post and listen to that episode of Linux Reality right away.  I'll wait.

As awesome as it is to be able to type "ssh myserver", enter the password, and start entering commands to be run on your server, there's a better way.  It's called SSH keys, and they will save you the trouble of typing in your password every time you want to connect to the server and they will give your server extra protection from being hacked.  It's easier and more secure, which almost never happens, so you know you have to do it.

Creating an SSH key

Simply hop into the command line and type "ssh-keygen".  It will ask you to give a filename and location for the new keys, and it will ask you to give it a passphrase.  When it is finished, go into your home directory's .ssh folder, and you will see two files: id_rsa and id_rsa.pub.  The id_rsa file is your private key; leave it where it is and don't let anyone have access to it.  Copy the id_rsa.pub file to your server.  On the server, go into your home directory's .ssh folder.  Create a file called authorized_keys if it doesn't already exist and copy the contents of your id_rsa.pub file into it (append the contents if the authorized_keys file already exists).  Now, go back to your client machine and SSH into your server.  It should let you in without asking for a password.

More SSH hardening measures

Let's face it, half the point of SSH is the security.  Setting up keys as I described will protect communications between your computers and ensure that you are actually contacting the server you think you are contacting with almost no effort on your part.  There are a few extra steps that should be taken to gain the highest level of security:

1. Disallow protocol 1: On the server, open /etc/ssh/sshd_config as root.  Find the line that says "Protocol 1,2".  Delete the 1 and the comma, so it only says "Protocol 2".  Don't close sshd_config yet...
2. Also in sshd_config, find the line that says "#PasswordAuthentication yes".  Remove the hash mark from the beginning of the line and change "yes" to "no".  Keep sshd_config open...
3. Find the line that says "Port 22" and change the 22 to another number between 1024 and 65535.  
4. Save that file and restart the ssh daemon (you can usually do this by running "sh /etc/init.d/sshd restart" as root)
5. On your client, open /etc/ssh/ssh_config as root
6. Find the line that says "Port 22" and change it to the same port number you set in step 3 above.
7. Find the line that says "Protocol 1,2" and change it to "Protocol 2", as you did on the server in step 1 above.
8. Find the line that says "Cipher aes128-cbc,3des-cbc,blowfish-cbc...".  Remove the hash mark at the beginning of the line if there is one, then remove all of the ciphers listed except aes256-cbc.  So that line should read, "Cipher aes256-cbc".
9. Save that file
10. Bookmark this blog post, because you will have to repeat steps 5-9 on all of your clients.

This may seem like a lot of work, but please keep in mind that SSH has been around for a very long time and there are a lot of automated ways to attack an SSH server that rely on the default settings, such as support for Protocol 1 and having the SSH daemon listen on port 22.  Changing these defaults takes only a few minutes but makes it exponentially harder for hackers to get in.  These steps are absolutely essential if you are considering exposing your SSH daemon to the public Internet.  

At this point, you are able communicate between machines with more ease and convenience than ever, and those communications are secured by military-grade authentication and encryption.  Security and convenience will never be this close, so take advantage!