Note: This article covers material present in Version 1 Revision 3 and below.  Topics found below may be mitigated in the most current version of the ESXi 5 STIG.  Ensure you are using the most current version of the DISA STIG documents.

Had a colleague point out to me that I gave a pass on a STIG finding for ESXi 5 Server that is, in fact, not that straight forward.  I wanted to take a moment to break that finding out and give some additional guidance.

SRG-OS-99999-ESXI5-000158 – Unauthorized Kernel Modules Must Not Be Loaded on Host

So the key word here is “unauthorized”.  What do they mean?  Well, they are talking about unsigned kernel modules, but there’s a trick to even that.  Per the STIG no kernel module may be loaded that lacks a digital signature… so lets look at how we can do this check.

Right off I’ll tell you there’s at least two ways, likely more, to knock this out.  By default there are a LOT of kernel modules on a default ESXi Server install, too many to go through by hand per the instructions in the STIG.  How can we make this easier.

First off we can reuse a play from the vSphere Hardening Guide for 5.0 and utilize PowerShell.

# List the system modules and Signature Info for each host
Foreach ($VMHost in Get-VMHost )
{
  $ESXCli = Get-EsxCli -VMHost $VMHost $ESXCli.system.module.list() | Foreach {
      $ESXCli.system.module.get($_.Name) | Select @{N="VMHost";E={$VMHost}}, Module, License, Modulefile, Version,
      SignedStatus, SignatureDigest, SignatureFingerPrint
    }
}

This method allows us to inspect the results for each VM on the host you are connected to.

The second method is done from the ESXi command line, like the other commands within the STIG. However, the STIG only provides you instructions on how to do it one module at a time. Here’s how you get a dump of all kernel modules and their signatures at the same time.  This is a one-liner!

 for OUT in $(esxcli system module list | awk '$2 ~/true/ { print $1 }'); do echo $OUT; esxcli system module get -m $OUT | grep "Signature "; done

Now, let’s talk about the catch here.  First off you need to review the following KB article (Unsigned VMkernel Modules in 5.x).  There’s a couple of instances where you might see that certain kernel modules do not show their signature status correctly.  Use caution here and do not just go blindly into disabling kernel modules that do not show their signing status correctly, when compared to the KB above.  If you are in doubt, file a support ticket with VMware Federal Support.  Additionally, keep an eye on this finding in the next revision.  You are likely to see some changes to this requirement in the very near future.

Big Giant Note: If you are using OEM provided installation media, like HP or Dell, you will likely see several kernel modules that do not show their signature correctly.  The first thing to note is that the signature will not show if the module is not enabled.  Second, and I cannot stress this enough, do not go blindly disabling kernel modules.  When in doubt always file a support ticket with our Federal Support Team and walk though it with them.