Home » Security hardening for openstack-ansible

Category 1 (Low) controls

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

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

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

disable_services['autofs'] = no

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

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

Exception

Adjusting the bootloader configuration can cause issues with reboots and this work is left up to the deployer. Enabling auditing at boot time is helpful, but the risk may not be worth the change in most environments.

The auditd process starts very early during the boot process to catch events already, and this should be sufficient for most environments.

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

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

Exception

Verifying contents of files installed from packages is more difficult in Ubuntu, mainly due to the lack of an equivalent of rpm -V. The debsums package installs the debsums command and that can be used to look for files that have changed since the package was installed.

However, not all packages have MD5 checksums for all files and debsums doesn’t do detailed checking like rpm. Deployers are urged to run debsums -c to review changes made to files on their systems. This report takes a long time to run on most systems.

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

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

Exception

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

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

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

Exception

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

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

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

Exception

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

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

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

Exception

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.

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

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

Exception

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.

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

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

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.

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

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

Exception

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.

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

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

Exception

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.

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

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

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.

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

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

Exception

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

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

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

Exception

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

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

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

Exception

Ubuntu doesn’t use the Red Hat Network Service, so this requirement doesn’t apply.

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

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

Details: V-38480 in STIG Viewer.

Notes for deployers

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:

password_warn_age: 7

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

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

Details: V-38482 in STIG Viewer.

Notes for deployers

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.

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

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

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.

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

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

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.

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

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

Details: V-38516 in STIG Viewer.

Notes for deployers

The Reliable Datagram Sockets (RDS) protocol must be disabled. Neither Ubuntu 14.04 or openstack-ansible enables this module by default, so the Ansible tasks in this role will disable the module.

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

disable_module['rds']: no

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

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

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

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

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

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

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

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

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

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

V-38528: The system must log Martian packets.

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

The Ansible task in this role will ensure that martian packets are logged to rsyslog. Wikpedia’s article on martian packets provides additional information.

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

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

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

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

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

Exception

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

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

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

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.

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

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

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.

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

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

By default, Ubuntu 14.04 rejects ICMPv4 packets sent to a broadcast address. The Ansible tasks for this STIG configuration ensures that the secure default setting is maintained.

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

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

Exception

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

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

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

Details: V-38537 in STIG Viewer.

Notes for deployers

Ubuntu already ignores ICMPv4 bogus error messages by default. The role will ensure that this default setting is maintained.

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

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

Exception

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

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

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

Rules are added for auditing network configuration changes. The path to Ubuntu’s standard network configuration location has replaced the path to Red Hat’s default network configuration location.

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

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

The RHEL 6 STIG requires that changes to SELinux policies and configuration are audited. However, Ubuntu’s preference for Mandatory Access Control (MAC) is AppArmor and openstack-ansible configures AppArmor by default.

This requirement has been modified to fit AppArmor on an Ubuntu system.

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

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

Exception

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:

auditd_rules['DAC_chmod']: yes
auditd_rules['DAC_fchmod']: yes
auditd_rules['DAC_fchmodat']: yes

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

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

Rules are added for auditd to log discretionary access control permission changes done with chown.

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

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

Exception

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:

auditd_rules['DAC_chmod']: yes
auditd_rules['DAC_fchmod']: yes
auditd_rules['DAC_fchmodat']: yes

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

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

Exception

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:

auditd_rules['DAC_chmod']: yes
auditd_rules['DAC_fchmod']: yes
auditd_rules['DAC_fchmodat']: yes

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

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

Rules are added for auditing discretionary access control changes made by fchown.

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

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

Rules are added for auditing discretionary access control changes made by fchownat.

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

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

Rules are added for auditing discretionary access control changes made by fremovexattr.

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

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

Rules are added for auditing discretionary access control changes made via fsetxattr.

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

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

Rules are added for auditing discretionary access control changes made via lchown.

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

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

Rules are added for auditing discretionary access control changes made via lremovexattr.

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

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

Rules are added to auditd to log all DAC modifications using lsetxattr.

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

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

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.

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

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

Rules are added so that all permission modifications made via setxattr are logged.

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

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

Rules are added for auditd to log failed access attempts to files and programs.

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

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

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.

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

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

Rules are added for auditd to log successful filesystem mounts.

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

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

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.

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

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

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.

V-38571: The system must require passwords to contain at least one lowercase alphabetic character.

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

Details: V-38571 in STIG Viewer.

Notes for deployers

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.

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

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

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.

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

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

Exception

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:

auditd_rules['deletions'] = no

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

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

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

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

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

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:

remove_services['xinetd'] = no

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

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

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.

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

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

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

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

ssh_client_alive_interval = 600

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

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

Details: V-38610 in STIG Viewer.

Notes for deployers

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:

ssh_client_alive_count_max = 0

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

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

Details: V-38616 in STIG Viewer.

Notes for deployers

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

V-38618: The avahi service must be disabled.

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

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

V-38624: System logs must be rotated daily.

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

The STIG requires that system logs are rotate 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.

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

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

Details: V-38627 in STIG Viewer.

Notes for deployers

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:

remove_services['ldap-server']: no

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

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

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.

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

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

Details: V-38639 in STIG Viewer.

Notes for deployers

Exception

Neither Ubuntu or openstack-ansible installs a graphical desktop by default. 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.

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

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

services.yml reads a list of services and their desired state from the ‘defaults/main.yml’ cat3_services variable. With this list the tasks will ensure the services are in the state desired by their corresponding STIG requirement.

V-38641: The atd service must be disabled.

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

services.yml reads a list of services and their desired state from the ‘defaults/main.yml’ cat3_services variable. With this list the tasks will ensure the services are in the state desired by their corresponding STIG requirement.

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

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

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 umask_daemons_init to 027. The current default for Ubuntu 14.04 is 027 already, so deployers do not need to make any adjustments to Ansible variables to meet the STIG requirement.

V-38644: The ntpdate service must not be running.

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

Special case

Ubuntu doesn’t provide the same ntpdate service that a Red Hat Enterprise Linux 6 server would have. In addition, time synchronization is added within the fixes for V-38620 (where chrony is installed and configured).

There is no action to be taken on Ubuntu for this STIG.

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

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

Exception

Ubuntu’s default umask setting in /etc/login.defs is 022, but the STIG requires 077 to be set. Since changing umask settings can disrupt some systems, this change requires a deployer to opt-in.

To opt-in for this change and adjust the umask, the Ansible variable umask_login_defs must be set to 077.

V-38646: The oddjobd service must not be running.

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

Special case

Ubuntu doesn’t package the oddjobd daemon, so there are no packages to remove or daemons to stop. There is no action to be taken for this STIG on Ubuntu 14.04.

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

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

Fixed by another STIG

Ubuntu 14.04 doesn’t use umask settings in /etc/profile. Those settings are expected to be in /etc/login.defs instead. See V-38645 for more details.

V-38648: The qpidd service must not be running.

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

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:

disable_services['qpidd']: no

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

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

Opt-in required

Neither Ubuntu or openstack-ansible installs the csh shell by default.

Since umask changes can be disruptive on some systems, the deployer must opt-in for this change to happen. If the 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.

V-38650: The rdisc service must not be running.

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

Special case

Ubuntu doesn’t provide packages containing the rdisc service at this time. Therefore, no action is taken for this STIG.

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

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

Opt-in required

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 umask_bash to 077.

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

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

Exception

Neither Ubuntu nor openstack-ansible will configure any removable media mounts by default. Deploys are strongly urged to mount any additional disks with the noexec mount option set.

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

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

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

Details: V-38656 in STIG Viewer.

Notes for deployers

Although the samba server isn’t installed by Ubuntu or openstack-ansible by default, the Ansible tasks will check to see if the package is installed and the configuration file will be adjusted. If adjustments are made, the service will be restarted.

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

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

Details: V-38657 in STIG Viewer.

Notes for deployers

Exception

Ubuntu and openstack-ansible do not currently configure any samba share mounts by default. However, deployers are urged to follow this STIG if they ever mount samba shares within their infrastructure.

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

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

Exception

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.

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

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

Exception

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.

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

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

Exception

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.

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

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

Details: V-38669 in STIG Viewer.

Notes for deployers

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.

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

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

Ubuntu doesn’t provide the netconsole package and the daemon isn’t included in any other Ubuntu packages. Therefore, no action is required for this STIG.

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

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

Ubuntu doesn’t restrict core dumps by default, but the STIG requires that core dumps are disabled for all users unless absolutely necessary.

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

disable_core_dumps: no

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

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

Details: V-38676 in STIG Viewer.

Notes for deployers

Neither Ubuntu nor openstack-ansible install the X windows server by default. 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:

remove_services['xorg']: no

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

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

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'

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

Unique usernames allow for accountability on the system.

Details: V-38683 in STIG Viewer.

Notes for deployers

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

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

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

Opt-in required

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:

max_simultaneous_logins: 10

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

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

Exception

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.

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

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

Exception

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

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


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

Exception

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.

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

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

Opt-in required

By default, Ubuntu doesn’t require that inactive accounts are locked after a period of time. The STIG requires that accounts with 35 days of activity are locked.

Deployers must opt-in for this change by setting the inactive_account_lock_days Ansible variable. 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 inactive_account_lock_days is set.

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

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

Details: V-38693 in STIG Viewer.

Notes for deployers

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.

V-38694: 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.

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

Opt-in required

By default, Ubuntu doesn’t require that inactive accounts are locked after a period of time. The STIG requires that accounts with 35 days of activity are locked.

Deployers must opt-in for this change by setting the inactive_account_lock_days Ansible variable. 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 inactive_account_lock_days is set.

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

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

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

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

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

Exception

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.

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

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

Although neither Ubuntu nor openstack-ansible installs or configures vsftpd by default, the Ansible task 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.

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

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

Although SELinux is available on Ubuntu 14.04, the policies aren’t maintained as well as they are on Red Hat-based systems. The openstack-ansible has chosen to use the more Ubuntu-compatible Linux security module, AppArmor.

AppArmor roles are configured in openstack-ansible to limit the chances of container breakout and the potential damage done in case it does occur.

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

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

Exception

Although SELinux works through a labeling system where every file (including devices) receive a label, AppArmor 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.

Table Of Contents

Previous topic

Security hardening controls in detail

Next topic

Category 2 (Medium) controls

Project Source

This Page