Application of STIG Baseline to VMware Photon

There has been a lot of great work done to generate STIG baselines for the various VMware products. This content is publicly-available on Github under the vmware/dod-compliance-and-automation repository. As I’m currently focused on using VMware Photon 5, I’m going to explore that process with you now.

Initial Testing

Before applying your STIG, you’ll probably want to run the CINC auditor (think Chef InSpec) to check and see what the current state of your Photon 5 device is. You can install the auditor using the below command, or, from their website.

#https://cinc.sh/download/
curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -P cinc-auditor -v 6

Once installed, navigate to the applicable directory from the Github repo and run the inspec command. You’ll want to modify the input-file to match your environment, but I’m reusing the sample here.

cd dod-compliance-and-automation/photon/5.0/v2r1-srg/inspec/vmware-photon-5.0-stig-baseline &&
inspec exec . -t ssh://root@192.168.1.211 --show-progress --input-file inputs-example.yml -i ~/.ssh/id_rsa

This scan will run and then give you a detailed, as well as summarized view for the machine’s current state when compared to the STIG rules. In this case, my instance has a significant number of deviations.

That same Github repository also contains applicable Ansible playbooks for the application or all or some of the applicable settings. See the Readme in the top level to determine the best approach for you. For this example, I’m just going to apply the all the defaults that don’t require extra-vars.

Once the Ansible Playbook has completed it’s application, you can now re-run the CINC Auditor to validate a successful application. As you can see below, the delta is now significantly smaller.

It’s important to note that I discovered once this activity was completed some logs from /var/log/messages no longer ingest correctly using the configuration specified in Different Logging Approaches. I noticed that almost immediately new logging failures appeared in the Fluentd log.

After doing some analysis, the log events have a pretty wide variety of syntaxes, with some (but not all) including the PID, and some (but not all) placing the process name in parenthesis. Some examples are shown below.

2025-02-27T22:03:16.190527+00:00 photon-test-5 audit: BPF prog-id=27 op=UNLOAD

2025-02-28T17:19:50.996789+00:00 photon-test-5 env[675]: Starting Wazuh v4.10.1...

2025-02-28T17:19:44.501078+00:00 photon-test-5 (udev-worker)[534]: Network interface NamePolicy= disabled on kernel command line.

2025-02-28T17:19:43.981900+00:00 photon-test-5 (systemd): pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal=[<unknown>] user=[root] ruser=[<unknown>] rhost=[<unknown>]"

Because of these variances, you can no longer use the native Syslog parser. Instead, I have created a regular expression that allows for all the variances to be detected and correctly classified.

<source>
  @type tail
  path /host-var-log/messages
  pos_file /var/log/td-agent/messages.pos
  tag system.log
  <parse>
    @type regexp
    expression /(?<timestamp>\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{1,6}\+\d{2}:\d{2}) (?<host>[\w|\-|_|\d]*) (?<proc>\(?[\w|_|-]*\)?)\[?(?<pid>[\d]*)?\]?:(?<message>.*)/
  </parse>
</source>

Using this, you should now have a successfully hardened device, as well as continued logging capabilities if you’re using Fluentd.