auth - Authentication

User or automated authentication to a Linux system must be closely monitored and carefully configured to prevent unauthorized access.

Overview

Most of the STIG requirements for authentication are already included in Linux distributions by default or are easily applied without disruptions. Deployers should review the documentation below and test all changes on a non-production system first.

STIG requirements

All of the tasks for these STIG requirements are included in tasks/rhel7stig/auth.yml.

V-71937

  • Summary: The system must not have accounts configured with blank or null passwords.

  • Severity: High

  • Implementation Status: Implemented

Deployer/Auditor notes

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

V-71943

  • Summary: Accounts subject to three unsuccessful logon attempts within 15 minutes must be locked for the maximum configurable period.

  • Severity: Medium

  • Implementation Status: Opt-In - Red Hat Only

V-71945

  • Summary: If three unsuccessful root logon attempts within 15 minutes occur the associated account must be locked.

  • Severity: Medium

  • Implementation Status: Opt-In - Red Hat Only

Deployer/Auditor notes

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

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

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

security_pam_faillock_enable: yes

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

  • security_pam_faillock_attempts: This many failed login attempts within the specified time interval with trigger the account to lock. (STIG requirement: 3 attempts)

  • security_pam_faillock_interval: This is the time interval (in seconds) to use when measuring excessive failed login attempts. (STIG requirement: 900 seconds)

  • security_pam_faillock_deny_root: Set to yes to apply the restriction to the root user or set to no to exempt the root user from the account locking restrictions. (STIG requirement: yes)

  • security_pam_faillock_unlock_time: This sets the time delay (in seconds) before a locked account is automatically unlocked. (STIG requirement: 604800 seconds)

Note

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

V-71947

  • Summary: Users must provide a password for privilege escalation.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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

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

security_sudoers_nopasswd_check_enable: no

V-71949

  • Summary: Users must re-authenticate for privilege escalation.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.

V-71965

  • Summary: The operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users) using multifactor authentication.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.

V-71971

  • Summary: The operating system must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.

V-72001

  • Summary: The system must not have unnecessary accounts.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.

V-72217

  • Summary: The operating system must limit the number of concurrent sessions to 10 for all accounts and/or account types.

  • Severity: Low

  • Implementation Status: Opt-In

Deployer/Auditor notes

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

V-72227

  • Summary: The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) authentication communications.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.

V-72229

  • Summary: The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) communications.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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

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

Warning

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

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

V-72231

  • Summary: The operating system must implement cryptography to protect the integrity of Lightweight Directory Access Protocol (LDAP) communications.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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

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

Warning

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

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

V-72275

  • Summary: The system must display the date and time of the last successful account logon upon logon.

  • Severity: Low

  • Implementation Status: Verification Only

Deployer/Auditor notes

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.

V-72277

  • Summary: There must be no .shosts files on the system.

  • Severity: High

  • Implementation Status: Opt-In

Deployer/Auditor notes

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

V-72279

  • Summary: There must be no shosts.equiv files on the system.

  • Severity: High

  • Implementation Status: Implemented

Deployer/Auditor notes

This control is implemented by the tasks for another control:

V-72427

  • Summary: The operating system must implement multifactor authentication for access to privileged accounts via pluggable authentication modules (PAM).

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.

V-72433

  • Summary: The operating system must implement certificate status checking for PKI authentication.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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

V-72435

  • Summary: The operating system must implement smart card logons for multifactor authentication for access to privileged accounts.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.

V-77823

  • Summary: The operating system must require authentication upon booting into single-user and maintenance modes.

  • Severity: Medium

  • Implementation Status: Exception - Manual Intervention

Deployer/Auditor notes

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.