22

We are running a few Solaris / Linux VMs on ESXi that contain very sensitive encrypted data that eventually get decrypted as required in memory.

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.

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?

Marius Burz
  • 331
  • 1
  • 2
  • 6
  • Are you only concerned about a condition where your ESXi host crashes? – ewwhite Dec 23 '12 at 18:39
  • 1
    @ewwhite not only. The main concern is that this decrypted data ends up in the host's FS, and this is a big security concern to us. – Marius Burz Dec 23 '12 at 18:44
  • 1
    Why? Who has access to the server? – ewwhite Dec 23 '12 at 18:49
  • 3
    I don't mean to be rude but I'd rather return the attention to the initial question. – Marius Burz Dec 23 '12 at 18:54
  • 1
    But @ewwhite is one of our foremost VMware experts. He's certainly asking for a very good reason. After all, understanding the [totality of your situation](http://meta.stackexchange.com/q/66377/189912) is critical to giving you [a good answer](http://meta.serverfault.com/q/3608/126632). – Michael Hampton Dec 23 '12 at 18:57
  • 6
    It was a security audit that triggered the whole situation, we'd just feel so much more comfortable having no memory that contains decrypted data dumped/serialized to the FS. – Marius Burz Dec 23 '12 at 19:03

3 Answers3

14

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.

enter image description here

No memory reservation (default):

root@deore:/volumes/vol2/staging/Test_Bed# ls -al | grep vswp
-rw------- 1 nfs  nobody  3221225472 Dec 23 13:31 Test_Bed-ad493981.vswp
-rw------- 1 nfs  nobody   115343360 Dec 23 13:31 vmx-Test_Bed-2907257217-1.vswp

With memory reservation locked-in:

root@deore:/volumes/vol2/staging/Test_Bed# ls -al | grep vswp
-rw------- 1 nfs  nobody           0 Dec 23 13:38 Test_Bed-ad493981.vswp
-rw------- 1 nfs  nobody   115343360 Dec 23 13:38 vmx-Test_Bed-2907257217-1.vswp

Edit 20210711: Wayback Machine or Archive Today archived versions of the above links (of which some already were gone):

Jeroen Wiert Pluimers
  • 286
  • 5
  • 14
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 2
    A theoretical scenario would involve a string of events (as always), say a host crashes, HDDs get replaced, those HDDs might contain decrypted data in such swap files (unbeknown to most), end up in the wrong hands because most think the data on them is not that sensitive (the sensitive data lies on other HDDs, encrypted). – Marius Burz Dec 23 '12 at 19:24
  • @MariusBurz See edits above. – ewwhite Dec 23 '12 at 19:52
  • We couldn't get rid of the vmx-*.vswp files, but now that you say they aren't what we thought they are, we need to have another look at the whole thing. I can confirm on my 5.1 test machine @ home the standard vswp file is created with 0kb. – Marius Burz Dec 23 '12 at 20:03
  • 2
    @MariusBurz The vmx vswp files are controlled by the `sched.swap.vmxSwapEnabled` parameter. They can also be disabled. – ewwhite Dec 23 '12 at 20:07
  • 1
    Thank you very much for helping me out @ewwhite. I wish I could have explained it better as it came to what files still got created, it would have been much easier for you to recognize where our problem lied. We thought that file was a standard swap file where it wasn't. – Marius Burz Dec 23 '12 at 20:16
4

It 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.

Community
  • 1
user9517
  • 114,104
  • 20
  • 206
  • 289
2

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
  • 237,123
  • 42
  • 477
  • 940
  • This is indeed one way of solving this problem, but it still is only a workaround. I assume the most secure would be using some local SEDs, any idea whether/how ESXi supports them? – Marius Burz Dec 23 '12 at 18:37