LowEndBox - Cheap VPS, Hosting and Dedicated Server Deals

Setting Up An Encrypted Volume on your Ubuntu VPS

lowendtutorial

Developers commonly use virtual private servers to build applications for their clients. Securing the data stored on your VPS can help protect against the accidental exposure of your data in case of a breach.

Linux distros such as Ubuntu can assist you in creating an encrypted volume on your VPS. Best of all, this can all be done from the command line interface (SSH).

How Encrypted Volumes Work

When you’re working with a low end box, creating an encrypted volume may prove to be a more versatile option than encrypting the entire disk.

Using an encrypted volume allows you to easily move your data across platforms, since an encrypted volume is essentially a large file that ends with the IMG file extension.

Before You Start

A few things should be noted before you begin creating encrypted volumes for your VPS. You should:

  • Always keep your encryption password in a safe place
  • Be aware that encryption could hurt system performance
  • Stop any services that may be using the data you want to encrypt
  • Always backup your data

Concerning the last bullet point, if the headers or meta-date of your encrypted files become corrupt, you risk losing the entire volume.

Installing DM-Crypt on Ubuntu

For the sake of this tutorial, we will assume that your VPS is Ubuntu based. To get started with encrypted volumes, we will use DM-Crypt. The directions may be slightly different for other flavors of Linux.

To install DM-Crypt using SSH, execute the following commands as Root:

> sudo apt-get update

> sudo apt-get install cryptsetup

Once this install is complete, you’re ready to begin creating encrypted volumes. The first step is to allocate space to the volume. Here’s an example:

> sudo fallocate -l 2GB /root/folder/volume1.img

Please note that this volume is not dynamic. It cannot be expanded. This command gives you an encrypted volume of 2GB.

Next, we’ll encrypt the allocated space. You’ll be required to create a password.

> sudo cryptsetup luksFormat /root/folder/volume1.img

Next, we must create a name for the encrypted volume. Let’s keep it simple and call it “volume1”

> sudo cryptsetup luksOpen /root/folder/volume1.img volume1

We’ve allocated the space, we’ve encrypted the space, we’ve created a label for the encrypted volume, now we must create a file system. It is best to use XFS. Do this by typing:

> sudo mkfs.xfs -m crc=1 /dev/mapper/volume1

Start Moving Data to the Encrypted Volume

You completed all of the prerequisites for creating the encrypted volume, now it’s time to start utilizing this secured space. Do this by executing these commands at the SSH prompt.

> sudo mkdir -p /root/folder/volume1

> sudo mount /dev/mapper/volume1 /root/folder/volume1

> sudo rsync -azv --progress /root/originating/datafolder/ /root/folder/volume1

Final Thoughts

Once you are done moving files the to the new encrypted volume, you can restart any services associated with the data that was being encrypted. You could easily move the hypothetical volume1.img file and remount it onto another VPS, should you need to transfer your data onto a production box.
*Special Note*

JoePie91, an astute member of Low End Talk, points out the following extra precaution/note:

“Securing the data stored on your VPS can help protect against the accidental exposure of your data in case of a breach.”

No, it probably won’t. There are precisely two cases in which this has any use *whatsoever*:

* The attacker is dumb and doesn’t know how to dump RAM.
* The server is turned off and *physically* stolen.

Disk encryption does absolutely nothing to protect you from any vaguely competent attacker while the system is running. 

Jon Biloh

10 Comments

  1. joepie91:

    As per usual, since it seems that every article on LEB nowadays is wrong somehow, a comment:

    “Securing the data stored on your VPS can help protect against the accidental exposure of your data in case of a breach.”

    No, it probably won’t. There are precisely two cases in which this has any use *whatsoever*:

    * The attacker is dumb and doesn’t know how to dump RAM.
    * The server is turned off and *physically* stolen.

    Disk encryption does absolutely nothing to protect you from any vaguely competent attacker while the system is running. That’s not what it’s for, and I consider it negligent that this article doesn’t bother to go into exactly what ‘protection’ this offers.

    October 16, 2016 @ 12:40 pm | Reply
    • foobar-333:

      Really, the primary reason why encrypting the “disk” of your VPS might be a good idea is to protect against accidental data leaks when the hosting company moves your data to a different (real) disk and doesn’t properly sanitize the disk the data was on before handing it to some third party (like, selling it on ebay).

      That’s also why you probably should encrypt all of it, the whole root file system, as there often are cryptographic keys and password and stuff on there that you wouldn’t want to get into the wrong hands.

      October 16, 2016 @ 2:48 pm | Reply
    • pepa:

      I agree, it’s good to clarify the limitations of the protection offered.

      I also agree with foobar-333’s use case.

      Another case where protection works is where this volume isn’t mounted. Even when an attacker accesses the live filesystem, the encrypted volume can’t be decrypted without the key.

      October 17, 2016 @ 4:39 am | Reply
      • Paul:

        Pepa, but then you as SysAdmin have to keep entering the password whenever you want to use the encrypted volume, or store the password on the server which defeats the security.

        October 17, 2016 @ 8:29 pm | Reply
        • In a live server, you would reboot your server once a month. The hacker would have to wait every once a month to monitor the paraphrase.

          April 7, 2020 @ 9:06 pm | Reply
    • Paul:

      It also protects you against a hosting company who are able to read your disk image whilst the server is active, or move your vm to new hardware and someone else inherits your disk blocks.
      Overall I agree, it doesn’t protect your server against an intruder whilst server is active and disk is mounted.

      October 17, 2016 @ 8:33 pm | Reply
      • joepie91:

        “It also protects you against a hosting company who are able to read your disk image whilst the server is active”

        No, it does not. The provider can simply extract the key from RAM and decrypt the volume. Disk encryption is only useful for *at-rest encryption* (and yes, reused HDDs are a potential case of that).

        October 19, 2016 @ 5:22 pm | Reply
        • Paul:

          I know.
          I specifically DID NOT suggest that the data is vulnerable if the hosting company can read the VM’s RAM, hence I only said disk.
          I guess I should have specific.

          October 19, 2016 @ 8:04 pm | Reply
  2. oLution:

    > It is best to use XFS.

    Please explain the reason

    October 18, 2016 @ 6:13 pm | Reply
  3. gc1:

    Are there likely to be any problems with this method if the VPS is an openVZ container? I.e. does dm-crypt or mounting of xfs or other file systems depend on any kernel modules or other features which an openVZ container might not have ?

    October 31, 2016 @ 10:32 am | Reply

Leave a Reply to Paul Cancel reply

Some notes on commenting on LowEndBox:

  • Do not use LowEndBox for support issues. Go to your hosting provider and issue a ticket there. Coming here saying "my VPS is down, what do I do?!" will only have your comments removed.
  • Akismet is used for spam detection. Some comments may be held temporarily for manual approval.
  • Use <pre>...</pre> to quote the output from your terminal/console, or consider using a pastebin service.

Your email address will not be published. Required fields are marked *