Home » Security hardening for openstack-ansible
A comprehensive account management process that includes automation helps to ensure the accounts designated as requiring attention are consistently and promptly addressed. Enterprise environments make user account management challenging and complex. A user management process requiring administrators to manually address account management functions adds risk of potential oversight.
Details: V-38439 in STIG Viewer.
Exception
Although adding centralized authentication and carefully managing user accounts is critical for securing any system, that’s left up to deployers to handle via their internal business processes.
The “/etc/gshadow” file contains group password hashes. Protection of this file is critical for system security.
Details: V-38443 in STIG Viewer.
The Ansible tasks will ensure that /etc/gshadow is owned by root. This is the default in Ubuntu 14.04 already, but the tasks will ensure that the permissions match the STIG requirements in case they were changed by other means after the installation of the operating system.
In “ip6tables” the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to “DROP” implements proper design for a firewall, i.e., any packets which are not explicitly permitted should not be accepted.
Details: V-38444 in STIG Viewer.
Exception
See V-38551 for additional details. IPv6 configuration and filtering is left up to the deployer.
If non-privileged users can write to audit logs, audit trails can be modified or destroyed.
Details: V-38445 in STIG Viewer.
Although audit log files are owned by the root user and group by default in Ubuntu 14.04, the Ansible task for V-38445 will ensure that they are configured as such.
A number of system services utilize email messages sent to the root user to notify system administrators of active or impending issues. These messages must be forwarded to at least one monitored email address.
Details: V-38446 in STIG Viewer.
Forwarding root’s email to another user is highly recommended, but the Ansible tasks won’t configure an email address to receive root’s email unless that email address is configured. Set root_forward_email to an email address that is ready to receive root’s email.
The “/etc/gshadow” file contains group password hashes. Protection of this file is critical for system security.
Details: V-38448 in STIG Viewer.
Although the /etc/gshadow file is group-owned by root by default, the Ansible tasks will ensure that it is configured that way.
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
Details: V-38449 in STIG Viewer.
The /etc/gshadow file’s permissions will be changed to 0000 to meet the requirements of the STIG.
The “/etc/passwd” file contains information about the users that are configured on the system. Protection of this file is critical for system security.
Details: V-38450 in STIG Viewer.
The ownership of /etc/passwd will be changed to root.
The “/etc/passwd” file contains information about the users that are configured on the system. Protection of this file is critical for system security.
Details: V-38451 in STIG Viewer.
The group ownership for /etc/passwd will be set to root.
If the “/etc/passwd” file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security.
Details: V-38457 in STIG Viewer.
The permissions for /etc/passwd will be set to 0644.
The “/etc/group” file contains information regarding groups that are configured on the system. Protection of this file is important for system security.
Details: V-38458 in STIG Viewer.
The Ansible task will ensure that the /etc/group file is owned by the root user.
The “/etc/group” file contains information regarding groups that are configured on the system. Protection of this file is important for system security.
Details: V-38459 in STIG Viewer.
The tasks in file_perms.yml will ensure that /etc/group is owned by the root account.
The “/etc/group” file contains information regarding groups that are configured on the system. Protection of this file is important for system security.
Details: V-38461 in STIG Viewer.
Ubuntu sets the mode of /etc/group to 0644 by default and the Ansible task will ensure that it is current set to those permissions.
Taking appropriate action in case of disk errors will minimize the possibility of losing audit records.
Details: V-38464 in STIG Viewer.
Ubuntu’s default for disk_error_action is SUSPEND, which actually only suspends audit logging. That could be a security issue, so SYSLOG is recommended and is set by default by openstack-ansible-security. There are additional options available, like EXEC, SINGLE or HALT.
To configure a different disk_error_action, set the following Ansible variable:
disk_error_action: SYSLOG
For details on available settings and what they do, run man auditd.conf. Some options can cause the host to go offline until the issue is fixed. Deployers are urged to carefully read the auditd documentation prior to changing the disk_error_action setting from the default.
Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system.
Details: V-38465 in STIG Viewer.
Exception
Ubuntu 14.04 sets library files to have 0755 (or more restrictive) permissions by default. Deployers are urged to review the permissions of libraries regularly to ensure the system hasn’t been altered.
Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system.
Details: V-38466 in STIG Viewer.
Exception
As with V-38465, Ubuntu sets the ownership of library files to root by default. Deployers are urged to configure monitoring for changes to these files.
Taking appropriate action in case of a filled audit storage volume will minimize the possibility of losing audit records.
Details: V-38468 in STIG Viewer.
Ubuntu’s default for disk_full_action is SUSPEND, which actually only suspends audit logging. That could be a security issue, so SYSLOG is recommended and is set by default by openstack-ansible-security. If syslog messages are being sent to remote servers, these log messages should alert an administrator about the disk being full. There are additional options available, like EXEC, SINGLE or HALT.
To configure a different disk_full_action, set the following Ansible variable:
disk_full_action: SYSLOG
For details on available settings and what they do, run man auditd.conf. Some options can cause the host to go offline until the issue is fixed. Deployers are urged to carefully read the auditd documentation prior to changing the disk_full_action setting from the default.
System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.
Details: V-38469 in STIG Viewer.
Exception
Ubuntu sets the permissions for system commands to 0755 or less already. Deployers are urged to review these permissions for changes over time as they can be a sign of a compromise.
Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.
Details: V-38470 in STIG Viewer.
Ubuntu’s default for space_left_action is SUSPEND, which actually only suspends audit logging. That could be a security issue, so SYSLOG is recommended and is set by default by openstack-ansible-security. If syslog messages are being sent to remote servers, these log messages should alert an administrator about the disk being almost full. There are additional options available, like EXEC, SINGLE or HALT.
To configure a different space_left_action, set the following Ansible variable:
space_left_action: SYSLOG
For details on available settings and what they do, run man auditd.conf. Some options can cause the host to go offline until the issue is fixed. Deployers are urged to carefully read the auditd documentation prior to changing the space_left_action setting from the default.
System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.
Details: V-38472 in STIG Viewer.
Exception
Ubuntu sets system commands to be owned by root by default Deployers are urged to review ownership changes via auditd rules to ensure system commands haven’t changed ownership over time.
Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result. While it does not negate the password length requirement, it is preferable to migrate from a password-based authentication scheme to a stronger one based on PKI (public key infrastructure).
Details: V-38475 in STIG Viewer.
Configuration required
Ubuntu 14.04 does not set a password length requirement by default. The STIG recommends passwords to be a minimum of 14 characters in length. To apply this setting, set the following Ansible variable:
password_minimum_length: 14
Deployers are urged to avoid the use of passwords and rely upon SSH keys if possible.
Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.
Details: V-38477 in STIG Viewer.
Configuration required
Ubuntu doesn’t set a limitation on how frequently uses can change passwords. However, the STIG recommends setting a limit of one password change per day.
To enable this configuration, use this Ansible variable:
password_minimum_days: 14
Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise.
Details: V-38479 in STIG Viewer.
Configuration required
Ubuntu doesn’t set a limitation on the age of passwords. However, the STIG recommends setting a limit of 60 days before a password must be changed.
To enable this configuration, use this Ansible variable:
password_maximum_days: 60
Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.
Details: V-38481 in STIG Viewer.
Exception
Operating system patching is left up to the deployer to configure based on their business requirements and toleration for risk. Enabling automated updates in Ubuntu can be done with changes to the apt configuration.
Ubuntu’s documentation on automatic updates covers a few options for configuring apt.
Ensuring the validity of packages’ cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering.
Details: V-38483 in STIG Viewer.
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.
Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the date and time of their last successful login allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. At ssh login, a user must be presented with the last successful login date and time.
Details: V-38484 in STIG Viewer.
Ubuntu 14.04 already enables the display of the last successful login for a user immediately after login. An Ansible task ensures this setting is applied and restarts the ssh daemon if necessary.
Operating system backup is a critical step in maintaining data assurance and availability. System-level information includes system-state information, operating system and application software, and licenses. Backups must be consistent with organizational recovery time and recovery point objectives.
Details: V-38486 in STIG Viewer.
Exception
System backups are left to the deployer to configure. Deployers are stringly urged to maintain backups of each system, including log files and critical configuration information.
Operating system backup is a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. Backups shall be consistent with organizational recovery time and recovery point objectives.
Details: V-38488 in STIG Viewer.
Exception
System backups are left to the deployer to configure. Deployers are stringly urged to maintain backups of each system, including log files and critical configuration information.
The AIDE package must be installed if it is to be available for integrity checking.
Details: V-38489 in STIG Viewer.
The aide package will be installed by Ansible tasks.
USB storage devices such as thumb drives can be used to introduce unauthorized software and other vulnerabilities. Support for these devices should be disabled and the devices themselves should be tightly controlled.
Details: V-38490 in STIG Viewer.
Exception
Disabling the usb-storage module can add extra security, but it’s not necessary on most systems. To disable the usb-storage module on hosts, set the following variable to yes:
security_disable_module_usb_storage: yes
NOTE: The module will be disabled on the next reboot.
Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account.
Details: V-38492 in STIG Viewer.
The virtual consoles mentioned in V-38492 aren’t used in Ubuntu 14.04 by default.
If users can delete audit logs, audit trails can be modified or destroyed.
Details: V-38493 in STIG Viewer.
Ubuntu 14.04 sets the mode of /var/log/audit/ to 0750 by default. The Ansible task for this requirement ensures that the mode is 0750 (which is more strict than the STIG requirement).
If non-privileged users can write to audit logs, audit trails can be modified or destroyed.
Details: V-38495 in STIG Viewer.
The Ansible tasks will ensure that files in /var/log/audit are owned by the root user.
Disabling authentication for default system accounts makes it more difficult for attackers to make use of them to compromise a system.
Details: V-38496 in STIG Viewer.
Exception
The Ansible tasks will check for default system accounts (other than root) that are not locked. The tasks won’t take any action, however, because any action could cause authorized users to be unable to access the system. However, if any unlocked default system accounts are found, the playbook will fail with an error message until the user accounts are locked.
Deployers who intentionally want to skip this step should use --skip-tags V-38496 to avoid a playbook failure on this check.
Deployers are urged to audit the accounts on their systems and lock any users that don’t need to log in via consoles or via ssh.
If users can write to audit logs, audit trails can be modified or destroyed.
Details: V-38498 in STIG Viewer.
Ubuntu and CentOS set the current audit log (the one that is actively being written to) to 0600 so that only the root user can read and write to it. The older, rotated logs are set to 0400 since they should not receive any more writes.
The STIG requirement states that log files must have mode 0640 or less. The security role will remove any permissions that are not allowed by the STIG (u-x,g-wx,o-rwx).
The hashes for all user account passwords should be stored in the file “/etc/shadow” and never in “/etc/passwd”, which is readable by all users.
Details: V-38499 in STIG Viewer.
The Ansible task will search for password hashes in /etc/passwd using awk and report a failure if any are found.
An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.
Details: V-38500 in STIG Viewer.
The Ansible tasks will search for accounts in /etc/passwd that have UID 0 that aren’t the normal root account. If any matching accounts are found, a warning is printed to stdout and the Ansible play will fail.
No action is taken on those accounts as that action may disrupt a production environment. Deployers are strongly urged to use sudo for these types of actions.
Locking out user accounts after a number of incorrect attempts within a specific period of time prevents direct password guessing attacks.
Details: V-38501 in STIG Viewer.
Exception and opt-in alternative
Adjusting PAM configurations is very risky since it affects how all users authenticate. In addition, pam_faillock.so isn’t available in Ubuntu.
Another option is to utilize pam_tally to deny logins after failed attempts. Adjusting PAM configurations automatically can disrupt the operation of production systems, so this is left up to the deployer to configure. For more details on how to configure pam_tally, refer to this AskUbuntu article about pam_tally.
Another alternative is fail2ban. Read the notes below for more tails on this option.
The Ansible tasks will install fail2ban and configure it to ban IP addresses using the following logic
Deployers must opt-in for fail2ban to be installed and configured. To opt-in, set the install_fail2ban Ansible variable to yes. The time period for bans can also be configured (in seconds) via tha fail2ban_bantime variable:
install_fail2ban: yes
fail2ban_bantime: 900
NOTE: Fail2ban can only review authentication attempts for services that listen on the network, such as ssh. It has no control over physical consoles. Deployers are strongly urged to use stong physical security policies to prevent unauthorized users from accessing server consoles. In addition, deployers must secure out-of-band access methods, like IPMI, as they can be vectors for physical console access as well.
The “/etc/shadow” file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.
Details: V-38502 in STIG Viewer.
Ubuntu 14.04 sets the user and group ownership of /etc/passwd to root by default. The Ansible task will ensure that the default is maintained.
The “/etc/shadow” file stores password hashes. Protection of this file is critical for system security.
Details: V-38503 in STIG Viewer.
Ubuntu 14.04 sets the user and group ownership of /etc/passwd to root by default. The Ansible task will ensure that the default is maintained.
The “/etc/shadow” file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.
Details: V-38504 in STIG Viewer.
Although Ubuntu 14.04’s default for /etc/shadow is 0640, the STIG requires a mode of 0000. This doesn’t affect how the system operates since root is the only user that should be able to read from and write to /etc/shadow. Allowing users to read the file could open up the system to attacks since the password hashes can be dumped and brute forced.
IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers.
Details: V-38511 in STIG Viewer.
Special Case
Running virtual infrastructure requires IP forwarding to be enabled on various interfaces. The STIG allows for this, so long as the system is being operated as a router (as is the case for an OpenStack host).
The “iptables” service provides the system’s host-based firewalling capability for IPv4 and ICMP.
Details: V-38512 in STIG Viewer.
Exception
Although a minimal set of iptables rules are configured on openstack-ansible hosts, the “deny all” requirement of the STIG is not met. This is largely left up to the deployer to do, based on their assessment of their own network segmentation.
Deployers are urged to review the network access controls that are applied on the network devices between their OpenStack environment and the rest of their network.
In “iptables” the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to “DROP” implements proper design for a firewall, i.e., any packets which are not explicitly permitted should not be accepted.
Details: V-38513 in STIG Viewer.
Exception
Although a minimal set of iptables rules are configured on openstack-ansible hosts, the “deny all” requirement of the STIG is not met. This is largely left up to the deployer to do, based on their assessment of their own network segmentation.
Deployers are urged to review the network access controls that are applied on the network devices between their OpenStack environment and the rest of their network.
Disabling DCCP protects the system against exploitation of any flaws in its implementation.
Details: V-38514 in STIG Viewer.
The Datagram Congestion Control Protocol (DCCP) must be disabled if it’s not needed. Neither Ubuntu 14.04 or openstack-ansible utilizes this kernel module and the Ansible tasks will disable it by default.
To opt-out of this change, simply change the following variable to no:
security_disable_module_dccp: no
NOTE: The module will be disabled on the next reboot.
Disabling SCTP protects the system against exploitation of any flaws in its implementation.
Details: V-38515 in STIG Viewer.
The Stream Control Transmission Protocol (SCTP) must be disabled. This module isn’t used by Ubuntu 14.04 or openstack-ansible by default.
To opt-out of this change, set the following variable to no:
security_disable_module_sctp: no
NOTE: The module will be disabled on the next reboot.
Disabling TIPC protects the system against exploitation of any flaws in its implementation.
Details: V-38517 in STIG Viewer.
The Transparent Inter-Process Communication (TIPC) 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_tipc: no
NOTE: The module will be disabled on the next reboot.
The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.
Details: V-38518 in STIG Viewer.
Exception
Different systems may have different log files populated depending on the type of data that rsyslogd receives. By default, log files are created with the user and group ownership set to root.
The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.
Details: V-38519 in STIG Viewer.
Exception
Different systems may have different log files populated depending on the type of data that rsyslogd receives. By default, log files are created with the user and group ownership set to root.
A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.
Details: V-38520 in STIG Viewer.
Exception
At the moment, OpenStack-Ansible already sends logs to the rsyslog container from various containers and hosts. However, deployers are strongly urged to forward these logs to a system outside their openstack-ansible environment to ensure that they cannot be altered.
Some compliance programs require centralized logging, including PCI-DSS.
A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.
Details: V-38521 in STIG Viewer.
Exception
At the moment, OpenStack-Ansible already sends logs to the rsyslog container from various containers and hosts. However, deployers are strongly urged to forward these logs to a system outside their openstack-ansible environment to ensure that they cannot be altered.
Some compliance programs require centralized logging, including PCI-DSS.
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Details: V-38523 in STIG Viewer.
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.
Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required.
Details: V-38524 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.
Accepting “secure” ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.
Details: V-38526 in STIG Viewer.
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.
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Details: V-38529 in STIG Viewer.
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.
Accepting “secure” ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.
Details: V-38532 in STIG Viewer.
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.
A TCP SYN flood attack can cause a denial of service by filling a system’s TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests.
Details: V-38539 in STIG Viewer.
The STIG recommends enabling TCP SYN cookies to deal with TCP SYN floods. Ubuntu 14.04 already enables SYN cookies by default, and this role will ensure that the default is maintained.
Keep in mind, however, that high-traffic environments may require TCP SYN cookies to be disabled. Certain load balancers may forward requests in such a way that web servers may think they’re being SYN flooded during peak traffic events. Putting well-configured hardware network devices in front of OpenStack environments is always recommended and this may allow some deployers to turn off SYN cookies within their environment.
Deployers can disable TCP SYN cookies by setting an Ansible variable:
security_sysctl_tcp_syncookies: 0
For more information on TCP SYN cookies and TCP SYN floods, refer to these links:
Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks.
Details: V-38542 in STIG Viewer.
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.
Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks.
Details: V-38544 in STIG Viewer.
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.
Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation.
Details: V-38546 in STIG Viewer.
Opt-in required
The STIG requires IPv6 to be disabled system-wide unless it is needed for the system to operate. Deployers must consider how their network is configured before disabling IPv6 entirely.
To opt-in for this change, set the following Ansible variable to yes:
disable_ipv6: yes
NOTE: This change will go into effect immediately on the system and persist through reboots.
An illicit ICMP redirect message could result in a man-in-the-middle attack.
Details: V-38548 in STIG Viewer.
Exception
Disabling IPv6 redirects can cause issues with OpenStack environments which have IPv6 enabled and are routing IPv6 traffic.
The “ip6tables” service provides the system’s host-based firewalling capability for IPv6 and ICMPv6.
Details: V-38549 in STIG Viewer.
Exception
Adding IPv6 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.
The “ip6tables” service provides the system’s host-based firewalling capability for IPv6 and ICMPv6.
Details: V-38551 in STIG Viewer.
Exception
Filtering IPv6 traffic is left up to the deployer to implement. The openstack-ansible roles don’t configure IPv6 (at this time) and adding persistent ip6tables rules could harm a running system.
However, deployers are strongly recommended to implement IPv6 filtering at the edges of the network via network devices. In addition, deployers should be aware that link-local IPv6 addresses are configured automatcally by the system and those addresses could open up new network paths for future attacks.
For example, if IPv4 access was tightly controlled and segmented, hosts and/or containers could possibly communicate across these boundaries using IPv6 link-local addresses. For more detailed information on this security topic, review Cisco’s documentation titled IPv6 Security Brief that is available on their website.
The “ip6tables” service provides the system’s host-based firewalling capability for IPv6 and ICMPv6.
Details: V-38553 in STIG Viewer.
Exception
Adding IPv6 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.
The “iptables” service provides the system’s host-based firewalling capability for IPv4 and ICMP.
Details: V-38555 in STIG Viewer.
Exception
Adding IPv4 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.
The “iptables” service provides the system’s host-based firewalling capability for IPv4 and ICMP.
Details: V-38560 in STIG Viewer.
Exception
Adding IPv4 firewalling on OpenStack hosts is left up to the deployer to configure. Deployers are urged to use proper network segmentation between their OpenStack infrastructure and virtual machines, which will mitigate many of the most critical threats.
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.
Details: V-38573 in STIG Viewer.
Exception and opt-in alternative
Adjusting PAM configurations is very risky since it affects how all users authenticate. In addition, pam_faillock.so isn’t available in Ubuntu.
Another option is to utilize pam_tally to deny logins after failed attempts. Adjusting PAM configurations automatically can disrupt the operation of production systems, so this is left up to the deployer to configure. For more details on how to configure pam_tally, refer to this AskUbuntu article about pam_tally.
Another alternative is fail2ban. Read the notes below for more tails on this option.
The Ansible tasks will install fail2ban and configure it to ban IP addresses using the following logic
Deployers must opt-in for fail2ban to be installed and configured. To opt-in, set the install_fail2ban Ansible variable to yes. The time period for bans can also be configured (in seconds) via tha fail2ban_bantime variable:
install_fail2ban: yes
fail2ban_bantime: 900
NOTE: Fail2ban can only review authentication attempts for services that listen on the network, such as ssh. It has no control over physical consoles. Deployers are strongly urged to use stong physical security policies to prevent unauthorized users from accessing server consoles. In addition, deployers must secure out-of-band access methods, like IPMI, as they can be vectors for physical console access as well.
Using a stronger hashing algorithm makes password cracking attacks more difficult.
Details: V-38574 in STIG Viewer.
The STIG requires SHA512 to be used for hashing password since it is in the list of FIPS 140-2 approved hashing algorithms. This is also the default in Ubuntu 14.04.
The Ansible tasks will verify that the secure default is still set in the system’s PAM configuration. If it has been altered, the playbook will fail and display an error.
Further reading:
Using a stronger hashing algorithm makes password cracking attacks more difficult.
Details: V-38576 in STIG Viewer.
The STIG requires SHA512 to be used for hashing password since it is in the list of FIPS 140-2 approved hashing algorithms. This is also the default in Ubuntu 14.04.
The Ansible tasks will verify that the secure default is still set in /etc/login.defs. If it has been altered, the playbook will fail and display an error.
Further reading:
Using a stronger hashing algorithm makes password cracking attacks more difficult.
Details: V-38577 in STIG Viewer.
The STIG requires SHA512 to be used for hashing password since it is in the list of FIPS 140-2 approved hashing algorithms. This is also the default in Ubuntu 14.04.
The libuser package isn’t installed by default in Ubuntu or via openstack-ansible. The Ansible tasks will do the following:
Further reading:
Only root should be able to modify important boot parameters.
Details: V-38579 in STIG Viewer.
Ubuntu 14.04 sets the ownership on /boot/grub/grub.cfg to root by default. The Ansible task will ensure that the secure default is maintained.
The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel.
Details: V-38580 in STIG Viewer.
Rules will be added to auditd so that any kernel module loading or unloading events will be logged.
The “root” group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.
Details: V-38581 in STIG Viewer.
The group ownership for /boot/grub/grub.cfg will be set to root.
The xinetd service provides a dedicated listener service for some programs, which is no longer necessary for commonly-used network services. Disabling it ensures that these uncommon services are not running, and also prevents attacks against xinetd itself.
Details: V-38582 in STIG Viewer.
If the xinetd package is installed, it will be stopped immediately and will not start on the next boot. No action is taken if xinetd isn’t installed.
To opt-out of this change, simply adjust the following configuration item to no:
security_disable_xinetd: no
Proper permissions ensure that only the root user can modify important boot parameters.
Details: V-38583 in STIG Viewer.
The permissions on /boot/grub/grub.cfg will be set to 0644.
Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.
Details: V-38585 in STIG Viewer.
Exception
Configuring a password for the bootloader is left up to the deployer to configure. Each deployer should consider the potential damage to their system should someone gain unauthorized physical access at the server itself or via an out-of-band management solution (like IPMI, DRAC, or iLO).
This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.
Details: V-38586 in STIG Viewer.
Exception
As with V-38585, this is left to the deployer to configure bassed on their exposure to physical threats. If there is a concern around a user gaining unauthorized physical access and/or gaining access through an out-of-band access mechanism, deployers are strongly urged to consider applying this security configuration.
Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security.
Details: V-38588 in STIG Viewer.
Exception
As with V-38585, this configuration is left up to the deployer to determine their risk of attacks via physical access or out-of-band access to a server console.
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Ensuring that an administrator is involved in unlocking locked accounts draws appropriate attention to such situations.
Details: V-38592 in STIG Viewer.
Exception
Adjusting PAM configurations on a running system carries a fair amount of risk, and deployers are urged to rely upon ssh keys or centralized authentication for user authentication.
Centralized authentication systems provide a benefit of locking a user’s account in all systems they have access to, rather than locking access to only one system.
An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.
Details: V-38593 in STIG Viewer.
A default warning banner will replace the contents of /etc/issue.net. To configure the banner, simply edit files/login_banner.txt.
Smart card login provides two-factor authentication stronger than that provided by a username/password combination. Smart cards leverage a PKI (public key infrastructure) in order to provide and verify credentials.
Details: V-38595 in STIG Viewer.
Exception
Use of additional factors for authentication is left up to the deployer, but it is strongly recommended.
Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code he or she has introduced into a process’s address space during an attempt at exploitation. Additionally, ASLR also makes it more difficult for an attacker to know the location of existing code in order to repurpose it using return oriented programming (ROP) techniques.
Details: V-38596 in STIG Viewer.
The Ansible tasks will set kernel.randomize_va_space=2 immediately and will also ensure that the setting is applied on the next boot. This setting is currently the default in Ubuntu 14.04.
ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process’s memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range.
Details: V-38597 in STIG Viewer.
Although Red Hat kernels provide ExecShield, Ubuntu provides Non-Executable Memory (NX) support and it is enabled by default. There’s not an option to enable or disable it.
For more information, refer to Ubuntu’s security feature documentation on NX.
This setting will cause the system greeting banner to be used for FTP connections as well.
Details: V-38599 in STIG Viewer.
If the vsftpd package is installed, a login banner will be applied so that users will see if after logging in. This package isn’t installed by default in Ubuntu 14.04 and it isn’t installed by openstack-ansible either.
Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers.
Details: V-38600 in STIG Viewer.
The Ansible tasks will disable the sending of ICMPv4 redirects by setting the sysctl variable net.ipv4.conf.default.send_redirects=0. However, bridging still requires redirects to be enabled, so those interfaces won’t be affected by this change.
Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers.
Details: V-38601 in STIG Viewer.
See the documentation for V-38600 for more details.
Removing the “ypserv” package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.
Details: V-38603 in STIG Viewer.
The nis package is Ubuntu’s equivalent of Red Hat’s ypserv package. The Ansible tasks will remove the nis package if it is installed. To opt-out of this change, adjust the following configuration variable to no:
security_remove_ypserv: no
Disabling the “ypbind” service ensures the system is not acting as a client in a NIS or NIS+ domain.
Details: V-38604 in STIG Viewer.
Exception
The ypbind service is removed as part of V-38603 where the nis package is removed from the system entirely. Since neither Ubuntu nor openstack-ansible install any NIS-related services, this configuration is skipped.
Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential.
Details: V-38605 in STIG Viewer.
The cron service is running by default in Ubuntu and is required for openstack-ansible’s services to function properly. The Ansible tasks in this role will ensure that cron is running and is configured to start at boot time.
Removing the “tftp-server” package decreases the risk of the accidental (or intentional) activation of tftp services.
Details: V-38606 in STIG Viewer.
The tftpd package in Ubuntu will be removed. To opt-out, adjust the following configuration variable to no:
security_remove_tftp_server: no
Disabling the “tftp” service ensures the system is not acting as a tftp server, which does not provide encryption or authentication.
Details: V-38609 in STIG Viewer.
The tftpd service is removed by V-38606 and it is not installed by Ubuntu or openstack-ansible by default. For this reason, it’s recommended to remove the service by using the Ansible task from V-38606.
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.
Details: V-38611 in STIG Viewer.
By default, Ubuntu configures the ssh daemon so that rsh’s .rhosts files are ignored. The Ansible tasks will ensure that this setting hasn’t changed from the default.
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts.
Details: V-38612 in STIG Viewer.
The tasks in sshd.yml will ensure that SSH does not allow host based authentication.
Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root’s password.
Details: V-38613 in STIG Viewer.
Although the STIG recommends disabling root logins via ssh, the default in this role is to allow it. The openstack-ansible deployment uses the root user by default at this time, but that may change later and allow for this configuration to be set.
To disallow root logins via ssh, simply adjust this configuration variable:
ssh_permit_root_login: 'no'
NOTE: The quotes around 'no' or 'yes' are very important. Ansible will treat no and yes as booleans by default and that will cause a True to land in your sshd configuration file. This will causes errors during sshd’s startup.
The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution.
Details: V-38615 in STIG Viewer.
The ssh daemon will be configured so that a warning banner will be displayed after login. To configure the banner, edit the files/login_banner.txt file.
Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.
Details: V-38617 in STIG Viewer.
The ssh daemon will be configured to use the approved list of ciphers as recommended by the STIG.
Unencrypted passwords for remote FTP servers may be stored in ”.netrc” files. DoD policy requires passwords be encrypted in storage and not used in access scripts.
Details: V-38619 in STIG Viewer.
The Ansible tasks will check for .netrc files in /root and /home on the system and print a failure warning if any are found.
Enabling the “ntpd” service ensures that the “ntpd” service will be running and that the system will synchronize its time to any servers specified. This is important whether the system is configured to be a client (and synchronize only its own clock) or it is also acting as an NTP server to other systems. Synchronizing time is essential for authentication services such as Kerberos, but it is also important for maintaining accurate logs and auditing possible security breaches.
Details: V-38620 in STIG Viewer.
The chrony service is installed to manage clock synchronization for hosts and to serve as an NTP server for NTP clients. Chrony was chosen over ntpd because it’s actively maintained and has some enhancements for virtualized environments.
There are two configurations available for users to adjust chrony’s default configuration:
The ntp_servers variable is a list of NTP servers that chrony should use to synchronize time. They are set to North American NTP servers by default.
The allowed_ntp_subnets variable is a list of subnets (in CIDR notation) that are allowed to reach your servers running chrony. A sane default is chosen (all RFC1918 networks are allowed), but this can be easily adjusted.
For more information on chrony, review the chrony documentation at the upstream site, or run man chrony on a host with chrony installed.
Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. Using a trusted NTP server provided by your organization is recommended.
Details: V-38621 in STIG Viewer.
Fixed by another STIG
The Ansible tasks for V-38620 will configure the chrony daemon and allow deployers to specify their NTP servers. Deployers that are subject to US DoD requirements will need to use DoD-approved time servers. Refer to the STIG in the STIG viewer using the link above this “Developer Notes” section.
This ensures “postfix” accepts mail messages (such as cron job reports) from the local system only, and not from the network, which protects it from network attack.
Details: V-38622 in STIG Viewer.
The STIG requires that postfix only listens on the localhost so that it isn’t abused as a mail relay. The Ansible task will adjust the inet_interfaces line in the Postfix configuration and restart postfix if the line is changed.
Although it’s not common, some deployers may need to configure hosts so they can receive email over the network. In that case, deployers would need to set the following Ansible variable:
postfix_inet_interfaces: all
Note that postfix can have inet_interfaces set to localhost and it can still send email on the network. The inet_interfaces directive only controls where postfix listens for incoming email.
For more information, review the postfix documentation for inet_interfaces.
Log files can contain valuable information regarding system configuration. If the system log files are not protected, unauthorized users could change the logged data, eliminating their forensic value.
Details: V-38623 in STIG Viewer.
Ubuntu sets the mode on rsyslog files to 0640 by default, but the STIG requires 0600 or less. The Ansible tasks will adjust the rsyslog configuration so that any new log files will have the mode set to 0600.
This will take effect the next time that log files are rotated with logrotate (configured in V-38624).
The ssl directive specifies whether to use ssl or not. If not specified it will default to “no”. It should be set to “start_tls” rather than doing LDAP over SSL.
Details: V-38625 in STIG Viewer.
Exception
Neither Ubuntu 14.04 or openstack-ansible configures LDAP authentication by default. Deployers that use LDAP authentication for systems are strongly urged to use TLS connectivity between client hosts and LDAP servers to prevent eavesdroppers on the network from reading the authentication attempts as they are made. The certificates on the LDAP server must be trusted by each client.
The tls_cacertdir or tls_cacertfile directives are required when tls_checkpeer is configured (which is the default for openldap versions 2.1 and up). These directives define the path to the trust certificates signed by the site CA.
Details: V-38626 in STIG Viewer.
Exception
Neither Ubuntu 14.04 or openstack-ansible configures LDAP authentication by default. Deployers that use LDAP authentication for systems are strongly urged to use TLS connectivity between client hosts and LDAP servers to prevent eavesdroppers on the network from reading the authentication attempts as they are made. The certificates on the LDAP server must be trusted by each client.
Ensuring the “auditd” service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.
Details: V-38628 in STIG Viewer.
This STIG requirement overlaps with V-38632.
Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby.
Details: V-38629 in STIG Viewer.
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.
Enabling idle activation of the screen saver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area.
Details: V-38630 in STIG Viewer.
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.
Ensuring the “auditd” service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.
Details: V-38631 in STIG Viewer.
This STIG requirement overlaps with V-38632.
Ensuring the “auditd” service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.
Details: V-38632 in STIG Viewer.
The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.
Details: V-38633 in STIG Viewer.
Ubuntu’s default setting for max_log_files matches the STIG requirement of rotating logs when they reach 6MB. The Ansible task for this STIG requirement ensures that the secure default is maintained.
Deployers who want to exceed the STIG guideline can increase the size of logs by adjusting the following Ansible variable:
max_log_file: 6
Automatically rotating logs (by setting this to “rotate”) minimizes the chances of the system unexpectedly running out of disk space by being overwhelmed with log data. However, for systems that must never discard log data, or which use external processes to transfer it and reclaim space, “keep_logs” can be employed.
Details: V-38634 in STIG Viewer.
Ubuntu’s default action for max_log_file_action is to rotate the logs. This meets the STIG requirements and the Ansible task will ensure that the secure default is maintained.
Use caution when changing this option. Certain values, like SUSPEND will cause the audit daemon to lock the machine when the maximum size for a log file is reached. Review the audit documentation carefully before making adjustments.
The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.
Details: V-38636 in STIG Viewer.
Ubuntu keeps 5 rotated logs with the num_logs option and this meets the STIG requirement. The Ansible task will ensure that the secure default is maintained.
Deployers who want to allow logs to grow to larger sizes prior to rotation can adjust the following Ansible variable:
num_logs: 5
The hash on important files like audit system executables should match the information given by the RPM database. Audit executables with erroneous hashes could be a sign of nefarious activity on the system.
Details: V-38637 in STIG Viewer.
The auditd package is verified with debsums and the playbook will fail immediately if any of the files from the auditd package have been altered. This could be the sign of a system compromise.
If the debsums package isn’t installed, the Ansible task will install it during the playbook run.
Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby.
Details: V-38638 in STIG Viewer.
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.
Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files.
Details: V-38643 in STIG Viewer.
Exception
Searching for world-writable files on a host deployed with openstack-ansible can be very time consuming and it can create unneccessary I/O load on hosts. Deployers are urged to check for world-writable files on a regular basis in directories where those files might be a concern (especially web accessible directories).
The command provided with the STIG is helpful for finding these types of files:
find ${MOUNT_POINT} -xdev -type f -perm -002
Running find / isn’t recommended on systems without LVM storage for containers since it will eventually search through the filesystems of the LXC containers that are deployed by openstack-ansible. The -xdev option prevents find from wandering into other mounted filesystems and will prevent it from searching through containers in logical volumes.
Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users.
Details: V-38652 in STIG Viewer.
Exception
Although neither Ubuntu 14.04 or openstack-ansible mount remote filesystems by default, deployers are urged to use the nodev option on any remotely mounted filesystems whenever possible.
NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem.
Details: V-38654 in STIG Viewer.
Exception
Although neither Ubuntu 14.04 or openstack-ansible mount remote filesystems by default, deployers are urged to use the nosuid option on any remotely mounted filesystems whenever possible.
Preventing reuse of previous passwords helps ensure that a compromised password is not reused by a user.
Details: V-38658 in STIG Viewer.
Exception
Making adjustments to PAM configurations via automated methods is risky since it can disrupt user authentication on various hosts. Deployers are strongly urged to rely on ssh keys as opposed to enforcing password complexity and rotation requirements.
Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information.
Details: V-38660 in STIG Viewer.
Although neither Ubuntu 14.04 or openstack-ansible install or configure the SNMP daemon by default, the Ansible tasks will check to see if the SNMP configuration file is present. If the file is present, and the file contains configurations for insecure SNMP protocols, an error will be printed and the playbook will fail.
The task specifically looks for uncommented configuration lines containing:
Red Hat’s guide to SNMP has some example configurations that deployers can use to enable SNMPv3.
Permissions on audit binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated.
Details: V-38663 in STIG Viewer.
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 audit binaries and configuration files that is incorrect could allow an unauthorized user to gain privileges that they should not have. The ownership set by the vendor should be maintained. Any deviations from this baseline should be investigated.
Details: V-38664 in STIG Viewer.
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.
Group-ownership of audit binaries and configuration files that is incorrect could allow an unauthorized user to gain privileges that they should not have. The group-ownership set by the vendor should be maintained. Any deviations from this baseline should be investigated.
Details: V-38665 in STIG Viewer.
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.
Adding host-based intrusion detection tools can provide the capability to automatically take actions in response to malicious behavior, which can provide additional agility in reacting to network threats. These tools also often include a reporting capability to provide network awareness of system, which may not otherwise exist in an organization’s systems management regime.
Details: V-38667 in STIG Viewer.
Fixed by another STIG
The openstack-ansible project already installs and configures AppArmor, which is a Linux Security Module providing similar functionality to SELinux. In addition, AIDE is installed to monitor system files in the Ansible tasks for V-38429.
By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.
Details: V-38670 in STIG Viewer.
The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. Ubuntu will configure the cron job automatically as soon as the package is installed. If the cron job is missing, an error will be printed and the playbook will fail.
The sendmail software was not developed with security in mind and its design prevents it from being effectively contained by SELinux. Postfix should be used instead.
Details: V-38671 in STIG Viewer.
Although neither Ubuntu nor openstack-ansible install or configure sendmail by default, the Ansible task will remove the sendmail package if it exists on the system.
To opt-out of this change, adjust the following Ansible variable to no:
security_remove_sendmail: no
By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.
Details: V-38673 in STIG Viewer.
Exception
Installing AIDE on Ubuntu isn’t an issue, but there’s a bug that causes AIDE to wander into individual LXC infrastructure container filesystems. This causes AIDE runs to take an extremely long time to complete and also adds files into AIDE’s database that shouldn’t be included.
This security configuration will be revisited at a later date.
Unnecessary services should be disabled to decrease the attack surface of the system.
Details: V-38674 in STIG Viewer.
Ubuntu sets the default runlevel in /etc/init/rc-sysinit.conf and it should be set to 2 on Ubuntu systems. The Ansible task will verify that the correct runlevel is set. If the verification fails, an error will be printed and the playbook will fail.
Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.
Details: V-38678 in STIG Viewer.
When auditd notices that free disk space on its logging partition is low, it will trigger the space_left_action. The threshold of remaining disk space is configured by space_left in /etc/audit/auditd.conf.
By default, Ubuntu sets this value to 75 megabytes. The STIG doesn’t set a specific requirement for the exact size, so the Ansible task will ensure that the Ubuntu default of 75 megabytes is set.
DHCP relies on trusting the local network. If the local network is not trusted, then it should not be used. However, the automatic configuration provided by DHCP is commonly used and the alternative, manual configuration, presents an unacceptable burden in many circumstances.
Details: V-38679 in STIG Viewer.
Exception
The DHCP client is needed for containers to function properly and may be needed for some hosts as well. Deployers should examine their networking configuration to verify if DHCP clients can be disabled.
Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action.
Details: V-38680 in STIG Viewer.
By default, Ubuntu sets the default recipient for storage capacity issues in auditd to the root user. The Ansible task ensures that the default remains set.
Deployers are strongly urged to review V-38446 to ensure they have set the root_forward_email variable so that the email system can route these critical notifications to a monitored mailbox.
If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation.
Details: V-38682 in STIG Viewer.
The Ansible task will disable the bluetooth kernel modules to meet the STIG requirements. To opt-out of this change, adjust the following Ansible variable to no:
disable_bluetooth_module: no
NOTE: The module will be disabled on the next system reboot.
In “iptables” the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to “DROP” implements proper design for a firewall, i.e., any packets which are not explicitly permitted should not be accepted.
Details: V-38686 in STIG Viewer.
Exception
Although a minimal set of iptables rules are configured on openstack-ansible hosts, the “deny all” requirement of the STIG is not met. This is largely left up to the deployer to do, based on their assessment of their own network segmentation.
Deployers are urged to review the network access controls that are applied on the network devices between their OpenStack environment and the rest of their network.
An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.
Details: V-38688 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.
An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.
Details: V-38689 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.
Disabling the “bluetooth” service prevents the system from attempting connections to Bluetooth devices, which entails some security risk. Nevertheless, variation in this risk decision may be expected due to the utility of Bluetooth connectivity and its limited range.
Details: V-38691 in STIG Viewer.
Although neither Ubuntu 14.04 or openstack-ansible installs the bluetooth package, the Ansible tasks will disable the service and stop it if it’s found to be running on the system.
To opt-out of this change, adjust the following Ansible variable to no:
security_disable_bluetooth: no
By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.
Details: V-38695 in STIG Viewer.
The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. Ubuntu will configure the cron job automatically as soon as the package is installed. If the cron job is missing, an error will be printed and the playbook will fail.
By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.
Details: V-38696 in STIG Viewer.
The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. Ubuntu will configure the cron job automatically as soon as the package is installed. If the cron job is missing, an error will be printed and the playbook will fail.
By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.
Details: V-38698 in STIG Viewer.
The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. Ubuntu will configure the cron job automatically as soon as the package is installed. If the cron job is missing, an error will be printed and the playbook will fail.
By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.
Details: V-38700 in STIG Viewer.
The AIDE package is already installed as part of the Ansible tasks to fix V-38429, but these Ansible tasks will verify that the cron job file is actually in place. Ubuntu will configure the cron job automatically as soon as the package is installed. If the cron job is missing, an error will be printed and the playbook will fail.
Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to quickly enumerate known user accounts without logging in.
Details: V-43150 in STIG Viewer.
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.
Disabling a major host protection feature, such as SELinux, at boot time prevents it from confining system services at boot time. Further, it increases the chances that it will remain off during system operation.
Details: V-51337 in STIG Viewer.
Opt-in required
The tasks in the security role can enable the Linux Security Module (LSM) that is appropriate for the Linux distribution in use. For Ubuntu, the default LSM is AppArmor. Refer to Ubuntu’s AppArmor documentation for more details on how AppArmor works.
Deployers can opt in for this change by setting the following Ansible variable:
security_enable_linux_security_module: yes
Setting the variable to yes will run the tasks that enable AppArmor.
Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges.
Details: V-51363 in STIG Viewer.
The openstack-ansible project configures AppArmor to limit the actions of containers and reduce the changes (and potential damages) of a container breakout. The RHEL 6 STIG mentions SELinux but the existing SELinux policies provided with Ubuntu aren’t as well maintained as those provided with RHEL.
For AIDE to be effective, an initial database of “known-good” information about files must be captured and it should be able to be verified against the installed files.
Details: V-51391 in STIG Viewer.
When AIDE is first installed for V-38429, a new database will be created. The creation process takes some time because AIDE needs to review each file in its list of monitored files to get timestamps and hashes. The initialization will be forked into the background so that it doesn’t slow down the playbook run.
Some directories are excluded from AIDE runs to prevent AIDE from wandering into directories where it shouldn’t be hashing/monitoring files. The defaults/main.yml file has some recommended directories as part of the aide_exclude_dirs variable.
Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.
Details: V-51875 in STIG Viewer.
Ubuntu 14.04 already enables the display of the last successful login for a user immediately after login. An Ansible task ensures this setting is applied and restarts the ssh daemon if necessary.
Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur.
Details: V-54381 in STIG Viewer.
Exception
The STIG requires that the audit system must switch the entire system into single-user mode when the space for logging becomes dangerously low.
This will cause serious service disruptions for any environment and should only be enabled for extremely high security environments.
Ubuntu sets admin_space_left_action to SUSPEND by default, and this will cause logging to be temporarily suspended until disk space is freed.
For extremely high security environments, this Ansible variable can be provided to meet the requirements of the STIG:
admin_space_left_action: SINGLE
Allowing users to execute binaries from world-writable directories such as “/tmp” should never be necessary in normal operation and can expose the system to potential compromise.
Details: V-57569 in STIG Viewer.
Exception
Altering partitions and how they are mounted is left up to the deployer to configure during the OS installation process. Mounting /tmp/ with the noexec option is highly recommended to prevent scripts or binaries from being executed from /tmp.
The “sudo” command allows authorized users to run programs (including shells) as other users, system users, and root. The “/etc/sudoers” file is used to configure authorized “sudo” users as well as the programs they are allowed to run. Some configuration options in the “/etc/sudoers” file allow configured users to run programs without re-authenticating. Use of these configuration options makes it easier for one compromised account to be used to compromise other accounts.
Details: V-58901 in STIG Viewer.
This STIG requires that NOPASSWD and !authenticate are not used within the sudoers configuration files. Using these directives reduces the security of the system.
NOPASSWD allows users to run commands as root without providing a password first. Using !authenticate with the Defaults directive will disable password usage for any users which use sudo.
There are two configuration options for handling these changes. By default, both of these options are set to no, which means that the sudoers configuration files will not be altered:
sudoers_remove_nopasswd: no
sudoers_remove_authenticate: no
Setting sudoers_remove_nopasswd to yes will cause the Ansible tasks to search for any lines containing NOPASSWD and comment them out of the configuration. Setting sudoers_remove_authenticate will do the same actions on lines containing !authenticate. Lines that are already commented will be left unaltered.