kdpv - Reuters
If you rented a server, then you do not have full control over it. This means that specially trained people can come to the hoster at any time and ask for any of your data. And the hoster will give them back if the requirement is executed according to the law.
You really don't want your web server logs or user data to get to someone else. It is impossible to build a perfect defense. Protecting yourself from a host that owns a hypervisor and provides you with a virtual machine is next to impossible. But perhaps it will be possible to reduce the risks a little. Encryption of rented cars is not as useless as it seems at first glance. At the same time, let's look at the threats of extracting data from physical servers.
Threat Model
As a rule, the hoster will try to protect the interests of the client as much as possible to the extent possible by law. If only access logs were requested in a letter from the authorities, the hoster will not give dumps of all your virtual machines with databases. Shouldn't, at least. If they ask for all the data in full, then the hoster will copy the virtual disks with all the files and you will not know about it.
Regardless of the scenario, your main task is to make the attack too difficult and expensive. There are usually three main threat options.
Official
Most often, a paper letter is sent to the official office of the hoster demanding to provide the necessary data in accordance with the relevant resolution. If everything is done correctly, the hoster provides the necessary access logs and other data to the authorities. Usually they just ask to send the necessary data.
Occasionally, if it is very necessary, representatives of law enforcement agencies come to the data center in person. For example, when you have your own dedicated server and data from there can only be taken physically.
In all countries, gaining access to private property, conducting searches and other activities requires evidence that the data may contain important information for the investigation of a crime. In addition, a search warrant issued in accordance with all regulations is required. There may be nuances associated with the peculiarities of local legislation. The main thing to understand is that in the case of the correct official path, representatives of the data center will not let anyone go further than the checkpoint.
Moreover, in most countries it is impossible to simply take and pull out working equipment. For example, in Russia, until the end of 2018, according to Article 183 of the Code of Criminal Procedure of the Russian Federation, part 3.1, it was guaranteed that during the seizure, the seizure of electronic media is carried out with the participation of a specialist. At the request of the legal owner of the seized electronic media or the owner of the information contained on them, the specialist participating in the seizure, in the presence of witnesses, copies information from the seized electronic media to other electronic media.
Then, unfortunately, this paragraph was removed from the article.
Secret and unofficial
This is already the territory of activity of specially trained comrades from the NSA, FBI, MI5 and other three-letter organizations. Most often, the legislation of countries provides for extremely broad powers for such structures. Moreover, there is almost always a legal ban on any direct and indirect disclosure of the very fact of cooperation with such law enforcement agencies. Russia has similar .
In the event of such a threat to your data, they will almost certainly be pulled out. At the same time, in addition to simple withdrawal, the entire unofficial arsenal of backdoors, zero-day vulnerabilities, extracting data from the RAM of your virtual machine, and other pleasures can be used. At the same time, the hoster will be obliged to help the specialists of law enforcement agencies as much as possible.
Unscrupulous employee
Not all people are equally good. Some of the data center administrators may decide to earn extra money and sell your data. Further development of events depends on its powers and accesses. The most frustrating thing is that an administrator with access to the virtualization console has full control over your machines. You can always take a snapshot along with all the contents of the RAM and then slowly study it.
VDS
So you have a virtual machine that the host gave you. How can you organize encryption to protect yourself? In fact, almost nothing. Moreover, even someone else's dedicated server may end up as a virtual machine into which the necessary devices are thrown.
If the task of the remote system is not just to store data, but to perform some calculations, then the only option for working with an untrusted machine is to implement . In this case, the system will carry out calculations without the ability to understand what exactly it is doing. Unfortunately, the overhead costs for implementing such encryption are so high that their practical application is currently limited to very narrow tasks.
Plus, at the moment when the virtual machine is running and performing some actions, all encrypted volumes are in an accessible state, otherwise the OS simply will not be able to work with them. This means that having access to the virtualization console, you can always take a snapshot of a running machine and extract all keys from RAM.
Many vendors have attempted to organize hardware-based RAM encryption so that even the hoster does not have access to this data. For example, the Intel Software Guard Extensions technology, which organizes areas in the virtual address space that are protected from reading and writing from outside this area by other processes, including the operating system kernel. Unfortunately, you will not be able to fully trust these technologies, as you will be limited to your virtual machine. In addition, there are already ready-made examples to this technology. And yet, encrypting virtual machines is not as pointless as it might seem.
Encrypting data on VDS
Iβll make a reservation right away that everything that we do below does not amount to full-fledged protection. The hypervisor will allow you to make the necessary copies without stopping the service and without you noticing.
- If, upon request, the hoster transfers a βcoldβ image of your virtual machine, then you are relatively safe. This is the most common scenario.
- If the hoster gives a full snapshot of a running machine, then everything is pretty bad. All data will be mounted in the system in clear text. In addition, it will be possible to rummage through RAM in search of private keys and similar data.
By default, if you deployed an OS from a vanilla image, the hoster does not have root access. You can always mount the media with the rescue image and change the root password by chrooting into the virtual machine environment. But this will require a reboot, which will be noticed. Plus, all mounted encrypted partitions will be closed.
However, if the deployment of a virtual machine does not come from a vanilla image, but from a pre-prepared one, then the hoster can often add a privileged account to assist in an emergency at the client. For example, to change a forgotten root password.
Even in the case of a full snapshot, not everything is so sad. An attacker will not receive encrypted files if you have mounted them from a remote file system on another machine. Yes, in theory, you can open the RAM dump and extract the encryption keys from there. But in practice, this is not very trivial and it is very unlikely that the process will go beyond a simple file transfer.
We order a car
For our test purposes, we take a simple machine in . We don't need a lot of resources, so let's take the option of paying for the actually spent megahertz and traffic. Just enough to play.
The classic dm-crypt of the entire partition did not take off. By default, the disk is given in one piece, with root for the entire partition. Shrinking an ext4 partition on a mounted root is practically a guaranteed brick instead of a file system. I tried) Tambourine did not help.
Create a crypto container
Therefore, we will not encrypt the entire partition, but use file cryptocontainers, namely the audited and reliable VeraCrypt. For our purposes this is sufficient. First, we pull out and install the package with the CLI version from the official site. You can check the signature at the same time.
wget https://launchpad.net/veracrypt/trunk/1.24-update4/+download/veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb
dpkg -i veracrypt-console-1.24-Update4-Ubuntu-18.04-amd64.deb
Now we will create the container itself somewhere in our home so we can mount it manually on reboot. Set the container size, password, and encryption algorithms interactively. You can choose the patriotic Grasshopper cipher and the Stribog hash function.
veracrypt -t -c ~/my_super_secretNow let's install nginx, mount the container and fill it with secret information.
mkdir /var/www/html/images
veracrypt ~/my_super_secret /var/www/html/images/
wget https://upload.wikimedia.org/wikipedia/ru/2/24/Lenna.pngLet's fix /var/www/html/index.nginx-debian.html a little to get the right page and you can check it.
Connecting and checking
The container is mounted, the data is available and given.
And here is the machine after a reboot. The data is securely stored in ~/my_super_secret.
If you really need and want hardcore, then you can encrypt the entire OS so that when you reboot it requires connecting via ssh and entering a password. This will also suffice in a simple cold data retrieval scenario. Here and remote disk encryption. Although in the case of VDS it is complicated and redundant.
bare metal
It is not so easy to put your own server in the data center. Someone else's dedicated may turn out to be a virtual machine where all devices are thrown. But something interesting in terms of protection begins when you have the opportunity to place your trusted physical server in the data center. Here you can already use traditional dm-crypt, VeraCrypt or any other encryption of your choice to its full potential.
It must be understood that when implementing total encryption, the server will not be able to rise on its own after a reboot. You will need to raise the connection to the local IP-KVM, IPMI or other similar interface. Then we manually enter the master key. The scheme looks so-so in terms of continuity and fault tolerance, but there are no special alternatives if the data is so valuable.
NCipher nShield F3 Hardware Security Module
A softer option assumes that the data is encrypted, and the key is located directly on the server itself in a special HSM (Hardware Security Module). As a rule, these are very functional devices that not only provide hardware cryptography, but also have mechanisms for detecting physical hacking attempts. If someone starts picking your server with a grinder, then the HSM with an independent power supply will reset the keys that it stores in its memory. The attacker will get the encrypted stuffing. In this case, the reboot may occur automatically.
Removing the keys is a much faster and more humane option than activating a thermite or an electromagnetic spark gap. For such devices, neighbors in the rack in the data center will beat you for a very long time. Moreover, when using encryption on the media themselves, you practically do not experience any overhead. All this happens transparently to the OS. True, in this case, one must trust the conditional Samsung and hope that there is an honest AES256, and not a banal XOR.
At the same time, one should not forget that all extra ports must be physically disabled or stupidly filled with compound. Otherwise, you give the attackers an opportunity to . If you have a PCI Express or Thunderbolt sticking out, including USB with its support, you are vulnerable. An attacker will be able to carry out an attack through these ports and gain direct access to the memory with keys.
In a very sophisticated version, the attacker will be able to carry out a cold boot attack. At the same time, it simply pours a good portion of liquid nitrogen into your server, roughly removes the frozen memory sticks and dumps them with all the keys. Often, an ordinary cooling spray and temperatures in the region of -50 degrees are enough to carry out an attack. There is also a more accurate option. If you have not disabled loading from external devices, then the attacker's algorithm will be even simpler:
- Freeze memory sticks without opening the case
- Connect your bootable flash drive
- With special utilities, remove data from RAM that survived the reboot due to freezing.
Divide and Conquer
Ok, we only have virtual machines, but I want to somehow reduce the risks of data leakage.
You can, in principle, try to revise the architecture and separate data storage and processing across different jurisdictions. For example, the frontend with encryption keys is from a hoster in the Czech Republic, and the backend with encrypted data is somewhere in Russia. In the case of a standard seizure attempt, it is extremely unlikely that law enforcement agencies will be able to carry out this simultaneously in different jurisdictions. Plus, this partially insures us against the scenario of taking a snapshot.
Well, or you can consider a completely clean option - End-to-End encryption. Of course, this goes beyond the scope of the TOR and does not imply the execution of calculations on the side of the remote machine. However, this is a perfectly acceptable option when it comes to storing and synchronizing data. For example, this is very conveniently implemented in the same Nextcloud. At the same time, synchronization, versioning and other goodies of the server side will not go anywhere.
Total
There are no perfectly secure systems. The task is only to make the attack more expensive than the potential benefit.
Some reduction in the risks of accessing data on a virtual one can be obtained by combining encryption and separate storage from different hosts.
A more or less reliable option is to use your iron server.
And the hoster will still have to trust one way or another. This is what the whole industry is based on.
Source: habr.com