STIG Controls by Tag

STIG Controls by Tag

aide (8 controls)

A file integrity tool must be installed. (V-38489)

The AIDE package must be installed if it is to be available for integrity checking.

Details: V-38489 in STIG Viewer

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.


The operating system must detect unauthorized changes to software and information. (V-38670)

By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.

Details: V-38670 in STIG Viewer

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.


The operating system must ensure unauthorized, security-relevant configuration changes detected are tracked. (V-38673)

By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.

Details: V-38673 in STIG Viewer

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.


A file integrity tool must be used at least weekly to check for unauthorized file changes, particularly the addition of unauthorized system libraries or binaries, or for unauthorized modification to authorized system libraries or binaries. (V-38695)

By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.

Details: V-38695 in STIG Viewer

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.


The operating system must employ automated mechanisms, per organization defined frequency, to detect the addition of unauthorized components/devices into the operating system. (V-38696)

By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.

Details: V-38696 in STIG Viewer

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.


The operating system must employ automated mechanisms to detect the presence of unauthorized software on organizational information systems and notify designated organizational officials in accordance with the organization defined frequency. (V-38698)

By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.

Details: V-38698 in STIG Viewer

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.


The operating system must provide a near real-time alert when any of the organization defined list of compromise or potential compromise indicators occurs. (V-38700)

By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.

Details: V-38700 in STIG Viewer

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.


A file integrity baseline must be created. (V-51391)

For AIDE to be effective, an initial database of “known-good” information about files must be captured and it should be able to be verified against the installed files.

Details: V-51391 in STIG Viewer

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.

auditd (46 controls)

Audit log files must be group-owned by root. (V-38445)

If non-privileged users can write to audit logs, audit trails can be modified or destroyed.

Details: V-38445 in STIG Viewer

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.


The audit system must take appropriate action when there are disk errors on the audit storage volume. (V-38464)

Taking appropriate action in case of disk errors will minimize the possibility of losing audit records.

Details: V-38464 in STIG Viewer

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.


The system must use a separate file system for the system audit data path. (V-38467)

Placing “/var/log/audit” in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space.

Details: V-38467 in STIG Viewer

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.


The audit system must take appropriate action when the audit storage volume is full. (V-38468)

Taking appropriate action in case of a filled audit storage volume will minimize the possibility of losing audit records.

Details: V-38468 in STIG Viewer

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.


The audit system must alert designated staff members when the audit storage volume approaches capacity. (V-38470)

Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.

Details: V-38470 in STIG Viewer

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.


The system must forward audit records to the syslog service. (V-38471)

The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include an audit event multiplexor plugin (audispd) to pass audit records to the local syslog server.

Details: V-38471 in STIG Viewer

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.


Audit log directories must have mode 0755 or less permissive. (V-38493)

If users can delete audit logs, audit trails can be modified or destroyed.

Details: V-38493 in STIG Viewer

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).


Audit log files must be owned by root. (V-38495)

If non-privileged users can write to audit logs, audit trails can be modified or destroyed.

Details: V-38495 in STIG Viewer

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.


Audit log files must have mode 0640 or less permissive. (V-38498)

If users can write to audit logs, audit trails can be modified or destroyed.

Details: V-38498 in STIG Viewer

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).


The audit system must be configured to audit all attempts to alter system time through stime. (V-38525)

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Details: V-38525 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The audit system must be configured to audit all attempts to alter system time through clock_settime. (V-38527)

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Details: V-38527 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The audit system must be configured to audit all attempts to alter system time through /etc/localtime. (V-38530)

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Details: V-38530 in STIG Viewer

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.


The operating system must automatically audit account creation. (V-38531)

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Details: V-38531 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The operating system must automatically audit account modification. (V-38534)

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Details: V-38534 in STIG Viewer

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.


The operating system must automatically audit account disabling actions. (V-38536)

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Details: V-38536 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The operating system must automatically audit account termination. (V-38538)

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

Details: V-38538 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The audit system must be configured to audit modifications to the systems network configuration. (V-38540)

The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited.

Details: V-38540 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The audit system must be configured to audit modifications to the systems Mandatory Access Control (MAC) configuration (SELinux). (V-38541)

The system’s mandatory access policy (SELinux) should not be arbitrarily changed by anything other than administrator action. All changes to MAC policy should be audited.

Details: V-38541 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using chmod. (V-38543)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38543 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using chown. (V-38545)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38545 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using fchmod. (V-38547)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38547 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using fchmodat. (V-38550)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38550 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using fchown. (V-38552)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38552 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using fchownat. (V-38554)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38554 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using fremovexattr. (V-38556)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38556 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using fsetxattr. (V-38557)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38557 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using lchown. (V-38558)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38558 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using lremovexattr. (V-38559)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38559 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using lsetxattr. (V-38561)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38561 in STIG Viewer

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

The audit system must be configured to audit all discretionary access control permission modifications using removexattr. (V-38563)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38563 in STIG Viewer

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.


The audit system must be configured to audit all discretionary access control permission modifications using setxattr. (V-38565)

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

Details: V-38565 in STIG Viewer

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

The audit system must be configured to audit failed attempts to access files and programs. (V-38566)

Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.

Details: V-38566 in STIG Viewer

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

The audit system must be configured to audit successful file system mounts. (V-38568)

The unauthorized exportation of data to external media could result in an information leak where classified information, Privacy Act information, and intellectual property could be lost. An audit trail should be created each time a filesystem is mounted to help identify and guard against information loss.

Details: V-38568 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

Rules are added for auditd to log successful filesystem mounts.


The audit system must be configured to audit user deletions of files and programs. (V-38575)

Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as detecting malicious processes that attempt to delete log files to conceal their presence.

Details: V-38575 in STIG Viewer

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

The audit system must be configured to audit changes to the /etc/sudoers file. (V-38578)

The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes.

Details: V-38578 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The audit system must be configured to audit the loading and unloading of dynamic kernel modules. (V-38580)

The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel.

Details: V-38580 in STIG Viewer

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.


The operating system must produce audit records containing sufficient information to establish the identity of any user/subject associated with the event. (V-38628)

Ensuring the “auditd” service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.

Details: V-38628 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

This STIG requirement overlaps with V-38632.


The operating system must employ automated mechanisms to facilitate the monitoring and control of remote access methods. (V-38631)

Ensuring the “auditd” service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.

Details: V-38631 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

This STIG requirement overlaps with V-38632.


The operating system must produce audit records containing sufficient information to establish what type of events occurred. (V-38632)

Ensuring the “auditd” service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.

Details: V-38632 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The system must set a maximum audit log file size. (V-38633)

The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.

Details: V-38633 in STIG Viewer

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

The system must rotate audit log files that reach the maximum file size. (V-38634)

Automatically rotating logs (by setting this to “rotate”) minimizes the chances of the system unexpectedly running out of disk space by being overwhelmed with log data. However, for systems that must never discard log data, or which use external processes to transfer it and reclaim space, “keep_logs” can be employed.

Details: V-38634 in STIG Viewer

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.


The audit system must be configured to audit all attempts to alter system time through adjtimex. (V-38635)

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Details: V-38635 in STIG Viewer

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.


The system must retain enough rotated audit logs to cover the required log retention period. (V-38636)

The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.

Details: V-38636 in STIG Viewer

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

The system package management tool must verify contents of all files associated with the audit package. (V-38637)

The hash on important files like audit system executables should match the information given by the RPM database. Audit executables with erroneous hashes could be a sign of nefarious activity on the system.

Details: V-38637 in STIG Viewer

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.

Note

If the debsums package isn’t installed on Ubuntu, the Ansible task will install it during the playbook run.


The audit system must provide a warning when allocated audit record storage volume reaches a documented percentage of maximum audit record storage capacity. (V-38678)

Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.

Details: V-38678 in STIG Viewer

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.


The audit system must switch the system to single-user mode when available audit storage volume becomes dangerously low. (V-54381)

Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur.

Details: V-54381 in STIG Viewer

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.

Note

This will cause serious service disruptions for any environment and should only be enabled for extremely high security environments.

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

auth (47 controls)

The system must provide automated support for account management functions. (V-38439)

A comprehensive account management process that includes automation helps to ensure the accounts designated as requiring attention are consistently and promptly addressed. Enterprise environments make user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight.

Details: V-38439 in STIG Viewer

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.


The /etc/gshadow file must be owned by root. (V-38443)

The “/etc/gshadow” file contains group password hashes. Protection of this file is critical for system security.

Details: V-38443 in STIG Viewer

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.


The /etc/gshadow file must be group-owned by root. (V-38448)

The “/etc/gshadow” file contains group password hashes. Protection of this file is critical for system security.

Details: V-38448 in STIG Viewer

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.


The /etc/gshadow file must have mode 0000. (V-38449)

The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.

Details: V-38449 in STIG Viewer

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.


The /etc/passwd file must be owned by root. (V-38450)

The “/etc/passwd” file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Details: V-38450 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The /etc/passwd file must be group-owned by root. (V-38451)

The “/etc/passwd” file contains information about the users that are configured on the system. Protection of this file is critical for system security.

Details: V-38451 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The /etc/passwd file must have mode 0644 or less permissive. (V-38457)

If the “/etc/passwd” file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security.

Details: V-38457 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The /etc/group file must be owned by root. (V-38458)

The “/etc/group” file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Details: V-38458 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The /etc/group file must be group-owned by root. (V-38459)

The “/etc/group” file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Details: V-38459 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The /etc/group file must have mode 0644 or less permissive. (V-38461)

The “/etc/group” file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

Details: V-38461 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The system must require passwords to contain a minimum of 15 characters. (V-38475)

Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result. While it does not negate the password length requirement, it is preferable to migrate from a password-based authentication scheme to a stronger one based on PKI (public key infrastructure).

Details: V-38475 in STIG Viewer

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.


Users must not be able to change passwords more than once every 24 hours. (V-38477)

Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.

Details: V-38477 in STIG Viewer

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

User passwords must be changed at least every 60 days. (V-38479)

Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise.

Details: V-38479 in STIG Viewer

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

Users must be warned 7 days in advance of password expiration. (V-38480)

Setting the password warning age enables users to make the change at a practical time.

Details: V-38480 in STIG Viewer

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

The system must require passwords to contain at least one numeric character. (V-38482)

Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.

Details: V-38482 in STIG Viewer

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.


There must be no .rhosts or hosts.equiv files on the system. (V-38491)

Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system.

Details: V-38491 in STIG Viewer

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.


The system must prevent the root account from logging in from virtual consoles. (V-38492)

Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account.

Details: V-38492 in STIG Viewer

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.


The system must prevent the root account from logging in from serial consoles. (V-38494)

Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account.

Details: V-38494 in STIG Viewer

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.


Default operating system accounts, other than root, must be locked. (V-38496)

Disabling authentication for default system accounts makes it more difficult for attackers to make use of them to compromise a system.

Details: V-38496 in STIG Viewer

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.


The system must not have accounts configured with blank or null passwords. (V-38497)

If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

Details: V-38497 in STIG Viewer

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.


The /etc/passwd file must not contain password hashes. (V-38499)

The hashes for all user account passwords should be stored in the file “/etc/shadow” and never in “/etc/passwd”, which is readable by all users.

Details: V-38499 in STIG Viewer

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.


The root account must be the only account having a UID of 0. (V-38500)

An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.

Details: V-38500 in STIG Viewer

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.


The system must disable accounts after excessive login failures within a 15-minute interval. (V-38501)

Locking out user accounts after a number of incorrect attempts within a specific period of time prevents direct password guessing attacks.

Details: V-38501 in STIG Viewer

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.


The /etc/shadow file must be owned by root. (V-38502)

The “/etc/shadow” file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Details: V-38502 in STIG Viewer

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.


The /etc/shadow file must be group-owned by root. (V-38503)

The “/etc/shadow” file stores password hashes. Protection of this file is critical for system security.

Details: V-38503 in STIG Viewer

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.


The /etc/shadow file must have mode 0000. (V-38504)

The “/etc/shadow” file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

Details: V-38504 in STIG Viewer

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.


The system must require passwords to contain at least one uppercase alphabetic character. (V-38569)

Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space.

Details: V-38569 in STIG Viewer

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.


The system must require passwords to contain at least one special character. (V-38570)

Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.

Details: V-38570 in STIG Viewer

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.


The system must require passwords to contain at least one lower-case alphabetic character. (V-38571)

Requiring a minimum number of lower-case characters makes password guessing attacks more difficult by ensuring a larger search space.

Details: V-38571 in STIG Viewer

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.


The system must require at least eight characters be changed between the old and new passwords during a password change. (V-38572)

Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however.

Details: V-38572 in STIG Viewer

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.


The system must disable accounts after three consecutive unsuccessful logon attempts. (V-38573)

Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.

Details: V-38573 in STIG Viewer

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.


The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (system-auth). (V-38574)

Using a stronger hashing algorithm makes password cracking attacks more difficult.

Details: V-38574 in STIG Viewer

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:


The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (login.defs). (V-38576)

Using a stronger hashing algorithm makes password cracking attacks more difficult.

Details: V-38576 in STIG Viewer

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:


The system must use a FIPS 140-2 approved cryptographic hashing algorithm for generating account password hashes (libuser.conf). (V-38577)

Using a stronger hashing algorithm makes password cracking attacks more difficult.

Details: V-38577 in STIG Viewer

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:


The system must require administrator action to unlock an account locked by excessive failed login attempts. (V-38592)

Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Ensuring that an administrator is involved in unlocking locked accounts draws appropriate attention to such situations.

Details: V-38592 in STIG Viewer

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.


The system must be configured to require the use of a CAC, PIV compliant hardware token, or Alternate Logon Token (ALT) for authentication. (V-38595)

Smart card login provides two-factor authentication stronger than that provided by a username/password combination. Smart cards leverage a PKI (public key infrastructure) in order to provide and verify credentials.

Details: V-38595 in STIG Viewer

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.


If the system is using LDAP for authentication or account information, the system must use a TLS connection using FIPS 140-2 approved cryptographic algorithms. (V-38625)

The LDAP server will use unencrypted connections by default. If the LDAP daemon is not configured to use” ldaps:///”, all communications between the client and the server will not be encrypted. The LDAP server should be configured to use “ldaps:///” over the default “ldap:///”.

Details: V-38625 in STIG Viewer

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.


The LDAP client must use a TLS connection using trust certificates signed by the site CA. (V-38626)

The tls_cacertdir or tls_cacertfile directives are required when tls_checkpeer is configured (which is the default for openldap versions 2.1 and up). These directives define the path to the trust certificates signed by the site CA.

Details: V-38626 in STIG Viewer

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.


The system must prohibit the reuse of passwords within five iterations. (V-38658)

Preventing reuse of previous passwords helps ensure that a compromised password is not reused by a user.

Details: V-38658 in STIG Viewer

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.


All GIDs referenced in /etc/passwd must be defined in /etc/group (V-38681)

Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights.

Details: V-38681 in STIG Viewer

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'

All accounts on the system must have unique user or account names (V-38683)

Unique usernames allow for accountability on the system.

Details: V-38683 in STIG Viewer

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

Emergency accounts must be provisioned with an expiration date. (V-38690)

When emergency accounts are created, there is a risk they may remain in place and active after the need for them no longer exists. Account expiration greatly reduces the risk of accounts being misused or hijacked.

Details: V-38690 in STIG Viewer

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.


Accounts must be locked upon 35 days of inactivity. (V-38692)

Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.

Details: V-38692 in STIG Viewer

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.


The system must require passwords to contain no more than three consecutive repeating characters. (V-38693)

Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.

Details: V-38693 in STIG Viewer

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.


The operating system must manage information system identifiers for users and devices by disabling the user identifier after an organization defined time period of inactivity. (V-38694)

Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.

Details: V-38694 in STIG Viewer

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.


The operating system, upon successful logon/access, must display to the user the number of unsuccessful logon/access attempts since the last successful logon/access. (V-51875)

Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.

Details: V-51875 in STIG Viewer

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.


The sudo command must require authentication. (V-58901)

The “sudo” command allows authorized users to run programs (including shells) as other users, system users, and root. The “/etc/sudoers” file is used to configure authorized “sudo” users as well as the programs they are allowed to run. Some configuration options in the “/etc/sudoers” file allow configured users to run programs without re-authenticating. Use of these configuration options makes it easier for one compromised account to be used to compromise other accounts.

Details: V-58901 in STIG Viewer

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.

boot (9 controls)

Auditing must be enabled at boot by setting a kernel parameter. (V-38438)

Each process on the system carries an “auditable” flag which indicates whether its activities can be audited. Although “auditd” takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot.

Details: V-38438 in STIG Viewer

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

The system must use a separate file system for /tmp. (V-38455)

The “/tmp” partition is used as temporary storage by many programs. Placing “/tmp” in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it.

Details: V-38455 in STIG Viewer

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.


The system must use a separate file system for /var. (V-38456)

Ensuring that “/var” is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the “/var” directory to contain world-writable directories, installed by other software packages.

Details: V-38456 in STIG Viewer

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.


The system boot loader configuration file(s) must be owned by root. (V-38579)

Only root should be able to modify important boot parameters.

Details: V-38579 in STIG Viewer

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.


The system boot loader configuration file(s) must have mode 0600 or less permissive. (V-38583)

Proper permissions ensure that only the root user can modify important boot parameters.

Details: V-38583 in STIG Viewer

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.


The system boot loader must require authentication. (V-38585)

Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.

Details: V-38585 in STIG Viewer

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).


The system must require authentication upon booting into single-user and maintenance modes. (V-38586)

This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.

Details: V-38586 in STIG Viewer

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.


The system must not permit interactive boot. (V-38588)

Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security.

Details: V-38588 in STIG Viewer

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.


The noexec option must be added to the /tmp partition. (V-57569)

Allowing users to execute binaries from world-writable directories such as “/tmp” should never be necessary in normal operation and can expose the system to potential compromise.

Details: V-57569 in STIG Viewer

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.

console (3 controls)

The system must allow locking of the console screen in text mode. (V-38590)

Installing “screen” ensures a console locking capability is available for users who may need to suspend console logins.

Details: V-38590 in STIG Viewer

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.


The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, console login prompts. (V-38593)

An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.

Details: V-38593 in STIG Viewer

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.


The x86 Ctrl-Alt-Delete key sequence must be disabled. (V-38668)

A locally logged-in user who presses Ctrl-Alt-Delete, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.

Details: V-38668 in STIG Viewer

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.

file_perms (16 controls)

Library files must have mode 0755 or less permissive. (V-38465)

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system.

Details: V-38465 in STIG Viewer

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.


Library files must be owned by a system account. (V-38466)

Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system.

Details: V-38466 in STIG Viewer

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.


All system command files must have mode 755 or less permissive. (V-38469)

System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.

Details: V-38469 in STIG Viewer

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.


All system command files must be owned by root. (V-38472)

System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.

Details: V-38472 in STIG Viewer

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.


All rsyslog-generated log files must be owned by root. (V-38518)

The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.

Details: V-38518 in STIG Viewer

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.


All rsyslog-generated log files must be group-owned by root. (V-38519)

The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.

Details: V-38519 in STIG Viewer

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.


The audit system must be configured to audit all use of setuid and setgid programs. (V-38567)

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.

Details: V-38567 in STIG Viewer

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.


The system boot loader configuration file(s) must be group-owned by root. (V-38581)

The “root” group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.

Details: V-38581 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


All rsyslog-generated log files must have mode 0600 or less permissive. (V-38623)

Log files can contain valuable information regarding system configuration. If the system log files are not protected, unauthorized users could change the logged data, eliminating their forensic value.

Details: V-38623 in STIG Viewer

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.


The system default umask for daemons must be 027 or 022. (V-38642)

The umask influences the permissions assigned to files created by a process at run time. An unnecessarily permissive umask could result in files being created with insecure permissions.

Details: V-38642 in STIG Viewer

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.


There must be no world-writable files on the system. (V-38643)

Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files.

Details: V-38643 in STIG Viewer

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.


The system default umask in /etc/login.defs must be 077. (V-38645)

The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and/or written to by unauthorized users.

Details: V-38645 in STIG Viewer

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

The system default umask in /etc/profile must be 077. (V-38647)

The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and/or written to by unauthorized users.

Details: V-38647 in STIG Viewer

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.


The system default umask for the csh shell must be 077. (V-38649)

The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and/or written to by unauthorized users.

Details: V-38649 in STIG Viewer

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.


The system default umask for the bash shell must be 077. (V-38651)

The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and/or written to by unauthorized users.

Details: V-38651 in STIG Viewer

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.


All public directories must be owned by a system account. (V-38699)

Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.

Details: V-38699 in STIG Viewer

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.

kernel (24 controls)

The operating system must enforce requirements for the connection of mobile devices to operating systems. (V-38490)

USB storage devices such as thumb drives can be used to introduce unauthorized software and other vulnerabilities. Support for these devices should be disabled and the devices themselves should be tightly controlled.

Details: V-38490 in STIG Viewer

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.


The Datagram Congestion Control Protocol (DCCP) must be disabled unless required. (V-38514)

Disabling DCCP protects the system against exploitation of any flaws in its implementation.

Details: V-38514 in STIG Viewer

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.


The Stream Control Transmission Protocol (SCTP) must be disabled unless required. (V-38515)

Disabling SCTP protects the system against exploitation of any flaws in its implementation.

Details: V-38515 in STIG Viewer

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.


The Reliable Datagram Sockets (RDS) protocol must be disabled unless required. (V-38516)

Disabling RDS protects the system against exploitation of any flaws in its implementation.

Details: V-38516 in STIG Viewer

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.


The Transparent Inter-Process Communication (TIPC) protocol must be disabled unless required. (V-38517)

Disabling TIPC protects the system against exploitation of any flaws in its implementation.

Details: V-38517 in STIG Viewer

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.


The system must not accept IPv4 source-routed packets on any interface. (V-38523)

Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.

Details: V-38523 in STIG Viewer

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.


The system must not accept ICMPv4 redirect packets on any interface. (V-38524)

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

Details: V-38524 in STIG Viewer

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

The system must not accept ICMPv4 secure redirect packets on any interface. (V-38526)

Accepting “secure” ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.

Details: V-38526 in STIG Viewer

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

The system must log Martian packets. (V-38528)

The presence of “martian” packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected.

Details: V-38528 in STIG Viewer

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.


The system must not accept IPv4 source-routed packets by default. (V-38529)

Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.

Details: V-38529 in STIG Viewer

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.


The system must not accept ICMPv4 secure redirect packets by default. (V-38532)

Accepting “secure” ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.

Details: V-38532 in STIG Viewer

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.


The system must ignore ICMPv4 redirect messages by default. (V-38533)

This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.

Details: V-38533 in STIG Viewer

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.


The system must not respond to ICMPv4 sent to a broadcast address. (V-38535)

Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network.

Details: V-38535 in STIG Viewer

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.


The system must ignore ICMPv4 bogus error responses. (V-38537)

Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged.

Details: V-38537 in STIG Viewer

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.


The system must be configured to use TCP syncookies when experiencing a TCP SYN flood. (V-38539)

A TCP SYN flood attack can cause a denial of service by filling a system’s TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests.

Details: V-38539 in STIG Viewer

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:


The system must use a reverse-path filter for IPv4 network traffic when possible on all interfaces. (V-38542)

Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks.

Details: V-38542 in STIG Viewer

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.


The system must use a reverse-path filter for IPv4 network traffic when possible by default. (V-38544)

Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks.

Details: V-38544 in STIG Viewer

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.


The IPv6 protocol handler must not be bound to the network stack unless needed. (V-38546)

Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation.

Details: V-38546 in STIG Viewer

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.


The system must ignore ICMPv6 redirects by default. (V-38548)

An illicit ICMP redirect message could result in a man-in-the-middle attack.

Details: V-38548 in STIG Viewer

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

The system must implement virtual address space randomization. (V-38596)

Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code he or she has introduced into a process’s address space during an attempt at exploitation. Additionally, ASLR also makes it more difficult for an attacker to know the location of existing code in order to repurpose it using return oriented programming (ROP) techniques.

Details: V-38596 in STIG Viewer

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.


The system must limit the ability of processes to have simultaneous write and execute access to memory. (V-38597)

ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process’s memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range.

Details: V-38597 in STIG Viewer

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.


The system must not send ICMPv4 redirects by default. (V-38600)

Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers.

Details: V-38600 in STIG Viewer

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.


The system must not send ICMPv4 redirects from any interface. (V-38601)

Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers.

Details: V-38601 in STIG Viewer

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.


The Bluetooth kernel module must be disabled. (V-38682)

If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation.

Details: V-38682 in STIG Viewer

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.

log (2 controls)

The operating system must back up audit records on an organization defined frequency onto a different system or media than the system being audited. (V-38520)

A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.

Details: V-38520 in STIG Viewer

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.


The operating system must support the requirement to centrally manage the content of audit records generated by organization defined information system components. (V-38521)

A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.

Details: V-38521 in STIG Viewer

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.

lsm (4 controls)

The system must have a host-based intrusion detection tool installed. (V-38667)

Adding host-based intrusion detection tools can provide the capability to automatically take actions in response to malicious behavior, which can provide additional agility in reacting to network threats. These tools also often include a reporting capability to provide network awareness of system, which may not otherwise exist in an organization’s systems management regime.

Details: V-38667 in STIG Viewer

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.


The system must use a Linux Security Module at boot time. (V-51337)

Disabling a major host protection feature, such as SELinux, at boot time prevents it from confining system services at boot time. Further, it increases the chances that it will remain off during system operation.

Details: V-51337 in STIG Viewer

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.

Note

If SELinux was disabled before the security role was applied, the filesystem will be automatically relabeled on the next boot. For most systems, this process only takes a few minutes. However, it can take additional time to finish on systems with slow disks or a large number of files.

Deployers are strongly urged to relabel the filesystem if the system has never had SELinux in enforcing mode previously. Rebooting into enforcing mode with a partially-labeled filesystem can lead to unnecessary SELinux policy denials.

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.


The system must use a Linux Security Module configured to enforce limits on system services. (V-51363)

Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges.

Details: V-51363 in STIG Viewer

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.


All device files must be monitored by the system Linux Security Module. (V-51379)

If a device file carries the SELinux type “unlabeled_t”, then SELinux cannot properly restrict access to the device file.

Details: V-51379 in STIG Viewer

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.

mail (4 controls)

The mail system must forward all mail for root to one or more system administrators. (V-38446)

A number of system services utilize email messages sent to the root user to notify system administrators of active or impending issues. These messages must be forwarded to at least one monitored email address.

Details: V-38446 in STIG Viewer

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.


Mail relaying must be restricted. (V-38622)

This ensures “postfix” accepts mail messages (such as cron job reports) from the local system only, and not from the network, which protects it from network attack.

Details: V-38622 in STIG Viewer

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.


The postfix service must be enabled for mail delivery. (V-38669)

Local mail delivery is essential to some system maintenance and notification tasks.

Details: V-38669 in STIG Viewer

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.


The audit system must identify staff members to receive notifications of audit log storage volume capacity issues. (V-38680)

Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action.

Details: V-38680 in STIG Viewer

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.

misc (26 controls)

The system must use a separate file system for /var/log. (V-38463)

Placing “/var/log” in its own partition enables better separation between log files and other files in “/var/”.

Details: V-38463 in STIG Viewer

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.


The system must use a separate file system for user home directories. (V-38473)

Ensuring that “/home” is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage.

Details: V-38473 in STIG Viewer

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.


The operating system must conduct backups of system-level information contained in the information system per organization defined frequency to conduct backups that are consistent with recovery time and recovery point objectives. (V-38486)

Operating system backup is a critical step in maintaining data assurance and availability. System-level information includes system-state information, operating system and application software, and licenses. Backups must be consistent with organizational recovery time and recovery point objectives.

Details: V-38486 in STIG Viewer

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.


The operating system must conduct backups of user-level information contained in the operating system per organization defined frequency to conduct backups consistent with recovery time and recovery point objectives. (V-38488)

Operating system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. Backups shall be consistent with organizational recovery time and recovery point objectives.

Details: V-38488 in STIG Viewer

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.


IP forwarding for IPv4 must not be enabled, unless the system is a router. (V-38511)

IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers.

Details: V-38511 in STIG Viewer

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).


The audit system must be configured to audit all attempts to alter system time through settimeofday. (V-38522)

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.

Details: V-38522 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


There must be no .netrc files on the system. (V-38619)

Unencrypted passwords for remote FTP servers may be stored in ”.netrc” files. DoD policy requires passwords be encrypted in storage and not used in access scripts.

Details: V-38619 in STIG Viewer

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.


The system clock must be synchronized continuously, or at least daily. (V-38620)

Enabling the “ntpd” service ensures that the “ntpd” service will be running and that the system will synchronize its time to any servers specified. This is important whether the system is configured to be a client (and synchronize only its own clock) or it is also acting as an NTP server to other systems. Synchronizing time is essential for authentication services such as Kerberos, but it is also important for maintaining accurate logs and auditing possible security breaches.

Details: V-38620 in STIG Viewer

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.


The system clock must be synchronized to an authoritative DoD time source. (V-38621)

Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. Using a trusted NTP server provided by your organization is recommended.

Details: V-38621 in STIG Viewer

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.


System logs must be rotated daily. (V-38624)

Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full.

Details: V-38624 in STIG Viewer

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.


The ntpdate service must not be running. (V-38644)

The “ntpdate” service may only be suitable for systems which are rebooted frequently enough that clock drift does not cause problems between reboots. In any event, the functionality of the ntpdate service is now available in the ntpd program and should be considered deprecated.

Details: V-38644 in STIG Viewer

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.


Remote file systems must be mounted with the nodev option. (V-38652)

Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users.

Details: V-38652 in STIG Viewer

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.


The snmpd service must not use a default password. (V-38653)

Presence of the default SNMP password enables querying of different system aspects and could result in unauthorized knowledge of the system.

Details: V-38653 in STIG Viewer

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.


Remote file systems must be mounted with the nosuid option. (V-38654)

NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem.

Details: V-38654 in STIG Viewer

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.


The noexec option must be added to removable media partitions. (V-38655)

Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise.

Details: V-38655 in STIG Viewer

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.


The operating system must employ cryptographic mechanisms to protect information in storage. (V-38659)

The risk of a system’s physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost.

Details: V-38659 in STIG Viewer

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.


The snmpd service must use only SNMP protocol version 3 or newer. (V-38660)

Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information.

Details: V-38660 in STIG Viewer

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.


The operating system must protect the confidentiality and integrity of data at rest. (V-38661)

The risk of a system’s physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost.

Details: V-38661 in STIG Viewer

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.


The operating system must employ cryptographic mechanisms to prevent unauthorized disclosure of data at rest unless otherwise protected by alternative physical measures. (V-38662)

The risk of a system’s physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost.

Details: V-38662 in STIG Viewer

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.


The system must use and update a DoD-approved virus scan program. (V-38666)

Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems.

Details: V-38666 in STIG Viewer

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:


Process core dumps must be disabled unless needed. (V-38675)

A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems.

Details: V-38675 in STIG Viewer

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

The system must limit users to 10 simultaneous system logins, or a site-defined number, in accordance with operational requirements. (V-38684)

Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions.

Details: V-38684 in STIG Viewer

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

Temporary accounts must be provisioned with an expiration date. (V-38685)

When temporary accounts are created, there is a risk they may remain in place and active after the need for them no longer exists. Account expiration greatly reduces the risk of accounts being misused or hijacked.

Details: V-38685 in STIG Viewer

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.


The sticky bit must be set on all public directories. (V-38697)

Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure. The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, and by users for temporary file storage - such as /tmp - and for directories requiring global read/write access.

Details: V-38697 in STIG Viewer

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


The FTP daemon must be configured for logging or verbose mode. (V-38702)

To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the ftp server are logged using the verbose vsftpd log format. The default vsftpd log file is /var/log/vsftpd.log.

Details: V-38702 in STIG Viewer

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.


The system must use a Linux Security Module configured to limit the privileges of system services. (V-51369)

Setting the SELinux policy to “targeted” or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services.

Details: V-51369 in STIG Viewer

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.

network (10 controls)

The systems local IPv6 firewall must implement a deny-all, allow-by-exception policy for inbound packets. (V-38444)

In “ip6tables” the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to “DROP” implements proper design for a firewall, i.e., any packets which are not explicitly permitted should not be accepted.

Details: V-38444 in STIG Viewer

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.


The operating system must prevent public IPv4 access into an organizations internal networks, except as appropriately mediated by managed interfaces employing boundary protection devices. (V-38512)

The “iptables” service provides the system’s host-based firewalling capability for IPv4 and ICMP.

Details: V-38512 in STIG Viewer

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.


The systems local IPv4 firewall must implement a deny-all, allow-by-exception policy for inbound packets. (V-38513)

In “iptables” the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to “DROP” implements proper design for a firewall, i.e., any packets which are not explicitly permitted should not be accepted.

Details: V-38513 in STIG Viewer

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.


The system must employ a local IPv6 firewall. (V-38549)

The “ip6tables” service provides the system’s host-based firewalling capability for IPv6 and ICMPv6.

Details: V-38549 in STIG Viewer

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.


The operating system must connect to external networks or information systems only through managed IPv6 interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture. (V-38551)

The “ip6tables” service provides the system’s host-based firewalling capability for IPv6 and ICMPv6.

Details: V-38551 in STIG Viewer

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.


The operating system must prevent public IPv6 access into an organizations internal networks, except as appropriately mediated by managed interfaces employing boundary protection devices. (V-38553)

The “ip6tables” service provides the system’s host-based firewalling capability for IPv6 and ICMPv6.

Details: V-38553 in STIG Viewer

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.


The system must employ a local IPv4 firewall. (V-38555)

The “iptables” service provides the system’s host-based firewalling capability for IPv4 and ICMP.

Details: V-38555 in STIG Viewer

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.


The operating system must connect to external networks or information systems only through managed IPv4 interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture. (V-38560)

The “iptables” service provides the system’s host-based firewalling capability for IPv4 and ICMP.

Details: V-38560 in STIG Viewer

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.


The systems local firewall must implement a deny-all, allow-by-exception policy for forwarded packets. (V-38686)

In “iptables” the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to “DROP” implements proper design for a firewall, i.e., any packets which are not explicitly permitted should not be accepted.

Details: V-38686 in STIG Viewer

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.


The system must provide VPN connectivity for communications over untrusted networks. (V-38687)

Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network.

Details: V-38687 in STIG Viewer

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.

nfsd (2 controls)

The NFS server must not have the all_squash option enabled. (V-38460)

The “all_squash” option maps all client requests to a single anonymous uid/gid on the NFS server, negating the ability to track file access by user ID.

Details: V-38460 in STIG Viewer

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.


The NFS server must not have the insecure file locking option enabled. (V-38677)

Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user.

Details: V-38677 in STIG Viewer

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.

package (13 controls)

The system package management tool must verify contents of all files associated with packages. (V-38447)

The hash on important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system.

Details: V-38447 in STIG Viewer

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.


The system package management tool must verify permissions on all files and directories associated with packages. (V-38452)

Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated.

Details: V-38452 in STIG Viewer

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.


The system package management tool must verify group-ownership on all files and directories associated with packages. (V-38453)

Group-ownership of system binaries and configuration files that is incorrect could allow an unauthorized user to gain privileges that they should not have. The group-ownership set by the vendor should be maintained. Any deviations from this baseline should be investigated.

Details: V-38453 in STIG Viewer

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.


The system package management tool must verify ownership on all files and directories associated with packages. (V-38454)

Ownership of system binaries and configuration files that is incorrect could allow an unauthorized user to gain privileges that they should not have. The ownership set by the vendor should be maintained. Any deviations from this baseline should be investigated.

Details: V-38454 in STIG Viewer

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.


Vendor-provided cryptographic certificates must be installed to verify the integrity of system software. (V-38476)

The Red Hat GPG keys are necessary to cryptographically verify packages are from Red Hat.

Details: V-38476 in STIG Viewer

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.


The Red Hat Network Service (rhnsd) service must not be running, unless using RHN or an RHN Satellite. (V-38478)

Although systems management and patching is extremely important to system security, management by a system outside the enterprise enclave is not desirable for some environments. However, if the system is being managed by RHN or RHN Satellite Server the “rhnsd” daemon can remain on.

Details: V-38478 in STIG Viewer

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.


System security patches and updates must be installed and up-to-date. (V-38481)

Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.

Details: V-38481 in STIG Viewer

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.

Note

Automatically upgrading packages can provide significant security benefits, but they can reduce availability and reliability. Updating packages can cause daemons to restart on some systems and they can cause local customizations of configuration files to be lost.

Deployers are strongly urged to understand the nature of this change and the associated risks prior to enabling automatic upgrades.

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.


The system package management tool must cryptographically verify the authenticity of system software packages during installation. (V-38483)

Ensuring the validity of packages’ cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering.

Details: V-38483 in STIG Viewer

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.


The operating system, upon successful logon, must display to the user the date and time of the last logon or access via ssh. (V-38484)

Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the date and time of their last successful login allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. At ssh login, a user must be presented with the last successful login date and time.

Details: V-38484 in STIG Viewer

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.


The system package management tool must cryptographically verify the authenticity of all software packages during installation. (V-38487)

Ensuring all packages’ cryptographic signatures are valid prior to installation ensures the provenance of the software and protects against malicious tampering.

Details: V-38487 in STIG Viewer

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.


The system package management tool must verify permissions on all files and directories associated with the audit package. (V-38663)

Permissions on audit binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated.

Details: V-38663 in STIG Viewer

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.


The system package management tool must verify ownership on all files and directories associated with the audit package. (V-38664)

Ownership of audit binaries and configuration files that is incorrect could allow an unauthorized user to gain privileges that they should not have. The ownership set by the vendor should be maintained. Any deviations from this baseline should be investigated.

Details: V-38664 in STIG Viewer

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.


The system package management tool must verify group-ownership on all files and directories associated with the audit package. (V-38665)

Group-ownership of audit binaries and configuration files that is incorrect could allow an unauthorized user to gain privileges that they should not have. The group-ownership set by the vendor should be maintained. Any deviations from this baseline should be investigated.

Details: V-38665 in STIG Viewer

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.

services (30 controls)

Automated file system mounting tools must not be enabled unless needed. (V-38437)

All filesystems that are required for the successful operation of the system should be explicitly listed in “/etc/fstab” by an administrator. New filesystems should not be arbitrarily introduced via the automounter. The “autofs” daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as “/misc/cd”. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it is almost always possible to configure filesystem mounts statically by editing “/etc/fstab” rather than relying on the automounter.

Details: V-38437 in STIG Viewer

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

The xinetd service must be disabled if no network services utilizing it are enabled. (V-38582)

The xinetd service provides a dedicated listener service for some programs, which is no longer necessary for commonly-used network services. Disabling it ensures that these uncommon services are not running, and also prevents attacks against xinetd itself.

Details: V-38582 in STIG Viewer

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

The xinetd service must be uninstalled if no network services utilizing it are enabled. (V-38584)

Removing the “xinetd” package decreases the risk of the xinetd service’s accidental (or intentional) activation.

Details: V-38584 in STIG Viewer

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

The telnet-server package must not be installed. (V-38587)

Removing the “telnet-server” package decreases the risk of the unencrypted telnet service’s accidental (or intentional) activation. Mitigation: If the telnet-server package is configured to only allow encrypted sessions, such as with Kerberos or the use of encrypted network tunnels, the risk of exposing sensitive information is mitigated.

Details: V-38587 in STIG Viewer

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

The telnet daemon must not be running. (V-38589)

The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. The telnet protocol is also subject to man-in-the-middle attacks. Mitigation: If an enabled telnet daemon is configured to only allow encrypted sessions, such as with Kerberos or the use of encrypted network tunnels, the risk of exposing sensitive information is mitigated.

Details: V-38589 in STIG Viewer

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.


The rsh-server package must not be installed. (V-38591)

The “rsh-server” package provides several obsolete and insecure network services. Removing it decreases the risk of those services’ accidental (or intentional) activation.

Details: V-38591 in STIG Viewer

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

The rshd service must not be running. (V-38594)

The rsh service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Details: V-38594 in STIG Viewer

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.


The rexecd service must not be running. (V-38598)

The rexec service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Details: V-38598 in STIG Viewer

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.


The FTPS/FTP service on the system must be configured with the Department of Defense (DoD) login banner. (V-38599)

This setting will cause the system greeting banner to be used for FTP connections as well.

Details: V-38599 in STIG Viewer

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.


The rlogind service must not be running. (V-38602)

The rlogin service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network.

Details: V-38602 in STIG Viewer

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.


The ypserv package must not be installed. (V-38603)

Removing the “ypserv” package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.

Details: V-38603 in STIG Viewer

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

The ypbind service must not be running. (V-38604)

Disabling the “ypbind” service ensures the system is not acting as a client in a NIS or NIS+ domain.

Details: V-38604 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The cron service must be running. (V-38605)

Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential.

Details: V-38605 in STIG Viewer

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.


The tftp-server package must not be installed unless required. (V-38606)

Removing the “tftp-server” package decreases the risk of the accidental (or intentional) activation of tftp services.

Details: V-38606 in STIG Viewer

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

The TFTP service must not be running. (V-38609)

Disabling the “tftp” service ensures the system is not acting as a tftp server, which does not provide encryption or authentication.

Details: V-38609 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The avahi service must be disabled. (V-38618)

Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Its functionality is convenient but is only appropriate if the local network can be trusted.

Details: V-38618 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The openldap-servers package must not be installed unless required. (V-38627)

Unnecessary packages should not be installed to decrease the attack surface of the system.

Details: V-38627 in STIG Viewer

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

The Automatic Bug Reporting Tool (abrtd) service must not be running. (V-38640)

Mishandling crash data could expose sensitive information about vulnerabilities in software executing on the local machine, as well as sensitive information from within a process’s address space or registers.

Details: V-38640 in STIG Viewer

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

The atd service must be disabled. (V-38641)

The “atd” service could be used by an unsophisticated insider to carry out activities outside of a normal login session, which could complicate accountability. Furthermore, the need to schedule tasks with “at” or “batch” is not common.

Details: V-38641 in STIG Viewer

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

The oddjobd service must not be running. (V-38646)

The “oddjobd” service may provide necessary functionality in some environments but it can be disabled if it is not needed. Execution of tasks by privileged programs, on behalf of unprivileged ones, has traditionally been a source of privilege escalation security issues.

Details: V-38646 in STIG Viewer

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.


The qpidd service must not be running. (V-38648)

The qpidd service is automatically installed when the “base” package selection is selected during installation. The qpidd service listens for network connections which increases the attack surface of the system. If the system is not intended to receive AMQP traffic then the “qpidd” service is not needed and should be disabled or removed.

Details: V-38648 in STIG Viewer

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

The rdisc service must not be running. (V-38650)

General-purpose systems typically have their network and routing information configured statically by a system administrator. Workstations or some special- purpose systems often use DHCP (instead of IRDP) to retrieve dynamic network configuration information.

Details: V-38650 in STIG Viewer

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

The system must use SMB client signing for connecting to samba servers using smbclient. (V-38656)

Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit.

Details: V-38656 in STIG Viewer

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.


The system must use SMB client signing for connecting to samba servers using mount.cifs. (V-38657)

Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit.

Details: V-38657 in STIG Viewer

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.


The sendmail package must be removed. (V-38671)

The sendmail software was not developed with security in mind and its design prevents it from being effectively contained by SELinux. Postfix should be used instead.

Details: V-38671 in STIG Viewer

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

The netconsole service must be disabled unless required. (V-38672)

The “netconsole” service is not necessary unless there is a need to debug kernel panics, which is not common.

Details: V-38672 in STIG Viewer

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

The xorg-x11-server-common (X Windows) package must not be installed, unless required. (V-38676)

Unnecessary packages should not be installed to decrease the attack surface of the system.

Details: V-38676 in STIG Viewer

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

The DHCP client must be disabled if not needed. (V-38679)

DHCP relies on trusting the local network. If the local network is not trusted, then it should not be used. However, the automatic configuration provided by DHCP is commonly used and the alternative, manual configuration, presents an unacceptable burden in many circumstances.

Details: V-38679 in STIG Viewer

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.


The Bluetooth service must be disabled. (V-38691)

Disabling the “bluetooth” service prevents the system from attempting connections to Bluetooth devices, which entails some security risk. Nevertheless, variation in this risk decision may be expected due to the utility of Bluetooth connectivity and its limited range.

Details: V-38691 in STIG Viewer

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

The TFTP daemon must operate in secure mode which provides access only to a single directory on the host file system. (V-38701)

Using the “-s” option causes the TFTP service to only serve files from the given directory. Serving files from an intentionally specified directory reduces the risk of sharing files which should remain private.

Details: V-38701 in STIG Viewer

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.

sshd (10 controls)

The SSH daemon must be configured to use only the SSHv2 protocol. (V-38607)

SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used.

Details: V-38607 in STIG Viewer

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.


The SSH daemon must set a timeout interval on idle sessions. (V-38608)

Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another.

Details: V-38608 in STIG Viewer

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

The SSH daemon must set a timeout count on idle sessions. (V-38610)

This ensures a user login will be terminated as soon as the “ClientAliveCountMax” is reached.

Details: V-38610 in STIG Viewer

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

The SSH daemon must ignore .rhosts files. (V-38611)

SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.

Details: V-38611 in STIG Viewer

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.


The SSH daemon must not allow host-based authentication. (V-38612)

SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.

Details: V-38612 in STIG Viewer

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.


The system must not permit root logins using remote access programs such as ssh. (V-38613)

Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root’s password.

Details: V-38613 in STIG Viewer

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.


The SSH daemon must not allow authentication using an empty password. (V-38614)

Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.

Details: V-38614 in STIG Viewer

Notes for deployers and auditors

Implementation Status: Implemented

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


The SSH daemon must be configured with the Department of Defense (DoD) login banner. (V-38615)

The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution.

Details: V-38615 in STIG Viewer

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.


The SSH daemon must not permit user environment settings. (V-38616)

SSH environment options potentially allow users to bypass access restriction in some configurations.

Details: V-38616 in STIG Viewer

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.


The SSH daemon must be configured to use only FIPS 140-2 approved ciphers. (V-38617)

Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.

Details: V-38617 in STIG Viewer

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.

x11 (9 controls)

The system must allow locking of graphical desktop sessions. (V-38474)

The ability to lock graphical desktop sessions manually allows users to easily secure their accounts should they need to depart from their workstations temporarily.

Details: V-38474 in STIG Viewer

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.


The graphical desktop environment must set the idle timeout to no more than 15 minutes. (V-38629)

Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby.

Details: V-38629 in STIG Viewer

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.


The graphical desktop environment must automatically lock after 15 minutes of inactivity and the system must require user reauthentication to unlock the environment. (V-38630)

Enabling idle activation of the screen saver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area.

Details: V-38630 in STIG Viewer

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.


The graphical desktop environment must have automatic lock enabled. (V-38638)

Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby.

Details: V-38638 in STIG Viewer

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.


The system must display a publicly-viewable pattern during a graphical desktop environment session lock. (V-38639)

Setting the screensaver mode to blank-only conceals the contents of the display from passersby.

Details: V-38639 in STIG Viewer

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.


X Windows must not be enabled unless required. (V-38674)

Unnecessary services should be disabled to decrease the attack surface of the system.

Details: V-38674 in STIG Viewer

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

Note

This change will not take effect until the server is rebooted. Changing a runlevel on an actively running system can cause certain services to stop, start, or restart.


A login banner must be displayed immediately prior to, or as part of, graphical desktop environment login prompts. (V-38688)

An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.

Details: V-38688 in STIG Viewer

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.


The Department of Defense (DoD) login banner must be displayed immediately prior to, or as part of, graphical desktop environment login prompts. (V-38689)

An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.

Details: V-38689 in STIG Viewer

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.


The login user list must be disabled. (V-43150)

Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to quickly enumerate known user accounts without logging in.

Details: V-43150 in STIG Viewer

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.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.