Guide to the Secure Configuration of Red Hat OpenStack Platform 10
with profile [DRAFT] Controlled Unclassified Infomration (CUI) Profile for Red Hat OpenStack Plaform 10These are the controls for scanning against CUI for rhosp10
https://www.open-scap.org/security-policies/scap-security-guide
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.
Profile Title | [DRAFT] Controlled Unclassified Infomration (CUI) Profile for Red Hat OpenStack Plaform 10 |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_cui |
Revision History
Current version: 0.1.58
- draft (as of 2021-10-11)
Platforms
- cpe:/a:redhat:openstack:10
Table of Contents
Checklist
contains 36 rules |
OpenStackgroupTODO TODO TODO |
contains 36 rules |
Cinder STIG ChecklistgroupHigh level overview of Cinder STIG settings to go here! |
contains 9 rules |
Check-Block-02: Are strict permissions set for cinder config files?rule To properly set the permissions of $ sudo chmod 0640 /etc/cinder/*.confRationale: Due to the nature of the cinder config files, normal users should not be able to view contents references: 3.1.5 Remediation script:
|
Check-Block-01: Is user/group ownership of config files set to root/cinder?ruleConfiguration 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.
references: 3.1.5 |
Check-Block-02: Are strict permissions set for cinder config files?ruleSimilar to the previous check, it is recommended to set strict access permissions for such configuration files.
|
Check-Block-06: Does cinder communicates with glance over TLS?ruleSimilar 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.
references: 3.13.8 |
Check-Block-07: Is NAS operating in secure enviornment?ruleCinder 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.
references: 3.1.5 |
Check-Block-05: Does cinder communicates with nova over TLS?ruleOpenStack 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.
references: 3.13.8 |
Check-Block-08: Is max size for the body of a request set to default (114688)?ruleIf 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.
references: 3.1.7 |
Check-Block-04: Is TLS enabled for authentication?ruleOpenStack 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.
references: 3.13.8 |
Check-Block-03: Is keystone used for authentication?ruleOpenStack 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.
references: 3.5.2 |
Horizon STIG ChecklistgroupHigh level overview of Horizon STIG settings to go here! |
contains 8 rules |
Cross-Site Request Forgery Prevention: Enable CSRF_COOKIE_SECURE (non-containerized deployments)ruleUsage of a secure cookie for the CSRF cookie is determined by the CSRF_COOKIE_SECURE TrueWhen 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. Remediation script:
|
Check-Dashboard-08: Is disable_password_reveal set to True?ruleSimilar to the previous check, it is recommended not to reveal password fields.
references: 3.13.8 |
Check-Dashboard-01: Is user/group of config files set to root/horizon?ruleConfiguration 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.
references: 3.1.5 |
Check-Dashboard-02: Are strict permissions set for horizon configuration files?ruleSimilar to the previous check, it is recommended to set strict access permissions for such configuration files.
references: 3.1.5 |
Check-Dashboard-07: Is password_autocomplete set to False?ruleCommon 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.
references: 3.13.8 |
Check-Dashboard-06: Is SESSION_COOKIE_HTTPONLY parameter set to True?ruleThe “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.
references: 3.13.8 |
Check-Dashboard-05: Is SESSION_COOKIE_SECURE parameter set to True?ruleThe “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.
references: 3.13.8 |
Check-Dashboard-03: Is USE_SSL parameter set to True?ruleOpenstack 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.
references: 3.13.8 |
Keystone STIG ChecklistgroupHigh level overview of Keystone STIG settings to go here! |
contains 9 rules |
Check-Identity-04: Does Identity use strong hashing algorithms for PKI tokens?ruleMD5 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.
references: 3.1.11 |
Check-Identity-06: Disable admin token in /etc/keystone/keystone.confruleThe 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.
references: 3.1.5 |
Set Maximum Inactivity PeriodruleKeystone can be configured to disable accounts after an
organizationally-defined time period. This is achieved by configuring the
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. |
Check-Identity-01: Is user/group ownership of config files set to keystone?ruleConfiguration 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.
references: 3.1.5 |
Check-Identity-02: Are strict permissions set for Identity configuration files?ruleSimilar to the previous check, it is recommended to set strict access permissions for such configuration files.
references: 3.1.5 |
Set Account Lockout DurationruleOnce a user account is locked out, such as exceeding the
amount of logon attempts as defined by 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. |
Set Maximum Number of Failed Authentication AttemptsruleThe 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.
Defining a maximum number of failed logon attempts can help mitigate brute force password attacks. |
Check-Identity-05: Is max_request_body_size set to default (114688)?ruleThe 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.
|
Check-Identity-03: is SSL enabled for Identity?ruleOpenStack 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.
references: 3.13.8 |
Neutron STIG ChecklistgroupHigh level overview of Neutron STIG settings to go here! |
contains 5 rules |
Check-Neutron-05: Is SSL enabled on Neutron API server?ruleSimilar to the previous check, it is recommended to enable secure communication on API server.
references: 3.13.8 |
Check-Neutron-01: Is user/group ownership of config files set to root/neutron?ruleConfiguration 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.
references: 3.1.5 |
Check-Neutron-02: Are strict permissions set for Compute configuration files?ruleSimilar to the previous check, it is recommended to set strict access permissions for such configuration files.
references: 3.1.5 |
Check-Neutron-04: Is secure protocol used for authentication?ruleOpenStack 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.
|
Check-Neutron-03: Is keystone used for authentication?ruleOpenStack 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.
references: 3.13.8 |
Nova STIG ChecklistgroupHigh level overview of Nova STIG settings to go here! |
contains 5 rules |
Check-Compute-01: Is user/group ownership of config files set to root/nova?ruleConfiguration 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.
references: 3.1.5 |
Check-Compute-02: Are strict permissions set for Compute configuration files?ruleSimilar to the previous check, it is recommended to set strict access permissions for such configuration files.
references: 3.1.5 |
Check-Compute-04: Is secure protocol used for authentication?ruleOpenStack 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.
references: 3.13.8 |
Check-Compute-05: Does Nova communicates with Glance securely?ruleOpenStack 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.
references: 3.13.8 |
Check-Compute-03: Is keystone used for authentication?ruleOpenStack 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.
references: 3.1.5 |