STIG Controls by Severity¶

Contents

STIG Controls by Severity

High (29 controls)¶

The file permissions, ownership, and group membership of system files and commands must match the vendor values. (V-71849)¶

STIG Description¶

Severity: High

Discretionary access control is weakened if a user or group has access permissions to system files and directories greater than the default.

Satisfies: SRG-OS-000257-GPOS-00098, SRG-OS-000278-GPOS-00108

Deployer/Auditor notes¶

Implementation Status: Opt-In

Note

Ubuntu’s debsums command does not support verification of permissions and ownership for files that were installed by packages. This STIG requirement will be skipped on Ubuntu.

The STIG requires that all files owned by an installed package must have their permissions, user ownership, and group ownership set back to the vendor defaults.

Although this is a good practice, it can cause issues if permissions or ownership were intentionally set after the packages were installed. It also causes significant delays in deployments. Therefore, this STIG is not applied by default.

Deployers may opt in for the change by setting the following Ansible variable:

security_reset_perm_ownership: yes

The cryptographic hash of system files and commands must match vendor values. (V-71855)¶

STIG Description¶

Severity: High

Without cryptographic integrity protections, system command and files can be altered by unauthorized users without detection.

Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the key used to generate the hash.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Ansible tasks will check the rpm -Va output (on CentOS, RHEL, openSUSE and SLE) or the output of debsums (on Ubuntu) to see if any files installed from packages have been altered. The tasks will print a list of files that have changed since their package was installed.

Deployers should be most concerned with any checksum failures for binaries and their libraries. These are most often a sign of system compromise or poor system administration practices.

Configuration files may appear in the list as well, but these are often less concerning since some of these files are adjusted by the security role itself.

Generating and validating checksums of all files installed by packages consume a significant amount of disk I/O and could impact the performance of a production system. It can also delay the playbook’s completion. Therefore, the check is disabled by default.

Deployers can enable the check by setting the following Ansible variable:

security_check_package_checksums: yes

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

STIG Description¶

Severity: High

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

Deployer/Auditor notes¶

Implementation Status: Implemented

The Ansible tasks will ensure that PAM is configured to disallow logins from accounts with null or blank passwords. This involves removing a single option from one of the PAM configuration files:

CentOS or RHEL: removes nullok from /etc/pam.d/system-auth
Ubuntu: removes nullok_secure from /etc/pam.d/common-auth
openSUSE Leap or SLE: remove nullok from /etc/pam.d/common-auth and /etc/pam.d/common-password

Deployers can opt-out of this change by setting the following Ansible variable:

security_disallow_blank_password_login: no

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

STIG Description¶

Severity: High

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

Deployer/Auditor notes¶

Implementation Status: Implemented

The PermitEmptyPasswords configuration will be set to no in /etc/ssh/sshd_config and sshd will be restarted. This disallows logins over ssh for users with a empty or null password set.

Deployers can opt-out of this change by setting the following Ansible variable:

security_sshd_disallow_empty_password: no

The operating system must not allow an unattended or automatic logon to the system via a graphical user interface. (V-71953)¶

STIG Description¶

Severity: High

Failure to restrict system access to authenticated users negatively impacts operating system security.

Deployer/Auditor notes¶

Implementation Status: Implemented

If AutomaticLoginEnable=true exists in the gdm configuration file, /etc/gdm/custom.conf, the configuration will removed. This disallows automatic logins for gdm and requires a user to complete the username and password prompts.

Deployers can opt-out of this change by setting an Ansible variable:

security_disable_gdm_automatic_login: no

The operating system must not allow an unrestricted logon to the system. (V-71955)¶

STIG Description¶

Severity: High

Failure to restrict system access to authenticated users negatively impacts operating system security.

Deployer/Auditor notes¶

Implementation Status: Implemented

If TimedLoginEnable=true exists in the gdm configuration file, /etc/gdm/custom.conf, the configuration will removed. This disallows timed logins for guest users in gdm.

Deployers can opt-out of this change by setting an Ansible variable:

security_disable_gdm_timed_login: no

Systems with a Basic Input/Output System (BIOS) must require authentication upon booting into single-user and maintenance modes. (V-71961)¶

STIG Description¶

Severity: High

If the system does not require valid root authentication before it boots into single-user or maintenance mode, anyone who invokes single-user or maintenance mode is granted privileged access to all files on the system. GRUB 2 is the default boot loader for RHEL 7 and is designed to require a password to boot into single-user mode or make modifications to the boot menu.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that GRUB 2 asks for a password whenever a user attempts to enter single-user or maintenance mode, this change might be disruptive in an emergency situation. Therefore, this change is not applied by default.

Deployers that wish to opt in for this change should set two Ansible variables:

security_require_grub_authentication: yes
security_grub_password_hash: grub.pbkdf2.sha512.10000.7B21785BEAFEE3AC...

The default password set in the security role is ‘secrete’, but deployers should set a much more secure password for production environments. Use the grub2-mkpasswd-pbkdf2 command to create a password hash string and use it as the value for the Ansible variable security_grub_password_hash.

Warning

This change must be tested in a non-production environment first. Requiring authentication in GRUB 2 without proper communication to users could cause extensive delays in emergency situations.

Systems using Unified Extensible Firmware Interface (UEFI) must require authentication upon booting into single-user and maintenance modes. (V-71963)¶

STIG Description¶

Severity: High

Deployer/Auditor notes¶

Implementation Status: Opt-In

The tasks in the security role for V-71961 will also apply changes to systems that use UEFI. For more details, refer to the following documentation:

Systems with a Basic Input/Output System (BIOS) must require authentication upon booting into single-user and maintenance modes. (V-71961)

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

STIG Description¶

Severity: High

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).

The rsh-server service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication.

If a privileged user were to log on using this service, the privileged user password could be compromised.

Deployer/Auditor notes¶

Implementation Status: Implemented

The role will remove the rsh-server package from the system if it is installed. Deployers can opt-out of this change by setting the following Ansible variable:

security_rhel7_remove_rsh_server: no

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

STIG Description¶

Severity: High

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

Deployer/Auditor notes¶

Implementation Status: Implemented

The role will remove the NIS server package from the system if it is installed. The package name differs between Linux distributions:

CentOS: ypserv
Ubuntu: nis
openSUSE Leap: ypserv

Deployers can opt-out of this change by setting the following Ansible variable:

security_rhel7_remove_ypserv: no

The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components from a repository without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. (V-71977)¶

STIG Description¶

Severity: High

Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor.

Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.

Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should not have to verify the software again. This requirement does not mandate DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved CA.

Deployer/Auditor notes¶

Implementation Status: Implemented

On Ubuntu systems, the tasks check for the AllowUnauthenticated string anywhere in the apt configuration files found within /etc/apt/apt.conf.d/. If the string is found, a warning is printed on the console.

On CentOS 7 systems, the tasks set the gpgcheck option to 1 in the /etc/yum.conf file. This enables GPG checks for all packages installed with yum.

On openSUSE Leap systems, the tasks set the gpgcheck option to 1 in the /etc/zypp/zypp.conf file. This enables GPG checks for all packages installed with zypper.

Setting security_enable_gpgcheck_packages to no will skip the AllowUnauthenticated string check on Ubuntu and it will set gpgcheck=0 in /etc/yum.conf or /etc/zypp/zypp.conf on CentOS and openSUSE Leap systems respectively.

The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. (V-71979)¶

STIG Description¶

Severity: High

Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.

Deployer/Auditor notes¶

Implementation Status: Implemented

On Ubuntu systems, the tasks comment out the no-debsig configuration line in /etc/dpkg/dpkg.cfg. This causes dpkg to verify GPG signatures for all packages that are installed locally.

On CentOS 7 systems, the tasks set the localpkg_gpgcheck option to 1 in the /etc/yum.conf file. This enables GPG checks for all packages installed locally with yum.

On openSUSE Leap systems, the tasks set the gpgcheck option to 1 in the /etc/zypp/zypp.conf file. This enables GPG checks for all packages installed with zypper.

Setting security_enable_gpgcheck_packages_local to no will skip the no-debsig adjustment on Ubuntu and it will set local_gpgcheck=0 in /etc/yum.conf on CentOS systems. Similarly, on openSUSE Leap systems, it will set gpgcheck=0 in /etc/zypp/zypp.conf.

The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of packages without verification of the repository metadata. (V-71981)¶

STIG Description¶

Severity: High

Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.

Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should not have to verify the software again. This requirement does not mandate DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved Certificate Authority.

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that repository XML files are verified during yum runs.

Warning

This setting is disabled by default because it can cause issues with CentOS systems and prevent them from retrieving repository information. Deployers who choose to enable this setting should test it thoroughly on non-production environments before applying it to production systems.

Deployers can override this default and opt in for the change by setting the following Ansible variable:

security_enable_gpgcheck_repo: yes

The operating system must enable SELinux. (V-71989)¶

STIG Description¶

Severity: High

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality.

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role enable the appropriate Linux Security Module (LSM) for the operating system.

For Ubuntu, openSUSE and SUSE Linux Enterprise 12 systems, AppArmor is installed and enabled. This change takes effect immediately.

For CentOS or Red Hat Enterprise Linux systems, SELinux is enabled (in enforcing mode) and its user tools are automatically installed. If SELinux is not in enforcing mode already, a reboot is required to enable SELinux and relabel the filesystem.

Warning

Relabeling a filesystem takes time and the server must be offline for the relabeling to complete. Filesystems with large amounts of files and filesystems on slow disks will cause the relabeling process to take more time.

Deployers can opt out of this change by setting the following Ansible variable:

security_rhel7_enable_linux_security_module: no

The operating system must enable the SELinux targeted policy. (V-71991)¶

STIG Description¶

Severity: High

This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality.

Deployer/Auditor notes¶

Implementation Status: Implemented

The SELinux targeted policy is enabled on CentOS 7 and Red Hat systems. AppArmor only has one set of policies, so this change has no effect on Ubuntu, openSUSE Leap and SUSE systems running AppArmor.

For more information on this change and how to opt out, refer to The operating system must enable SELinux. (V-71989).

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

STIG Description¶

Severity: High

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

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role disable the control-alt-delete key sequence by masking its systemd service unit.

Deployers can opt out of this change by setting the following Ansible variable:

security_rhel7_disable_ctrl_alt_delete: no

The operating system must be a vendor supported release. (V-71997)¶

STIG Description¶

Severity: High

An operating system release is considered “supported” if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

The STIG requires that the current release of the operating system is still supported and is actively receiving security updates. Deployers are urged to stay current with the latest releases from Ubuntu, SUSE, CentOS and Red Hat.

The following links provide more details on end of life (EOL) dates for the distributions supported by this role:

The root account must be the only account having unrestricted access to the system. (V-72005)¶

STIG Description¶

Severity: High

If an account other than root also has a User Identifier (UID) of “0”, it has root authority, giving that account unrestricted access to the entire operating system. Multiple accounts with a UID of “0” afford an opportunity for potential intruders to guess a password for a privileged account.

Deployer/Auditor notes¶

Implementation Status: Implemented

If an account with UID 0 other than root exists on the system, the playbook will fail with an error message that includes the other accounts which have a UID of 0.

Deployers are strongly urged to keep only one account with UID 0, root, and to use sudo any situations where root access is required.

The operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect data requiring data-at-rest protections in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. (V-72067)¶

STIG Description¶

Severity: High

Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000185-GPOS-00079, SRG-OS-000396-GPOS-00176, SRG-OS-000405-GPOS-00184, SRG-OS-000478-GPOS-00223

Deployer/Auditor notes¶

Implementation Status: Implemented - Red Hat And Suse Only

The tasks in the Ansible role install the dracut-fips (RHEL and SLE) and dracut-fips-aesni (RHEL) packages and check to see if FIPS is enabled on the system. If it is not enabled, a warning message is printed in the Ansible output.

Enabling FIPS at boot time requires additional manual configuration. Refer to Chapter 7. Federal Standards and Regulations in the Red Hat documentation for more details. Section 7.1.1 contains the steps required for updating the bootloader configuration and regenerating the initramfs.

Note

This change only applies to CentOS, Red Hat Enterprise Linux, openSUSE Leap and SUSE Linux Enterprise. Ubuntu does not use dracut by default and the process for enabling the FIPS functionality at boot time is more complex.

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

STIG Description¶

Severity: High

Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled.

Deployer/Auditor notes¶

Implementation Status: Implemented

The role will remove the telnet server package from the system if it is installed. The package name differs between Linux distributions:

CentOS: telnet-server
Ubuntu: telnetd
openSUSE Leap: telnet-server

Deployers can opt-out of this change by setting the following Ansible variable:

security_rhel7_remove_telnet_server: no

Auditing must be configured to produce records containing information to establish what type of events occurred, where the events occurred, the source of the events, and the outcome of the events.

These audit records must also identify individual identities of group account users. (V-72079)¶

STIG Description¶

Severity: High

Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.

Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Associating event types with detected events in the operating system audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.

Satisfies: SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000042-GPOS-00021, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role start the audit daemon immediately and ensure that it starts at boot time.

The system must use a virus scan program. (V-72213)¶

STIG Description¶

Severity: High

Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems.

The virus scanning software should be configured to perform scans dynamically on accessed files. If this capability is not available, the system must be configured to scan, at a minimum, all altered files on the system on a daily basis.

If the system processes inbound SMTP mail, the virus scanner must be configured to scan all received mail.

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that a virus scanner is installed and running, but the value of a virus scanner within an OpenStack control plane or on a hypervisor is negligible in many cases. In addition, the disk I/O impact of a virus scanner can impact a production environment negatively.

The security role has tasks to deploy ClamAV with automatic updates, but the tasks are disabled by default.

Deployers can enable the ClamAV virus scanner by setting the following Ansible variable:

security_enable_virus_scanner: yes

Warning

The ClamAV packages are provided in the EPEL repository. Setting the security_enable_virus_scanner will also cause the EPEL repository to be installed by the role.

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

STIG Description¶

Severity: High

SSHv1 is an insecure implementation of the SSH protocol and has many well-known vulnerability exploits. Exploits of the SSH daemon could provide immediate root access to the system.

Satisfies: SRG-OS-000074-GPOS-00042, SRG-OS-000480-GPOS-00227

Deployer/Auditor notes¶

Implementation Status: Implemented

The Protocol configuration is set to 2 in /etc/ssh/sshd_config and sshd is restarted.

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_protocol: 2

Warning

There is no reason to enable any other protocol than SSHv2. SSHv1 has multiple vulnerabilities, and it is no longer widely used.

There must be no .shosts files on the system. (V-72277)¶

STIG Description¶

Severity: High

The .shosts files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.

Deployer/Auditor notes¶

Implementation Status: Opt-In

The tasks in the security role examine the filesystem for any .shosts or shosts.equiv files. If they are found, they are deleted.

The search for these files will take a very long time on systems with slow disks or systems with a large amount of files. Therefore, this task is skipped by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_remove_shosts_files: yes

There must be no shosts.equiv files on the system. (V-72279)¶

STIG Description¶

Severity: High

The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

There must be no .shosts files on the system. (V-72277)

A File Transfer Protocol (FTP) server package must not be installed unless needed. (V-72299)¶

STIG Description¶

Severity: High

The FTP service provides an unencrypted remote access that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised. SSH or other encrypted file transfer methods must be used in place of this service.

Deployer/Auditor notes¶

Implementation Status: Not Implemented

This STIG is not yet implemented.

The Trivial File Transfer Protocol (TFTP) server package must not be installed if not required for operational support. (V-72301)¶

STIG Description¶

Severity: High

If TFTP is required for operational support (such as the transmission of router configurations) its use must be documented with the Information System Security Officer (ISSO), restricted to only authorized personnel, and have access control rules established.

Deployer/Auditor notes¶

Implementation Status: Implemented

The role will remove the TFTP server package from the system if it is installed. The package name differs between Linux distributions:

CentOS: tftp-server
Ubuntu: tftpd
openSUSE Leap: tftp

Deployers can opt-out of this change by setting the following Ansible variable:

security_rhel7_remove_tftp_server: no

Remote X connections for interactive users must be encrypted. (V-72303)¶

STIG Description¶

Severity: High

Open X displays allow an attacker to capture keystrokes and execute commands remotely.

Deployer/Auditor notes¶

Implementation Status: Implemented

The X11Forwarding configuration is set to yes in /etc/ssh/sshd_config and sshd is restarted.

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_enable_x11_forwarding: no

SNMP community strings must be changed from the default. (V-72313)¶

STIG Description¶

Severity: High

Whether active or not, default Simple Network Management Protocol (SNMP) community strings must be changed to maintain security. If the service is running with the default authenticators, anyone can gather data about the system and the network and use the information to potentially compromise the integrity of the system or network(s). It is highly recommended that SNMP version 3 user authentication and message encryption be used in place of the version 2 community strings.

Deployer/Auditor notes¶

Implementation Status: Verification Only

The tasks in the security role examine the contents of the /etc/snmp/snmpd.conf file (if it exists) and search for the default community strings: public and private. If either default string is found, a message is printed in the Ansible output.

Medium (198 controls)¶

The operating system must enable a user session lock until that user re-establishes access using established identification and authentication procedures. (V-71891)¶

STIG Description¶

Severity: Medium

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence.

The session lock is implemented at the point where session activity can be determined.

Regardless of where the session lock is determined and implemented, once invoked, the session lock must remain in place until the user reauthenticates. No other activity aside from reauthentication must unlock the system.

Satisfies: SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011

Deployer/Auditor notes¶

Implementation Status: Implemented

The STIG requires that graphical sessions are locked when the screensaver starts and that users must re-enter credentials to restore access to the system. The screensaver lock is enabled by default if dconf is present on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_lock_session: no

The operating system must initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. (V-71893)¶

STIG Description¶

Severity: Medium

A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not log out because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, operating systems need to be able to identify when a user’s session has idled and take action to initiate the session lock.

The session lock is implemented at the point where session activity can be determined and/or controlled.

Deployer/Auditor notes¶

Implementation Status: Implemented

The STIG requires that the screensaver appears when a session reaches a certain period of inactivity. The tasks will enable the screensaver for inactive sessions by default.

Deployers can opt out of this change by setting an Ansible variable:

security_lock_session_when_inactive: no

The operating system must set the idle delay setting for all connection types. (V-71895)¶

STIG Description¶

Severity: Medium

The session lock is implemented at the point where session activity can be determined and/or controlled.

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control. Refer to the documentation for more details on the change and how to opt out:

The operating system must initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. (V-71893)

The operating system must have the screen package installed. (V-71897)¶

STIG Description¶

Severity: Medium

The screen package allows for a session lock to be implemented and configured.

Deployer/Auditor notes¶

Implementation Status: Implemented

The role will ensure that the screen package is installed.

The operating system must initiate a session lock for the screensaver after a period of inactivity for graphical user interfaces. (V-71899)¶

STIG Description¶

Severity: Medium

The session lock is implemented at the point where session activity can be determined and/or controlled.

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control. Refer to the documentation for more details on the change and how to opt out:

The operating system must initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. (V-71893)

The operating system must initiate a session lock for graphical user interfaces when the screensaver is activated. (V-71901)¶

STIG Description¶

Severity: Medium

The session lock is implemented at the point where session activity can be determined and/or controlled.

Deployer/Auditor notes¶

Implementation Status: Implemented

The STIG requires that a graphical session is locked when the screensaver starts. This requires a user to re-enter their credentials to regain access to the system.

The tasks will set a timeout of 5 seconds after the screensaver has started before the session is locked. This gives a user a few seconds to press a key or wiggle their mouse after the screensaver appears without needing to re-enter their credentials.

Deployers can adjust this timeout by setting an Ansible variable:

security_lock_session_screensaver_lock_delay: 5

When passwords are changed or new passwords are established, the new password must contain at least one upper-case character. (V-71903)¶

STIG Description¶

Severity: Medium

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Deployer/Auditor notes¶

Implementation Status: Opt-In

The password quality requirements from the STIG are examples of good security practice, but deployers are strongly encouraged to use centralized authentication for administrative server access whenever possible.

Password quality requirements are controlled by two Ansible variables: one for each individual password requirement and one “master switch” variable. The master switch variable controls all password requirements and it is disabled by default.

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_require_uppercase: no

When passwords are changed or new passwords are established, the new password must contain at least one lower-case character. (V-71905)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_require_lowercase: no

When passwords are changed or new passwords are assigned, the new password must contain at least one numeric character. (V-71907)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_require_numeric: no

When passwords are changed or new passwords are assigned, the new password must contain at least one special character. (V-71909)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_require_special: no

When passwords are changed a minimum of eight of the total number of characters must be changed. (V-71911)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_require_characters_changed: no

When passwords are changed a minimum of four character classes must be changed. (V-71913)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_require_character_classes_changed: no

When passwords are changed the number of repeating consecutive characters must not be more than three characters. (V-71915)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_limit_repeated_characters: no

When passwords are changed the number of repeating characters of the same character class must not be more than four characters. (V-71917)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can enable all password quality requirements by setting the master switch variable to yes:

security_pwquality_apply_rules: yes

When the master switch variable is enabled, each individual password quality requirement can be disabled by a variable. To disable the fix for this STIG control, set the following Ansible variable:

security_pwquality_limit_repeated_character_classes: no

The PAM system service must be configured to store only encrypted representations of passwords. (V-71919)¶

STIG Description¶

Severity: Medium

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords encrypted with a weak algorithm are no more protected than if they are kept in plain text.

Deployer/Auditor notes¶

Implementation Status: Implemented

The PAM configuration file for password storage is checked to ensure that sha512 is found on the pam_unix.so line. If sha512 is not found, a debug message is printed in the Ansible output.

The shadow file must be configured to store only encrypted representations of passwords. (V-71921)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

The default password storage mechanism for Ubuntu 16.04, CentOS 7, openSUSE Leap, SUSE Linux Enterprise 12 and Red Hat Enterprise Linux 7 is SHA512 and the tasks in the security role ensure that the default is maintained.

Deployers can configure a different password storage mechanism by setting the following Ansible variable:

security_password_encrypt_method: SHA512

Warning

SHA512 is the default on most modern Linux distributions and it meets the requirement of the STIG. Do not change the value unless a system has a specific need for a different password mechanism.

User and group account administration utilities must be configured to store only encrypted representations of passwords. (V-71923)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented - Red Hat Only

The role ensures that crypt_style is set to sha512 in /etc/libuser.conf, which is the default for CentOS 7 and Red Hat Enterprise Linux 7.

Ubuntu, openSUSE and SUSE Linux Enterprise 12 do not use libuser, so this change is not applicable.

Deployers can opt out of this change by setting the following Ansible variable:

security_libuser_crypt_style_sha512: no

Passwords for new users must be restricted to a 24 hours/1 day minimum lifetime. (V-71925)¶

STIG Description¶

Severity: Medium

Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, the password could be repeatedly changed in a short period of time to defeat the organization’s policy regarding password reuse.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that all passwords have a minimum lifetime set, this can cause issue in some production environments. Therefore, deployers must opt in for this change.

Set the following Ansible variable to an integer (in days) to enable this setting:

security_password_min_lifetime_days: 1

The STIG requires the minimum lifetime for password to be one day.

Passwords must be restricted to a 24 hours/1 day minimum lifetime. (V-71927)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Setting a minimum password lifetime on interactive user accounts provides security benefits by limiting the frequency of password changes. However, this can cause login problems for users without proper communication and coordination.

Deployers can opt-in for this change by setting the following Ansible variable:

security_set_minimum_password_lifetime: yes

The tasks will examine each interactive user account and set the minimum password age if the existing setting is not equal to one day.

Passwords for new users must be restricted to a 60-day maximum lifetime. (V-71929)¶

STIG Description¶

Severity: Medium

Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that all passwords have a maximum lifetime set, this can cause authentication disruptions in production environments if users are not aware that their password will expire. Therefore, this change is not applied by default.

Deployers can opt in for this change and provide a maximum lifetime for user passwords (in days) by setting the following Ansible variable:

security_password_max_lifetime_days: 60

The STIG requires that all passwords expire after 60 days.

Existing passwords must be restricted to a 60-day maximum lifetime. (V-71931)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that a maximum password lifetime is set for all interactive user accounts, the security benefits of this configuration are debatable. The draft of NIST Publication 800-63B argues that password rotation may reduce overall security in some situations.

Deployers can opt-in for this change by setting the following Ansible variable:

security_set_maximum_password_lifetime: yes

The tasks will examine each interactive user account and set the maximum password age if the existing setting is not equal to 60 days.

Passwords must be prohibited from reuse for a minimum of five generations. (V-71933)¶

STIG Description¶

Severity: Medium

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed per policy requirements.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that five passwords are remembered to prevent re- use, this can cause issues in production environment if the change is not communicated well to users. Therefore, the tasks in the security role do not apply this change by default.

Deployers can opt in for the change and specify a number of passwords to remember by setting the following Ansible variable:

security_password_remember_password: 5

Passwords must be a minimum of 15 characters in length. (V-71935)¶

STIG Description¶

Severity: Medium

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that passwords have a minimum length of 15 characters, this change might be disruptive to users on a production system without communicating the change first. Therefore, this change is not applied by default.

Deployers can opt in for the change by setting the following Ansible variable:

security_pwquality_require_minimum_password_length: yes

The operating system must disable account identifiers (individuals, groups, roles, and devices) if the password expires. (V-71941)¶

STIG Description¶

Severity: Medium

Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.

Operating systems need to track periods of inactivity and disable application identifiers after zero days of inactivity.

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that user accounts are disabled when their password expires. This might be disruptive for some users or for automated processes. Therefore, the tasks in the security role do not apply this change by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_disable_account_if_password_expires: yes

Accounts subject to three unsuccessful logon attempts within 15 minutes must be locked for the maximum configurable period. (V-71943)¶

STIG Description¶

Severity: Medium

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.

Satisfies: SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005

Deployer/Auditor notes¶

Implementation Status: Opt-In - Red Hat Only

This STIG control is implemented by:

If three unsuccessful root logon attempts within 15 minutes occur the associated account must be locked. (V-71945)

If three unsuccessful root logon attempts within 15 minutes occur the associated account must be locked. (V-71945)¶

STIG Description¶

Severity: Medium

Satisfies: SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005

Deployer/Auditor notes¶

Implementation Status: Opt-In - Red Hat Only

The STIG requires that accounts with excessive failed login attempts are locked. It sets a limit of three failed attempts in a 15 minute interval and these restrictions are applied to all users (including root). Accounts cannot be automatically unlocked for seven days.

This change might cause disruptions in production environments without proper communication to users. Therefore, this change is not applied by default.

Deployers can opt in for the change by setting the following variable:

security_pam_faillock_enable: yes

There are also three configuration options that can be adjusted by setting Ansible variables:

security_pam_faillock_attempts: This many failed login attempts within the specified time interval with trigger the account to lock. (STIG requirement: 3 attempts)
security_pam_faillock_interval: This is the time interval (in seconds) to use when measuring excessive failed login attempts. (STIG requirement: 900 seconds)
security_pam_faillock_deny_root: Set to yes to apply the restriction to the root user or set to no to exempt the root user from the account locking restrictions. (STIG requirement: yes)
security_pam_faillock_unlock_time: This sets the time delay (in seconds) before a locked account is automatically unlocked. (STIG requirement: 604800 seconds)

Note

Ubuntu, openSUSE Leap and SUSE Linux Enterprise 12 do not provide pam_faillock. This change is only applied to CentOS 7 or Red Hat Enterprise Linux 7 systems.

Users must provide a password for privilege escalation. (V-71947)¶

STIG Description¶

Severity: Medium

Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

When operating systems provide the capability to escalate a functional capability, it is critical the user re-authenticate.

Satisfies: SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

The STIG requires all users to authenticate when using sudo, but this change can be highly disruptive for automated scripts or applications that cannot perform interactive authentication. Automated edits from Ansible tasks might cause authentication disruptions on some hosts, and deployers are urged to carefully review each use of the NOPASSWD directive in their sudo configuration files.

Deployers can opt-out of this change by setting an Ansible variable:

security_sudoers_nopasswd_check_enable: no

Users must re-authenticate for privilege escalation. (V-71949)¶

STIG Description¶

Severity: Medium

Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

When operating systems provide the capability to escalate a functional capability, it is critical the user reauthenticate.

Satisfies: SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

The STIG requires all users to re-authenticate when using sudo, but this change can be highly disruptive for automated scripts or applications that cannot perform interactive authentication. Automated edits from Ansible tasks might cause authentication disruptions on some hosts, and deployers are urged to carefully review each use of the !authenticate directive in their sudo configuration files.

The delay between logon prompts following a failed console logon attempt must be at least four seconds. (V-71951)¶

STIG Description¶

Severity: Medium

Configuring the operating system to implement organization-wide security implementation guides and security checklists verifies compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements.

Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example, registry settings; account, file, and directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the Ansible role set a four second delay between failed login attempts. Deployers can configure a different delay (in seconds) by setting the following Ansible variable:

security_shadow_utils_fail_delay: 4

The operating system must not allow users to override SSH environment variables. (V-71957)¶

STIG Description¶

Severity: Medium

Failure to restrict system access to authenticated users negatively impacts operating system security.

Deployer/Auditor notes¶

Implementation Status: Implemented

The PermitUserEnvironment configuration is set to no in /etc/ssh/sshd_config and sshd is restarted.

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_disallow_environment_override: no

The operating system must not allow a non-certificate trusted host SSH logon to the system. (V-71959)¶

STIG Description¶

Severity: Medium

Failure to restrict system access to authenticated users negatively impacts operating system security.

Deployer/Auditor notes¶

Implementation Status: Implemented

The HostbasedAuthentication configuration is set to no in /etc/ssh/sshd_config and sshd is restarted.

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_disallow_host_based_auth: no

The operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users) using multifactor authentication. (V-71965)¶

STIG Description¶

Severity: Medium

To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system.

Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following:

1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication;

and

Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.

Satisfies: SRG-OS-000104-GPOS-00051, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000109-GPOS-00056, SRG-OS-000108-GPOS-00055, SRG-OS-000108-GPOS-00057, SRG-OS-000108-GPOS-00058

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deploying multi-factor authentication methods, including smart cards, is a complicated process that requires preparation and communication. This work is left to deployers to complete manually.

The operating system must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. (V-71971)¶

STIG Description¶

Severity: Medium

Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges.

Privileged functions include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals who do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

The tasks in the security role cannot determine the access levels of individual users.

Deployers are strongly encouraged to configure SELinux user confinement on compatible systems using semanage login. Refer to the Confining Existing Linux Users documentation from Red Hat for detailed information and command line examples.

A file integrity tool must verify the baseline operating system configuration at least weekly. (V-71973)¶

STIG Description¶

Severity: Medium

Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security.

Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system’s Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Initializing the AIDE database and completing the first AIDE run causes increased disk I/O and CPU usage for extended periods. Therefore, the AIDE database is not automatically initialized by the tasks in the security role.

Deployers can enable the AIDE database initialization within the security role by setting the following Ansible variable:

security_rhel7_initialize_aide: yes

Designated personnel must be notified if baseline configurations are changed in an unauthorized manner. (V-71975)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

The cron job for AIDE is configured to send emails to the root user after each AIDE run.

USB mass storage must be disabled. (V-71983)¶

STIG Description¶

Severity: Medium

USB mass storage permits easy introduction of unknown devices, thereby facilitating malicious activity.

Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227

Deployer/Auditor notes¶

Implementation Status: Opt-In

The tasks in the security role disable the usb-storage module and the change is applied the next time the server is rebooted.

Deployers can opt out of this change by setting the following Ansible variable:

security_rhel7_disable_usb_storage: no

File system automounter must be disabled unless required. (V-71985)¶

STIG Description¶

Severity: Medium

Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity.

Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227

Deployer/Auditor notes¶

Implementation Status: Implemented

The autofs service is stopped and disabled if it is found on the system. Deployers can opt out of this change by setting the following Ansible variable:

security_rhel7_disable_autofs: no

The operating system must define default permissions for all authenticated users in such a way that the user can only read and modify their own files. (V-71995)¶

STIG Description¶

Severity: Medium

Setting the most restrictive default permissions ensures that when new accounts are created, they do not have unnecessary access.

Deployer/Auditor notes¶

Implementation Status: Opt-In - Ubuntu And Suse Only

The STIG requires that the umask for all authenticated users is 077. This ensures that all new files and directories created by a user are accessible only by that user.

Although this change has a significant security benefit, it can cause problems for users who are not expecting the change. The security role will not adjust the umask by default.

Deployers can opt-in for the change by setting the default umask with an Ansible variable:

security_shadow_utils_umask: 077

Note

Ubuntu, openSUSE Leap and SUSE Linux Enterpsise 12 use pam_umask and it uses the default umask provided by the UMASK line in /etc/login.defs. The default setting on Ubuntu, openSUSE Leap and SUSE Linux Enterprise 12 systems is 022. This allows the user’s group and other users on the system to read and execute files, but they cannot write to them.

CentOS and Red Hat Enterprise Linux do not use pam_umask and instead set a default umask of 0002 for regular users and 0022 for root. This gives the regular user’s group full access to newly created files, but other users cannot write to those files.

The tasks for this STIG requirement are not currently applied to CentOS and Red Hat Enterprise Linux systems. See Launchpad Bug #1656003 for more details.

Vendor packaged system security patches and updates must be installed and up to date. (V-71999)¶

STIG Description¶

Severity: Medium

Timely patching is critical for maintaining the operational availability, confidentiality, and integrity of information technology (IT) systems. However, failure to keep operating system and application software patched is a common mistake made by IT professionals. New patches are released daily, and it is often difficult for even experienced System Administrators to keep abreast of all the new patches. When new weaknesses in an operating system exist, patches are usually made available by the vendor to resolve the problems. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that security patches and updates are applied when they are made available, this might be disruptive to some systems. Therefore, the tasks in the security role will not configure automatic updates by default.

Deployers can opt in for automatic package updates by setting the following Ansible variable:

security_rhel7_automatic_package_updates: yes

When enabled, the tasks install and configure yum-cron on CentOS and Red Hat Enterprise Linux. On Ubuntu systems, the unattended-upgrades package is installed and configured. On openSUSE Leap and SUSE Linux Enterprise systems, a daily cronjob is installed.

The system must not have unnecessary accounts. (V-72001)¶

STIG Description¶

Severity: Medium

Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers are strongly urged to review the list of user accounts on each server regularly. Evaluation of user accounts must be done on a case-by-case basis and the tasks in the security role are unable to determine which user accounts are valid. Deployers must complete this work manually.

All files and directories must have a valid owner. (V-72007)¶

STIG Description¶

Severity: Medium

Unowned files and directories may be unintentionally inherited if a user is assigned the same User Identifier “UID” as the UID of the un-owned files.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Searching an entire filesystem with find reduces system performance and might impact certain applications negatively. Therefore, the search for files and directories with an invalid owner is disabled by default.

Deployers can opt in for this search by setting the following Ansible variable:

security_search_for_invalid_owner: yes

Any files or directories without a valid user owner are displayed in the Ansible output.

All files and directories must have a valid group owner. (V-72009)¶

STIG Description¶

Severity: Medium

Files without a valid group owner may be unintentionally inherited if a group is assigned the same Group Identifier (GID) as the GID of the files without a valid group owner.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Deployers can opt in for this search by setting the following Ansible variable:

security_search_for_invalid_group_owner: yes

Any files or directories without a valid group owner are displayed in the Ansible output.

All local interactive users must have a home directory assigned in the /etc/passwd file. (V-72011)¶

STIG Description¶

Severity: Medium

If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.

Deployer/Auditor notes¶

Implementation Status: Implemented

The usernames of all users without home directories assigned are provided in the Ansible console output. Deployers should use this list of usernames to audit each system to ensure every user has a valid home directory.

All local interactive user accounts, upon creation, must be assigned a home directory. (V-72013)¶

STIG Description¶

Severity: Medium

If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.

Deployer/Auditor notes¶

Implementation Status: Implemented

The CREATE_HOME variable is set to yes by the tasks in the security role. This ensures that home directories are created each time a new user account is created.

Deployers can opt out of this change by setting the following Ansible variable:

security_shadow_utils_create_home: no

Note

On CentOS 7, Red Hat Enterprise Linux 7 systems, openSUSE Leap and SUSE Linux Enterprise 12, home directories are always created with new users by default. Home directories are not created by default on Ubuntu systems.

All local interactive user home directories defined in the /etc/passwd file must exist. (V-72015)¶

STIG Description¶

Severity: Medium

If a local interactive user has a home directory defined that does not exist, the user may be given access to the / directory as the current working directory upon logon. This could create a Denial of Service because the user would not be able to access their logon configuration files, and it may give them visibility to system files they normally would not be able to access.

Deployer/Auditor notes¶

Implementation Status: Implemented

Each interactive user on the system is checked to verify that their assigned home directory exists on the filesystem. If a home directory is missing, the name of the user and their assigned home directory is printed in the Ansible console output.

All local interactive user home directories must have mode 0750 or less permissive. (V-72017)¶

STIG Description¶

Severity: Medium

Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that all home directories have the proper owner, group owner, and permissions, these changes might be disruptive in some environments. These tasks are not executed by default.

Deployers can opt in for the following changes to each home directory:

Permissions are set to 0750 at a maximum. If permissions are already more restrictive than 0750, the permissions are left unchanged.
User ownership is set to the UID of the user.
Group ownership is set to the GID of the user.

Deployers can opt in for these changes by setting the following Ansible variable:

security_set_home_directory_permissions_and_owners: yes

All local interactive user home directories must be owned by their respective users. (V-72019)¶

STIG Description¶

Severity: Medium

If a local interactive user does not own their home directory, unauthorized users could access or modify the user’s files, and the users may not be able to access their own files.

Deployer/Auditor notes¶

Implementation Status: Opt-In

This control is implemented by the tasks for another control. Refer to the documentation for more details on the change and how to opt out:

All local interactive user home directories must have mode 0750 or less permissive. (V-72017)

All local interactive user home directories must be group-owned by the home directory owners primary group. (V-72021)¶

STIG Description¶

Severity: Medium

If the Group Identifier (GID) of a local interactive user’s home directory is not the same as the primary GID of the user, this would allow unauthorized access to the user’s files, and users that share the same group may not be able to access files that they legitimately should.

Deployer/Auditor notes¶

Implementation Status: Opt-In

This control is implemented by the tasks for another control. Refer to the documentation for more details on the change and how to opt out:

All local interactive user home directories must have mode 0750 or less permissive. (V-72017)

All files and directories contained in local interactive user home directories must be owned by the owner of the home directory. (V-72023)¶

STIG Description¶

Severity: Medium

If local interactive users do not own the files in their directories, unauthorized users may be able to access them. Additionally, if files are not owned by the user, this could be an indication of system compromise.

Deployer/Auditor notes¶

Deployer/Auditor notes¶

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers should manually search their system for world-writable programs and change the permissions on those programs. They are easily found with this command:

find / -perm -002 -type f

World-writable executables should not be needed under almost all circumstances.

All system device files must be correctly labeled to prevent unauthorized modification. (V-72039)¶

STIG Description¶

Severity: Medium

If an unauthorized or modified device is allowed to exist on the system, there is the possibility the system may perform unintended or unauthorized operations.

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers should examine any filesystem mounts of NFS imports to ensure that the nosetuid option is set.

All world-writable directories must be group-owned by root, sys, bin, or an application group. (V-72047)¶

STIG Description¶

Severity: Medium

If a world-writable directory has the sticky bit set and is not group-owned by a privileged Group Identifier (GID), unauthorized users may be able to modify files created by others.

The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.

Deployer/Auditor notes¶

Implementation Status: Opt-In

The tasks in the security role examine the world-writable directories on the system and report any directories that are not group-owned by the root user. Those directories appear in the Ansible output.

Deployers should review the list of directories and group owners to ensure that they are appropriate for the directory. Unauthorized group ownership could allow certain users to modify files from other users.

Searching the entire filesystem for world-writable directories will consume a significant amount of disk I/O and could impact the performance of a production system. It can also delay the playbook’s completion. Therefore, the search is disabled by default.

Deployers can enable the search by setting the following Ansible variable:

security_find_world_writable_dirs: yes

The umask must be set to 077 for all local interactive user accounts. (V-72049)¶

STIG Description¶

Severity: Medium

The umask controls the default access mode assigned to newly created files. A umask of 077 limits new files to mode 700 or less permissive. Although umask can be represented as a four-digit number, the first digit representing special access modes is typically ignored or required to be “0”. This requirement applies to the globally configured system defaults and the local interactive user defaults for each account on the system.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Although the STIG requires that all local interactive user accounts have a umask of 077, this change can be disruptive for users and the applications they run. This change cannot be applied in an automated way.

Deployers should review user initialization files regularly to ensure that the umask is not specified. This allows the system-wide setting of 077 to be applied to all user sessions.

Cron logging must be implemented. (V-72051)¶

STIG Description¶

Severity: Medium

Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Ubuntu, CentOS, Red Hat Enterprise Linux, openSUSE Leap and SUSE Linux Enterprise already capture the logs from cron.

Ubuntu systems collect cron job logs into the main syslog file (/var/log/syslog) rather than separate them into their own log file. CentOS and Red Hat Enterprise Linux systems collect cron logs in /var/log/cron. openSUSE Leap and SUSE Linux Enterprise collect cron job in /var/log/messages.

Deployers should not need to adjust these configurations unless a specific environment requires it. The tasks in the security role do not make changes to the rsyslog configuration.

If the cron.allow file exists it must be owned by root. (V-72053)¶

STIG Description¶

Severity: Medium

If the owner of the “cron.allow” file is not set to root, the possibility exists for an unauthorized user to view or to edit sensitive information.

Deployer/Auditor notes¶

When a server is initially provisioned, deployers should avoid storing the boot loader on removable media. It is not possible to change this via automated tasks.

The operating system must shut down upon audit processing failure, unless availability is an overriding concern. If availability is a concern, the system must alert the designated staff (System Administrator [SA] and Information System Security Officer [ISSO] at a minimum) in the event of an audit processing failure. (V-72081)¶

STIG Description¶

Severity: Medium

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.

Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.

This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Satisfies: SRG-OS-000046-GPOS-00022, SRG-OS-000047-GPOS-00023

Deployer/Auditor notes¶

Implementation Status: Implemented

The audit daemon takes various actions when there is an auditing failure. There are three options for the -f flag for auditctl:

0: In the event of an auditing failure, do nothing.
1: In the event of an auditing failure, write messages to the kernel log.
2: In the event of an auditing failure, cause a kernel panic.

Most operating systems set the failure flag to 1 by default, which maximizes system availability while still causing an alert. The tasks in the security role set the flag to 1 by default.

Deployers can adjust the following Ansible variable to customize the failure flag:

security_rhel7_audit_failure_flag: 1

Warning

Setting the failure flag to 2 is strongly discouraged unless the security of the system takes priority over its availability. Any failure in auditing causes a kernel panic and the system requires a hard reboot.

The operating system must off-load audit records onto a different system or media from the system being audited. (V-72083)¶

STIG Description¶

Severity: Medium

Information stored in one location is vulnerable to accidental or incidental deletion or alteration.

Off-loading is a common process in information systems with limited audit storage capacity.

Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224

Deployer/Auditor notes¶

Implementation Status: Opt-In

The audispd service transmits audit logs to other servers. Deployers should specify the address of another server that can receive audit logs by setting the following Ansible variable:

security_audisp_remote_server: '10.0.21.1'

The operating system must encrypt the transfer of audit records off-loaded onto a different system or media from the system being audited. (V-72085)¶

STIG Description¶

Severity: Medium

Information stored in one location is vulnerable to accidental or incidental deletion or alteration.

Off-loading is a common process in information systems with limited audit storage capacity.

Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224

Deployer/Auditor notes¶

Implementation Status: Opt-In

The audispd daemon transmits audit logs without encryption by default. The STIG requires that these logs are encrypted while they are transferred across the network. The encryption is controlled by the enable_krb5 option in /etc/audisp/audisp-remote.conf.

Deployers can opt-in for encrypted audit log transmission by setting the following Ansible variable:

security_audisp_enable_krb5: yes

Warning

Only enable this setting if kerberos is already configured.

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

STIG Description¶

Severity: Medium

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

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role set the disk_full_action and network_failure_action to syslog in the audispd remote configuration. In the event of a full disk on the remote log server or a network interruption, the local system sends warnings to syslog. This is the safest option since it maximizes the availability of the local system.

Deployers have two other options available:

single: Switch the local server into single-user mode in the event of a logging failure.
halt: Shut off the local server gracefully in the event of a logging failure.

Warning

Choosing single or halt causes a server to go into a degraded or offline state immediately after a logging failure.

Deployers can adjust these configurations by setting the following Ansible variables (the safe defaults are shown here):

security_rhel7_auditd_disk_full_action: syslog
security_rhel7_auditd_network_failure_action: syslog

The operating system must immediately notify the System Administrator (SA) and Information System Security Officer ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. (V-72089)¶

STIG Description¶

Severity: Medium

If security personnel are not notified immediately when storage volume reaches 75 percent utilization, they are unable to plan for audit record storage capacity expansion.

Deployer/Auditor notes¶

Implementation Status: Implemented

The space_left configuration is set to 25% of the size of the disk mounted on /. This calculation is done automatically.

Deployers can set a custom threshold for the space_left configuration (in megabytes) by setting the following Ansible variable:

# Example: A setting of 1GB (1024MB)
security_rhel7_auditd_space_left: 1024

The operating system must immediately notify the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) via email when the threshold for the repository maximum audit record storage capacity is reached. (V-72091)¶

STIG Description¶

Severity: Medium

If security personnel are not notified immediately when the threshold for the repository maximum audit record storage capacity is reached, they are unable to expand the audit record storage capacity before records are lost.

Deployer/Auditor notes¶

Implementation Status: Implemented

The space_left_action in the audit daemon configuration is set to email. This configuration causes the root user to receive an email when the space_left threshold is reached.

Deployers can customize this configuration by setting the following Ansible variable:

security_rhel7_auditd_space_left_action: email

The operating system must immediately notify the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) when the threshold for the repository maximum audit record storage capacity is reached. (V-72093)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

The action_mail_acct configuration in the audit daemon configuration file is set to root to meet the requirements of the STIG. Deployers can customize the recipient of the emails that come from auditd by setting the following Ansible variable:

security_rhel7_auditd_action_mail_acct: root

All privileged function executions must be audited. (V-72095)¶

STIG Description¶

Severity: Medium

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

This STIG is difficult to implement in an automated way because the number of applications on a system with setuid/setgid permissions changes over time. In addition, adding audit rules for some of these automatically could cause a significant increase in logging traffic when these applications are used regularly.

Deployers are urged to do the following instead:

Minimize the amount of applications with setuid/setgid privileges
Monitor any new applications that gain setuid/setgid privileges
Add risky applications with setuid/setgid privileges to auditd for detailed syscall monitoring

All uses of the chown command must be audited. (V-72097)¶

STIG Description¶

Severity: Medium

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all chown syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

This rule is disabled by default to avoid high CPU usage and disk space exhaustion. Deployers should only enable this rule if they have tested it thoroughly in a non-production environment with system health monitoring enabled.

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_chown: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the fchown command must be audited. (V-72099)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all fchown syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_fchown: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the lchown command must be audited. (V-72101)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all lchown syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_lchown: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the fchownat command must be audited. (V-72103)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all fchownat syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_fchownat: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the chmod command must be audited. (V-72105)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all chmod syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_chmod: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the fchmod command must be audited. (V-72107)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all fchmod syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_fchmod: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the fchmodat command must be audited. (V-72109)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all fchmodat syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_fchmodat: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the setxattr command must be audited. (V-72111)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all setxattr syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_setxattr: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the fsetxattr command must be audited. (V-72113)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all fsetxattr syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_fsetxattr: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the lsetxattr command must be audited. (V-72115)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all lsetxattr syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_lsetxattr: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the removexattr command must be audited. (V-72117)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all removexattr syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_removexattr: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the fremovexattr command must be audited. (V-72119)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all fremovexattr syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_fremovexattr: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the lremovexattr command must be audited. (V-72121)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000392-GPOS-00172, SRG-OS-000064-GPOS-00033

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that all lremovexattr syscalls are audited, but this change creates a significant increase in logging on most systems. This increase can cause some systems to run out of disk space for logs.

Warning

Deployers can opt in for this change by setting the following Ansible variable:

security_rhel7_audit_lremovexattr: yes

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the creat command must be audited. (V-72123)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all creat syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_creat: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the open command must be audited. (V-72125)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all open syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_open: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the openat command must be audited. (V-72127)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all openat syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_openat: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the open_by_handle_at command must be audited. (V-72129)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all open_by_handle_at syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_open_by_handle_at: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the truncate command must be audited. (V-72131)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all truncate syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_truncate: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the ftruncate command must be audited. (V-72133)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all ftruncate syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_ftruncate: no

security_rhel7_audit_restorecon: no

The operating system must generate audit records for all successful/unsuccessful account access count events. (V-72143)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all successful and unsuccessful account access events. Deployers can opt out of this change by setting the following Ansible variable:

security_rhel7_audit_account_access: no

The operating system must generate audit records for all unsuccessful account access events. (V-72145)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

The operating system must generate audit records for all successful/unsuccessful account access count events. (V-72143)

The operating system must generate audit records for all successful account access events. (V-72147)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time an account is accessed.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_account_access: no

All uses of the passwd command must be audited. (V-72149)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged password commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the passwd command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_passwd_command: no

All uses of the unix_chkpwd command must be audited. (V-72151)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the unix_chkpwd command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_unix_chkpwd: no

All uses of the gpasswd command must be audited. (V-72153)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the gpasswd command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_gpasswd: no

All uses of the chage command must be audited. (V-72155)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the chage command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_chage: no

All uses of the userhelper command must be audited. (V-72157)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the userhelper command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_userhelper: no

All uses of the su command must be audited. (V-72159)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged access commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the su command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_su: no

All uses of the sudo command must be audited. (V-72161)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the sudo command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_sudo: no

All uses of the sudoers command must be audited. (V-72163)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time a user manages the configuration files for sudo.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_sudo_config_changes: no

All uses of the newgrp command must be audited. (V-72165)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the newgrp command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_newgrp: no

All uses of the chsh command must be audited. (V-72167)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the chsh command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_chsh: no

All uses of the sudoedit command must be audited. (V-72169)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the sudoedit command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_sudoedit: no

All uses of the mount command must be audited. (V-72171)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged mount commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the mount command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_mount: no

All uses of the umount command must be audited. (V-72173)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the umount command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_umount: no

All uses of the postdrop command must be audited. (V-72175)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged postfix commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the postdrop command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_postdrop: no

All uses of the postqueue command must be audited. (V-72177)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the postqueue command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_postqueue: no

All uses of the ssh-keysign command must be audited. (V-72179)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged ssh commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the ssh-keysign command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_ssh_keysign: no

All uses of the crontab command must be audited. (V-72183)¶

STIG Description¶

Severity: Medium

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the crontab command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_crontab: no

All uses of the pam_timestamp_check command must be audited. (V-72185)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the pam_timestamp_check command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_pam_timestamp_check: no

All uses of the init_module command must be audited. (V-72187)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all init_module syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_init_module: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the delete_module command must be audited. (V-72189)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all delete_module syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_delete_module: no

security_rhel7_audit_modprobe: no

The operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd. (V-72197)¶

STIG Description¶

Severity: Medium

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time that an account is modified. This includes changes to the following files:

/etc/group
/etc/passwd
/etc/gshadow
/etc/shadow
/etc/security/opasswd

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_account_actions: no

All uses of the rename command must be audited. (V-72199)¶

STIG Description¶

Severity: Medium

If the system is not configured to audit certain activities and write them to an audit log, it is more difficult to detect and track system compromises and damages incurred during a system compromise.

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all rename syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_rename: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the renameat command must be audited. (V-72201)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all renameat syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_renameat: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the rmdir command must be audited. (V-72203)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit all rmdir syscalls on the system.

Deployers can opt out of this change by setting an Ansible variable:

security_rhel7_audit_rmdir: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the unlink command must be audited. (V-72205)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the unlink command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_unlink: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

All uses of the unlinkat command must be audited. (V-72207)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks add a rule to auditd that logs each time the unlinkat command is used.

Deployers can opt-out of this change by setting an Ansible variable:

security_rhel7_audit_unlinkat: no

This rule is compatible with x86, x86_64, and ppc64 architectures.

The system must send rsyslog output to a log aggregation server. (V-72209)¶

STIG Description¶

Severity: Medium

Sending rsyslog output to another system ensures that the logs cannot be removed or modified in the event that the system is compromised or has a hardware failure.

Deployer/Auditor notes¶

Implementation Status: Verification Only

The tasks in the security role check for uncommented lines in the rsyslog configuration that contain @ or @@, which signifies that a remote logging configuration is in place. If these lines are not found, a warning message is printed in the Ansible output.

The rsyslog daemon must not accept log messages from other servers unless the server is being used for log aggregation. (V-72211)¶

STIG Description¶

Severity: Medium

Unintentionally running a rsyslog server accepting remote messages puts the system at increased risk. Malicious rsyslog messages sent to the server could exploit vulnerabilities in the server software itself, could introduce misleading information in to the system’s logs, or could fill the system’s storage leading to a Denial of Service. If the system is intended to be a log aggregation server its use must be documented with the ISSO.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers must take manual steps to add or remove syslog reception configuration lines depending on a server’s role:

If the server is a log aggregation server, deployers must configure the server to receive syslog output from the other servers via TCP connections.
If the server is not a log aggregation server, deployers must configure the server so that it does not accept syslog output from other servers.

The system must update the virus scan program every seven days or more frequently. (V-72215)¶

STIG Description¶

Severity: Medium

Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems.

The virus scanning software should be configured to check for software and virus definition updates with a frequency no longer than seven days. If a manual process is required to update the virus scan software or definitions, it must be documented with the Information System Security Officer (ISSO).

Deployer/Auditor notes¶

Implementation Status: Implemented

By default, CentOS 7, Red Hat Enterprise Linux 7, openSUSE Leap and SUSE Linux Enterprise 12 check for virus database updates 12 times a day. Ubuntu servers have a default of 24 checks per day.

The tasks in the security role do not adjust these defaults as they are more secure than the STIG’s requirement.

The host must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the Ports, Protocols, and Services Management Component Local Service Assessment (PPSM CLSA) and vulnerability assessments. (V-72219)¶

STIG Description¶

Severity: Medium

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.

Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component.

To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.

Satisfies: SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers should review each firewall rule on a regular basis to ensure that each port is open for a valid reason.

A FIPS 140-2 approved cryptographic algorithm must be used for SSH communications. (V-72221)¶

STIG Description¶

Severity: Medium

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised.

Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.

FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general purpose computing system.

Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000120-GPOS-00061, SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173

Deployer/Auditor notes¶

Implementation Status: Implemented

The Ciphers configuration is set to aes128-ctr,aes192-ctr,aes256-ctr in /etc/ssh/sshd_config and sshd is restarted.

Deployers can change the list of ciphers by setting the following Ansible variable:

security_sshd_cipher_list: 'cipher1,cipher2,cipher3'

All network connections associated with a communication session must be terminated at the end of the session or after 10 minutes of inactivity from the user at a command prompt, except to fulfill documented and validated mission requirements. (V-72223)¶

STIG Description¶

Severity: Medium

Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element.

Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that the operating system terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role set a 600 second (10 minute) timeout for network connections associated with a communication session. Deployers can change the timeout value by setting the following Ansible variable:

# Example: shorten the timeout to 5 minutes (300 seconds)
security_rhel7_session_timeout: 300

The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) authentication communications. (V-72227)¶

STIG Description¶

Severity: Medium

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers are strongly urged to utilize sssd for systems that authenticate against LDAP or Active Directory (AD) servers.

The ldap connector for sssd connects only to LDAP servers over encrypted connections. Review the man page for sssd-ldap for more details on this requirement.

The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) communications. (V-72229)¶

STIG Description¶

Severity: Medium

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers are strongly urged to utilize sssd for systems that authenticate against LDAP or Active Directory (AD) servers.

To meet this control, deployers must ensure that ldap_tls_cacert or ldap_tls_cacertdir are set in the /etc/sssd/sssd.conf file. The ldap_tls_cacert directive specifies a single certificate while ldap_tls_cacertdir specifies a directory where sssd can find CA certificates.

Warning

Use caution when adjusting these settings. If the correct CA certificates are not already deployed to the servers that perform LDAP authentication, their attempts to authenticate users might fail.

Consult with administrators of the LDAP system and test all changes on a non-production system first.

The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) communications. (V-72231)¶

STIG Description¶

Severity: Medium

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers are strongly urged to utilize sssd for systems that authenticate against LDAP or Active Directory (AD) servers.

Warning

Use caution when adjusting these settings. If the correct CA certificates are not already deployed to the servers that perform LDAP authentication, their attempts to authenticate users might fail.

Consult with administrators of the LDAP system and test all changes on a non-production system first.

All networked systems must have SSH installed. (V-72233)¶

STIG Description¶

Severity: Medium

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.

This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.

Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa.

Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190

Deployer/Auditor notes¶

Implementation Status: Implemented

The STIG requires that every system has an ssh client and server installed. The role installs the following packages:

CentOS: openssh-clients, openssh-server
Ubuntu: openssh-client, openssh-server
openSUSE Leap: openssh

All networked systems must use SSH for confidentiality and integrity of transmitted and received information as well as information during preparation for transmission. (V-72235)¶

STIG Description¶

Severity: Medium

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.

Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.

Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000423-GPOS-00188, SRG-OS-000423-GPOS-00189, SRG-OS-000423-GPOS-00190

Deployer/Auditor notes¶

Implementation Status: Implemented

The STIG has a requirement that the sshd daemon is running and enabled at boot time. The tasks in the security role ensure that these requirements are met.

Some deployers may not have sshd enabled on highly specialized systems and those deployers should opt out of this change by setting the following Ansible variable:

security_enable_sshd: no

Note

Setting security_enable_sshd to no causes the tasks to ignore the state of the service entirely. A setting of no does not stop or alter the sshd service.

All network connections associated with SSH traffic must terminate at the end of the session or after 10 minutes of inactivity, except to fulfill documented and validated mission requirements. (V-72237)¶

STIG Description¶

Severity: Medium

Terminating an idle SSH session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle SSH session will also free up resources committed by the managed network element.

Satisfies: SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109

Deployer/Auditor notes¶

Implementation Status: Implemented

The ClientAliveInterval configuration is set to 600 in /etc/ssh/sshd_config and sshd is restarted.

Deployers can adjust the length of the interval by changing the following Ansible variable:

security_sshd_client_alive_interval: 600

Note

The STIG requires that ClientAliveInterval is set to 600 and ClientAliveCountMax is set to zero, which sets a 10 minute session timeout. If no data is transferred in a 10 minute period, the session is disconnected.

The ClientAliveInterval specifies how long the ssh daemon waits before it sends a message to the client to see if it is still alive. The ClientAliveCountMax specifies how many of these messages are sent without receiving a response.

Deployers should refer to All network connections associated with SSH traffic must terminate after a period of inactivity. (V-72241) to customize the ClientAliveCountMax setting.

The SSH daemon must not allow authentication using RSA rhosts authentication. (V-72239)¶

STIG Description¶

Severity: Medium

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

Deployer/Auditor notes¶

Implementation Status: Implemented

This STIG is already applied by the changes for The SSH daemon must not allow authentication using known hosts authentication. (V-72249).

All network connections associated with SSH traffic must terminate after a period of inactivity. (V-72241)¶

STIG Description¶

Severity: Medium

Satisfies: SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109

Deployer/Auditor notes¶

Implementation Status: Implemented

The ClientAliveCountMax configuration is set to 0 in /etc/ssh/sshd_config and sshd is restarted.

Deployers can adjust the maximum amount of client alive intervals by changing the following Ansible variable.

security_sshd_client_alive_count_max: 0

Deployers can select another setting for PermitRootLogin, from the available options without-password, prohibit-password, forced-commands-only, yes, or no by setting the following variable:

security_sshd_permit_root_login: no

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_disallow_gssapi: no

The SSH daemon must not permit Kerberos authentication unless needed. (V-72261)¶

STIG Description¶

Severity: Medium

Kerberos authentication for SSH is often implemented using Generic Security Service Application Program Interface (GSSAPI). If Kerberos is enabled through SSH, the SSH daemon provides a means of access to the system’s Kerberos implementation. Vulnerabilities in the system’s Kerberos implementation may then be subject to exploitation. To reduce the attack surface of the system, the Kerberos authentication mechanism within SSH must be disabled for systems not using this capability.

Deployer/Auditor notes¶

Implementation Status: Implemented

The KerberosAuthentication configuration is set to no in /etc/ssh/sshd_config and sshd is restarted.

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_disable_kerberos_auth: no

The SSH daemon must perform strict mode checking of home directory configuration files. (V-72263)¶

STIG Description¶

Severity: Medium

If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user.

Deployer/Auditor notes¶

Implementation Status: Implemented

The StrictModes configuration is set to yes in /etc/ssh/sshd_config and sshd is restarted.

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_enable_strict_modes: no

The SSH daemon must use privilege separation. (V-72265)¶

STIG Description¶

Severity: Medium

SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section.

Deployer/Auditor notes¶

Implementation Status: Implemented

The UsePrivilegeSeparation configuration is set to sandbox in /etc/ssh/sshd_config and sshd is restarted.

Deployers can opt out of this change by setting the following Ansible variable:

security_sshd_enable_privilege_separation: no

Note

Although the STIG requires this setting to be yes, the sandbox setting actually provides more security because it enables privilege separation during the early authentication process.

The SSH daemon must not allow compression or must only allow compression after successful authentication. (V-72267)¶

STIG Description¶

Severity: Medium

If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.

Deployer/Auditor notes¶

Implementation Status: Implemented

The Compression configuration is set to delayed in /etc/ssh/sshd_config and sshd is restarted.

Deployers can choose another option by setting the following Ansible variable:

security_sshd_compression: 'no'

Note

The following are the available settings for Compression in the ssh configuration file:

delayed: Compression is enabled after authentication.
no: Compression is disabled.
yes: Compression is enabled during authentication and during the session (not allowed by the STIG).

The delayed option balances security with performance and is an approved option in the STIG.

The operating system must, for networked systems, synchronize clocks with a server that is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS). (V-72269)¶

STIG Description¶

Severity: Medium

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate.

Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints).

Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role make the following changes on each host:

The chrony package is installed.
The service (chronyd on Red Hat, CentOS, SLE and openSUSE Leap, chrony on Ubuntu) is started and enabled at boot time.
A configuration file template is deployed that includes maxpoll 10 on each server line.

Deployers can opt out of these changes by setting the following Ansible variable:

security_rhel7_enable_chrony: no

Note

Although the STIG mentions the traditional ntpd service, this role uses chrony, which is a more modern implementation.

The operating system must protect against or limit the effects of Denial of Service (DoS) attacks by validating the operating system is implementing rate-limiting measures on impacted network interfaces. (V-72271)¶

STIG Description¶

Severity: Medium

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

This requirement addresses the configuration of the operating system to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that incoming TCP connections are rate limited with firewalld, this setting can cause problems with certain applications which handle large amounts of TCP connections. Therefore, the tasks in the security role do not apply the rate limit by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_enable_firewalld_rate_limit: yes

The STIG recommends a limit of 25 connection per minute and allowing bursts up to 100 connections. Both of these options are adjustable with the following Ansible variables:

security_enable_firewalld_rate_limit_per_minute: 25
security_enable_firewalld_rate_limit_burst: 100

Warning

Deployers should test rate limiting in a non-production environment first before applying it to production systems. Ensure that the application running on the system is receiving a large volume of requests so that the rule can be thoroughly tested.

The operating system must enable an application firewall, if available. (V-72273)¶

STIG Description¶

Severity: Medium

Firewalls protect computers from network attacks by blocking or limiting access to open network ports. Application firewalls limit which applications are allowed to communicate over the network.

Satisfies: SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232

Deployer/Auditor notes¶

Implementation Status: Opt-In

The STIG requires that a firewall is configured on each server. This might be disruptive to some environments since the default firewall policy for firewalld is very restrictive. Therefore, the tasks in the security role do not install or enable the firewalld daemon by default.

Deployers can opt in for this change by setting the following Ansible variable:

security_enable_firewalld: yes

Warning

Deployers must pre-configure firewalld or copy over a working XML file in /etc/firewalld/zones/ from another server. The default firewalld restrictions on Ubuntu, CentOS, Red Hat Enterprise Linux and openSUSE Leap are highly restrictive.

The system must not forward Internet Protocol version 4 (IPv4) source-routed packets. (V-72283)¶

STIG Description¶

Severity: Medium

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in this role set net.ipv4.conf.all.accept_source_route and net.ipv4.conf.default.accept_source_route to 0 by default. This prevents the system from forwarding source-routed IPv4 packets on all new and existing interfaces.

Deployers can opt out of this change by setting the following Ansible variable:

security_disallow_source_routed_packet_forward_ipv4: no

For more details on source routed packets, refer to the Red Hat documentation.

The system must not forward Internet Protocol version 4 (IPv4) source-routed packets by default. (V-72285)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

The system must not forward Internet Protocol version 4 (IPv4) source-routed packets. (V-72283)

The system must not respond to Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) echoes sent to a broadcast address. (V-72287)¶

STIG Description¶

Severity: Medium

Responding to broadcast (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in this role set net.ipv4.icmp_echo_ignore_broadcasts to 1 by default. This prevents the system from responding to IPv4 ICMP echoes sent to the broadcast address.

Deployers can opt out of this change by setting the following Ansible variable:

security_disallow_echoes_broadcast_address: no

The system must prevent Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages from being accepted. (V-72289)¶

STIG Description¶

Severity: Medium

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host’s route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

The system must ignore Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages. (V-73175)

The system must not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects by default. (V-72291)¶

STIG Description¶

Severity: Medium

ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system’s route table, possibly revealing portions of the network topology.

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in this role set net.ipv4.conf.default.send_redirects and net.ipv4.conf.all.send_redirects to 0 by default. This prevents a system from sending IPv4 ICMP redirect packets on all new and existing interfaces.

Deployers can opt out of this change by setting the following Ansible variable:

security_disallow_icmp_redirects: no

The system must not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects. (V-72293)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

The system must not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects by default. (V-72291)

Network interfaces must not be in promiscuous mode. (V-72295)¶

STIG Description¶

Severity: Medium

Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow then to collect information such as logon IDs, passwords, and key exchanges between systems.

If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the Information System Security Officer (ISSO) and restricted to only authorized personnel.

Deployer/Auditor notes¶

Implementation Status: Verification Only

All interfaces are examined to ensure they are not in promiscuous mode. A warning message is printed in the Ansible output if any promiscuous interfaces are found.

The system must be configured to prevent unrestricted mail relaying. (V-72297)¶

STIG Description¶

Severity: Medium

If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending spam or other unauthorized activity.

Deployer/Auditor notes¶

Implementation Status: Implemented

The smtpd_client_restrictions configuration in postfix is set to permit_mynetworks, reject to meet the STIG’s requirements.

Deployers can opt out of this change by setting the following Ansible variable:

security_rhel7_restrict_mail_relaying: no

If the Trivial File Transfer Protocol (TFTP) server is required, the TFTP daemon must be configured to operate in secure mode. (V-72305)¶

STIG Description¶

Severity: Medium

Restricting TFTP to a specific directory prevents remote users from copying, transferring, or overwriting system files.

Deployer/Auditor notes¶

Implementation Status: Verification Only

The tasks in the security role examine the TFTP server configuration file (if it exists) to verify that the secure operation flag (-s) is listed on the server_args line. If it is missing, a warning message is printed in the Ansible output.

An X Windows display manager must not be installed unless approved. (V-72307)¶

STIG Description¶

Severity: Medium

Internet services that are not required for system or application processes must not be active to decrease the attack surface of the system. X Windows has a long history of security vulnerabilities and will not be used unless approved and documented.

Deployer/Auditor notes¶

Implementation Status: Implemented

The role will remove the xorg server package from the system if it is installed. The package name differs between Linux distributions:

CentOS: xorg-x11-server-Xorg
Ubuntu: xorg-xserver
openSUSE Leap: xorg-x11-server

Deployers can opt-out of this change by setting the following Ansible variable:

security_rhel7_remove_xorg: no

The system must not be performing packet forwarding unless the system is a router. (V-72309)¶

STIG Description¶

Severity: Medium

Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Disabling IP forwarding on a system that routes packets or host virtual machines might cause network interruptions. The tasks in this role do not adjust the net.ipv4.ip_forward configuration by default.

Deployers can opt in for this change and disable IP forwarding by setting the following Ansible variable:

security_disallow_ip_forwarding: yes

Warning

IP forwarding is required in some environments. Always test in a non-production environment before changing this setting on a production system.

The Network File System (NFS) must be configured to use RPCSEC_GSS. (V-72311)¶

STIG Description¶

Severity: Medium

When an NFS server is configured to use RPCSEC_SYS, a selected userid and groupid are used to handle requests from the remote user. The userid and groupid could mistakenly or maliciously be set incorrectly. The RPCSEC_GSS method of authentication uses certificates on the server and client systems to more securely authenticate the remote mount request.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers using NFS should examine their mounts to ensure krb5:krb5i:krb5p is provided with the sec option. Kerberos must be installed and configured before making the change.

The system access control program must be configured to grant or deny system access to specific hosts and services. (V-72315)¶

STIG Description¶

Severity: Medium

If the systems access control program is not configured with appropriate rules for allowing and denying access to system network resources, services may be accessible to unauthorized hosts.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

The firewalld service is optionally enabled and configured in the tasks for another STIG control:

The operating system must enable an application firewall, if available. (V-72273)

Deployers should review their firewalld ruleset regularly to ensure that each firewall rule is specific as possible. Each rule should allow the smallest number of hosts to access the smallest number of services.

The system must not have unauthorized IP tunnels configured. (V-72317)¶

STIG Description¶

Severity: Medium

IP tunneling mechanisms can be used to bypass network filtering. If tunneling is required, it must be documented with the Information System Security Officer (ISSO).

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers should review all tunneled connections on a regular basis to ensure each is valid and properly secured. This requires careful verification that cannot be done with automated Ansible tasks.

The system must not forward IPv6 source-routed packets. (V-72319)¶

STIG Description¶

Severity: Medium

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv6 forwarding is enabled and the system is functioning as a router.

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in this role set net.ipv6.conf.all.accept_source_route to 0 by default. This prevents the system from forwarding source-routed IPv6 packets.

Deployers can opt out of this change by setting the following Ansible variable:

security_disallow_source_routed_packet_forward_ipv6: no

Refer to “IPv6 source routing: history repeats itself” for more details on IPv6 source routed packets.

The operating system must have the required packages for multifactor authentication installed. (V-72417)¶

STIG Description¶

Severity: Medium

Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.

A privileged account is defined as an information system account with authorizations of a privileged user.

Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

Requires further clarification from NIST.

Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000375-GPOS-00162

Deployer/Auditor notes¶

Implementation Status: Implemented

The STIG requires that the following multifactor authentication packages are installed:

authconfig
authconfig-gtk
esc
pam_pkcs11

Any adjustment to PKI authentication can cause disruptions for users. Deployers should verify that their environment is compatible with smart cards before requiring them for authentication.

The operating system must set the lock delay setting for all connection types. (V-73155)¶

STIG Description¶

Severity: Medium

The session lock is implemented at the point where session activity can be determined and/or controlled.

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

The operating system must enable a user session lock until that user re-establishes access using established identification and authentication procedures. (V-71891)

The operating system must set the session idle delay setting for all connection types. (V-73157)¶

STIG Description¶

Severity: Medium

The session lock is implemented at the point where session activity can be determined and/or controlled.

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

The operating system must enable a user session lock until that user re-establishes access using established identification and authentication procedures. (V-71891)

When passwords are changed or new passwords are established, pwquality must be used. (V-73159)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Opt-In

The security role can require new or changed passwords to follow the pwquality rules, but this change can be disruptive for users without proper communication. Deployers must opt in for this change by setting the following variable:

security_enable_pwquality_password_set: yes

File systems that are being imported via Network File System (NFS) must be mounted to prevent binary files from being executed. (V-73161)¶

STIG Description¶

Severity: Medium

The “noexec” mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Deployer/Auditor notes¶

This control is implemented by the tasks for another control:

The operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd. (V-72197)

The system must ignore Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages. (V-73175)¶

STIG Description¶

Severity: Medium

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

The system must not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects. (V-72293)

Wireless network adapters must be disabled. (V-73177)¶

STIG Description¶

Severity: Medium

The use of wireless networking can introduce many different attack vectors into the organization’s network. Common attack vectors such as malicious association and ad hoc networks will allow an attacker to spoof a wireless access point (AP), allowing validated systems to connect to the malicious AP and enabling the attacker to monitor and record network traffic. These malicious APs can also serve to create a man-in-the-middle attack or be used to create a denial of service to valid network resources.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers should review the configuration of any wireless networking device connected to the system to ensure it must be enabled. The STIG requires that all wireless network devices are enabled unless required.

The operating system must uniquely identify and must authenticate users using multifactor authentication via a graphical user logon. (V-77819)¶

STIG Description¶

Severity: Medium

Severity: Medium

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.

Deployer/Auditor notes¶

Implementation Status: Implemented

Most modern systems enable Address Space Layout Randomization (ASLR) by default (with a setting of 2), and the role ensures that the secure default is maintained.

Deployers can opt out of the change by setting the following Ansible variable:

security_enable_aslr: no

For more details on the ASLR settings, review the sysctl documentation.

Low (11 controls)¶

The operating system must remove all software components after updated versions have been installed. (V-71987)¶

STIG Description¶

Severity: Low

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that dependent packages are removed automatically when a package is removed, this can cause problems with certain packages, especially kernels. Deployers must opt in to meet the requirements of this STIG control.

Deployers should set the following variable to enable automatic dependent package removal:

security_package_clean_on_remove: yes

All Group Identifiers (GIDs) referenced in the /etc/passwd file must be defined in the /etc/group file. (V-72003)¶

STIG Description¶

Severity: Low

If a user is assigned the GID of a group not existing on the system, and a group with the GID is subsequently created, the user may have unintended rights to any files associated with the group.

Implementation Status: Implemented

CentOS 7 and Red Hat Enterprise Linux 7 already deploy a very secure AIDE configuration that checks access control lists (ACLs) and extended attributes by default. No configuration changes are applied on these systems.

However, Ubuntu lacks the rules that include ACL and extended attribute checks. The tasks in the security role will add a small configuration block at the end of the AIDE configuration file to meet the requirements of this STIG, as well as V-72071.

openSUSE Leap and SUSE Linux Enterprise 12 also lack a rule to check ACLs and extended attributes. The default configuration file is adjusted to include those as well.

The file integrity tool must be configured to verify extended attributes. (V-72071)¶

STIG Description¶

Severity: Low

Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications.

Deployer/Auditor notes¶

Implementation Status: Implemented

openSUSE Leap and SUSE Linux Enterprise 12 also lack a rule to check ACLs and extended attributes. The default configuration file is adjusted to include those as well.

The operating system must limit the number of concurrent sessions to 10 for all accounts and/or account types. (V-72217)¶

STIG Description¶

Severity: Low

Operating system management includes the ability to control the number of users and user sessions that utilize an operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to DoS attacks.

This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based on mission needs and the operational environment for each system.

Deployer/Auditor notes¶

Implementation Status: Opt-In

Although the STIG requires that each account is limited to 10 concurrent connections, this change might be disruptive in some environments. Therefore, this change is not applied by default.

Deployers can opt in for this change by setting a concurrent connection limit with this Ansible variable:

security_rhel7_concurrent_session_limit: 10

The system must display the date and time of the last successful account logon upon logon. (V-72275)¶

STIG Description¶

Severity: Low

Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.

Deployer/Auditor notes¶

Implementation Status: Verification Only

The PAM configuration is checked for the presence of pam_lastlogin and a warning message is printed if the directive is not found. The tasks in the security role do not adjust PAM configurations since these changes might be disruptive in some environments.

Deployers should review their PAM configurations and add pam_lastlogin to /etc/pam.d/postlogin on CentOS and Red Hat Enterprise Linux or to /etc/pam.d/login on Ubuntu, openSUSE Leap and SUSE Linux Enterprise.

For systems using DNS resolution, at least two name servers must be configured. (V-72281)¶

STIG Description¶

Severity: Low

To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.

Deployer/Auditor notes¶

Implementation Status: Implemented

If a server has fewer than two nameservers configured in /etc/resolv.conf, a warning is printed in the Ansible output.