Review All STIG Controls¶

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

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

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

STIG Description¶

Severity: Medium

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.

The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters:

"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests–not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:

"I've read  consent to terms in IS user agreem't."

Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007, SRG-OS-000228-GPOS-00088

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role configure dconf to display a login banner each time a graphical session starts on the system. The default banner message set by the role is:

You are accessing a secured system and your actions will be logged along with identifying information. Disconnect immediately if you are not an authorized user of this system.

Deployers can customize this message by setting an Ansible variable:

security_enable_graphical_login_message_text: >
    This is a customized banner message.

In addition, deployers can opt out of displaying a login banner message by changing security_enable_graphical_login_message to no.

STIG Description¶

Severity: Medium

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.

The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters:

"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests–not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007, SRG-OS-000228-GPOS-00088

Deployer/Auditor notes¶

Implementation Status: Implemented

The security role configures a login banner for graphical logins using dconf. Deployers can opt out of this change by setting the following Ansible variable:

security_enable_graphical_login_message: no

The message is customized by setting another Ansible variable:

security_enable_graphical_login_message_text: >
    You are accessing a secured system and your actions will be logged along
    with identifying information. Disconnect immediately if you are not an
    authorized user of this system.

STIG Description¶

Severity: Medium

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.

The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters:

"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests–not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner:

"I've read  consent to terms in IS user agreem't."

Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007

Deployer/Auditor notes¶

Implementation Status: Implemented

The security role already deploys a login banner for console logins with tasks from another STIG:

• The Standard Mandatory DoD Notice and Consent Banner must be displayed immediately prior to, or as part of, remote access logon prompts. (V-72225)

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

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

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

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)

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

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

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)

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

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

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_lowercase: no

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_numeric: no

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_special: no

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_characters_changed: no

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_character_classes_changed: no

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_limit_repeated_characters: no

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_limit_repeated_character_classes: no

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.

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

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

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.

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

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.

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.

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

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

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

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

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

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

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)

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

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)

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.

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.

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

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

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

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

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

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.

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

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)

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

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

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

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

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.

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

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: Implemented

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

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.

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

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

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

security_enable_gpgcheck_repo: yes

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

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

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

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.

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

security_rhel7_enable_linux_security_module: no

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

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

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

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:

• Ubuntu releases
• CentOS EOL dates
• Red Hat Enterprise Linux Life Cycle
• openSUSE EOL dates
• SUSE Linux Enterprise

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.

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.

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.

Deployer/Auditor notes¶

Implementation Status: Implemented

If any users are found with invalid GIDs, those users are printed in the Ansible output. Deployers should review the list and ensure all users are assigned to a valid group that is defined in /etc/group.

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.

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.

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

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 group owner is disabled by default.

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.

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.

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

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.

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

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)

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)

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¶

Implementation Status: Exception - Manual Intervention

Although the STIG has requirements for ownership and permissions of files and directories in each user’s home directory, broad changes to these settings might cause disruptions to users on a system. Therefore, these changes are left to deployers to examine and adjust manually.

STIG Description¶

Severity: Medium

If a local interactive user’s files are group-owned by a group of which the user is not a member, unintended users may be able to access them.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Although the STIG has requirements for ownership and permissions of files and directories in each user’s home directory, broad changes to these settings might cause disruptions to users on a system. Therefore, these changes are left to deployers to examine and adjust manually.

STIG Description¶

Severity: Medium

If a local interactive user files have excessive permissions, unintended users may be able to access or modify them.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Although the STIG has requirements for ownership and permissions of files and directories in each user’s home directory, broad changes to these settings might cause disruptions to users on a system. Therefore, these changes are left to deployers to examine and adjust manually.

STIG Description¶

Severity: Medium

Local initialization files are used to configure the user’s shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Although the STIG requires that all initialization files for interactive users have proper owners, group owners, and permissions, these changes are often disruptive for users. The tasks in the security role do not make any changes to user initialization files.

Deployers should review the content and discretionary access controls applied to each user’s initialization files in their home directory.

STIG Description¶

Severity: Medium

Local initialization files for interactive users are used to configure the user’s shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Although the STIG requires that all initialization files for interactive users have proper owners, group owners, and permissions, these changes are often disruptive for users. The tasks in the security role do not make any changes to user initialization files.

Deployers should review the content and discretionary access controls applied to each user’s initialization files in their home directory.

STIG Description¶

Severity: Medium

Local initialization files are used to configure the user’s shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Although the STIG requires that all initialization files for interactive users have proper owners, group owners, and permissions, these changes are often disruptive for users. The tasks in the security role do not make any changes to user initialization files.

Deployers should review the content and discretionary access controls applied to each user’s initialization files in their home directory.

STIG Description¶

Severity: Medium

The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory (other than the user’s home directory), executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the Information System Security Officer (ISSO).

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Although the STIG requires that all initialization files must contain executable search paths that resolve to the user’s home directory, this change be disruptive for most users. The tasks in the security role do not make any changes to user initialization files.

STIG Description¶

Severity: Medium

If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level.

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.

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.

Deployer/Auditor notes¶

Implementation Status: Implemented - Red Hat Only

The tasks in the security role examine the SELinux contexts on each device file found on the system. Any devices without appropriate labels are printed in the Ansible output.

Deployers should investigate the unlabeled devices and ensure that the correct labels are applied for the class of device.

STIG Description¶

Severity: Medium

The “nosuid” mount option causes the system to not execute setuid and setgid files with owner privileges. This option must be used for mounting any file system not containing approved setuid and setguid files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Deployers should examine any filesystem mounts that contain home directories to ensure that the nosetuid option is set.

STIG Description¶

Severity: Medium

The “nosuid” mount option causes the system to not execute “setuid” and “setgid” files with owner privileges. This option must be used for mounting any file system not containing approved “setuid” and “setguid” files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

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

STIG Description¶

Severity: Medium

The “nosuid” mount option causes the system to not execute “setuid” and “setgid” files with owner privileges. This option must be used for mounting any file system not containing approved “setuid” and “setguid” files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

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.

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

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.

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.

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¶

Implementation Status: Implemented

The tasks in the security role check for the existence of /etc/cron.allow and set both the user and group ownership to root. This is the default on Ubuntu, CentOS, Red Hat Enterprise Linux systems, openSUSE Leap and SUSE Linux Enterprise 12 already.

STIG Description¶

Severity: Medium

If the group owner of the “cron.allow” file is not set to root, sensitive information could be viewed or edited by unauthorized users.

Deployer/Auditor notes¶

Implementation Status: Implemented

The group ownership for /etc/cron.allow is already set by the task for the following STIG control:

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

STIG Description¶

Severity: Medium

Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps may consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition.

Deployer/Auditor notes¶

Implementation Status: Implemented

The kdump service is disabled if it exists on the system. Deployers can opt out of this change by setting the following Ansible variable:

security_disable_kdump: no

STIG Description¶

Severity: Low

The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.

Deployer/Auditor notes¶

Implementation Status: Exception - Initial Provisioning

Deployers should consider using filesystem mounts for home directories during the initial server provisioning process. Adding filesystem mounts after a system is provisioned might lead to downtime.

The tasks in the security role do not take action on filesystem mounts. If the server does not mount /home as a separate filesystem, a warning is printed in the Ansible output.

STIG Description¶

Severity: Low

The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.

Deployer/Auditor notes¶

Implementation Status: Exception - Initial Provisioning

Deployers should consider using filesystem mounts for /var during the initial server provisioning process. Adding filesystem mounts after a system is provisioned might lead to downtime.

The tasks in the security role do not take action on filesystem mounts. If the server does not mount /var as a separate filesystem, a warning is printed in the Ansible output.

STIG Description¶

Severity: Low

The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.

Deployer/Auditor notes¶

Implementation Status: Exception - Initial Provisioning

Deployers should consider using filesystem mounts for /var/log/audit during the initial server provisioning process. Adding filesystem mounts after a system is provisioned might lead to downtime.

The tasks in the security role do not take action on filesystem mounts. If the server does not mount /var/log/audit as a separate filesystem, a warning is printed in the Ansible output.

STIG Description¶

Severity: Low

The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.

Deployer/Auditor notes¶

Implementation Status: Exception - Initial Provisioning

Deployers should consider using filesystem mounts for /tmp during the initial server provisioning process. Adding filesystem mounts after a system is provisioned might lead to downtime.

The tasks in the security role do not take action on filesystem mounts. If the server does not mount /tmp as a separate filesystem, a warning is printed in the Ansible output.

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.

STIG Description¶

Severity: Low

ACLs can provide permissions beyond those permitted through the file mode and must be verified by file integrity tools.

Deployer/Auditor notes¶

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.

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

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

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.

STIG Description¶

Severity: Medium

File integrity tools use cryptographic hashes for verifying file contents and directories have not been altered. These hashes must be FIPS 140-2 approved cryptographic hashes.

Deployer/Auditor notes¶

Implementation Status: Implemented

The default AIDE configuration in CentOS 7, Red Hat Enterprise Linux 7, openSUSE Leap and SUSE Linux Enterprise 12 already uses SHA512 to validate file contents and directories. No changes are required on these systems.

The tasks in the security role add a rule to end of the AIDE configuration on Ubuntu systems that uses SHA512 for validation.

STIG Description¶

Severity: Medium

Malicious users with removable boot media can gain access to a system configured to use removable media as the boot loader. If removable media is designed to be used as the boot loader, the requirement must be documented with the Information System Security Officer (ISSO).

Deployer/Auditor notes¶

Implementation Status: Exception - Initial Provisioning

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.

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

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.

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.

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

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'

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

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.

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

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

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

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

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

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.

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

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.

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

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.

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

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

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.

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

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.

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

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

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

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

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

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

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

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-000392-GPOS-00172, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit any time the semanage command is used.

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

security_rhel7_audit_semanage: no

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-000392-GPOS-00172, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209

Deployer/Auditor notes¶

Implementation Status: Implemented

Rules are added to audit any time the setsebool command is used.

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

security_rhel7_audit_setsebool: no

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-000392-GPOS-00172, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209

Deployer/Auditor notes¶

Implementation Status: Implemented

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

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

security_rhel7_audit_chcon: no

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-000392-GPOS-00172, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209

Deployer/Auditor notes¶

Implementation Status: Implemented

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

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

security_rhel7_audit_restorecon: no

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

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

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

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

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 unix_chkpwd command is used.

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

security_rhel7_audit_unix_chkpwd: no

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 gpasswd command is used.

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

security_rhel7_audit_gpasswd: no

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 chage command is used.

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

security_rhel7_audit_chage: no

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 userhelper command is used.

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

security_rhel7_audit_userhelper: no

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

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 sudo command is used.

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

security_rhel7_audit_sudo: no

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

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 newgrp command is used.

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

security_rhel7_audit_newgrp: no

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 chsh command is used.

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

security_rhel7_audit_chsh: no

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 sudoedit command is used.

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

security_rhel7_audit_sudoedit: no

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

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 umount command is used.

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

security_rhel7_audit_umount: no

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

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 postqueue command is used.

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

security_rhel7_audit_postqueue: no

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

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

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.

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

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

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

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

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-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Deployer/Auditor notes¶

Implementation Status: Implemented

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

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

security_rhel7_audit_insmod: no

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-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Deployer/Auditor notes¶

Implementation Status: Implemented

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

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

security_rhel7_audit_rmmod: no

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-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Deployer/Auditor notes¶

Implementation Status: Implemented

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

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

security_rhel7_audit_modprobe: no

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

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.

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

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

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

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.

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

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.

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.

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.

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

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.

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

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.

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'

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

STIG Description¶

Severity: Medium

Display of a standardized and approved use notification before granting access to the publicly accessible operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.

The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters:

"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests–not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007 , SRG-OS-000228-GPOS-00088

Deployer/Auditor notes¶

Implementation Status: Implemented

The tasks in the security role deploy a standard notice and consent banner into /etc/motd on each server. Ubuntu, CentOS, Red Hat Enterprise Linux, openSUSE Leap and SUSE Linux Enterprise display this banner after each successful login via ssh or the console.

Deployers can choose a different destination for the banner by setting the following Ansible variable:

security_sshd_banner_file: /etc/motd

The message is customized with the following Ansible variable:

security_login_banner_text: |
  ------------------------------------------------------------------------------
  * WARNING                                                                    *
  * You are accessing a secured system and your actions will be logged along   *
  * with identifying information. Disconnect immediately if you are not an     *
  * authorized user of this system.                                            *
  ------------------------------------------------------------------------------

STIG Description¶

Severity: Medium

Without cryptographic integrity protections, information 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: 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.

STIG Description¶

Severity: Medium

Without cryptographic integrity protections, information 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: 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.

STIG Description¶

Severity: Medium

Without cryptographic integrity protections, information 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: 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.

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

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, 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

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.

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.

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

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

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.

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.

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

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

The IgnoreRhosts 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_disallow_rhosts_auth: no

STIG Description¶

Severity: Medium

Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.

Deployer/Auditor notes¶

Implementation Status: Implemented

The PrintLastLog 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_print_last_log: no

STIG Description¶

Severity: Medium

Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging on directly as root. In addition, logging on with a user-specific account provides individual accountability of actions performed on the system.

Deployer/Auditor notes¶

Implementation Status: Implemented

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

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

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

The IgnoreUserKnownHosts 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_disallow_known_hosts_auth: no

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

STIG Description¶

Severity: Medium

DoD information systems are required to use FIPS 140-2 approved cryptographic hash functions. The only SSHv2 hash algorithm meeting this requirement is SHA.

Deployer/Auditor notes¶

Implementation Status: Implemented

The MACs configuration is set to hmac-sha2-256,hmac-sha2-512 in /etc/ssh/sshd_config and sshd is restarted.

Deployers can adjust the allowed Message Authentication Codes (MACs) by setting the following Ansible variable:

security_sshd_allowed_macs: 'hmac-sha2-256,hmac-sha2-512'

STIG Description¶

Severity: Medium

If a public host key file is modified by an unauthorized user, the SSH service may be compromised.

Deployer/Auditor notes¶

Implementation Status: Implemented

The permissions on ssh public host keys is set to 0644. If the existing permissions are more restrictive than 0644, the tasks do not make changes to the files.

STIG Description¶

Severity: Medium

If an unauthorized user obtains the private SSH host key file, the host could be impersonated.

Deployer/Auditor notes¶

Implementation Status: Implemented

The permissions on ssh private host keys is set to 0600. If the existing permissions are more restrictive than 0600, the tasks do not make changes to the files.

STIG Description¶

Severity: Medium

GSSAPI authentication is used to provide additional authentication mechanisms to applications. Allowing GSSAPI authentication through SSH exposes the system’s GSSAPI to remote hosts, increasing the attack surface of the system. GSSAPI authentication must be disabled unless needed.

Deployer/Auditor notes¶

Implementation Status: Implemented

The GSSAPIAuthentication setting is set to no to meet the requirements of the STIG.

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

security_sshd_disallow_gssapi: no

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

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

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

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'

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

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

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

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.

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

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)

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.

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.

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

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)

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

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)

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

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

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)

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.

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

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.

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

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

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.

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

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

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.

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.

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.

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.

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.

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

These packages are benign if they are not needed on a system, but authconfig-gtk may cause some graphical dependencies to be installed which may not be needed on some systems. The security role installs these packages, but it skips the installation of authconfig-gtk. Deployers can install the graphical package manually if needed.

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: Exception - Manual Intervention

Although the STIG requires that the sssd.conf contains both nss and pam authentication modules, this change can be disruptive in environments that are already using LDAP or Active Directory for authentication. Deployers should make these changes only if their environment is compatible.

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: Exception - Manual Intervention

Any adjustment to PKI authentication can cause disruptions for users. Deployers should verify that enabling OCSP validation is compatible with their existing configuration.

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: Exception - Manual Intervention

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.

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

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)

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

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)

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. “Pwquality” enforces complex password construction configuration on the system.

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

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¶

Implementation Status: Exception - Manual Intervention

Deployers should review their NFS mounts to ensure they are mounted with the noexec option. Deployers should skip this change if they execute applications from NFS mounts.

STIG Description¶

Severity: Medium

Taking appropriate action when there is an error sending audit records to a remote system will minimize the possibility of losing audit records.

Deployer/Auditor notes¶

Implementation Status: Implemented

This control is implemented by the tasks for another control:

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

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

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 account creations, modifications, disabling, and termination events that affect /etc/passwd. (V-72197)

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

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 account creations, modifications, disabling, and termination events that affect /etc/passwd. (V-72197)

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

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 account creations, modifications, disabling, and termination events that affect /etc/passwd. (V-72197)

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

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 account creations, modifications, disabling, and termination events that affect /etc/passwd. (V-72197)

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 not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects. (V-72293)

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.

STIG Description¶

Severity: Medium

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

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.

Satisfies: SRG-OS-000375-GPOS-00161,SRG-OS-000375-GPOS-00162

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

The STIG requires that multifactor authentication is used for graphical user logon, but this change requires custom configuration based on the authentication solution that is used.

Deployers should review the available options, such as traditional smartcards, USB devices (such as Yubikeys), or software token systems, and use one of these solutions on each system.

STIG Description¶

Severity: Medium

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

Deployer/Auditor notes¶

Implementation Status: Implemented

The ansible-hardening role disables the DCCP kernel module by default. Each system must be rebooted to fully apply the change.

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

security_rhel7_disable_dccp: no

STIG Description¶

Severity: Medium

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.

Deployer/Auditor notes¶

Implementation Status: Exception - Manual Intervention

Modifying sensitive systemd unit files directly or via overrides could cause a system to have issues during the boot process. The role does not make any adjustments to the rescue.service because this service is critical during emergencies.

All of the distributions supported by the role already require authentication for single user mode.

STIG Description¶

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.