STIG Controls by Tag¶

Notes for deployers and auditors¶

Implementation Status: Implemented

The security role installs and configures the aide package to provide file integrity monitoring on the host.

Notes for deployers and auditors¶

Implementation Status: Implemented

The aide package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place.

The cron job is installed as part of the aide package installation. If the cron job is missing, an error will be printed and the playbook will fail.

Notes for deployers and auditors¶

Implementation Status: Implemented

AIDE is configured to exclude certain directories, and that list of directories is controlled by the security_aide_exclude_dirs Ansible variable.

Notes for deployers and auditors¶

Implementation Status: Implemented

The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. The cron job is installed as part of the aide package installation.

If the cron job is missing, an error will be printed and the playbook will fail.

Notes for deployers and auditors¶

Implementation Status: Implemented

The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. The cron job is installed as part of the aide package installation. If the cron job is missing, an error will be printed and the playbook will fail.

Notes for deployers and auditors¶

Implementation Status: Implemented

The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. The cron job is installed as part of the aide package installation. If the cron job is missing, an error will be printed and the playbook will fail.

Notes for deployers and auditors¶

Implementation Status: Implemented

The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. The cron job is installed as part of the aide package installation. If the cron job is missing, an error will be printed and the playbook will fail.

Notes for deployers and auditors¶

Implementation Status: Implemented

When AIDE is first installed for V-38429, a new database will be created. The creation process takes some time because AIDE needs to review each file in its list of monitored files to get timestamps and hashes. The initialization will be forked into the background so that it doesn’t slow down the playbook run.

Some directories are excluded from AIDE runs to prevent AIDE from wandering into directories where it shouldn’t be hashing/monitoring files. The defaults/main.yml file has some recommended directories as part of the security_aide_exclude_dirs variable.

Notes for deployers and auditors¶

Implementation Status: Implemented

The logs generated by the audit daemon are owned by root in Ubuntu 14.04, Ubuntu 16.04 and CentOS 7. The Ansible task for V-38445 ensures that the files are owned by the root user.

Notes for deployers and auditors¶

Implementation Status: Implemented

The default configuration for disk_error_action is SUSPEND, which only suspends audit logging when there is a disk error on the system. Suspending audit logging can lead to security problems because the system is no longer keeping track of which syscalls were made.

The security role sets the configuration to SYSLOG so that messages are sent to syslog when disk errors occur. There are additional options available, like EXEC, SINGLE or HALT.

To configure a different disk_error_action, set the following Ansible variable:

security_disk_error_action: SYSLOG

For details on available settings and what they do, run man auditd.conf. Some options can cause the host to go offline until the issue is fixed. Deployers are urged to carefully read the auditd documentation prior to changing the security_disk_error_action setting from the default.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Storing audit logs on a separate partition is recommended, but this change is left up to deployers to configure during the installation of the OS.

Notes for deployers and auditors¶

Implementation Status: Implemented

The default configuration for disk_full_action is SUSPEND, which only suspends audit logging. Suspending audit logging can lead to security problems because the system is no longer keeping track of which syscalls were made.

The security role sets the configuration to SYSLOG so that messages are sent to syslog when the disk is full. If syslog messages are being sent to remote servers, these log messages should alert an administrator about the disk being full. There are additional options available, like EXEC, SINGLE or HALT.

To configure a different disk_full_action, set the following Ansible variable:

security_disk_full_action: SYSLOG

For details on available settings and what they do, run man auditd.conf. Some options can cause the host to go offline until the issue is fixed. Deployers are urged to carefully read the auditd documentation prior to changing the disk_full_action setting from the default.

Notes for deployers and auditors¶

Implementation Status: Implemented

The default configuration for security_space_left_action is SUSPEND, which actually only suspends audit logging. Suspending audit logging can lead to security problems because the system is no longer keeping track of which syscalls were made.

The security role sets the configuration to SYSLOG so that messages are sent to syslog when the available disk space reaches a low level. If syslog messages are being sent to remote servers, these log messages should alert an administrator about the disk being almost full. There are additional options available, like EXEC, SINGLE or HALT.

To configure a different space_left_action, set the following Ansible variable:

security_space_left_action: SYSLOG

For details on available settings and what they do, run man auditd.conf. Some options can cause the host to go offline until the issue is fixed. Deployers are urged to carefully read the auditd documentation prior to changing the space_left_action setting from the default.

Notes for deployers and auditors¶

Implementation Status: Implemented

An Ansible task will adjust active from no to yes in /etc/audisp/plugins.d/syslog.conf so that auditd records are forwarded to syslog automatically. The auditd daemon will be restarted if the configuration file is changed.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set the mode of /var/log/audit/ to 0750 by default. The Ansible task for this requirement ensures that the mode is 0750 (which is more strict than the STIG requirement).

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will ensure that files in /var/log/audit are owned by the root user.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu and CentOS set the current audit log (the one that is actively being written to) to 0600 so that only the root user can read and write to it. The older, rotated logs are set to 0400 since they should not receive any more writes.

The STIG requirement states that log files must have mode 0640 or less. The security role will remove any permissions that are not allowed by the STIG (u-x,g-wx,o-rwx).

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules are added for auditing changes to system time done via stime.

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules are added for auditing changes to system time done via clock_settime.

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules are added to auditd to log all attempts to change the system time using /etc/localtime.

Notes for deployers and auditors¶

Implementation Status: Implemented

The audit rules from V-38534 already cover all account modifications.

Notes for deployers and auditors¶

Implementation Status: Implemented

Audit rules are added in a task so that any events associated with account modifications are logged. The new audit rule will be loaded immediately with augenrules --load.

Notes for deployers and auditors¶

Implementation Status: Implemented

The audit rules from V-38534 already cover all account modifications.

Notes for deployers and auditors¶

Implementation Status: Implemented

The audit rules from V-38534 already cover all account modifications.

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules are added that allows auditd to track network configuration changes.

Notes for deployers and auditors¶

Implementation Status: Implemented

For Ubuntu, rules are added to auditd that will log any changes made in the /etc/apparmor directory.

For CentOS, rules are added to auditd that will log any changes made in the /etc/selinux directory.

To opt-out of this change, set the following Ansible variable:

security_audit_mac_changes: no

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules which monitor chmod, fchmod, and fchmodat syscalls can cause high CPU and I/O load during OpenStack-Ansible deployments and while updating packages with apt. By default, these rules are disabled.

These audit rules can be enabled by setting any of the following variables:

security_audit_DAC_chmod: yes
security_audit_DAC_fchmod: yes
security_audit_DAC_fchmodat: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with chown are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for chown usage by setting the following Ansible variable:

security_audit_DAC_chown: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules which monitor chmod, fchmod, and fchmodat syscalls can cause high CPU and I/O load during OpenStack-Ansible deployments and while updating packages with apt. By default, these rules are disabled.

These audit rules can be enabled by setting any of the following variables:

security_audit_DAC_chmod: yes
security_audit_DAC_fchmod: yes
security_audit_DAC_fchmodat: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules which monitor chmod, fchmod, and fchmodat syscalls can cause high CPU and I/O load during OpenStack-Ansible deployments and while updating packages with apt. By default, these rules are disabled.

These audit rules can be enabled by setting any of the following variables:

security_audit_DAC_chmod: yes
security_audit_DAC_fchmod: yes
security_audit_DAC_fchmodat: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with fchown are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for fchown usage by setting the following Ansible variable:

security_audit_DAC_fchown: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with fchownat are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for fchownat usage by setting the following Ansible variable:

security_audit_DAC_fchownat: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with fremovexattr are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for fremovexattr usage by setting the following Ansible variable:

security_audit_DAC_fremovexattr: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with fsetxattr are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for fsetxattr usage by setting the following Ansible variable:

security_audit_DAC_fsetxattr: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with lchown are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for lchown usage by setting the following Ansible variable:

security_audit_DAC_lchown: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with lremovexattr are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for lremovexattr usage by setting the following Ansible variable:

security_audit_DAC_lremovexattr: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with lxsetxattr are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for lsetxattr usage by setting the following Ansible variable:

security_audit_DAC_lsetxattr: yes

Notes for deployers and auditors¶

Implementation Status: Implemented

Audit rules are added in a task so that any events associated with the discretionary access controls (DAC) permission modifications are logged. The new audit rule will be loaded immediately with augenrules --load.

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for permission changes made with setxattr are disabled by default as they can generate an excessive amount of logs in a short period of time, especially during a deployment.

Deployers can enable auditing for lsetxattr usage by setting the following Ansible variable:

security_audit_DAC_lsetxattr: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for logging failed access attempts can generate significant amounts of log traffic in some environments. These rules are disabled by default.

To opt-in for this change and enable audit logging for these events, adjust the following Ansible variable:

security_auditd_failed_access: yes

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules are added for auditd to log successful filesystem mounts.

Notes for deployers and auditors¶

Implementation Status: Opt-In

The audit rules for monitoring deleted files can cause very high system load during OpenStack-Ansible deployments and during package updates using apt. It’s recommended that deployers keep these rules disabled unless they’re explicitly required.

These rules are disabled by default, but they can be enabled by setting the following Ansible variable:

security_audit_deletions: yes

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules are added to audit changes to /etc/sudoers.

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules will be added to auditd so that any kernel module loading or unloading events will be logged.

Notes for deployers and auditors¶

Implementation Status: Implemented

This STIG requirement overlaps with V-38632.

Notes for deployers and auditors¶

Implementation Status: Implemented

This STIG requirement overlaps with V-38632.

Notes for deployers and auditors¶

Implementation Status: Implemented

The tasks in auth.yml will install auditd and ensure it is running.

Notes for deployers and auditors¶

Implementation Status: Implemented

The default setting for security_max_log_file in Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 matches the STIG requirement of rotating logs when they reach 6MB. The Ansible task for this STIG requirement ensures that the secure default is maintained.

Deployers who want to exceed the STIG guideline can increase the size of logs by adjusting the following Ansible variable:

security_max_log_file: 6

Notes for deployers and auditors¶

Implementation Status: Implemented

The default action for security_max_log_file_action on Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 is to rotate the logs. This meets the STIG requirements and the Ansible task will ensure that the secure default is maintained.

Use caution when changing this option. Certain values, like SUSPEND will cause the audit daemon to lock the machine when the maximum size for a log file is reached. Review the audit documentation carefully before making adjustments.

Notes for deployers and auditors¶

Implementation Status: Implemented

Audit rules are added in a task so that any events associated with altering system time are logged. The new audit rule will be loaded immediately with augenrules --load.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu keeps 5 rotated logs with the security_num_logs option and this meets the STIG requirement. The Ansible task will ensure that the secure default is maintained.

Deployers who want to allow logs to grow to larger sizes prior to rotation can adjust the following Ansible variable:

security_num_logs: 5

Notes for deployers and auditors¶

Implementation Status: Implemented

The auditd package is verified with debsums in Ubuntu and with rpm in CentOS. The playbook will fail immediately if any of the files from the auditd package have been altered. This could be the sign of a system compromise.

Notes for deployers and auditors¶

Implementation Status: Implemented

When auditd notices that free disk space on its logging partition is low, it will trigger the security_space_left_action. The threshold of remaining disk space is configured by security_space_left in /etc/audit/auditd.conf.

By default, Ubuntu 14.04, Ubuntu 16.04 and CentOS 7 set this value to 75 megabytes. The STIG doesn’t set a specific requirement for the exact size, so the Ansible task will ensure that the default of 75 megabytes is set.

Notes for deployers and auditors¶

Implementation Status: Opt-In

The STIG requires that the audit system must switch the entire system into single-user mode when the space for logging becomes dangerously low.

The security_admin_space_left_action configuration is set to SUSPEND by default, and this will cause logging to be temporarily suspended until disk space is freed.

For extremely high security environments, this Ansible variable can be provided to meet the requirements of the STIG:

security_admin_space_left_action: SINGLE

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Although adding centralized authentication and carefully managing user accounts is critical for securing any system, that’s left up to deployers to handle via their internal business processes.

Notes for deployers and auditors¶

Implementation Status: Implemented

The /etc/gshadow file is owned by root by default on Ubuntu 14.04, Ubuntu 16.04 and CentOS 7. The security role ensures that the file is owned by root.

Notes for deployers and auditors¶

Implementation Status: Implemented

Although the /etc/gshadow file is group-owned by root by default, the Ansible tasks will ensure that it is configured that way.

Notes for deployers and auditors¶

Implementation Status: Implemented

The /etc/gshadow file’s permissions will be changed to 0000 to meet the requirements of the STIG.

Notes for deployers and auditors¶

Implementation Status: Implemented

The ownership of /etc/passwd will be changed to root.

Notes for deployers and auditors¶

Implementation Status: Implemented

The group ownership for /etc/passwd will be set to root.

Notes for deployers and auditors¶

Implementation Status: Implemented

The permissions for /etc/passwd will be set to 0644.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible task will ensure that the /etc/group file is owned by the root user.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will ensure that /etc/group is owned by the root user.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will ensure that the mode of /etc/group//` is set to ``0644.

Notes for deployers and auditors¶

Implementation Status: Configuration Required

The STIG recommends passwords to be a minimum of 14 characters in length. To apply this setting, set the following Ansible variable:

security_password_minimum_length: 14

Deployers are urged to avoid the use of passwords and rely upon SSH keys if possible.

Notes for deployers and auditors¶

Implementation Status: Configuration Required

The STIG recommends setting a limit of one password change per day. To enable this configuration, use this Ansible variable:

security_password_minimum_days: 14

Notes for deployers and auditors¶

Implementation Status: Configuration Required

The STIG recommends setting a limit of 60 days before a password must be changed. To enable this configuration, use this Ansible variable:

security_password_maximum_days: 60

Notes for deployers and auditors¶

Implementation Status: Configuration Required

After enabling password age limits in V-38479, be sure to configure warnings for users so they know when their password is approaching expiration. STIG’s recommendation is seven days prior to the expiration. Use an Ansible variable to configure the warning:

security_password_warn_age: 7

Notes for deployers and auditors¶

Implementation Status: Exception

Password complexity requirements are left up to the deployer. Deployers are urged to rely on SSH keys as often as possible to avoid problems with passwords.

Review the pam_cracklib documentation by running man pam_cracklib or read the detailed documentation from Hal Pomeranz.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible task will check for the presence of /etc/hosts.equiv and /root/.rhosts. Both of those files could potentially be used with rsh for host access.

The rshd daemon is not installed by default with Ubuntu 14.04, Ubuntu 16.04, CentOS 7, or OpenStack-Ansible.

Notes for deployers and auditors¶

Implementation Status: Exception

Virtual consoles are helpful during an emergency and they can only be reached by physical or other out-of-band access (such as DRAC, iLO, or iKVM). This change can be confusing for system administrators and it is left up to the deployer to complete.

As an alternative, deployers could take action to restrict physical access to server terminals. Out-of-band access mechanisms should be segmented onto their own restricted network and should use centralized authentication.

Notes for deployers and auditors¶

Implementation Status: Exception

Removing serial consoles from /etc/securetty can make troubleshooting a server extremely difficult. Deployers are urged to use strong physical security practices to prevent unauthorized users from gaining physical access to critical hosts. In addition, out-of-band systems that allow for serial over LAN access should also be heavily secured.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

The Ansible tasks will check for default system accounts (other than root) that are not locked. The tasks won’t take any action, however, because any action could cause authorized users to be unable to access the system. However, if any unlocked default system accounts are found, the playbook will fail with an error message until the user accounts are locked.

Deployers who intentionally want to skip this step should use --skip-tags V-38496 to avoid a playbook failure on this check.

Deployers are urged to audit the accounts on their systems and lock any users that don’t need to log in via consoles or via ssh.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 allow accounts with null passwords to authenticate via PAM by default. This STIG requires that those login attempts are blocked.

For Ubuntu, the nullok_secure option will be removed from /etc/pam.d /common-auth.

For CentOS, the nullok option will be removed from /etc/pam.d/system- auth.

The effects of the change are immediate and no service restarts are required.

Deployers can opt-out of this change by adjusting an Ansible variable:

security_pam_remove_nullok: no

Setting the variable to yes (the default) will cause the Ansible tasks to remove the nullok_secure parameter while setting the variable to no will leave the PAM configuration unchanged.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible task will search for password hashes in /etc/passwd using awk and report a failure if any are found.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will search for accounts in /etc/passwd that have UID 0 that aren’t the normal root account. If any matching accounts are found, a warning is printed to stdout and the Ansible play will fail.

No action is taken on those accounts as that action may disrupt a production environment. Deployers are strongly urged to use sudo for these types of actions.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Adjusting PAM configurations is very risky since it affects how all users authenticate. In addition, pam_faillock.so isn’t available in Ubuntu.

Another option is to utilize pam_tally to deny logins after failed attempts. Adjusting PAM configurations automatically can disrupt the operation of production systems, so this is left up to the deployer to configure. For more details on how to configure pam_tally, refer to this AskUbuntu article about pam_tally.

Another alternative is fail2ban. Read the notes below for more tails on this option.

The Ansible tasks will install fail2ban and configure it to ban IP addresses using the following logic

• The IP has attempted three logins in the last 10 minutes and all have failed
• That IP will be banned for 15 minutes (via iptables rules)

Deployers must opt-in for fail2ban to be installed and configured. To opt-in, set the security_install_fail2ban Ansible variable to yes. The time period for bans can also be configured (in seconds) via tha security_fail2ban_bantime variable:

security_install_fail2ban: yes
security_fail2ban_bantime: 900

NOTE: Fail2ban can only review authentication attempts for services that listen on the network, such as ssh. It has no control over physical consoles. Deployers are strongly urged to use stong physical security policies to prevent unauthorized users from accessing server consoles. In addition, deployers must secure out-of-band access methods, like IPMI, as they can be vectors for physical console access as well.

Notes for deployers and auditors¶

Implementation Status: Implemented

The user and group ownership of /etc/passwd is root by default. The Ansible task will ensure that the default is maintained.

Notes for deployers and auditors¶

Implementation Status: Implemented

The user and group ownership of /etc/passwd is root by default. The Ansible task will ensure that the default is maintained.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04 and Ubuntu 16.04 set the mode of /etc/shadow to 0640, but CentOS 7 sets it to 000. The STIG requires the mode to be 000 and the Ansible tasks in the security role ensure that the mode meets the requirement.

Special note for Ubuntu: This change doesn’t affect how the system operates since root is the only user that should be able to read from and write to /etc/shadow. Allowing users to read the file could open up the system to attacks since the password hashes can be dumped and brute forced.

Notes for deployers and auditors¶

Implementation Status: Exception

Password complexity requirements are left up to the deployer. Deployers are urged to rely on SSH keys as often as possible to avoid problems with passwords.

Review the pam_cracklib documentation by running man pam_cracklib or read the detailed documentation from Hal Pomeranz.

Notes for deployers and auditors¶

Implementation Status: Exception

Password complexity requirements are left up to the deployer. Deployers are urged to rely on SSH keys as often as possible to avoid problems with passwords.

Review the pam_cracklib documentation by running man pam_cracklib or read the detailed documentation from Hal Pomeranz.

Notes for deployers and auditors¶

Implementation Status: Exception

Password complexity requirements are left up to the deployer. Deployers are urged to rely on SSH keys as often as possible to avoid problems with passwords.

Review the pam_cracklib documentation by running man pam_cracklib or read the detailed documentation from Hal Pomeranz.

Notes for deployers and auditors¶

Implementation Status: Exception

Password complexity requirements are left up to the deployer. Deployers are urged to rely on SSH keys as often as possible to avoid problems with passwords.

Review the pam_cracklib documentation by running man pam_cracklib or read the detailed documentation from Hal Pomeranz.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Adjusting PAM configurations is very risky since it affects how all users authenticate. In addition, pam_faillock.so isn’t available in Ubuntu.

Another option is to utilize pam_tally to deny logins after failed attempts. Adjusting PAM configurations automatically can disrupt the operation of production systems, so this is left up to the deployer to configure. For more details on how to configure pam_tally, refer to this AskUbuntu article about pam_tally.

Another alternative is fail2ban. Read the notes below for more tails on this option.

The Ansible tasks will install fail2ban and configure it to ban IP addresses using the following logic

• The IP has attempted three logins in the last 10 minutes and all have failed
• That IP will be banned for 15 minutes (via iptables rules)

Deployers must opt-in for fail2ban to be installed and configured. To opt-in, set the security_install_fail2ban Ansible variable to yes. The time period for bans can also be configured (in seconds) via tha security_fail2ban_bantime variable:

security_install_fail2ban: yes
security_fail2ban_bantime: 900

NOTE: Fail2ban can only review authentication attempts for services that listen on the network, such as ssh. It has no control over physical consoles. Deployers are strongly urged to use stong physical security policies to prevent unauthorized users from accessing server consoles. In addition, deployers must secure out-of-band access methods, like IPMI, as they can be vectors for physical console access as well.

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG requires SHA512 to be used for hashing password since it is in the list of FIPS 140-2 approved hashing algorithms. This is also the default in Ubuntu 14.04, Ubuntu 16.04, and CentOS 7.

The Ansible tasks will verify that the secure default is still set in the system’s PAM configuration. If it has been altered, the playbook will fail and display an error.

Further reading:

• FIPS 140-2 on Wikipedia
• FIPS 140-2 from NIST

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG requires SHA512 to be used for hashing password since it is in the list of FIPS 140-2 approved hashing algorithms. This is also the default in Ubuntu 14.04, Ubuntu 16.04, and CentOS 7.

The Ansible tasks will verify that the secure default is still set in /etc/login.defs. If it has been altered, the playbook will fail and display an error.

Further reading:

• FIPS 140-2 on Wikipedia
• FIPS 140-2 from NIST

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG requires SHA512 to be used for hashing password since it is in the list of FIPS 140-2 approved hashing algorithms. This is also the default in Ubuntu 14.04, Ubuntu 16.04, and CentOS 7.

The libuser package isn’t installed by default in Ubuntu or via openstack-ansible. The Ansible tasks will do the following:

• Check to see if libuser is installed
• If it’s installed, it will check for the password hashing algorithm in /etc/libuser.conf
• If libuser is installed and the password hashing algorithm isn’t SHA512, an error will be printed and the playbook will fail

Further reading:

• FIPS 140-2 on Wikipedia
• FIPS 140-2 from NIST

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Adjusting PAM configurations on a running system carries a fair amount of risk, and deployers are urged to rely upon ssh keys or centralized authentication for user authentication.

Centralized authentication systems provide a benefit of locking a user’s account in all systems they have access to, rather than locking access to only one system.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Use of additional factors for authentication is left up to the deployer, but it is strongly recommended.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Deployers that use LDAP authentication for systems are strongly urged to use TLS connectivity between client hosts and LDAP servers to prevent eavesdroppers on the network from reading the authentication attempts as they are made. The certificates on the LDAP server must be trusted by each client.

The tasks in the security role do not adjust the LDAP configuration since this could disrupt future authentication attempts.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Deployers that use LDAP authentication for systems are strongly urged to use TLS connectivity between client hosts and LDAP servers to prevent eavesdroppers on the network from reading the authentication attempts as they are made. The certificates on the LDAP server must be trusted by each client.

The tasks in the security role do not adjust the LDAP configuration since this could disrupt future authentication attempts.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Making adjustments to PAM configurations via automated methods is risky since it can disrupt user authentication on various hosts. Deployers are strongly urged to rely on ssh keys as opposed to enforcing password complexity and rotation requirements.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will run pwck to find any groups that are defined in /etc/passwd but not in /etc/group. This could be a sign of an accidental misconfiguration or a more serious security problem. If the command returns output about missing groups, the playbook will fail.

To see the exact problems on the system when the playbook fails, run this command as root:

pwck -r | grep 'no group'

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible task will use the pwck command to search for non-unique usernames on the system. If any matching usernames are found, an error will be printed and the playbook will fail.

NOTE: The pwck command will find other abnormalities on the system, including users that exist in /etc/passwd but not in /etc/shadow, and vice versa. If the playbook fails on this task, try to run this command on the system as root to find out what caused the failure:

pwck -rq

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

It’s not possible to determine which accounts may be temporary or permanent via automated methods, so this configuration change is left to deployers to configure and manage. Refer to the documentation in the STIG Viewer (link above) about configuring temporary accounts with an expiration date.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Deployers must opt-in for this change by setting the following Ansible variable:

security_inactive_account_lock_days: 35

The STIG requires this to be set to 35 days at a maximum. The Ansible tasks will not make any changes to /etc/default/useradd unless security_inactive_account_lock_days is set.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Password complexity requirements are left up to the deployer. Deployers are urged to rely on SSH keys as often as possible to avoid problems with passwords.

Review the pam_cracklib documentation by running man pam_cracklib or read the detailed documentation from Hal Pomeranz.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Deployers must opt-in for this change by setting the following Ansible variable:

security_inactive_account_lock_days: 35

The STIG requires this to be set to 35 days at a maximum. The Ansible tasks will not make any changes to /etc/default/useradd unless security_inactive_account_lock_days is set.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 already enable the display of the last successful login for a user immediately after login. An Ansible task ensures this setting is applied and restarts the ssh daemon if necessary.

Notes for deployers and auditors¶

Implementation Status: Implemented

This STIG requires that NOPASSWD and !authenticate are not used within the sudoers configuration files. Using these directives reduces the security of the system.

NOPASSWD allows users to run commands as root without providing a password first. Using !authenticate with the Defaults directive will disable password usage for any users which use sudo.

There are two configuration options for handling these changes. By default, both of these options are set to no, which means that the sudoers configuration files will not be altered:

security_sudoers_remove_nopasswd: no
security_sudoers_remove_authenticate: no

Setting security_sudoers_remove_nopasswd to yes will cause the Ansible tasks to search for any lines containing NOPASSWD and comment them out of the configuration. Setting security_sudoers_remove_authenticate will do the same actions on lines containing !authenticate. Lines that are already commented will be left unaltered.

Notes for deployers and auditors¶

Implementation Status: Implemented

To opt-out of the change, set the following variable:

security_enable_audit_during_boot: no

Deployers may opt-in for the change without automatically updating the active grub.cfg file by setting the following Ansible variables:

security_enable_audit_during_boot: yes
security_enable_grub_update: no

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Configuring another mount for /tmp can disrupt a running system and this configuration is skipped.

However, deployers are strongly urged to consider creating a separate partition and/or LVM logical volume for /tmp during installation of the OS if possible.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Configuring another mount for /var can disrupt a running system and this configuration is skipped.

However, deployers are strongly urged to consider creating a separate partition and/or LVM logical volume for /var during installation of the OS if possible.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04 sets the ownership on /boot/grub/grub.cfg to root by default. The Ansible task will ensure that the secure default is maintained.

In Ubuntu 16.04 and CentOS 7, the bootloader configuration files in /boot/grub2 are owned by the root user by default.

Deployers should monitor these files for changes in ownership, permissions and contents. The aide daemon is installed by the security role to monitor these files.

Notes for deployers and auditors¶

Implementation Status: Exception

For Ubuntu 14.04, the permissions on /boot/grub/grub.cfg will be set to 0644.

Ubuntu 16.04 and CentOS 7 use grub2. The configuration files in /boot/grub2 are regenerated when new kernels are installed or when the root user regenerates the configuration file. File ownership and permissions are set appropriately after each of these events.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Configuring a password for the bootloader is left up to the deployer to configure. Each deployer should consider the potential damage to their system should someone gain unauthorized physical access at the server itself or via an out-of-band management solution (like IPMI, DRAC, or iLO).

Notes for deployers and auditors¶

Implementation Status: Exception

As with V-38585, this is left to the deployer to configure based on their exposure to physical threats. If there is a concern around a user gaining unauthorized physical access and/or gaining access through an out-of-band access mechanism, deployers are strongly urged to consider applying this security configuration.

Notes for deployers and auditors¶

Implementation Status: Exception

As with V-38585, this configuration is left up to the deployer to determine their risk of attacks via physical access or out-of-band access to a server console.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Altering partitions and how they are mounted is left up to the deployer to configure during the OS installation process. Mounting /tmp/ with the noexec option is highly recommended to prevent scripts or binaries from being executed from /tmp.

Notes for deployers and auditors¶

Implementation Status: Exception

While providing text screen locking does add additional security, deployers are strongly urged to limit physical access and out-of-band access to servers where someone else might be able to join a user’s session when they step away. In addition, if a user is logging in remotely via ssh, they should lock their entire workstation to prevent unauthorized access to their system as well as the systems they are actively accessing.

Notes for deployers and auditors¶

Implementation Status: Implemented

A default warning banner will replace the contents of /etc/issue.net. To configure the banner, simply edit files/login_banner.txt.

Notes for deployers and auditors¶

Implementation Status: Implemented

In Ubuntu 14.04, the Ansible tasks disable the control-alt-delete keyboard sequence via a configuration in /etc/init/control-alt-delete.conf. A reboot is recommended to apply the change.

Linux distributions that use systemd, such as Ubuntu 16.04 and CentOS 7, disable the key sequence by masking the ctrl-alt-del.target with systemctl.

Notes for deployers and auditors¶

Implementation Status: Exception

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set library files to have 0755 (or more restrictive) permissions by default. Deployers are urged to review the permissions of libraries regularly to ensure the system has not been altered.

Notes for deployers and auditors¶

Implementation Status: Exception

As with V-38465, Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set the ownership of library files to root by default. Deployers are urged to configure monitoring for changes to these files.

Notes for deployers and auditors¶

Implementation Status: Exception

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set the permissions for system commands to 0755 or less already. Deployers are urged to review these permissions for changes over time as they can be a sign of a compromise.

Notes for deployers and auditors¶

Implementation Status: Exception

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 set system commands to be owned by root by default. Deployers are urged to review ownership changes via auditd rules to ensure system commands haven’t changed ownership over time.

Notes for deployers and auditors¶

Implementation Status: Exception

Different systems may have different log files populated depending on the type of data that rsyslogd receives. By default, log files are created with the user and group ownership set to root.

Deployers should review the files generated by the rsyslogd daemon to verify that they have the most restrictive ownership and permissions.

Notes for deployers and auditors¶

Implementation Status: Exception

Different systems may have different log files populated depending on the type of data that rsyslogd receives. By default, log files are created with the user and group ownership set to root.

Deployers should review the files generated by the rsyslogd daemon to verify that they have the most restrictive ownership and permissions.

Notes for deployers and auditors¶

Implementation Status: Exception

Keeping the list of setuid/setgid applications up to date and adding the paths to those files within the audit.rules file is challenging. Deployers are urged to use setuid/setgid sparingly and carefully monitor all applications with those permissions set.

Notes for deployers and auditors¶

Implementation Status: Implemented

The group ownership for /boot/grub/grub.cfg will be set to root.

Notes for deployers and auditors¶

Implementation Status: Implemented

The mode on rsyslog files is set to 0640 by default in Ubuntu 14.04 and Ubuntu 16.04 by default. CentOS 7 sets the mode to 0600 by default. The Ansible tasks will adjust the rsyslog configuration so that any new log files will have the mode set to 0600.

This will take effect the next time that log files are rotated with logrotate (configured in V-38624). Deployers can also make this change manually with chmod.

Notes for deployers and auditors¶

Implementation Status: Opt-In

The STIG requires that daemons have their umask set to 027 or 022. Since changing umasks can disrupt some systems, this is an opt-in change.

Deployers that want this change applied to their systems must set the Ansible variable security_umask_daemons_init to 027.

Notes for deployers and auditors¶

Implementation Status: Exception

Searching for world-writable files on a host deployed with openstack-ansible can be very time consuming and it can create unneccessary I/O load on hosts. Deployers are urged to check for world-writable files on a regular basis in directories where those files might be a concern (especially web accessible directories).

The command provided with the STIG is helpful for finding these types of files:

find ${MOUNT_POINT} -xdev -type f -perm -002

Running find / isn’t recommended on systems without LVM storage for containers since it will eventually search through the filesystems of the LXC containers that are deployed by openstack-ansible. The -xdev option prevents find from wandering into other mounted filesystems and will prevent it from searching through containers in logical volumes.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Changing umask settings can disrupt some systems and this change requires a deployer to opt-in. To opt-in for this change and adjust the umask, set the following Ansible variable:

security_umask_login_defs: 077

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04 doesn’t use umask settings in /etc/profile. Those settings are expected to be in /etc/login.defs instead.

For CentOS 7, umask settings are present in /etc/profile but they are overidden by settings in /etc/login.defs.

See V-38645 for more details.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Since umask changes can be disruptive on some systems, the deployer must opt-in for this change to happen. If the security_umask_csh Ansible variable is set and the csh package is installed, the Ansible tasks will ensure the appropriate umask is set in the csh configuration file.

If users have an active csh shell session, they will need to logout and create a new session to pick up the new umask change.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Changing the umask for the bash shell is an opt-in setting. Deployers that want to set the umask for bash sessions to match the STIG requirement must set the Ansible variable security_umask_bash to 077.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

The STIG requires administrators to search for directories meeting all of the following criteria:

• World writable
• Owned by a normal user (UID > 499)

It requires that those directories are owned by root to prevent users from removing and replacing files. This find command isn’t run within the Ansible tasks in openstack-ansible-security because it can be a very time-consuming task and it can slow down disk I/O while it runs.

Deployers are strongly urged to review the permissions and ownerships of critical directories on their systems regularly to verify that they meet the requirements of this STIG.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Disabling the usb-storage module can add extra security, but it’s not necessary on most systems. To disable the usb-storage module on hosts, set the following variable to yes:

security_disable_module_usb_storage: yes

NOTE: The module will be disabled on the next reboot.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Datagram Congestion Control Protocol (DCCP) must be disabled if it’s not needed. Although this protocol is occasionally used in some OpenStack environments for quality of service functions, it is not in the default implementation.

To opt-out of this change, simply change the following variable to no:

security_disable_module_dccp: no

NOTE: The module will be disabled on the next reboot.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Stream Control Transmission Protocol (SCTP) must be disabled. To opt-out of this change, set the following variable to no:

security_disable_module_sctp: no

NOTE: The module will be disabled on the next reboot.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Reliable Datagram Sockets (RDS) protocol must be disabled. The Ansible tasks in this role will disable the module.

To opt-out of this change, set the following variable to no:

security_disable_module_rds: no

NOTE: The module will be disabled on the next reboot.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Transparent Inter-Process Communication (TIPC) protocol must be disabled. To opt-out of this change, set the following variable to no:

security_disable_module_tipc: no

NOTE: The module will be disabled on the next reboot.

Notes for deployers and auditors¶

Implementation Status: Exception

The STIG makes several requirements for IPv4 network restrictions, but these restrictions can impact certain network interfaces and cause service disruptions. Some security configurations make sense for certain types of network interfaces, like bridges, but other restrictions cause the network interface to stop passing valid traffic between hosts, containers, or virtual machines.

The default network scripts and LXC userspace tools already configure various network devices to their most secure setting. Since some hosts will act as routers, enabling security configurations that restrict network traffic can cause service disruptions for OpenStack environments.

Notes for deployers and auditors¶

Implementation Status: Opt-In

The STIG requires that ICMPv4 redirects are disabled on the host. However, this can cause problems with LXC-based deployments, such as environments deployed with OpenStack-Ansible.

Deployers can opt-in for this change by setting the following Ansible variable:

security_disable_icmpv4_redirects: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The STIG requires that secure ICMP redirects are disabled, but this can cause issues in some virtualized or containerized environments. The Ansible tasks in the security role will not disable these redirects by default.

Deployers who want to enable the task (and disable ICMP redirects), should set the following Ansible variable:

security_disable_icmpv4_redirects_secure: yes

Notes for deployers and auditors¶

Implementation Status: Opt-In

The STIG requires that all martian packets are logged by setting the sysctl parameter net.ipv4.conf.all.log_martians to 1.

Although the logs can be valuable in some situations, the setting can generate a significant amount of logging in OpenStack environments, especially those that use neutron’s Linux bridge networking. In some situations, the logging can flood the physical terminal and make troubleshooting at the console or via out of band (like iKVM, DRAC and iLO) extremely difficult.

The role will ensure that martian packet logging is disabled by default. Deployers that need this logging enabled will need to set the following Ansible variable:

security_sysctl_enable_martian_logging: yes

Wikpedia’s article on martian packets provides additional information.

Notes for deployers and auditors¶

Implementation Status: Exception

The STIG makes several requirements for IPv4 network restrictions, but these restrictions can impact certain network interfaces and cause service disruptions. Some security configurations make sense for certain types of network interfaces, like bridges, but other restrictions cause the network interface to stop passing valid traffic between hosts, containers, or virtual machines.

The default network scripts and LXC userspace tools already configure various network devices to their most secure setting. Since some hosts will act as routers, enabling security configurations that restrict network traffic can cause service disruptions for OpenStack environments.

Notes for deployers and auditors¶

Implementation Status: Exception

The STIG makes several requirements for IPv4 network restrictions, but these restrictions can impact certain network interfaces and cause service disruptions. Some security configurations make sense for certain types of network interfaces, like bridges, but other restrictions cause the network interface to stop passing valid traffic between hosts, containers, or virtual machines.

The default network scripts and LXC userspace tools already configure various network devices to their most secure setting. Since some hosts will act as routers, enabling security configurations that restrict network traffic can cause service disruptions for OpenStack environments.

Notes for deployers and auditors¶

Implementation Status: Exception

The STIG makes several requirements for IPv4 network restrictions, but these restrictions can impact certain network interfaces and cause service disruptions. Some security configurations make sense for certain types of network interfaces, like bridges, but other restrictions cause the network interface to stop passing valid traffic between hosts, containers, or virtual machines.

The default network scripts and LXC userspace tools already configure various network devices to their most secure setting. Since some hosts will act as routers, enabling security configurations that restrict network traffic can cause service disruptions for OpenStack environments.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will ensure that net.ipv4.icmp_echo_ignore_broadcasts is set to 1, which will cause the system to stop responding to ICMPv4 packets sent to the broadcast address.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will ensure that net.ipv4.icmp_ignore_bogus_error_responses is set to 1. This prevents a host from responding to bogus ICMPv4 error messages.

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG recommends enabling TCP SYN cookies to deal with TCP SYN floods.

Note that high-traffic environments may require TCP SYN cookies to be disabled. Certain load balancers may forward requests in such a way that web servers may think they’re being SYN flooded during peak traffic events. Putting well- configured hardware network devices in front of OpenStack environments is always recommended and this may allow some deployers to turn off SYN cookies within their environment.

Deployers can disable TCP SYN cookies by setting an Ansible variable:

security_sysctl_enable_tcp_syncookies: no

Most operating systems, such as Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 have TCP syncookies enabled by default upon installation. For more information on TCP SYN cookies and TCP SYN floods, refer to these links:

• Wikipedia: SYN flood
• Wikipedia: SYN cookies

Notes for deployers and auditors¶

Implementation Status: Exception

The STIG makes several requirements for IPv4 network restrictions, but these restrictions can impact certain network interfaces and cause service disruptions. Some security configurations make sense for certain types of network interfaces, like bridges, but other restrictions cause the network interface to stop passing valid traffic between hosts, containers, or virtual machines.

The default network scripts and LXC userspace tools already configure various network devices to their most secure setting. Since some hosts will act as routers, enabling security configurations that restrict network traffic can cause service disruptions for OpenStack environments.

Notes for deployers and auditors¶

Implementation Status: Exception

The STIG makes several requirements for IPv4 network restrictions, but these restrictions can impact certain network interfaces and cause service disruptions. Some security configurations make sense for certain types of network interfaces, like bridges, but other restrictions cause the network interface to stop passing valid traffic between hosts, containers, or virtual machines.

The default network scripts and LXC userspace tools already configure various network devices to their most secure setting. Since some hosts will act as routers, enabling security configurations that restrict network traffic can cause service disruptions for OpenStack environments.

Notes for deployers and auditors¶

Implementation Status: Opt-In

The STIG requires IPv6 to be disabled system-wide unless it is needed for the system to operate. Deployers must consider how their network is configured before disabling IPv6 entirely.

To opt-in for this change, set the following Ansible variable to yes:

security_disable_ipv6: yes

NOTE: This change will go into effect immediately on the system and persist through reboots.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required.

It is configurable by security_disable_icmpv6_redirects variable. This feature is disabled by default. Disabling IPv6 redirects can cause issues with OpenStack environments which have IPv6 enabled and are routing IPv6 traffic.

Deployers can opt-in to this change and disable ICMPv6 redirects by setting the following Ansible variable:

security_disable_icmpv6_redirects: yes

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will set kernel.randomize_va_space to 2 immediately and will also ensure that the setting is applied on the next boot. This setting is currently the default in Ubuntu 14.04, Ubuntu 16.04, and CentOS 7.

Notes for deployers and auditors¶

Implementation Status: Implemented

Non-Executable Memory (NX) is the successor to ExecShield, and it is enabled by default on Ubuntu 14.04, Ubuntu 16.04, and CentOS 7.

For more information, refer to Ubuntu’s security feature documentation on NX.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will disable the sending of ICMPv4 redirects by setting the sysctl variable net.ipv4.conf.default.send_redirects to 0. However, bridging still requires redirects to be enabled, so those interfaces won’t be affected by this change.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will set net.ipv4.conf.all.send_redirects to 0 so that hosts will stop sending ICMPv4 redirects on all interfaces.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible task will disable the bluetooth kernel modules to meet the STIG requirements. To opt-out of this change, adjust the following Ansible variable to no:

disable_bluetooth_module: no

NOTE: The module will be disabled on the next system reboot.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

At the moment, openstack-ansible already sends logs to the rsyslog container from various containers and hosts. However, deployers are strongly urged to forward these logs to a system outside their openstack-ansible environment to ensure that they cannot be altered.

Some compliance programs require centralized logging, including PCI-DSS.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

At the moment, openstack-ansible already sends logs to the rsyslog container from various containers and hosts. However, deployers are strongly urged to forward these logs to a system outside their openstack-ansible environment to ensure that they cannot be altered.

Some compliance programs require centralized logging, including PCI-DSS.

Notes for deployers and auditors¶

Implementation Status: Implemented

The openstack-ansible project already installs and configures AppArmor, which is a Linux Security Module providing similar functionality to SELinux. In addition, AIDE is installed to monitor system files in the Ansible tasks for V-38429.

Notes for deployers and auditors¶

Implementation Status: Implemented

The tasks in the security role will enable the Linux Security Module (LSM) that is appropriate for the Linux distribution in use.

For Ubuntu, the default LSM is AppArmor. Refer to Ubuntu’s AppArmor documentation for more details on how AppArmor works. The tasks will enable AppArmor and start it immediately on the system.

For CentOS, the default LSM is SELinux. Refer to Red Hat’s Security-Enhanced Linux documentation for more details on SELinux. The tasks will enable SELinux on the next boot.

Deployers can opt-out of this change by setting the following Ansible variable:

security_enable_linux_security_module: False

Setting the variable to False will prevent the tasks from making any adjustments to the LSM status.

On CentOS 7, the security role will verify that SELinux is in Enforcing mode. If SELinux is in Disabled or Permissive mode, the playbook will fail with an error message.

Notes for deployers and auditors¶

Implementation Status: Implemented

For Ubuntu, the standard AppArmor policies provided by the AppArmor package are loaded. The OpenStack-Ansible project also configures AppArmor to limit the actions of containers and reduce the changes (and potential damages) of a container breakout.

On CentOS 7, the selinux-policy-targeted package provides SELinux policies that enforce limits on system services and users.

Notes for deployers and auditors¶

Implementation Status: Exception - Ubuntu

The security role will search for unlabeled devices on CentOS and the playbook will fail with an error message if any unlabeled devices are found.

Although SELinux works through a labeling system where every file (including devices) receives a label, AppArmor on Ubuntu works purely through policies without labels. However, OpenStack-Ansible does configure several AppArmor policies to reduce the chances and impact of LXC container breakouts on OpenStack hosts.

Notes for deployers and auditors¶

Implementation Status: Configuration Required

Forwarding root’s email to another user is highly recommended so that someone can receive emails about errors or security events.

Deployers should set security_root_forward_email to a valid email address of a user or mailing list that should receive critical automated emails from the server.

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG requires that postfix only listens on the localhost so that it isn’t abused as a mail relay. The Ansible task will adjust the inet_interfaces line in the Postfix configuration and restart postfix if the line is changed.

Although it’s not common, some deployers may need to configure hosts so they can receive email over the network. In that case, deployers would need to set the following Ansible variable:

security_postfix_inet_interfaces: all

Note that postfix can have inet_interfaces set to localhost and it can still send email on the network. The inet_interfaces directive only controls where postfix listens for incoming email.

For more information, review the postfix documentation for inet_interfaces.

Notes for deployers and auditors¶

Implementation Status: Implemented

The postfix package will be installed and configured to run at boot time. Review the documentation for V-38446 to ensure that root’s email is forwarded to an email account that can monitor for critical alerts and other notifications.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will ensure that mail for the auditd user is forwarded to the root user for review.

Deployers are strongly urged to review V-38446 to ensure they have set the security_root_forward_email variable so that the email system can route these critical notifications to a monitored mailbox.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Configuring a separate partition for /var/log is currently left up to the deployer. There are security and operational benefits that come from the change, but it must be done when the system is initially installed.

Deployers are urged to consider making a separate partition for /var/log during OS installation.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Creating /home on a different partition is highly recommended but it is left to deployers to configure during the installation of the OS.

Notes for deployers and auditors¶

Implementation Status: Exception

System backups are left to the deployer to configure. Deployers are stringly urged to maintain backups of each system, including log files and critical configuration information.

Notes for deployers and auditors¶

Implementation Status: Exception

System backups are left to the deployer to configure. Deployers are stringly urged to maintain backups of each system, including log files and critical configuration information.

Notes for deployers and auditors¶

Implementation Status: Implemented

Running virtual infrastructure requires IP forwarding to be enabled on various interfaces. The STIG allows for this, so long as the system is being operated as a router (as is the case for an OpenStack host).

Notes for deployers and auditors¶

Implementation Status: Implemented

Rules are added for auditing changes to system time made via settimeofday.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will check for .netrc files in /root and /home on the system and print a failure warning if any are found.

Notes for deployers and auditors¶

Implementation Status: Implemented

The chrony service is installed to manage clock synchronization for hosts and to serve as an NTP server for NTP clients. Chrony was chosen over ntpd because it’s actively maintained and has some enhancements for virtualized environments.

Deployers can opt out of the chrony installation by setting the following Ansible variable:

security_enable_chrony: no

There are two configurations available for users to adjust chrony’s default configuration:

The security_ntp_servers variable is a list of NTP servers that chrony should use to synchronize time. They are set to North American NTP servers by default.

The security_allowed_ntp_subnets variable is a list of subnets (in CIDR notation) that are allowed to reach your servers running chrony. A sane default is chosen (all RFC1918 networks are allowed), but this can be easily adjusted.

For more information on chrony, review the chrony documentation at the upstream site, or run man chrony on a host with chrony installed.

Notes for deployers and auditors¶

Implementation Status: Implemented

Fixed by another STIG

The Ansible tasks for V-38620 will configure the chrony daemon and allow deployers to specify their NTP servers. Deployers that are subject to US DoD requirements will need to use DoD-approved time servers. Refer to the STIG in the STIG viewer using the link above this “Developer Notes” section.

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG requires that system logs are rotated daily, but the check only involves verifying that logrotate is installed and activated by cron. The openstack-ansible project already configures weekly log rotation with compression. For high-traffic logging environments, changing the frequency to weekly in /etc/logrotate.conf may help.

Notes for deployers and auditors¶

Implementation Status: Implemented

Time synchronization is added within the fixes for V-38620 (where chrony is installed and configured). The ntpdate service is not used.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Deployers are urged to use the nodev option on any remotely mounted filesystems whenever possible.

The security role does not take action on filesystem mounts since this could affect the stability or availability of the host.

Notes for deployers and auditors¶

Implementation Status: Exception

The OpenStack-Ansible project doesn’t install snmpd by default. Deployers are strongly recommended to use SNMPv3 with strong passwords for all connectivity if they choose to install snmpd.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Deployers are urged to use the nosuid option on any remotely mounted filesystems whenever possible.

The security role does not take action on filesystem mounts since this could affect the stability or availability of the host.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Deployers are strongly urged to mount any additional disks with the noexec mount option set whenever possible.

For more information about the noexec mount option, review this good answer from a ServerFault user about noexec.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Creating encrypted storage is left up to the deployer to consider and implement. Although encrypting data at rest on storage volumes does reduce the chances of data theft if the server is physically compromised, it doesn’t provide protection from a user who is logged in while the server is running.

Linux systems provide various options for storage encryption. The Linux Unified Key Setup is a good implementation to review.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will check to see if the SNMP configuration file is present. If the file is present, and the file contains configurations for insecure SNMP protocols, an error will be printed and the playbook will fail.

The task specifically looks for uncommented configuration lines containing:

• v1
• v2c
• com2sec
• community

Red Hat’s guide to SNMP has some example configurations that deployers can use to enable SNMPv3.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Creating encrypted storage is left up to the deployer to consider and implement. Although encrypting data at rest on storage volumes does reduce the chances of data theft if the server is physically compromised, it doesn’t provide protection from a user who is logged in while the server is running.

Linux systems provide various options for storage encryption. The Linux Unified Key Setup is a good implementation to review.

Notes for deployers and auditors¶

Implementation Status: Exception - Initial Provisioning

Creating encrypted storage is left up to the deployer to consider and implement. Although encrypting data at rest on storage volumes does reduce the chances of data theft if the server is physically compromised, it doesn’t provide protection from a user who is logged in while the server is running.

Linux systems provide various options for storage encryption. The Linux Unified Key Setup is a good implementation to review.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

The installation of an antivirus program is left up to the deployer. There are strong arguments against virus scanners due to detection failures and performance impacts.

The following links provide more information about installing antivirus software on Ubuntu and CentOS:

• Ubuntu documentation - Antivirus
• CentOS Blog - How to Install ClamAV and Configure Daily Scanning on CentOS

Notes for deployers and auditors¶

Implementation Status: Implemented

The security role will add a file in /etc/security/limits.d/ that disables core dumps for all users. Although this setting is more secure, it can prevent users from debugging kernel errors.

To opt-out of this change, set the following Ansible variable to no:

security_disable_core_dumps: no

Notes for deployers and auditors¶

Implementation Status: Opt-In

Ubuntu does not set a limit on the maximum number of active sessions that a single user can have at one time. The STIG requires setting a limit of 10.

To opt-in for this change, set the following Ansible variable:

security_max_simultaneous_logins: 10

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

It’s not possible to determine which accounts may be temporary or permanent via automated methods, so this configuration change is left to deployers to configure and manage. Refer to the documentation in the STIG Viewer (link above) about configuring temporary accounts with an expiration date.

Notes for deployers and auditors¶

Implementation Status: Exception

Running a find command on the system during the playbook run is time-consuming and will also slow down disk I/O while it runs. Deployers are urged to review public directories to ensure the sticky bit is configured.

Further reading: sticky bit on Wikipedia

Notes for deployers and auditors¶

Implementation Status: Implemented

The security role will ensure that the appropriate log configuration lines are applied to /etc/vsftpd.conf to meet the STIG requirements. If the vsftpd package isn’t installed, the Ansible tasks won’t make any changes to the system.

Notes for deployers and auditors¶

Implementation Status: Implemented

For Ubuntu, the standard AppArmor policies provided by the AppArmor package are loaded. The OpenStack-Ansible project also configures AppArmor to limit the actions of containers and reduce the changes (and potential damages) of a container breakout.

On CentOS 7, the selinux-policy-targeted package provides SELinux policies that enforce limits on system services and users. SELinux is configured to use the targeted policy by default.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

See V-38551 for additional details. IPv6 configuration and filtering is left up to the deployer.

Notes for deployers and auditors¶

Implementation Status: Exception

Although a minimal set of iptables rules are configured on openstack-ansible hosts, the “deny all” requirement of the STIG is not met. This is largely left up to the deployer to do, based on their assessment of their own network segmentation.

Deployers are urged to review the network access controls that are applied on the network devices between their OpenStack environment and the rest of their network.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Although a minimal set of iptables rules are configured on openstack-ansible hosts, the “deny all” requirement of the STIG is not met. This is largely left up to the deployer to do, based on their assessment of their own network segmentation.

Deployers are urged to review the network access controls that are applied on the network devices between their OpenStack environment and the rest of their network.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Adding IPv6 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Filtering IPv6 traffic is left up to the deployer to implement. The openstack-ansible roles don’t configure IPv6 (at this time) and adding persistent ip6tables rules could harm a running system.

However, deployers are strongly recommended to implement IPv6 filtering at the edges of the network via network devices. In addition, deployers should be aware that link-local IPv6 addresses are configured automatcally by the system and those addresses could open up new network paths for future attacks.

For example, if IPv4 access was tightly controlled and segmented, hosts and/or containers could possibly communicate across these boundaries using IPv6 link-local addresses. For more detailed information on this security topic, review Cisco’s documentation titled IPv6 Security Brief that is available on their website.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Adding IPv6 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Adding IPv4 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Adding IPv4 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Although a minimal set of iptables rules are configured on OpenStack-Ansible hosts, the “deny all” requirement of the STIG is not met. This is largely left up to the deployer to do, based on their assessment of their own network segmentation.

Deployers are urged to review the network access controls that are applied on the network devices between their OpenStack environment and the rest of their network.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

The configuration of encrypted tunnels between deployers and their OpenStack environment is left up to the deployers to configure.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will check for all_squash in /etc/exports (if it is present). If found, a warning message will be printed. No configuration changes will be made since neither Ubuntu or openstack-ansible configures the NFS server by default.

Notes for deployers and auditors¶

Implementation Status: Implemented

If the system has NFS exports configured, the Ansible tasks will search for insecure_locks in the options column for any of the available exports. If the option is found, the playbook will fail with an error.

Notes for deployers and auditors¶

Implementation Status: Exception

Although Ubuntu provides the debsums command for checking the contents of files installed from packages, it cannot perform a detailed level of checking sufficient to meet the STIG requirement. Some packages are not shipped with MD5 checksums for all files. Deployers are encouraged to use debsums -c regularly to check for alterations in as many packages as possible.

Ubuntu does not currently have a capability to check file permissions, ownership, or group ownership against the permissions that were originally set when the package was installed.

In CentOS, the rpm command can verify package contents, ownership, group ownership, and permissions after the package has been installed. However, many configuration files are changed by the security role and this will cause the verification to fail.

Deployers should utilize the monitoring capabilities of the aide package (which is installed by other Ansible tasks in this role) to determine which configuration files, libraries or binaries may have been changed.

Notes for deployers and auditors¶

Implementation Status: Exception

Although Ubuntu provides the debsums command for checking the contents of files installed from packages, it cannot perform a detailed level of checking sufficient to meet the STIG requirement. Some packages are not shipped with MD5 checksums for all files. Deployers are encouraged to use debsums -c regularly to check for alterations in as many packages as possible.

Ubuntu does not currently have a capability to check file permissions, ownership, or group ownership against the permissions that were originally set when the package was installed.

In CentOS, the rpm command can verify package contents, ownership, group ownership, and permissions after the package has been installed. However, many configuration files are changed by the security role and this will cause the verification to fail.

Deployers should utilize the monitoring capabilities of the aide package (which is installed by other Ansible tasks in this role) to determine which configuration files, libraries or binaries may have been changed.

Notes for deployers and auditors¶

Implementation Status: Exception - Ubuntu

Verifying ownership and permissions of installed packages isn’t possible in the current version of dpkg as it is with rpm. This security configuration is skipped for Ubuntu.

For CentOS, this check is done as part of V-38637.

Notes for deployers and auditors¶

Implementation Status: Exception

Although Ubuntu provides the debsums command for checking the contents of files installed from packages, it cannot perform a detailed level of checking sufficient to meet the STIG requirement. Some packages are not shipped with MD5 checksums for all files. Deployers are encouraged to use debsums -c regularly to check for alterations in as many packages as possible.

Ubuntu does not currently have a capability to check file permissions, ownership, or group ownership against the permissions that were originally set when the package was installed.

In CentOS, the rpm command can verify package contents, ownership, group ownership, and permissions after the package has been installed. However, many configuration files are changed by the security role and this will cause the verification to fail.

Deployers should utilize the monitoring capabilities of the aide package (which is installed by other Ansible tasks in this role) to determine which configuration files, libraries or binaries may have been changed.

Notes for deployers and auditors¶

Implementation Status: Implemented

The security role verifies that the GPG keys that correspond to each supported Linux distribution are installed on each host. If the GPG keys are not found, or if they differ from the list of trusted GPG keys, the playbook execution will stop.

Deployers can skip this task (and avoid this failure) by using --skip-tags V-38476 when they are applying the security role.

Notes for deployers and auditors¶

Implementation Status: Exception

Ubuntu and CentOS do not use the Red Hat Network Service. However, there are tasks in the security role which ensure that all packages have GPG checks enabled (see V-38462) and provide the option for deployers to apply updates automatically.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Operating system patching policies vary from organization to organization and are typically established based on business requirements and risk tolerance.

Deployers can enable automatic updates by setting security_unattended_upgrades to True:

security_unattended_upgrades: true

In Ubuntu, the unattended-upgrades package is installed and enabled. This will apply updates that are made available to the trusty-security (Ubuntu 14.04) or xenial-security (Ubuntu 16.04) repositories.

In CentOS, the yum-cron package is installed and configured to automatically apply updates.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible task for V-38462 already checks for configurations that would disable any GPG checks when installing packages. However, it is possible for the root user to override these configurations via command line parameters.

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 already enable the display of the last successful login for a user immediately after login. An Ansible task ensures this setting is applied and restarts the ssh daemon if necessary.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible task for V-38462 already checks for apt configurations that would disable any GPG checks when installing packages. However, it’s possible for the root user to override these configurations via command line parameters.

Notes for deployers and auditors¶

Implementation Status: Exception - Ubuntu

Verifying ownership and permissions of installed packages isn’t possible in the current version of dpkg as it is with rpm. This security configuration is skipped for Ubuntu.

For CentOS, this check is done as part of V-38637.

Notes for deployers and auditors¶

Implementation Status: Exception - Ubuntu

Verifying ownership and permissions of installed packages isn’t possible in the current version of dpkg as it is with rpm. This security configuration is skipped for Ubuntu. For CentOS, this check is done as part of V-38637.

Notes for deployers and auditors¶

Implementation Status: Exception - Ubuntu

Verifying ownership and permissions of installed packages isn’t possible in the current version of dpkg as it is with rpm. This security configuration is skipped for Ubuntu. For CentOS, this check is done as part of V-38637.

Notes for deployers and auditors¶

Implementation Status: Implemented

If autofs is installed, it will be disabled by Ansible tasks. To opt-out of this change, adjust the following variable:

security_disable_autofs: no

Notes for deployers and auditors¶

Implementation Status: Implemented

If the xinetd package is installed, it will be stopped immediately and will not start on the next boot. No action is taken if xinetd isn’t installed.

To opt-out of this change, simply adjust the following configuration item to no:

security_disable_xinetd: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The xinetd service will be removed by the Ansible tasks, if it is installed. To opt-out of this change, adjust the following variable to no:

security_remove_xinetd: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The telnetd service will be removed by the Ansible tasks, if it is installed. To opt-out of this change, adjust the following variable to no:

security_remove_telnet_server: no

Notes for deployers and auditors¶

Implementation Status: Implemented

Running a telnet daemon isn’t recommended under most situations, so the telnet server package will be removed from the system if it is installed. The telnet server is removed by the Ansible tasks for V-38587, so no action is required here.

Notes for deployers and auditors¶

Implementation Status: Implemented

The rshd service will be removed by the Ansible tasks, if it is installed. To opt-out of this change, adjust the following variable to no:

security_remove_rsh_server: no

Notes for deployers and auditors¶

Implementation Status: Implemented

Running a rsh daemon isn’t recommended under most situations, so the rsh server package will be removed from the system if it is installed. The rsh server is removed by the Ansible tasks for V-38591, so no action is required here.

Notes for deployers and auditors¶

Implementation Status: Implemented

On Ubuntu, the rexecd daemon is part of the package that contains the rsh daemon. CentOS 7 doesn’t provide the rexecd daemon in any packages.

Running a rsh daemon isn’t recommended under most situations, so the rsh server package will be removed from the system if it is installed. The rsh server is removed by the Ansible tasks for V-38591, so no action is required here.

Notes for deployers and auditors¶

Implementation Status: Implemented

If the vsftpd package is installed, a login banner will be applied so that users will see if after logging in. This package isn’t installed by default in Ubuntu 14.04 and it isn’t installed by openstack-ansible either.

Notes for deployers and auditors¶

Implementation Status: Implemented

In Ubuntu, the rlogind daemon is part of the package that contains the rsh daemon. CentOS 7 does not provide the rlogind daemon in any packages.

Running a rsh daemon isn’t recommended under most situations, so the rsh server package will be removed from the system if it is installed. The rsh server is removed by the Ansible tasks for V-38591, so no action is required here.

Notes for deployers and auditors¶

Implementation Status: Implemented

This packages is named differently depending on the Linux distribution:

• Ubuntu 14.04: nis
• Ubuntu 16.04: nis
• CentOS 7: ypserv

The Ansible tasks will remove the appropriate package if it is installed. To opt-out of this change, adjust the following configuration variable to no:

security_remove_ypserv: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The ypbind service is removed entirely as part of V-38603.

Notes for deployers and auditors¶

Implementation Status: Implemented

The cron service is running by default in Ubuntu 14.04, Ubuntu 16.04, and CentOS 7. It is required for various OpenStack services to function properly. The Ansible tasks in this role will ensure that cron is running and is configured to start at boot time.

Notes for deployers and auditors¶

Implementation Status: Implemented

The package containing the tftp daemon has different names depending on the Linux distribution:

• Ubuntu 14.04: tftpd
• Ubuntu 16.04: tftpd
• CentOS 7: tftp-server

The Ansible tasks will select the appropriate package for the Linux distribution and remove the package. To opt-out, adjust the following configuration variable to no:

security_remove_tftp_server: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The package containing the tftpd service is removed by V-38606.

Notes for deployers and auditors¶

Implementation Status: Implemented

The avahi daemon will be disabled if the package is installed.

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG requires that any LDAP server packages on the system are removed. The Ansible role will remove slapd from the server if it is present.

To opt-out of this change, set the following Ansible variable to no:

security_remove_ldap_server: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks in the security role will disable the abrtd service and stop the service immediately. To opt-out of this change, set the following Ansible variable:

security_disable_abrtd: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks in the security role will disable the atd service and stop the service immediately. To opt-out of this change, set the following Ansible variable:

security_disable_atd: no

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Very few environments run the oddjobd service, and those that do run it are usually associated with highly-available, clustered systems. Deployers will need to disable this service manually if it is running on the system.

Notes for deployers and auditors¶

Implementation Status: Implemented

Although some OpenStack implementations use qpidd for their messaging hub, neither Ubuntu or openstack-ansible configures the service on the hosts by default. The Ansible task for this STIG will check to see if the init script exists for qpidd. If it does, the daemon will be stopped and disable on the next boot.

To opt-out of this change, adjust the following Ansible variable to no:

security_disable_qpidd: no

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu doesn’t provide packages containing the rdisc service at this time.

In CentOS, the rdisc service will be stopped and disabled if it is present on the system. To opt-out of this change, set the following Ansible variable:

security_disable_rdisc: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will check to see if the samba package is installed and the configuration file will be adjusted. If adjustments are made, the service will be restarted.

Notes for deployers and auditors¶

Implementation Status: Exception - Manual Intervention

Deployers are urged to require SMB client signing if they ever mount samba shares within their infrastructure.

Notes for deployers and auditors¶

Implementation Status: Implemented

The security role will remove the sendmail package if it exists on the system. To opt-out of this change, adjust the following Ansible variable to no:

security_remove_sendmail: no

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu doesn’t provide the netconsole package and the daemon isn’t included in any other Ubuntu packages.

In CentOS, the netconsole daemon will be stopped and disabled if it is found to be installed. Deployers can opt-out of this change by setting the following Ansible variable:

security_disable_netconsole: no

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will remove the xserver-xorg package if it is present.

To opt-out of the change, set the following Ansible variable to no:

security_remove_xorg: no

Notes for deployers and auditors¶

Implementation Status: Exception

The DHCP client is needed for containers to function properly and may be needed for some hosts as well. Deployers should examine their networking configuration to verify if DHCP clients can be disabled.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks will disable the bluetooth service and stop it if it is running on the system.

To opt-out of this change, adjust the following Ansible variable to no:

security_disable_bluetooth: no

Notes for deployers and auditors¶

Implementation Status: Exception

Neither OpenStack-Ansible or any of the operating systems supported by the security role will install the tftp daemon by default. Deployers with a tftp server deployed should review the risks associated with running the service and configure it to meet the STIG’s requirements.

Notes for deployers and auditors¶

Implementation Status: Implemented

The tasks in sshd.yml will ensure that SSH requires all connections to use protocol version 2.

Notes for deployers and auditors¶

Implementation Status: Implemented

The ClientAliveInterval in the ssh configuration will be set to 15 minutes as recommended by the STIG. However, this time is configurable by setting security_ssh_client_alive_interval to another value, in seconds.

To change to 10 minutes, adjust the configuration item to 600 seconds:

security_ssh_client_alive_interval: 600

Notes for deployers and auditors¶

Implementation Status: Implemented

The STIG recommends setting ClientAliveCountMax to ensure that ssh connections will close after reaching the ClientAliveInterval one time. To change this setting, simply change this configuration option to something other than 0:

security_ssh_client_alive_count_max: 0

Notes for deployers and auditors¶

Implementation Status: Implemented

Ubuntu 14.04, Ubuntu 16.04, and CentOS 7 configure the ssh daemon so that rsh’s .rhosts files are ignored by default. The Ansible tasks will ensure that this setting has not changed from the default.

Notes for deployers and auditors¶

Implementation Status: Implemented

The Ansible tasks in the security role ensure that the ssh daemon does not allow host based authentication.

Notes for deployers and auditors¶

Implementation Status: Opt-In

Although the STIG recommends disabling root logins via ssh, the default in this role is to allow it. The openstack-ansible deployment uses the root user by default at this time, but that may change later and allow for this configuration to be set.

To disallow root logins via ssh, simply adjust this configuration variable:

security_ssh_permit_root_login: 'no'

NOTE: The quotes around 'no' or 'yes' are very important. Ansible will treat no and yes as booleans by default and that will cause a True to land in your sshd configuration file. This will causes errors during sshd’s startup.

Notes for deployers and auditors¶

Implementation Status: Implemented

The tasks in sshd.yml will ensure that SSH does not allow empty passwords.

Notes for deployers and auditors¶

Implementation Status: Implemented

The ssh daemon will be configured so that a warning banner will be displayed after login. To configure the banner, edit the files/login_banner.txt file.

Notes for deployers and auditors¶

Implementation Status: Implemented

The ssh daemon will be configured to disallow user environment settings that may allow users to bypass access restrictions in some cases.

Notes for deployers and auditors¶

Implementation Status: Implemented

The ssh daemon will be configured to use the approved list of ciphers as recommended by the STIG.

Notes for deployers and auditors¶

Implementation Status: Exception

The openstack-ansible roles don’t install X by default, so there is no graphical desktop to configure.

Notes for deployers and auditors¶

Implementation Status: Exception

Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

Notes for deployers and auditors¶

Implementation Status: Exception

Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

Notes for deployers and auditors¶

Implementation Status: Exception

Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

Notes for deployers and auditors¶

Implementation Status: Exception

Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

Notes for deployers and auditors¶

Implementation Status: Implemented

In Ubuntu 14.04, the upstart init system looks for the default runlevel in the /etc/init/rc-sysinit.conf file. The tasks in the security role will ensure that the DEFAULT_RUNLEVEL environment variable is set to 2, which is a non-graphical runlevel.

In Ubuntu 16.04 and CentOS 7, systemd handles various targets, which are similar to runlevels from earlier init systems. There are two targets that are important for this STIG:

• graphical.target: similar to runlevel 5 from earlier init systems
• multi-user.target: similar to runlevel 2 or 3 from earlier init systems

The tasks in the security role will ensure that the default target is the multi-user.target, which provides a text-based system.

Deployers can opt out of this change by setting an Ansible variable:

security_disable_x_windows: no

Notes for deployers and auditors¶

Implementation Status: Exception

Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

Notes for deployers and auditors¶

Implementation Status: Exception

Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

Notes for deployers and auditors¶

Implementation Status: Exception

Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.