This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Aria

Performing compliance automation tasks for Aria Suite products.

1 - Audit VMware Aria Automation 8

Auditing VMware Aria Automation 8.x for STIG Compliance

Overview

Auditing VMware Aria Automation for STIG compliance involves scanning the application, the Kubernetes and Docker services running on the appliance, and the underlying Photon OS.

When auditing VMware Aria Automation we will split up tasks between product and appliance based controls which are defined as follows:

  • Product Control: Configurations that interact with the Product via the User Interface or API that are exposed to administrators. Whether these are Default or Non-Default, the risk of mis-configuration affecting availability of the product is low but could impact how the environment is operated if not assessed.
  • Appliance Control: Appliance controls deal with the underlying components (databases, web servers, Photon OS, etc.) that make up the product. Altering these add risk to product availability if precautionary steps and care in implementation are not taken. Identifying and relying on Default settings in this category makes this category less risky (Default Appliance Controls should be seen as a positive).

The VMware Aria Automation auditing uses InSpec over an SSH connection. It is recommended to disable SSH after the auditing is complete.

Prerequisites

Versions listed below were used for this documentation. Other versions of these tools may work as well but if issues are found it is recommended to utilize the versions listed here.

Assumptions

  • Commands are initiated from a Linux machine. Windows will also work but paths and commands may need to be adjusted from the examples.
  • The DOD Compliance and Automation repository downloaded and extracted to /usr/share/stigs.
  • CINC Auditor is used in lieu of InSpec. If InSpec is used replace cinc-auditor with inspec when running commands.

Auditing VMware Aria Automation

Update profile inputs

Included in each of the vmware-vra-8x-stig-baseline sub-folders (aria-automation, docker, and kubernetes) is an inspec input file named ‘inspec.yml’. Additionally, at the top level, an inputs.yml file can be created that “rolls up” all of the variables into one file, and can be utilized at the command line.

Evaluate each of the input files (aria-automation/inspec.yml, docker\inspec.yml, kubernetes\inspec.yml), and if any of the input variables need to be over-ridden, then make sure those variables are included in the top level inputs.yml file. Examples are provided below.

VMware Aria Automation - Sample Inputs

syslogHost: "log.test.local"
ntpServers: "['time1.server.org', 'time2.server.org']"
maxAuthTries: "2"

Update the SSH config to allow scan

If the VMware Aria Automation appliance has SSH access disabled, the scans will not be able to run. SSH must be temporarily enabled to complete the scan, then can be disabled again once the audit is complete.

# Connect to the console through vCenter
vi /etc/ssh/sshd_config
# Update PermitRootLogin from no to yes and save
systemctl restart sshd

Run the audit

In this example we will be scanning a target VMware Aria Automation appliance, specifying an inputs file, and outputting a report to the CLI and to a JSON file.

# Note this command is run from the root of the profile folder. Update paths as needed (instead of '.', use './path/to/profile') if running from a different location.
> cinc-auditor exec . -t ssh://root@aria-automation.domain.path --password 'replaceme' --show-progress --input-file inputs.yml --reporter cli json:/tmp/reports/Aria_Automation_8x_STIG_Report.json

# Shown below is example output at the CLI.
  ✔  PHTN-40-000227: The Photon operating system must not send IPv4 Internet Control Message Protocol redirects.
     ✔  Kernel Parameter net.ipv4.conf.all.send_redirects value is expected to cmp == 0
     ✔  Kernel Parameter net.ipv4.conf.default.send_redirects value is expected to cmp == 0
  ✔  PHTN-40-000228: The Photon operating system must log IPv4 packets with impossible addresses.
     ✔  Kernel Parameter net.ipv4.conf.all.log_martians value is expected to cmp == 1
     ✔  Kernel Parameter net.ipv4.conf.default.log_martians value is expected to cmp == 1
  ✔  PHTN-40-000229: The Photon operating system must use a reverse-path filter for IPv4 network traffic.
     ✔  Kernel Parameter net.ipv4.conf.all.rp_filter value is expected to cmp == 1
     ✔  Kernel Parameter net.ipv4.conf.default.rp_filter value is expected to cmp == 1

Profile Summary: zz successful controls, zz control failures, zz controls skipped
Test Summary: zz successful, zz failures, zz skipped

Convert the results to CKL

If a STIG Viewer Checklist (CKL) file is needed then the results from the scans can be converted to CKL with the SAF CLI.

# Converting the scan results from the prior section to CKL
saf convert hdf2ckl -i /tmp/reports/Aria_Automation_8x_STIG_Report.json -o /tmp/reports/Aria_Automation_8x_STIG_Report.ckl --hostname aria-automation --fqdn aria-automation.domain.path --ip 10.10.10.20 --mac 00:00:00:00:00:00

Opening the CKL file in STIG Viewer will look like the example screenshot below. Note the InSpec results are included in the Finding Details pane.
STIG Viewer Checklist

2 - Remediate VMware Aria Automation 8

Remediating VMware Aria Automation 8.x for STIG Compliance

Overview

Remediating VMware Aria Automation for STIG compliance includes the application, the Kubernetes and Docker services running on the appliance, and the underlying Photon OS.

Remediating the application controls is currently a manual process. Please refer to the Photon, Kubernetes, and Docker documentation for details on remediating those controls with the provided Ansible content.

3 - Audit VMware Aria Suite Lifecycle 8

Auditing VMware Aria Suite Lifecycle for STIG Compliance

Overview

Auditing VMware Aria Suite Lifecycle for STIG compliance involves scanning the NGINX and vpostgres components, the underlying Photon OS, and the application itself.

When auditing VMware Aria Suite Lifecycle we will split up tasks between product and appliance based controls which are defined as follows:

  • Product Control: Configurations that interact with the Product via the User Interface or API that are exposed to administrators. Whether these are Default or Non-Default, the risk of mis-configuration effecting availability of the product is low but could impact how the environment is operated if not assessed.
  • Appliance Control: Appliance controls deal with the underlying components (databases, web servers, Photon OS, etc) that make up the product. Altering these add risk to product availability if precautionary steps and care in implementation are not taken. Identifying and relying on Default settings in this category makes this category less risky (Default Appliance Controls should be seen as a positive).

To audit VMware Aria Suite Lifecycle using InSpec we utilize the ssh transport which connects to the appliance via ssh and performs queries. It is recommended to disable SSH on the appliance after the auditing is complete.

Prerequisites

Versions listed below were used for this documentation. Other versions of these tools may work as well but if issues are found it is recommended to utilize the versions listed here.

  • The vmware-vrslcm-8.x-stig-baseline profile downloaded.
  • InSpec/Cinc Auditor 6.6.0
  • SAF CLI 1.4.0
  • STIG Viewer 2.17
  • A VMware Aria Suite Lifecycle environment. Version 8.18 was used in these examples.
  • An account with SSH access to VMware Aria Suite Lifecycle.

Assumptions

  • Commands are initiated from a Linux machine. Windows will also work but paths and commands may need to be adjusted from the examples.
  • The DOD Compliance and Automation repository downloaded and extracted to /usr/share/stigs.
  • CINC Auditor is used in lieu of InSpec. If InSpec is used replace cinc-auditor with inspec when running commands.

Auditing VMware Aria Suite Lifecycle

Update profile inputs

Included in each of the vmware-vrslcm-8.x-stig-baseline sub-folders (application, nginx, photon, and vpostgres) is an inspec input file named ‘inspec.yml’. Additionally, at the top level, an inputs-example.yml file is included that “rolls up” all of the variables into one file, and can be edited and utilized at the command line.

Evaluate each of the input files (application/inspec.yml, nginx/inspec.yml, photon/inspec.yml, vpostgres/inspec.yml), and if any of the input variables need to be over-ridden, then make sure those variables are included in the top level inputs-example.yml file. Examples are provided below.

VMware Aria Operations for Logs - Sample Inputs

# Application
hostname:                         "lifecycle.domain"
username:                         "admin@local"
password:                         "password"
ntpServers:                       ["time-a-b.nist.gov", "time-a-c.nist.gov"] 

# NGINX
limit_conn_server_limit:          "1000"
hsts_header:                      "max-age=31536000"
nginx_ssl_session_timeout:        "5m"
nginx_keepalive_timeout:          "65"

Update the SSH config to allow scan

If the VMware Aria Suite Lifecycle appliance has SSH access disabled, the scans will not be able to run. SSH must be temporarily enabled to complete the scan, then can be disabled again once the audit is complete.

# Connect to the console through vCenter
vi /etc/ssh/sshd_config
# Update PermitRootLogin from no to yes and save
systemctl restart sshd

Run the audit

In this example we will be scanning a target VMware Aria Suite Lifecycle appliance, specifying an inputs file, and outputting a report to the CLI and to a JSON file.

# Note this command is run from the root of the profile folder. Update paths as needed (instead of '.', use './path/to/profile') if running from a different location.
> cinc-auditor exec . -t ssh://root@aria-lifecycle.domain.path --password 'replaceme' --show-progress --input-file inputs-example.yml --reporter cli json:/tmp/reports/Aria_Lifecycle_8x_STIG_Report.json

# Shown below is example output at the CLI.
  ✔  PHTN-30-000119: The Photon operating system must configure sshd to restrict AllowTcpForwarding.
     ✔  Command: `sshd -T|&grep -i allowtcpforwarding` stdout.strip is expected to cmp == "allowtcpforwarding no"
  ✔  PHTN-30-000120: The Photon operating system must configure sshd to restrict LoginGraceTime.
     ✔  Command: `sshd -T|&grep -i LoginGraceTime` stdout.strip is expected to cmp == "LoginGraceTime 30"
  ✔  PHTN-30-000240: The Photon operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, generate cryptographic hashes, and protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
     ✔  File /proc/sys/crypto/fips_enabled content is expected to cmp == 1
  ✔  PHTN-30-000245: The Photon operating system must disable systemd fallback Domain Name System (DNS).
     ✔  Command: `resolvectl status | grep 'Fallback DNS'` stdout is expected to cmp == ""


Profile Summary: zz successful controls, zz control failures, zz controls skipped
Test Summary: zz successful, zz failures, zz skipped

Convert the results to CKL

If a STIG Viewer Checklist (CKL) file is needed then the results from the scans can be converted to CKL with the SAF CLI.

# Converting the scan results from the prior section to CKL
saf convert hdf2ckl -i /tmp/reports/Aria_Lifecycle_8x_STIG_Report.json -o /tmp/reports/Aria_Lifecycle_8x_STIG_Report.ckl --hostname aria-lifecycle --fqdn aria-lifecycle.domain.path --ip 10.10.10.20 --mac 00:00:00:00:00:00

Opening the CKL file in STIG Viewer will look like the example screenshot below. Note the InSpec results are included in the Finding Details pane.
STIG Viewer Checklist

4 - Remediate VMware Aria Suite Lifecycle 8

Remediating VMware Aria Suite Lifecycle 8.x for STIG Compliance

Overview

Remediating VMware Aria Suite Lifecycle for STIG compliance involves configuring nginx, postgres, photon, and the appliance.

When remediating we will split up tasks between product and appliance based controls which are defined as follows:

  • Product Control: Configurations that interact with the Product via the User Interface or API that are exposed to administrators. Whether these are Default or Non-Default, the risk of mis-configuration effecting availability of the product is low but could impact how the environment is operated if not assessed.
  • Appliance Control: Appliance controls deal with the underlying components (databases, web servers, Photon OS, etc) that make up the product. Altering these add risk to product availability without precautionary steps and care in implementation. Identifying and relying on Default settings in this category makes this category less risky (Default Appliance Controls should be seen as a positive).

Ansible will be used to perform remediation.

Prerequisites

Versions listed below were used for this documentation. Other versions of these tools may work as well but if issues are found it is recommended to try the versions listed here.

  • Ansible 2.16.7
  • A VMware Aria Suite Lifecycle 8.14 or newer environment.
  • An account with sufficient privileges to configure VMware Aria Suite Lifecycle.

Assumptions

  • Commands are initiated from a Linux machine.
  • The DOD Compliance and Automation repository downloaded and extracted to /usr/share/stigs.
  • Ansible installed and all playbook dependencies resolved as provided in the requirements.yml file in each playbook. Install with ansible-galaxy roles install -r requirements.yml.
  • The dependent Photon OS Ansible roles(Photon 3.0) installed and available. Verify role installation with ansible-galaxy role list.

Remediate VMware Aria Suite Lifecycle (Appliance and/or Product Controls)

An Ansible playbook has been provided that will target a single VMware Aria Suite Lifecycle server over SSH and configure any non-compliant controls.

Running the playbook

To run all of the controls, follow the example below:

  • Navigate to the Ansible playbook folder
    cd /usr/share/stigs/aria/lifecycle/8.x/v1r2-srg/ansible/vmware-vrslcm-8.x-stig-ansible-hardening

  • The -k parameter will prompt for password.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b

  • Output example:

SSH password:

PLAY [VRLCM 8.x Remediation Automation] *********************************************************************************

TASK [Gathering Facts] **************************************************************************************************
ok: [10.225.1.22]

TASK [nginx : Include nginx] ********************************************************************************************
included: /usr/stigs/LCM_ANSIBLE/vmware-vrlcm-8.x-stig-ansible-hardening/roles/nginx/tasks/nginx.yml for 10.225.1.22

TASK [nginx : Backup nginx.conf - Create time stamp] ********************************************************************
ok: [10.225.1.22] => {"ansible_facts": {"backup_timestamp": "2024-07-21-19-49-12"}, "changed": false}

TASK [nginx : Backup nginx.conf - If restoring be sure to restore permissions that original file had!!] *****************
ok: [10.225.1.22] => {"changed": false, "checksum": "a607028d0dca90b99f9288409d0943f", "dest": "/tmp/ansible-backups-vrlcm-nginx-2024-07-21-19-49-12/nginx.conf", "gid": 0, "group": "root", "md5sum": "dc629a0d27436898449629b", "mode": "0750", "owner": "root", "size": 7806, "src": "/etc/nginx/nginx.conf", "state": "file", "uid": 0}

TASK [nginx : VLMN-8X-000019 - Check log file permissions] **************************************************************
ok: [10.225.1.22] => {"changed": false, "cmd": "find /var/log/nginx/* -xdev -type f -a '(' -perm -640 -o -not -user root -o -not -group root ')' -exec ls {} \\;", "delta": "0:00:00.007661", "end": "2024-07-23 22:32:20.151514", "msg": "", "rc": 0, "start": "2024-07-23 22:32:20.143853", "stderr": "", "stderr_lines": [], "stdout": "/var/log/nginx/access.log\n/var/log/nginx/error.log", "stdout_lines": ["/var/log/nginx/access.log", "/var/log/nginx/error.log"]}

TASK [nginx : VLMN-8X-000019 - Verify and update file permissions] ******************************************************
changed: [10.225.1.22] => (item=/var/log/nginx/access.log) => {"ansible_loop_var": "item", "changed": true, "gid": 0, "group": "root", "item": "/var/log/nginx/access.log", "mode": "0640", "owner": "root", "path": "/var/log/nginx/access.log", "size": 165, "state": "file", "uid": 0}
changed: [10.225.1.22] => (item=/var/log/nginx/error.log) => {"ansible_loop_var": "item", "changed": true, "gid": 0, "group": "root", "item": "/var/log/nginx/error.log", "mode": "0640", "owner": "root", "path": "/var/log/nginx/error.log", "size": 533, "state": "file", "uid": 0}

....

PLAY RECAP **************************************************************************************************************
10.225.1.22      : ok=9    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  • A more conservative and preferred approach is to target any non-compliant controls or run each component separately to allow for functional testing in between.

  • Providing the tag “nginx” will instruct the playbook to only run the nginx role. This tag can be seen in each role’s task/main.yml file.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b -t nginx

  • Providing the tag “VLMN-8X-000019” will instruct the playbook to only run the task tagged with the STIG ID of VLMN-8X-000019.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b -t VLMN-8X-000019

5 - Audit VMware Aria Operations for Logs 8

Auditing VMware Aria Operations for Logs 8.x for STIG Compliance

Overview

Auditing VMware Aria Operations for Logs for STIG compliance involves scanning the application, the cassandra and tc server services, and the underlying Photon OS.

When auditing VMware Aria Operations for Logs we will split up tasks between product and appliance based controls which are defined as follows:

  • Product Control: Configurations that interact with the Product via the User Interface or API that are exposed to administrators. Whether these are Default or Non-Default, the risk of mis-configuration affecting availability of the product is low but could impact how the environment is operated if not assessed.
  • Appliance Control: Appliance controls deal with the underlying components (databases, web servers, Photon OS, etc.) that make up the product. Altering these add risk to product availability if precautionary steps and care in implementation are not taken. Identifying and relying on Default settings in this category makes this category less risky (Default Appliance Controls should be seen as a positive).

The VMware Aria Operations for Logs auditing uses InSpec over an SSH connection. It is recommended to disable SSH after the auditing is complete.

Prerequisites

Versions listed below were used for this documentation. Other versions of these tools may work as well but if issues are found it is recommended to utilize the versions listed here.

Assumptions

  • Commands are initiated from a Linux machine. Windows will also work but paths and commands may need to be adjusted from the examples.
  • The DOD Compliance and Automation repository downloaded and extracted to /usr/share/stigs.
  • CINC Auditor is used in lieu of InSpec. If InSpec is used replace cinc-auditor with inspec when running commands.

Auditing VMware Aria Operations for Logs

Update profile inputs

Included in each of the vmware-vrli-8.x-stig-baseline sub-folders (ariaopslogs, cassandra, and tcserver) is an inspec input file named ‘inspec.yml’. Additionally, at the top level, an inputs-example.yml file is included that “rolls up” all of the variables into one file, and can be edited and utilized at the command line.

Evaluate each of the input files (ariaopslogs/inspec.yml, cassandra\inspec.yml, tcserver\inspec.yml), and if any of the input variables need to be over-ridden, then make sure those variables are included in the top level inputs-example.yml file. Examples are provided below.

VMware Aria Operations for Logs - Sample Inputs

# Application
apipath:                   "loginsight.domain:9543/api/v2"
username:                  "admin"
password:                  "PASSWORD"
ntpServers:                ["0.vmware.pool.ntp.org", "1.vmware.pool.ntp.org", "2.vmware.pool.ntp.org", "3.vmware.pool.ntp.org"]

# Cassandra
ipaddress:                 "10.10.10.10"

# tc Server
maxThreads:                "150"
minUmask:                  "0007"
connectionTimeout:         "20000"
maxKeepAliveRequests:      "50"
sessionTimeout:            "30"

# Photon
usePwqualityConf:          true
syslogServer:              "syslog.test.local:514"

Update the SSH config to allow scan

If the VMware Aria Operations for Logs appliance has SSH access disabled, the scans will not be able to run. SSH must be temporarily enabled to complete the scan, then can be disabled again once the audit is complete.

# Connect to the console through vCenter
vi /etc/ssh/sshd_config
# Update PermitRootLogin from no to yes and save
systemctl restart sshd

Run the audit

In this example we will be scanning a target VMware Aria Operations for Logs appliance, specifying an inputs file, and outputting a report to the CLI and to a JSON file.

# Note this command is run from the root of the profile folder. Update paths as needed (instead of '.', use './path/to/profile') if running from a different location.
> cinc-auditor exec . -t ssh://root@aria-ops-logs.domain.path --password 'replaceme' --show-progress --input-file inputs-example.yml --reporter cli json:/tmp/reports/Aria_Ops_Logs_8x_STIG_Report.json

# Shown below is example output at the CLI.
  ✔  PHTN-40-000227: The Photon operating system must not send IPv4 Internet Control Message Protocol redirects.
     ✔  Kernel Parameter net.ipv4.conf.all.send_redirects value is expected to cmp == 0
     ✔  Kernel Parameter net.ipv4.conf.default.send_redirects value is expected to cmp == 0
  ✔  PHTN-40-000228: The Photon operating system must log IPv4 packets with impossible addresses.
     ✔  Kernel Parameter net.ipv4.conf.all.log_martians value is expected to cmp == 1
     ✔  Kernel Parameter net.ipv4.conf.default.log_martians value is expected to cmp == 1
  ✔  PHTN-40-000229: The Photon operating system must use a reverse-path filter for IPv4 network traffic.
     ✔  Kernel Parameter net.ipv4.conf.all.rp_filter value is expected to cmp == 1
     ✔  Kernel Parameter net.ipv4.conf.default.rp_filter value is expected to cmp == 1


Profile Summary: zz successful controls, zz control failures, zz controls skipped
Test Summary: zz successful, zz failures, zz skipped

Convert the results to CKL

If a STIG Viewer Checklist (CKL) file is needed then the results from the scans can be converted to CKL with the SAF CLI.

# Converting the scan results from the prior section to CKL
saf convert hdf2ckl -i /tmp/reports/Aria_Ops_Logs_8x_STIG_Report.json -o /tmp/reports/Aria_Ops_Logs_8x_STIG_Report.ckl --hostname aria-ops-logs --fqdn aria-ops-logs.domain.path --ip 10.10.10.20 --mac 00:00:00:00:00:00

Opening the CKL file in STIG Viewer will look like the example screenshot below. Note the InSpec results are included in the Finding Details pane.
STIG Viewer Checklist

6 - Remediate VMware Aria Operations for Logs 8

Remediating VMware Aria Operations for Logs 8.x for STIG Compliance

Overview

Remediating VMware Aria Operations for Logs for STIG compliance involves configuring cassandra, tc server, photon, and the appliance.

When remediating we will split up tasks between product and appliance based controls which are defined as follows:

  • Product Control: Configurations that interact with the Product via the User Interface or API that are exposed to administrators. Whether these are Default or Non-Default, the risk of mis-configuration effecting availability of the product is low but could impact how the environment is operated if not assessed.
  • Appliance Control: Appliance controls deal with the underlying components (databases, web servers, Photon OS, etc) that make up the product. Altering these add risk to product availability without precautionary steps and care in implementation. Identifying and relying on Default settings in this category makes this category less risky (Default Appliance Controls should be seen as a positive).

Ansible will be used to perform remediation.

Prerequisites

Versions listed below were used for this documentation. Other versions of these tools may work as well but if issues are found it is recommended to try the versions listed here.

  • Ansible 2.16.7
  • A VMware Aria Operations for Logs 8.14 or newer environment.
  • An account with sufficient privileges to configure VMware Aria Suite Lifecycle.

Assumptions

  • Commands are initiated from a Linux machine.
  • The DOD Compliance and Automation repository downloaded and extracted to /usr/share/stigs.
  • Ansible installed and all playbook dependencies resolved as provided in the requirements.yml file in each playbook. Install with ansible-galaxy roles install -r requirements.yml.
  • The dependent Photon OS Ansible roles(Photon 4.0) installed and available. Verify role installation with ansible-galaxy role list.

Remediate VMware Aria Operations for Logs (Appliance and/or Product Controls)

An Ansible playbook has been provided that will target a single VMware Aria Operations for Logs server over SSH and configure any non-compliant controls.

Running the playbook

To run all of the controls, follow the example below:

  • Navigate to the Ansible playbook folder
    cd /usr/share/stigs/aria/operations-for-logs/8.x/v1r4-srg/ansible/vmware-vrli-8.x-stig-ansible-hardening

  • The -k parameter will prompt for password.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b

  • Output example:

SSH password:

PLAY [VRLI 8.x Remediation Automation] ******************************************************

TASK [Gathering Facts] **********************************************************************
ok: [10.225.1.3]

TASK [ariaopslogs : Include ariaopslogs] ****************************************************
included: /usr/stigs/vmware-vrli-8.x-stig-ansible-hardening/roles/ariaopslogs/tasks/ariaopslogs.yml for 10.10.10.20

TASK [ariaopslogs : Generate sessionId] *****************************************************
ok: [10.225.1.3] => {"access_control_expose_headers": "X-Content-Type-Options,X-LI-Build", "changed": false, "connection": "close", "content_length": "223", "content_type": "application/json; charset=UTF-8", "cookies": {}, "cookies_string": "", "date": "Tue, 23 Jul 2024 22:19:09 UTC", "elapsed": 0, "json": {"sessionId": "k6USJl6s+PXLuCz4gXgVJJ9WwJu9V9Emi8YwaozwETk8u43TAKAVsXFM4JNipoat7tjai6dj/", "ttl": 1800, "userId": "c17ae391-df17-4954-8a3a-7545e87c"}, "msg": "OK (223 bytes)", "redirected": false, "status": 200, "url": "https://10.10.10.20:9543/api/v2/sessions", "x_content_type_options": "nosniff", "x_li_build": "24021974"}

TASK [ariaopslogs : Extract & save sessionId] ***********************************************
ok: [10.225.1.3] => {"ansible_facts": {"session_id": "k6USJl6s+PXLuCz4gXgVJJ9WwJu9V9Emi8YwaozwETKUKPWnx8F6L+1BQb7hk6Tk8u43TAKAVsXFM4JNipokvWlziI3K8NmaoDw1fsGJat7tjai6dj/"}, "changed": false}

TASK [cassandra : Include cassandra] ********************************************************
included: /usr/stigs/vmware-vrli-8.x-stig-ansible-hardening/roles/cassandra/tasks/cassandra.yml for 10.225.1.3

TASK [cassandra : VLIC-8X-000007 - Check log conf file permissions] *************************
ok: [10.225.1.3] => {"changed": false, "cmd": "stat -c \"%a:%U:%G\" /usr/lib/loginsight/application/lib/apache-cassandra-4.1.4/conf/cassandra.yaml;", "delta": "0:00:00.011136", "end": "2024-07-23 22:19:13.212163", "msg": "", "rc": 0, "start": "2024-07-23 22:19:13.201027", "stderr": "", "stderr_lines": [], "stdout": "644:root:root", "stdout_lines": ["644:root:root"]}

TASK [cassandra : VLIC-8X-000007 - Verify and update conf file permissions] *****************
changed: [10.225.1.3] => (item=644:root:root) => {"ansible_loop_var": "item", "changed": true, "gid": 0, "group": "root", "item": "644:root:root", "mode": "0640", "owner": "root", "path": "/usr/lib/loginsight/application/lib/apache-cassandra-4.1.4/conf/cassandra.yaml", "size": 88384, "state": "file", "uid": 0}

TASK [tcserver : Include tcserver] **********************************************************
included: /usr/stigs/vmware-vrli-8.x-stig-ansible-hardening/roles/tcserver/tasks/tcserver.yml for 10.225.1.3

TASK [tcserver : Backup files - Create time stamp] ******************************************
ok: [10.225.1.3] => {"ansible_facts": {"backup_timestamp": "2024-07-21-19-36-12"}, "changed": false}

....

PLAY RECAP **********************************************************************************
10.10.10.20    : ok=10   changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  • A more conservative and preferred approach is to target any non-compliant controls or run each component separately to allow for functional testing in between.

  • Providing the tag “cassandra” will instruct the playbook to only run the cassandra role. This tag can be seen in each role’s task/main.yml file.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b -t cassandra

  • Providing the tag “VLIC-8X-000007” will instruct the playbook to only run the task tagged with the STIG ID of VLIC-8X-000007.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b -t VLIC-8X-000007

7 - Audit VMware Aria Operations 8

Auditing VMware Aria Operations 8.x for STIG Compliance

Overview

Auditing VMware Aria Operations for STIG compliance involves scanning the application, the web services, the vpostgres service, and the underlying Photon OS.

When auditing VMware Aria Operations we will split up tasks between product and appliance based controls which are defined as follows:

  • Product Control: Configurations that interact with the Product via the User Interface or API that are exposed to administrators. Whether these are Default or Non-Default, the risk of mis-configuration affecting availability of the product is low but could impact how the environment is operated if not assessed.
  • Appliance Control: Appliance controls deal with the underlying components (databases, web servers, Photon OS, etc.) that make up the product. Altering these add risk to product availability if precautionary steps and care in implementation are not taken. Identifying and relying on Default settings in this category makes this category less risky (Default Appliance Controls should be seen as a positive).

The VMware Aria Operations auditing uses InSpec over an SSH connection. It is recommended to disable SSH after the auditing is complete.

Prerequisites

Versions listed below were used for this documentation. Other versions of these tools may work as well but if issues are found it is recommended to utilize the versions listed here.

Assumptions

  • Commands are initiated from a Linux machine. Windows will also work but paths and commands may need to be adjusted from the examples.
  • The DOD Compliance and Automation repository downloaded and extracted to /usr/share/stigs.
  • CINC Auditor is used in lieu of InSpec. If InSpec is used replace cinc-auditor with inspec when running commands.

Auditing VMware Aria Operations

Update profile inputs

Included in each of the vmware-aria-operations-8x-stig-baseline sub-folders (application, apache, api, casa, ui, and vpostgres) is an inspec input file named ‘inspec.yml’. Additionally, at the top level, an inputs.yml file can be created that “rolls up” all of the variables into one file, and can be utilized at the command line.

Evaluate each of the input files (application/inspec.yml, apache\inspec.yml, etc.), and if any of the input variables need to be over-ridden, then make sure those variables are included in the top level inputs.yml file. Examples are provided below.

VMware Aria Operations - Sample Inputs

api-sessionTimeout:        "30"
api-maxThreads:            "300"
casa-sessionTimeout:       "30"
casa-maxThreads:           "300"
ui-sessionTimeout:         "30"
ui-maxThreads:             "300"
#vpostgres
tcpKeepAliveIdle:          "7200"
tcpKeepAliveInterval:      "75"
tcpKeepAliveCount:         "9"

Update the SSH config to allow scan

If the VMware Aria Operations appliance has SSH access disabled, the scans will not be able to run. SSH must be temporarily enabled to complete the scan, then can be disabled again once the audit is complete.

# Connect to the console through vCenter
vi /etc/ssh/sshd_config
# Update PermitRootLogin from no to yes and save
systemctl restart sshd

Run the audit

In this example we will be scanning a target VMware Aria Operations appliance, specifying an inputs file, and outputting a report to the CLI and to a JSON file.

# Note this command is run from the root of the profile folder. Update paths as needed (instead of '.', use './path/to/profile') if running from a different location.
> cinc-auditor exec . -t ssh://root@aria-ops.domain.path --password 'replaceme' --show-progress --input-file inputs.yml --reporter cli json:/tmp/reports/Aria_Ops_8x_STIG_Report.json

# Shown below is example output at the CLI.
  ✔  PHTN-50-000241: The Photon operating system must install rsyslog for offloading of audit logs.
     ✔  Service rsyslog is expected to be installed
  ✔  PHTN-50-000242: The Photon operating system must enable the rsyslog service.
     ✔  Service rsyslog is expected to be enabled
     ✔  Service rsyslog is expected to be running
  ✔  PHTN-50-000244: The Photon operating system must enable hardlink access control protection in the kernel.
     ✔  Kernel Parameter fs.protected_hardlinks value is expected to cmp == 1
  ✔  PHTN-50-000245: The Photon operating system must mount /tmp securely.
     ✔  ["mode=1777", "strictatime", "nosuid", "nodev", "size=50%%", "nr_inodes=1m", "noexec"] is expected to include "nosuid", "noexec", and "nodev"
  ✔  PHTN-50-000246: The Photon operating system must restrict core dumps.
     ✔  Kernel Parameter fs.suid_dumpable value is expected to eq 0 or eq 2

Profile Summary: zz successful controls, zz control failures, zz controls skipped
Test Summary: zz successful, zz failures, zz skipped

Convert the results to CKL

If a STIG Viewer Checklist (CKL) file is needed then the results from the scans can be converted to CKL with the SAF CLI.

# Converting the scan results from the prior section to CKL
saf convert hdf2ckl -i /tmp/reports/Aria_Ops_8x_STIG_Report.json -o /tmp/reports/Aria_Ops_8x_STIG_Report.ckl --hostname aria-ops --fqdn aria-ops.domain.path --ip 10.10.10.20 --mac 00:00:00:00:00:00

Opening the CKL file in STIG Viewer will look like the example screenshot below. Note the InSpec results are included in the Finding Details pane.
STIG Viewer Checklist

8 - Remediate Aria Operations 8

Remediating VMware Aria Operations 8.x for STIG Compliance

Overview

Remediating VMware Aria Operations for STIG compliance involves configuring apache, the tc server services, photon, postgres, and the appliance.

When remediating we will split up tasks between product and appliance based controls which are defined as follows:

  • Product Control: Configurations that interact with the Product via the User Interface or API that are exposed to administrators. Whether these are Default or Non-Default, the risk of mis-configuration effecting availability of the product is low but could impact how the environment is operated if not assessed.
  • Appliance Control: Appliance controls deal with the underlying components (databases, web servers, Photon OS, etc) that make up the product. Altering these add risk to product availability without precautionary steps and care in implementation. Identifying and relying on Default settings in this category makes this category less risky (Default Appliance Controls should be seen as a positive).

Ansible will be used to perform remediation.

Prerequisites

Versions listed below were used for this documentation. Other versions of these tools may work as well but if issues are found it is recommended to try the versions listed here.

  • Ansible 2.16.7
  • A VMware Aria Operations 8.14 or newer environment.
  • An account with sufficient privileges to configure VMware Aria Suite Lifecycle.

Assumptions

  • Commands are initiated from a Linux machine.
  • The DOD Compliance and Automation repository downloaded and extracted to /usr/share/stigs.
  • Ansible installed and all playbook dependencies resolved as provided in the requirements.yml file in each playbook. Install with ansible-galaxy roles install -r requirements.yml.
  • The dependent Photon OS Ansible roles(Photon 4.0 for 8.14 to 8.16, Photon 5.0 for 8.18) installed and available. Verify role installation with ansible-galaxy role list.

Remediate VMware Aria Operations (Appliance and/or Product Controls)

An Ansible playbook has been provided that will target a single VMware Aria Operations server over SSH and configure any non-compliant controls.

Running the playbook

To run all of the controls, follow the example below:

  • Navigate to the Ansible playbook folder
    cd /usr/share/stigs/aria/operations/8.x/v1r3-srg/ansible/vmware-aria-operations-8.x-stig-ansible-hardening

  • The -k parameter will prompt for password.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b

  • Output example:

SSH password:

PLAY [vmware-aria-operations-8x-stig-ansible-hardening] ************************************************

TASK [Gathering Facts] *********************************************************************************
ok: [10.10.10.20]

TASK [apache : Include apache] *************************************************************************
included: /usr/stigs/vmware-vrops-8.x-stig-ansible-hardening/roles/apache/tasks/apache.yml for 10.10.10.20

....

TASK [ui : Include ui] *********************************************************************************
included: /usr/stigs/vmware-vrops-8.x-stig-ansible-hardening/roles/ui/tasks/ui.yml for 10.225.0.148

TASK [ui : VRPU-8X-000001 - Add or configure maximum concurrent connections permitted - Executor node] *********
changed: [10.225.0.148] => {"actions": {"namespaces": {}, "state": "present", "xpath": "//Executor[@name=\"tomcatThreadPool\"]"}, "changed": true}

TASK [ui : VRPU-8X-000001 - Add or configure maximum concurrent connections permitted - Connector node] *********
changed: [10.225.0.148] => {"actions": {"namespaces": {}, "state": "present", "xpath": "//Connector[not(@executor)] | //Connector[@executor != \"tomcatThreadPool\"]"}, "changed": true}

....

RUNNING HANDLER [ui : Restart UI] **********************************************************************
changed: [10.225.0.148] => {"changed": true, "name": "vmware-vcops-web.service", "state": "started", 
...
}

PLAY RECAP *********************************************************************************************
10.225.0.148    : ok=12   changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  • A more conservative and preferred approach is to target any non-compliant controls or run each component separately to allow for functional testing in between.

  • Providing the tag “ui” will instruct the playbook to only run the ui role. This tag can be seen in each role’s task/main.yml file.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b -t ui

  • Providing the tag “VRPU-8X-000001” will instruct the playbook to only run the task tagged with the STIG ID of VRPU-8X-000001.
    ansible-playbook -i 10.10.10.20, -u root playbook.yml -k -v -b -t VRPU-8X-000001