Guide to the Secure Configuration of Red Hat Enterprise OpenStack Platform
with profile RHEL OSP STIGSample profile description.
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 DISA STIG for Red Hat Enterprise OpenStack Platform is one example of a baseline created from this guidance.
This benchmark is a direct port of a SCAP Security Guide benchmark developed for Red Hat Enterprise Linux. It has been modified through an automated process to remove specific dependencies on Red Hat Enterprise Linux and to function with Scientifc Linux. The result is a generally useful SCAP Security Guide benchmark with the following caveats:
- Scientifc Linux is not an exact copy of Red Hat Enterprise Linux. Scientific Linux is a Linux distribution produced by Fermi National Accelerator Laboratory. It is a free and open source operating system based on Red Hat Enterprise Linux and aims to be "as close to the commercial enterprise distribution as we can get it." There may be configuration differences that produce false positives and/or false negatives. If this occurs please file a bug report.
- Scientifc Linux is derived from the free and open source software made available by Red Hat, but it is not produced, maintained or supported by Red Hat. Scientifc Linux has its own build system, compiler options, patchsets, and is a community supported, non-commercial operating system. Scientifc Linux does not inherit certifications or evaluations from Red Hat Enterprise Linux. As such, some configuration rules (such as those requiring FIPS 140-2 encryption) will continue to fail on Scientifc Linux.
Members of the Scientifc Linux community are invited to participate in OpenSCAP and SCAP Security Guide development. Bug reports and patches can be sent to GitHub: https://github.com/OpenSCAP/scap-security-guide. The mailing list is at https://fedorahosted.org/mailman/listinfo/scap-security-guide.
Profile Title | RHEL OSP STIG |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_stig-openstack |
Revision History
Current version: 0.1.29
- draft (as of 2016-05-05)
Platforms
- cpe:/o:redhat:enterprise_linux:7
- cpe:/o:scientificlinux:scientificlinux:7
- cpe:/o:redhat:enterprise_linux:7::client
Table of Contents
Checklist
contains 32 rules |
ServicesgroupIntro paragraph on need to secure OSP services. |
contains 32 rules |
Horizon STIG ChecklistgroupHigh level overview of Horizon STIG settings to go here! |
contains 8 rules |
Check-Dashboard-01: Is user/group of config files set to root/horizon?rule
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.
|
Check-Dashboard-02: Are strict permissions set for horizon configuration files?rule
Similar to the previous check, it is recommended to set strict access permissions for such configuration files.
|
Check-Dashboard-03: Is USE_SSL parameter set to True?rule
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.
|
Check-Dashboard-04: Is CSRF_COOKIE_SECURE parameter set to True?rule
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.
|
Check-Dashboard-05: Is SESSION_COOKIE_SECURE parameter set to True?rule
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.
|
Check-Dashboard-06: Is SESSION_COOKIE_HTTPONLY parameter set to True?rule
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.
|
Check-Dashboard-07: Is password_autocomplete set to False?rule
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.
|
Check-Dashboard-08: Is disable_password_reveal set to True?rule
Similar to the previous check, it is recommended not to reveal password fields.
|
Cinder STIG ChecklistgroupHigh level overview of Cinder STIG settings to go here! |
contains 8 rules |
Check-Block-01: Is user/group ownership of config files set to root/cinder?rule
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.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a)
|
Check-Block-02: Are strict permissions set for Compute configuration files?rule
Similar to the previous check, it is recommended to set strict access permissions for such configuration files.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a)
|
Check-Block-03: Is keystone used for authentication?rule
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.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a)
|
Check-Block-04: Is TLS enabled for authentication?rule
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.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a)
|
Check-Block-05: Does cinder communicates with nova over TLS?rule
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.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a)
|
Check-Block-06: Does cinder communicates with glance over TLS?rule
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.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a)
|
Check-Block-07: Is NAS operating in secure enviornment?rule
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.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a) |
Check-Block-08: Is max size for the body of a request set to default (114688)?rule
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.
identifiers: CCE-RHELOSP-CCE-TBD references: FOO-1(a)
|
Keystone STIG ChecklistgroupHigh level overview of Keystone STIG settings to go here! |
contains 6 rules |
Check-Identity-01: Is user/group ownership of config files set to keystone?rule
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.
|
Check-Identity-02: Are strict permissions set for Identity configuration files?rule
Similar to the previous check, it is recommended to set strict access permissions for such configuration files.
|
Check-Identity-03: is SSL enabled for Identity?rule
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.
|
Check-Identity-04: Does Identity use strong hashing algorithms for PKI tokens?rule
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.
|
Check-Identity-05: Is max_request_body_size set to default (114688)?rule
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.
|
Check-Identity-06: Disable admin token in /etc/keystone/keystone.confrule
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.
|
Neutron STIG ChecklistgroupHigh level overview of Neutron STIG settings to go here! |
contains 5 rules |
Check-Neutron-01: Is user/group ownership of config files set to root/neutron?rule
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.
|
Check-Neutron-02: Are strict permissions set for Compute configuration files?rule
Similar to the previous check, it is recommended to set strict access permissions for such configuration files.
|
Check-Neutron-03: Is keystone used for authentication?rule
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.
|
Check-Neutron-04: Is secure protocol used for authentication?rule
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.
|
Check-Neutron-05: Is SSL enabled on Neutron API server?rule
Similar to the previous check, it is recommended to enable secure communication on API server.
|
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?rule
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.
|
Check-Compute-02: Are strict permissions set for Compute configuration files?rule
Similar to the previous check, it is recommended to set strict access permissions for such configuration files.
|
Check-Compute-03: Is keystone used for authentication?rule
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.
|
Check-Compute-04: Is secure protocol used for authentication?rule
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.
|
Check-Compute-05: Does Nova communicates with Glance securely?rule
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.
|