User or automated authentication to a Linux system must be closely monitored and carefully configured to prevent unauthorized access.
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.
All of the tasks for these STIG requirements are included in
tasks/rhel7stig/auth.yml
.
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:
nullok
from /etc/pam.d/system-auth
nullok_secure
from /etc/pam.d/common-auth
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
This STIG control is implemented by:
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.
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.
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.
Deploying multi-factor authentication methods, including smart cards, is a complicated process that requires preparation and communication. This work is left to deployers to complete manually.
The 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.
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.
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
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.
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.
Deployers are strongly urged to utilize sssd
for systems that authenticate
against LDAP or Active Directory (AD) servers.
To meet this control, deployers must ensure that ldap_tls_cacert
or
ldap_tls_cacertdir
are set in the /etc/sssd/sssd.conf
file. The
ldap_tls_cacert
directive specifies a single certificate while
ldap_tls_cacertdir
specifies a directory where sssd
can find CA
certificates.
Warning
Use caution when adjusting these settings. If the correct CA certificates are not already deployed to the servers that perform LDAP authentication, their attempts to authenticate users might fail.
Consult with administrators of the LDAP system and test all changes on a non-production system first.
The 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.
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
This control is implemented by the tasks for another control:
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.
Any adjustment to PKI authentication can cause disruptions for users. Deployers should verify that enabling OCSP validation is compatible with their existing configuration.
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.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.