Home » Security hardening for openstack-ansible

Category 2 (Medium) controls

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

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

Details: V-38439 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38443 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38444 in STIG Viewer.

Notes for deployers

Exception

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

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

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

Details: V-38445 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38446 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38448 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38449 in STIG Viewer.

Notes for deployers

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

V-38450: The /etc/passwd file must be owned by 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-38450 in STIG Viewer.

Notes for deployers

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

V-38451: The /etc/passwd file must be group-owned by 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.

Notes for deployers

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

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

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

Details: V-38457 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38458 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38459 in STIG Viewer.

Notes for deployers

The tasks in file_perms.yml will ensure that /etc/group is owned by the root account.

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

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

Details: V-38461 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38464 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38465 in STIG Viewer.

Notes for deployers

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.

V-38466: Library files must be owned by root.

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

Details: V-38466 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38468 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38469 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38470 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38472 in STIG Viewer.

Notes for deployers

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.

V-38475: The system must require passwords to contain a minimum of 14 characters.

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

Details: V-38475 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38477 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38479 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38481 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38483 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38484 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38486 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38488 in STIG Viewer.

Notes for deployers

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.

V-38489: A file integrity tool must be installed.

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

Details: V-38489 in STIG Viewer.

Notes for deployers

The aide package will be installed by Ansible tasks.

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

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

Details: V-38490 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38492 in STIG Viewer.

Notes for deployers

The virtual consoles mentioned in V-38492 aren’t used in Ubuntu 14.04 by default.

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

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

Details: V-38493 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38495 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38496 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38498 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38499 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38500 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38501 in STIG Viewer.

Notes for deployers

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

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

Deployers must opt-in for fail2ban to be installed and configured. To opt-in, set the 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.

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

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

Details: V-38502 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38503 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38504 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38511 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38512 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38513 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38514 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38515 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38517 in STIG Viewer.

Notes for deployers

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.

V-38518: All rsyslog-generated log files must be owned by 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-38518 in STIG Viewer.

Notes for deployers

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.

V-38519: All rsyslog-generated log files must be group-owned by 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.

Notes for deployers

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.

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

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

Details: V-38520 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38521 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38523 in STIG Viewer.

Notes for deployers

Exception

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

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

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

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

Details: V-38524 in STIG Viewer.

Notes for deployers

Exception

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

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

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

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

Details: V-38526 in STIG Viewer.

Notes for deployers

Exception

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

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

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

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

Details: V-38529 in STIG Viewer.

Notes for deployers

Exception

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

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

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

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

Details: V-38532 in STIG Viewer.

Notes for deployers

Exception

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

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

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

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

Details: V-38539 in STIG Viewer.

Notes for deployers

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:

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

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

Details: V-38542 in STIG Viewer.

Notes for deployers

Exception

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

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

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

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

Details: V-38544 in STIG Viewer.

Notes for deployers

Exception

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

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

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

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

Details: V-38546 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38548 in STIG Viewer.

Notes for deployers

Exception

Disabling IPv6 redirects can cause issues with OpenStack environments which have IPv6 enabled and are routing IPv6 traffic.

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

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

Details: V-38549 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38551 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38553 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38555 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38560 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38573 in STIG Viewer.

Notes for deployers

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

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

Deployers must opt-in for fail2ban to be installed and configured. To opt-in, set the 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.

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

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

Details: V-38574 in STIG Viewer.

Notes for deployers

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:

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

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

Details: V-38576 in STIG Viewer.

Notes for deployers

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:

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

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

Details: V-38577 in STIG Viewer.

Notes for deployers

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:

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

Further reading:

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

Only root should be able to modify important boot parameters.

Details: V-38579 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38580 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38581 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38582 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38583 in STIG Viewer.

Notes for deployers

The permissions on /boot/grub/grub.cfg will be set to 0644.

V-38585: The system boot loader must require authentication.

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

Details: V-38585 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38586 in STIG Viewer.

Notes for deployers

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.

V-38588: The system must not permit interactive boot.

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

Details: V-38588 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38592 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38593 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38595 in STIG Viewer.

Notes for deployers

Exception

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

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

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

Details: V-38596 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38597 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38599 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38600 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38601 in STIG Viewer.

Notes for deployers

See the documentation for V-38600 for more details.

V-38603: The ypserv package must not be installed.

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

Details: V-38603 in STIG Viewer.

Notes for deployers

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

V-38604: The ypbind service must not be running.

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

Details: V-38604 in STIG Viewer.

Notes for deployers

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.

V-38605: The cron service must be running.

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

Details: V-38605 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38606 in STIG Viewer.

Notes for deployers

The tftpd package in Ubuntu will be removed. To opt-out, adjust the following configuration variable to no:

security_remove_tftp_server: no

V-38609: The TFTP service must not be running.

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

Details: V-38609 in STIG Viewer.

Notes for deployers

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.

V-38611: The SSH daemon must ignore .rhosts files.

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

Details: V-38611 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38612 in STIG Viewer.

Notes for deployers

The tasks in sshd.yml will ensure that SSH does not allow host based authentication.

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

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

Details: V-38613 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38615 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38617 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38619 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38620 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38621 in STIG Viewer.

Notes for deployers

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.

V-38622: Mail relaying must be restricted.

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

Details: V-38622 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38623 in STIG Viewer.

Notes for deployers

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

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

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.

Notes for deployers

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.

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

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

Details: V-38626 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38628 in STIG Viewer.

Notes for deployers

This STIG requirement overlaps with V-38632.

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

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

Details: V-38629 in STIG Viewer.

Notes for deployers

Exception

Neither Ubuntu or openstack-ansible installs a graphical desktop by default. Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

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

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

Details: V-38630 in STIG Viewer.

Notes for deployers

Exception

Neither Ubuntu or openstack-ansible installs a graphical desktop by default. Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

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

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

Details: V-38631 in STIG Viewer.

Notes for deployers

This STIG requirement overlaps with V-38632.

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

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

Details: V-38632 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38633 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38634 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38636 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38637 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38638 in STIG Viewer.

Notes for deployers

Exception

Neither Ubuntu or openstack-ansible installs a graphical desktop by default. Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

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

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

Details: V-38643 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38652 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38654 in STIG Viewer.

Notes for deployers

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.

V-38658: The system must prohibit the reuse of passwords within twenty-four iterations.

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

Details: V-38658 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38660 in STIG Viewer.

Notes for deployers

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:

  • v1
  • v2c
  • com2sec
  • community

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

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

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

Details: V-38663 in STIG Viewer.

Notes for deployers

Exception

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

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

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

Details: V-38664 in STIG Viewer.

Notes for deployers

Exception

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

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

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

Details: V-38665 in STIG Viewer.

Notes for deployers

Exception

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

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

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

Details: V-38667 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38670 in STIG Viewer.

Notes for deployers

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.

V-38671: The sendmail package must be removed.

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

Details: V-38671 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38673 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38674 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38678 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38679 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38680 in STIG Viewer.

Notes for deployers

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.

V-38682: The Bluetooth kernel module must be disabled.

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

Details: V-38682 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38686 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38688 in STIG Viewer.

Notes for deployers

Exception

Neither Ubuntu or openstack-ansible installs a graphical desktop by default. Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

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

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

Details: V-38689 in STIG Viewer.

Notes for deployers

Exception

Neither Ubuntu or openstack-ansible installs a graphical desktop by default. Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

V-38691: The Bluetooth service must be disabled.

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

Details: V-38691 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-38695 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38696 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38698 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-38700 in STIG Viewer.

Notes for deployers

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.

V-43150: The login user list must be disabled.

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

Details: V-43150 in STIG Viewer.

Notes for deployers

Exception

Neither Ubuntu or openstack-ansible installs a graphical desktop by default. Deployers are urged to use graphical desktops only on client machines that connect to the OpenStack environment, rather than configuring graphical desktops within the OpenStack infrastructure itself.

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

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

Details: V-51337 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-51363 in STIG Viewer.

Notes for deployers

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.

V-51391: A file integrity baseline must be created.

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

Details: V-51391 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-51875 in STIG Viewer.

Notes for deployers

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.

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

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

Details: V-54381 in STIG Viewer.

Notes for deployers

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

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

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

Details: V-57569 in STIG Viewer.

Notes for deployers

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.

V-58901: The sudo command must require authentication.

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

Details: V-58901 in STIG Viewer.

Notes for deployers

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.

Table Of Contents

Previous topic

Category 1 (Low) controls

Next topic

Category 3 (High) controls

Project Source

This Page