Guide to the Secure Configuration of Red Hat OpenStack Platform 13

with profile RHOSP STIG
Sample profile description.

The ComplianceAsCode Project
https://www.open-scap.org/security-policies/scap-security-guide

This guide presents a catalog of security-relevant configuration settings for Red Hat OpenStack Platform 13. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The NIST National Checklist Program (NCP), which provides required settings for the United States Government, is one example of a baseline created from this guidance.

Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile Title	RHOSP STIG
Profile ID	xccdf_org.ssgproject.content_profile_stig

CPE Platforms

cpe:/a:redhat:openstack:13

Revision History

Current version: 0.1.55

draft (as of 2021-03-19)

OpenStack

Checklist

Group Guide to the Secure Configuration of Red Hat OpenStack Platform 13 Group contains 6 groups and 35 rules

Group OpenStack Group contains 5 groups and 35 rules

[ref] TODO TODO TODO

Group Cinder STIG Checklist Group contains 8 rules

[ref] High level overview of Cinder STIG settings to go here!

Rule Check-Block-03: Is keystone used for authentication? [ref]
OpenStack supports various authentication strategies like noauth, keystone etc. If the ‘noauth’ strategy is used then the users could interact with OpenStack services without any authentication. This could be a potential risk since an attacker might gain unauthorized access to the OpenStack components. Thus it is strongly recommended that all services must be authenticated with keystone using their service accounts. Pass: If value of parameter auth_strategy under [DEFAULT] section in /etc/cinder/cinder.conf is set to keystone. Fail: If value of parameter auth_strategy under [DEFAULT] section is set to noauth.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_using_keystone
Identifiers and References	References: FOO-1(a), 3.5.2

Rule Check-Block-06: Does cinder communicates with glance over TLS? [ref]
Similar to previous check (Check-Block-05: Does cinder communicates with nova over TLS?), it is recommended all the components must communicate with each other using a secured communication protocol. Pass: If value of parameter glance_api_insecure under [DEFAULT] section in /etc/cinder/cinder.conf is set to False. Fail: If value of parameter glance_api_insecure under [DEFAULT] section in /etc/cinder/cinder.conf is set to True.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_glance_tls
Identifiers and References	References: FOO-1(a), 3.13.8

Rule Check-Block-02: Are strict permissions set for cinder config files? [ref]
Similar to the previous check, it is recommended to set strict access permissions for such configuration files. Run the following commands: `$ stat -L -c "%a" /etc/cinder/cinder.conf $ stat -L -c "%a" /etc/cinder/api-paste.ini $ stat -L -c "%a" /etc/cinder/policy.json $ stat -L -c "%a" /etc/cinder/rootwrap.conf` Pass: If permissions are set to 640 or stricter. The permissions of 640 translates into owner r/w, group r, and no rights to others i.e. “u=rw,g=r,o=”. Note that with Check-Block-01: Is user/group ownership of config files set to root/cinder? and permissions set to 640, root has read/write access and cinder has read access to these configuration files. The access rights can also be validated using the following command. This command will only be available on your system if it supports ACLs. `$ getfacl --tabular -a /etc/cinder/cinder.conf getfacl: Removing leading '/' from absolute path names # file: etc/cinder/cinder.conf USER root rw- GROUP cinder r-- mask r-- other ---` Fail: If permissions are not set to at least 640.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_file_perms
Identifiers and References	References: FOO-1(a)

Rule Check-Block-08: Is max size for the body of a request set to default (114688)? [ref]
If the maximum body size per request is not defined, the attacker can craft an arbitrary osapi request of large size causing the service to crash and finally resulting in Denial Of Service attack. Assigning the maximum value ensures that any malicious oversized request gets blocked ensuring continued availability of the service. Pass: If value of parameter osapi_max_request_body_size under [DEFAULT] section in /etc/cinder/cinder.conf is set to 114688 or if value of parameter max_request_body_size under [oslo_middleware] section in /etc/cinder/cinder.conf is set to 114688. Fail: If value of parameter osapi_max_request_body_size under [DEFAULT] section in /etc/cinder/cinder.conf is not set to 114688 or if value of parameter max_request_body_size under [oslo_middleware] section in /etc/cinder/cinder.conf is not set to 114688.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_osapi_max_request_body
Identifiers and References	References: FOO-1(a), 3.1.7

Rule Check-Block-05: Does cinder communicates with nova over TLS? [ref]
OpenStack components communicate with each other using various protocols and the communication might involve sensitive / confidential data. An attacker may try to eavesdrop on the channel in order to get access to sensitive information. Thus all the components must communicate with each other using a secured communication protocol. Pass: If value of parameter nova_api_insecure under [DEFAULT] section in /etc/cinder/cinder.conf is set to False. Fail: If value of parameter nova_api_insecure under [DEFAULT] section in /etc/cinder/cinder.conf is set to True.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_nova_tls
Identifiers and References	References: FOO-1(a), 3.13.8

Rule Check-Block-04: Is TLS enabled for authentication? [ref]
OpenStack components communicate with each other using various protocols and the communication might involve sensitive / confidential data. An attacker may try to eavesdrop on the channel in order to get access to sensitive information. Thus all the components must communicate with each other using a secured communication protocol. Pass: If value of parameter auth_protocol under [keystone_authtoken] section in /etc/cinder/cinder.conf is set to https, or if value of parameter identity_uri under [keystone_authtoken] section in /etc/cinder/cinder.conf is set to Identity API endpoint starting with https:// and value of parameter insecure under the same [keystone_authtoken] section in the same /etc/cinder/cinder.conf is set to False. Fail: If value of parameter auth_protocol under [keystone_authtoken] section in /etc/cinder/cinder.conf is set to http, or if value of parameter identity_uri under [keystone_authtoken] section in /etc/cinder/cinder.conf is not set to Identity API endpoint starting with https:// or value of parameter insecure under the same [keystone_authtoken] section in the same /etc/cinder/cinder.conf is set to True.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_tls_enabled
Identifiers and References	References: FOO-1(a), 3.13.8

Rule Check-Block-07: Is NAS operating in secure enviornment? [ref]
Cinder supports an NFS driver which works differently than a traditional block storage driver. The NFS driver does not actually allow an instance to access a storage device at the block level. Instead, files are created on an NFS share and mapped to instances, which emulates a block device. Cinder supports secure configuration for such files by controlling the file permissions when cinder volumes are created. Cinder configuration can also control whether file operations are run as the root user or the current OpenStack process user. Pass: If value of parameter nas_secure_file_permissions under [DEFAULT] section in /etc/cinder/cinder.conf is set to auto. When set to auto, a check is done during cinder startup to determine if there are existing cinder volumes, no volumes will set the option to True, and use secure file permissions. The detection of existing volumes will set the option to False, and use the current insecure method of handling file permissions. If value of parameter nas_secure_file_operations under [DEFAULT] section in /etc/cinder/cinder.conf is set to auto. When set to “auto”, a check is done during cinder startup to determine if there are existing cinder volumes, no volumes will set the option to True, be secure and do NOT run as the root user. The detection of existing volumes will set the option to False, and use the current method of running operations as the root user. For new installations, a “marker file” is written so that subsequent restarts of cinder will know what the original determination had been. Fail: If value of parameter nas_secure_file_permissions under [DEFAULT] section in /etc/cinder/cinder.conf is set to False and if value of parameter nas_secure_file_operations under [DEFAULT] section in /etc/cinder/cinder.conf is set to False.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_nas_secure_file_permissions
Identifiers and References	References: FOO-1(a), 3.1.5

Rule Check-Block-01: Is user/group ownership of config files set to root/cinder? [ref]
Configuration files contain critical parameters and information required for smooth functioning of the component. If an unprivileged user, either intentionally or accidentally, modifies or deletes any of the parameters or the file itself then it would cause severe availability issues resulting in a denial of service to the other end users. Thus user ownership of such critical configuration files must be set to root and group ownership must be set to cinder. Run the following commands: `$ stat -L -c "%U %G" /etc/cinder/cinder.conf \| egrep "root cinder" $ stat -L -c "%U %G" /etc/cinder/api-paste.ini \| egrep "root cinder" $ stat -L -c "%U %G" /etc/cinder/policy.json \| egrep "root cinder" $ stat -L -c "%U %G" /etc/cinder/rootwrap.conf \| egrep "root cinder"` Pass: If user and group ownership of all these config files is set to root and cinder respectively. The above commands show output of root cinder. Fail: If the above commands does not return any output as the user and group ownership might have set to any user other than root or any group other than cinder.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_cinder_file_ownership
Identifiers and References	References: FOO-1(a), 3.1.5

Group Nova STIG Checklist Group contains 5 rules

[ref] High level overview of Nova STIG settings to go here!

Rule Check-Compute-02: Are strict permissions set for Compute configuration files? [ref]
Similar to the previous check, it is recommended to set strict access permissions for such configuration files. Run the following commands: `$ stat -L -c "%a" /etc/nova/nova.conf $ stat -L -c "%a" /etc/nova/api-paste.ini $ stat -L -c "%a" /etc/nova/policy.json $ stat -L -c "%a" /etc/nova/rootwrap.conf` Pass: If permissions are set to 640 or stricter. The permissions of 640 translates into owner r/w, group r, and no rights to others i.e. “u=rw,g=r,o=”. Note that with Check-Compute-01: Is user/group ownership of config files set to root/nova? and permissions set to 640, root has read/write access and nova has read access to these configuration files. The access rights can also be validated using the following command. This command will only be available on your system if it supports ACLs. `$ getfacl --tabular -a /etc/nova/nova.conf getfacl: Removing leading '/' from absolute path names # file: etc/nova/nova.conf USER root rw- GROUP nova r-- mask r-- other ---` Fail: If permissions are not set to at least 640.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_nova_file_perms
Identifiers and References	References: 3.1.5

Rule Check-Compute-04: Is secure protocol used for authentication? [ref]
OpenStack components communicate with each other using various protocols and the communication might involve sensitive / confidential data. An attacker may try to eavesdrop on the channel in order to get access to sensitive information. Thus all the components must communicate with each other using a secured communication protocol. Pass: If value of parameter auth_protocol under [keystone_authtoken] section in /etc/nova/nova.conf is set to https, or if value of parameter identity_uri under [keystone_authtoken] section in /etc/nova/nova.conf is set to Identity API endpoint starting with https://. Fail: If value of parameter auth_protocol under [keystone_authtoken] section in /etc/nova/nova.conf is set to http`, or if value of parameter identity_uri under [keystone_authtoken] section in /etc/nova/nova.conf is not set to Identity API endpoint starting with https://.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_nova_secure_authentication
Identifiers and References	References: 3.13.8

Rule Check-Compute-01: Is user/group ownership of config files set to root/nova? [ref]
Configuration files contain critical parameters and information required for smooth functioning of the component. If an unprivileged user, either intentionally or accidentally modifies or deletes any of the parameters or the file itself then it would cause severe availability issues causing a denial of service to the other end users. Thus user ownership of such critical configuration files must be set to root and group ownership must be set to nova. Run the following commands: `$ stat -L -c "%U %G" /etc/nova/nova.conf \| egrep "root nova" $ stat -L -c "%U %G" /etc/nova/api-paste.ini \| egrep "root nova" $ stat -L -c "%U %G" /etc/nova/policy.json \| egrep "root nova" $ stat -L -c "%U %G" /etc/nova/rootwrap.conf \| egrep "root nova"` Pass: If user and group ownership of all these config files is set to root and nova respectively. The above commands show output of root nova. Fail: If the above commands does not return any output as the user and group ownership might have set to any user other than root or any group other than nova.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_nova_file_ownership
Identifiers and References	References: 3.1.5

Rule Check-Compute-05: Does Nova communicates with Glance securely? [ref]
OpenStack components communicate with each other using various protocols and the communication might involve sensitive / confidential data. An attacker may try to eavesdrop on the channel in order to get access to sensitive information. Thus all the components must communicate with each other using a secured communication protocol. Pass: If value of parameter glance_api_insecure under [DEFAULT] section in /etc/nova/nova.conf is set to False, or if value of parameter api_insecure under [glance] section in /etc/nova/nova.conf is set to False. Fail: If value of parameter glance_api_insecure under [DEFAULT] section in /etc/nova/nova.conf is set to True, or if value of parameter api_insecure under [glance] section in /etc/nova/nova.conf is set to True.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_nova_secure_glance
Identifiers and References	References: 3.13.8

Rule Check-Compute-03: Is keystone used for authentication? [ref]
OpenStack supports various authentication strategies like noauth, keystone etc. If the ‘noauth’ strategy is used then the users could interact with OpenStack services without any authentication. This could be a potential risk since an attacker might gain unauthorized access to the OpenStack components. Thus it is strongly recommended that all services must be authenticated with keystone using their service accounts. Pass: If value of parameter auth_strategy under [DEFAULT] section in /etc/nova/nova.conf is set to keystone. Fail: If value of parameter auth_strategy under [DEFAULT] section is set to noauth or noauth2.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_nova_use_keystone
Identifiers and References	References: 3.1.5

Group Keystone STIG Checklist Group contains 9 rules

[ref] High level overview of Keystone STIG settings to go here!

Rule Check-Identity-01: Is user/group ownership of config files set to keystone? [ref]
Configuration files contain critical parameters and information required for smooth functioning of the component. If an unprivileged user, either intentionally or accidentally modifies or deletes any of the parameters or the file itself then it would cause severe availability issues causing a denial of service to the other end users. Thus user and group ownership of such critical configuration files must be set to that component owner. Run the following commands: $ stat -L -c "%U %G" /etc/keystone/keystone.conf \| egrep "keystone keystone" $ stat -L -c "%U %G" /etc/keystone/keystone-paste.ini \| egrep "keystone keystone" $ stat -L -c "%U %G" /etc/keystone/policy.json \| egrep "keystone keystone" $ stat -L -c "%U %G" /etc/keystone/logging.conf \| egrep "keystone keystone" $ stat -L -c "%U %G" /etc/keystone/ssl/certs/signing_cert.pem \| egrep "keystone keystone" $ stat -L -c "%U %G" /etc/keystone/ssl/private/signing_key.pem \| egrep "keystone keystone" $ stat -L -c "%U %G" /etc/keystone/ssl/certs/ca.pem \| egrep "keystone keystone" Pass: If user and group ownership of all these config files is set to keystone. The above commands show output of keystone keystone. Fail: If the above commands does not return any output as the user or group ownership might have set to any user other than keystone.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_file_ownership
Identifiers and References	References: 3.1.5

Rule Set Maximum Number of Failed Authentication Attempts [ref]
The account lockout feature limits the number of incorrect password attempts. If a user fails to authenticate after the maximum number of attempts, the service disables the user. The maximum number of failed authentication attempts is set by the `lockout_failure_attempts` option in under the `[security_compliance]` section in `keystone.conf`.
Rationale:	Defining a maximum number of failed logon attempts can help mitigate brute force password attacks.
Severity:	medium
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_lockout_failure_attempts
Identifiers and References	References: AC-7, 3.1.8

Rule Check-Identity-04: Does Identity use strong hashing algorithms for PKI tokens? [ref]
MD5 is a weak and depreciated hashing algorithm. It can be cracked using brute force attack. Identity tokens are sensitive and need to be protected with a stronger hashing algorithm to prevent unauthorized disclosure and subsequent access. Pass: If value of parameter hash_algorithm under [token] section in /etc/keystone/keystone.conf is set to SHA256. Fail: If value of parameter hash_algorithm under [token]section is set to MD5.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_algorithm_hashing
Identifiers and References	References: 3.1.11

Rule Set Maximum Inactivity Period [ref]
Keystone can be configured to disable accounts after an organizationally-defined time period. This is achieved by configuring the `disable_user_account_days_inactive` setting in the `[security_compliance]` section in `keystone.conf`.
Rationale:	Automatically disabling accounts ensures that users who have not authenticated for an organizationally-defined time period are automatically disabled. This reduces the risk of stale accounts being used for malicious purposes.
Severity:	medium
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_disable_user_account_days_inactive
Identifiers and References	References: AC-2(3), 3.1.1, 3.1.2

Rule Check-Identity-05: Is max_request_body_size set to default (114688)? [ref]
The parameter max_request_body_size defines the maximum body size per request in bytes. If the maximum size is not defined, the attacker could craft an arbitrary request of large size causing the service to crash and finally resulting in Denial Of Service attack. Assigning the maximum value ensures that any malicious oversized request gets blocked ensuring continued availability of the component. Pass: If value of parameter max_request_body_size in /etc/keystone/keystone.conf is set to default (114688) or some reasonable value based on your environment. Fail: If value of parameter max_request_body_size is not set.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_max_request_body_size
Identifiers and References

Rule Check-Identity-03: is SSL enabled for Identity? [ref]
OpenStack components communicate with each other using various protocols and the communication might involve sensitive or confidential data. An attacker may try to eavesdrop on the channel in order to get access to sensitive information. Thus all the components must communicate with each other using a secured communication protocol like HTTPS. Pass: If value of parameter enable under [ssl] section in /etc/keystone/keystone.conf is set to True. Fail: If value of parameter enable under [ssl] section is not set to True.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_use_ssl
Identifiers and References	References: 3.13.8

Rule Check-Identity-02: Are strict permissions set for Identity configuration files? [ref]
Similar to the previous check, it is recommended to set strict access permissions for such configuration files. Run the following commands: `$ stat -L -c "%a" /etc/keystone/keystone.conf $ stat -L -c "%a" /etc/keystone/keystone-paste.ini $ stat -L -c "%a" /etc/keystone/policy.json $ stat -L -c "%a" /etc/keystone/logging.conf $ stat -L -c "%a" /etc/keystone/ssl/certs/signing_cert.pem $ stat -L -c "%a" /etc/keystone/ssl/private/signing_key.pem $ stat -L -c "%a" /etc/keystone/ssl/certs/ca.pem` Pass: If permissions are set to 640 or stricter. Fail: If permissions are not set to at least 640.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_file_perms
Identifiers and References	References: 3.1.5

Rule Check-Identity-06: Disable admin token in /etc/keystone/keystone.conf [ref]
The admin token is generally used to bootstrap Identity. This token is the most valuable Identity asset, which could be used to gain cloud admin privileges. Pass: If admin_token under [DEFAULT] section in /etc/keystone/keystone.conf is disabled. And, AdminTokenAuthMiddleware under [filter:admin_token_auth] is deleted from /etc/keystone/keystone-paste.ini Fail: If admin_token under [DEFAULT] section is set and AdminTokenAuthMiddleware exists in keystone-paste.ini.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_disable_admin_token
Identifiers and References	References: 3.1.5

Rule Set Account Lockout Duration [ref]
Once a user account is locked out, such as exceeding the amount of logon attempts as defined by `lockout_failure_attempts`, Keystone will lockout an account for the time period defined by the `lockout_duration` configuration option unde the `[security_compliance]` section in `keystone.conf`. Note that if `lockout_failure_attempts` is enabled and `lockout_duration` is left undefined, users will be locked out indefinitely until the user is explicitly re-enabled.
Rationale:	Defining a lockout duration helps mitigate certain attacks, such as brute force attempts. Additionally defining a lockout duration, versus indefinately locking an account, lowers administrative burden of re-enabling accounts of users who accidentally triggered the maximum failure attempts.
Severity:	medium
Rule ID:	xccdf_org.ssgproject.content_rule_keystone_lockout_duration
Identifiers and References	References: AC-7, 3.1.2, 3.1.2

Group Horizon STIG Checklist Group contains 8 rules

[ref] High level overview of Horizon STIG settings to go here!

Rule Check-Dashboard-07: Is password_autocomplete set to False? [ref]
Common feature that applications use to provide users a convenience is to cache the password locally in the browser (on the client machine) and having it ‘pre-typed’ in all subsequent requests. While this feature can be perceived as extremely friendly for the average user, at the same time, it introduces a flaw, as the user account becomes easily accessible to anyone that uses the same account on the client machine and thus may lead to compromise of the user account. Pass: If value of parameter password_autocomplete in /etc/openstack-dashboard/local_settings is set to off. Fail: If value of parameter password_autocomplete in /etc/openstack-dashboard/local_settings is set to on.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_horizon_password_autocomplete
Identifiers and References	References: 3.13.8

Rule Check-Dashboard-02: Are strict permissions set for horizon configuration files? [ref]
Similar to the previous check, it is recommended to set strict access permissions for such configuration files. Run the following commands: `$ stat -L -c "%a" /etc/openstack-dashboard/local_settings` Pass: If permissions are set to 640 or stricter. The permissions of 640 translates into owner r/w, group r, and no rights to others i.e. “u=rw,g=r,o=”. Note that with Check-Dashboard-01: Is user/group of config files set to root/horizon? and permissions set to 640, root has read/write access and horizon has read access to these configuration files. The access rights can also be validated using the following command. This command will only be available on your system if it supports ACLs. `$ getfacl --tabular -a /etc/openstack-dashboard/local_settings getfacl: Removing leading '/' from absolute path names # file: etc/openstack-dashboard/local_settings USER root rw- GROUP horizon r-- mask r-- other ---` Fail: If permissions are not set to at least 640.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_horizon_file_perms
Identifiers and References	References: 3.1.5

Rule Check-Dashboard-05: Is SESSION_COOKIE_SECURE parameter set to True? [ref]
The “SECURE” cookie attribute instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection. This session protection mechanism is mandatory to prevent the disclosure of the session ID through MitM (Man-in-the-Middle) attacks. It ensures that an attacker cannot simply capture the session ID from web browser traffic. Pass: If value of parameter SESSION_COOKIE_SECURE in /etc/openstack-dashboard/local_settings is set to True. Fail: If value of parameter SESSION_COOKIE_SECURE in /etc/openstack-dashboard/local_settings is set to False.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_horizon_session_cookie_secure
Identifiers and References	References: 3.13.8

Rule Check-Dashboard-03: Is USE_SSL parameter set to True? [ref]
Openstack services communicate with each other using various protocols and the communication might involve sensitive/confidential information. An attacker may try to eavesdrop on the channel in order to get access to sensitive information. Thus all the services must communicate with each other using a secured communication protocol like HTTPS. Pass: If value of parameter USE_SSL in /etc/openstack-dashboard/local_settings is set to True. Fail: If value of parameter USE_SSL in /etc/openstack-dashboard/local_settings is set to False.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_horizon_use_ssl
Identifiers and References	References: 3.13.8

Rule Cross-Site Request Forgery Prevention: Enable CSRF_COOKIE_SECURE (non-containerized deployments) [ref]

Usage of a secure cookie for the CSRF cookie is determined by the CSRF_COOKIE_SECURE parameter. When Red Hat OpenStack Platform is deployed as non-containerized services, this configuration setting is configured in the /etc/openstack-dashboard/local_settings file. The CSRF_COOKIE_SECURE option must be set to True:

CSRF_COOKIE_SECURE True

When CSRF_COOKIE_SECURE is set to True, the cookie will be marked as "secure," which means web browsers may ensure that the cookie is only sent with an HTTPS connection.

Rationale:

CSRF (Cross-site request forgery) is an attack which forces an end user to execute unauthorized commands on a web application in which he/she is currently authenticated. A successful CSRF exploit can compromise end user data and operations in case of normal user. If the targeted end user has admin privileges, this can compromise the entire web application.

Severity:

high

Rule ID: xccdf_org.ssgproject.content_rule_horizon_csrf_cookie_secure

Identifiers and References

Identifiers: CCE-82165-2

References: SC-5, 3.1.1, 3.1.2

Remediation Ansible snippet ⇲

Complexity:	low
Disruption:	low
Strategy:	restrict

- name: Enable CSRF_COOKIE_SECURE
  command: openstack-config --set /etc/openstack-dashboard/local_settings DEFAULT
    CSRF_COOKIE_SECURE True
  changed_when: false
  tags:
    - CCE-82165-2
    - NIST-800-171-3.1.1
    - NIST-800-171-3.1.2
    - NIST-800-53-SC-5
    - high_severity
    - horizon_csrf_cookie_secure
    - low_complexity
    - low_disruption
    - no_reboot_needed
    - restrict_strategy

Rule Check-Dashboard-06: Is SESSION_COOKIE_HTTPONLY parameter set to True? [ref]
The “HTTPONLY” cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks. Pass: If value of parameter SESSION_COOKIE_HTTPONLY in /etc/openstack-dashboard/local_settings is set to True. Fail: If value of parameter SESSION_COOKIE_HTTPONLY in /etc/openstack-dashboard/local_settings is set to False.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_horizon_session_cookie_httponly
Identifiers and References	References: 3.13.8

Rule Check-Dashboard-08: Is disable_password_reveal set to True? [ref]
Similar to the previous check, it is recommended not to reveal password fields. Pass: If value of parameter disable_password_reveal in /etc/openstack-dashboard/local_settings is set to True. Fail: If value of parameter disable_password_reveal in /etc/openstack-dashboard/local_settings is set to False.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_horizon_disable_password_reveal
Identifiers and References	References: 3.13.8

Rule Check-Dashboard-01: Is user/group of config files set to root/horizon? [ref]
Configuration files contain critical parameters and information required for smooth functioning of the component. If an unprivileged user, either intentionally or accidentally modifies or deletes any of the parameters or the file itself then it would cause severe availability issues causing a denial of service to the other end users. Thus user ownership of such critical configuration files must be set to root and group ownership must be set to horizon. Run the following commands: `$ stat -L -c "%U %G" /etc/openstack-dashboard/local_settings \| egrep "root horizon"` Pass: If user and group ownership of the config file is set to root and horizon respectively. The above commands show output of root horizon. Fail: If the above commands does not return any output as the user and group ownership might have set to any user other than root or any group other than horizon.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_horizon_file_ownership
Identifiers and References	References: 3.1.5

Group Neutron STIG Checklist Group contains 5 rules

[ref] High level overview of Neutron STIG settings to go here!

Rule Check-Neutron-04: Is secure protocol used for authentication? [ref]
OpenStack components communicate with each other using various protocols and the communication might involve sensitive / confidential data. An attacker may try to eavesdrop on the channel in order to get access to sensitive information. Thus all the components must communicate with each other using a secured communication protocol. Pass: If value of parameter auth_protocol under [keystone_authtoken] section in /etc/neutron/neutron.conf is set to https, or if value of parameter identity_uri under [keystone_authtoken] section in /etc/neutron/neutron.conf is set to Identity API endpoint starting with https://. Fail: If value of parameter auth_protocol under [keystone_authtoken] section in /etc/neutron/neutron.conf is set to http`, or if value of parameter identity_uri under [keystone_authtoken] section in /etc/neutron/neutron.conf is not set to Identity API endpoint starting with https://.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_neutron_use_https
Identifiers and References	References: 3, 13, 8

Rule Check-Neutron-02: Are strict permissions set for Compute configuration files? [ref]
Similar to the previous check, it is recommended to set strict access permissions for such configuration files. Run the following commands: `$ stat -L -c "%a" /etc/neutron/neutron.conf $ stat -L -c "%a" /etc/neutron/api-paste.ini $ stat -L -c "%a" /etc/neutron/policy.json $ stat -L -c "%a" /etc/neutron/rootwrap.conf` Pass: If permissions are set to 640 or stricter. The permissions of 640 translates into owner r/w, group r, and no rights to others i.e. “u=rw,g=r,o=”. Note that with Check-Neutron-01: Is user/group ownership of config files set to root/neutron? and permissions set to 640, root has read/write access and neutron has read access to these configuration files. The access rights can also be validated using the following command. This command will only be available on your system if it supports ACLs. `$ getfacl --tabular -a /etc/neutron/neutron.conf getfacl: Removing leading '/' from absolute path names # file: etc/neutron/neutron.conf USER root rw- GROUP neutron r-- mask r-- other ---` Fail: If permissions are not set to at least 640.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_neutron_file_perms
Identifiers and References	References: 3.1.5

Rule Check-Neutron-01: Is user/group ownership of config files set to root/neutron? [ref]
Configuration files contain critical parameters and information required for smooth functioning of the component. If an unprivileged user, either intentionally or accidentally modifies or deletes any of the parameters or the file itself then it would cause severe availability issues causing a denial of service to the other end users. Thus user ownership of such critical configuration files must be set to root and group ownership must be set to neutron. Run the following commands: $ stat -L -c "%U %G" /etc/neutron/neutron.conf \| egrep "root neutron" $ stat -L -c "%U %G" /etc/neutron/api-paste.ini \| egrep "root neutron" $ stat -L -c "%U %G" /etc/neutron/policy.json \| egrep "root neutron" $ stat -L -c "%U %G" /etc/neutron/rootwrap.conf \| egrep "root neutron" Pass: If user and group ownership of all these config files is set to root and neutron respectively. The above commands show output of root neutron. Fail: If the above commands does not return any output as the user and group ownership might have set to any user other than root or any group other than neutron.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_neutron_file_ownership
Identifiers and References	References: 3.1.5

Rule Check-Neutron-05: Is SSL enabled on Neutron API server? [ref]
Similar to the previous check, it is recommended to enable secure communication on API server. Pass: If value of parameter use_ssl under [DEFAULT] section in /etc/neutron/neutron.conf is set to True. Fail: If value of parameter use_ssl under [DEFAULT] section in /etc/neutron/neutron.conf is set to False.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_neutron_api_use_ssl
Identifiers and References	References: 3.13.8

Rule Check-Neutron-03: Is keystone used for authentication? [ref]
OpenStack supports various authentication strategies like noauth, keystone etc. If the ‘noauth’ strategy is used then the users could interact with OpenStack services without any authentication. This could be a potential risk since an attacker might gain unauthorized access to the OpenStack components. Thus it is strongly recommended that all services must be authenticated with keystone using their service accounts. Pass: If value of parameter auth_strategy under [DEFAULT] section in /etc/neutron/neutron.conf is set to keystone. Fail: If value of parameter auth_strategy under [DEFAULT] section is set to noauth or noauth2.
Rationale:
Severity:	unknown
Rule ID:	xccdf_org.ssgproject.content_rule_neutron_use_keystone
Identifiers and References	References: 3.13.8

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.