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
Deployer/Auditor notes¶
This STIG control is implemented by:
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 toyes
to apply the restriction to the root user or set tono
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.