We are running a few Solaris / Linux VMs on ESXi that contain very sensitive encrypted data that eventually get decrypted as required in memory.
VMware Snapshot can be simply created using vSphere client connected to ESXi host or vCenter Server and through vSphere web client. Even VMware snapshots can be created using the command line and powerCLI scripts. Let’s take a look at how to create Virtual Machine Snapshot from vSphere Web Client. To begin this process and make things clean we will first remove (not the data) the VM from the VMware Infrastructure clients inventory list (right click on the VM and select Remove from Inventory). Then to replace a corrupted VMX file you can rename, preferable option, or delete the offending VMX file.
Everything is fine, except for the ESXi swap files which could potentially store some of the decrypted data, the cherry on top of the cake being that these files won't get removed in case of a host crash.
![Disable Disable](https://docs.vmware.com/en/VMware-vSphere/6.0/com.vmware.vsphere.virtualsan.doc/images/GUID-AC0A3321-CB3E-4160-86E7-1787DFECD50F-low.png)
Is there any way to disable these files completely?
We already tried reserving the whole allocated RAM to the VMs on a per VM basis, but the files still get created.
What would it take to have ESXi swapping completely disabled for the entire host or only for some VMs?
3 Answers
This is an interesting question. I've never thought about data security at the hypervisor level... usually security policies and hardening revolve around OS-specific tasks (limiting daemons, ports, disabling core files, filesystem mount options, etc.)
But after some quick research (and running strings
against active VMWare .vswp files) shows that it's definitely possible to extract data from .vswp files residing on a VMWare datastore. This link helps explain the lifecycle of such files.
In your case, I think your approach is going to be determined security policy and requirements. In my experience in finance and dealing with audits, I think that an accepted approach would be to limit/secure access to the host server. Recall that by default, your ESXi host does not have SSH or console access enabled. Enabling those features throws an event/alert in vCenter that needs to be manually overridden, so the assumption is that auditing access is the best way to control access to this information.
If there are concerns about who may have access to the server, there may not be a technical solution to an administrative problem. I'll check some other sources to see if there's a way to limit use of .vswp files, though.
--edit--
You can reserve all of the guest RAM. You don't specify which version of VMWare you're using, but in my 5.1 installation, there's an option to Reserve all guest memory. Enabling this option creates a zero-length .vswp file, rather than one equal to the size of RAM allocated to the virtual machine. Pay no attention to the vmx-*.vswp file. That's new to ESXi 5.x, and it's not related to the guest's operating system memory pressure (it's for VMX process heap, guest peripherals and management agents). In addition, the vmx-*.vswp files can be disabled by setting sched.swap.vmxSwapEnabled
to FALSE
.
I think this will give you what you're asking for.
No memory reservation (default):
With memory reservation locked-in:
ewwhiteewwhiteIt looks like your trying to solve the problem wrong. Trying to stop the machine swapping is no guarantee that sensitive data will not get on disk. What about core dumps etc ? Once you have a writable device that has been in a system that contains sensitive data it should not be considered 'clean' and should be destroyed when it's use is over.
If your data is that sensitive then you should physically secure the system. Everyone who needs access the system should be vetted appropriately and specifically authorized to do so. Their activities need to be authorized,logged and supervised etc.
The scenario you describe is easily managed. You should have procedures for destroying the devices that contain sensitive data commensurate with the sensitivity of the data. You simply do not let the device out of your secure environment unless it is signed for by an appropriate authority at which point it ceases to be your problem.
It should be sufficient to encrypt the virtual machine swapfiles that ESXi creates. Try putting the swapfiles on a datastore that's encrypted, such as an encrypting SAN or self-encrypting disk.
Michael Hampton♦Michael Hampton