Data encryption on a virtual server

A little healthy paranoia hasn't hurt anyone yet. In addition to messengers with end-to-end encryption, file encryption on smartphones "out of the box" and mandatory use of SSL on websites, it will not be superfluous to protect data on virtual servers. Moreover, modern technologies have made it simple and accessible to any user. Large providers providing VPS hosting services offer to encrypt user data using standard operating system tools. For example, Microsoft, in its Azure cloud, uses BitLocker for servers on Windows , and DM-Crypt for virtual machines on Linux. ... These tools allow you to keep your data privacy even if an attacker gains access to the data center where the server is located or your local computer.



 You can trust your data to hosters providing VPS, you can not trust, but no one will forbid you to use the same methods with any VPS provider, configured yourself. In this article, I'll show you how to do it.

Encrypting data on Windows with BitLocker

The simplest, but most secure, encryption method for Windows is the built-in BitLocker service. Its setup is simple and quick, so the easiest way is to use the graphical interface. Let's analyze this process using the example of Windows Server 2016, located at the RuVDS provider. I will choose a server location in Moscow to reduce ping:





And for faster BitLocker, use the smallest SSD.





We will connect via standard RDP, which should be configured a little before use. To do this, click the "Show parameters" switch at the bottom of the window, check the "Clipboard" box in the "Local resources" tab, and select "Disks" in the dialog called by the "Details" button. 





This will allow you to copy files to your computer or paste them through the regular clipboard. RDP will honestly warn that: "This remote connection can be harmful ...", due to the sharing of local resources. Let's take note and connect to the server.



After login, we will see the usual desktop and administration panel. Let's connect the BitLocker service directly from it by selecting the "Add roles and features" option. On the first screen, check the "Skip ..." checkbox so as not to read the warning every time you change the configuration, then click "Next" and select "Role-based or feature-based installation", then select our local server and in the "Features" section, mark "BitLocker Drive Encryption". 





Confirm "Add Features", click "Next", check the option "Restart the destination server automatically if required" and click "Install".





After installing the service, the system will automatically reboot, and the next time you connect, a window will appear that the installation was successful.



Since we have a virtual server, it does not have a " Trusted Platform Module " crypto processor , which means we need to configure access policies so that BitLocker prompts for a password at system boot. If you do not do this, when you try to enable encryption, the system will display an error message:





We go to the search, insert the program name there: " gpedit.msc " and run it. We need to find the option along the following path: Local Computer Policy → Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives





It is necessary to activate the policy by selecting "Enabled", select the checkbox "Allow BitLocker without a compatible TPM (requires a password or a startup key on a USB flash drive)" in the options and click "OK". 



It remains to select the drives that you want to encrypt in Explorer. 





The setup wizard will analyze the system and ask you to continue ("Next"). In the next dialog box, he will warn that the drive will be used by BitLocker and will recommend that you first backup critical data. Good idea, but assuming you've already done that, click Next. The system will prepare the disk for encryption, but in the process, it will warn you that there is nowhere to move your Windows Recovery data and will offer to enable and configure this system after encryption. The installation is almost complete and the wizard will require you to reboot the system.





After the reboot, the service will be installed and the system will offer to encrypt the disk





On the next dialog box, the wizard will ask you to insert a USB flash drive or enter a password. Since our server is virtual, we choose the latter. In the next window, we come up with, enter and confirm the password, the system will swear, if it is too simple or short, you have to show your imagination. 



Next, we will be prompted to choose the way in which the access recovery key will be saved in case we forget the BitLocker password. 





We have nowhere to insert USB, you can select the local disk of your computer, access to which was opened in the RDP options. The file will be named something like this: "BitLocker Recovery Key BE32F397-9C84-4765-9840-50BF3893CAB6.TXT". And inside there will be a short instruction and a recovery key: 





Having saved the file, we proceed to the choice of the type of encryption. Since our local hard drive is protected, we select the first option: "New encryption mode". 



The next screen requires confirmation that we really want to encrypt the disk, click "Continue", we get a message that the process will start after reboot and a proposal to reboot the computer.



Everything - the system disk of our server is encrypted.



We try to connect to it and ... Nothing works!



Everything is logical. BitLocker will require you to enter a password at boot, and this happens even before the system is ready to work remotely. This cannot be done via RDP.



We go to the RuVDS page, which contains information about running servers, and we see an interesting picture:





In the screenshot from the virtual monitor, something very similar to the system prompt. Indeed, we will have to use the emergency mode access console in order to enter the password before booting the system:





We enter the password and see the continuation of the download. The emergency console can be closed and connected via RDP. By the way, we need such an operation every time the virtual server is restarted. Not very convenient, but that's the price of security.



Now, when we open the drive menu, we see new items in it: "Change BitLocker password" and "Manage BitLocker". Having opened the second item, we can see the status of the disk and its encryption management. Since I deliberately chose a small SSD for the demonstration, the encryption took less than five minutes. When it ended, the interface looked like this:





Bitlocker installation and disk encryption on the virtual server are now complete. Now, if someone gains physical access to your computer, he will not be able to connect to the server, even if he goes to the provider's website under your login. And if he comes to the data center and connects from the inside to your VPS, he will still not be able to receive the data - it will be encrypted.



The main thing is not to keep in sight the file containing the key to restore access!



By the way, how do you use this key if you forgot your BitLocker password? It's very simple, you need to reboot the server and go to the emergency console, but now choose not to log in, but restore. Press ESC and get an invitation to enter the key. One subtlety, you only need to enter numbers, and minus separators will be inserted automatically. If you enter incorrectly, you will receive an error message and a request to enter the key again. If it is entered correctly, the system will continue to boot. 



Configuring BitLocker on a Remote Server - Completed.

Encrypting data on Linux with dm-crypt

There are many different partition encryption solutions for Linux, we will use dm-crypt , a simple and reliable system that Microsoft uses in its Azure cloud. 



dm-crypt - a standard disk encryption system based on Linux kernel, based on: d evice m apper , the subsystem creates and provides transparency to work with virtual devices; and crypt o API- an encryption subsystem that is used for VPN over IPsec and a number of other functions. Dm-crypt has two ways of working with a crypto container, plain - in which the data does not contain a visible format and looks like a random set of bytes, and LUKS - which provides more options, for example, automatic detection of crypto containers by the system, but the file will contain metadata which can determine the very fact of encryption. We will use the second method, via the LUKS protocol .



The server is selected in the same way as in the first section, except for the operating system. Let's skip the steps for presetting, they can be found in the RuVDS manualand move on to installing the encryption system. Let's update the package list and install cryptsetup - the dm-crypt command line interface (for simplicity, all commands will be entered as root):

apt update
apt install cryptsetup 

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

To store encrypted data, you must first create a special file, which will then act as a device. It must be inseparable, and for this there are several ways, with varying degrees of security.



One of them is with the fallocate command.



Create a 512MB file named test-crypt in the root user's home directory:

fallocate -l 512M /root/test-crypt

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

This is the easiest and fastest method, but the least secure, because the command simply allocates disk space without overwriting the data that was contained there.



It is safer to create a file using the dd (dataset definition) utility, it allows you not only to create a file, but also write information into it that will overwrite the previous content from the selected area. For example zeros from / dev / zero virtual device:

dd if=/dev/zero of=/root/test-crypt bs=1M count=512

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

The most paranoid way is to populate the file from / dev / urandom. But it is also the slowest:

dd if=/dev/urandom of=/root/test-crypt bs=1M count=512

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

After creating the file, you need to convert it to a LUKS section:

cryptsetup -y luksFormat /root/test-crypt

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Answer YES



the program prompt and then set a password. Unlike BitLocker, there will be no recovery methods, private keys and other conveniences here; if you forget your password, your data will be irretrievably lost! Approach this issue very responsibly. Therefore, be sure to use the option -y



that asks for password confirmation. 



Let's check what we got using the utility file



:

file /root/test-crypt

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

The output should show something like:

test-crypt:  LUKS encrypted file, ver 2 [, , sha256] UUID: 820a6557-ee7b-4f67-9f53-eb11586cc5dc

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

This means that the crypto container is created and ready to use, it remains to deploy it to the crypt-volume device: 

cryptsetup luksOpen /root/test-crypt crypt-volume

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Create a filesystem there:

mkfs.ext4 -j /dev/mapper/crypt-volume

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

And select the mount point: 

mkdir /mnt/crypt-files

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

The encrypted device is ready to use, all that remains is to mount it and use it as a regular disk, all encryption and decryption operations take place "on the fly", transparent to the user and the system.

mount /dev/mapper/crypt-volume /mnt/crypt-files

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Let's check our device. Let's copy some data into it, for example, the contents of the / etc / ssh directory and see what the dh utility says

cp -r /etc/ssh/ /mnt/crypt-files/ 
df -h

Filesystem           Size  Used Avail Use% Mounted on
udev                 928M     0  928M   0% /dev
tmpfs                191M  648K  191M   1% /run
/dev/sda1             20G  2.7G   16G  15% /
tmpfs                955M     0  955M   0% /dev/shm
tmpfs                5.0M     0  5.0M   0% /run/lock
tmpfs                955M     0  955M   0% /sys/fs/cgroup
tmpfs                191M     0  191M   0% /run/user/1000
/dev/mapper/crypt-volume  465M  1.3M  429M   2% /mnt/crypt-files

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

As we can see, the device is mounted, has the volume determined by us and is filled by about 1% with files from the ssh directory.



In order to finish working with the crypto container, you need to unmount it and then disable it:

cd /
umount /mnt/crypt-files
cryptsetup luksClose crypt-volume

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

The work with the device is finished and we have the most ordinary file, encrypted with our password, data that is inaccessible to an outsider, even if he gets physical access to the server. 



To use the crypto container again, you will need to initialize and mount it again:

cryptsetup luksOpen /root/test-crypt crypt-volume
mount /dev/mapper/crypt-volume /mnt/crypt-files

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

This completes the review of data encryption systems that can be used on virtual servers.



Good connection everyone!