Home » Security hardening for openstack-ansible
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Placing “/var/log” in its own partition enables better separation between log files and other files in “/var/”.
Details: V-38463 in STIG Viewer.
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.
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.
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.
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.
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.
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.
Exception
Creating /home on a different partition is highly recommended but it is left to deployers to configure during the installation of the OS.
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.
Exception
The openstack-ansible roles don’t install X by default, so there is no graphical desktop to configure.
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.
Exception
Ubuntu doesn’t use the Red Hat Network Service, so this requirement doesn’t apply.
Setting the password warning age enables users to make the change at a practical time.
Details: V-38480 in STIG Viewer.
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
Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.
Details: V-38482 in STIG Viewer.
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.
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.
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.
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.
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.
Disabling RDS protects the system against exploitation of any flaws in its implementation.
Details: V-38516 in STIG Viewer.
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:
security_disable_module_rds: no
NOTE: The module will be disabled on the next reboot.
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.
Rules are added for auditing changes to system time made via 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-38525 in STIG Viewer.
Rules are added for auditing changes to system time done via 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-38527 in STIG Viewer.
Rules are added for auditing changes to system time done via clock_settime.
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.
Exception
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.
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.
Rules are added to auditd to log all attempts to change the system time using /etc/localtime.
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.
Exception
The audit rules from V-38534 already cover all account modifications.
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.
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.
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.
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.
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.
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.
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.
Exception
The audit rules from V-38534 already cover all account modifications.
Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged.
Details: V-38537 in STIG Viewer.
Ubuntu already ignores ICMPv4 bogus error messages by default. The role will ensure that this default setting is maintained.
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.
Exception
The audit rules from V-38534 already cover all account modifications.
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.
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.
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.
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.
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.
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:
security_audit_DAC_chmod: yes
security_audit_DAC_fchmod: yes
security_audit_DAC_fchmodat: yes
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.
Exception
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 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.
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:
security_audit_DAC_chmod: yes
security_audit_DAC_fchmod: yes
security_audit_DAC_fchmodat: yes
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.
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:
security_audit_DAC_chmod: yes
security_audit_DAC_fchmod: yes
security_audit_DAC_fchmodat: yes
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.
Exception
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 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.
Exception
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 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.
Exception
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 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.
Exception
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 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.
Exception
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 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.
Exception
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 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.
Exception
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 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.
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 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.
Exception
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
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.
Exception
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
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.
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 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.
Rules are added for auditd to log successful filesystem mounts.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
security_audit_deletions: yes
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.
Rules are added to audit changes to /etc/sudoers.
Removing the “xinetd” package decreases the risk of the xinetd service’s accidental (or intentional) activation.
Details: V-38584 in STIG Viewer.
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
Installing “screen” ensures a console locking capability is available for users who may need to suspend console logins.
Details: V-38590 in STIG Viewer.
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.
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.
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
This ensures a user login will be terminated as soon as the “ClientAliveCountMax” is reached.
Details: V-38610 in STIG Viewer.
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
SSH environment options potentially allow users to bypass access restriction in some configurations.
Details: V-38616 in STIG Viewer.
The ssh daemon will be configured to disallow user environment settings that may allow users to bypass access restrictions in some cases.
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.
The avahi daemon will be disabled if the package is installed.
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.
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.
Unnecessary packages should not be installed to decrease the attack surface of the system.
Details: V-38627 in STIG Viewer.
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
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.
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.
Setting the screensaver mode to blank-only conceals the contents of the display from passersby.
Details: V-38639 in STIG Viewer.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
Special case
Ubuntu doesn’t provide packages containing the rdisc service at this time. Therefore, no action is taken for this STIG.
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.
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.
Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise.
Details: V-38655 in STIG Viewer.
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.
Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit.
Details: V-38656 in STIG Viewer.
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.
Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit.
Details: V-38657 in STIG Viewer.
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.
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.
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.
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.
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.
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.
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.
Local mail delivery is essential to some system maintenance and notification tasks.
Details: V-38669 in STIG Viewer.
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 “netconsole” service is not necessary unless there is a need to debug kernel panics, which is not common.
Details: V-38672 in STIG Viewer.
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.
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.
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
Unnecessary packages should not be installed to decrease the attack surface of the system.
Details: V-38676 in STIG Viewer.
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:
security_remove_xorg: no
Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights.
Details: V-38681 in STIG Viewer.
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'
Unique usernames allow for accountability on the system.
Details: V-38683 in STIG Viewer.
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
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.
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
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.
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.
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.
Exception
The configuration of encrypted tunnels between deployers and their OpenStack environment is left up to the deployers to configure.
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.
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.
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.
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.
Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.
Details: V-38693 in STIG Viewer.
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.
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.
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.
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.
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
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.
Exception
The STIG requires administrators to search for directories meeting all of the following criteria:
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.
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.
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.
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.
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 project 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.
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.
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.