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.
Related Posts:
- Have you ever visited the web’s busiest hosting forum? LowEndTalk awaits. - September 27, 2022
- Grab the deals first by subscribing to our new deal alerts - September 16, 2022
- LowEndBox is on Instagram and TikTok! - August 5, 2022
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.
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.
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.
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.
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.
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.
“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).
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.
> It is best to use XFS.
Please explain the reason
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 ?